[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] xen/x86/pvh: use preset XSDT header for XSDT generation


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 16 May 2023 11:23:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8X/ySDcgJo2bF/96Sgw/t2NcUNoutRPmYmkCEzvaqhQ=; b=njh8sggyNyex1dJf/MesShPP1F3/JHBelAJVYe1EwduY3WMKZQMj0UiCgEI998mCa4fkOLBeBVJo1QgC0GJHECTtJmriSrV0tq0/LsJl7m4KMhz706r9DL9Hr8ci7pcp/tDIDWDznYQmxtMmolffmYwDdNfUpDsnGL/4W+v8X7cPc2QkBrKP1/9cXLOQEu9lXEfvkg/BJxMIFLN9JOgT9Ck4LHQUVfDqQjbOMH2mWuXz25g3lyzbSuDanjPbhXXqJ+8gSWllq5ZQS8BHoUsWkaZNnqJFN3FdVH9z+Pmjtt6+bi11Pfw4XOC6J1BiHa/5jkerGxepsx6tEiL1zt+t0Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pk8GdR+FgnCiGpmmSdH1x3VK3AB8j/UVtJpLPHykvbFD3TO0TGcx8Gf5eWEOBM1nJxYQaR0Lk76Fj/F0kPvheGhL0+tI32E0/PH536RNDgevFjGIiRsgKaenYK1mzmcz9P2FTgskSPNnuwAcjhg726fpGvuEdttclREVfsQ8o4TTFMkYHONe24RL6tShxaQsDCSdXPn0YWvaldPFKmZAXUjQIPOykGwYkeBjuy+va8Ox5/R/QZOF/YYINB3DPs3zX7CfQyaCANqk9+B2GCIDr12VWD8hor6UhXOXNEP4BwetaGKBr0klI15egXx93WqgVS1vRssmQcOmvWoRnVy1pg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, andrew.cooper3@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Xenia.Ragiadakou@xxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxx>
  • Delivery-date: Tue, 16 May 2023 09:23:43 +0000
  • Ironport-data: A9a23:zcJf5q8J/R4pq2HzRg4PDrUDYH+TJUtcMsCJ2f8bNWPcYEJGY0x3z zdKXTrTP/qDYjShf9p1aNjl8EJQ7MPUzdViTgU5qX88E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKicYXoZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI+1BjOkGlA5AdmOKkV5Aa2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklBq dsAFhw1TCm/vPiE7K2iVOd1o+gKeZyD0IM34hmMzBn/JNN/GNXvZvuP4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWMilUui9ABM/KMEjCObd9SkUuC4 HrP4kzyAw0ANczZwj2Amp6prraXwnKnBdhDT9VU8NY6mUacyV0eTyEHD3a6s8KItmKlXt1Qf hl8Fi0G6PJaGFaQZtv3UgC8oXWElgUBQNcWGOo/gCmW0bbd6QudAmkCTxZCZcYguctwQiYlv neZktWsCTFxvbm9TXOG6qzSvT60ITISL2IJeWkDVwRty+nupoA6yCjGQddqHKe2icDdEDT8h TuNqUAWnKkeg8cN0OOg4VnNjjaop57IZgcw6kPcWWfN0+9iTIusZojt5V2F6/9Fdd+dVgPY4 yNCnNWC5ucTC53LjDaKXOgGALCu4bCCLSHYhllsWZIm8lxB5kKeQGyZ2xkmTG8BDyrOUWaBj JP70e+J2KJuAQ==
  • Ironport-hdrordr: A9a23:45/q2qs74VkxoVDBdtlr1Iy37skDstV00zEX/kB9WHVpm6yj+v xG/c5rsCMc7Qx6ZJhOo7+90cW7L080lqQFg7X5X43DYOCOggLBQL2KhbGI/9SKIVycygcy78 Zdm6gVMqyLMbB55/yKnTVRxbwbsaW6GKPDv5ag8590JzsaD52Jd21Ce36m+ksdfnggObMJUK Cyy+BgvDSadXEefq2AdwI4t7iqnaysqHr+CyR2fiIa1A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, May 16, 2023 at 11:13:17AM +0200, Jan Beulich wrote:
> On 16.05.2023 10:24, 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@xxxxxxx>
> >>>>>>
> >>>>>> 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@xxxxxxx>
> >>>>>> ---
> >>>>>>  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.
> 
> We could also mandate ACPI version >= 2 for PVH Dom0.

Sorry, mentioned on IRC, the above is not required because the RSDP
provided to dom0 is already crafted by Xen and unconditionally set to
version == 2.  There's no need to adjust the RSDP at all.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.