qemu-riscv
[Top][All Lists]
Advanced

[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: Tue, 17 May 2022 15:03:38 +1000

On Sat, May 7, 2022 at 6:30 AM Atish Kumar Patra <atishp@rivosinc.com> wrote:
>
> On Fri, May 6, 2022 at 4:00 AM Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Fri, 6 May 2022 at 09:18, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Fri, May 06, 2022 at 06:34:47AM +1000, Alistair Francis wrote:
> > > > Even if we didn't worry about backwards compatibility the current virt
> > > > machine would still be what most users want. It's just a small number
> > > > of users who don't want MMIO devices and instead want to use PCIe for
> > > > everything. Realistically it's only HPC users who would want this type
> > > > of machine, at least that's my understanding.
> > >
> > > I'm not so sure about that. Every other architecture has ended up
> > > standardizing on PCI for general purpose virtual machines. IIRC,
> > > aarch64 started off with MMIO, but switched to PCI as it matured.
> > >
> > > In terms of having VM mgmt tools "just work" for risc-v, I think
> > > it will be very compelling for the general 'virt' machine to be
> > > PCI based, otherwise all the assumptions about PCI in mgmt apps
> > > are going to break requiring never ending riscv fixes.
> >
> > Mmm, my experience with aarch64 virt is that PCI is much nicer
> > as a general preference. aarch64 virt has some MMIO devices
> > for historical reasons and some because you can't reasonably
> > do the necessary things with PCI, but I'm actively trying to
> > push people who submit new MMIO device features for virt to
> > try to use a PCI-based solution instead if they possibly can.

Interesting...

Ok, maybe calling this "virt-pcie" might be a good start, with the
expectation to eventually replace the current virt with the new
virt-pcie at some point.

The other option would be to try and gradually change from the current
virt machine to this new virt machine

Alistair

> >
>
> Yeah. That was one of the primary goals of this series. If we have an
> alternate PCI only machine,
> folks will be more motivated to add only PCI based solutions in the
> future. In that case, there will be minimal
> or no change required to the machine code itself.
>
> Just for clarification: We can achieve the same with the current virt
> machine. But it is already bloated with a bunch of MMIO devices
> and will probably continue to do so because of its flexibility. In
> addition to that, any real PCI based platform emulation can not reuse
> the virt machine code which will result in more vendor specific
> implementations in the future..
>
> > thanks
> > -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]