From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: (v2) Design proposal for RMRR fix Date: Tue, 20 Jan 2015 10:48:41 +0000 Message-ID: <54BE40990200007800056E99@mail.emea.novell.com> References: <54B68FA10200007800054F01@mail.emea.novell.com> <54B6B578.60106@eu.citrix.com> <54B78A5A02000078000552C2@mail.emea.novell.com> <54BCDD53020000780005645A@mail.emea.novell.com> <20150119113359.GB17236@deinos.phlegethon.org> <54BCFB8D0200007800056684@mail.emea.novell.com> <20150119122334.GD17236@deinos.phlegethon.org> <54BD1A1802000078000567E7@mail.emea.novell.com> <54BE11D20200007800056C73@mail.emea.novell.com> <54BE29A30200007800056D31@mail.emea.novell.com> <1421750332.10440.208.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1421750332.10440.208.camel@citrix.com> Content-Disposition: inline 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 Cc: Kevin Tian , "wei.liu2@citrix.com" , "stefano.stabellini@eu.citrix.com" , George Dunlap , Tim Deegan , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Yang Z Zhang , TiejunChen List-Id: xen-devel@lists.xenproject.org >>> On 20.01.15 at 11:38, wrote: > On Tue, 2015-01-20 at 09:10 +0000, Jan Beulich wrote: >> >>> On 20.01.15 at 09:59, wrote: >> >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >> Sent: Tuesday, January 20, 2015 3:29 PM >> >> >> >> >>> On 20.01.15 at 01:45, wrote: >> >> >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >> >> The proposed new hypercall represents _only_ reserved regions. >> >> >> But it was said several times that making the existing one work >> >> >> for HVM (and then fit the purposes here) is at least an option >> >> >> worth investigating. >> >> > >> >> > I did consider this option but there's a reason which makes it not >> >> > suitable. Based on current discussion, we need provide per-region >> >> > override (force/try) to the caller e.g. hvmloader here, while >> >> > XENMEM_memory_map only provides plain e820 information, and >> >> > extending it w/ such override for general e820 entry looks a bit >> >> > weird. >> >> >> >> I don't see why - the returned table only resembles an E820 one, >> >> i.e. I can't see why we couldn't steal a flag bit from e.g. the type >> >> field, or define a maybe-reserved type. >> > >> > Originally I was not sure whether any caller assumption is made on >> > an exactly-mimicked e820 behavior. so looks not a problem here >> > from your thought. > > hvmloader could update the table to convert any magic entries into > standard ones, such that by the time any guest software sees it it would > look like a normal e820. > > In fact it would have to do that for the version it passes on to the > guest via SeaBIOS (i.e. the thing which would become the actual e820), > maybe it's an open question what the guest would see if it chose to use > the hypercall directly. Yeah, for the actual E820 the conversion of course has to happen. But I think there's no strong need for it to be done on the variant obtainable via hypercall - it would only destroy information, and who knows what having that piece of information available may be good for in the future. Jan