Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.01.15 at 17:34, <elena.ufimtseva@xxxxxxxxxx> wrote:
> On Tue, Jan 27, 2015 at 08:24:36AM +0000, Jan Beulich wrote:
>> >>> On 26.01.15 at 18:30, <elena.ufimtseva@xxxxxxxxxx> wrote:
>> > On Mon, Jan 26, 2015 at 05:06:12PM +0000, Jan Beulich wrote:
>> >> >>> On 26.01.15 at 17:57, <elena.ufimtseva@xxxxxxxxxx> wrote:
>> >> > On Fri, Jan 23, 2015 at 10:50:23AM +0000, Jan Beulich wrote:
>> >> >> >>> On 22.01.15 at 18:34, <elena.ufimtseva@xxxxxxxxxx> wrote:
>> >> >> > (XEN)  00000000d56f0000 - 00000000d5fff000 (reserved)
>> >> >> 
>> >> >> So this is where one of the RMRRs sits in (and also where
>> >> >> the faults occur according to the two numbers you sent
>> >> >> earlier, which - as others have already said - is an indication
>> >> >> of the reported RMRRs being incomplete), ...
>> >> >> 
>> >> >> > (XEN)  00000000d5fff000 - 00000000d6000000 (usable)
>> >> >> > (XEN)  00000000d7000000 - 00000000df200000 (reserved)
>> >> >> 
>> >> >> ... and this is the exact range of the other one. But the usable
>> >> >> entry between them is a sign of the firmware not doing the
>> >> >> best job in assigning resources.
>> >> >> 
>> >> >> I don't, btw, think that blindly mapping all the reserved regions
>> >> >> into PVH Dom0's P2M would be (or is, if that's what's happening
>> >> >> today) correct - these regions are named reserved for a
>> >> >> reason. In the case here it's actually RAM, not MMIO, and
>> >> >> Dom0 (as well as Xen) has no business accessing these (for others
>> >> >> this may be different, e.g. the LAPIC and IO-APIC ones below,
>> >> >> but Xen learns/knows of them by means different from looking
>> >> >> at the memory map).
>> >> > 
>> >> > I understand this this. At the same time I think pv dom0 does exactly
>> >> > this blind mapping. I also tried to map these regions as read-only and
>> >> > that worked. Can be this an option for these ram regions?
>> >> 
>> >> No - they're reserved, so there shouldn't be _any_ access to them.
>> >> The only possible workaround I see as acceptable would be the
>> >> already proposed addition of a command line option allowing to
>> >> specify additional RMRR-like regions.
>> >> 
>> > 
>> > Understood. And I am guessing the permissions overloading option should
>> > be available as well? For example, RW or R only. RMRRs are always mapped 
>> > with RW.
>> 
>> That's an option, but not a requirement imo.
>> 
>> > Why can be this a platform quirk?
>> 
>> Did you mean "can't"? If not, I don't understand the question. If so,
>> remember that we're talking about RAM allocated by the firmware
>> for special purposes. Hence such a quirk would need tailoring to any
>> particular published firmware version, and would need to take into
>> account any differences in the memory use that may result from
>> setting firmware options differently (and assuming that the memory
>> use is deterministic across boots when the options don't change -
>> I've seen systems where memory use differed between warm and
>> cold boots). IOW, not something that's likely to be practical.
> 
> What about pv dom0 case? pv dom0 maps these reserved memory ranges with
> RW access rights. Should be this unified in some way?

I'm again having some difficulty relating the question to the context
given. But anyway - where do you see Dom0 getting reserved
memory regions mapped RW unconditionally? The fact that
iommu_inclusive_mapping=1 by default is to cover firmware bugs
afaik. I could see us altering this at some point to only behave that
way on older systems. But that's a decision mainly to be made by
the VT-d maintainers.

Jan


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