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

[Ard Biesheuvel]

On Mon, 19 Nov 2018 at 04:44, Leif Lindholm <address@hidden> wrote:
>
> On Fri, Nov 16, 2018 at 02:04:07PM -0800, Ard Biesheuvel wrote:
> > > > > What is this using the exynos4210 USB device for? That
> > > > > is definitely not correct for a generic board.
> > > > >
> > > > Checked the code:
> > > > #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
> > > > #define TYPE_EXYNOS4210_EHCI "exynos4210-ehci-usb"
> > > > #define TYPE_TEGRA2_EHCI "tegra2-ehci-usb"
> > > > #define TYPE_PPC4xx_EHCI "ppc4xx-ehci-usb"
> > > > #define TYPE_FUSBH200_EHCI "fusbh200-ehci-usb"
> > > >
> > > > The first one seems only a parent type, not a general instance, cannot
> > > > be used directly.
> > > > The other four are specific instances using the first as parent type,
> > > > one of them can be chosen to use.
> > > > That is my understanding, any comments, or do we need to implement one
> > > > which seems generic?
> > >
> > > 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.