On 06/05/20 18:56, John Hauser wrote:

Paolo Bonzini wrote:

On 05/05/20 23:15, John Hauser wrote:

- attempts to execute WFI, unless the instruction completes within an
implementation-specific, bounded time;

It would be great to have this controlled by a bit in the hstatus CSR.
For example a hypervisor that does not overcommit CPUs will probably
want to delegate WFI to the guest. Guest-delegated interrupts then
would not incur the overhead of world switching, while host-handled
interrupts would exit to the hypervisor anyway.

I'm afraid this makes no sense to me. Ordinary user-mode applications
don't execute WFI.

But this would be a VS-mode application, not an ordinary user-mode
application. I'm not sure why U-mode matters. Anyway...

And if a guest OS itself executes WFI, I find it hard to believe it
expects the WFI to trap as an illegal instruction, much less that it
has a performance-sensitive response coded in its illegal instruction
trap handler.

So I don't understand "delegate WFI to the guest". What's the scenario
where a guest OS expects WFI to trap?

... I guess this is the misunderstanding. I'm not proposing to delegate
the WFI trap to the guest, but rather *the WFI instruction*: HS-mode
could optionally let WFI run in VS-mode, even if it wouldn't complete
within a bounded time. This is because, if you don't overcommit CPUs,
there's no advantage in getting out of VS-mode and doing the wait for
interrupts in HS-mode.

When an interrupt arrives, it would either be delivered to VS-mode or
cause an HS-mode trap, depending on the contents of hideleg.

Nested virtualization does not matter.

Is this clearer?

Paolo