qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Xen-devel] [PATCH] Citrix PV Bus device


From: Tim Deegan
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Citrix PV Bus device
Date: Tue, 2 Jul 2013 11:15:34 +0100
User-agent: Mutt/1.4.2.1i

At 10:56 +0100 on 02 Jul (1372762607), Ian Campbell wrote:
> On Tue, 2013-07-02 at 10:14 +0100, Paul Durrant wrote:
> > I had actually coded up a solution based on the existing Xen platform
> > device, by having it synthesize a device ID based on the Xen version
> > to which we could then host the xenbus driver, to allow us to deploy
> > multiple versions of xenbus should compatibility (with things such as
> > the shared info interface) become an issue. The co-installer for this
> > driver could also spot existing PV driver installations and make sure
> > they don't get trashed.
> 
> I think only this last bit of functionality is critical here, and it
> allows us to avoid having to carry multiple platform devices in
> upstream, doesn't it?
> 
> > This idea was rejected by Citrix product teams though, because we
> > would not be able to prevent any Windows guest without some known PV
> > drivers from downloading our new driver from Windows Update and this
> > was seen as undesirable.
> 
> Well, if your product requirements are at odds with doing the right
> thing upstream then I think it would be best for you to just carry
> patches to make XS behave how you want.

I think it's a reasonable aim to have the WU drivers not spontaneously
appear on VMs (on all Xen hosts, remember) where the admin has chosen
not to install PV drivers. 

Generally, the more I think about this the more I'm convinced that _not_
installing the drivers on any existing systems without explicit
permission is the most important thing.

> I hope we can find a suitable compromise though.

Well, the WU drivers could refuse to install except as upgrade to
themselves (i.e. fail if there's any unknown driver bound to the xen
platform device, and also fail if there's _no_ driver bound).  Then the
guest admin can choose to install the drivers by hand and get automatic
updates after that.

XS, XC and anyone else who chooses could carry a separate patch that
changes the default to 'install if there are no drivers', signalling
over xenstore, or ACPI, or a Windows domain policy, or whatever.

Tim.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]