Re: [Xen-devel] [PATCH RFC 4/5] pvh: dom0 add rw mapping for dom0_iommu_rwmem boot opt

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Feb 18, 2015 at 07:55:16AM +0000, Jan Beulich wrote:
> >>> On 17.02.15 at 19:25, <elena.ufimtseva@xxxxxxxxxx> wrote:
> > On Tue, Feb 17, 2015 at 12:33:12PM +0000, Jan Beulich wrote:
> >> For all further changes done here, I'd really like to first understand
> >> why you don't simply add extra RMRRs based on the command line
> >> option introduced in the next patch, as that would appear to make
> >> most of what you do here unnecessary.
> > 
> > I discussed it with Konrad and it was an option, but I used that
> > approach. Now looks like everyone is agree with adding extra RMRRs
> > derived from command-line to existing list of RMRRs, I will post next
> > version and will do it this way.
> > I am not sure though if there is need to distinguish between these extra 
> > RMRRs regions and the ones derived from ACPI.
> 
> Did anyone suggest you'd need to make a distinction?

Yes me. We were thinking in terms of the blacklist of RMRR regions to a guest
that Intel is looking at. And that these command-driven blacklist needn't
be blacklisted in the guest RMRR region.. The theory was that:
 1). The system admin might just want the real RMRR regions blacklisted.
 2). The other regions that are blacklisted could be blacklisted or not
     depending on the desires of the system admin. As in, we would want the
     system admin to make this choice and by defualt blacklist it. That
     would require either keeping those two RMRR regions in two seperate
     buckets or perhaps have the RMRR list have an extra bit (cmd_line:yes).

But all of that is a bit of hand-waving because the RMRR patches aren't
yet ready and we thought it might be just easier to address this once
those patches are in (or being posted as non-RFC).

Um, but if this comes up - then the code can be redone to address it when
the RMRR patches are ready.

> 
> Jan
> 

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