Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 20, 2017 at 02:10:33PM +0100, Julien Grall wrote:
> Hi Royger,
> 
> On 20/01/2017 12:01, Roger Pau Monné wrote:
> > On Thu, Jan 19, 2017 at 09:14:03PM +0100, Julien Grall wrote:
> In case of ARM, Xen does not use any PCI devices (no PCI UART) itself so
> scanning before hand is not necessary. If possible, I would prefer to have
> the scanning in one place rather than spreading in different place depending
> on the segments (we do have multiple segment on ARM).

AFAIK on ARM you could do the scan inside of the implementation of
PHYSDEVOP_pci_mmcfg_reserved hypercall, and that would be enough in order to
discover the devices.

> > 
> > > Also, you are assuming that the MCFG will describe the host controller. 
> > > This
> > > is the case only when host controller available at boot. So you may miss
> > > some here.
> > 
> > Yes, I know, that's why we need the hypercall. The information in the MCFG
> > table might be incomplete, and the hardware domain would have to fetch extra
> > ECAM information from the _SEG method of host bridge devices in the ACPI
> > namespace.
> > 
> > > Furthermore, on ARM we have other static tables (such as GTDT) contain 
> > > MMIO
> > > region to map.
> > > 
> > > Lastly, all devices are not PCI and you may have platform devices. The
> > > platform devices will only be described in the ASL. Just in case, those
> > > regions are not necessarily described in UEFI memory map.
> > 
> > Will those devices work properly in such scenario? (ie: are they behind the
> > SMMU?)
> 
> Platform devices might or might not be behind of the SMMU. It will depend if
> the device is DMA-capable and often whether the implementer decided to have
> an SMMU.
> 
> Today, there is no SMMU support (it is by-passed) for ACPI so we haven't yet
> encountered the problem. We have an item to investigate the work to be done
> here.

Why would you need the SMMU for ACPI?

> Some thoughts, each device will be associated to one of multiple StreamID
> (ID to configure the SMMU). I guess we could find this from the static table
> IORT, need to check.
> 
> Also, some of the platform device will have MSIs, I suspect the number of
> MSIs will be either hardcoded or found in the ASL. So we would need to have
> a new hypercall to advertise those.
> 
> > 
> > > So you need DOM0 to tell the list of regions.
> > 
> > Yes, I agree that we need such hypercall ATM, although I think that we 
> > might be
> > able to get rid of it in the long term if we are able to parse the AML 
> > tables
> > from Xen.
> 
> Are you suggesting to bring a full AML parser in Xen? If so, it will be much
> bigger than Xen ARM itself. I would need a strong use case to accept a such
> thing.

It could be placed in the init section, and get rid of it after boot. Also, I
find it hard to believe that an AML parser is bigger than the whole Xen on ARM.
The OpenBSD folks have a DSDT parser in ~4000 lines of code [0], and that's
probably way more than what Xen actually needs.

Roger.

[0] https://github.com/openbsd/src/blob/master/sys/dev/acpi/dsdt.c

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel