diff options
| author | Joao Martins <joao.m.martins@oracle.com> | 2022-07-19 18:00:14 +0100 |
|---|---|---|
| committer | Michael S. Tsirkin <mst@redhat.com> | 2022-07-26 10:40:58 -0400 |
| commit | b3e6982b4154c1c0ab8b25f2e1ac7838a1809824 (patch) | |
| tree | 65dd37f849d1f118b0fa5617e9b431b7a4c66eea /chardev/meson.build | |
| parent | 8504f129450b909c88e199ca44facd35d38ba4de (diff) | |
| download | qemu-b3e6982b4154c1c0ab8b25f2e1ac7838a1809824.zip qemu-b3e6982b4154c1c0ab8b25f2e1ac7838a1809824.tar.gz qemu-b3e6982b4154c1c0ab8b25f2e1ac7838a1809824.tar.bz2 | |
i386/pc: restrict AMD only enforcing of 1Tb hole to new machine type
The added enforcing is only relevant in the case of AMD where the
range right before the 1TB is restricted and cannot be DMA mapped
by the kernel consequently leading to IOMMU INVALID_DEVICE_REQUEST
or possibly other kinds of IOMMU events in the AMD IOMMU.
Although, there's a case where it may make sense to disable the
IOVA relocation/validation when migrating from a
non-amd-1tb-aware qemu to one that supports it.
Relocating RAM regions to after the 1Tb hole has consequences for
guest ABI because we are changing the memory mapping, so make
sure that only new machine enforce but not older ones.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-12-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'chardev/meson.build')
0 files changed, 0 insertions, 0 deletions