Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

[Alistair Francis]

On Tue, Mar 15, 2022 at 10:51 PM Ralf Ramsauer
<ralf.ramsauer@oth-regensburg.de> wrote:
>
>
>
> On 15/03/2022 13:42, Peter Maydell wrote:
> > On Tue, 15 Mar 2022 at 12:29, Ralf Ramsauer
> > <ralf.ramsauer@oth-regensburg.de> wrote:
> >> I have no kernel specified in the guest, so I'd then expect to boot into
> >> an completely empty machine (besides the tiny startup stub in the MROM).
> >> However, I still get the exact same error as mentioned in my initial mail.
> >>
> >> Again, without "-enable-kvm", everything works as expected (i.e., I
> >> don't see any output, because there's basically no guest code to execute).
> >
> > Well, you'll always be trying to execute something, even if it's
> > all-zeroes. I dunno what RISC-V does with its encodings, but you
> > typically either end up in an infinite loop of taking exceptions
> > (if all-0s isn't a valid instruction) or else you just execute
> > through all of guest RAM (if it is something similar to a no-op).
> > In the latter scenario it's quite plausible that the guest ends
> > up doing something KVM doesn't expect, such as trying to execute
> > from an area of the address space where there is no RAM, or a device.
> > If so, "return failure from VCPU_RUN and QEMU aborts" is what I
> > think I would expect to see.
> >
> > If I were you I would try it with some actual guest code loaded
> > at a location where there is RAM...
>
> I guess you are right, and I think, together with the other mail, I now
> understand why I experienced a failure:
>
> As Anup explained, there is no M-Mode, but I passed an OpenSBI BIOS. The
> initial MROM handed over to OpenSBI (located at RAM base 0x80000000). At
> some point, OpenSBI threw an exception (maybe it accessed an CSR it is
> not allowed to, whatever), because it is in S-Mode. Exception vectors
> were not (yet) installed, but initialized with 0x0.

Hmm... This seems like a bug. We shouldn't allow the user to specify a
`-bios` option if using KVM. Would you mind preparing a patch to catch
this?

Alistair

>
> This is how I ended up with the PC at 0x0. Behind 0x0, there's no
> physical backing, and KVM threw an Instruction Guest PF (SCAUSE=0x14).
>
> Didn't verify this, but this somehow sounds plausible to me.
>
> Thanks!
>    Ralf
>
> >
> > -- PMM