[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 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.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.