[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
Hi, At 12:58 +0000 on 06 Dec (1512565090), Julien Grall wrote: > On 12/06/2017 12:28 PM, George Dunlap wrote: > > 2. It sounds like rather than using PoD, you could use the > > "misconfigured p2m table" technique that x86 uses: set bits in the p2m > > entry which cause a specific kind of HAP fault when accessed. The fault > > handler then looks in the p2m entry, and if it finds an otherwise valid > > entry, it just fixes the "misconfigured" bits and continues. > > I thought about this. But when do you set the entry to misconfigured? > > If you take the example of Linux 32-bit. There are a couple of full > cache clean during the boot of uni-processor. So you would need to go > through the p2m multiple time and reset the access bits. My 2c (echoing what some others have already said): +1 for avoiding the full majesty of PoD if you don't need it. It should be possible to do something like the misconfigured-entry bit trick by _allocating_ the memory up-front and building the p2m entries but only making them usable by the {IO}MMUs on first access. That would make these early p2m walks shorter (because they can skip whole subtrees that aren't marked present yet) without making major changes to domain build or introducing run-time failures. Also beware of DoS conditions -- a guest that touches all its memory and then flushes by set/way mustn't be allowed to hurt the rest of the system. That probably means the set/way flush has to be preemptable. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |