294cbbf1 | 23-Feb-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/mem/cxl_type3: Fix missing ERRP_GUARD() in ct3_realize()
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUA
hw/mem/cxl_type3: Fix missing ERRP_GUARD() in ct3_realize()
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code.
But in ct3_realize(), @errp is dereferenced without ERRP_GUARD():
cxl_doe_cdat_init(cxl_cstate, errp); if (*errp) { goto err_free_special_ops; }
Here we check *errp, because cxl_doe_cdat_init() returns void. And ct3_realize() - as a PCIDeviceClass.realize() method - doesn't get the NULL @errp parameter, it hasn't triggered the bug that dereferencing the NULL @errp.
To follow the requirement of @errp, add missing ERRP_GUARD() in ct3_realize().
Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240223085653.1255438-4-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
004e3a93 | 23-Oct-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/cxl: Add tunneled command support to mailbox for switch cci.
This implementation of tunneling makes the choice that our Type 3 device is a Logical Device (LD) of a Multi-Logical Device (MLD) that
hw/cxl: Add tunneled command support to mailbox for switch cci.
This implementation of tunneling makes the choice that our Type 3 device is a Logical Device (LD) of a Multi-Logical Device (MLD) that just happens to only have one LD for now.
Tunneling is supported from a Switch Mailbox CCI (and shortly via MCTP over I2C connected to the switch MCTP CCI) via an outer level to the FM owned LD in the MLD Type 3 device. From there an inner tunnel may be used to access particular LDs.
Protocol wise, the following is what happens in a real system but we don't emulate the transports - just the destinations and the payloads.
( Host -> Switch Mailbox CCI - in band FM-API mailbox command or Host -> Switch MCTP CCI - MCTP over I2C using the CXL FM-API MCTP Binding. ) then (if a tunnel command) Switch -> Type 3 FM Owned LD - MCTP over PCI VDM using the CXL FM-API binding (addressed by switch port) then (if unwrapped command also a tunnel command) Type 3 FM Owned LD to LD0 via internal transport (addressed by LD number)
or (added shortly)
Host to Type 3 FM Owned MCTP CCI - MCTP over I2C using the CXL FM-API MCTP Binding. then (if unwrapped comand is a tunnel comamnd) Type 3 FM Owned LD to LD0 via internal transport. (addressed by LD number)
It is worth noting that the tunneling commands over PCI VDM presumably use the appropriate MCTP binding depending on opcode. This may be the CXL FMAPI binding or the CXL Memory Device Binding.
Additional commands will need to be added to make this useful beyond testing the tunneling works.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-18-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
ede604d5 | 23-Oct-2023 |
Gregory Price <gourry.memverge@gmail.com> |
hw/cxl/type3: Cleanup multiple CXL_TYPE3() calls in read/write functions
Call CXL_TYPE3 once at top of function to avoid multiple invocations.
Signed-off-by: Gregory Price <gregory.price@memverge.c
hw/cxl/type3: Cleanup multiple CXL_TYPE3() calls in read/write functions
Call CXL_TYPE3 once at top of function to avoid multiple invocations.
Signed-off-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20231023160806.13206-16-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
25a52959 | 23-Oct-2023 |
Davidlohr Bueso <dave@stgolabs.net> |
hw/cxl: Add support for device sanitation
Make use of the background operations through the sanitize command, per CXL 3.0 specs. Traditionally run times can be rather long, depending on the size of
hw/cxl: Add support for device sanitation
Make use of the background operations through the sanitize command, per CXL 3.0 specs. Traditionally run times can be rather long, depending on the size of the media.
Estimate times based on: https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20231023160806.13206-14-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
cac36a8f | 23-Oct-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/cxl/mbox: Pull the CCI definition out of the CXLDeviceState
Enables having multiple CCIs per devices. Each CCI (mailbox) has it's own state and command list, so they can't share a single structur
hw/cxl/mbox: Pull the CCI definition out of the CXLDeviceState
Enables having multiple CCIs per devices. Each CCI (mailbox) has it's own state and command list, so they can't share a single structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-4-Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
eb1b7c4b | 22-Jun-2023 |
David Hildenbrand <david@redhat.com> |
memory-device: Drop size alignment check
There is no strong requirement that the size has to be multiples of the requested alignment, let's drop it. This is a preparation for hv-baloon.
Signed-off-
memory-device: Drop size alignment check
There is no strong requirement that the size has to be multiples of the requested alignment, let's drop it. This is a preparation for hv-baloon.
Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
show more ...
|
a2335113 | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device,vhost: Support automatic decision on the number of memslots
We want to support memory devices that can automatically decide how many memslots they will use. In the worst case, they hav
memory-device,vhost: Support automatic decision on the number of memslots
We want to support memory devices that can automatically decide how many memslots they will use. In the worst case, they have to use a single memslot.
The target use cases are virtio-mem and the hyper-v balloon.
Let's calculate a reasonable limit such a memory device may use, and instruct the device to make a decision based on that limit. Use a simple heuristic that considers: * A memslot soft-limit for all memory devices of 256; also, to not consume too many memslots -- which could harm performance. * Actually still free and unreserved memslots * The percentage of the remaining device memory region that memory device will occupy.
Further, while we properly check before plugging a memory device whether there still is are free memslots, we have other memslot consumers (such as boot memory, PCI BARs) that don't perform any checks and might dynamically consume memslots without any prior reservation. So we might succeed in plugging a memory device, but once we dynamically map a PCI BAR we would be in trouble. Doing accounting / reservation / checks for all such users is problematic (e.g., sometimes we might temporarily split boot memory into two memslots, triggered by the BIOS).
We use the historic magic memslot number of 509 as orientation to when supporting 256 memory devices -> memslots (leaving 253 for boot memory and other devices) has been proven to work reliable. We'll fallback to suggesting a single memslot if we don't have at least 509 total memslots.
Plugging vhost devices with less than 509 memslots available while we have memory devices plugged that consume multiple memslots due to automatic decisions can be problematic. Most configurations might just fail due to "limit < used + reserved", however, it can also happen that these memory devices would suddenly consume memslots that would actually be required by other memslot consumers (boot, PCI BARs) later. Note that this has always been sketchy with vhost devices that support only a small number of memslots; but we don't want to make it any worse.So let's keep it simple and simply reject plugging such vhost devices in such a configuration.
Eventually, all vhost devices that want to be fully compatible with such memory devices should support a decent number of memslots (>= 509).
Message-ID: <20230926185738.277351-13-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
766aa0a6 | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device,vhost: Support memory devices that dynamically consume memslots
We want to support memory devices that have a dynamically managed memory region container as device memory region. This
memory-device,vhost: Support memory devices that dynamically consume memslots
We want to support memory devices that have a dynamically managed memory region container as device memory region. This device memory region maps multiple RAM memory subregions (e.g., aliases to the same RAM memory region), whereby these subregions can be (un)mapped on demand.
Each RAM subregion will consume a memslot in KVM and vhost, resulting in such a new device consuming memslots dynamically, and initially usually 0. We already track the number of used vs. required memslots for all memslots. From that, we can derive the number of reserved memslots that must not be used otherwise.
The target use case is virtio-mem and the hyper-v balloon, which will dynamically map aliases to RAM memory region into their device memory region container.
Properly document what's supported and what's not and extend the vhost memslot check accordingly.
Message-ID: <20230926185738.277351-10-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
f9716f4b | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device: Track required and actually used memslots in DeviceMemoryState
Let's track how many memslots are required by plugged memory devices and how many are currently actually getting used by
memory-device: Track required and actually used memslots in DeviceMemoryState
Let's track how many memslots are required by plugged memory devices and how many are currently actually getting used by plugged memory devices.
"required - used" is the number of reserved memslots. For now, the number of used and required memslots is always equal, and there are no reservations. This is a preparation for memory devices that want to dynamically consume memslots after initially specifying how many they require -- where we'll end up with reserved memslots.
To track the number of used memslots, create a new address space for our device memory and register a memory listener (add/remove) for that address space.
Message-ID: <20230926185738.277351-9-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
7975feec | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device: Support memory devices with multiple memslots
We want to support memory devices that have a memory region container as device memory region that maps multiple RAM memory regions. Let'
memory-device: Support memory devices with multiple memslots
We want to support memory devices that have a memory region container as device memory region that maps multiple RAM memory regions. Let's start by supporting memory devices that statically map multiple RAM memory regions and, thereby, consume multiple memslots.
We already have one device that uses a container as device memory region: NVDIMMs. However, a NVDIMM always ends up consuming exactly one memslot.
Let's add support for that by asking the memory device via a new callback how many memslots it requires.
Message-ID: <20230926185738.277351-7-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
8c49951c | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
vhost: Return number of free memslots
Let's return the number of free slots instead of only checking if there is a free slot. Required to support memory devices that consume multiple memslots.
This
vhost: Return number of free memslots
Let's return the number of free slots instead of only checking if there is a free slot. Required to support memory devices that consume multiple memslots.
This is a preparation for memory devices that consume multiple memslots.
Message-ID: <20230926185738.277351-6-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
e967413f | 13-Sep-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/cxl: Support 4 HDM decoders at all levels of topology
Support these decoders in CXL host bridges (pxb-cxl), CXL Switch USP and CXL Type 3 end points.
Signed-off-by: Jonathan Cameron <Jonathan.Ca
hw/cxl: Support 4 HDM decoders at all levels of topology
Support these decoders in CXL host bridges (pxb-cxl), CXL Switch USP and CXL Type 3 end points.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20230913132523.29780-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|