[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.