All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Jan Beulich <jbeulich@suse.com>,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
	Xenia.Ragiadakou@amd.com,
	Stefano Stabellini <stefano.stabellini@amd.com>
Subject: Re: [PATCH 1/2] xen/x86/pvh: use preset XSDT header for XSDT generation
Date: Wed, 17 May 2023 10:42:00 +0200	[thread overview]
Message-ID: <ZGSTWJcLmWGPg9QM@Air-de-Roger> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2305161509040.128889@ubuntu-linux-20-04-desktop>

On Tue, May 16, 2023 at 03:11:49PM -0700, Stefano Stabellini wrote:
> On Tue, 16 May 2023, Roger Pau Monné wrote:
> > On Tue, May 16, 2023 at 10:10:07AM +0200, Roger Pau Monné wrote:
> > > On Mon, May 15, 2023 at 05:16:27PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 15 May 2023, Jan Beulich wrote:
> > > > > On 15.05.2023 10:48, Roger Pau Monné wrote:
> > > > > > On Fri, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini wrote:
> > > > > >> From: Stefano Stabellini <stefano.stabellini@amd.com>
> > > > > >>
> > > > > >> Xen always generates a XSDT table even if the firmware provided a RSDT
> > > > > >> table. Instead of copying the XSDT header from the firmware table (that
> > > > > >> might be missing), generate the XSDT header from a preset.
> > > > > >>
> > > > > >> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> > > > > >> ---
> > > > > >>  xen/arch/x86/hvm/dom0_build.c | 32 +++++++++-----------------------
> > > > > >>  1 file changed, 9 insertions(+), 23 deletions(-)
> > > > > >>
> > > > > >> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > > > > >> index 307edc6a8c..5fde769863 100644
> > > > > >> --- a/xen/arch/x86/hvm/dom0_build.c
> > > > > >> +++ b/xen/arch/x86/hvm/dom0_build.c
> > > > > >> @@ -963,13 +963,18 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
> > > > > >>                                        paddr_t *addr)
> > > > > >>  {
> > > > > >>      struct acpi_table_xsdt *xsdt;
> > > > > >> -    struct acpi_table_header *table;
> > > > > >> -    struct acpi_table_rsdp *rsdp;
> > > > > >>      const struct acpi_table_desc *tables = acpi_gbl_root_table_list.tables;
> > > > > >>      unsigned long size = sizeof(*xsdt);
> > > > > >>      unsigned int i, j, num_tables = 0;
> > > > > >> -    paddr_t xsdt_paddr;
> > > > > >>      int rc;
> > > > > >> +    struct acpi_table_header header = {
> > > > > >> +        .signature    = "XSDT",
> > > > > >> +        .length       = sizeof(struct acpi_table_header),
> > > > > >> +        .revision     = 0x1,
> > > > > >> +        .oem_id       = "Xen",
> > > > > >> +        .oem_table_id = "HVM",
> > > > > > 
> > > > > > I think this is wrong, as according to the spec the OEM Table ID must
> > > > > > match the OEM Table ID in the FADT.
> > > > > > 
> > > > > > We likely want to copy the OEM ID and OEM Table ID from the RSDP, and
> > > > > > possibly also the other OEM related fields.
> > > > > > 
> > > > > > Alternatively we might want to copy and use the RSDT on systems that
> > > > > > lack an XSDT, or even just copy the header from the RSDT into Xen's
> > > > > > crafted XSDT, since the format of the RSDP and the XSDT headers are
> > > > > > exactly the same (the difference is in the size of the description
> > > > > > headers that come after).
> > > > > 
> > > > > I guess I'd prefer that last variant.
> > > > 
> > > > I tried this approach (together with the second patch for necessity) and
> > > > it worked.
> > > > 
> > > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > > > index fd2cbf68bc..11d6d1bc23 100644
> > > > --- a/xen/arch/x86/hvm/dom0_build.c
> > > > +++ b/xen/arch/x86/hvm/dom0_build.c
> > > > @@ -967,6 +967,10 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
> > > >          goto out;
> > > >      }
> > > >      xsdt_paddr = rsdp->xsdt_physical_address;
> > > > +    if ( !xsdt_paddr )
> > > > +    {
> > > > +        xsdt_paddr = rsdp->rsdt_physical_address;
> > > > +    }
> > > >      acpi_os_unmap_memory(rsdp, sizeof(*rsdp));
> > > >      table = acpi_os_map_memory(xsdt_paddr, sizeof(*table));
> > > >      if ( !table )
> > > 
> > > To be slightly more consistent, could you use:
> > > 
> > > /*
> > >  * Note the header is the same for both RSDT and XSDT, so it's fine to
> > >  * copy the native RSDT header to the Xen crafted XSDT if no native
> > >  * XSDT is available.
> > >  */
> > > if (rsdp->revision > 1 && rsdp->xsdt_physical_address)
> > >     sdt_paddr = rsdp->xsdt_physical_address;
> > > else
> > >     sdt_paddr = rsdp->rsdt_physical_address;
> > > 
> > > It was an oversight of mine to not check for the RSDP revision, as
> > > RSDP < 2 will never have an XSDT.  Also add:
> > > 
> > > Fixes: 1d74282c455f ('x86: setup PVHv2 Dom0 ACPI tables')
> > 
> > Just realized this will require some more work so that the guest
> > (dom0) provided RSDP is at least revision 2.  You will need to adjust
> > the field and recalculate the checksum if needed.
> 
> But we are always providing RSDP version 2 in pvh_setup_acpi, right?

Yes, as said in the reply to Jan, just ignore this.

Thanks, Roger.


  reply	other threads:[~2023-05-17  8:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-13  1:16 [PATCH 0/2] PVH Dom0 on QEMU Stefano Stabellini
2023-05-13  1:17 ` [PATCH 1/2] xen/x86/pvh: use preset XSDT header for XSDT generation Stefano Stabellini
2023-05-15  8:48   ` Roger Pau Monné
2023-05-15 14:14     ` Jan Beulich
2023-05-16  0:16       ` Stefano Stabellini
2023-05-16  6:13         ` Jan Beulich
2023-05-16  8:10         ` Roger Pau Monné
2023-05-16  8:13           ` Roger Pau Monné
2023-05-16  8:24           ` Roger Pau Monné
2023-05-16  9:13             ` Jan Beulich
2023-05-16  9:23               ` Roger Pau Monné
2023-05-16 22:11             ` Stefano Stabellini
2023-05-17  8:42               ` Roger Pau Monné [this message]
2023-05-13  1:17 ` [PATCH 2/2] xen/x86/pvh: copy ACPI tables to Dom0 instead of mapping Stefano Stabellini
2023-05-15  9:44   ` Roger Pau Monné
2023-05-16  0:11     ` Stefano Stabellini
2023-05-16  0:38       ` Stefano Stabellini
2023-05-16  6:27       ` Jan Beulich
2023-05-16  9:21       ` Roger Pau Monné
2023-05-16 23:34         ` Stefano Stabellini
2023-05-17  8:40           ` Roger Pau Monné
2023-05-17 21:00             ` Stefano Stabellini
2023-05-18  8:34               ` Roger Pau Monné
2023-05-15 14:17   ` Jan Beulich
2023-05-16  0:12     ` Stefano Stabellini
2023-05-18  7:24     ` Xenia Ragiadakou
2023-05-18  9:31       ` Roger Pau Monné
2023-05-18 11:36         ` Xenia Ragiadakou
2023-05-18 11:44           ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGSTWJcLmWGPg9QM@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=Xenia.Ragiadakou@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=stefano.stabellini@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.