Re: H-extension PoC Done requirements - follow-up from RISC-V Hypervisor Sync-up Call


On Tue, 2020-09-29 at 23:01 +0100, SandroPinto@DEI wrote:
Sorry but when you read "Oct 13th" I intended to write "Oct 27th".
Got confused with the dates!

On Tue, Sep 29, 2020 at 10:53 PM SandroPinto@DEI <d5631@...
Hi Greg,

Thank you for sharing your views.

Under the light of what you have written, please let me add:

On #1, we can add Bao as well.

On #2, we can definitely help with the "completed RTL
implementation" since we already have the modified Rocket core with
the H extension running Bao and two VMs (Linux + FreeRTOS) on a
Xilinx ZCU104.
That's awesome. I did not know that you have a working RTL
implementation with H extension.

@ Anup & Atish
If you agree, I would take the opportunity of an upcoming sync-up
call (Oct 13th ?!) to give a small presentation about our PoC and
share our experience through this journey.
Absolutely. I have added your talk to the agenda for upcoming meeting
on 27th october.

Our goal is to get feedback and understand the best way to share
with all of you what we have done.
We are more than happy to make the RTL available so that we can
enable any member to run their own experiences and setups.
Eventually we could get KVM and Xvisor up and running in the
"completed RTL implementation", and get #2 (and the overall goal)
sooner than expected.
Yes. It would be very helpful. Few other university researchers i.e.
Ariane & Shakti guys are also trying to implement H-extension to their
core. If you can opensource the RTL, it would help them as well.


On Tue, Sep 29, 2020 at 5:54 PM Greg Favor <gfavor@...
Following up from this morning's RISC-V Hypervisor Sync-up Call,
one key remaining issue that gates being able to freeze the H-
extension spec - which gates a lot of things being able to get
into Linux/gcc/etc. - is the Proof of Concept task in the
official Done Policy.

I believe the goals of this Done task is:

1) Flushing out any functional deficiencies in the extension's
2) Flushing any unexpected complexities for a hardware

On #1 I believe a lot of work has occurred based on running KVM
on QEMU (all based on the latest draft of the H-extension). I
think Xvisor support is also in a similar state (?). Overall, my
impression is that this has reached a point that one can say that
#1 has been satisfied. Anup and Atish, would you agree? (Or
what remains to be done to reach a sufficient level of
+Alistair (Qemu maintainer & H extension developer)

Yes. IIRC, the Qemu supports latest hypervisor spec v0.6.1. I believe
the upstream Qemu supports v0.6 and the patches for v0.6.1 are in the
mailing list as well.

On #2 I suggest that it would be sufficient to have at least one
"real-world" RTL implementation of the H-extension completed.
Requiring that an implementation actually be running KVM on an
FPGA or emulator is a higher bar that doesn't really offer any
further useful feedback on this goal, while practically speaking
pushing spec freeze by a couple of quarters. So I propose that
we agree on "completed RTL implementation" as being the criterion
for the H-extension to satisfy the PoC Done task. Any
disagreements or thoughts otherwise?

Btw, if Anup and Atish are positive on #1 and we agree on what I
proposed for #2, then I think we can be looking at freezing the
spec sooner than later (but very much also subject to Andrew and
John not wanting to keep the spec open a little longer for some
other reason(s)). If I had to speculate, maybe this all nets out
to freezing the spec by the end of the year (tbd). But let's
first settle this PoC issue. Then I can talk with John and
Andrew about the overall path to freeze.



Join to automatically receive all group messages.