All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@suse.de>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen devel list <xen-devel@lists.xensource.com>
Subject: Re: [rfc/patch] pv-on-hvm: make netfront grab PCI ressources.
Date: Fri, 09 Feb 2007 12:17:26 +0100	[thread overview]
Message-ID: <45CC5846.3040606@suse.de> (raw)
In-Reply-To: <C1F10AAE.91E8%Keir.Fraser@cl.cam.ac.uk>

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>

  reply	other threads:[~2007-02-09 11:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2007-02-09 16:03     ` Kirk Allan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45CC5846.3040606@suse.de \
    --to=kraxel@suse.de \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.