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. In U mode, WFI is useful only in connection
with support for user-level interrupts provided by the may-never-be-
standardized N extension.

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?

The only thing I can think of is when the guest is a nested
hypervisor. But I'm not sure that specifically focusing on optimizing
WFI for a nested hypervisor is really on the agenda. Why not make many
other improvements in support of nested hypervisors, besides this one
thing? We intend eventually to propose a whole package of optional
added support for nested hypervisors. But outside of that add-on
extension, nested hypervisors aren't catered to beyond a bare-bones
level of support.

- John Hauser