-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On
Behalf Of John Hauser
Sent: 28 May 2021 23:41
To: tech-privileged@...
Cc: Paolo Bonzini <pbonzini@...>
Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration

Paolo Bonzini wrote:

If the answer to any of the above three questions is no, what can be
done to avoid the frankly ludicrous delay in the approval of a
specification that has seen no significant change in one year?

There is at least one small but significant change to the hypervisor extension
being discussed, to redefine the "G" bit in G-stage address translation PTEs to
indicate that a page of guest physical address space is "virtual I/O", meaning
the hardware must order VM accesses to those addresses as though they
were I/O accesses, not main memory.

From hypervisor perspective, the "G" bit in G-stage PTEs is not used at all.

For software emulated MMIO, the hypervisor does not create any mapping
in the G-stage to ensure that it always traps which allows hypervisor to
trap-n-emulate it.

For pass-through MMIO (such as IMSIC guest MSI files directly accessed
by Guest), the guest physical address translates to host physical address
of actual MMIO device in the G-stage and we will have host PMAs which
will mark all MMIO devices as IO regions.

At this point, the G bit in the G-stage PTE is unused from software
perspective. Why do we need to re-purpose G-bit because we already
have PMAs marking all MMIO addresses as I/O region ?

Another minor change planned is to have attempts to write a strictly read-
only CSR always raise an illegal instruction exception, instead of sometimes
raising a virtual instruction exception as currently specified.

The reason there has been no movement on the hypervisor extension for
several months is not because there is totally nothing to do, but because I've
lacked the time to attend to it simultaneously with a thousand other things.

If you'd like more progress on the hypervisor extension, feel free to drive the
discussion to get agreement one way or another on the first point, the "I/O"
bit in G-stage PTEs. The issue concerns when a hypervisor is emulating a
device that has memory that is supposed to be in I/O space but is actually
being emulated using main memory. A guest OS expects accesses to that
virtual device memory to be in I/O space and ordered according to the I/O
rules, but that's not currently what happens.

- John Hauser

Regards,
Anup