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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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


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