Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 23 Dec 2016, Roger Pau Monné wrote:
> Hello,
> 
> I've been looking into the STAO specification[0], because I think it would 
> also
> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
> use it.
> 
> Xen doesn't have an AML parser, so I'm not sure how is it supposed to guess
> the name of the devices it wants to hide from Dom0. Is there something I'm
> missing that can be used in order to find out the device name in the ACPI
> namespace without parsing AML tables?
> 
> Thanks, Roger.
> 
> [0] https://lists.xen.org/archives/html/xen-devel/2016-08/pdfYfOWKJ83jH.pdf

Hi Roger,

Happy New Year!

There is no silver bullet here. However, we discussed several
alternative options in the past:

o per platform hardcoded paths
  we could have a per platform static table in Xen to store namespace
  paths to hide via STAO

o find out namespace paths without an interpreter
  Al Stone described a way to determine namespace paths without a full
  interpreter. Copy/pasting from 547F8A54.6060006@xxxxxxxxxx:

> > Okey dokey.  The basic idea is that objects in the ACPI namespace
> > (i.e., everything in the summation of the DSDT and any SSDTs) can
> > have an identifier describing what it is, similar to the compatible
> > property in DT.  There are three methods involved: _HID (hardware ID),
> > _CID (compatible ID), or _CLS; one or more of these must be present
> > for every namespace object needed by a device driver -- it's how the
> > driver probe finds the right object.
> > 
> > While it's a bit fiddly, it is possible and reasonably straightforward
> > to hunt down the _HID/_CID values in the DSDT without running the ACPI
> > interpreter.  If we can do that, I think we can determine the path name
> > since we can treat the DSDT as a static data structure for this usage.

  In the end, we didn't use this strategy and opted for a special flag
  for the UART.


If neither of these options are good enough for your use case, then it
is worth considering updating the STAO specification to include other
ways to match devices to hide from OSPM. For example:

o new ad hoc flag, as for the UART
  if your device is easily identifiable via another table, like the UART
  is with the SPCR table, then we could add another special flag to
  STAO. The flag would be something like "hide the device described in
  XXX".

o something based on BDF
  if your goal is to hide a PCI device, then we could add a list of PCI
  BDFs to hide. It would be up to the OSPM to match these BDFs with
  their corresponding DSDT entries and ignore them.

These two are just ideas, Al and Graeme might have better ones. it would
be helpful to know your use case in details to be able to suggest an
appropriate solution.

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