WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RFC - PV blk driver options for hvm guest

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC - PV blk driver options for hvm guest
From: "Ross Maxfield" <rmaxfiel@xxxxxxxxxx>
Date: Wed, 04 Oct 2006 11:34:16 -0400
Delivery-date: Wed, 04 Oct 2006 08:35:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>>> Steven Smith <sos22-xen@xxxxxxxxxxxxx> 10/01/06 11:42 AM >>> 
>> 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.

There were no apparent objections to booting on the PV blk driver.
Needless to say, I was quite pleased, as well, at how much more rapidly the
the guest OS came up.


As I look further into this, an over-arching question begins to form.  
Originally, I had suggested that a 'type=' be added to the 'disk' line, like 
the net, to indicate the use of FV or PV drivers.  But now I'm wondering if a 
more global tag should be used to indicate that all drivers are either FV or 
PV.  Implementing the original idea would be a more involved but create the 
opportunity for one disk device to be supported by a FV driver and another by a 
PV driver.  The question is, why would anyone ever wish to have mixed driver 
technology?  With the PV drivers having such a profound increase in performance 
and given that PV drivers are available for the quest (and assuming if a a PV 
driver is available for one technology, i.e. LAN or BLK, then it would be 
available for the other) then why would someone use the FV driver? Thus the 
more simple solution to have a single switch in the guest's config file 
indicating the mode for all devices, LAN or BLK.

Having said all this, it occurs to me that this idea may be a bit premature as 
qemu's emulation of the ide device has sufficient support for removable media, 
whereas PV blk drivers have very little, therefore, being able to indicate 
which blk devices use either PV of FV drivers is warranted, at least for now. 

-- Ross




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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Xen-devel] RFC - PV blk driver options for hvm guest, Ross Maxfield <=