[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: Monday, January 19, 2015 5:33 PM
> >>> On 18.01.15 at 09:58, <kevin.tian@xxxxxxxxx> 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?

definitely it's not wrong. I meant to include this option but looks it got
missed when sending the mail. Using hypercall is similarly to use xenstore 
(just matter where to centrally save the information). Originally I thought
people may think user space option is more flexible. But now since
using xenstore has dependency problem, let's go with this hypercall option.

so in a summary two new hypercalls will be added: one general to allow
libxl query per-device RMRR, and then the other domain specific to allow 
libxl specifying reserved regions.


Xen-devel mailing list



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