From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: (v2) Design proposal for RMRR fix Date: Wed, 14 Jan 2015 12:21:19 +0000 Message-ID: <1421238079.19103.246.camel@citrix.com> References: <54B3A71002000078000538E1@mail.emea.novell.com> <54B3AB380200007800053917@mail.emea.novell.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Tian, Kevin" Cc: "wei.liu2@citrix.com" , "stefano.stabellini@eu.citrix.com" , George Dunlap , "tim@xen.org" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Jan Beulich , "Zhang, Yang Z" , "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.org On Wed, 2015-01-14 at 09:43 +0000, Tian, Kevin 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?) NB the pci syntax already supports key=value style options, so this would have to use the more meaningful foo=try/force approach if you want to go this route (and it's also clearly preferable from a UI pov anyway). > > 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. Please avoid opaque "0" vs "1" values here too if you go this way. Ian.