On Wed, May 25, 2022 at 1:56 AM Andrea Bolognani <abolo...@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 <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.
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 >
