summary refs log tree commit diff stats
path: root/rust/qemu-macros/src (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-09-22rust/qdev: Refine the documentation for QDevProp traitManos Pitsidianakis1-4/+11
Refine the documentation to clarify: * `unsfae` requires that `VALUE` must be valid. * using `*const` instead of `&` because the latter will cause compiler error. Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-7-zhao1.liu@intel.com
2025-09-22rust/qdev: use addr_of! in QDevPropManos Pitsidianakis1-4/+4
We want a &raw pointer, so unsafe { &_ } is not needed. Suggested-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-6-zhao1.liu@intel.com
2025-09-22rust/common/uninit: Fix Clippy's complaints about lifetimeZhao Liu1-2/+2
Clippy complains about the following cases and following its suggestion to fix these warnings. warning: the following explicit lifetimes could be elided: 'a --> common/src/uninit.rs:38:6 | 38 | impl<'a, T, U> Deref for MaybeUninitField<'a, T, U> { | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes = note: `#[warn(clippy::needless_lifetimes)]` on by default help: elide the lifetimes | 38 - impl<'a, T, U> Deref for MaybeUninitField<'a, T, U> { 38 + impl<T, U> Deref for MaybeUninitField<'_, T, U> { | warning: the following explicit lifetimes could be elided: 'a --> common/src/uninit.rs:49:6 | 49 | impl<'a, T, U> DerefMut for MaybeUninitField<'a, T, U> { | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes help: elide the lifetimes | 49 - impl<'a, T, U> DerefMut for MaybeUninitField<'a, T, U> { 49 + impl<T, U> DerefMut for MaybeUninitField<'_, T, U> { | warning: `common` (lib) generated 2 warnings (run `cargo clippy --fix --lib -p common` to apply 2 suggestions) Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-5-zhao1.liu@intel.com
2025-09-22rust/qemu-macros: Fix Clippy's complaints about lambda parameter namingZhao Liu1-2/+2
error: `rename` shadows a previous, unrelated binding --> qemu-macros/src/lib.rs:265:14 | 265 | |rename| -> Result<proc_macro2::TokenStream, Error> { | ^^^^^^ | note: previous binding is here --> qemu-macros/src/lib.rs:245:30 | 245 | let DeviceProperty { rename, defval } = prop; | ^^^^^^ = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#shadow_unrelated = note: requested on the command line with `-D clippy::shadow-unrelated` Rename the lambda parameter to "prop_rename" to fix the above clippy error. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-4-zhao1.liu@intel.com
2025-09-22subprojects: Ignore .wraplock file generated by meson v1.9.0Zhao Liu1-0/+3
The .wraplock file is automatically generated by meson v1.9.0 (the related issue: https://github.com/mesonbuild/meson/issues/14948). Ignore it for now. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-3-zhao1.liu@intel.com
2025-09-22subprojects: Update .gitignore for proc-macro2 and synZhao Liu1-1/+1
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20250920160520.3699591-2-zhao1.liu@intel.com
2025-09-22rust: qemu-macros: switch #[property] parsing to use combinatorsPaolo Bonzini3-56/+49
Since we are going to add more attribute parsing for high-level migration state macros, use the attrs crate instead of a handwritten parser for device properties as well. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-22subprojects: add attrs cratePaolo Bonzini8-2/+47
The attrs crate is a simple combinator-based for Rust attributes. It will be used instead of a handwritten parser. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-22rust: build: remove "protocol: rust: from doctestsPaolo Bonzini5-5/+0
It is added already by rust.doctest. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-22rust: vmstate: use "cast()" instead of "as"Paolo Bonzini1-1/+1
Reported by clippy, fix it. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-22rust: build: add back common and util testsPaolo Bonzini2-0/+7
These were dropped by mistake when extracting the crates. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-22docs: use the pyvenv version of MesonPaolo Bonzini3-3/+3
The version in the system might be too old for QEMU; this will be especially true if Rust is going to be enabled by default. Adjust the docs to suggest using pyvenv/bin/meson, which is in fact what the "make" wrappers will be running internally. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-19util/vhost-user-server: vu_message_read(): improve error handlingVladimir Sementsov-Ogievskiy1-6/+11
1. Drop extra error_report_err(NULL), it will just crash, if we get here. 2. Get and report error of qemu_set_blocking(), instead of aborting. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19chardev: close an fd on failure pathVladimir Sementsov-Ogievskiy2-0/+2
There are at least two failure paths, where we forget to close an fd. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19chardev: qemu_chr_open_fd(): add errpVladimir Sementsov-Ogievskiy6-10/+31
Every caller already support errp, let's go further. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19treewide: use qemu_set_blocking instead of g_unix_set_fd_nonblockingVladimir Sementsov-Ogievskiy21-55/+67
Instead of open-coded g_unix_set_fd_nonblocking() calls, use QEMU wrapper qemu_set_blocking(). Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> [DB: fix missing closing ) in tap-bsd.c, remove now unused GError var] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19util: drop qemu_socket_set_block()Vladimir Sementsov-Ogievskiy3-14/+0
Now it's unused. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19io/channel-socket: rework qio_channel_socket_copy_fds()Vladimir Sementsov-Ogievskiy2-20/+55
We want to switch from qemu_socket_set_block() to newer qemu_set_blocking(), which provides return status of operation, to handle errors. Still, we want to keep qio_channel_socket_readv() interface clean, as currently it allocate @fds only on success. So, in case of error, we should close all incoming fds and keep user's @fds untouched or zero. Let's make separate functions qio_channel_handle_fds() and qio_channel_cleanup_fds(), to achieve what we want. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19util: drop qemu_socket_try_set_nonblock()Vladimir Sementsov-Ogievskiy7-40/+12
Now we can use qemu_set_blocking() in these cases. Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19util: drop qemu_socket_set_nonblock()Vladimir Sementsov-Ogievskiy14-37/+67
Use common qemu_set_blocking() instead. Note that pre-patch the behavior of Win32 and Linux realizations are inconsistent: we ignore failure for Win32, and assert success for Linux. How do we convert the callers? 1. Most of callers call qemu_socket_set_nonblock() on a freshly created socket fd, in conditions when we may simply report an error. Seems correct switching to error handling both for Windows (pre-patch error is ignored) and Linux (pre-patch we assert success). Anyway, we normally don't expect errors in these cases. Still in tests let's use &error_abort for simplicity. What are exclusions? 2. hw/virtio/vhost-user.c - we are inside #ifdef CONFIG_LINUX, so no damage in switching to error handling from assertion. 3. io/channel-socket.c: here we convert both old calls to qemu_socket_set_nonblock() and qemu_socket_set_block() to one new call. Pre-patch we assert success for Linux in qemu_socket_set_nonblock(), and ignore all other errors here. So, for Windows switch is a bit dangerous: we may get new errors or crashes(when error_abort is passed) in cases where we have silently ignored the error before (was it correct in all such cases, if they were?) Still, there is no other way to stricter API than take this risk. 4. util/vhost-user-server - compiled only for Linux (see util/meson.build), so we are safe, switching from assertion to &error_abort. Note: In qga/channel-posix.c we use g_warning(), where g_printerr() would actually be a better choice. Still let's for now follow common style of qga, where g_warning() is commonly used to print such messages, and no call to g_printerr(). Converting everything to use g_printerr() should better be another series. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19migration: qemu_file_set_blocking(): add errp parameterVladimir Sementsov-Ogievskiy6-10/+15
qemu_file_set_blocking() is a wrapper on qio_channel_set_blocking(), so let's passthrough the errp. Note the migration should not be using &error_abort in these calls, however, this is done to expedite the API conversion. The original code would have eventually ended up calling either qemu_socket_set_nonblock which would asset on Linux, or g_unix_set_fd_nonblocking which would propagate errors. We never saw asserts in practice, and conceptually they should not happen, but ideally this code will be later adapted to remove use of &error_abort. Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19treewide: handle result of qio_channel_set_blocking()Vladimir Sementsov-Ogievskiy16-30/+69
Currently, we just always pass NULL as errp argument. That doesn't look good. Some realizations of interface may actually report errors. Channel-socket realization actually either ignore or crash on errors, but we are going to straighten it out to always reporting an errp in further commits. So, convert all callers to either handle the error (where environment allows) or explicitly use &error_abort. Take also a chance to change the return value to more convenient bool (keeping also in mind, that underlying realizations may return -1 on failure, not -errno). Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> [DB: fix return type mismatch in TLS/websocket channel impls for qio_channel_set_blocking] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19util: add qemu_set_blocking() functionVladimir Sementsov-Ogievskiy3-0/+34
In generic code we have qio_channel_set_blocking(), which takes bool parameter, and qemu_file_set_blocking(), which as well takes bool parameter. At lower fd-layer we have a mess of functions: - enough direct calls to Unix-specific g_unix_set_fd_nonblocking() (of course, all calls are out of Windows-compatible code), which is glib specific with GError, which we can't use, and have to handle error-reporting by hand after the call. and several platform-agnostic qemu_* helpers: - qemu_socket_set_nonblock(), which asserts success for posix (still, in most cases we can handle the error in better way) and ignores error for win32 realization - qemu_socket_try_set_nonblock(), providing and error, but not errp, so we have to handle it after the call - qemu_socket_set_block(), which simply ignores an error Note, that *_socket_* word in original API, which we are going to substitute was intended, because Windows support these operations only for sockets. What leads to solution of dropping it again? 1. Having a QEMU-native wrapper with errp parameter for g_unix_set_fd_nonblocking() for non-socket fds worth doing, at least to unify error handling. 2. So, if try to keep _socket_ vs _file_ words, we'll have two actually duplicated functions for Linux, which actually will be executed successfully on any (good enough) fds, and nothing prevent using them improperly except for the name. That doesn't look good. 3. Naming helped us in the world where we crash on errors or ignore them. Now, with errp parameter, callers are intended to proper error checking. And for places where we really OK with crash-on-error semantics (like tests), we have an explicit &error_abort. So, this commit starts a series, which will effectively revert commit ff5927baa7ffb9 "util: rename qemu_*block() socket functions" (which in turn was reverting f9e8cacc5557e43 "oslib-posix: rename socket_set_nonblock() to qemu_set_nonblock()", so that's a long story). Now we don't simply rename, instead we provide the new API and update all the callers. This commit only introduces a new fd-layer wrapper. Next commits will replace old API calls with it, and finally remove old API. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19char-socket: tcp_chr_recv(): add commentVladimir Sementsov-Ogievskiy1-1/+6
Add comment, to stress that the order of operation (first drop old fds, second check read status) is intended. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19char-socket: tcp_chr_recv(): drop extra _set_(block,cloexec)Vladimir Sementsov-Ogievskiy1-14/+0
qio_channel_readv_full() guarantees BLOCKING and CLOEXEC states for incoming descriptors, no reason to call extra ioctls. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19io/channel: document how qio_channel_readv_full() handles fdsVladimir Sementsov-Ogievskiy1-0/+17
The only realization, which may have incoming fds is qio_channel_socket_readv() (in io/channel-socket.c). qio_channel_socket_readv() do call (through qio_channel_socket_copy_fds()) qemu_socket_set_block() and qemu_set_cloexec() for each fd. Also, qio_channel_socket_copy_fds() is called at the end of qio_channel_socket_readv(), on success path. Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19migration/qemu-file: don't make incoming fds blocking againVladimir Sementsov-Ogievskiy3-5/+12
In migration we want to pass fd "as is", not changing its blocking status. The only current user of these fds is CPR state (through VMSTATE_FD), which of-course doesn't want to modify fds on target when source is still running and use these fds. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-19MAINTAINERS: list qemu-security@nongnu.org as security contactDaniel P. Berrangé1-1/+1
The qemu-security@nongnu.org list is considered the authoritative contact for reporting QEMU security issues. Remove the Red Hat security team address in favour of QEMU's list, to ensure that upstream gets first contact. There is a representative of the Red Hat security team as a member of qemu-security@nongnu.org whom requests CVE assignments on behalf of QEMU when needed. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2025-09-189pfs: Stop including gstrfuncs.hPeter Foley1-1/+0
gstrfuncs.h is not intended to be included directly. In fact this only works because glib.h is already included by osdep.h. Just remove the include. Signed-off-by: Peter Foley <pefoley@google.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/qemu-devel/20250905-9p-v2-1-2ad31999684d@google.com Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2025-09-189pfs: Add FreeBSD supportMark Johnston9-15/+179
This is largely derived from existing Darwin support. FreeBSD apparently has better support for *at() system calls so doesn't require workarounds for a missing mknodat(). The implementation has a couple of warts however: - The extattr(2) system calls don't support anything akin to XATTR_CREATE or XATTR_REPLACE, so a racy workaround is implemented. - Attribute names cannot begin with "user." or "system." on ZFS. However FreeBSD's extattr(2) system calls support two dedicated namespaces for these two. So "user." or "system." prefixes are trimmed off from attribute names and instead EXTATTR_NAMESPACE_USER or EXTATTR_NAMESPACE_SYSTEM are picked and passed to extattr system calls accordingly. The 9pfs tests were verified to pass on the UFS, ZFS and tmpfs filesystems. Signed-off-by: Mark Johnston <markj@FreeBSD.org> Link: https://lore.kernel.org/qemu-devel/aJOWhHB2p-fbueAm@nuc Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2025-09-18hw/loongarch/virt: Register reset interface with cpu plug callbackBibo Mao2-13/+2
With cpu hotplug is implemented on LoongArch virt machine, reset interface with hot-added CPU should be registered. Otherwise there will be problem if system reboots after cpu is hot-added. Now register reset interface with CPU plug callback, so that all cold/hot added CPUs let their reset interface registered. And remove reset interface with CPU unplug callback. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Song Gao <gaosong@loongson.cn> Message-ID: <20250906070200.3749326-4-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2025-09-18hw/loongarch/virt: Remove unnecessay pre-boot setting with BSPBibo Mao2-26/+0
With BSP core, it boots from aux boot code and loads data into register A0-A2 and PC. Pre-boot setting is not unnecessary and can be removed. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-ID: <20250906070200.3749326-3-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2025-09-18hw/loongarch/virt: Add BSP support with aux boot codeBibo Mao1-2/+34
If system boots directly from Linux kernel, BSP core jumps to kernel entry of Linux kernel image and other APs jump to aux boot code. Instead BSP and APs can all jump to aux boot code like UEFI bios. With aux boot code, BSP core is judged from physical cpu id, whose cpu id is 0. With BSP core, load data to register A0-A2 and PC. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-ID: <20250906070200.3749326-2-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2025-09-17accel/kvm: Set guest_memfd_offset to non-zero value only when guest_memfd is ↵Xiaoyao Li1-1/+2
valid Current QEMU unconditionally sets the guest_memfd_offset of KVMSlot in kvm_set_phys_mem(), which leads to the trace of kvm_set_user_memory looks: kvm_set_user_memory AddrSpace#0 Slot#4 flags=0x2 gpa=0xe0000 size=0x20000 ua=0x7f5840de0000 guest_memfd=-1 guest_memfd_offset=0x3e0000 ret=0 It's confusing that the guest_memfd_offset has a non-zero value while the guest_memfd is invalid (-1). Change to only set guest_memfd_offset when guest_memfd is valid and leave it as 0 when no valid guest_memfd. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250728115707.1374614-4-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17accel/kvm: Zero out mem explicitly in kvm_set_user_memory_region()Xiaoyao Li1-1/+1
Zero out the entire mem explicitly before it's used, to ensure the unused feilds (pad1, pad2) are all zeros. Otherwise, it might cause problem when the pad fields are extended by future KVM. Fixes: ce5a983233b4 ("kvm: Enable KVM_SET_USER_MEMORY_REGION2 for memslot") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20250728115707.1374614-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17accel/kvm: Switch to check KVM_CAP_GUEST_MEMFD and KVM_CAP_USER_MEMORY2 on VMXiaoyao Li1-2/+2
It returns more accruate result on checking KVM_CAP_GUEST_MEMFD and KVM_CAP_USER_MEMORY2 on VM instance instead of on KVM platform. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250728115707.1374614-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17i386/kvm: Drop KVM_CAP_X86_SMM check in kvm_arch_init()Xiaoyao Li1-2/+1
x86_machine_is_smm_enabled() checks the KVM_CAP_X86_SMM for KVM case. No need to check KVM_CAP_X86_SMM in kvm_arch_init(). So just drop the check of KVM_CAP_X86_SMM to simplify the code. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250729062014.1669578-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17multiboot: Fix the split lockXiaoyao Li2-1/+1
While running the kvm-unit-tests on Intel platforms with "split lock disable" feature, every test triggers a kernel warning of x86/split lock detection: #AC: qemu-system-x86_64/373232 took a split_lock trap at address: 0x1e3 Hack KVM by exiting to QEMU on split lock #AC, we get KVM: exception 17 exit (error code 0x0) EAX=00000001 EBX=00000000 ECX=00000014 EDX=0001fb80 ESI=00000000 EDI=000000a8 EBP=00000000 ESP=00006f10 EIP=000001e3 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0900 00009000 0000ffff 00009300 DPL=0 DS16 [-WA] CS =c000 000c0000 0000ffff 00009b00 DPL=0 CS16 [-RA] SS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA] DS =c000 000c0000 0000ffff 00009300 DPL=0 DS16 [-WA] FS =0950 00009500 0000ffff 00009300 DPL=0 DS16 [-WA] GS =06f2 00006f20 0000ffff 00009300 DPL=0 DS16 [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000c02b4 00000027 IDT= 00000000 000003ff CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=89 16 08 00 65 66 0f 01 16 06 00 66 b8 01 00 00 00 0f 22 c0 <65> 66 ff 2e 00 00 b8 10 00 00 00 8e d0 8e d8 8e c0 8e e0 8e e8 66 b8 08 00 66 ba 10 05 66 And it matches with what disassembled from multiboo_dma.bin: #objdump -b binary -m i386 -D pc-bios/multiboot_dma.bin 1d1: 08 00 or %al,(%eax) 1d3: 65 66 0f 01 16 lgdtw %gs:(%esi) 1d8: 06 push %es 1d9: 00 66 b8 add %ah,-0x48(%esi) 1dc: 01 00 add %eax,(%eax) 1de: 00 00 add %al,(%eax) 1e0: 0f 22 c0 mov %eax,%cr0 > 1e3: 65 66 ff 2e ljmpw *%gs:(%esi) 1e7: 00 00 add %al,(%eax) 1e9: b8 10 00 00 00 mov $0x10,%eax 1ee: 8e d0 mov %eax,%ss 1f0: 8e d8 mov %eax,%ds 1f2: 8e c0 mov %eax,%es 1f4: 8e e0 mov %eax,%fs 1f6: 8e e8 mov %eax,%gs 1f8: 66 b8 08 00 mov $0x8,%ax 1fc: 66 ba 10 05 mov $0x510,%dx We can see that the instruction at 0x1e3 is a far jmp through the GDT. However, the GDT is not 8 byte aligned, the base is 0xc02b4. Intel processors follow the LOCK semantics to set the accessed flag of the segment descriptor when loading a segment descriptor. If the the segment descriptor crosses two cache line, it causes split lock. Fix it by aligning the GDT on 8 bytes, so that segment descriptor cannot span two cache lines. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20250808035027.2194673-1-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17target/i386: Define enum X86ASIdx for x86's address spacesXiaoyao Li4-5/+10
Define X86ASIdx as enum, like ARM's ARMASIdx, so that it's clear index 0 is for memory and index 1 is for SMM. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-By: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17i386/cpu: Enable SMM cpu address space under KVMXiaoyao Li3-5/+15
Kirill Martynov reported assertation in cpu_asidx_from_attrs() being hit when x86_cpu_dump_state() is called to dump the CPU state[*]. It happens when the CPU is in SMM and KVM emulation failure due to misbehaving guest. The root cause is that QEMU i386 never enables the SMM address space for cpu since KVM SMM support has been added. Enable the SMM cpu address space under KVM when the SMM is enabled for the x86machine. [*] https://lore.kernel.org/qemu-devel/20250523154431.506993-1-stdcalllevi@yandex-team.ru/ Reported-by: Kirill Martynov <stdcalllevi@yandex-team.ru> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17hpet: guard IRQ handling with BQLIgor Mammedov1-0/+8
Commit [1] made qemu fail with abort: xen_evtchn_set_gsi: Assertion `bql_locked()' failed. when running ./tests/functional/x86_64/test_kvm_xen.py tests. To fix it make sure that BQL is held when manipulating IRQs. Fixes: 7defb58baf (hpet: switch to fine-grained device locking) Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Link: https://lore.kernel.org/r/20250910142506.86274-1-imammedo@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: do not inline do_init_ioPaolo Bonzini1-5/+0
This is now possible since the hwcore integration tests do not link the system crate anymore. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250908105005.2119297-34-pbonzini@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: meson: remove unnecessary complication in device cratesPaolo Bonzini2-6/+0
It is not necessary anymore to explicitly list procedural macro crates when doing the final link using rustc. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250908105005.2119297-33-pbonzini@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17docs: update rust.rstMarc-André Lureau1-29/+32
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-23-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: re-export qemu macros from common/qom/hwcoreMarc-André Lureau34-45/+35
This is just a bit nicer. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-22-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: re-export qemu_macros internal helper in "bits"Marc-André Lureau1-2/+5
Avoid the need to import "qemu_macros". Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-21-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: repurpose qemu_api -> testsMarc-André Lureau15-230/+35
The crate purpose is only to provide integration tests at this point, that can't easily be moved to a specific crate. It's also often a good practice to have a single integration test crate (see for ex https://github.com/rust-lang/cargo/issues/4867) Drop README.md, use docs/devel/rust.rst instead. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-20-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust/pl011: drop dependency on qemu_apiMarc-André Lureau8-5/+106
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-19-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust/hpet: drop now unneeded qemu_api depMarc-André Lureau3-3/+0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-18-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-09-17rust: rename qemu_api_macros -> qemu_macrosMarc-André Lureau41-69/+69
Since "qemu_api" is no longer the unique crate to provide APIs. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Link: https://lore.kernel.org/r/20250827104147.717203-17-marcandre.lureau@redhat.com Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>