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

[Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>]

On Tue, Jan 27, 2015 at 06:41:39AM +0000, Tian, Kevin wrote:
> > From: Elena Ufimtseva [mailto:elena.ufimtseva@xxxxxxxxxx]
> > Sent: Tuesday, January 27, 2015 1:31 AM
> > 
> > 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.
> 
> yes the proposal RMRR change would allow an user to specify arbitrary 
> regions which should cover such bogus platform.

Is dom0 rmrr-like region override option is in rmrr design proposal? I
saw you briefly mentioned this.

> 
> > >
> > 
> > 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.
> > Why can be this a platform quirk?
> > 
> 
> I don't see why you want permission overloading here. Unless there's a clear
> description from vendor about the exact behavior, we even don't know how
> to describe this quirk since it's only based on your experiments (who knows
> whether the controller may use R or RW in different situations) :-)

Its going to be hard to describe override option too )

> Thanks
> Kevin

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