Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 08/12/17 08:03, Tim Deegan wrote:
> Hi,
Hi Tim,

Somehow your e-mail was marked as spam by gmail.

> 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.
I am not aware of any way on Arm to misconfigure an entry. We do have 
valid and access bits, although they will affect the IOMMU as well. So 
it will not be possible to get page-table sharing with this "feature" 
enabled.
At the moment, I am thinking to provide a per-guest option to turn 
on/off the possibility to use the valid/access bit. That will be at the 
expense to do a full invalidate on S/W.
> 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.
I am fully aware about it :). This was actually mentioned in my first 
e-mail.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel