[PULL 12/60] target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()

From: Daniel Henrique Barboza We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every ti

[PULL 26/60] hw/riscv/opentitan: Rename machine_[class]_init() functions

From: Philippe Mathieu-Daudé Follow QOM style which declares FOO_init() as instance initializer and FOO_class_init() as class initializer: rename the OpenTitan machine class/instance init() accordingly. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alistair Francis Reviewed-by: Daniel Hen

[PULL 06/60] target/riscv: add PRIV_VERSION_LATEST

From: Daniel Henrique Barboza All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make i

[PULL 18/60] target/riscv: Make RLB/MML/MMWP bits writable only when Smepmp is enabled

From: Weiwei Li RLB/MML/MMWP bits in mseccfg CSR are introduced by Smepmp extension. So they can only be writable and set to 1s when cfg.epmp is true. Then we also need't check on epmp in pmp_hart_has_privs_default(). Signed-off-by: Weiwei Li Signed-off-by: Junqiang Wang Reviewed-by: Alistair

[PULL 09/60] target/riscv/cpu.c: add priv_spec validate/disable_exts helpers

From: Daniel Henrique Barboza We're doing env->priv_spec validation and assignment at the start of riscv_cpu_realize(), which is fine, but then we're doing a force disable on extensions that aren't compatible with the priv version. This second step is being done too early. The disabled extension

[PULL 19/60] target/riscv: Remove unused paramters in pmp_hart_has_privs_default()

From: Weiwei Li The addr and size parameters in pmp_hart_has_privs_default() are unused. Signed-off-by: Weiwei Li Signed-off-by: Junqiang Wang Reviewed-by: Alistair Francis Message-Id: <20230517091519.34439-7-liwei...@iscas.ac.cn> Signed-off-by: Alistair Francis --- target/riscv/pmp.c | 9 +

[PULL 14/60] target/riscv: Update pmp_get_tlb_size()

From: Weiwei Li PMP entries before (including) the matched PMP entry may only cover partial of the TLB page, and this may split the page into regions with different permissions. Such as for PMP0 (0x8008~0x800F, R) and PMP1 (0x8000~ 0x8FFF, RWX), write access to 0x8000 will mat

[PULL 08/60] target/riscv: Update check for Zca/Zcf/Zcd

From: Weiwei Li Even though Zca/Zcf/Zcd can be included by C/F/D, however, their priv version is higher than the priv version of C/F/D. So if we use check for them instead of check for C/F/D totally, it will trigger new problem when we try to disable the extensions based on the configured priv ve

[PULL 15/60] target/riscv: Move pmp_get_tlb_size apart from get_physical_address_pmp

From: Weiwei Li pmp_get_tlb_size can be separated from get_physical_address_pmp and is only needed when ret == TRANSLATE_SUCCESS. Signed-off-by: Weiwei Li Signed-off-by: Junqiang Wang Reviewed-by: LIU Zhiwei Reviewed-by: Alistair Francis Message-Id: <20230517091519.34439-3-liwei...@iscas.ac.

[PULL 02/60] target/riscv: Move zc* out of the experimental properties

From: Weiwei Li Zc* extensions (version 1.0) are ratified. Signed-off-by: Weiwei Li Signed-off-by: Junqiang Wang Reviewed-by: Daniel Henrique Barboza Reviewed-by: LIU Zhiwei Message-Id: <20230510030040.20528-1-liwei...@iscas.ac.cn> Signed-off-by: Alistair Francis --- target/riscv/cpu.c | 1

[PULL 00/60] riscv-to-apply queue

The following changes since commit fdd0df5340a8ebc8de88078387ebc85c5af7b40f: Merge tag 'pull-ppc-20230610' of https://gitlab.com/danielhb/qemu into staging (2023-06-10 07:25:00 -0700) are available in the Git repository at: https://github.com/alistair23/qemu.git tags/pull-riscv-to-apply-202

[PULL 04/60] target/riscv/cpu.c: remove set_vext_version()

From: Daniel Henrique Barboza This setter is doing nothing else but setting env->vext_ver. Assign the value directly. Signed-off-by: Daniel Henrique Barboza Reviewed-by: LIU Zhiwei Reviewed-by: Weiwei Li Reviewed-by: Alistair Francis Message-Id: <20230517135714.211809-3-dbarb...@ventanamicro

[PATCH v2 13/18] target/riscv/kvm.c: update KVM MISA bits

Our design philosophy with KVM properties can be resumed in two main decisions based on KVM interface availability and what the user wants to do: - if the user disables an extension that the host KVM module doesn't know about (i.e. it doesn't implement the kvm_get_one_reg() interface), keep bootin

