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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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).

Jan


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