[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V
From: |
Alistair Francis |
Subject: |
Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V |
Date: |
Wed, 1 Jun 2022 12:01:56 +1000 |
On Wed, May 25, 2022 at 1:56 AM Andrea Bolognani <abologna@redhat.com> wrote:
>
> On Mon, May 23, 2022 at 08:16:40PM -0700, Atish Patra wrote:
> > On Sun, May 22, 2022 at 10:59 PM Alistair Francis <alistair23@gmail.com>
> > wrote:
> > > On Wed, May 18, 2022 at 4:38 PM Atish Patra <atishp@atishpatra.org> wrote:
> > > > 1. virt machine is not well documented and already bloated. There is
> > > > no specification for virt machine as such.
> > > > Putting restrictions after a certain release will lead to confusion.
> > > > 2. Do we support existing MMIO devices after that specific version or
> > > > not ?
> > >
> > > Yeah, so I guess this doesn't achieve the same outcome you want. I
> > > would say we would still include some MMIO devices, like UART for
> > > example.
> >
> > Why ? We can just rely on the pcie based uart (virtio-serial-pci or
> > serial-pci) should be enough.
> > The only MMIO devices that should be allowed are the ones that can't
> > be behind pcie.
>
> IIRC virtio-serial is initialized too late to catch messages produced
> very early by the firmware (and possibly the kernel), which means
> it's okay for regular usage but not when trying to debug an entire
> class of boot issues.
Agreed. OpenSBI doesn't even support PCIe so we need an MMIO UART for
OpenSBI to be able to print messages
Alistair
>
> Either way, it looks like you wouldn't be able to completely get rid
> of MMIO even if you introduced a new virt-pcie machine type. That's
> the same for the aarch64 virt machine. I agree with Dan that we
> should follow the example set by that architecture - it has worked
> out pretty well.
>
> If there is a desire to reduce the complexity of the "standard"
> machine type, can we just take the current virt machine type and
> rename it to something else? And have your simpler code take over the
> virt name? Sure, it will cause some pain in the short term, but the
> RISC-V ecosystem is still young enough for it to not be a deal
> breaker.
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, (continued)
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Alistair Francis, 2022/05/17
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Daniel P . Berrangé, 2022/05/17
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Alistair Francis, 2022/05/17
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Atish Patra, 2022/05/18
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Daniel P . Berrangé, 2022/05/18
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Peter Maydell, 2022/05/18
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Atish Kumar Patra, 2022/05/19
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Alistair Francis, 2022/05/23
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Atish Patra, 2022/05/23
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Andrea Bolognani, 2022/05/24
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V,
Alistair Francis <=
- Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Anup Patel, 2022/05/06
Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V, Atish Kumar Patra, 2022/05/05