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

[Ard Biesheuvel]

On Tue, 20 Nov 2018 at 09:49, Hongbo Zhang <address@hidden> wrote:
>
> On Tue, 20 Nov 2018 at 16:16, Gerd Hoffmann <address@hidden> wrote:
> >
> >   Hi,
> >
> > > > 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.
> >
> > Generic sysbus ehci should not be difficuilt, 10 lines patch or so.
> >
> > Gives you only usb2 though.  usb1 devices are handled either via ohci
> > companion controller (should be doable), or via integrated usb2 hub
> > (more common on recent hardware, but qemu usb-hub is usb1 only).
> >
> > Generic sysbus xhci would be more work.  But you'll get usb 1+2+3
> > support.  And wiring up platform MSIs should be possible too.
> >
> In kernel, these drivers are enabled by default:
> CONFIG_USB_XHCI_PLATFORM=y
> CONFIG_USB_EHCI_HCD_PLATFORM=y
> CONFIG_USB_OHCI_HCD_PLATFORM=y
>
> If we do generic EHCI or XHCI in qemu, can the driver in kernel work
> with it? (I guess yes?)
> My thought is if the available kernel driver will work without any
> change, then we can create it in qemu.
>

Yes that should work. Our MacchiatoBin DSDT has the following for its
XHCI controllers:

Device (XHC0)
{
    Name (_HID, "PNP0D10")      // _HID: Hardware ID
    Name (_UID, 0x00)           // _UID: Unique ID
    Name (_CCA, 0x01)           // _CCA: Cache Coherency Attribute

    Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
    {
        Memory32Fixed (ReadWrite,
            0xF2500000,         // Address Base (MMIO)
            0x00004000,         // Address Length
            )
        Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
        {
          CP_GIC_SPI_CP0_USB_H0
        }
    })
}

and this gets picked up by the kernel without problems.

Wiring up platform MSIs would involve modifying the IORT as well,
which is one of the reasons I'd prefer to make these fixed devices: we
cannot rely on qemu_fw_cfg to generate it for us, and adding a lot of
new code to generate this on the fly is simply not worth the effort.