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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> Sent: Wednesday, January 14, 2015 8:02 PM
> 
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
> >>>> On 14.01.15 at 10:43, <kevin.tian@xxxxxxxxx> wrote:
> >>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >>> Sent: Wednesday, January 14, 2015 5:00 PM
> >>>
> >>>>>> On 14.01.15 at 09:06, <kevin.tian@xxxxxxxxx> wrote:
> >>>> Now the open is whether we want to fail domain creation for all of above
> >>>> conflicts. user may choose to bear with conflicts at his own disposal, or
> >>>> libxl doesn't want to fail conflicts as preparation for future
> >>>> hotplug/migration.
> >>>> One possible option is to add a per-region flag to specify whether
> treating
> >>>> relevant conflict as an error, when libxl composes the list to domain
> >>>> builder.
> >>>> and this information will be saved in a user space database accessible to
> >>>> all components and also waterfall to Xen hypervisor when libxl requests
> >>>> actual device assignment.
> >>>
> >>> That's certainly a possibility, albeit saying (in the guest config) that
> >>> a region to be reserved only when possible is about the same as
> >>> not stating that region. If at all, I'd see the rmrr-host value be a
> >>> tristate (don't, try, and force) to that effect.
> >>>
> >>
> >> how about something like below with bi-state?
> >>
> >> for statically assigned device:
> >>    pci = [ "00:02.0, 0/1" ]
> >> where '0/1' represents try/force (or use 'try/force', or have a meaningful
> >> attribute like rmrr_check=try/force?)
> >
> > As said many times before, for statically assigned devices such a flag
> > makes no sense.
> >
> >> for other usages like hotplug/migration:
> >>    reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1', 
> >> ...]
> >> If 'host' is specified, it implies rmrr_host, besides user can specific
> >> explicit ranges according to his detail requirement.
> >
> > For host the flag makes sense, but for the explicitly specified regions
> > - as said before - I don't think it does.
> 
> You don't think there are any circumstances where an admin should be
> allowed to "shoot himself in the foot" by assigning a device which he
> knows the RMRRs conflict -- perhaps because he "knows" that the RMRRs
> won't actually be used?
> 
> I thought I heard someone say that many devices will only use RMRRs for
> compatibility with older OSes or during boot; in which case, there may
> be devices which you can safely assign to newer OSes / hot-plug after
> the guest has booted even without reserving the RMRR.  If such devices
> exist, then the admin should be able to assign those, shouldn't they?
> 
> Making it "rmrr=force" by default, but allowing an admin to specify
> "rmrr=try", makes sense to me.  It does introduce an extra layer of
> complication, so I wouldn't push for it; but if Kevin / Intel wants to
> do the work, I think it's a good thing.
> 

We'd like to hear more opinions here, both from developers and users.
Possibly Citrix guys have more inputs from Xenserver/Xenclient
productions, because they may have some devices assigned before
which have RMRR but not expose an issue before this fix (e.g. USB 
controller in a laptop). Now adding a strict policy to treat all conflicts
as error may cause some regression on those usages. I'm not sure
how severe it will be. If it's apparently not a problem to most people,
then we can follow that simple policy which is easier. :-) 

Thanks
Kevin

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