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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2015-01-19 at 10:21 +0000, George Dunlap wrote:
> On 01/18/2015 08:58 AM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Thursday, January 15, 2015 7:45 PM
> >>
> >>>
> >>> If above high level flow can be agreed, then we can move forward to
> >>> discuss next level detail e.g. how to pass the rmrr list cross different
> >>> components. :-)
> >>
> >> I think we're definitely ready to move on.  There are a bunch of tiny
> >> details we could discuss, but those are  mostly minor changes that can
> >> be tweaked when the patches are submitted.
> >>
> > 
> > Thanks for all the good discussions in the thread, and good we have 
> > consensus to move forward now.
> > 
> > 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)
> > 
> > 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?)
> 
> I *think* the last time I asked such a question, the answer was that
> allowing the domain builder to access xenstore would introduce a
> cyclical dependency.  But I can't remember the details now (and I may h
> ave it wrong).

IIRC libxenstore depends on libxenctrl, so having libxenctrl depend on
libxenstore would be problematic. (There has been talk recently of
refactoring libxenctrl into multiple more single-minded libraries, which
might help with this so of thing).

I don't think xenstore is particularly the right answer here though,
either hvm_info (or a table referenced from it) or, since Jan doesn't
like that approach, a hypercall as he suggests would work.

Ian.


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