Re: [RFC PATCH v2 07/21] i386/pc: Drop pc_machine_kvm_type()

On 9/21/2023 4:51 PM, David Hildenbrand wrote: On 14.09.23 05:51, Xiaoyao Li wrote: pc_machine_kvm_type() was introduced by commit e21be724eaf5 ("i386/xen: add pc_machine_kvm_type to initialize XEN_EMULATE mode") to do Xen specific initialization by utilizing kvm_type method. commit eeedfe6c631

[PATCH v2] hw/sd/sdhci: Block Size Register bits [14:12] is lost

Block Size Register bits [14:12] is SDMA Buffer Boundary, it is missed in register write, but it is needed in SDMA transfer. e.g. it will be used in sdhci_sdma_transfer_multi_blocks to calculate boundary_ variables. Missing this field will cause wrong operation for different SDMA Buffer Boundary s

Re: [PATCH v11 6/9] gfxstream + rutabaga: add initial support for gfxstream

On 2023/09/22 8:44, Gurchetan Singh wrote: On Tue, Sep 19, 2023 at 3:07 PM Akihiko Odaki > wrote: On 2023/09/20 3:36, Bernhard Beschow wrote: > > > Am 15. September 2023 02:38:02 UTC schrieb Gurchetan Singh mailto:gurchetansi...@chromium.

RE: [PATCH v1 13/22] vfio: Add base container

>-Original Message- >From: Eric Auger >Sent: Friday, September 22, 2023 1:20 AM >Subject: Re: [PATCH v1 13/22] vfio: Add base container > >Hi Zhenzhong, >On 9/21/23 05:35, Duan, Zhenzhong wrote: >> Hi Eric, >> >>> -Original Message- >>> From: Eric Auger >>> Sent: Thursday, Septe

Re: [PATCH v13 6/9] gfxstream + rutabaga: add initial support for gfxstream

On 2023/09/22 9:03, Gurchetan Singh wrote: On Wed, Sep 20, 2023 at 5:05 AM Mark Cave-Ayland mailto:mark.cave-ayl...@ilande.co.uk>> wrote: On 20/09/2023 12:42, Akihiko Odaki wrote: > On 2023/08/29 9:36, Gurchetan Singh wrote: >> This adds initial support for gfxstream and cros

Re: Concerns regarding e17bebd049 ("dump: Set correct vaddr for ELF dump")

Not sure if crash people subscribed to linux-debuggers, let's add more cc for awareness about this thread. On Thu, 21 Sept 2023 at 01:45, Stephen Brennan wrote: > > Stephen Brennan writes: > > Hi Jon, > > > > Jon Doron writes: > >> Hi Stephen, > >> Like you have said the reason is as I wrote in

[PATCH] vfio/pci: rename vfio_put_device to vfio_pci_put_device

vfio_put_device() is a VFIO PCI specific function, rename it with 'vfio_pci' prefix to avoid confusing. No functional change. Suggested-by: Cédric Le Goater Signed-off-by: Zhenzhong Duan --- hw/vfio/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/vfio/pci.c b/h

Re: [virtio-dev] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg

On Thu, Sep 21, 2023 at 2:28 PM Chen, Jiqian wrote: > > Hi Jason, > > On 2023/9/21 12:22, Jason Wang wrote: > > On Tue, Sep 19, 2023 at 7:43 PM Jiqian Chen wrote: > >> > >> When guest vm does S3, Qemu will reset and clear some things of virtio > >> devices, but guest can't aware that, so that may

[PATCH v4] hw/i386/pc: improve physical address space bound check for 32-bit x86 systems

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. Linu

Re: [PATCH v3 4/5] hw/char: riscv_htif: replace exit calls with proper shutdown

On Thu, Sep 7, 2023 at 9:26 PM Clément Chigot wrote: > > This replaces the exit calls by shutdown requests, ensuring a proper > cleanup of Qemu. Otherwise, some connections like gdb could be broken > before its final packet ("Wxx") is being sent. This part, being done > inside qemu_cleanup functio

Re: [PATCH v3 01/19] target/riscv: introduce TCG AccelCPUClass

On Wed, Sep 20, 2023 at 9:22 PM Daniel Henrique Barboza wrote: > > target/riscv/cpu.c needs to handle all possible accelerators (TCG and > KVM at this moment) during both init() and realize() time. This forces > us to resort to a lot of "if tcg" and "if kvm" throughout the code, > which isn't wron

Re: [PATCH v3 02/19] target/riscv: move riscv_cpu_realize_tcg() to TCG::cpu_realizefn()

