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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.02.15 at 19:06, <konrad.wilk@xxxxxxxxxx> wrote:
> 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).

I don't see why hand-specified regions should be treated any
different from what ACPI tells us: After all the sole purpose is to
work around the firmware not properly specifying these regions
in the first place.

Jan


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