[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] e4bcec: acpi/nvdimm: Define trace events for
|
From: |
Richard Henderson |
|
Subject: |
[Qemu-commits] [qemu/qemu] e4bcec: acpi/nvdimm: Define trace events for NVDIMM and su... |
|
Date: |
Tue, 26 Jul 2022 12:58:04 -0700 |
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: e4bcec0c3c8527a3f2be2791fa6a89387b9116c1
https://github.com/qemu/qemu/commit/e4bcec0c3c8527a3f2be2791fa6a89387b9116c1
Author: Robert Hoo <robert.hu@linux.intel.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/acpi/nvdimm.c
M hw/acpi/trace-events
M include/hw/mem/nvdimm.h
Log Message:
-----------
acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()
Signed-off-by: Robert Hoo <robert.hu@linux.intel.com>
Reviewed-by: Jingqi Liu <jingqi.liu@intel.com>
Message-Id: <20220704085852.330005-1-robert.hu@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 71a5f07e75ba34072a074181d37009abc28d7083
https://github.com/qemu/qemu/commit/71a5f07e75ba34072a074181d37009abc28d7083
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M include/hw/boards.h
Log Message:
-----------
hw/machine: Clear out left over CXL related pointer from move of state
handling to machines.
This got left behind in the move of the CXL setup code from core
files to the machines that support it.
Link:
https://gitlab.com/qemu-project/qemu/-/commit/1ebf9001fb2701e3c00b401334c8f3900a46adaa
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220701132300.2264-2-Jonathan.Cameron@huawei.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 4a447a710c523392b09391232d5a3dfb156a9d75
https://github.com/qemu/qemu/commit/4a447a710c523392b09391232d5a3dfb156a9d75
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Always place CXL Memory Regions after device_memory
Previously broken_reserved_end was taken into account, but Igor Mammedov
identified that this could lead to a clash between potential RAM being
mapped in the region and CXL usage. Hence always add the size of the
device_memory memory region. This only affects the case where the
broken_reserved_end flag was set.
Fixes: 6e4e3ae936e6 ("hw/cxl/component: Implement host bridge MMIO (8.2.5,
table 142)")
Reported-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220701132300.2264-3-Jonathan.Cameron@huawei.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: cb70b7e8712e17e5761a7447defdce5572cd4b80
https://github.com/qemu/qemu/commit/cb70b7e8712e17e5761a7447defdce5572cd4b80
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M include/hw/cxl/cxl_component.h
Log Message:
-----------
hw/cxl: Fix size of constant in interleave granularity function.
Whilst the interleave granularity is always small enough that this isn't
a real problem (much less than 4GiB) let's change the constant
to ULL to fix the coverity warning.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 829de299d1 ("hw/cxl/component: Add utils for interleave parameter
encoding/decoding")
Fixes: Coverity CID 1488868
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20220701132300.2264-4-Jonathan.Cameron@huawei.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 4ab4c33014b4876bc6d7888efecd6bfcca0d045a
https://github.com/qemu/qemu/commit/4ab4c33014b4876bc6d7888efecd6bfcca0d045a
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/acpi-build.c
M hw/i386/pc.c
M hw/i386/sgx.c
M hw/i386/x86.c
M include/hw/i386/x86.h
Log Message:
-----------
hw/i386: add 4g boundary start to X86MachineState
Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState field @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-2-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 4876778749021a59a03dd3da3518dc861bc95ff8
https://github.com/qemu/qemu/commit/4876778749021a59a03dd3da3518dc861bc95ff8
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M hw/pci-host/i440fx.c
M include/hw/pci-host/i440fx.h
Log Message:
-----------
i386/pc: create pci-host qdev prior to pc_memory_init()
At the start of pc_memory_init() we usually pass a range of
0..UINT64_MAX as pci_memory, when really its 2G (i440fx) or
32G (q35). To get the real user value, we need to get pci-host
passed property for default pci_hole64_size. Thus to get that,
create the qdev prior to memory init to better make estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-3-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: c48eb7a4e869f338e5b3e233fed7c9dbb0520247
https://github.com/qemu/qemu/commit/c48eb7a4e869f338e5b3e233fed7c9dbb0520247
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M include/hw/i386/pc.h
Log Message:
-----------
i386/pc: pass pci_hole64_size to pc_memory_init()
Use the pre-initialized pci-host qdev and fetch the
pci-hole64-size into pc_memory_init() newly added argument.
Use PCI_HOST_PROP_PCI_HOLE64_SIZE pci-host property for
fetching pci-hole64-size.
This is in preparation to determine that host-phys-bits are
enough and for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-4-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 5ff62e2afedf5c984048f90a881794622a9eb3e8
https://github.com/qemu/qemu/commit/5ff62e2afedf5c984048f90a881794622a9eb3e8
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: factor out above-4g end to an helper
There's a couple of places that seem to duplicate this calculation
of RAM size above the 4G boundary. Move all those to a helper function.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-5-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 55668e409bcaf04e6af7acb44037d5f18c6b786e
https://github.com/qemu/qemu/commit/55668e409bcaf04e6af7acb44037d5f18c6b786e
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: factor out cxl range end to helper
Move calculation of CXL memory region end to separate helper.
This is in preparation to a future change that removes CXL range
dependency on the CXL memory region, with the goal of allowing
pc_pci_hole64_start() to be called before any memory region are
initialized.
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-6-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 42bed0712725ce338fc1cad725c3d9cf5cf443dc
https://github.com/qemu/qemu/commit/42bed0712725ce338fc1cad725c3d9cf5cf443dc
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: factor out cxl range start to helper
Factor out the calculation of the base address of the memory region.
It will be used later on for the cxl range end counterpart calculation
and as well in pc_memory_init() CXL memory region initialization, thus
avoiding duplication.
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-7-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 1065b21993628a00066a2ab1439bfff5d186c12d
https://github.com/qemu/qemu/commit/1065b21993628a00066a2ab1439bfff5d186c12d
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: handle unitialized mr in pc_get_cxl_range_end()
Remove pc_get_cxl_range_end() dependency on the CXL memory region,
and replace with one that does not require the CXL host_mr to determine
the start of CXL start.
This in preparation to allow pc_pci_hole64_start() to be called early
in pc_memory_init(), handle CXL memory region end when its underlying
memory region isn't yet initialized.
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Message-Id: <20220719170014.27028-8-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Commit: 8288a8286d00e074b765f1d47ee61159ed5291fd
https://github.com/qemu/qemu/commit/8288a8286d00e074b765f1d47ee61159ed5291fd
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: factor out device_memory base/size to helper
Move obtaining hole64_start from device_memory memory region base/size
into an helper alongside correspondent getters in pc_memory_init() when
the hotplug range is unitialized. While doing that remove the memory
region based logic from this newly added helper.
This is the final step that allows pc_pci_hole64_start() to be callable
at the beginning of pc_memory_init() before any memory regions are
initialized.
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-9-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 1caab5cf86bdf02fa71079c4ca4a3c0748f39eb5
https://github.com/qemu/qemu/commit/1caab5cf86bdf02fa71079c4ca4a3c0748f39eb5
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: bounds check phys-bits against max used GPA
Calculate max *used* GPA against the CPU maximum possible address
and error out if the former surprasses the latter. This ensures
max used GPA is reacheable by configured phys-bits. Default phys-bits
on Qemu is TCG_PHYS_ADDR_BITS (40) which is enough for the CPU to
address 1Tb (0xff ffff ffff) or 1010G (0xfc ffff ffff) in AMD hosts
with IOMMU.
This is preparation for AMD guests with >1010G, where it will want relocate
ram-above-4g to be after 1Tb instead of 4G.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-10-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: 8504f129450b909c88e199ca44facd35d38ba4de
https://github.com/qemu/qemu/commit/8504f129450b909c88e199ca44facd35d38ba4de
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
i386/pc: relocate 4g start to 1T where applicable
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 is attempted and the CPU wasn't configured
with a big enough phys-bits, an error message will be printed
due to the maxphysaddr vs maxusedaddr check previously added.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20220719170014.27028-11-joao.m.martins@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: b3e6982b4154c1c0ab8b25f2e1ac7838a1809824
https://github.com/qemu/qemu/commit/b3e6982b4154c1c0ab8b25f2e1ac7838a1809824
Author: Joao Martins <joao.m.martins@oracle.com>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M include/hw/i386/pc.h
Log Message:
-----------
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>
Commit: 0522be9a0c0094088ccef7aab352c57f483ca250
https://github.com/qemu/qemu/commit/0522be9a0c0094088ccef7aab352c57f483ca250
Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/virtio/virtio-iommu.c
Log Message:
-----------
hw/virtio/virtio-iommu: Enforce power-of-two notify for both MAP and UNMAP
Currently we only enforce power-of-two mappings (required by the QEMU
notifier) for UNMAP requests. A MAP request not aligned on a
power-of-two may be successfully handled by VFIO, and then the
corresponding UNMAP notify will fail because it will attempt to split
that mapping. Ensure MAP and UNMAP notifications are consistent.
Fixes: dde3f08b5cab ("virtio-iommu: Handle non power of 2 range invalidations")
Reported-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Message-Id: <20220718135636.338264-1-jean-philippe@linaro.org>
Tested-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit: e5b6555fb8e8a91dd1d612e2e2d66bf5f43ad1dd
https://github.com/qemu/qemu/commit/e5b6555fb8e8a91dd1d612e2e2d66bf5f43ad1dd
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2022-07-26 (Tue, 26 Jul 2022)
Changed paths:
M hw/acpi/nvdimm.c
M hw/acpi/trace-events
M hw/i386/acpi-build.c
M hw/i386/pc.c
M hw/i386/pc_piix.c
M hw/i386/pc_q35.c
M hw/i386/sgx.c
M hw/i386/x86.c
M hw/pci-host/i440fx.c
M hw/virtio/virtio-iommu.c
M include/hw/boards.h
M include/hw/cxl/cxl_component.h
M include/hw/i386/pc.h
M include/hw/i386/x86.h
M include/hw/mem/nvdimm.h
M include/hw/pci-host/i440fx.h
Log Message:
-----------
Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu
into staging
pc,virtio: fixes
Several fixes. From now on, regression fixes only.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmLgQr8PHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpGUUIAKtNhrnKopGm4LlRpx8zN3Jc1Jo0nb648gaM
# Oyi+Pl8+hpESUhaWN10XDk38/QuPQfIFeR2ZhfYjFTRlZE+n3X9LVlwL8ejjP8KH
# AcWm78Ff/SLA45aMKMmw74pvEDNsoPYTp7TrfeIej5ub8BIXr8+8pqDdIR9WwtWO
# PbhLNXkTT2yLEs6jCVT4/dyh7zivSkrY7G/RVmtUaFe3PgY8fdW2z3+Txz7UIMgw
# CQoGuAucCO5ToBbs2CbT0V5yxY6G5VO6Qd8g0PzDW4M6GsY/Xr5QCnyJe0jTW0d6
# Dcc7UZFAzGNzyQCxHCic9xwTO+ZcJPJlH5TwknunxOb9xwCx4Qs=
# =zN41
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 26 Jul 2022 12:38:39 PM PDT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu:
hw/virtio/virtio-iommu: Enforce power-of-two notify for both MAP and UNMAP
i386/pc: restrict AMD only enforcing of 1Tb hole to new machine type
i386/pc: relocate 4g start to 1T where applicable
i386/pc: bounds check phys-bits against max used GPA
i386/pc: factor out device_memory base/size to helper
i386/pc: handle unitialized mr in pc_get_cxl_range_end()
i386/pc: factor out cxl range start to helper
i386/pc: factor out cxl range end to helper
i386/pc: factor out above-4g end to an helper
i386/pc: pass pci_hole64_size to pc_memory_init()
i386/pc: create pci-host qdev prior to pc_memory_init()
hw/i386: add 4g boundary start to X86MachineState
hw/cxl: Fix size of constant in interleave granularity function.
hw/i386/pc: Always place CXL Memory Regions after device_memory
hw/machine: Clear out left over CXL related pointer from move of state
handling to machines.
acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Compare: https://github.com/qemu/qemu/compare/f6cce6bcb2ef...e5b6555fb8e8
- [Qemu-commits] [qemu/qemu] e4bcec: acpi/nvdimm: Define trace events for NVDIMM and su...,
Richard Henderson <=