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

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Monday, January 19, 2015 9:52 PM
> 
> >>> On 19.01.15 at 13:23, <tim@xxxxxxx> wrote:
> > At 11:41 +0000 on 19 Jan (1421664109), Jan Beulich wrote:
> >> >>> On 19.01.15 at 12:33, <tim@xxxxxxx> wrote:
> >> > FWIW, I don't like adding hypervisor state (and even more so
> >> > hypervisor mechanism like a new hypercall) for things that the
> >> > hypervisor doesn't need to know about.  Since the e820 is only shared
> >> > between the tools and the guest, I'd prefer it to go in either
> >> > the hvm_info_table or xenstore.
> >>
> >> But we have the guest E820 in the hypervisor already, which we
> >> also can't drop (as XENMEM_memory_map is a generally accessible
> >> hypercall).
> >
> > So we do. :(  What is the difference between that (with appropriate
> > reserved regions in the map) and the proposed new hypercall?
> 
> 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. 

Thanks
Kevin

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