[PATCH v2 18/18] target/riscv/kvm.c: read/write (cbom|cboz)_blocksize in KVM

If we don't set a proper cbom_blocksize|cboz_blocksize in the FDT the Linux Kernel will fail to detect the availability of the CBOM/CBOZ extensions, regardless of the contents of the 'riscv,isa' DT prop. The FDT is being written using the cpu->cfg.cbom|z_blocksize attributes, so let's expose them

[PATCH v2 17/18] target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helper

There are 2 places in which we need to get a pointer to a certain property of the cpu->cfg struct based on property offset. Next patch will add a couple more. Create a helper to avoid repeating this code over and over. Signed-off-by: Daniel Henrique Barboza --- target/riscv/kvm.c | 11 +++--

[PATCH v2 14/18] target/riscv/kvm.c: add multi-letter extension KVM properties

Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter exte

[PATCH v2 16/18] target/riscv: update multi-letter extension KVM properties

We're now ready to update the multi-letter extensions status for KVM. kvm_riscv_update_cpu_cfg_isa_ext() is called called during vcpu creation time to verify which user options changes host defaults (via the 'user_set' flag) and tries to write them back to KVM. Failure to commit a change to KVM i

[PATCH v2 05/18] target/riscv/cpu.c: restrict 'marchid' value

'marchid' shouldn't be set to a different value as previously set for named CPUs. For all other CPUs it shouldn't be freely set either - the spec requires that 'marchid' can't have the MSB (most significant bit) set and every other bit set to zero, i.e. 0x8000 is an invalid 'marchid' value for

[PATCH v2 09/18] linux-headers: Update to v6.4-rc1

Update to commit ac9a78681b92 ("Linux 6.4-rc1"). Signed-off-by: Daniel Henrique Barboza --- include/standard-headers/linux/const.h| 2 +- include/standard-headers/linux/virtio_blk.h | 18 +++ .../standard-headers/linux/virtio_config.h| 6 +++ include/standard-headers/linux/vi

[PATCH v2 11/18] target/riscv/cpu: add misa_ext_infos[]

Next patch will add KVM specific user properties for both MISA and multi-letter extensions. For MISA extensions we want to make use of what is already available in misa_ext_cfgs[] to avoid code repetition. The new misa_ext_infos[] array will hold name and description for each MISA extension that m

[PATCH v2 06/18] target/riscv: use KVM scratch CPUs to init KVM properties

Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to rea

[PATCH v2 00/18] target/riscv, KVM: fixes and enhancements

Hi, In this new version a lot of changes were made in the second half of the series, all based on Andrew's feeback in v1. Most notable changes are focused on reducing code repetition: - a new misa_ext_infos[] array that holds 'name' and 'description' info for MISA extensions to be shared betwe

[PATCH v2 04/18] target/riscv/cpu.c: restrict 'mimpid' value

Following the same logic used with 'mvendorid' let's also restrict 'mimpid' for named CPUs. Generic CPUs keep setting the value freely. Note that we're getting rid of the default RISCV_CPU_MARCHID value. The reason is that this is not a good default since it's dynamic, changing with with every QEM

[PATCH v2 12/18] target/riscv: add KVM specific MISA properties

Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small imp

[PATCH v2 15/18] target/riscv: make riscv_isa_string_ext() KVM compatible

The isa_edata_arr[] is used by riscv_isa_string_ext() to create the riscv,isa DT attribute. isa_edata_arr[] is kept in sync with the TCG property vector riscv_cpu_extensions[], i.e. all TCG properties from this vector that has a riscv,isa representation are included in isa_edata_arr[]. KVM doesn't

[PATCH v2 02/18] hw/riscv/virt.c: skip 'mmu-type' FDT if satp mode not set

The absence of a satp mode in riscv_host_cpu_init() is causing the following error: $ sudo ./qemu/build/qemu-system-riscv64 -machine virt,accel=kvm \ -m 2G -smp 1 -nographic -snapshot \ -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ -append "earlycon=s

[PATCH v2 10/18] target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPU

At this moment we're retrieving env->misa_ext during kvm_arch_init_cpu(), leaving env->misa_ext_mask behind. We want to set env->misa_ext_mask, and we want to set it as early as possible. The reason is that we're going to use it in the validation process of the KVM MISA properties we're going to a

[PATCH v2 07/18] target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids()

