aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-07-10hw/pci/pci: Remove multifunction parameter from pci_new_multifunction()Bernhard Beschow
There is also pci_new() which creates non-multifunction PCI devices. Accordingly the parameter is always set to true when a multi function PCI device is to be created. The reason for the parameter's existence seems to be that it is used in the internal PCI code as well which is the only location where it gets set to false. This one usage can be resolved by factoring out an internal helper function. Remove this redundant, error-prone parameter. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230304114043.121024-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci/pci: Remove multifunction parameter from ↵Bernhard Beschow
pci_create_simple_multifunction() There is also pci_create_simple() which creates non-multifunction PCI devices. Accordingly the parameter is always set to true when a multi function PCI device is to be created. The reason for the parameter's existence seems to be that it is used in the internal PCI code as well which is the only location where it gets set to false. This one usage can be replaced by trivial code. Remove this redundant, error-prone parameter. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230304114043.121024-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_piix: Move i440fx' realize near its qdev_new()Bernhard Beschow
I440FX realization is currently mixed with PIIX3 creation. Furthermore, it is common practice to only set properties between a device's qdev_new() and qdev_realize(). Clean up to resolve both issues. Since I440FX spawns a PCI bus let's also move the pci_bus initialization there. Note that when running `qemu-system-x86_64 -M pc -S` before and after this patch, `info mtree` in the QEMU console doesn't show any differences except that the ordering is different. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-18-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Resolve i440fx_init()Bernhard Beschow
i440fx_init() is a legacy init function. The previous patches worked towards TYPE_I440FX_PCI_HOST_BRIDGE to be instantiated the QOM way. Do this now by transforming the parameters passed to i440fx_init() into property assignments. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-17-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-07-10hw/pci-host/i440fx: Add I440FX_HOST_PROP_PCI_TYPE propertyBernhard Beschow
I440FX needs a different PCI device model if the "igd-passthru" property is enabled. The type name is currently passed as a parameter to i440fx_init(). This parameter will be replaced by a property assignment once i440fx_init() gets resolved. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-16-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Add PCI_HOST_{ABOVE, BELOW}_4G_MEM_SIZE propertiesBernhard Beschow
Introduce the properties in anticipation of QOM'ification; Q35 has the same properties. Note that we want to avoid a "ram size" property in the QOM interface since it seems redundant to both properties introduced in this change. Thus the removal of the ram_size parameter. We assume the invariant of both properties to sum up to "ram size" which is already asserted in pc_memory_init(). Under Xen the invariant seems to hold as well, so we now also check it there. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-15-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Add PCI_HOST_PROP_IO_MEM propertyBernhard Beschow
Introduce the property in anticipation of QOM'ification; Q35 has the same property. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-14-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Make MemoryRegion pointers accessible as propertiesBernhard Beschow
The goal is to eliminate i440fx_init() which is a legacy init function. This neccessitates the memory regions to be properties, like in Q35, which will be assigned in board code. Since i440fx needs different PCI devices in Xen mode, and since i440fx shall be self-contained, the PCI device will be created during realization of the host. Thus the pointers need to be moved to the host structure to be usable as properties. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-13-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Move i440fx_realize() into PCII440FXState sectionBernhard Beschow
i440fx_realize() realizes the PCI device inside the host bridge (PCII440FXState), but is implemented between i440fx_pcihost_realize() and i440fx_init() which deal with the host bridge itself (I440FXState). Since we want to append i440fx_init() to i440fx_pcihost_realize() later let's move i440fx_realize() out of the way. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-12-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Have common names for some local variablesBernhard Beschow
`PCIHostState` is often referred to as `phb`, own device state usually as `s`. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-11-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Replace magic values by existing constantsBernhard Beschow
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-10-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Add "i440fx" child property in board codeBernhard Beschow
The parent-child relation is usually established near a child's qdev_new(). For i440fx this allows for reusing the machine parameter, thus avoiding qdev_get_machine() which relies on a global variable. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-9-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_piix: Turn some local variables into initializersBernhard Beschow
Eliminates an else branch. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-8-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Make some property name macros reusable by i440fxBernhard Beschow
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCI_HOST_BYPASS_IOMMU property from board codeBernhard Beschow
The Q35 PCI host already has a PCI_HOST_BYPASS_IOMMU property. However, the host initializes this property itself by accessing global machine state, thereby assuming it to be a PC machine. Avoid this by having board code set this property. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci/pci_host: Introduce PCI_HOST_BYPASS_IOMMU macroBernhard Beschow
Introduce a macro to avoid copy and pasting strings which can easily cause typos. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230630073720.21297-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCMachineState::bus in board codeBernhard Beschow
The Q35 PCI host currently sets the PC machine's PCI bus attribute through global state, thereby assuming the machine to be a PC machine. The Q35 machine code already holds on to Q35's pci bus attribute, so can easily set its own property while preserving encapsulation. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Fix double, contradicting .endianness assignmentBernhard Beschow
Fixes the following clangd warning (-Winitializer-overrides): q35.c:297:19: Initializer overrides prior initialization of this subobject q35.c:292:19: previous initialization is here Settle on little endian which is consistent with using pci_host_conf_le_ops. Fixes: bafc90bdc594 ("q35: implement TSEG") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_q35: Resolve redundant q35_host variableBernhard Beschow
The variable is redundant to "phb" and is never used by its real type. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10vhost-user: Make RESET_DEVICE a per device messageTom Lonergan
A device reset is issued per device, not per VQ. The legacy device reset message, VHOST_USER_RESET_OWNER, is already a per device message. Therefore, this change adds the proper message, VHOST_USER_RESET_DEVICE, to per device messages. Signed-off-by: Tom Lonergan <tom.lonergan@nutanix.com> Message-Id: <20230628163927.108171-3-tom.lonergan@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2023-07-10vhost-user: Change one_time to per_device requestTom Lonergan
Some devices, like virtio-scsi, consist of one vhost_dev, while others, like virtio-net, contain multiple vhost_devs. The QEMU vhost-user code has a concept of one-time messages which is misleading. One-time messages are sent once per operation on the device, not once for the lifetime of the device. Therefore, as discussed in [1], vhost_user_one_time_request should be renamed to vhost_user_per_device_request and the relevant comments updated to match the real functionality. [1] https://lore.kernel.org/qemu-devel/20230127083027-mutt-send-email-mst@kernel.org/ Signed-off-by: Tom Lonergan <tom.lonergan@nutanix.com> Message-Id: <20230628163927.108171-2-tom.lonergan@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2023-07-10hw/smbios: Fix core count in type4Zhao Liu
>From SMBIOS 3.0 specification, core count field means: Core Count is the number of cores detected by the BIOS for this processor socket. [1] Before 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology"), MachineState.smp.cores means "the number of cores in one package", and it's correct to use smp.cores for core count. But 003f230e37d7 changes the smp.cores' meaning to "the number of cores in one die" and doesn't change the original smp.cores' use in smbios as well, which makes core count in type4 go wrong. Fix this issue with the correct "cores per socket" caculation. [1] SMBIOS 3.0.0, section 7.5.6, Processor Information - Core Count Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/smbios: Fix thread count in type4Zhao Liu
>From SMBIOS 3.0 specification, thread count field means: Thread Count is the total number of threads detected by the BIOS for this processor socket. It is a processor-wide count, not a thread-per-core count. [1] So here we should use threads per socket other than threads per core. [1] SMBIOS 3.0.0, section 7.5.8, Processor Information - Thread Count Fixes: c97294ec1b9e ("SMBIOS: Build aggregate smbios tables and entry point") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-4-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/smbios: Fix smbios_smp_sockets caculationZhao Liu
smp.sockets is the number of sockets which is configured by "-smp" ( otherwise, the default is 1). Trying to recalculate it here with another rules leads to errors, such as: 1. 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") changes the meaning of smp.cores but doesn't fix original smp.cores uses. With the introduction of cluster, now smp.cores means the number of cores in one cluster. So smp.cores * smp.threads just means the threads in a cluster not in a socket. 2. On the other hand, we shouldn't use smp.cpus here because it indicates the initial number of online CPUs at the boot time, and is not mathematically related to smp.sockets. So stop reinventing the another wheel and use the topo values that has been calculated. Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-3-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10machine: Add helpers to get cores/threads per socketZhao Liu
The number of cores/threads per socket are needed for smbios, and are also useful for other modules. Provide the helpers to wrap the calculation of cores/threads per socket so that we can avoid calculation errors caused by other modules miss topology changes. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-2-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10tests/qtest: enable tests for virtio-scmiMilan Zamazal
We don't have a virtio-scmi implementation in QEMU and only support a vhost-user backend. This is very similar to virtio-gpio and we add the same set of tests, just passing some vhost-user messages over the control socket. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230628100524.342666-4-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/virtio: Add vhost-user-scmi-pci boilerplateMilan Zamazal
This allows is to instantiate a vhost-user-scmi device as part of a PCI bus. It is mostly boilerplate similar to the other vhost-user-*-pci boilerplates of similar devices. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Message-Id: <20230628100524.342666-3-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/virtio: Add boilerplate for vhost-user-scmi deviceMilan Zamazal
This creates the QEMU side of the vhost-user-scmi device which connects to the remote daemon. It is based on code of similar vhost-user devices. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Message-Id: <20230628100524.342666-2-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10vhost-user-gpu: implement get_edid frontend featureErico Nunes
Implement the frontend side of the get_edid feature in the qemu vhost-user-gpu frontend device. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230626164708.1163239-5-ernunes@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10contrib/vhost-user-gpu: implement get_edid featureErico Nunes
Implement the virtio-gpu feature in contrib/vhost-user-gpu, which was unsupported until now. In this implementation, the feature is enabled inconditionally to avoid creating another optional config argument. Similarly to get_display_info, vhost-user-gpu sends a message back to the frontend to have access to all the display information. In the case of get_edid, it also needs to pass which scanout we should retrieve the edid for. The VHOST_USER_GPU_PROTOCOL_F_EDID protocol feature is required if the frontend sets the VIRTIO_GPU_F_EDID virtio-gpu feature. If the frontend sets the virtio-gpu feature but does not support the protocol feature, the backend will abort with an error. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230626164708.1163239-4-ernunes@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10docs: vhost-user-gpu: add protocol changes for EDIDErico Nunes
VHOST_USER_GPU_GET_EDID is defined as a message from the backend to the frontend to retrieve the EDID data for a given scanout. The VHOST_USER_GPU_PROTOCOL_F_EDID protocol feature is defined as a way to check whether this new message is supported or not. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230626164708.1163239-3-ernunes@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10virtio-gpu: refactor generate_edid function to virtio_gpu_baseErico Nunes
This functionality can be shared with upcoming use in vhost-user-gpu, so move it to the shared file to avoid duplicating it. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230626164708.1163239-2-ernunes@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10virtio-net: pass Device-TLB enable/disable events to vhostViktor Prutyanov
If vhost is enabled for virtio-net, Device-TLB enable/disable events must be passed to vhost for proper IOMMU unmap flag selection. Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230626091258.24453-3-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10vhost: register and change IOMMU flag depending on Device-TLB stateViktor Prutyanov
The guest can disable or never enable Device-TLB. In these cases, it can't be used even if enabled in QEMU. So, check Device-TLB state before registering IOMMU notifier and select unmap flag depending on that. Also, implement a way to change IOMMU notifier flag if Device-TLB state is changed. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2001312 Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230626091258.24453-2-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10vdpa: Remove status in reset tracingEugenio Pérez
It is always 0 and it is not useful to route call through file descriptor. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230526153736.472443-1-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10Merge tag 'pull-vfio-20230710' of https://github.com/legoater/qemu into stagingRichard Henderson
vfio queue: * Fixes in error handling paths of VFIO PCI devices * Improvements of reported errors for VFIO migration * Linux header update * Enablement of AtomicOps completers on root ports * Fix for unplug of passthrough AP devices # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmSrug0ACgkQUaNDx8/7 # 7KHYCRAAt6UeZi8nKPlN+cs6guOagCcAJOu13nm7XN0bFxjYf/Q2t618cpM7PLSk # h+4VGsMUVJ1dumcCkBmv7LAn0G6CpVR3VDi5QuGfMODRhpWfSoaypPIizRgrbarL # lSyaVaPIaddlDZ4AIfFA9Ebnytvm5/ecsyTr0cv7OejVKWI/jN6bC/v36AmNQKKQ # J5RCDpQ6fOsdqf0Dzvn7xjuHRE4DYtsWkVoslDoBQMgPWHLF8UwRu/OPD6cBQYAR # /fmgoOkkNDMdN3laqwAyfAUjKfOFpLuZzJ5KNFjtkBiktm66dw4Y8/lWoChVR+S6 # PRZ3nk0HxyzB96zCytfggBX905PBD54LIuockRaYKTlTxT19C3fDjDz5tsjKNhLR # aFec4KiJaUJj0fa/Vw8DB/WUbCgbOXGHiWhY8vNdpVoc9AZe8xj9z4nB3hmzx1i/ # lZhsM/s3kTNHpVGlW7vTfbToFBmt1eoglu+ILe/HeHLi8LjzCsHy+wR5c0n0/HVI # fLUuUS1AGQvi8+HCCUi7gwzpJkl4rPJsPx51wfXJk+q/3GQ8g9Mg9qotHNHm4N60 # zq/I5VqqEkJzdaMjup04ZqsMAWqGrnU2f4aNPvBhgaeO9CQE/buIsA34buQRwiG4 # wTodqm0jrkx0Z59jliZ0mFU/LxMvhMaQCEh+OdyZ9vRtfLBjF4c= # =U2Hc # -----END PGP SIGNATURE----- # gpg: Signature made Mon 10 Jul 2023 08:58:05 AM BST # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [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: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-vfio-20230710' of https://github.com/legoater/qemu: vfio/pci: Enable AtomicOps completers on root ports pcie: Add a PCIe capability version helper s390x/ap: Wire up the device request notifier interface linux-headers: update to v6.5-rc1 vfio: Fix null pointer dereference bug in vfio_bars_finalize() vfio/migration: Return bool type for vfio_migration_realize() vfio/migration: Remove print of "Migration disabled" vfio/migration: Free resources when vfio_migration_realize fails vfio/migration: Change vIOMMU blocker from global to per device vfio/pci: Disable INTx in vfio_realize error path hw/vfio/pci-quirks: Sanitize capability pointer Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-07-10vfio/pci: Enable AtomicOps completers on root portsAlex Williamson
Dynamically enable Atomic Ops completer support around realize/exit of vfio-pci devices reporting host support for these accesses and adhering to a minimal configuration standard. While the Atomic Ops completer bits in the root port device capabilities2 register are read-only, the PCIe spec does allow RO bits to change to reflect hardware state. We take advantage of that here around the realize and exit functions of the vfio-pci device. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Robin Voetter <robin@streamhpc.com> Tested-by: Robin Voetter <robin@streamhpc.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10pcie: Add a PCIe capability version helperAlex Williamson
Report the PCIe capability version for a device Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Robin Voetter <robin@streamhpc.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10s390x/ap: Wire up the device request notifier interfaceTony Krowiak
Let's wire up the device request notifier interface to handle device unplug requests for AP. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20230530225544.280031-1-akrowiak@linux.ibm.com/ Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10linux-headers: update to v6.5-rc1Cédric Le Goater
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio: Fix null pointer dereference bug in vfio_bars_finalize()Avihai Horon
vfio_realize() has the following flow: 1. vfio_bars_prepare() -- sets VFIOBAR->size. 2. msix_early_setup(). 3. vfio_bars_register() -- allocates VFIOBAR->mr. After vfio_bars_prepare() is called msix_early_setup() can fail. If it does fail, vfio_bars_register() is never called and VFIOBAR->mr is not allocated. In this case, vfio_bars_finalize() is called as part of the error flow to free the bars' resources. However, vfio_bars_finalize() calls object_unparent() for VFIOBAR->mr after checking only VFIOBAR->size, and thus we get a null pointer dereference. Fix it by checking VFIOBAR->mr in vfio_bars_finalize(). Fixes: 89d5202edc50 ("vfio/pci: Allow relocating MSI-X MMIO") Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio/migration: Return bool type for vfio_migration_realize()Zhenzhong Duan
Make vfio_migration_realize() adhere to the convention of other realize() callbacks(like qdev_realize) by returning bool instead of int. Suggested-by: Cédric Le Goater <clg@redhat.com> Suggested-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio/migration: Remove print of "Migration disabled"Zhenzhong Duan
Property enable_migration supports [on/off/auto]. In ON mode, error pointer is passed to errp and logged. In OFF mode, we doesn't need to log "Migration disabled" as it's intentional. In AUTO mode, we should only ever see errors or warnings if the device supports migration and an error or incompatibility occurs while further probing or configuring it. Lack of support for migration shoundn't generate an error or warning. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio/migration: Free resources when vfio_migration_realize failsZhenzhong Duan
When vfio_realize() succeeds, hot unplug will call vfio_exitfn() to free resources allocated in vfio_realize(); when vfio_realize() fails, vfio_exitfn() is never called and we need to free resources in vfio_realize(). In the case that vfio_migration_realize() fails, e.g: with -only-migratable & enable-migration=off, we see below: (qemu) device_add vfio-pci,host=81:11.1,id=vfio1,bus=root1,enable-migration=off 0000:81:11.1: Migration disabled Error: disallowing migration blocker (--only-migratable) for: 0000:81:11.1: Migration is disabled for VFIO device If we hotplug again we should see same log as above, but we see: (qemu) device_add vfio-pci,host=81:11.1,id=vfio1,bus=root1,enable-migration=off Error: vfio 0000:81:11.1: device is already attached That's because some references to VFIO device isn't released. For resources allocated in vfio_migration_realize(), free them by jumping to out_deinit path with calling a new function vfio_migration_deinit(). For resources allocated in vfio_realize(), free them by jumping to de-register path in vfio_realize(). Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Fixes: a22651053b59 ("vfio: Make vfio-pci device migration capable") Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio/migration: Change vIOMMU blocker from global to per deviceZhenzhong Duan
Contrary to multiple device blocker which needs to consider already-attached devices to unblock/block dynamically, the vIOMMU migration blocker is a device specific config. Meaning it only needs to know whether the device is bypassing or not the vIOMMU (via machine property, or per pxb-pcie::bypass_iommu), and does not need the state of currently present devices. For this reason, the vIOMMU global migration blocker can be consolidated into the per-device migration blocker, allowing us to remove some unnecessary code. This change also makes vfio_mig_active() more accurate as it doesn't check for global blocker. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10vfio/pci: Disable INTx in vfio_realize error pathZhenzhong Duan
When vfio realize fails, INTx isn't disabled if it has been enabled. This may confuse host side with unhandled interrupt report. Fixes: c5478fea27ac ("vfio/pci: Respond to KVM irqchip change notifier") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-10hw/vfio/pci-quirks: Sanitize capability pointerAlex Williamson
Coverity reports a tained scalar when traversing the capabilities chain (CID 1516589). In practice I've never seen a device with a chain so broken as to cause an issue, but it's also pretty easy to sanitize. Fixes: f6b30c1984f7 ("hw/vfio/pci-quirks: Support alternate offset for GPUDirect Cliques") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2023-07-09Merge tag 'pull-tcg-20230709' of https://gitlab.com/rth7680/qemu into stagingRichard Henderson
crypto: Provide aes-round.h and host accel # -----BEGIN PGP SIGNATURE----- # # iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmSqvGodHHJpY2hhcmQu # aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV+1bgf9EG57jfnCQLCfMQ6C # 0bQ0MaeAkGg+7+mUwyi3OPB1VO0yjEKv5pWEnolzrGud35P0KsyoO+msqGqxnbMv # IbhPkQZbmfMsGFPG1DbswjiwmQU5cV+ciONDM+C+qepnuUN+JrzIDHoEFzQRFoQo # eQL/LnuyUkYBvR7YCKNJxFHtwILKcYQPH4jiC6a92C11AzYjDfilSxnuQ2RwL3Tn # Zwf8TKJP5QGExvUdtm8f6xJ1LT7WAvsk9ZTwudE/+XRTnw8RWk6RmZSEQPx+cBdI # p3opaoxkkMrdmcaXbr+9eSfBGq2gsVkKYPiyTDuwVW26575Nob9ZmodT3oSBNlkC # +njd4w== # =Nf5i # -----END PGP SIGNATURE----- # gpg: Signature made Sun 09 Jul 2023 02:55:54 PM BST # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate] * tag 'pull-tcg-20230709' of https://gitlab.com/rth7680/qemu: (37 commits) crypto: Unexport AES_*_rot, AES_TeN, AES_TdN crypto: Remove AES_imc crypto: Implement aesdec_IMC with AES_imc_rot crypto: Remove AES_shifts, AES_ishifts target/riscv: Use aesdec_ISB_ISR_IMC_AK target/riscv: Use aesenc_SB_SR_MC_AK target/riscv: Use aesdec_IMC target/riscv: Use aesdec_ISB_ISR_AK target/riscv: Use aesenc_SB_SR_AK target/arm: Use aesdec_IMC target/arm: Use aesenc_MC target/arm: Use aesdec_ISB_ISR_AK target/arm: Use aesenc_SB_SR_AK target/arm: Demultiplex AESE and AESMC target/i386: Use aesdec_ISB_ISR_IMC_AK target/i386: Use aesenc_SB_SR_MC_AK target/i386: Use aesdec_IMC target/i386: Use aesdec_ISB_ISR_AK target/i386: Use aesenc_SB_SR_AK target/ppc: Use aesdec_ISB_ISR_AK_IMC ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-07-09Merge tag 'linux-user-fcntl64-pull-request' of ↵Richard Henderson
https://github.com/hdeller/qemu-hppa into staging linux-user: Fix fcntl64() and accept4() for 32-bit targets A set of 3 patches: The first two patches fix fcntl64() and accept4(). the 3rd patch enhances the strace output for pread64/pwrite64(). This pull request does not includes Richard's mmap2 patch: https://patchew.org/QEMU/20230630132159.376995-1-richard.henderson@linaro.org/20230630132159.376995-12-richard.henderson@linaro.org/ Changes: v3: - added r-b from Richard to patches #1 and #2 v2: - rephrased commmit logs - return O_LARGFILE for fcntl() syscall too - dropped #ifdefs in accept4() patch - Dropped my mmap2() patch (former patch #3) - added r-b from Richard to 3rd patch Helge # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZKl5RQAKCRD3ErUQojoP # X82sAQDnW53s7YkU4sZ1YREPWPVoCXZXgm587jTrmwT4v9AenQEAlbKdsw4hzzr/ # ptuKvgZfZaIp5QjBUl/Dh/CI5aVOLgc= # =hd4O # -----END PGP SIGNATURE----- # gpg: Signature made Sat 08 Jul 2023 03:57:09 PM BST # gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F # gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown] # gpg: aka "Helge Deller <deller@kernel.org>" [unknown] # 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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603 # Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F * tag 'linux-user-fcntl64-pull-request' of https://github.com/hdeller/qemu-hppa: linux-user: Improve strace output of pread64() and pwrite64() linux-user: Fix accept4(SOCK_NONBLOCK) syscall linux-user: Fix fcntl() and fcntl64() to return O_LARGEFILE for 32-bit targets Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-07-09crypto: Unexport AES_*_rot, AES_TeN, AES_TdNRichard Henderson
These arrays are no longer used outside of aes.c. Acked-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-23 23:34:22 +0000