Re: [PATCH RFCv2 9/9] arm64: Support async page fault

From: Marc Zyngier
Date: Thu May 28 2020 - 03:03:35 EST


On 2020-05-28 07:14, Gavin Shan wrote:
Hi Paolo,

On 5/27/20 4:48 PM, Paolo Bonzini wrote:
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:

- the page ready signal can be done as an interrupt, rather than an
exception. This is because "page ready" can be handled asynchronously,
in contrast to "page not present" which must be done on the same
instruction that triggers it. You can refer to the recent series from
Vitaly Kuznetsov that switched "page ready" to an interrupt.


Yeah, page ready can be handled asynchronously. I think it would be
nice for x86/arm64 to share same design. x86 has 256 vectors and it
seems 0xec is picked for the purpose. However, arm64 doesn't have so
many (interrupt/exception) vectors and PPI might be appropriate for
the purpose if I'm correct, because it has same INTD for all CPUs.
From this point, it's similar to x86's vector. There are 16 PPIs, which
are in range of 16 to 31, and we might reserve one for this. According
to GICv3/v4 spec, 22 - 30 have been assigned.

The assignment of the PPIs is completely implementation defined,
and is not part of the architecture (and certainly not in the
GICv3/v4 spec). SBSA makes some statements as to the way they *could*
be assigned, but that's in no way enforced. This allocation is entirely
controlled by userspace, which would need to configure tell KVM
which PPI to use on a per-VM basis.

You would then need to describe the PPI assignment through firmware
(both DT and ACPI) so that the guest kernel can know what PPI the
hypervisor would be signalling on.

It is also not very future proof should we move to a different
interrupt architecture.


- the page not present is reusing the memory abort exception, and
there's really no reason to do so. I think it would be best if ARM
could reserve one ESR exception code for the hypervisor. Mark, any
ideas how to proceed here?


Well, a subclass of ESR exception code, whose DFSC (Data Fault Status
Code) is 0x34, was taken for the purpose in RFCv1. The code is IMPDEF
one and Mark suggested not to do so. I agree the page not present needs a
separately subclass of exception. With that, there will be less conflicts
and complexity. However, the question is which subclass or DFSC code I should
used for the purpose.

The current state of the architecture doesn't seem to leave much leeway in
terms of SW creativity here. You just can't allocate your own ISS encoding
without risking a clash with future revisions of the architecture.
It isn't even clear whether the value you put would stick in ESR_EL1
if it isn't a valid value for this CPU (see the definition of 'Reserved'
in the ARM ARM).

Allocating such a syndrome would require from ARM:

- the guarantee that no existing implementation, irrespective of the
implementer, can cope with the ISS encoding of your choice,

- the written promise in the architecture that some EC/ISS values
are reserved for SW, and that promise to apply retrospectively.

This is somewhat unlikely to happen.

M.
--
Jazz is not dead. It just smells funny...