ARM virtualization.

So this is pretty awesome. It's not just a prototype for the ARM big.LITTLE architecture, but also a good example of writing a hypervisor targetting ARM.

http://git.linaro.org/gitweb?p=arm/big.LITTLE/switcher.git;a=summary

http://lwn.net/Articles/481055/

How not to write specifications.

Since my current definition of "havin' a good time" means attempting to start a native NT application in Linux, I am forced to be quite familiar with the PE-COFF format.

Needless to say, this is a poorly written specification. Here are some of the questions you won't find an answer to.

1. Endianness of the format. Is it always little-endian? (i.e. for big-endian machines as well?). Apparently, yes.
2. Endianness of applying the relocation records. The base relocation record is obviously LE, but what about the modified VAs? I would assume target-endianness, but this isn't actually noted.
3. Optional header checksum: what's the actual algorithm? I mean, it can't be any more interesting than a CRC32, and an *interested party* will obviously reverse engineer this, so you can't actually think that hiding such details is a security mechanism?
4. What is the expected result of IMAGE_REL_BASED_HIGHADJ? Community consensus implies that the high value of the 32-bit word modified needs to be sign adjusted. Why not just say that in the specification?
5. Why not list what base relocation types apply to what architectures?

I am sure there are more...

Linux Kernel unit testing.

Most software engineers, when asked how they would approach designing and implementing a particular component, will always say something about unit tests. Especially so if put on the spot in an interview setting. Yet, examining something like the Linux kernel, Xen or Tiano Core UEFI, you see plenty of new complex code that has no unit or component testing anywhere in sight.

Varying SCSI queue depth for VMware PVSCSI block devices.

I was toying with the block subsystem a bit in a Linux virtual machine running under ESX 5.0, when I realized
I could not change the SCSI queue depth. It turns out that the driver simply didn't implement the interface! It was, however, pretty easy to fix this.

https://github.com/andreiw/andreiw-wip/blob/master/linux/3.2/0001-VMW_PVSCSI-Allow-TCQ-depth-change-through-sysfs.patch

Now you can do something like the following:

# for i in {a..z}; do  eval 'echo 1 > /sys/block/sd$i/device/queue_depth'; done

The patch should make it to mainline, when the current PVSCSI maintainer, Arvind Kumar, gets it integrated.

Why would you care? Because /sys/block/sda/device/queue_depth is quite different from /sys/block/sda/queue/nr_requests. nr_requests controls the request flow before the I/O scheduler, while queue_depth controls the flow of actual dispatch on I/O device. You might be interested in either of those if you run with multiple VMDKs, have an intensive I/O workload on one disk, and notice starvation on others.

PE32+

One gloomy evening I decided to look at the latest Portable Executable specification, and thought it would
be pretty cool to write a PE loader.

Doing so under Linux is not particularly difficult, given the binfmt infrastructure, already well used to support legacy and emulation targets.

Two gloomy evenings later I had something that could load a rudimentary PE-COFF executable :-). It doesn't handle an IAT yet, so no shared objects, and since I was in a hurry and tired, no relocations and section alignment must equal file alignment, but I'll work those three out eventually.

Since I didn't have a PE tool chain on hand, I assembled the headers manually, kindly borrowing from them Tiny PE work.

So, uh, why? Firstly, because I can. It's fun, and it exposes me to those parts of the kernel that you don't have much opportunity otherwise to meddle in (and where the learning curve is steeper than usual). But I was lately
wondering what it would take to run the ReactOS userspace under Linux... So you could say my end goal is
write an NT personality for Linux, so I can run an unmodified ReactOS smss.exe with an unmodified ntdll.dll.

Anyway, as usual, the patch against 3.2+ and example hello.asm on my Github account -
https://github.com/andreiw/andreiw-wip/tree/master/linux/3.2/pe32+

Have fun!

FIQ debugger, redux.

I found myself (temporarily, thanks Chris!) in the posession of an OLPC XO 1.75 . Very interesting hardware. The Marvell chip isn't something to particularly rave about (compared to the Xoom's dual Cortex-A9s), but at the end of the day it's a completely open platform (hardware and software), that runs an OS based on Fedora. Plus it uses OpenFirmware instead of some half-baked ROM monitor or a UEFI.. Totally cool. The other great thing is that the kernel is a 3.0-based kernel (not mainline, but w/e), which makes this that much more interesting, especially in light of my interests in MMC flash block core and ARM KGDB/KDB support.

Anyway, while playing with it I had the system wedge up in some totally useless state. Given a lack of a FIQ watchdog or debugger code, I decided to port the FIQ debugger over...

Update: Looks like the XO folks found it useful to hunt for some bugs, cool!

Quick update.

I've been very busy recently with my move to Boston, MA, hence the lack of new content. I have now joined the ranks of VMware employees. Hopefully in the next few weeks I'll have the time to blog about all the interesting things I've stumbled upon and done since my last update :-).

I've been setting up my new personal laptop with Arch Linux, and after migrating my .emacs over
took a look what was in my emacs backups directory. Wow! There is some pretty interesting stuff...from end of High School all the way through college and beyond:
- RM16->PM32 start code for my Bochs32 EDK1 TianoCore port.
- A cassette basic loader and cassette-over-serial ROM emulation for running the MS ROM BASIC in Bochs.
- ELF loader development.
- Beginnings of an RO UEFI NTFS driver.
- Various files from my kernel projects, including ppc7xxx support.
- Various PowerPC and OpenFirmware os-dev related files.
- NES emulator UIC SIGGAME project files.
- LaTeXed homework assignments, scholarship papers, Haskell sources, shell, compilers, etc.
- ZINN Is Not Notes notesfiles replacement from IMSA.

This is exactly why I should convert my entire home directory into a git repo :-).