.bloggandomene

This post is about a nice discovery I made when I upgraded my XEN dom0 kernel to the latest one (2.6.32-).
I suddenly noticed that the I/O performance was highly dropping down when moving few small files (~350MB) from one partition to another one of the same hard-disk.

I worried myself so I began investigating about the issue and, eventually, I posted on xen-users mailing list .

After few days I’ve been told that the problem was probably given by the I/O scheduler on the guest machine.

The solution is to disable domU scheduler and leave all the work to the dom0 scheduler. And it, actually, did the trick for me.

In order to do that, just add ‘elevator=noop’ to the kernel’s bootflag of your guest machine and check if the system becomes more reactive.

If you are interested into the whole dynamic or you’re simply willing to understand better the reasons why this happens, here’s the thread on XEN mailing list.

If you’ll find a possible explanation for such a slow-down.

Just to be curious: drop me a comment about if something changes or not on your systems.

Yesterday we have made the tree. Don’t know what’s the correct translation of that but, I mean, we have decorated the tree. You know.. when you put some fancy balls on a tree to celebrate Christmas properly..
Well, during this task I’ve discovered that I am not using my Wireless Phones so much so I was wondering about a way to make use of them.

So came to my mind brilliant idea to try to connect those phones to my XEN home-server.
I rebooted the machine, enabled integrated audio in the BIOS and I started looking for a solution to pass the relative PCI audio controller to my virtual machine “aquaria” that is the one devoted to such a task.

By “Googleing” around I’ve found very few sparse information so I decided to blog about this, since I think PCI passthrough is a XEN point of strength.

PCI passthrough means the ability to literally pass a PCI peripheral to a domU domain in order to gave it the full control of that peripheral.

There are two ways to achieve this: using pciback or pcistub.

I’m going to consider only pciback in my post because I think it’s the most elegant solution.

In order to make your dom0 providing such a feature you’ll need CONFIG_XEN_PCIDEV_BACKEND=y in your dom0 kernel configuration.
In order to make your domU acknowledging such device you’ll need CONFIG_XEN_PCIDEV_FRONTEND=y in your domU kernel configuration.

Please, double check your configuration.

As far as I know, CONFIG_XEN_PCIDEV_FRONTEND, is available only in xen-patched kernel (so you won’t find such parameter in your vanilla kernel). I think this is a huge limitation since I hadn’t ever installed a xen-patched-domU kernel since yesterday. I hope someday it’s going to be merged in mainline.

However this isn’t enough to get your XEN environment working properly.
To allow dom0 passing the PCI device you should collect its address:

$ lspci | grep Audio

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

$ lspci -n | grep 00\:1b\.0

00:1b.0 0403: 8086:27d8 (rev 01)

Once you gathered those informations, you have to edit /boot/grub/grub.conf file in order to tell dom0 to use pciback to handle that PCI controller:

root (hd0,1)
kernel /boot/xen.gz
module /boot/vmlinuz root=/dev/sda2 pciback.permissive pciback.hide=(00:1b.0)

The next step is to properly configure your domU so, open its configuration file and add

pci = [ '00:1b.0' ]

.

Theorically this should be enough to make your domU working properly.

This is my dom0 dmesg after being restarted:

pciback 0000:00:1b.0: seizing device
pciback 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
pciback 0000:00:1b.0: PCI INT A disabled
pciback: vpci: 0000:00:1b.0: assign to virtual slot 0

And these are my domU dmesg and lspci:

pcifront pci-0: Installing PCI frontend
pcifront pci-0: Creating PCI Frontend Bus 0000:00

$ lspci -v

00:00.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
	Subsystem: Intel Corporation Device d604
	Flags: bus master, fast devsel, latency 0, IRQ 22
	Memory at 882a0000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
	Kernel driver in use: HDA Intel

I hope this walkthrough has been useful to you. If someone more experienced than me in these things would contact me to fix some mistakes, I’d be glad to hear him/her out