Allow 'marchid' and 'mimpid' to also be initialized in kvm_riscv_init_machine_ids(). After this change, the handling of mvendorid/marchid/mimpid for the 'host' CPU type will be equal to what we already have for TCG named CPUs, i.e. the user is not able to set these values to a different val than t

[PATCH v2 08/18] target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs

After changing user validation for mvendorid/marchid/mimpid to guarantee that the value is validated on user input time, coupled with the work in fetching KVM default values for them by using a scratch CPU, we're certain that the values in cpu->cfg.(mvendorid|marchid|mimpid) are already good to be

[PATCH v2 03/18] target/riscv/cpu.c: restrict 'mvendorid' value

We're going to change the handling of mvendorid/marchid/mimpid by the KVM driver. Since these are always present in all CPUs let's put the same validation for everyone. It doesn't make sense to allow 'mvendorid' to be different than it is already set in named (vendor) CPUs. Generic (dynamic) CPUs

[PATCH v2 01/18] target/riscv: skip features setup for KVM CPUs

As it is today it's not possible to use '-cpu host' if the RISC-V host has RVH enabled. This is the resulting error: $ sudo ./qemu/build/qemu-system-riscv64 \ -machine virt,accel=kvm -m 2G -smp 1 \ -nographic -snapshot -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv

Re: [PATCH v3 2/9] target/tricore: Remove pointless CONFIG_SOFTMMU guard

On Tue, Jun 13, 2023 at 03:33:40PM +0200, Philippe Mathieu-Daudé wrote: > We don't build any user emulation target for Tricore, > only the system emulation. No need to check for it as > it is always defined. > > Signed-off-by: Philippe Mathieu-Daudé > Reviewed-by: Richard Henderson > --- > targ

Re: [PATCH v2] Use named constants in BCM props

От: Philippe Mathieu-Daudé Отправлено: 13 июня 2023 г. 1:30 Кому: Sergey Kambalin; qemu-...@nongnu.org Копия: qemu-devel@nongnu.org; Kambalin, Sergey Тема: Re: [PATCH v2] Use named constants in BCM props On 12/6/23 13:59, Sergey Kambalin wrote: > ping > > - PI_

[PATCH] kvm: reuse per-vcpu stats fd to avoid vcpu interruption

A regression has been detected in latency testing of KVM guests. More specifically, it was observed that the cyclictest numbers inside of an isolated vcpu (running on isolated pcpu) are: # Max Latencies: 00090 00096 00141 Where a maximum of 50us is acceptable. The implementation of KVM_GET_STA

Re: [PATCH 14/16] target/riscv: adapt 'riscv_isa_string' for KVM

On 6/13/23 07:29, Daniel Henrique Barboza wrote: On 6/7/23 09:21, Andrew Jones wrote: On Tue, May 30, 2023 at 04:46:21PM -0300, Daniel Henrique Barboza wrote: KVM is not using the same attributes as TCG, i.e. it doesn't use isa_edata_arr[]. Add a new kvm_riscv_isa_string_ext() helper that

Re: [PATCH QEMU v5 8/8] tests: Add migration dirty-limit capability test

~hyman wrote: > From: Hyman Huang(黄勇) > > Add migration dirty-limit capability test if kernel support > dirty ring. > > Migration dirty-limit capability introduce dirty limit > capability, two parameters: x-vcpu-dirty-limit-period and > vcpu-dirty-limit are introduced to implement the live > migr

Re: [PATCH QEMU v5 7/8] migration: Extend query-migrate to provide dirty page limit info

~hyman wrote: > From: Hyman Huang(黄勇) > > Extend query-migrate to provide throttle time and estimated > ring full time with dirty-limit capability enabled, through which > we can observe if dirty limit take effect during live migration. > > Signed-off-by: Hyman Huang(黄勇) > Signed-off-by: Markus

Re: [PATCH QEMU v5 7/8] migration: Extend query-migrate to provide dirty page limit info

~hyman wrote: > From: Hyman Huang(黄勇) > > Extend query-migrate to provide throttle time and estimated > ring full time with dirty-limit capability enabled, through which > we can observe if dirty limit take effect during live migration. > > Signed-off-by: Hyman Huang(黄勇) > Signed-off-by: Markus

Re: [PATCH][RESEND v5 3/3] Add a Hyper-V Dynamic Memory Protocol driver (hv-balloon)

On 12.06.2023 19:42, David Hildenbrand wrote: On 12.06.23 16:00, Maciej S. Szmigiero wrote: From: "Maciej S. Szmigiero" This driver is like virtio-balloon on steroids: it allows both changing the guest memory allocation via ballooning and inserting pieces of extra RAM into it on demand from a

