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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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