Re: RFC - PV blk driver for hvm guest

[Steven Smith <sos22-xen@srcf.ucam.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1984 bytes --]

> My testing of the the PV blk driver was first done by creating a
> second blk device in the 'disk='' line of the config file.  I could
> not use the PV driver for the first device because the guest's ide
> driver lays claim on hda before the PV driver is loaded.  In an
> attempt to get the guest to come up entirely on the PV drivers I
> modified qemu's ide.c to make the emulated device incompatible with
> the native IDE driver.  This allows the PV driver to create hda and
> the OS came up just fine.  (I had also rebuilt the guest's initrd to
> include and load the PV drivers, of course.)
And the bootloader coped with this without any objections?  I suppose
they'd mostly be using BIOS services, and I could well believe our
BIOS doesn't actually bother to check the PCI device ids before going
at the IDE controller.

> Having proved to myself that the guest can come up on PV drivers
> alone, I returned to the issue of qemu always creating the IDE
> device in the emulated PCI config space as opposed to the nic
> support which creates a PCI entry programmatically.  I see that
> currently in the config one can indicate 'ioemu:' as an attribute of
> the 'dev' in the 'disk=' line.  This attribute, however, is ignored
> in blkif.py and the IDE entry is created anyway.  The 'vif=' line
> uses the token 'type=' to indicate that the nic device is emulated
> by qemu by setting the type equal to 'ioemu', the default being that
> the quest's LAN is supported by netback.  The parsers for the
> 'disk=' line do not look for the 'type=' token.
I don't think there are any firm plans for how to handle this at the
moment, and it's certainly not going to happen for a little while
3.0.3 gets ready.  There was a suggestion at one point of having both
types of device present in every domain and then trying to unplug the
ioemu ones if we find that we have PV drivers available, but it's not
obvious that we'd always be able to get in early enough in the boot
process.

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel