Xen: ARM: Support to map mmio region specified in static ACPI tables

Xen: ARM: Support to map mmio region specified in static ACPI tables

[Jiandi An]

Hi Guys,

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?

Thanks.

-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

Re: Xen: ARM: Support to map mmio region specified in static ACPI tables

[Stefano Stabellini]

This is not exactly ARM specific, so expanding the CC list.

On Wed, 14 Dec 2016, Jiandi An wrote:
> Hi Guys,
> 
> 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

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

Re: Xen: ARM: Support to map mmio region specified in static ACPI tables

[Jan Beulich]

>>> On 20.12.16 at 00:39, <sstabellini@kernel.org> 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@lists.xen.org
https://lists.xen.org/xen-devel

Re: Xen: ARM: Support to map mmio region specified in static ACPI tables

[Stefano Stabellini]

On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 00:39, <sstabellini@kernel.org> 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@lists.xen.org
https://lists.xen.org/xen-devel