From: Alistair Francis <alistair23@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Anup Patel <apatel@ventanamicro.com>,
Anup Patel <anup@brainfault.org>,
Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Jiangyifei <jiangyifei@huawei.com>,
Stefan Huber <stefan.huber@oth-regensburg.de>
Subject: Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension
Date: Mon, 21 Mar 2022 15:43:07 +1000 [thread overview]
Message-ID: <CAKmqyKMGJR8M6MkL5Cer81qbCce0XmdcS8pQEkmH6X9h0SutmQ@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8mqdAf58FkxDPtL_UK2feGTEUE+h--_a8pRpSsGUCHYw@mail.gmail.com>
On Thu, Mar 17, 2022 at 7:46 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 16 Mar 2022 at 22:23, Alistair Francis <alistair23@gmail.com> wrote:
> > 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?
>
> You don't want to allow the possibility of a bios blob that expects
> to run in S-mode, the way arm virt can run an EL1 UEFI BIOS ?
Interesting. We could still allow that by using -device loader though.
If we load something in S mode it really is a kernel and not firmware,
so I think the -bios argument is a little misleading. We could make
-bios and -enable-kvm a warning instead, to discourage users from
providing OpenSBI, but still allow them to pass something.
To me not allowing it seems reasonable, and we can always re-allow it
in the future if there is a good use case.
Alistair
>
> thanks
> -- PMM
next prev parent reply other threads:[~2022-03-21 5:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 2:12 QEMU+KVM on RISC-V + Hypervisor Extension Ralf Ramsauer
2022-03-15 6:48 ` Alistair Francis
2022-03-15 8:33 ` Anup Patel
2022-03-15 12:17 ` [EXT] " Ralf Ramsauer
2022-03-15 12:25 ` Anup Patel
2022-03-15 12:44 ` Ralf Ramsauer
2022-03-15 12:42 ` Peter Maydell
2022-03-15 12:51 ` Ralf Ramsauer
2022-03-16 22:23 ` Alistair Francis
2022-03-17 9:45 ` Peter Maydell
2022-03-19 12:24 ` Ralf Ramsauer
2022-03-21 5:43 ` Alistair Francis [this message]
2022-03-21 20:47 ` Palmer Dabbelt
2022-03-23 17:05 ` Ralf Ramsauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKMGJR8M6MkL5Cer81qbCce0XmdcS8pQEkmH6X9h0SutmQ@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=jiangyifei@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=ralf.ramsauer@oth-regensburg.de \
--cc=stefan.huber@oth-regensburg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).