Re: [Xen-devel] Xen: ARM: Support to map mmio region specified in static ACPI tables

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 00:39, <sstabellini@xxxxxxxxxx> wrote:
> > On Wed, 14 Dec 2016, Jiandi An wrote:
> >> Xen currently does not handle mapping mmio regions specified in standard 
> > static ACPI tables such as BERT, TPM2, GT block, IORT, HEST, etc.  There 
> > has 
> > been some initial discussions on using whitelist and leave it up to the 
> > individual drivers in dom0 who need the particular region in particular 
> > ACPI 
> > static table to be mapped to add the support of calling back to XEN to 
> > request the mapping.  Just want to get the discussion started and gather 
> > consensus on this approach.  This means in each driver in dom0 logic is 
> > inserted to check for if running under Xen being dom0, then call hypercall 
> > to 
> > XEN to request mapping.  Maintainers for individual drivers (BERT driver, 
> > TPM 
> > driver, etc) may not like this idea for inserting XEN specific checking and 
> > mapping call in the driver right?
> > 
> > Hello Jiandi,
> > 
> > I don't think that this is exactly what was suggested. Let me elaborate
> > here.
> > 
> > Any devices, even non-discoverable devices, should request MMIO regions
> > mappings via xen_map_device_mmio. We should be able to receive an
> > internal Linux notification for each one of them via the usual
> > BUS_NOTIFY_ADD_DEVICE Linux callback. See drivers/xen/arm-device.c on
> > how to handle them. If we don't receive an internal Linux callback for a
> > particular device, it is likely because of a bug in Linux and we should
> > fix it.
> > 
> > For things that are not devices, such as the Boot Error Region described
> > by BERT, it's more blurry. We have two options:
> > 
> > 1) we introduce a new internal Linux API that allows us to replace the
> > memory mapping function used for ACPI tables such as BERT
> > 
> > 2) we introduce support in Xen to parse and map each of these tables (we
> > can do that because they are all static tables, no AML involved)
> > 
> > I think that 1) is simpler and more robust. We only need a way to
> > replace the ioremap implementation when Xen is enabled. It is also
> > pretty much the same suggestion that Konrad gave for the
> > OperationRegion:
> > http://marc.info/?l=xen-devel&m=148172287422178 
> 
> Indeed - 2) would have the problem that Dom0 has no way of
> knowing which of the tables Xen did process (after all, new
> tables get added to the spec, yet older Xen won't be updated
> accordingly).

That's a very good point.

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