Re: (v2) Design proposal for RMRR fix

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2015-01-20 at 09:10 +0000, Jan Beulich wrote:
> >>> On 20.01.15 at 09:59, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Tuesday, January 20, 2015 3:29 PM
> >> 
> >> >>> On 20.01.15 at 01:45, <kevin.tian@intel.com> 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.

> 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...

Indeed.

Ian.