On Wed, Sep 20, 2023 at 9:24 PM Daniel Henrique Barboza wrote: > > riscv_cpu_realize_tcg() was added to allow TCG cpus to have a different > realize() path during the common riscv_cpu_realize(), making it a good > choice to start moving TCG exclusive code to tcg-cpu.c. > > Rename it to tcg_cpu_rea

Re: [PATCH v3 03/19] target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c

On Wed, Sep 20, 2023 at 10:25 PM Daniel Henrique Barboza wrote: > > This function is the core of the RISC-V validations for TCG CPUs, and it > has a lot going on. > > Functions in cpu.c were made public to allow them to be used by the KVM > accelerator class later on. 'cpu_cfg_ext_get_min_version(

Re: [PATCH v3 04/19] target/riscv: move riscv_tcg_ops to tcg-cpu.c

On Wed, Sep 20, 2023 at 9:21 PM Daniel Henrique Barboza wrote: > > Move the remaining of riscv_tcg_ops now that we have a working realize() > implementation. > > Signed-off-by: Daniel Henrique Barboza > Reviewed-by: Philippe Mathieu-Daudé > Reviewed-by: Andrew Jones > Reviewed-by: LIU Zhiwei

RE: [PATCH v1 1/4] vfio: new command line params for device memory NUMA nodes

> Also, good to say why multiple nodes per device are needed. This is to support the GPU's MIG (Mult-Instance GPUs) feature, (https://www.nvidia.com/en-in/technologies/multi-instance-gpu/) which allows partitioning of the GPU device resources (including device memory) into several isolated instance

RE: [PATCH v1 3/4] hw/arm/virt-acpi-build: patch guest SRAT for NUMA nodes

