On Tue, Mar 15, 2022 at 10:51 PM Ralf Ramsauer <ralf.ramsa...@oth-regensburg.de> wrote: > > > > On 15/03/2022 13:42, Peter Maydell wrote: > > On Tue, 15 Mar 2022 at 12:29, Ralf Ramsauer > > <ralf.ramsa...@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
