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:23:05 +0000 Message-ID: <54B65FA9.4030704@eu.citrix.com> References: <54B3AB380200007800053917@mail.emea.novell.com> <54B3AE8802000078000539B7@mail.emea.novell.com> <54B54C09020000780005472D@mail.emea.novell.com> <54B5411F.8060208@eu.citrix.com> <54B5509402000078000547A5@mail.emea.novell.com> <1421237655.19103.242.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1421237655.19103.242.camel@citrix.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: Ian Campbell , "Tian, Kevin" Cc: "wei.liu2@citrix.com" , "stefano.stabellini@eu.citrix.com" , "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 01/14/2015 12:14 PM, Ian Campbell wrote: > On Wed, 2015-01-14 at 06:52 +0000, Tian, Kevin wrote: >>> From: Jan Beulich [mailto:JBeulich@suse.com] >>> Sent: Wednesday, January 14, 2015 12:06 AM >>> >>>>>> On 13.01.15 at 17:00, 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. Yes -- xl has a concept called "pci-assignable". Before you can add a device to a guest, you have to call "xl pci-assignable-add [device spec]". You can also run "xl pci-assignable-list" to see which devices are currently assignable. Normally this is true even for statically-assigned devices: If you add pci= [ "$bdi" ] to a config file, and $bdi hasn't been made assignable, then the pci-attach in domain creation will fail and the domain will be destroyed. You can make the domain builder do this automatically with the "seize=1" parameter; i.e., pci = [ "$bdf,seize=1" ]. My suggestion was that in addition to specifying the particular ranges, and specifying rmrr=host, we could also specify "rmrr=assignable", which would cause the domain builder to internally run libxl_pci_assignable_list() and find the RMRRs for all devices on the list. But as Ian says, that's a "nice to have", not a requirement. -George