All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Luciano Rocha <strange@nsk.no-ip.org>
Cc: Steve Ofsthun <sofsthun@virtualiron.com>,
	Andy Grover <andy.grover@oracle.com>,
	cgriffin@novell.com, James Harper <james.harper@bendigoit.com.au>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: RE: GPL Win PV driver issues
Date: Fri, 14 Dec 2007 20:40:32 +0000	[thread overview]
Message-ID: <20071214204032.GJ9211@redhat.com> (raw)
In-Reply-To: <20071214193659.GE28463@bit.office.eurotux.com>

On Fri, Dec 14, 2007 at 07:36:59PM +0000, Luciano Rocha wrote:
> On Fri, Dec 14, 2007 at 02:21:41PM -0500, Steve Ofsthun wrote:
> <snip>
> > At Virtual Iron, we currently manage domains directly (no xend, xm,
> > etc).  To deal with PV driver devices we have marked devices in xenstore
> > as being QEMU devices or PV "accelerated" devices.  Devices are allowed
> > to show up as both, but they don't default that way.  This allows us to
> > control visibility on a device by device basis.  This has been useful
> > for development but is not really visible to our customers.  Our product
> > just allows either all QEMU or all PV, but not both or any mix.
> <snip>
> > In the specialized case of boot devices, we need to access the QEMU
> > device from the BIOS boot sequence.  We chose not to change the BIOS to
> > access the PV devices via Xenbus, etc.  Instead we added a probe limit
> > option to QEMU devices that basically says that devices are only allowed
> > to respond to device probes X times.  For booting with the current BIOS
> > we limit IDE probes to 1 (the BIOS only).  This allows all BIOS access
> > to the device to proceed, but the guest OS probe will fail to detect the
> > emulated device.  As the guest OS boots, it only sees the device via the
> > PV drivers.
> 
> I've been thinking about this. Isn't it possible to allow both QEMU and
> PV devices to exist, and create a combined HW/PV driver? I.e., a driver
> for both the emulated device under Windows (as a later version than the
> one shipped in Windows). Then, if really running under Xen, the driver
> instructs dom0 to optionally terminate the QEMU server side and use the
> PV approach for communication.

It is *required* that both the QEMU and PV devices co-exist at the same
time for PV to be usable in the general case. Requiring modifications to
the Dom0 config file of a VM before PV can be used is not practical.
The admin in charge of the Dom0 cannot be assumed to be the same as the
admin in charge of the DomU. The DomU admin needs to be able to switch
to/from the PV drivers at will, without having to get Dom0 admin to do
magic config changes for them.

The easy solution is for the PV drivers to grab the PCI resources associated
with the emulated devices. So once the PV driver has loaded, then it is
impossible for the non-PV driver to activate itself. Likewise if the non-PV
driver is loaded, then the PV driver will be unable to grab the PCI resources
and can thus disable itself. No special Dom0 config required..

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

  parent reply	other threads:[~2007-12-14 20:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 21:05 GPL Win PV driver issues Andy Grover
2007-12-14  0:13 ` James Harper
2007-12-14 19:21   ` Steve Ofsthun
2007-12-14 19:36     ` Luciano Rocha
2007-12-14 19:42       ` Stefan de Konink
2007-12-14 20:16         ` Luciano Rocha
2007-12-14 22:19           ` James Harper
2007-12-14 20:40       ` Daniel P. Berrange [this message]
2007-12-14 21:51         ` Steve Ofsthun
2007-12-15  4:09           ` Mark Williamson
2007-12-15 16:50             ` Daniel P. Berrange
2007-12-15 16:52           ` Daniel P. Berrange
2007-12-16  5:59             ` James Harper
2007-12-14 22:21         ` James Harper
2007-12-14 22:37           ` Andy Grover
2007-12-14 22:53             ` James Harper
2007-12-14 22:17       ` James Harper
2008-01-01 19:06         ` Brian Wolfe
2008-01-02  2:45           ` James Harper
2008-01-02  3:32             ` Brian Wolfe
2008-01-02  4:20               ` James Harper
2008-01-02  7:24                 ` Brian Wolfe
2008-01-02  8:44                   ` James Harper
2008-01-20 10:19                     ` Stephan Seitz
2008-01-20 10:29                       ` James Harper

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=20071214204032.GJ9211@redhat.com \
    --to=berrange@redhat.com \
    --cc=andy.grover@oracle.com \
    --cc=cgriffin@novell.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=sofsthun@virtualiron.com \
    --cc=strange@nsk.no-ip.org \
    --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.