From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: (v2) Design proposal for RMRR fix Date: Mon, 12 Jan 2015 12:12:50 +0000 Message-ID: <1421064770.26317.19.camel@citrix.com> References: <54AE9A2F0200007800052ACF@mail.emea.novell.com> <54AEB9F90200007800052C8A@mail.emea.novell.com> <20150109202734.GF4083@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150109202734.GF4083@l.oracle.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: Konrad Rzeszutek Wilk Cc: Kevin Tian , "wei.liu2@citrix.com" , "stefano.stabellini@eu.citrix.com" , George Dunlap , "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 Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote: > 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 ? :-) I'd been thinking about that all the way down this thread ;-) It seems like a fairly reasonable approach, and the interfaces (e.g. get host memory e820) are mostly already there. But maybe there are HVM specific reasons why its not... Ian.