Re: [Xen-devel] (v2) Design proposal for RMRR fix

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-14 at 06:52 +0000, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > Sent: Wednesday, January 14, 2015 12:06 AM
> > 
> > >>> On 13.01.15 at 17:00, <george.dunlap@xxxxxxxxxxxxx> wrote:
> > > Another option I was thinking about: Before assigning a device to a
> > > guest, you have to unplug the device and assign it to pci-back (e.g.,
> > > with xl pci-assignable-add).  In addition to something like rmmr=host,
> > > we could add rmrr=assignable, which would add all of the RMRRs of all
> > > devices currently listed as "assignable".  The idea would then be that
> > > you first make all your devices assignable, then just start your guests,
> > > and everything you've made assignable will be able to be assigned.
> > 
> > Nice idea indeed, but I'm not sure about its practicability: It may
> > not be desirable to make all devices eventually to be handed to a
> > guest prior to starting any of the guests it may get handed to. In
> > particular there may be reasons why the host needs the device
> > while (or until after) creating the guests.
> > 
> 
> and I'm not sure whether there's enough knowledge to judge whether 
> a device is assignable since potential conflicts may be detected only
> when the guest is launched.

I don't think George was intending to imply otherwise, assignable here
just means "bound to xen-pciback", there may be other reasons why the
device cannot be assigned in practice when you come to actually use it,
i.e. RMRR conflicts which may only be discovered when a guest is started
would be one such practical reason.

George's suggestion sounds to me like a nice shortcut configuration
which will benefit many users, even if not all of them. So long as more
fine grained control is an option itseems like a Nice To Have type
thing.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel