From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: (v2) Design proposal for RMRR fix Date: Wed, 14 Jan 2015 12:01:56 +0000 Message-ID: <54B65AB4.5060504@eu.citrix.com> References: <54B3AE8802000078000539B7@mail.emea.novell.com> <54B515E6020000780005444A@mail.emea.novell.com> <54B54D48020000780005473E@mail.emea.novell.com> <54B540AA.1010905@eu.citrix.com> <54B63E250200007800054A36@mail.emea.novell.com> <54B651EE0200007800054ADD@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B651EE0200007800054ADD@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Kevin Tian Cc: "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "tim@xen.org" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org On 01/14/2015 10:24 AM, Jan Beulich wrote: >>>> On 14.01.15 at 10:43, wrote: >>> From: Jan Beulich [mailto:JBeulich@suse.com] >>> Sent: Wednesday, January 14, 2015 5:00 PM >>> >>>>>> On 14.01.15 at 09:06, 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. -George