All of lore.kernel.org
 help / color / mirror / Atom feed
* [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
@ 2007-02-08 16:50 Gerd Hoffmann
  2007-02-08 16:56 ` Petersson, Mats
  2007-02-08 17:13 ` Keir Fraser
  0 siblings, 2 replies; 7+ messages in thread
From: Gerd Hoffmann @ 2007-02-08 16:50 UTC (permalink / raw)
  To: Xen devel list

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

  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>

[-- Attachment #2: grab-ports.diff --]
[-- Type: text/x-patch, Size: 3177 bytes --]

diff -r 780f097b54c5 linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c	Wed Feb 07 17:29:52 2007 +0000
+++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c	Thu Feb 08 16:44:05 2007 +0100
@@ -2074,8 +2074,97 @@ static struct notifier_block notifier_in
 	.priority       = 0
 };
 
+/* ------------------------------------------------------------------ */
+
+#ifndef CONFIG_XEN
+#include <linux/pci.h>
+
+#define DRV_NAME "netfront"
+
+static int rtl8139_taken = 0;
+
+static void __devexit rtl8139_release(struct pci_dev *pdev)
+{
+	long ioaddr, iolen;
+	long mmio_addr, mmio_len;
+
+	ioaddr = pci_resource_start(pdev, 0);
+	iolen = pci_resource_len(pdev, 0);
+	mmio_addr = pci_resource_start(pdev, 1);
+	mmio_len = pci_resource_len(pdev, 1);
+
+	release_region(ioaddr, iolen);
+	release_mem_region(mmio_addr, mmio_len);
+
+	printk(KERN_INFO DRV_NAME ": released rtl8139 card\n");
+	rtl8139_taken--;
+}
+
+static int __devinit rtl8139_grab(struct pci_dev *pdev,
+				  const struct pci_device_id *ent)
+{
+	int ret;
+	long ioaddr, iolen;
+	long mmio_addr, mmio_len;
+
+	ret = pci_enable_device(pdev);
+	if (ret) {
+		printk(KERN_ERR DRV_NAME ": can't enable device\n");
+		return ret;
+	}
+
+	ioaddr = pci_resource_start(pdev, 0);
+	iolen = pci_resource_len(pdev, 0);
+
+	mmio_addr = pci_resource_start(pdev, 1);
+	mmio_len = pci_resource_len(pdev, 1);
+
+	if (request_mem_region(mmio_addr, mmio_len, DRV_NAME) == NULL)
+	{
+		printk(KERN_ERR DRV_NAME ": MEM I/O resource 0x%lx @ 0x%lx busy\n",
+		       mmio_addr, mmio_len);
+		return -EBUSY;
+	}
+
+	if (request_region(ioaddr, iolen, DRV_NAME) == NULL)
+	{
+		printk(KERN_ERR DRV_NAME ": I/O resource 0x%lx @ 0x%lx busy\n",
+		       iolen, ioaddr);
+		release_mem_region(mmio_addr, mmio_len);
+		return -EBUSY;
+	}
+
+	printk(KERN_INFO DRV_NAME ": grabbed rtl8139 card\n");
+	rtl8139_taken++;
+	return 0;
+}
+
+static struct pci_device_id rtl8139_pci_tbl[] __devinitdata = {
+	{
+		.vendor    = 0x10ec,  // Realtek
+		.device    = 0x8139,  // 8139
+		.subvendor = 0x5853,  // XenSource
+		.subdevice = 0x0001,  // #1
+	},
+	{0,}
+};
+MODULE_DEVICE_TABLE(pci, rtl8139_pci_tbl);
+
+static struct pci_driver rtl8139_grabber = {
+	.name     = DRV_NAME,
+	.probe    = rtl8139_grab,
+	.remove   = __devexit_p(rtl8139_release),
+	.id_table = rtl8139_pci_tbl,
+};
+
+#endif
+
+/* ------------------------------------------------------------------ */
+
 static int __init netif_init(void)
 {
+	int ret;
+	
 	if (!is_running_on_xen())
 		return -ENODEV;
 
@@ -2092,6 +2181,14 @@ static int __init netif_init(void)
 	if (is_initial_xendomain())
 		return 0;
 
+#ifndef CONFIG_XEN
+	ret = pci_module_init(&rtl8139_grabber);
+	if (ret)
+		return ret;
+	if (!rtl8139_taken)
+		return -EBUSY;
+#endif
+
 	IPRINTK("Initialising virtual ethernet driver.\n");
 
 	(void)register_inetaddr_notifier(&notifier_inetdev);
@@ -2108,6 +2205,9 @@ static void __exit netif_exit(void)
 
 	unregister_inetaddr_notifier(&notifier_inetdev);
 
+#ifndef CONFIG_XEN
+	pci_unregister_driver(&rtl8139_grabber);
+#endif
 	return xenbus_unregister_driver(&netfront);
 }
 module_exit(netif_exit);

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

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-08 16:50 [rfc/patch] pv-on-hvm: make netfront grab PCI ressources Gerd Hoffmann
@ 2007-02-08 16:56 ` Petersson, Mats
  2007-02-08 17:05   ` Gerd Hoffmann
  2007-02-08 17:13 ` Keir Fraser
  1 sibling, 1 reply; 7+ messages in thread
From: Petersson, Mats @ 2007-02-08 16:56 UTC (permalink / raw)
  To: Gerd Hoffmann, Xen devel list

 

> -----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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-08 16:56 ` Petersson, Mats
@ 2007-02-08 17:05   ` Gerd Hoffmann
  2007-02-08 17:55     ` Mark Williamson
  0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2007-02-08 17:05 UTC (permalink / raw)
  To: Petersson, Mats; +Cc: Xen devel list

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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-08 16:50 [rfc/patch] pv-on-hvm: make netfront grab PCI ressources Gerd Hoffmann
  2007-02-08 16:56 ` Petersson, Mats
@ 2007-02-08 17:13 ` Keir Fraser
  2007-02-09 11:17   ` Gerd Hoffmann
  1 sibling, 1 reply; 7+ messages in thread
From: Keir Fraser @ 2007-02-08 17:13 UTC (permalink / raw)
  To: Gerd Hoffmann, Xen devel list

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-08 17:05   ` Gerd Hoffmann
@ 2007-02-08 17:55     ` Mark Williamson
  0 siblings, 0 replies; 7+ messages in thread
From: Mark Williamson @ 2007-02-08 17:55 UTC (permalink / raw)
  To: xen-devel; +Cc: Petersson, Mats, Gerd Hoffmann

> 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!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-08 17:13 ` Keir Fraser
@ 2007-02-09 11:17   ` Gerd Hoffmann
  2007-02-09 16:03     ` Kirk Allan
  0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2007-02-09 11:17 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Xen devel list

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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
  2007-02-09 11:17   ` Gerd Hoffmann
@ 2007-02-09 16:03     ` Kirk Allan
  0 siblings, 0 replies; 7+ messages in thread
From: Kirk Allan @ 2007-02-09 16:03 UTC (permalink / raw)
  To: Keir Fraser, Gerd Hoffmann; +Cc: Xen devel list



>>> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-02-09 16:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08 16:50 [rfc/patch] pv-on-hvm: make netfront grab PCI ressources Gerd Hoffmann
2007-02-08 16:56 ` Petersson, Mats
2007-02-08 17:05   ` Gerd Hoffmann
2007-02-08 17:55     ` Mark Williamson
2007-02-08 17:13 ` Keir Fraser
2007-02-09 11:17   ` Gerd Hoffmann
2007-02-09 16:03     ` Kirk Allan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.