Hi Jonathan > > +if (pcidev->pdev.has_coherent_memory) { > > +uint64_t start_node = object_property_get_uint(obj, > > + "dev_mem_pxm_start", &error_abort); > > +uint64_t node_count = object_property_get_uint(obj, > > +

Re: [PATCH v3 05/19] target/riscv/cpu.c: add .instance_post_init()

On Wed, Sep 20, 2023 at 9:24 PM Daniel Henrique Barboza wrote: > > All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU > calls riscv_init_max_cpu_extensions(). Both can be moved to a common > instance_post_init() callback, implemented in riscv_cpu_post_init(), > called by all CPUs

Re: [PATCH v3 06/19] target/riscv: move 'host' CPU declaration to kvm.c

On Wed, Sep 20, 2023 at 9:22 PM Daniel Henrique Barboza wrote: > > This CPU only exists if we're compiling with KVM so move it to the kvm > specific file. > > Signed-off-by: Daniel Henrique Barboza > Reviewed-by: Philippe Mathieu-Daudé > Reviewed-by: Andrew Jones > Reviewed-by: LIU Zhiwei Rev

Re: [PATCH v3 07/19] target/riscv/cpu.c: mark extensions arrays as 'const'

On Wed, Sep 20, 2023 at 9:21 PM Daniel Henrique Barboza wrote: > > We'll need to export these arrays to the accelerator classes in the next > patches. Mark them as 'const' now because they should not be modified at > runtime. > > Note that 'riscv_cpu_options' will also be exported, but can't be ma

Re: [PATCH v3 08/19] target/riscv: move riscv_cpu_add_kvm_properties() to kvm.c

On Wed, Sep 20, 2023 at 10:47 PM Daniel Henrique Barboza wrote: > > We'll introduce the KVM accelerator class with a 'cpu_instance_init' > implementation that is going to be invoked during the common > riscv_cpu_post_init() (via accel_cpu_instance_init()). This > instance_init will execute KVM exc

Re: [PATCH v6 2/2] tpm: add backend for mssim

Found this cleaning out old mail, sorry for missing it until now! I think we owe James a quick decision wether we're willing to take the feature. Stefan, thoughts? James Bottomley writes: > From: James Bottomley > > The Microsoft Simulator (mssim) is the reference emulation platform > for the

Re: [PATCH v3 09/19] target/riscv: make riscv_add_satp_mode_properties() public

On Wed, Sep 20, 2023 at 9:24 PM Daniel Henrique Barboza wrote: > > This function is used for both accelerators. Make it public, and call it > from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to > split KVM specific code for the KVM accelerator class in the next patch. > > Signed-o

Re: [PATCH v3 10/19] target/riscv: remove kvm-stub.c

On Wed, Sep 20, 2023 at 9:22 PM Daniel Henrique Barboza wrote: > > This file is not needed for some time now. Both kvm_riscv_reset_vcpu() > and kvm_riscv_set_irq() have public declarations in kvm_riscv.h and are > wrapped in 'if kvm_enabled()' blocks that the compiler will rip it out > in non-KVM

Re: [PATCH v3 11/19] target/riscv: introduce KVM AccelCPUClass

On Wed, Sep 20, 2023 at 9:23 PM Daniel Henrique Barboza wrote: > > Add a KVM accelerator class like we did with TCG. The difference is > that, at least for now, we won't be using a realize() implementation for > this accelerator. > > We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), rena

Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics

Nina Schoetterl-Glausch writes: > On Wed, 2023-09-20 at 12:57 +0200, Markus Armbruster wrote: >> Nina Schoetterl-Glausch writes: >> >> > On Tue, 2023-09-19 at 14:47 +0200, Markus Armbruster wrote: >> > > Nina Schoetterl-Glausch writes: >> > > >> > > > From: Pierre Morel >> > > > >> > > > S3

Re: [PATCH 1/2] pc_piix: remove pc-i440fx-1.4 up to pc-i440fx-1.7

On 21/09/2023 14.10, Paolo Bonzini wrote: These are the last users of the 128K SeaBIOS blob in the i440FX family. Removing them allows us to drop PCI support from the 128K blob, thus making it easier to update SeaBIOS to newer versions. Signed-off-by: Paolo Bonzini --- docs/about/deprecated.r

Re: [PATCH 2/2] seabios: remove PCI drivers from bios.bin

On 21/09/2023 14.10, Paolo Bonzini wrote: bios.bin is now used only by ISA PC, so PCI drivers are not necessary. Signed-off-by: Paolo Bonzini --- pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/config.seabios-128k | 30 ++ 2 files changed, 22 inserti

[PATCH v2 1/3] hw/misc: Introduce AMD/Xilix Versal TRNG device

This adds a non-cryptographic grade implementation of the model for the True Random Number Generator (TRNG) component in AMD/Xilinx Versal device family. This implements all 3 modes defined by the actual hardware specs, all of which selectable by guest software at will at anytime: 1) PRNG mode, in

[PATCH v2 0/3] AMD/Xilinx Versal TRNG support

This series adds support for the True Random Number Generator (TRNG) in the AMD/Xilinx Versal family of devices. The series starts by introducing a non-cryptographic grade model of the TRNG controller in the Versal family of devices, followed by instantiating the model in Xilinx Versal machine. T

[PATCH v2 2/3] hw/arm: xlnx-versal-virt: Add AMD/Xilinx TRNG device

Connect the support for Versal True Random Number Generator (TRNG) device. Warning: unlike the TRNG component in a real device from the Versal device familiy, the connected TRNG model is not of cryptographic grade and is not intended for use cases when cryptograpically strong TRNG is needed. Sign

[PATCH v2 3/3] tests/qtest: Introduce tests for AMD/Xilinx Versal TRNG device

Signed-off-by: Tong Ho --- tests/qtest/meson.build | 2 +- tests/qtest/xlnx-versal-trng-test.c | 490 2 files changed, 491 insertions(+), 1 deletion(-) create mode 100644 tests/qtest/xlnx-versal-trng-test.c diff --git a/tests/qtest/meson.build b/tests/

[PATCH 1/4] multifd: wait for channels_ready before sending sync

In multifd_send_sync_main we need to wait for channels_ready before submitting sync packet as the threads may still be sending their previous pages. There is also no need to check for channels_ready in the loop before the wait for sem_sync, next iteration of sending pages or another sync will start

[PATCH 2/4] migration: check for rate_limit_max for RATE_LIMIT_DISABLED

In migration rate limiting atomic operations are used to read the rate limit variables and transferred bytes and they are expensive. Check first if rate_limit_max is equal to RATE_LIMIT_DISABLED and return false immediately if so. Signed-off-by: Elena Ufimtseva --- migration/migration-stats.c |

[PATCH 3/4] multifd: fix counters in multifd_send_thread

Previous commit cbec7eb76879d419e7dbf531ee2506ec0722e825 "migration/multifd: Compute transferred bytes correctly" removed accounting for packet_len in non-rdma case, but the next_packet_size only accounts for pages, not for the header packet (normal_pages * PAGE_SIZE) that is being sent as iov[0].

[PATCH 0/4] multifd: various fixes

Hello While working and testing various live migration scenarios, a few issues were found. This is my first patches in live migration and I will appreciate the suggestions from the community if these patches could be done differently. [PATCH 1/4] multifd: wait for channels_ready before sending s

[PATCH 4/4] multifd: reset next_packet_len after sending pages

Sometimes multifd sends just sync packet with no pages (normal_num is 0). In this case the old value is being preserved and being accounted for while only packet_len is being transferred. Reset it to 0 after sending and accounting for. TODO: Fix the same packet ids in the stream. with this patch,

<    1   2   3