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

[Leif Lindholm]

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)? :)

/
    Leif