Xen devel - Feb 2007 - [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.

Hi,

This patch makes netfront grab the rtl8139 PCI ressources when running
as paravirtualized driver in a HVM domain.  If the driver fails to grab
the ressources it refuses to load.  If it succeeds grabbing the
ressources this shoulld prevent any other driver from taking the device.

This makes sure that we don''t have two drivers (8139 pci driver and
netfront) active for the same device.

The device is matched by both pci id and pci subsystem id (which was
added a few days ago), so netfront (aka xen-vnif) will grab a virtual
network card only, not a real rtl8139 card.

As a bonus we''ll get driver auto loading support as the modutils are
able now to figure the

Comments?
  Gerd

PS: The same would be good for blkfront too, although there it is less
    critical as only one of the drivers succeeds registering the ide
    major number, so it can''t happen that both grab the same disk.

-- 
Gerd Hoffmann <kraxel@suse.de>


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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Gerd Hoffmann
> Sent: 08 February 2007 16:51
> To: Xen devel list
> Subject: [Xen-devel] [rfc/patch] pv-on-hvm: make netfront 
> grab PCI ressources.
> 
>   Hi,
> 
> This patch makes netfront grab the rtl8139 PCI ressources when running
> as paravirtualized driver in a HVM domain.  If the driver 
> fails to grab
> the ressources it refuses to load.  If it succeeds grabbing the
> ressources this shoulld prevent any other driver from taking 
> the device.
What if someone has configured the network card type to something other
than 8139?

Or is the rtl8139 in the above example just another word for "some
network card in QEMU"?

--
Mats



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

Petersson, Mats wrote:
>  
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> Gerd Hoffmann
>> Sent: 08 February 2007 16:51
>> To: Xen devel list
>> Subject: [Xen-devel] [rfc/patch] pv-on-hvm: make netfront 
>> grab PCI ressources.
>>
>>   Hi,
>>
>> This patch makes netfront grab the rtl8139 PCI ressources when running
>> as paravirtualized driver in a HVM domain.  If the driver 
>> fails to grab
>> the ressources it refuses to load.  If it succeeds grabbing the
>> ressources this shoulld prevent any other driver from taking 
>> the device.
> 
> What if someone has configured the network card type to something other
> than 8139?
Then it doesn''t work.  Can you do that in xen?  I had the impression
you''ll have to use the qemu default nic ...
> Or is the rtl8139 in the above example just another word for "some
> network card in QEMU"?
No, it matches the 8139 pci id.  For other cards it needs simliar code
(and qemu a patch to add the xensource subsystem id ...).

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

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

On 8/2/07 16:50, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> This patch makes netfront grab the rtl8139 PCI ressources when running
> as paravirtualized driver in a HVM domain.  If the driver fails to grab
> the ressources it refuses to load.  If it succeeds grabbing the
> ressources this shoulld prevent any other driver from taking the device.
> 
> This makes sure that we don''t have two drivers (8139 pci driver
and
> netfront) active for the same device.
It seems to me this is a tools issue: they should ensure that only netback
or qemu advertises a particular interface. Or qemu interface could be
disabled when netback is connected to (although that wouldn''t stop
rtl8139
driver seeing the deactivated qemu interface). In any case, doing a hack in
netfront doesn''t work if the rtl8139 driver gets probed first?

 -- Keir



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

> Then it doesn''t work.  Can you do that in xen?  I had the
impression
> you''ll have to use the qemu default nic ...
>
> > Or is the rtl8139 in the above example just another word for
"some
> > network card in QEMU"?
>
> No, it matches the 8139 pci id.  For other cards it needs simliar code
> (and qemu a patch to add the xensource subsystem id ...).
Is there a future proofing issue here?  Future versions of the device models 
may use a different emulated network device (e.g. there''s recurrent 
discussion about whether we ought to emulate a device that will give us 
better potential for IO batching).

Guests that are deployed now may still be running on future versions of Xen 
with updated device models.

Cheers,
Mark


-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Keir Fraser wrote:
> On 8/2/07 16:50, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> 
>> This patch makes netfront grab the rtl8139 PCI ressources when running
>> as paravirtualized driver in a HVM domain.  If the driver fails to grab
>> the ressources it refuses to load.  If it succeeds grabbing the
>> ressources this shoulld prevent any other driver from taking the
device.
>>
>> This makes sure that we don''t have two drivers (8139 pci
driver and
>> netfront) active for the same device.
> 
> It seems to me this is a tools issue: they should ensure that only netback
> or qemu advertises a particular interface.
There is one problem with that approach:  The bochs BIOS talks to the
emulated devices for booting from the ide disk.  Once the OS is up and
running you''ll want to use the paravirtual blkfront driver if possible.
 Same for pxe boot and virtual nic I guess ...
> In any case, doing a hack in
> netfront doesn''t work if the rtl8139 driver gets probed first?
Well, netfront can''t grab the PCI device then, and refuses to load.
That case is harder to handle though, I''m not that happy with the
solution yet.  The current approach has the drawback that the driver
will work only with recent qemu-dm versions (subsystem ID is needed for
device matching).

Another idea:  We could make the tools add the ioport / iomem ranges to
xenstore.  Then the frontend drivers can try to grab these ressources
and refuse to initialize if they are not available.  This way we can
have some fancy helper functions to handle that.  The scheme also
doesn''t need frontend driver updates in case the emulated device
changes
from rtl8139 to something else.  And we don''t run into compatibility
problems.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

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

>>> On Fri, Feb 9, 2007 at  4:17 AM, in message
<45CC5846.3040606@suse.de>, Gerd
Hoffmann <kraxel@suse.de> wrote: 
> Keir Fraser wrote:
>> On 8/2/07 16:50, "Gerd Hoffmann" <kraxel@suse.de>
wrote:
>> 
>>> This patch makes netfront grab the rtl8139 PCI ressources when
running
>>> as paravirtualized driver in a HVM domain.  If the driver fails to
grab
>>> the ressources it refuses to load.  If it succeeds grabbing the
>>> ressources this shoulld prevent any other driver from taking the
device.
>>>
>>> This makes sure that we don''t have two drivers (8139 pci
driver and
>>> netfront) active for the same device.
>> 
>> It seems to me this is a tools issue: they should ensure that only
netback
>> or qemu advertises a particular interface.
> 
> There is one problem with that approach:  The bochs BIOS talks to the
> emulated devices for booting from the ide disk.  Once the OS is up and
> running you''ll want to use the paravirtual blkfront driver if
possible.
>  Same for pxe boot and virtual nic I guess ...
> 
>> In any case, doing a hack in
>> netfront doesn''t work if the rtl8139 driver gets probed first?
> 
> Well, netfront can''t grab the PCI device then, and refuses to
load.
> That case is harder to handle though, I''m not that happy with the
> solution yet.  The current approach has the drawback that the driver
> will work only with recent qemu- dm versions (subsystem ID is needed for
> device matching).
> 
> Another idea:  We could make the tools add the ioport / iomem ranges to
> xenstore.  Then the frontend drivers can try to grab these ressources
> and refuse to initialize if they are not available.  This way we can
> have some fancy helper functions to handle that.  The scheme also
> doesn''t need frontend driver updates in case the emulated device
changes
> from rtl8139 to something else.  And we don''t run into
compatibility
> problems.
> 
> cheers,
>   Gerd
Back in 3.0.3 and earlier, if the guest''s config file did not have the
''type=ioemu'' in the vif = [....] line, qemu would somehow not
be instructed to insert an emulated NIC into the guest.  Now, with or without
the ''type=ioemu'', an emulated device shows up in the guest. 
Maybe some tool enhancements could be done and based on the config file populate
emulated devices or not.

Thanks
Kirk


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