On Mon, May 23, 2022 at 08:16:40PM -0700, Atish Patra wrote: > On Sun, May 22, 2022 at 10:59 PM Alistair Francis <alistai...@gmail.com> > wrote: > > On Wed, May 18, 2022 at 4:38 PM Atish Patra <ati...@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. 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
