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 09:10:43 +0000 Message-ID: <54BE29A30200007800056D31@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Kevin Tian Cc: "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , George Dunlap , Tim Deegan , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org >>> 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. The main aspect being that there is no existing caller in the HVM world, since at least one of [gs]et is currently getting explicitly refused for HVM guests. And PVH is still experimental... Jan