On Thu, 29 Oct 2020, Jürgen Groß wrote: > On 29.10.20 01:37, Stefano Stabellini wrote: > > On Tue, 27 Oct 2020, Elliott Mitchell wrote: > > > On Mon, Oct 26, 2020 at 06:44:27PM +0000, Julien Grall wrote: > > > > On 26/10/2020 16:03, Elliott Mitchell wrote: > > > > > On Mon, Oct 26, 2020 at 01:31:42PM +0000, Julien Grall wrote: > > > > > > On 24/10/2020 06:35, Elliott Mitchell wrote: > > > > > > > ACPI has a distinct > > > > > > > means of specifying a limited DMA-width; the above fails, because > > > > > > > it > > > > > > > assumes a *device-tree*. > > > > > > > > > > > > Do you know if it would be possible to infer from the ACPI static > > > > > > table > > > > > > the DMA-width? > > > > > > > > > > Yes, and it is. Due to not knowing much about ACPI tables I don't > > > > > know > > > > > what the C code would look like though (problem is which documentation > > > > > should I be looking at first?). > > > > > > > > What you provided below is an excerpt of the DSDT. AFAIK, DSDT content > > > > is written in AML. So far the shortest implementation I have seen for > > > > the AML parser is around 5000 lines (see [1]). It might be possible to > > > > strip some the code, although I think this will still probably too big > > > > for a single workaround. > > > > > > > > What I meant by "static table" is a table that looks like a structure > > > > and can be parsed in a few lines. If we can't find on contain the DMA > > > > window, then the next best solution is to find a way to identity the > > > > platform. > > > > > > > > I don't know enough ACPI to know if this solution is possible. A good > > > > starter would probably be the ACPI spec [2]. > > > > > > Okay, that is worse than I had thought (okay, ACPI is impressively > > > complex for something nominally firmware-level). > > > > > > There are strings in the present Tianocore implementation for Raspberry > > > PI 4B which could be targeted. Notably included in the output during > > > boot listing the tables, "RPIFDN", "RPIFDN RPI" and "RPIFDN RPI4" (I'm > > > unsure how kosher these are as this wsn't implemented nor blessed by the > > > Raspberry PI Foundation). > > > > > > I strongly dislike this approach as you soon turn the Xen project into a > > > database of hardware. This is already occurring with > > > xen/arch/arm/platforms and I would love to do something about this. On > > > that thought, how about utilizing Xen's command-line for this purpose? > > > > I don't think that a command line option is a good idea: basically it is > > punting to users the task of platform detection. Also, it means that > > users will be necessarily forced to edit the uboot script or grub > > configuration file to boot. > > > > Note that even if we introduced a new command line, we wouldn't take > > away the need for xen/arch/arm/platforms anyway. > > > > It would be far better for Xen to autodetect the platform if we can. > > > > > > > Have a procedure of during installation/updates retrieve DMA limitation > > > information from the running OS and the following boot Xen will follow > > > the appropriate setup. By its nature, Domain 0 will have the information > > > needed, just becomes an issue of how hard that is to retrieve... > > > > Historically that is what we used to do for many things related to ACPI, > > but unfortunately it leads to a pretty bad architecture where Xen > > depends on Dom0 for booting rather than the other way around. (Dom0 > > should be the one requiring Xen for booting, given that Xen is higher > > privilege and boots first.) > > > > > > I think the best compromise is still to use an ACPI string to detect the > > platform. For instance, would it be possible to use the OEMID fields in > > RSDT, XSDT, FADT? Possibly even a combination of them? > > > > Another option might be to get the platform name from UEFI somehow. > > What about having a small domain parsing the ACPI booting first and use > that information for booting dom0? > > That dom would be part of the Xen build and the hypervisor wouldn't need > to gain all the ACPI AML logic.
That could work, but in practice we don't have such a domain today -- the infrastructure is missing. I wonder whether the bootloader (uboot or grub) would know about the platform and might be able to pass that information to Xen somehow.