Re: [PATCH] udmabuf: revert 'Add support for mapping hugepages (v4)'

On 13.06.23 10:26, Kasireddy, Vivek wrote: Hi David, On 12.06.23 09:10, Kasireddy, Vivek wrote: Hi Mike, Hi Vivek, Sorry for the late reply; I just got back from vacation. If it is unsafe to directly use the subpages of a hugetlb page, then reverting this patch seems like the only option

Re: [PATCH QEMU v5 6/8] migration: Implement dirty-limit convergence algo

~hyman wrote: > From: Hyman Huang(黄勇) To speed thinkng up, 1-5 are included on next Migration PULL request. > Implement dirty-limit convergence algo for live migration, > which is kind of like auto-converge algo but using dirty-limit > instead of cpu throttle to make migration convergent. > > E

[PATCH] Fix handling of AVR interrupts above 33.

This commit addresses a bug in the AVR interrupt handling code. The modification involves replacing the usage of the ctz32 function with ctz64 to ensure proper handling of interrupts above 33 in the AVR target. Previously, timers 3, 4, and 5 interrupts were not functioning correctly because most o

Re: [PATCH QEMU v5 1/8] softmmu/dirtylimit: Add parameter check for hmp "set_vcpu_dirty_limit"

Juan Quintela wrote: > ~hyman wrote: >> From: Hyman Huang(黄勇) >> >> dirty_rate paraemter of hmp command "set_vcpu_dirty_limit" is invalid >> if less than 0, so add parameter check for it. > > why? And here I am, making a full of myself. vcpu_dirty_limit and vcpu_dirty_limit_period are two diff

Re: [PATCH QEMU v5 5/8] migration: Refactor auto-converge capability logic

~hyman wrote: > From: Hyman Huang(黄勇) > > Check if block migration is running before throttling > guest down in auto-converge way. > > Note that this modification is kind of like code clean, > because block migration does not depend on auto-converge > capability, so the order of checks can be adj

Re: [PATCH QEMU v5 4/8] migration: Introduce dirty-limit capability

~hyman wrote: > From: Hyman Huang(黄勇) > > Introduce migration dirty-limit capability, which can > be turned on before live migration and limit dirty > page rate durty live migration. > > Introduce migrate_dirty_limit function to help check > if dirty-limit capability enabled during live migration

Re: [PATCH QEMU v5 3/8] qapi/migration: Introduce vcpu-dirty-limit parameters

~hyman wrote: > From: Hyman Huang(黄勇) > > Introduce "vcpu-dirty-limit" migration parameter used > to limit dirty page rate during live migration. > > "vcpu-dirty-limit" and "x-vcpu-dirty-limit-period" are > two dirty-limit-related migration parameters, which can > be set before and during live mi

Re: [PATCH QEMU v5 1/8] softmmu/dirtylimit: Add parameter check for hmp "set_vcpu_dirty_limit"

