On Mon, May 02, 2022 at 02:19:30PM +0800, Gavin Shan wrote:
On 5/1/22 2:50 PM, Oliver Upton wrote:
On Sun, Apr 03, 2022 at 11:39:06PM +0800, Gavin Shan wrote:
This supports SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall.
They are used by guest to notify the completion of event in its
handler. The previously interrupted or preempted context is restored
like below.
* x0 - x17, PC and PState are restored to what values we had in
the interrupted or preempted context.
* If it's SDEI_EVENT_COMPLETE_AND_RESUME hypercall, IRQ exception
is injected.
I don't think that's how COMPLETE_AND_RESUME works. The caller specifies an
address at which it would like to begin execution within the client
exception level.
SDEI spec suggests this behaves like a synchronous exception. DEN 0054C
5.2.2 'Event Resume Context' speaks more about how it is supposed to
work.
It's actually the linux convention. If the event handler, which was
specified in previous hypercall to EVENT_REGISTER, returns success,
the (linux) client calls into COMPLETE_AND_RESUME and the resume
address is specified with FIQ vector offset. More details can be
found from arch/arm64/kernel::sdei.c::do_sdei_event().
Right -- but look at what its doing. It returns the address at which it
wants to resume execution.
arch/arm64/kernel.entry.S::__sdei_asm_handler winds up passing this as
an argument to COMPLETE_AND_RESUME. Also, what would happen if we run
something that isn't Linux inside of KVM? This is why I suggested
implementing COMPLETE_AND_RESUME in line with the specification, not
based on what the kernel is presently doing.