[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions
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, Yes, that is "can't". > 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. I see, thanks for explanation. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |