Re: [Qemu-devel] [PATCH v4] hw/arm: Add arm SBSA reference machine

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Mon, 19 Nov 2018 at 08:44, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>
> On Mon, Nov 19, 2018 at 07:51:29AM -0800, Ard Biesheuvel wrote:
> > > > > I think what we *really* want is sysbus-xhci-generic.
> > > > >
> > > > > That'll be a bit more work though as xhci core and xhci pci needs to be
> > > > > splitted, simliar to how it was done for ehci in commit
> > > > > 5010d4dc618b6b8e7c21129c487c06f6493f71fc (and related patches).
> > > > >
> > > > > Or just plug qemu-xhci into a pcie slot.  Not sure which would be closer
> > > > > to physical hardware.
> > > >
> > > > We don't need XHCI especially, EHCI is perfectly fine as well.
> > > >
> > > > This is mostly about ensuring that the emulated hardware spans the
> > > > space of what we encounter on real hardware, and non-PCIE SATA and USB
> > > > controllers is something we see often.
> > > >
> > > > So I could live with MMIO SATA and PCI USB as well, but I'd prefer it
> > > > if we could have both MMIO.
> > >
> > > I would actually strongly prefer non-MMIO.
> > >
> > > What "we see" is generally a result of embedded companies "value
> > > adding" in the usual way when moving from embedded to servers.
> > >
> > > I want the SBSA target to be an idealised machine, not an educational
> > > vehicle for showing how companies have got it wrong.
> > >
> > > Where in doubt, anything software discoverable should win over
> > > non-discoverable.
> >
> > I don't think it makes sense at all to idealize the SBSA machine in
> > this way. For example, there are elaborate provisions in the IORT spec
> > how to describe an I/O topology involving named components (as opposed
> > to PCIe devices), and I have not seen an arm64 SoC yet that uses PCIe
> > internally for on-chip network controllers, nor do I expect to in the
> > near future. So having non-PCIe USB or SATA will permit us to exercise
> > code paths in the OS that we do rely on in production, and will for
> > the foreseeable future.
>
> Fair point.
>
> I have no objections at all to adding _some_ MMIO components for the
> purpose of being able to validate this. But I am reluctant to mandate
> discrepancies in bits that 99% of users would expect to work
> identically as it has done on x86.
>
> If USB isn't auto-instantiated in qemu-system-x86_64, then indeed we
> don't need to do it here either.
>
> But I assume you specifically want things that do a lot of DMA, so I
> couldn't get away with asking for keeping it to the SBSA UART(s)? :)
>

Ideally, it would be something that supports platform MSIs as well,
but that is unlikely to be a priority for anyone (and i would be very
surprised if any of QEMU's sysbus host controllers implement that at
the moment)

I can live with just sysbus AHCI, though, if EHCI/XHCI are too cumbersome.