From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: (v2) Design proposal for RMRR fix Date: Fri, 9 Jan 2015 15:27:34 -0500 Message-ID: <20150109202734.GF4083@l.oracle.com> References: <54AE9A2F0200007800052ACF@mail.emea.novell.com> <54AEB9F90200007800052C8A@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: George Dunlap Cc: Kevin Tian , "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "ian.jackson@eu.citrix.com" , "tim@xen.org" , "xen-devel@lists.xen.org" , Jan Beulich , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org On Thu, Jan 08, 2015 at 06:02:04PM +0000, George Dunlap wrote: > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote: > >>>> On 08.01.15 at 16:59, wrote: > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote: > >>>> the 1st invocation of this interface will save all reported reserved > >>>> regions under domain structure, and later invocation (e.g. from > >>>> hvmloader) gets saved content. > >>> > >>> Why would the reserved regions need attaching to the domain > >>> structure? The combination of (to be) assigned devices and > >>> global RMRR list always allow reproducing the intended set of > >>> regions without any extra storage. > >> > >> So when you say "(to be) assigned devices", you mean any device which > >> is currently assigned, *or may be assigned at some point in the > >> future*? > > > > Yes. > > > >> Do you think the extra storage for "this VM might possibly be assigned > >> this device at some point" wouldn't really be that much bigger than > >> "this VM might possibly map this RMRR at some point in the future"? > > > > Since listing devices without RMRR association would be pointless, > > I think a list of devices would require less storage. But see below. > > > >> It seems a lot cleaner to me to have the toolstack tell Xen what > >> ranges are reserved for RMRR per VM, and then have Xen check again > >> when assigning a device to make sure that the RMRRs have already been > >> reserved. > > > > With an extra level of what can be got wrong by the admin. > > However, I now realize that doing it this way would allow > > specifying regions not associated with any device on the host > > the guest boots on, but associated with one on a host the guest > > may later migrate to. > > I did say the toolstack, not the admin. :-) > > At the xl level, I envisioned a single boolean that would say, "Make > my memory layout resemble the host system" -- so the MMIO hole would > be the same size, and all the RMRRs would be reserved. Like the e820_host=1 ? :-) > > But xapi, for instance, has a concept of "hardware pools" containing > individual hardware devices, which can be assigned to VMs. You could > imagine a toolstack like xapi keeping track of all devices which > *might be* assigned to a guest, and supplying Xen with the RMRRs. As > you say, then this could include hardware across a pool of hosts, with > the RMRRs of any device in the system reserved. > > Alternately, could the toolstack could be responsible for making sure > that nobody uses such a range; and then Xen when a device is assigned, > Xen can check to make sure that the gpfn space is empty before adding > the RMRRs? That might be the most flexible. > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel