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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 12/06/2017 03:15 PM, Jan Beulich wrote:
> > > > On 06.12.17 at 13:58, <julien.grall@xxxxxxxxxx> 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?
> What we do in x86 is that we flag all entries at the top level as
> misconfigured at any time where otherwise we would have to
> walk the full tree. Upon access, the misconfigured flag is being
> propagated down the page table hierarchy, with only the
> intermediate and leaf entries needed for the current access
> becoming properly configured again. In your case, as long as
> only a limited set of leaf entries are being touched before any
> S/W emulation is needed, you'd be able to skip all misconfigured
> entries in your traversal, just like with PoD you'd skip
> unpopulated ones.
Oh, what you call "misconfigured bits" would be clearing the valid bit 
of an entry on Arm. The entry would be considered invalid, but it is 
still possible to store informations (the rest of the bits are ignored 
by the hardware).
But I think this is bringing another class of problem. When a 
misconfigured is accessed, we would need to clean & invalidate the cache 
for that region.
At the moment, Xen only supports 4KB page granularity. So the region 
would be either 4KB, 2MB or 1GB. Flushing 2MB and 1GB region will take 
time because you can only clean & flush a line at the time. From the 
Arm, cacheline size can range from 16 bytes to 2048 bytes. This means we 
may want to preempt even in the middle of region to avoid blocking Xen 
for too long.
I think we need to clean & invalidate the region at least in the 
following places:
        1) The guest is read/writing a region
        2) Xen is accessing the region because of an hypercall

I will leave 1) aside as I think it is clear for everyone the reason of 
the clear & invalidate as long as how to preempt.
For 2), if we access a "misconfigured page" we would need to clean to 
avoid stall data. I think in that case, preemption would be difficult. 
Indeed we would need to modify all the hypercall to report back the 
preemption and restart again.
On a side node, soon we will need to support 64KB page granularity 
because this is the only way to handle 52-bit PA on Arm. In that case, 
region would be 64KB, 512MB, 4TB. Whether we will support 4TB is not 
decided, but I think 512MB should be.
Cheers,

--
Julien Grall

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