From: Igor Mammedov <imammedo@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: qemu-devel@nongnu.org, Eduardo Habkost <eduardo@habkost.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Alex Williamson <alex.williamson@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Ani Sinha <ani@anisinha.ca>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v6 09/10] i386/pc: relocate 4g start to 1T where applicable
Date: Mon, 11 Jul 2022 14:56:27 +0200 [thread overview]
Message-ID: <20220711145627.2c318ba6@redhat.com> (raw)
In-Reply-To: <20220701161014.3850-10-joao.m.martins@oracle.com>
On Fri, 1 Jul 2022 17:10:13 +0100
Joao Martins <joao.m.martins@oracle.com> wrote:
> It is assumed that the whole GPA space is available to be DMA
> addressable, within a given address space limit, except for a
> tiny region before the 4G. Since Linux v5.4, VFIO validates
> whether the selected GPA is indeed valid i.e. not reserved by
> IOMMU on behalf of some specific devices or platform-defined
> restrictions, and thus failing the ioctl(VFIO_DMA_MAP) with
> -EINVAL.
>
> AMD systems with an IOMMU are examples of such platforms and
> particularly may only have these ranges as allowed:
>
> 0000000000000000 - 00000000fedfffff (0 .. 3.982G)
> 00000000fef00000 - 000000fcffffffff (3.983G .. 1011.9G)
> 0000010000000000 - ffffffffffffffff (1Tb .. 16Pb[*])
>
> We already account for the 4G hole, albeit if the guest is big
> enough we will fail to allocate a guest with >1010G due to the
> ~12G hole at the 1Tb boundary, reserved for HyperTransport (HT).
>
> [*] there is another reserved region unrelated to HT that exists
> in the 256T boundary in Fam 17h according to Errata #1286,
> documeted also in "Open-Source Register Reference for AMD Family
> 17h Processors (PUB)"
>
> When creating the region above 4G, take into account that on AMD
> platforms the HyperTransport range is reserved and hence it
> cannot be used either as GPAs. On those cases rather than
> establishing the start of ram-above-4g to be 4G, relocate instead
> to 1Tb. See AMD IOMMU spec, section 2.1.2 "IOMMU Logical
> Topology", for more information on the underlying restriction of
> IOVAs.
>
> After accounting for the 1Tb hole on AMD hosts, mtree should
> look like:
>
> 0000000000000000-000000007fffffff (prio 0, i/o):
> alias ram-below-4g @pc.ram 0000000000000000-000000007fffffff
> 0000010000000000-000001ff7fffffff (prio 0, i/o):
> alias ram-above-4g @pc.ram 0000000080000000-000000ffffffffff
>
> If the relocation is done or the address space covers it, we
> also add the the reserved HT e820 range as reserved.
>
> Default phys-bits on Qemu is TCG_PHYS_ADDR_BITS (40) which is enough
> to address 1Tb (0xff ffff ffff). On AMD platforms, if a
> ram-above-4g relocation may be desired and the CPU wasn't configured
> with a big enough phys-bits, print an error message to the user
> and do not make the relocation of the above-4g-region if phys-bits
> is too low.
>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
> hw/i386/pc.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 101 insertions(+)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index a79fa1b6beeb..07025b510540 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -907,6 +907,87 @@ static uint64_t pc_get_cxl_range_end(PCMachineState *pcms)
> return start;
> }
>
> +static hwaddr pc_max_used_gpa(PCMachineState *pcms,
> + hwaddr above_4g_mem_start,
> + uint64_t pci_hole64_size)
> +{
> + X86MachineState *x86ms = X86_MACHINE(pcms);
> +
> + if (!x86ms->above_4g_mem_size) {
> + /*
> + * 32-bit pci hole goes from
> + * end-of-low-ram (@below_4g_mem_size) to IOAPIC.
> + */
> + return IO_APIC_DEFAULT_ADDRESS - 1;
> + }
this hunk still bothers me (nothing changed wrt v5 issues around it)
issues recap: (
1. correctness of it
2. being limited to AMD only, while it seems pretty generic to me
3. should be a separate patch
)
> +
> + return pc_pci_hole64_start() + pci_hole64_size;
> +}
> +
> +/*
> + * AMD systems with an IOMMU have an additional hole close to the
> + * 1Tb, which are special GPAs that cannot be DMA mapped. Depending
> + * on kernel version, VFIO may or may not let you DMA map those ranges.
> + * Starting Linux v5.4 we validate it, and can't create guests on AMD machines
> + * with certain memory sizes. It's also wrong to use those IOVA ranges
> + * in detriment of leading to IOMMU INVALID_DEVICE_REQUEST or worse.
> + * The ranges reserved for Hyper-Transport are:
> + *
> + * FD_0000_0000h - FF_FFFF_FFFFh
> + *
> + * The ranges represent the following:
> + *
> + * Base Address Top Address Use
> + *
> + * FD_0000_0000h FD_F7FF_FFFFh Reserved interrupt address space
> + * FD_F800_0000h FD_F8FF_FFFFh Interrupt/EOI IntCtl
> + * FD_F900_0000h FD_F90F_FFFFh Legacy PIC IACK
> + * FD_F910_0000h FD_F91F_FFFFh System Management
> + * FD_F920_0000h FD_FAFF_FFFFh Reserved Page Tables
> + * FD_FB00_0000h FD_FBFF_FFFFh Address Translation
> + * FD_FC00_0000h FD_FDFF_FFFFh I/O Space
> + * FD_FE00_0000h FD_FFFF_FFFFh Configuration
> + * FE_0000_0000h FE_1FFF_FFFFh Extended Configuration/Device Messages
> + * FE_2000_0000h FF_FFFF_FFFFh Reserved
> + *
> + * See AMD IOMMU spec, section 2.1.2 "IOMMU Logical Topology",
> + * Table 3: Special Address Controls (GPA) for more information.
> + */
> +#define AMD_HT_START 0xfd00000000UL
> +#define AMD_HT_END 0xffffffffffUL
> +#define AMD_ABOVE_1TB_START (AMD_HT_END + 1)
> +#define AMD_HT_SIZE (AMD_ABOVE_1TB_START - AMD_HT_START)
> +
> +static void pc_set_amd_above_4g_mem_start(PCMachineState *pcms,
> + uint64_t pci_hole64_size)
> +{
> + X86MachineState *x86ms = X86_MACHINE(pcms);
> + hwaddr start = x86ms->above_4g_mem_start;
> + hwaddr maxphysaddr, maxusedaddr;
> +
> + /* Bail out if max possible address does not cross HT range */
> + if (pc_max_used_gpa(pcms, start, pci_hole64_size) < AMD_HT_START) {
move it to the caller?
> + return;
> + }
> +
> + /*
> + * Relocating ram-above-4G requires more than TCG_PHYS_ADDR_BITS (40).
> + * So make sure phys-bits is required to be appropriately sized in order
> + * to proceed with the above-4g-region relocation and thus boot.
> + */
> + start = AMD_ABOVE_1TB_START;
> + maxphysaddr = ((hwaddr)1 << X86_CPU(first_cpu)->phys_bits) - 1;
> + maxusedaddr = pc_max_used_gpa(pcms, start, pci_hole64_size);
> + if (maxphysaddr < maxusedaddr) {
> + error_report("Address space limit 0x%"PRIx64" < 0x%"PRIx64
> + " phys-bits too low (%u) cannot avoid AMD HT range",
> + maxphysaddr, maxusedaddr, X86_CPU(first_cpu)->phys_bits);
> + exit(EXIT_FAILURE);
> + }
> +
> + x86ms->above_4g_mem_start = start;
> +}
> +
> void pc_memory_init(PCMachineState *pcms,
> MemoryRegion *system_memory,
> MemoryRegion *rom_memory,
> @@ -922,12 +1003,31 @@ void pc_memory_init(PCMachineState *pcms,
> PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
> X86MachineState *x86ms = X86_MACHINE(pcms);
> hwaddr cxl_base, cxl_resv_end = 0;
> + X86CPU *cpu = X86_CPU(first_cpu);
>
> assert(machine->ram_size == x86ms->below_4g_mem_size +
> x86ms->above_4g_mem_size);
>
> linux_boot = (machine->kernel_filename != NULL);
>
> + /*
> + * The HyperTransport range close to the 1T boundary is unique to AMD
> + * hosts with IOMMUs enabled. Restrict the ram-above-4g relocation
> + * to above 1T to AMD vCPUs only.
> + */
> + if (IS_AMD_CPU(&cpu->env)) {
> + pc_set_amd_above_4g_mem_start(pcms, pci_hole64_size);
> +
> + /*
> + * Advertise the HT region if address space covers the reserved
> + * region or if we relocate.
> + */
> + if (x86ms->above_4g_mem_start == AMD_ABOVE_1TB_START ||
> + cpu->phys_bits >= 40) {
> + e820_add_entry(AMD_HT_START, AMD_HT_SIZE, E820_RESERVED);
> + }
> + }
> +
> /*
> * Split single memory region and use aliases to address portions of it,
> * done for backwards compatibility with older qemus.
> @@ -938,6 +1038,7 @@ void pc_memory_init(PCMachineState *pcms,
> 0, x86ms->below_4g_mem_size);
> memory_region_add_subregion(system_memory, 0, ram_below_4g);
> e820_add_entry(0, x86ms->below_4g_mem_size, E820_RAM);
> +
stray newline?
> if (x86ms->above_4g_mem_size > 0) {
> ram_above_4g = g_malloc(sizeof(*ram_above_4g));
> memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g",
next prev parent reply other threads:[~2022-07-11 12:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 16:10 [PATCH v6 00/10] i386/pc: Fix creation of >= 1010G guests on AMD systems with IOMMU Joao Martins
2022-07-01 16:10 ` [PATCH v6 01/10] hw/i386: add 4g boundary start to X86MachineState Joao Martins
2022-07-01 16:10 ` [PATCH v6 02/10] i386/pc: create pci-host qdev prior to pc_memory_init() Joao Martins
2022-07-01 16:10 ` [PATCH v6 03/10] i386/pc: pass pci_hole64_size " Joao Martins
2022-07-09 20:51 ` B
2022-07-11 10:01 ` Joao Martins
2022-07-11 22:17 ` B
2022-07-12 9:27 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 04/10] i386/pc: factor out above-4g end to an helper Joao Martins
2022-07-07 12:42 ` Igor Mammedov
2022-07-07 15:14 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 05/10] i386/pc: factor out cxl range end to helper Joao Martins
2022-07-07 12:57 ` Igor Mammedov
2022-07-07 15:17 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 06/10] i386/pc: factor out cxl range start " Joao Martins
2022-07-07 13:00 ` Igor Mammedov
2022-07-07 15:18 ` Joao Martins
2022-07-11 12:47 ` Igor Mammedov
2022-07-11 14:28 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 07/10] i386/pc: handle unitialized mr in pc_get_cxl_range_end() Joao Martins
2022-07-07 13:05 ` Igor Mammedov
2022-07-07 15:21 ` Joao Martins
2022-07-11 12:58 ` Igor Mammedov
2022-07-11 14:32 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 08/10] i386/pc: factor out device_memory base/size to helper Joao Martins
2022-07-07 13:15 ` Igor Mammedov
2022-07-07 15:23 ` Joao Martins
2022-07-01 16:10 ` [PATCH v6 09/10] i386/pc: relocate 4g start to 1T where applicable Joao Martins
2022-07-07 15:53 ` Joao Martins
2022-07-11 12:56 ` Igor Mammedov [this message]
2022-07-11 14:52 ` Joao Martins
2022-07-11 15:31 ` Joao Martins
2022-07-11 20:03 ` Joao Martins
2022-07-12 9:06 ` Igor Mammedov
2022-07-12 10:01 ` Joao Martins
2022-07-12 10:21 ` Joao Martins
2022-07-12 11:35 ` Joao Martins
2022-07-14 9:28 ` Igor Mammedov
2022-07-14 9:54 ` Joao Martins
2022-07-14 10:47 ` Joao Martins
2022-07-14 11:50 ` Igor Mammedov
2022-07-14 15:39 ` Joao Martins
2022-07-14 9:30 ` Igor Mammedov
2022-07-01 16:10 ` [PATCH v6 10/10] i386/pc: restrict AMD only enforcing of valid IOVAs to new machine type Joao Martins
2022-07-04 14:27 ` Dr. David Alan Gilbert
2022-07-05 8:48 ` Joao Martins
2022-07-11 13:03 ` Igor Mammedov
2022-07-11 14:56 ` Joao Martins
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=20220711145627.2c318ba6@redhat.com \
--to=imammedo@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=ani@anisinha.ca \
--cc=dgilbert@redhat.com \
--cc=eduardo@habkost.net \
--cc=joao.m.martins@oracle.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=suravee.suthikulpanit@amd.com \
/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.