Re: (v2) Design proposal for RMRR fix

[Tim Deegan <tim@xen.org>]

At 11:24 +0000 on 19 Jan (1421663081), Tian, Kevin wrote:
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Monday, January 19, 2015 5:33 PM
> > 
> > >>> On 18.01.15 at 09:58, <kevin.tian@intel.com> wrote:
> > > still one open to hear suggestion though, regarding to how we want
> > > to pass the reserved regions to domain builder and hvmloader (for Xen
> > > we will extend related assignment hypercall to include per device override).
> > >
> > > one simple solution is to extend xc_hvm_build_args and hvm_info_table
> > > to include specified regions, with the limitation on defining a fixed
> > > number (possibly use E820_MAX as a reasonable assumption)
> > 
> > As said (in other contexts?) a couple of times recently - I think we
> > should try to avoid altering struct hvm_info_table if at all possible.
> > It should really only be used for information that cannot be passed
> > by any other means between the involved components.
> 
> yes, I should add this note when describing that option. Just want to
> put what's discussed before in the table.
> 
> > 
> > > another option is to place the information in xenstore which is more
> > > flexible. However domain builder doesn't use xenstore right now (suppose
> > > extending use xenstore is not complex?)
> > >
> > > or any other thought to be evaluated?
> > 
> > What's wrong with attaching them to the domain with a domctl, and
> > having a suitable "normal" hypercall (along the lines of
> > XENMEM_reserved_device_memory_map, just that this one would
> > need to be domain specific) for the domain (including hvmloader) to
> > retrieve it?

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.

Cheers,

Tim.