~hyman wrote: > From: Hyman Huang(黄勇) > > dirty_rate paraemter of hmp command "set_vcpu_dirty_limit" is invalid > if less than 0, so add parameter check for it. why? Next patch does it correctly: +if (params->has_x_vcpu_dirty_limit_period && +(params->x_vcpu_dirty_limit_period < 1

Re: [PATCH QEMU v5 2/8] qapi/migration: Introduce x-vcpu-dirty-limit-period parameter

~hyman wrote: > From: Hyman Huang(黄勇) > > Introduce "x-vcpu-dirty-limit-period" migration experimental > parameter, which is in the range of 1 to 1000ms and used to milliseconds > make dirtyrate calculation period configurable. > > Currently with the "x-vcpu-dirty-limit-period" varies, the > to

Re: [PATCH v2 05/20] qemu_file: Use a stat64 for qemu_file_transferred

Peter Xu wrote: > On Tue, May 30, 2023 at 08:39:26PM +0200, Juan Quintela wrote: >> This way we can read it from any thread. >> I checked that it gives the same value than the current one. We never >> use to qemu_files at the same time. >> >> Signed-off-by: Juan Quintela > > The follow up patch

Re: [PATCH v2 04/20] qemu-file: We only call qemu_file_transferred_* on the sending side

Peter Xu wrote: > On Tue, May 30, 2023 at 08:39:25PM +0200, Juan Quintela wrote: >> Remove the increase in qemu_file_fill_buffer() and add asserts to >> qemu_file_transferred* functions. >> >> Signed-off-by: Juan Quintela > > The read side accounting does look a bit weird and never caught my not

Re: [PATCH v5 00/16] iotests: use vm.cmd()

ping. 03-16 are still applicable to master with "git am -3" and very small conflict in "iotests: QemuStorageDaemon: add cmd() method like in QEMUMachine." On 15.02.23 16:25, Vladimir Sementsov-Ogievskiy wrote: Hi all! Let's get rid of pattern result = self.vm.qmp(...) self.assert_qm

Re: [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment

Am 13. Juni 2023 15:01:40 UTC schrieb "Michael S. Tsirkin" : >On Tue, Jun 13, 2023 at 03:40:28PM +0200, Philippe Mathieu-Daudé wrote: >> On 13/6/23 15:05, Igor Mammedov wrote: >> > On Tue, 13 Jun 2023 13:07:17 +0200 (CEST) >> > BALATON Zoltan wrote: >> > >> > > On Tue, 13 Jun 2023, Michael S.

Re: [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment

On Tue, Jun 13, 2023 at 03:40:28PM +0200, Philippe Mathieu-Daudé wrote: > On 13/6/23 15:05, Igor Mammedov wrote: > > On Tue, 13 Jun 2023 13:07:17 +0200 (CEST) > > BALATON Zoltan wrote: > > > > > On Tue, 13 Jun 2023, Michael S. Tsirkin wrote: > > > > On Tue, Jun 13, 2023 at 09:46:53AM +0200, Bernh

[PATCH v1 2/5] arm/virt: Properly handle unplug of virtio based memory devices

While we fence unplug requests from the outside, the VM can still trigger unplug of virtio based memory devices, for example, in Linux doing: # echo 0 > /sys/bus/pci/slots/3/power While doing that is not really expected to work without harming the guest OS (e.g., removing a virtio-mem device w

[PATCH v1 5/5] arm/virt: Support unplug of virtio-mem-pci devices

Let's support unplug of virtio-mem-pci devices by granting (forwarding) unplug requests if it's safe to unplug a virtio-mem device. Signed-off-by: David Hildenbrand --- hw/arm/virt.c | 34 +++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/hw/arm/vi

[PATCH v1 4/5] pc: Support unplug of virtio-mem-pci devices

Let's support unplug of virtio-mem-pci devices by granting (forwarding) unplug requests if it's safe to unplug a virtio-mem device. Signed-off-by: David Hildenbrand --- hw/i386/pc.c | 48 +--- 1 file changed, 41 insertions(+), 7 deletions(-) diff --gi

[PATCH v1 0/5] virtio-mem: Device unplug support

One limitation of virtio-mem is that we cannot currently unplug virtio-mem devices that have all memory unplugged from the VM. Let's properly handle forced unplug (as can be triggered by the VM) and add support for ordinary unplug (requests) of virtio-mem devices that are in a compatible state (no

[PATCH v1 3/5] virtio-mem: Prepare for unplug support of virtio-mem-pci devices

In many cases, blindly unplugging a virtio-mem device is problematic. We can only safely remove a device once: * The guest is not expecting to be able to read unplugged memory (unplugged-inaccessible == on) * The virtio-mem device does not have memory plugged (size == 0) * The virtio-mem device d

[PATCH v1 1/5] pc: Properly handle unplug of virtio based memory devices

While we fence unplug requests from the outside, the VM can still trigger unplug of virtio based memory devices, for example, in Linux doing: # echo 0 > /sys/bus/pci/slots/3/power While doing that is not really expected to work without harming the guest OS (e.g., removing a virtio-mem device w

[PATCH 11/18] migration: Move busy++ to migrate_with_multithread

And now we can simplify save_compress_page(). Signed-off-by: Juan Quintela --- migration/ram-compress.c | 1 + migration/ram.c | 7 +-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/migration/ram-compress.c b/migration/ram-compress.c index 3c44803132..2652cdee8b 100

[PATCH 10/18] migration: Simplify compress_page_with_multithread()

Move the goto to a while true. Signed-off-by: Juan Quintela --- migration/ram-compress.c | 48 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/migration/ram-compress.c b/migration/ram-compress.c index 8ce9519f3d..3c44803132 100644 --- a/mi

[PATCH 13/18] migration: Simplify decompress_data_with_multi_threads()

Doing a break to do another break is just confused. Just call return when we know we want to return. Signed-off-by: Juan Quintela --- migration/ram-compress.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/migration/ram-compress.c b/migration/ram-compress.c index 5e

[PATCH 09/18] migration: Make compress_data_with_multithreads return bool

Signed-off-by: Juan Quintela --- migration/ram-compress.h | 4 ++-- migration/ram-compress.c | 17 ++--- migration/ram.c | 2 +- 3 files changed, 13 insertions(+), 10 deletions(-) diff --git a/migration/ram-compress.h b/migration/ram-compress.h index e55d3b50bd..b228640092

[PATCH 06/18] migration: Create populate_compress()

So we don't have to access compression_counters from outside ram-compress.c. Signed-off-by: Juan Quintela --- migration/ram-compress.h | 3 +++ migration/migration.c| 11 +-- migration/ram-compress.c | 14 ++ 3 files changed, 18 insertions(+), 10 deletions(-) diff --git

[PATCH 16/18] migration: control_save_page() can take block through pss

Signed-off-by: Juan Quintela --- migration/ram.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index e3ff98a6ce..293ea87a70 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1114,14 +1114,14 @@ static int save_zero_page(PageSearch

[PATCH 15/18] migration: save_compress_page() can take block through pss

Signed-off-by: Juan Quintela --- migration/ram.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index 1bd586c23a..e3ff98a6ce 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1986,7 +1986,7 @@ int ram_save_queue_pages(const char

[PATCH 08/18] migration: Move update_compress_threads_counts() to ram-compress.c

Signed-off-by: Juan Quintela --- migration/ram-compress.h | 1 + migration/ram-compress.c | 17 + migration/ram.c | 15 --- 3 files changed, 18 insertions(+), 15 deletions(-) diff --git a/migration/ram-compress.h b/migration/ram-compress.h index 77465dad4b..

[PATCH 17/18] migration: Remove not needed block parameter for save_zero_page*

Signed-off-by: Juan Quintela --- migration/ram.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index 293ea87a70..0259c33da7 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1067,20 +1067,20 @@ void ram_release_page(

[PATCH 05/18] migration: Move compression_counters cleanup ram-compress.c

Signed-off-by: Juan Quintela --- migration/migration.c| 4 +--- migration/ram-compress.c | 5 + migration/savevm.c | 1 - 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/migration/migration.c b/migration/migration.c index 84551f040c..5105ad6825 100644 --- a/migration/

[PATCH 14/18] migration: Use "i" as an for index in ram-compress.c

It is used everywhere else in C. Once there, make sure that we don't use the index outside of the for declaring the variable there. Signed-off-by: Juan Quintela --- migration/ram-compress.c | 57 ++-- 1 file changed, 25 insertions(+), 32 deletions(-) diff --

[PATCH 01/18] migration: Give one error if trying to set MULTIFD and XBZRLE

Signed-off-by: Juan Quintela --- migration/options.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/migration/options.c b/migration/options.c index b62ab30cd5..c6674a4753 100644 --- a/migration/options.c +++ b/migration/options.c @@ -547,6 +547,13 @@ bool migrate_caps_check(bool *old_

[PATCH 04/18] migration: Remove save_page_use_compression()

After previous patch, we disable the posiblity that we use compression together with xbzrle. So we can use directly migrate_compress(). Once there, now we don't need the rs parameter, so remove it. Signed-off-by: Juan Quintela --- migration/ram.c | 34 +++--- 1 file

[PATCH 12/18] migration: Create compression_update_rates()

So we can move more compression_counters stuff to ram-compress.c. Create compression_counters struct to add the stuff that was on MigrationState. Signed-off-by: Juan Quintela --- migration/ram-compress.h | 1 + migration/ram.h | 1 - migration/ram-compress.c | 41 +

[PATCH 03/18] migration: RDMA is not compatible with anything else

So give an error instead of just ignoring the other methods. Signed-off-by: Juan Quintela --- migration/migration.c | 12 1 file changed, 12 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index dc05c6f6ea..84551f040c 100644 --- a/migration/migration.c +++

[PATCH 02/18] migration: Give one error if trying to set COMPRESSION and XBZRLE

As we have disable to use both together in the previous patch, we can remove this check. Signed-off-by: Juan Quintela --- migration/options.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/migration/options.c b/migration/options.c index c6674a4753..a18689c314 100644 --- a/migration/o

[PATCH 18/18] migration: Remove not needed file parameter for save_zero_page*

Signed-off-by: Juan Quintela --- migration/ram.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index 0259c33da7..ae11d0e992 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1069,16 +1069,15 @@ void ram_release_page(const

[PATCH 07/18] migration: Create ram_compressed_pages()

Signed-off-by: Juan Quintela fix ram_compress Signed-off-by: Juan Quintela --- migration/ram-compress.h | 1 + migration/ram-compress.c | 6 ++ migration/ram.c | 2 +- 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/migration/ram-compress.h b/migration/ram-compress.h

[PATCH 00/18] Migration compression cleanup

Hi On this series: - We got errors when setting incompatible migration methods (i.e. compression and RDMA) - Remove the posibility of running COMPRESSION and XBZRLE together (remember that compression don't work) - This series is the preliminar work to be able to compile out compression (

[PATCH] vfio/pci: Call vfio_prepare_kvm_msi_virq_batch() in MSI retry path

When vfio_enable_vectors() returns with less than requested nr_vectors we retry with what kernel reported back. But the retry path doesn't call vfio_prepare_kvm_msi_virq_batch() and this results in, qemu-system-aarch64: vfio: Error: Failed to enable 4 MSI vectors, retry with 1 qemu-system-aarch64:

Re: [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment

On 13/6/23 15:05, Igor Mammedov wrote: On Tue, 13 Jun 2023 13:07:17 +0200 (CEST) BALATON Zoltan wrote: On Tue, 13 Jun 2023, Michael S. Tsirkin wrote: On Tue, Jun 13, 2023 at 09:46:53AM +0200, Bernhard Beschow wrote: On Mon, Jun 12, 2023 at 3:01 PM Igor Mammedov wrote: On Sun, 11 Jun 2

[PATCH v3 9/9] meson: Replace softmmu_ss -> system_ss

We use the user_ss[] array to hold the user emulation sources, and the softmmu_ss[] array to hold the system emulation ones. Hold the latter in the 'system_ss[]' array for parity with user emulation. Mechanical change doing: $ sed -i -e s/softmmu_ss/system_ss/g $(git grep -l softmmu_ss) Signed

[PATCH v3 8/9] meson: Replace CONFIG_SOFTMMU -> CONFIG_SYSTEM_ONLY

Since we *might* have user emulation with softmmu, use the clearer 'CONFIG_SYSTEM_ONLY' key to check for system emulation. Signed-off-by: Philippe Mathieu-Daudé --- meson.build| 4 ++-- accel/qtest/meson.build| 2 +- accel/stubs/meson.build| 2 +-

[PATCH v3 7/9] meson: Alias CONFIG_SOFTMMU -> CONFIG_SYSTEM_ONLY

We use the CONFIG_USER_ONLY key to describe user emulation, and the CONFIG_SOFTMMU key to describe system emulation. Alias it as 'CONFIG_SYSTEM_ONLY' for parity with user emulation. Signed-off-by: Philippe Mathieu-Daudé --- meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/meson.bu

[PATCH v3 3/9] target/m68k: Check for USER_ONLY definition instead of SOFTMMU one

Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one. Invert some if() ladders for clarity. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson --- target/m68k/helper.h| 2 +- target/m68k/cpu.c | 14 ++-

[PATCH v3 5/9] hw/core/cpu: Check for USER_ONLY definition instead of SOFTMMU one

Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one. Invert the #ifdef'ry in TCGCPUOps structure for clarity. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson --- include/hw/core/cpu.h | 4 +- include/hw/cor

[PATCH v3 4/9] target/ppc: Check for USER_ONLY definition instead of SOFTMMU one

Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson --- target/ppc/cpu_init.c| 20 ++-- target/ppc/helper_regs.c | 6 ++ 2 files changed, 12 in

[PATCH v3 6/9] accel/tcg: Check for USER_ONLY definition instead of SOFTMMU one

Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one. Invert some if() ladders for clarity. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson --- accel/tcg/internal.h | 6 +++--- accel/tcg/cpu-exec.c | 4 ++-- 2 files c

[PATCH v3 0/9] bulk: Replace CONFIG_SOFTMMU by !CONFIG_USER_ONLY/CONFIG_SYSTEM_ONLY

Missing review: 1, 7, 8 Since v2: - Rebased - Added R-b tags - Rework i386_tr_init_disas_context() patch (Richard) - Dropped RFC prefix This series aims to clarify the CONFIG_[USER|SYSTEM] vs CONFIG_SOFTMMU confusion [*] by using explicit definitions, removing mentions of CONFIG_SOFTMMU in non-TC

[PATCH v3 1/9] target/i386: Simplify i386_tr_init_disas_context()

Since cpu_mmu_index() is well-defined for user-only, we can remove the surrounding #ifdef'ry entirely. Suggested-by: Richard Henderson Signed-off-by: Philippe Mathieu-Daudé --- target/i386/tcg/translate.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/target/i386/tcg/translate.c b/target

[PATCH v3 2/9] target/tricore: Remove pointless CONFIG_SOFTMMU guard

We don't build any user emulation target for Tricore, only the system emulation. No need to check for it as it is always defined. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson --- target/tricore/helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/tricore/

[PATCH v2 3/3] i386/cpuid: Move leaf 7 to correct group

CPUID leaf 7 was grouped together with SGX leaf 0x12 by commit b9edbadefb9e ("i386: Propagate SGX CPUID sub-leafs to KVM") by mistake. SGX leaf 0x12 has its specific logic to check if subleaf (starting from 2) is valid or not by checking the bit 0:3 of corresponding EAX is 1 or not. Leaf 7 follow

[PATCH v2 2/3] i386/cpuid: Remove subleaf constraint on CPUID leaf 1F

No such constraint that subleaf index needs to be less than 64. Signed-off-by: Xiaoyao Li --- target/i386/kvm/kvm.c | 4 1 file changed, 4 deletions(-) diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index afa97799d89a..d7e235ce35a6 100644 --- a/target/i386/kvm/kvm.c +++ b/targe

[PATCH v2 1/3] i386/cpuid: Decrease cpuid_i when skipping CPUID leaf 1F

Decrease array index cpuid_i when CPUID leaf 1F is skipped, otherwise it will get an all zero'ed CPUID entry with leaf 0 and subleaf 0. It conflicts with correct leaf 0. Signed-off-by: Xiaoyao Li --- target/i386/kvm/kvm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/target/i386/kvm/kvm.c

[PATCH v2 0/3] i386: Minor fixes of building CPUIDs

This v2 adds patch 3 to fix the build of CPUID leaf 7. The issue that fixed by Patch 1 looks fatal though it doesn't appear on KVM because KVM always searches with assending order and hit with the correct cpuid leaf 0. Patch 2 removes the wrong constraint on CPUID leaf 1f. Changes in v2: - Add P

Re: [PATCH 02/15] hw/pci-host/q35: Fix double, contradicting .endianness assignment

On Tue, 13 Jun 2023 13:07:17 +0200 (CEST) BALATON Zoltan wrote: > On Tue, 13 Jun 2023, Michael S. Tsirkin wrote: > > On Tue, Jun 13, 2023 at 09:46:53AM +0200, Bernhard Beschow wrote: > >> On Mon, Jun 12, 2023 at 3:01 PM Igor Mammedov wrote: > >> > >> On Sun, 11 Jun 2023 12:33:59 +0200 > >>

Re: [PATCH] hw/loongarch: Supplement cpu topology arguments

On 13/6/23 14:32, Tianrui Zhao wrote: Supplement LoongArch cpu topology arguments, including support socket and threads per core. Base-on: https://patchew.org/QEMU/20230613122613.2471743-1-zhaotian...@loongson.cn/ ^ FYI this tag ... Signed-off-by: Song Gao Signed-off-by: Tianrui Zhao ---

Re: [PATCH 2/2] ui/dbus: Expose a touch device interface

Hi Bilal On Tue, Jun 13, 2023 at 1:39 PM Bilal Elmoussaoui wrote: > So that clients making use of the DBus backend could > send touch events through the new org.qemu.Display1.Touch > interface > > Signed-off-by: Bilal Elmoussaoui > --- > ui/dbus-console.c| 56 ++

Re: [PATCH 1/2] ui/touch: Move event handling to a common helper

Hi Bilal On Tue, Jun 13, 2023 at 1:35 PM Bilal Elmoussaoui wrote: > To share code between the GTK and DBus UI bakcends > see the next commit for details > > Signed-off-by: Bilal Elmoussaoui > --- > include/ui/console.h | 14 ++ > ui/console.c | 65 ++

[PATCH] hw/loongarch: Supplement cpu topology arguments

Supplement LoongArch cpu topology arguments, including support socket and threads per core. Base-on: https://patchew.org/QEMU/20230613122613.2471743-1-zhaotian...@loongson.cn/ Signed-off-by: Song Gao Signed-off-by: Tianrui Zhao --- hw/loongarch/acpi-build.c | 4 hw/loongarch/virt.c

Re: [PATCH V2 1/4] qapi: strList_from_string

Steven Sistare writes: > On 2/10/2023 4:25 AM, Markus Armbruster wrote: >> Steven Sistare writes: >> >>> On 2/9/2023 1:59 PM, Markus Armbruster wrote: Steven Sistare writes: > On 2/9/2023 11:46 AM, Markus Armbruster wrote: >> Steven Sistare writes: >> >> [...] >> >>> For mo

<    1   2   3   >