From aff0c39c5bb5b45ebbf8f857cf8f546d4565f1bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Corvin=20K=C3=B6hne?= Date: Fri, 8 Nov 2024 13:48:30 +0100 Subject: vfio/igd: add pci id for Coffee Lake MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I've tested and verified that Coffee Lake devices are working properly. Signed-off-by: Corvin Köhne Reviewed-by: Alex Williamson --- hw/vfio/igd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c index a95d441f68..c5282827ec 100644 --- a/hw/vfio/igd.c +++ b/hw/vfio/igd.c @@ -88,6 +88,9 @@ static int igd_gen(VFIOPCIDevice *vdev) case 0x2200: case 0x5900: return 8; + /* CoffeeLake */ + case 0x3e00: + return 9; /* ElkhartLake */ case 0x4500: return 11; -- cgit v1.2.3 From 66650fd0cc67e11f84521a114a7cbc8a8a5033ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Corvin=20K=C3=B6hne?= Date: Fri, 8 Nov 2024 13:49:04 +0100 Subject: vfio/igd: fix calculation of graphics stolen memory MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When copying the calculation of the stolen memory size for Intels integrated graphics device of gen 9 and later from the Linux kernel [1], we missed subtracting 0xf0 from the graphics mode select value for values above 0xf0. This leads to QEMU reporting a very large size of the graphics stolen memory area. That's just a waste of memory. Additionally the guest firmware might be unable to allocate such a large buffer. [1] https://github.com/torvalds/linux/blob/7c626ce4bae1ac14f60076d00eafe71af30450ba/arch/x86/kernel/early-quirks.c#L455-L460 Signed-off-by: Corvin Köhne Reviewed-by: Philippe Mathieu-Daudé Fixes: 871922416683 ("vfio/igd: correctly calculate stolen memory size for gen 9 and later") Reviewed-by: Alex Williamson [ clg: Changed commit subject ] Signed-off-by: Cédric Le Goater --- hw/vfio/igd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c index c5282827ec..4047f4f071 100644 --- a/hw/vfio/igd.c +++ b/hw/vfio/igd.c @@ -501,7 +501,7 @@ static int igd_get_stolen_mb(int gen, uint32_t gmch) if (gms < 0xf0) return gms * 32; else - return gms * 4 + 4; + return (gms - 0xf0) * 4 + 4; } } -- cgit v1.2.3 From ebbf7c60bbd1ceedf9faf962e428ceda2388c248 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Date: Fri, 15 Nov 2024 09:34:40 +0100 Subject: vfio/container: Fix container object destruction MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When commit 96b7af4388b3 intoduced a .instance_finalize() handler, it did not take into account that the container was not necessarily inserted into the container list of the address space. Hence, if the container object is destroyed, by calling object_unref() for example, before vfio_address_space_insert() is called, QEMU may crash when removing the container from the list as done in vfio_container_instance_finalize(). This was seen with an SEV-SNP guest for which discarding of RAM fails. To resolve this issue, use the safe version of QLIST_REMOVE(). Cc: Zhenzhong Duan Cc: Eric Auger Fixes: 96b7af4388b3 ("vfio/container: Move vfio_container_destroy() to an instance_finalize() handler") Reviewed-by: Zhenzhong Duan Signed-off-by: Cédric Le Goater --- hw/vfio/container-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/container-base.c b/hw/vfio/container-base.c index 809b157674..6f86c37d97 100644 --- a/hw/vfio/container-base.c +++ b/hw/vfio/container-base.c @@ -103,7 +103,7 @@ static void vfio_container_instance_finalize(Object *obj) VFIOContainerBase *bcontainer = VFIO_IOMMU(obj); VFIOGuestIOMMU *giommu, *tmp; - QLIST_REMOVE(bcontainer, next); + QLIST_SAFE_REMOVE(bcontainer, next); QLIST_FOREACH_SAFE(giommu, &bcontainer->giommu_list, giommu_next, tmp) { memory_region_unregister_iommu_notifier( -- cgit v1.2.3