[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen: ARM: Support to map mmio region specified in static ACPI tables
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |