- Oct 06, 2023
-
-
Gurchetan Singh authored
This adds basic documentation for virtio-gpu. Suggested-by:
Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Tested-by:
Alyssa Ross <hi@alyssa.is> Tested-by:
Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Tested-by:
Antonio Caggiano <quic_acaggian@quicinc.com> Reviewed-by:
-
Gurchetan Singh authored
This change enables rutabaga to receive virtio-gpu-3d hypercalls when it is active. Signed-off-by:
-
Gurchetan Singh authored
- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present Signed-off-by:
-
Gurchetan Singh authored
This adds initial support for gfxstream and cross-domain. Both features rely on virtio-gpu blob resources and context types, which are also implemented in this patch. gfxstream has a long and illustrious history in Android graphics paravirtualization. It has been powering graphics in the Android Studio Emulator for more than a decade, which is the main developer platform. Originally conceived by Jesse Hall, it was first known as "EmuGL" [a]. The key design characteristic was a 1:1 threading model and auto-generation, which fit nicely with the OpenGLES spec. It also allowed easy layering with ANGLE on the host, which provides the GLES implementations on Windows or MacOS enviroments. gfxstream has traditionally been maintained by a single engineer, and between 2015 to 2021, the goldfish throne passed to Frank Yang. Historians often remark this glorious reign ("pax gfxstreama" is the academic term) was comparable to that of Augustus and both Queen Elizabeths. Just to name a few accomplishments in a resplendent panoply: higher versions of GLES, address space graphics, snapshot support and CTS compliant Vulkan [b]. One major drawback was the use of out-of-tree goldfish drivers. Android engineers didn't know much about DRM/KMS and especially TTM so a simple guest to host pipe was conceived. Luckily, virtio-gpu 3D started to emerge in 2016 due to the work of the Mesa/virglrenderer communities. In 2018, the initial virtio-gpu port of gfxstream was done by Cuttlefish enthusiast Alistair Delva. It was a symbol compatible replacement of virglrenderer [c] and named "AVDVirglrenderer". This implementation forms the basis of the current gfxstream host implementation still in use today. cross-domain support follows a similar arc. Originally conceived by Wayland aficionado David Reveman and crosvm enjoyer Zach Reizner in 2018, it initially relied on the downstream "virtio-wl" device. In 2020 and 2021, virtio-gpu was extended to include blob resources and multiple timelines by yours truly, features gfxstream/cross-domain both require to function correctly. Right now, we stand at the precipice of a truly fantastic possibility: the Android Emulator powered by upstream QEMU and upstream Linux kernel. gfxstream will then be packaged properfully, and app developers can even fix gfxstream bugs on their own if they encounter them. It's been quite the ride, my friends. Where will gfxstream head next, nobody really knows. I wouldn't be surprised if it's around for another decade, maintained by a new generation of Android graphics enthusiasts. Technical details: - Very simple initial display integration: just used Pixman - Largely, 1:1 mapping of virtio-gpu hypercalls to rutabaga function calls Next steps for Android VMs: - The next step would be improving display integration and UI interfaces with the goal of the QEMU upstream graphics being in an emulator release [d]. Next steps for Linux VMs for display virtualization: - For widespread distribution, someone needs to package Sommelier or the wayland-proxy-virtwl [e] ideally into Debian main. In addition, newer versions of the Linux kernel come with DRM_VIRTIO_GPU_KMS option, which allows disabling KMS hypercalls. If anyone cares enough, it'll probably be possible to build a custom VM variant that uses this display virtualization strategy. [a] https://android-review.googlesource.com/c/platform/development/+/34470 [b] https://android-review.googlesource.com/q/topic:%22vulkan-hostconnection-start%22 [c] https://android-review.googlesource.com/c/device/generic/goldfish-opengl/+/761927 [d] https://developer.android.com/studio/releases/emulator [e] https://github.com/talex5/wayland-proxy-virtwl Signed-off-by: -
Gurchetan Singh authored
This modifies the common virtio-gpu.h file have the fields and defintions needed by gfxstream/rutabaga, by VirtioGpuRutabaga. Signed-off-by:
-
Antonio Caggiano authored
This adds preparatory functions needed to: - decode blob cmds - tracking iovecs Signed-off-by:Antonio Caggiano <antonio.caggiano@collabora.com> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
Huang Rui <ray.huang@amd.com> Acked-by:
-
Gerd Hoffmann authored
Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
-
Antonio Caggiano authored
The feature can be enabled when a backend wants it. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
-
Dr. David Alan Gilbert authoredDefine a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow defining shared memory regions with sizes and offsets of 2^32 and more. Multiple instances of the capability are allowed and distinguished by a device-specific 'id'. Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
-
- Oct 05, 2023
-
-
https://git.kernel.org/pub/scm/virt/kvm/mst/qemuStefan Hajnoczi authoredvirtio,pci: features, cleanups vdpa: shadow vq vlan support net migration with cvq cxl: support emulating 4 HDM decoders serial number extended capability virtio: hared dma-buf Fixes, cleanups all over the place. Signed-off-by: -
https://gitlab.com/rth7680/qemuStefan Hajnoczi authored
accel: Introduce AccelClass::cpu_common_[un]realize accel: Target agnostic code movement accel/tcg: Cleanups to use CPUState instead of CPUArchState accel/tcg: Move CPUNegativeOffsetState into CPUState tcg: Split out tcg init functions to tcg/startup.h linux-user/hppa: Fix struct target_sigcontext layout build: Remove --enable-gprof # -----BEGIN PGP SIGNATURE----- # # iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmUdsL4dHHJpY2hhcmQu # aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/iYggAvDJEyMCAXSSH97BA # wZT/2D/MFIhOMk6xrQRnrXfrG70N0iVKz44jl9j7k1D+9BOHcso//DDJH3c96k9A # MgDb6W2bsWvC15/Qw6BALf5bb/II0MJuCcQvj3CNX5lNkXAWhwIOBhsZx7V9ST1+ # rihN4nowpRWdV5GeCjDGaJW455Y1gc96hICYHy6Eqw1cUgUFt9vm5aYU3FHlat29 # sYRaVYKUL2hRUPPNcPiPq0AaJ8wN6/s8gT+V1UvTzkhHqskoM4ZU89RchuXVoq1h # SvhKElyULMRzM7thWtpW8qYJPj4mxZsKArESvHjsunGD6KEz3Fh1sy6EKRcdmpG/ # II1vkg== # =k2Io # -----END PGP SIGNATURE----- # gpg: Signature made Wed 04 Oct 2023 14:36:46 EDT # g...
-
- Oct 04, 2023
-
-
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the virtio shared objects hash table. Signed-off-by:
Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-5-aesteve@redhat.com> Reviewed-by:
-
Add three new vhost-user protocol `VHOST_USER_BACKEND_SHARED_OBJECT_* messages`. These new messages are sent from vhost-user back-ends to interact with the virtio-dmabuf table in order to add or remove themselves as virtio exporters, or lookup for virtio dma-buf shared objects. The action taken in the front-end depends on the type stored in the virtio shared object hash table. When the table holds a pointer to a vhost backend for a given UUID, the front-end sends a VHOST_USER_GET_SHARED_OBJECT to the backend holding the shared object. The messages can only be sent after successfully negotiating a new VHOST_USER_PROTOCOL_F_SHARED_OBJECT vhost-user protocol feature bit. Finally, refactor code to send response message so that all common parts both for the common REPLY_ACK case, and other data responses, can call it and avoid code repetition. Signed-off-by:
-
This API manages objects (in this iteration, dmabuf fds) that can be shared along different virtio devices, associated to a UUID. The API allows the different devices to add, remove and/or retrieve the objects by simply invoking the public functions that reside in the virtio-dmabuf file. For vhost backends, the API stores the pointer to the backend holding the object. Suggested-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
-
Add hash function to uuid module using the djb2 hash algorithm. Add a couple simple unit tests for the hash function, checking collisions for similar UUIDs. Reviewed-by:
-
The 'next' was converted from a local variable to an output parameter in commit: 412e0e81 ("virtio: handle virtqueue_read_next_desc() errors") But all the actual uses of the 'i/next' as an output were removed a few months prior in commit: aa570d6f ("virtio: combine the read of a descriptor") Remove the unused argument to simplify the code. Also, adding a comment to the function to describe what it is actually doing, as it is not obvious that the 'desc' is both an input and an output argument. Signed-off-by:
Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927140016.2317404-3-i.maximets@ovn.org> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: -
It was supposed to be a compiler barrier and it was a compiler barrier initially called 'wmb' when virtio core support was introduced. Later all the instances of 'wmb' were switched to smp_wmb to fix memory ordering issues on non-x86 platforms. However, this one doesn't need to be an actual barrier, as its only purpose was to ensure that the value is not read twice. And since commit aa570d6f ("virtio: combine the read of a descriptor") there is no need for a barrier at all, since we're no longer reading guest memory here, but accessing a local structure. Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: -
We do not need the most up to date number of heads, we only want to know if there is at least one. Use shadow variable as long as it is not equal to the last available index checked. This avoids expensive qatomic dereference of the RCU-protected memory region cache as well as the memory access itself. The change improves performance of the af-xdp network backend by 2-3%. Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: -
Explain Coverity that we are not going to overflow vmsg->fds. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230925194040.68592-5-vsementsov@yandex-team.ru> Reviewed-by:
-
local_err must be NULL before calling object_property_set_bool(), so we must clear it on each iteration. Let's also use more convenient error_reportf_err(). Signed-off-by:
-
32-bit x86 systems do not have a reserved memory for hole64. On those 32-bit systems without PSE36 or PAE CPU features, hotplugging memory devices are not supported by QEMU as QEMU always places hotplugged memory above 4 GiB boundary which is beyond the physical address space of the processor. Linux guests also does not support memory hotplug on those systems. Please see Linux kernel commit b59d02ed08690 ("mm/memory_hotplug: disable the functionality for 32b") for more details. Therefore, the maximum limit of the guest physical address in the absence of additional memory devices effectively coincides with the end of "above 4G memory space" region for 32-bit x86 without PAE/PSE36. When users configure additional memory devices, after properly accounting for the additional device memory region to find the maximum value of the guest physical address, the address will be outside the range of the processor's physical address space. This change adds improvements to take above into consideration. For example, previously this was allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G With this change now it is no longer allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G qemu-system-x86_64: Address space limit 0xffffffff < 0x2bfffffff phys-bits too low (32) However, the following are allowed since on both cases physical address space of the processor is 36 bits: $ ./qemu-system-x86_64 -cpu pentium2 -m size=10G $ ./qemu-system-x86_64 -cpu pentium,pse36=on -m size=10G For 32-bit, without PAE/PSE36, hotplugging additional memory is no longer allowed. $ ./qemu-system-i386 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) $ ./qemu-system-i386 -machine q35 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) A new compatibility flag is introduced to make sure pc_max_used_gpa() keeps returning the old value for machines 8.1 and older. Therefore, the above is still allowed for older machine types in order to support compatibility. Hence, the following still works: $ ./qemu-system-i386 -machine pc-i440fx-8.1 -m size=1G,maxmem=3G,slots=2 $ ./qemu-system-i386 -machine pc-q35-8.1 -m size=1G,maxmem=3G,slots=2 Further, following is also allowed as with PSE36, the processor has 36-bit address space: $ ./qemu-system-i386 -cpu 486,pse36=on -m size=1G,maxmem=3G,slots=2 After calling CPUID with EAX=0x80000001, all AMD64 compliant processors have the longmode-capable-bit turned on in the extended feature flags (bit 29) in EDX. The absence of CPUID longmode can be used to differentiate between 32-bit and 64-bit processors and is the recommended approach. QEMU takes this approach elsewhere (for example, please see x86_cpu_realizefn()), With this change, pc_max_used_gpa() also uses the same method to detect 32-bit processors. Unit tests are modified to not run 32-bit x86 tests that use memory hotplug. Suggested-by:David Hildenbrand <david@redhat.com> Signed-off-by:
Ani Sinha <anisinha@redhat.com>
Reviewed-by: -
An MSI from I/O APIC may not exactly equal to APIC_DEFAULT_ADDRESS. In fact, Windows 17763.3650 configures I/O APIC to set the dest_mode bit. Cover the range assigned to APIC. Fixes: 577c470f ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by:
-
This patch solves a few issues. The most obvious is that the feature set was done previous to ACKNOWLEDGE | DRIVER status bit set. Current vdpa devices are permissive with this, but it is better to follow the standard. Fixes: 152128d6 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Signed-off-by:
Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230915170836.3078172-4-eperezma@redhat.com> Tested-by:
Lei Yang <leiyang@redhat.com> Reviewed-by:
-
Otherwise it continues the CVQ isolation probing. Fixes: 152128d6 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
-
It incorrectly prints "error setting features", probably because a copy paste miss. Fixes: 152128d6 ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by:
-
Will be needed so there is a defined serial number for information queries via the Switch CCI. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913133615.29876-1-Jonathan.Cameron@huawei.com> Reviewed-by:
-
Support these decoders in CXL host bridges (pxb-cxl), CXL Switch USP and CXL Type 3 end points. Signed-off-by:
-
In order to avoid having the size of the per HDM decoder register block repeated in lots of places, create the register definitions for HDM decoder 1 and use the offset between the first registers in HDM decoder 0 and HDM decoder 1 to establish the offset. Calculate in each function as this is more obvious and leads to shorter line lengths than a single #define which would need a long name to be specific enough. Note that the code currently only supports one decoder, so the bugs this fixes don't actually affect anything. Signed-off-by:
Fan Ni <fan.ni@samsung.com> Reviewed-by:
-
As an encoded version of these key configuration parameters is available in a register, provide functions to extract it again so as to avoid the need for duplicating the storage. Whilst here update the _enc() function to include additional values as defined in the CXL 3.0 specification. Whilst they are not currently used in the emulation, they may be in future and it is easier to compare with the specification if all values are covered. Add a spec reference for cxl_interleave_ways_enc() for consistency with the target count equivalent (and because it's nice to know where the magic numbers come from). Reviewed-by:
-
There is no strong justification for keeping these in the header so push them down into the associated cxl-component-utils.c file. Suggested-by:
-
Not zeroing it causes a SIGSEGV if the live migration is cancelled, at net device restart. This is caused because CVQ tries to reuse the iova_tree that is present in the first vhost_vdpa device at the end of vhost_vdpa_net_cvq_start. As a consequence, it tries to access an iova_tree that has been already free. Fixes: 00ef422e ("vdpa net: move iova tree creation from init to start") Reported-by:
Yanhui Ma <yama@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Tested-by:
Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by:
-
gcc 13.2.1 emits the following warning: net/vhost-vdpa.c: In function ‘net_vhost_vdpa_init.constprop’: net/vhost-vdpa.c:1394:25: error: ‘cvq_isolated’ may be used uninitialized [-Werror=maybe-uninitialized] 1394 | s->cvq_isolated = cvq_isolated; | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ net/vhost-vdpa.c:1355:9: note: ‘cvq_isolated’ was declared here 1355 | int cvq_isolated; | ^~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Eugenio Pérez <eperezma@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by:Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20230911215435.4156314-1-stefanha@redhat.com>
Acked-by: -
The bit positions of both registers are related. Tracing the registers independently results in the same offsets across these registers which eases debugging. Signed-off-by:
Bernhard Beschow <shentey@gmail.com> Acked-by:
Igor Mammedov <imammedo@redhat.com> Reviewed-by:
-
Signed-off-by:
-
The SMI command port is currently hardcoded by means of the ACPI_PORT_SMI_CMD macro. This hardcoding is Intel specific and doesn't match VIA, for example. There is already the AcpiFadtData::smi_cmd attribute which is used when building the FADT. Let's also use it when building the DSDT which confines SMI command port determination to just one place. This allows it to become a property later, thus resolving the Intel assumption. Signed-off-by:
-
Now that TYPE_ACPI_GED_X86 doesn't assign AcpiDeviceIfClass::madt_cpu any more it is the same as TYPE_ACPI_GED. Signed-off-by:
-
The "hw/boards.h" is unused since the previous commit. Since its removal requires include fixes in various unrelated files to keep the code compiling it has been split in a dedicated commit. Signed-off-by:
-
This virtual method was always set to the x86-specific pc_madt_cpu_entry(), even in piix4 which is also used in MIPS. The previous changes use pc_madt_cpu_entry() otherwise, so madt_cpu can be dropped. Since pc_madt_cpu_entry() is now only used in x86-specific code, the stub in hw/acpi/acpi-x86-stub can be removed as well. Signed-off-by:
-
build_cpus_aml() is architecture independent but needs to create architecture- specific CPU AML. So far this was achieved by using a virtual method from TYPE_ACPI_DEVICE_IF. However, build_cpus_aml() would resolve this interface from global (!) state. This makes it quite incomprehensible where this interface comes from (TYPE_PIIX4_PM?, TYPE_ICH9_LPC_DEVICE?, TYPE_ACPI_GED_X86?) an can lead to crashes when the generic code is ported to new architectures. So far, build_cpus_aml() is only called in architecture-specific code -- and only in x86. We can therefore simply pass pc_madt_cpu_entry() as callback to build_cpus_aml(). This is the same callback that would be used through TYPE_ACPI_DEVICE_IF. Signed-off-by:
-
This is x86-specific code, so there is no advantage in using pc_madt_cpu_entry() behind an architecture-agnostic interface. Signed-off-by:
-
