ESXi and Intel 82579v

/tmp/esxi/files/tmp/esxi/filesFor some strange reason ESXi has no driver for Intel 82579v NIC, and aborts the installation on a machine with such a NIC. Since I had no other machine to try ESXi on, and no PCI NIC was available at the moment, I've started to google for a solution. I've found some guide here, but ESXi-Customizer didn't work on my laptop, so I've used different tools to add the 82579v driver to ESXi installation ISO :)

First, loop mount the ISO image and extract the files from it:

mkdir -p /tmp/esxi/{mnt,files}
mount -t iso9660 -o loop /path/to/ESXi-installer-image.iso /tmp/esxi/mnt
cp -a /tmp/esxi/mnt/* /tmp/esxi/file

Then add the e1000e driver to the ESXi files:

cp /path/to/E1000E.tgz /tmp/esxi/files/net_igbe.t00
sed -i 's|/net_igb.v00|&1 --- /net_igbe.t00 ---|' /tmp/esxi/files/boot.cfg

And wrap the new ISO image:

mkisofs -o /path/to/updated/esxi-installer.iso \
-b isolinux.bin -c boot.cat -no-emul-boot \
-boot-load-size 4 -boot-info-table /tmp/esxi/files/

The image with 82579v is now ready for installation. After the ESXi is installed, it discards the custom driver and is should be added to the system on the hard disk. Luckily, I had Linux installed on the same box, so all I needed to do is to reboot to Linux, mount the ESXi partition containing the drivers and put E1000E.tgz there:

mkdir -p /tmp/esxi/mnt
mount /dev/sda5 /tmp/esxi/mnt/
cp /path/to/E1000E.tgz /tmp/esxi/mnt/net_igbe.t00
sed -i 's|/net_igb.v00|&1 --- /net_igbe.t00 ---|' /tmp/esxi/mnt/boot.cfg
umount /tmp/esxi/mnt/

After rebooting back to ESXi the network will be up and running.

HVX from 32768 feet

During last year and a half I am working on HVX project. If I remember correctly, HVX stands for HypeVisor eXtention.

It is а nested virtualization hypervisor implemented fully in software. Like KVM it's using QEMU for machine emulation, but instead of relying on hardware virtualization support for guest de-privileging, HVX uses dynamic binary translation of the guest kernel. The guest instructions that might access privileged state are simulated, while "safe" instructions are executed as is. Despite the apparent overhead the guest runs pretty fast, thanks to locality principle, caching, hashing and that kind of stuff.

Since the guest is not allowed to execute privileged instructions, it has no means to control its virtual memory mappings and HVX implements software MMU and maintains shadow page tables.

Add to it emulation of several performance critical devices and that more or less completes the picture :)

Yesterday we've had a launch of public beta in Ravello Systems. So, now I can openly talk about what I've been doing for the last year and a half :)

Launchpad Bug 571663

Several month ago OMAP3 SoCs were added to the list of ARM platforms supported by Lucid Lynx. And it was really disappointing to see that the only OMAP platform that’s not included in the Ubuntu kernel is the one I maintain...

So, I've opened a bug in the Launchpad and after three months of silence the bug is resolved as "Won't fix". Really annoying...

drivers

It's very entertaining to hear people talking about Linux device drivers for particular platform. For example, "we have developed drivers for our chip for omap3evm". Or "our driver perfectly works on Mainstone therefore porting it to your PXA platfrom should be realy easy". And the best one "How much time would it take to make the driver we used with PXA270 work on PXA300?".
I admit I was not there in the VxWorks days. More than that, I almost was not there in 2.4 and early 2.6 kernel days. But making such statements now when driver model exists in Linux kernel for several years sounds real nonsense. In Linux either you have a device driver or not. It cannot be a driver that works on platform A and fails on platform B. If an SPI network chip has driver for a single development platform, or even worse, lot of

#ifdef PLATFORM_A
  ... some code ...
#elif defined(PLATFORM_B)
  ... some other code ...
#endif

fragments in the driver, it means that this chip has no Linux device driver.

LPC

I had a really busy time last month. Being ten days off at the end of October made very backlogged at work and it was not that easy to catch up.

So, at the end of October I was at LinuxCon and LinuxPlumbers. The first one was mostly about marketing of desktop Linux and business acievements in the server market. So, most of the talks were in the business spirit and somehow seemed bored to me, modest developer. Except, perhaps, the Kernel Roundtable, that was really entertaining.

The Plumbers conference, on the contrary, aimed the developers and most presentations and sessions were "development driven". Although most of the speakers were less proficient in presentations than Mark Shuttleworth or Jim Zemlin, it was much more interesting for me to attend Plumbers talks than LinuxCon ones.

Some concluding notes from the conferences:
- ARM chip vendors are pushing towards ARM net-top/net-book. Ubuntu Karmic Koala supports Freescale iMX.51 and Marvell Dove, and according to Canonical insiders Freescale and Marvel are behind it :)
- Intel tries hard to increse Atom MID devices market share and even enter cell phone market with x86 architecture. And, according to H. Peter Anvin, "New Intel low-power chip is not a PC".
- V4L will undergo large rework to target capture controllers found in modern SoCs
- People say that the best connection point between Europe and US is Frankfurt

Ubuntu ARM

These days I've checked how Ubuntu can run on ARM machine. TI claims that OMAP3 gives "Laptop-like performance at handheld power levels in a single chip". And there's no way you cannot run Ubuntu on a laptop.