|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] RFC - PV blk driver for hvm guest
I've been experimenting with para-virtualized drivers running in hvm linux
guests and seeing, as do others, the significant performance benefit of the PV
drivers of the FV drivers. I have also noticed that qemu has the '-net' option
for emulating a nic, which the python code takes advantage of, but such an
option does not exist for the emulation of an ide device.
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.)
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 wish to create for block a similar functionality for block devices as we have
for nics. My guests will use the native FV nic drivers or the PV driver just
by simply adding or removing the 'type=ioemu' from the 'vif=' line. Adding
'type=' to 'disk=' will create appreciated consistency. Further I would like
to propose the introduction of a 'xenbus' type in addition to 'ioemu'. This is
in an effort to be backwards compatible to 3.0.2 as without specifying the type
the nic defaults to PV drivers but disk defaults to IDE emulation. Specifying
either 'ioemu' or 'xenbus' creates a obvious and deterministic result. It also
provides a convention for the possible introduction of other backends without
disturbing existing VMs.
With the introduction of the 'type=' for disk it follows that there must be
some changes to the python code and a new command line option for qemu which
would cause (or rather prevent) a PCI IDE entry when needed.
I write this longish letter in hopes of some relevant feedback, and to know if
work towards this end is already in progress.
Regards,
Ross Maxfield
Novell, Inc.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|