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

Re: [PATCH 2/2] xen/x86/pvh: copy ACPI tables to Dom0 instead of mapping


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 15 May 2023 11:44:04 +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=iBlkc0jM4MIbeBcv91rLDTvK8fWhLWiEZsFEsCcyOSA=; b=fF3ToLZJu/p/6CZEI0HRB1TzR6CIDHDhA4OWlnRgP0jKpHF4JedqkdPDyq/f01YeOEueQJNCsZJot0ol56qcBkHdv7vBwEk7GrAfdhhxFLmS1RFqDRC+xpFAt/fcPAUwiwXAWC0SW+L4ff4+dzY+DBeo0Kg+OSyPW/5Tc2rA4htzRnPnM8deCqe1iY4yKMHnYcvUyTTBPgQ2bSfr50/89tVRn96faPgxh6NqP9NQmzo8L04qSfetLnW9mocdi7YafzzaCTfZN5c6quXOc5m/IicNtbW96KUwyEcjXKpdFDewcKUlnnNJLP2mkh6+edqWGlPt7Uit+jKtQ8HhRIf9Ig==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MpRXXcpXVS/uVxHNUGOtE2VouKlIwSO8dG9YM+L5eIPvz0uQ2UMV4/QDVieWTHlWM6B6fwgHZkX8EpnyyQjsypdYESYCWA35Bj6IpIOS4iEI5wWigxQ2mE0gJhg6TjNSe7hjr5A5bvfZ2CpHpj1fA0ETVhFTublkDg0a+RFZ8J8+HjoBq1GZIP2+ZGloqFlaoKNHNrV0Xrj4TaqGCpIKpOzXtjA4fUkiB+eD1mOu6qNpHpPYn/nAcIs8rRcud4DmgR0q+m694WsqI6tffdVztSVNpulTZSIr7f9wzVwxIcDll7ilGt6+aeDpkb3Zde3ZUZS0XiePwpLKBeS8K7Oc7A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: andrew.cooper3@xxxxxxxxxx, jbeulich@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Xenia.Ragiadakou@xxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxx>
  • Delivery-date: Mon, 15 May 2023 09:44:35 +0000
  • Ironport-data: A9a23:CC0jo6qZoJRUwW/LbS4Ktu2DDlFeBmL4ZBIvgKrLsJaIsI4StFCzt garIBnVO6yNY2L2ct0jPoS2o0wCvZKGyYMwTgc6+C8yRSxA+ZuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpA1c/Ek/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06WJwUmAWP6gR5weDziRNVfrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAGxTd0GBq+Kd+pCmd9J93s8NIpjiY4xK7xmMzRmBZRonabbqZvyToPN9gnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeeraYWOEjCJbZw9ckKwv GXJ8n6/GhgHHNee1SCE4jSngeqncSbTAdpCRefpqa876LGV7l4aLUYfX32+muWa21yfQNdVO WI6pSV7+MDe82TuFLERRSaQu2WYtxQRX95RFewS6wyXzKfQpQGDCQAsTDRMddgnv88eXiEx2 xmCmNaBLSxitviZRGyQ8p+QrCiuIm4FIGkafygGQAAZpd75r+kbvh/JT98lKqe6j9T5EDL33 hiDqSR4jLIW5eYQy6i19FbAxSmwr5LESgo04AT/V2epqAh+YeaYi5eA7FHa6bNMKdifR1zY5 XwcwZHBt6YJEI2HkzGLTKMVBra16v2ZMTrax1lyA50m8Dfr8HmmFWxN3AxDyI5SGp5sUVfUj IX742u9OLc70KOWUJJK
  • Ironport-hdrordr: A9a23:zCZgtKHo950ATZJopLqELMeALOsnbusQ8zAXPiBKJCC9E/bo8v xG+c5w6faaslkssR0b9+xoW5PwI080l6QU3WB5B97LMDUO0FHCEGgI1/qA/9SPIUzDHu4279 YbT0B9YueAcGSTW6zBkXWF+9VL+qj5zEix792uq0uE1WtRGtldBwESMHf9LmRGADNoKLAeD5 Sm6s9Ot1ObCA8qhpTSPAhiYwDbzee77a7bXQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> 
> Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> the tables in the guest. Instead, copy the tables to Dom0.
> 
> This is a workaround.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> ---
> As mentioned in the cover letter, this is a RFC workaround as I don't
> know the cause of the underlying problem. I do know that this patch
> solves what would be otherwise a hang at boot when Dom0 PVH attempts to
> parse ACPI tables.

I'm unsure how safe this is for native systems, as it's possible for
firmware to modify the data in the tables, so copying them would
break that functionality.

I think we need to get to the root cause that triggers this behavior
on QEMU.  Is it the table checksum that fail, or something else?  Is
there an error from Linux you could reference?

I've got some feedback below, but I'm unsure copying is the correct
approach.

> ---
>  xen/arch/x86/hvm/dom0_build.c | 107 +++++++++-------------------------
>  1 file changed, 27 insertions(+), 80 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 5fde769863..a6037fc6ed 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -73,32 +73,6 @@ static void __init print_order_stats(const struct domain 
> *d)
>              printk("order %2u allocations: %u\n", i, order_stats[i]);
>  }
>  
> -static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> -                                       unsigned long nr_pages, const bool 
> map)
> -{
> -    int rc;
> -
> -    for ( ; ; )
> -    {
> -        rc = map ?   map_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn))
> -                 : unmap_mmio_regions(d, _gfn(pfn), nr_pages, _mfn(pfn));
> -        if ( rc == 0 )
> -            break;
> -        if ( rc < 0 )
> -        {
> -            printk(XENLOG_WARNING
> -                   "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
> -                   map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
> -            break;
> -        }
> -        nr_pages -= rc;
> -        pfn += rc;
> -        process_pending_softirqs();
> -    }
> -
> -    return rc;
> -}
> -
>  /* Populate a HVM memory range using the biggest possible order. */
>  static int __init pvh_populate_memory_range(struct domain *d,
>                                              unsigned long start,
> @@ -967,6 +941,8 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
> paddr_t madt_addr,
>      unsigned long size = sizeof(*xsdt);
>      unsigned int i, j, num_tables = 0;
>      int rc;
> +    struct acpi_table_fadt fadt;
> +    unsigned long fadt_addr = 0, dsdt_addr = 0, facs_addr = 0, fadt_size = 0;

paddr_t and size_t would be better.

>      struct acpi_table_header header = {
>          .signature    = "XSDT",
>          .length       = sizeof(struct acpi_table_header),
> @@ -1013,10 +989,33 @@ static int __init pvh_setup_acpi_xsdt(struct domain 
> *d, paddr_t madt_addr,
>      /* Copy the addresses of the rest of the allowed tables. */
>      for( i = 0, j = 1; i < acpi_gbl_root_table_list.count; i++ )
>      {
> +        void *table;

const __iomem.

> +
> +        pvh_steal_ram(d, tables[i].length, 0, GB(4), addr);
> +        table = acpi_os_map_memory(tables[i].address, tables[i].length);
> +        hvm_copy_to_guest_phys(*addr, table, tables[i].length, d->vcpu[0]);
> +        pvh_add_mem_range(d, *addr, *addr + tables[i].length, E820_ACPI);

Need to check for errors in the calls above.

> +
> +        if ( !strncmp(tables[i].signature.ascii, ACPI_SIG_FADT, 
> ACPI_NAME_SIZE) )
> +        {
> +            memcpy(&fadt, table, tables[i].length);
> +            fadt_addr = *addr;
> +            fadt_size = tables[i].length;
> +        }
> +        else if ( !strncmp(tables[i].signature.ascii, ACPI_SIG_DSDT, 
> ACPI_NAME_SIZE) )
> +                dsdt_addr = *addr;
> +        else if ( !strncmp(tables[i].signature.ascii, ACPI_SIG_FACS, 
> ACPI_NAME_SIZE) )
> +                facs_addr = *addr;

Wrong indentation.

> +
>          if ( pvh_acpi_xsdt_table_allowed(tables[i].signature.ascii,
> -                                         tables[i].address, 
> tables[i].length) )
> -            xsdt->table_offset_entry[j++] = tables[i].address;
> +                    tables[i].address, tables[i].length) )

Unrelated withe space adjustment?

Thanks, Roger.



 


Rackspace

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