On Tue, Jul 30, 2019 at 5:03 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 30/07/19 07:26, Anup Patel wrote: > > Here's a brief TODO list which we want to immediately work upon after this > > series: > > 1. Handle trap from unpriv access in SBI v0.1 emulation > > 2. In-kernel PLIC emulation > > 3. SBI v0.2 emulation in-kernel > > 4. SBI v0.2 hart hotplug emulation in-kernel > > 5. ..... and so on ..... > > > > We will include above TODO list in v2 series cover letter as well. > > I guess I gave you a bunch of extra items in today's more thorough > review. :) Thanks, your review comments are very useful. We will address all of them. > > BTW, since IPIs are handled in the SBI I wouldn't bother with in-kernel > PLIC emulation unless you can demonstrate performance improvements (for > example due to irqfd). In fact, it may be more interesting to add I thought VHOST requires irqfd and we would certainly endup providing in-kernel PLIC emulation to support VHOST. > plumbing for userspace handling of selected SBI calls (in addition to > get/putchar, sbi_system_reset and sbi_hart_down look like good > candidates in SBI v0.2). The get/putchar SBI v0.1 calls won't be encouraged going forward because we already have earlycon implmentation in-place and Guest kernel can directly write to UART registers for earlyprints. If we still wanted to implement get/putchar calls then we would need a RISC-V specific exit reason in KVM. We have tried to avoid RISC-V specific IOCTLs or exit reason in this series. > > > We were thinking to keep KVM RISC-V disabled by default (i.e. keep it > > experimental) until we have validated it on some FPGA or real HW. For now, > > users can explicitly enable it and play-around on QEMU emulation. I hope > > this is fine with most people ? > > That's certainly okay with me. > Thanks, Anup
