Re: [Xen-devel] (v2) Design proposal for RMRR fix

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, January 20, 2015 6:49 PM
> 
> >>> On 20.01.15 at 11:38, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Tue, 2015-01-20 at 09:10 +0000, Jan Beulich wrote:
> >> >>> On 20.01.15 at 09:59, <kevin.tian@xxxxxxxxx> wrote:
> >> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> Sent: Tuesday, January 20, 2015 3:29 PM
> >> >>
> >> >> >>> On 20.01.15 at 01:45, <kevin.tian@xxxxxxxxx> wrote:
> >> >> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> >> 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.
> 

If not destroying the new flag, it may break BIOS or OS if they don't know
the new flag. So I'd interpret the life cycle of new flag bit only valid
between hypercall return and constructing actual e820, and it will be
translated into E820_RESERVE in actual e820 if no conflict is detected.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel