Re: [PATCH v10 7/8] MAINTAINERS: Add myself as maintainer for yank feature

Lukas Straub writes: > I'll maintain this for now as the colo usecase is the first user > of this functionality. > > Signed-off-by: Lukas Straub > Acked-by: Stefan Hajnoczi > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index

Re: [PATCH v10 1/8] Introduce yank feature

Lukas Straub writes: > The yank feature allows to recover from hanging qemu by "yanking" > at various parts. Other qemu systems can register themselves and > multiple yank functions. Then all yank functions for selected > instances can be called by the 'yank' out-of-band qmp command. > Available

[RFC v3 09/10] target/arm: introduce CPU feature dependency mechanism

Some CPU features are dependent on other CPU features. For example, ID_AA64PFR0_EL1.FP field and ID_AA64PFR0_EL1.AdvSIMD must have the same value, which means FP and ADVSIMD are dependent on each other, FPHP and ADVSIMDHP are dependent on each other. This commit introduces a mechanism for CPU

[RFC v3 08/10] target/arm: Introduce user_mask to indicate whether the feature is set explicitly

To add CPU feature dependencies, we need to known whether a CPU feature is set explicitly or automatically by dependencies mechanism. Introduce user_mask to do that. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- target/arm/cpu.c | 2 ++ target/arm/cpu.h | 1 + 2 files changed, 3

[RFC v3 04/10] target/arm: convert isar regs to array

The isar in ARMCPU is a struct, each field of which represents an ID register. It's not convenient for us to support CPU feature in AArch64. So let's change it to an array first and add an enum as the index of the array for convenience. Since we will never access high 32-bits of ID registers in

[RFC v3 00/10] Support disable/enable CPU features for AArch64

QEMU does not support disable/enable CPU features in AArch64 for now. This patch series add support for CPU features in AArch64. Firstly, we change the isar struct in ARMCPU to an array for convenience. Secondly, we add support to configure CPU feautres in AArch64 and make sure that the ID

[RFC v3 01/10] linux-header: Introduce KVM_CAP_ARM_CPU_FEATURE

Introduce KVM_CAP_ARM_CPU_FEATURE. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- linux-headers/linux/kvm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h index 43580c767c33..146eaec35d49 100644 ---

[RFC v3 06/10] target/arm: register CPU features for property

The Arm architecture specifies a number of ID registers that are characterized as comprising a set of 4-bit ID fields. Each ID field identifies the presence, and possibly the level of support for, a particular feature in an implementation of the architecture. [1] For most of the ID fields, there

[RFC v3 05/10] target/arm: Introduce kvm_arm_cpu_feature_supported

Introduce kvm_arm_cpu_feature_supported to check whether KVM supports to set CPU features in ARM. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- target/arm/kvm64.c | 14 ++ target/arm/kvm_arm.h | 7 +++ 2 files changed, 21 insertions(+) diff --git

[RFC v3 07/10] target/arm: Allow ID registers to synchronize to KVM

There are 2 steps to synchronize the values of system registers from CPU state to KVM: 1. write to the values of system registers from CPU state to (index,value) list by write_cpustate_to_list; 2. write the values in (index,value) list to KVM by write_list_to_kvmstate; In step 1, the values

[RFC v3 10/10] target/arm: Add CPU features to query-cpu-model-expansion

Add CPU features to the result of query-cpu-model-expansion so that other applications (such as libvirt) can know the supported CPU features. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- target/arm/monitor.c | 4 1 file changed, 4 insertions(+) diff --git

[RFC v3 03/10] target/arm: only set ID_PFR1_EL1.GIC for AArch32 guest

Some AArch64 CPU doesn't support AArch32 mode, AArch32 registers should be 0. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index

[RFC v3 02/10] target/arm: Update ID fields

Update definitions for ID fields, up to ARMv8.6. Signed-off-by: zhanghailiang Signed-off-by: Peng Liang --- target/arm/cpu.h | 17 + 1 file changed, 17 insertions(+) diff --git a/target/arm/cpu.h b/target/arm/cpu.h index c18a91676656..4c76fff1985f 100644 --- a/target/arm/cpu.h

[PATCH] pci/shpc: don't push attention button when ejecting powered-off device

When the slot is in steady powered-off state and the device is being removed, there's no need to press the attention button. Nor is it mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0. Moreover it confuses the guest, Linux in particular, as it assumes that the attention

Re: [PATCH] util: Remove redundant checks in the openpty()

On 2020/10/31 23:21, Peter Maydell wrote: > On Sat, 31 Oct 2020 at 11:04, AlexChen wrote: >> >> As we can see from the following function call stack, the amaster and the >> aslave >> cannot be NULL: char_pty_open() -> qemu_openpty_raw() -> openpty(). >> In addition, the amaster and the aslave

[PATCH V2] hw/display/exynos4210_fimd: Fix potential NULL pointer dereference

In exynos4210_fimd_update(), the pointer s is dereferinced before being check if it is valid, which may lead to NULL pointer dereference. So move the assignment to global_width after checking that the s is valid. Reported-by: Euler Robot Signed-off-by: Alex Chen ---

[Bug 1902470] Re: migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts

** Description changed: hi, I found that the multi-channel TLS-handshake will be stuck when the dst- libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so migration cannot be cancelled

[Bug 1902470] Re: migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts

** Description changed: hi, - I found that the multi-channel TLS-handshake will be stuck when the dst-libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so - migration cannot be cancelled

Re: [RFC PATCH v2 07/13] hw/arm/virt-acpi-build: distinguish possible and present cpus Message

On 10/30/2020 1:20 AM, Andrew Jones wrote: You need to remove 'Message' from the summary. On Tue, Oct 20, 2020 at 09:14:34PM +0800, Ying Fang wrote: When building ACPI tables regarding CPUs we should always build them for the number of possible CPUs, not the number of present CPUs. We then

[Bug 1902470] [NEW] migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts

Public bug reported: hi, I found that the multi-channel TLS-handshake will be stuck when the dst- libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so migration cannot be cancelled though src-

Re: Out-of-Process Device Emulation session at KVM Forum 2020

On 2020/10/30 下午7:13, Stefan Hajnoczi wrote: I still don't get why it must be opaque. If the device state format needs to be in the VMM then each device needs explicit enablement in each VMM (QEMU, cloud-hypervisor, etc). Let's invert the question: why does the VMM need to understand the

Re: Out-of-Process Device Emulation session at KVM Forum 2020

On 2020/11/1 下午4:26, Paolo Bonzini wrote: Il sab 31 ott 2020, 22:49 Michael S. Tsirkin > ha scritto: > > I still don't get why it must be opaque. > > If the device state format needs to be in the VMM then each device > needs explicit enablement in

Re: Out-of-Process Device Emulation session at KVM Forum 2020

On 2020/10/30 下午9:15, Stefan Hajnoczi wrote: On Fri, Oct 30, 2020 at 12:08 PM Jason Wang wrote: On 2020/10/30 下午7:13, Stefan Hajnoczi wrote: On Fri, Oct 30, 2020 at 9:46 AM Jason Wang wrote: On 2020/10/30 下午2:21, Stefan Hajnoczi wrote: On Fri, Oct 30, 2020 at 3:04 AM Alex Williamson

Re: [PATCH 2/4] hw/pci-host/prep: Remove legacy PReP machine temporary workaround

On Mon, Oct 12, 2020 at 09:19:04AM +0200, Philippe Mathieu-Daudé wrote: > The legacy PReP machine has been removed in commit b2ce76a0730 > ("hw/ppc/prep: Remove the deprecated "prep" machine and the > OpenHackware BIOS"). This temporary workaround is no more > required, remove it. > >

Re: [PATCH 1/4] hw/pci-host/prep: Update coding style to make checkpatch.pl happy

On Mon, Oct 12, 2020 at 09:19:03AM +0200, Philippe Mathieu-Daudé wrote: > To make the next commit easier to review, clean this code first. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Gibson > --- > hw/pci-host/prep.c | 6 -- > 1 file changed, 4 insertions(+), 2

Re: [PATCH 4/5] spapr: Pass _abort when getting some PC DIMM properties

On Fri, Oct 30, 2020 at 02:25:42PM +0100, Greg Kurz wrote: > On Wed, 28 Oct 2020 16:22:16 +0100 > Igor Mammedov wrote: > > > On Tue, 27 Oct 2020 16:18:58 +0100 > > Greg Kurz wrote: > > > [...] > > > > > > It might require some more code refactoring because the way regular > > > PC-DIMMs are

Re: [PATCH-for-5.2 v3] util/cutils: Fix Coverity array overrun in freq_to_str()

On Sun, 1 Nov 2020 at 21:57, Philippe Mathieu-Daudé wrote: > > Fix Coverity CID 1435957: Memory - illegal accesses (OVERRUN): > > >>> Overrunning array "suffixes" of 7 8-byte elements at element > index 7 (byte offset 63) using index "idx" (which evaluates to 7). > > Note, the biggest input

[PATCH-for-5.2 v3] util/cutils: Fix Coverity array overrun in freq_to_str()

Fix Coverity CID 1435957: Memory - illegal accesses (OVERRUN): >>> Overrunning array "suffixes" of 7 8-byte elements at element index 7 (byte offset 63) using index "idx" (which evaluates to 7). Note, the biggest input value freq_to_str() can accept is UINT64_MAX, which is ~18.446 EHz, less

[PATCH-for-5.2 v2] util/cutils: Fix Coverity array overrun in freq_to_str()

Rewrite the iteration to avoid an array overrun. This fixes CID 1435957: Memory - illegal accesses (OVERRUN): >>> Overrunning array "suffixes" of 7 8-byte elements at element index 7 (byte offset 63) using index "idx" (which evaluates to 7). Note, the biggest input value freq_to_str() can

[PATCH-for-5.2] scripts/oss-fuzz: rename bin/qemu-fuzz-i386

OSS-Fuzz changed the way it scans for fuzzers in $DEST_DIR. The new code also scans subdirectories for fuzzers. This means that OSS-Fuzz is considering bin/qemu-fuzz-i386 as an independent fuzzer (it is not - it requires a --fuzz-target argument). This has led to coverage-build failures and false

Re: [PATCH v2 14/19] RFC: accel/tcg: Support split-rwx for darwin/iOS with vm_remap

Another change I made in alloc_code_gen_buffer_mirror_vmremap (in my patch as well) is to remove VM_FLAGS_RANDOM_ADDR. This was causing a rare out of memory error whenever the random address it chooses is too high. -j On Sat, Oct 31, 2020 at 6:42 PM Joelle van Dyne wrote: > > There's a compiler

[Bug 1902451] Re: incorrect cpuid feature detection

** Tags added: cpuid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1902451 Title: incorrect cpuid feature detection Status in QEMU: New Bug description: Hello, I am currently developing a

[PULL v3 25/32] s390x/pci: create a header dedicated to PCI CLP

From: Pierre Morel To have a clean separation between s390-pci-bus.h and s390-pci-inst.h headers we export the PCI CLP instructions in a dedicated header. Signed-off-by: Pierre Morel Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson ---

[PULL v3 31/32] hw/vfio: Use lock guard macros

From: Amey Narkhede Use qemu LOCK_GUARD macros in hw/vfio. Saves manual unlock calls Signed-off-by: Amey Narkhede Signed-off-by: Alex Williamson --- hw/vfio/platform.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c index

[PULL v3 30/32] s390x/pci: get zPCI function info from host

From: Matthew Rosato We use the capability chains of the VFIO_DEVICE_GET_INFO ioctl to retrieve the CLP information that the kernel exports. To be compatible with previous kernel versions we fall back on previous predefined values, same as the emulation values, when the ioctl is found to not

[PULL v3 32/32] vfio: fix incorrect print type

From: Zhengui li The type of input variable is unsigned int while the printer type is int. So fix incorrect print type. Signed-off-by: Zhengui li Signed-off-by: Alex Williamson --- hw/vfio/common.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/vfio/common.c

[PULL v3 26/32] s390x/pci: use a PCI Group structure

From: Pierre Morel We use a S390PCIGroup structure to hold the information related to a zPCI Function group. This allows us to be ready to support multiple groups and to retrieve the group information from the host. Signed-off-by: Pierre Morel Signed-off-by: Matthew Rosato Reviewed-by:

[PULL v3 23/32] s390x/pci: Add routine to get the vfio dma available count

From: Matthew Rosato Create new files for separating out vfio-specific work for s390 pci. Add the first such routine, which issues VFIO_IOMMU_GET_INFO ioctl to collect the current dma available count. Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck [aw: Fix non-Linux build with

[PULL v3 29/32] vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities

From: Matthew Rosato Now that VFIO_DEVICE_GET_INFO supports capability chains, add a helper function to find specific capabilities in the chain. Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson --- hw/vfio/common.c | 10 ++

[PULL v3 24/32] s390x/pci: Honor DMA limits set by vfio

From: Matthew Rosato When an s390 guest is using lazy unmapping, it can result in a very large number of oustanding DMA requests, far beyond the default limit configured for vfio. Let's track DMA usage similar to vfio in the host, and trigger the guest to flush their DMA mappings before vfio

[PULL v3 22/32] vfio: Find DMA available capability

From: Matthew Rosato The underlying host may be limiting the number of outstanding DMA requests for type 1 IOMMU. Add helper functions to check for the DMA available capability and retrieve the current number of DMA mappings allowed. Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck

[PULL v3 16/32] vfio: Make vfio-pci device migration capable

From: Kirti Wankhede If the device is not a failover primary device, call vfio_migration_probe() and vfio_migration_finalize() to enable migration support for those devices that support it respectively to tear it down again. Removed migration blocker from VFIO PCI device specific structure and

[PULL v3 28/32] s390x/pci: use a PCI Function structure

From: Pierre Morel We use a ClpRspQueryPci structure to hold the information related to a zPCI Function. This allows us to be ready to support different zPCI functions and to retrieve the zPCI function information from the host. Signed-off-by: Pierre Morel Signed-off-by: Matthew Rosato

[PULL v3 21/32] vfio: Create shared routine for scanning info capabilities

From: Matthew Rosato Rather than duplicating the same loop in multiple locations, create a static function to do the work. Signed-off-by: Matthew Rosato Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson --- hw/vfio/common.c | 21

[PULL v3 19/32] linux-headers: update against 5.10-rc1

From: Matthew Rosato commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec Signed-off-by: Matthew Rosato [aw: drop pvrdma_ring.h changes to avoid revert of d73415a31547 ("qemu/atomic.h: rename atomic_ to qatomic_")] Signed-off-by: Alex Williamson --- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h

[PULL v3 27/32] s390x/pci: clean up s390 PCI groups

From: Matthew Rosato Add a step to remove all stashed PCI groups to avoid stale data between machine resets. Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson --- hw/s390x/s390-pci-bus.c | 12 1 file changed, 12 insertions(+) diff --git

[PULL v3 15/32] vfio: Add ioctl to get dirty pages bitmap during dma unmap

From: Kirti Wankhede With vIOMMU, IO virtual address range can get unmapped while in pre-copy phase of migration. In that case, unmap ioctl should return pages pinned in that range and QEMU should find its correcponding guest physical addresses and report those dirty. Suggested-by: Alex

[PULL v3 11/32] vfio: Get migration capability flags for container

From: Kirti Wankhede Added helper functions to get IOMMU info capability chain. Added function to get migration capability information from that capability chain for IOMMU container. Similar change was proposed earlier: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg03759.html

[PULL v3 20/32] s390x/pci: Move header files to include/hw/s390x

From: Matthew Rosato Seems a more appropriate location for them. Signed-off-by: Matthew Rosato Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson --- MAINTAINERS |1 hw/s390x/s390-pci-bus.c |4 hw/s390x/s390-pci-bus.h | 372

[PULL v3 17/32] qapi: Add VFIO devices migration stats in Migration stats

From: Kirti Wankhede Added amount of bytes transferred to the VM at destination by all VFIO devices Signed-off-by: Kirti Wankhede Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Alex Williamson --- hw/vfio/common.c | 19 +++ hw/vfio/migration.c |

[PULL v3 14/32] vfio: Dirty page tracking when vIOMMU is enabled

From: Kirti Wankhede When vIOMMU is enabled, register MAP notifier from log_sync when all devices in container are in stop and copy phase of migration. Call replay and get dirty pages from notifier callback. Suggested-by: Alex Williamson Signed-off-by: Kirti Wankhede Reviewed-by: Yan Zhao

[PULL v3 18/32] update-linux-headers: Add vfio_zdev.h

From: Matthew Rosato vfio_zdev.h is used by s390x zPCI support to pass device-specific CLP information between host and userspace. Signed-off-by: Matthew Rosato Acked-by: Cornelia Huck Signed-off-by: Alex Williamson --- scripts/update-linux-headers.sh |2 +- 1 file changed, 1

[PULL v3 13/32] vfio: Add vfio_listener_log_sync to mark dirty pages

From: Kirti Wankhede vfio_listener_log_sync gets list of dirty pages from container using VFIO_IOMMU_GET_DIRTY_BITMAP ioctl and mark those pages dirty when all devices are stopped and saving state. Return early for the RAM block section of mapped MMIO region. Signed-off-by: Kirti Wankhede

[PULL v3 10/32] memory: Set DIRTY_MEMORY_MIGRATION when IOMMU is enabled

From: Kirti Wankhede mr->ram_block is NULL when mr->is_iommu is true, then fr.dirty_log_mask wasn't set correctly due to which memory listener's log_sync doesn't get called. This patch returns log_mask with DIRTY_MEMORY_MIGRATION set when IOMMU is enabled. Signed-off-by: Kirti Wankhede

[PULL v3 12/32] vfio: Add function to start and stop dirty pages tracking

From: Kirti Wankhede Call VFIO_IOMMU_DIRTY_PAGES ioctl to start and stop dirty pages tracking for VFIO devices. Signed-off-by: Kirti Wankhede Reviewed-by: Dr. David Alan Gilbert Signed-off-by: Alex Williamson --- hw/vfio/migration.c | 36 1 file

[PULL v3 08/32] vfio: Add save state functions to SaveVMHandlers

From: Kirti Wankhede Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy functions. These functions handles pre-copy and stop-and-copy phase. In _SAVING|_RUNNING device state or pre-copy phase: - read pending_bytes. If pending_bytes > 0, go through below steps. - read

[PULL v3 07/32] vfio: Register SaveVMHandlers for VFIO device

From: Kirti Wankhede Define flags to be used as delimiter in migration stream for VFIO devices. Added .save_setup and .save_cleanup functions. Map & unmap migration region from these functions at source during saving or pre-copy phase. Set VFIO device state depending on VM's state. During live

[PULL v3 09/32] vfio: Add load state functions to SaveVMHandlers

From: Kirti Wankhede Sequence during _RESUMING device state: While data for this device is available, repeat below steps: a. read data_offset from where user application should write data. b. write data of data_size to migration region from data_offset. c. write data_size which indicates vendor

[PULL v3 05/32] vfio: Add VM state change handler to know state of VM

From: Kirti Wankhede VM state change handler is called on change in VM's state. Based on VM state, VFIO device state should be changed. Added read/write helper functions for migration region. Added function to set device_state. Signed-off-by: Kirti Wankhede Reviewed-by: Neo Jia Reviewed-by:

[PULL v3 03/32] vfio: Add save and load functions for VFIO PCI devices

From: Kirti Wankhede Added functions to save and restore PCI device specific data, specifically config space of PCI device. Signed-off-by: Kirti Wankhede Reviewed-by: Neo Jia Signed-off-by: Alex Williamson --- hw/vfio/pci.c | 51 +

[PULL v3 06/32] vfio: Add migration state change notifier

From: Kirti Wankhede Added migration state change notifier to get notification on migration state change. These states are translated to VFIO device state and conveyed to vendor driver. Signed-off-by: Kirti Wankhede Reviewed-by: Neo Jia Reviewed-by: Dr. David Alan Gilbert Reviewed-by:

[PULL v3 02/32] vfio: Add vfio_get_object callback to VFIODeviceOps

From: Kirti Wankhede Hook vfio_get_object callback for PCI devices. Signed-off-by: Kirti Wankhede Reviewed-by: Neo Jia Suggested-by: Cornelia Huck Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson --- hw/vfio/pci.c |8 include/hw/vfio/vfio-common.h |

[PULL v3 04/32] vfio: Add migration region initialization and finalize function

From: Kirti Wankhede Whether the VFIO device supports migration or not is decided based of migration region query. If migration region query is successful and migration region initialization is successful then migration is supported else migration is blocked. Signed-off-by: Kirti Wankhede

[PULL v3 01/32] vfio: Add function to unmap VFIO region

From: Kirti Wankhede This function will be used for migration region. Migration region is mmaped when migration starts and will be unmapped when migration is complete. Signed-off-by: Kirti Wankhede Reviewed-by: Neo Jia Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson ---

[PULL v3 00/32] VFIO updates 2020-11-01 (for QEMU 5.2 soft-freeze)

Aggregated interdiff versus v1 pull request below. Thanks, Alex The following changes since commit 700d20b49e303549b32d3a7a3efbfcee8c7a4f6c: Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2020-11-01 14:02:19 +) are available in the Git repository at:

[Bug 1902451] [NEW] incorrect cpuid feature detection

Public bug reported: Hello, I am currently developing a x64 kernel and I wanted to check through cpuid if some features are available in the guest. When I try to enable cpu features like vmcb_clean or constant_tsc qemu is saying that my host doesn't support the requested features. However cat

Re: [PULL v2 00/32] VFIO updates 2020-10-28 (for QEMU 5.2 soft-freeze)

On Sat, 31 Oct 2020 14:54:54 + Peter Maydell wrote: > On Wed, 28 Oct 2020 at 16:42, Alex Williamson > wrote: > > > > The following changes since commit 33dc9914eac581dea9bdea35dcda4d542531d66a: > > > > Revert series: virtiofsd: Announce submounts to the guest (2020-10-28 > > 13:17:32

Re: [PATCH v3 0/2] 9pfs: test suite fixes

On 01/11/2020 19:17, Christian Schoenebeck wrote: Yes, that should be resolved with the next 9p PR as well, additionally with the following patch that is: https://github.com/cschoenebeck/qemu/commit/603cc76a6069 Thanks for the feedback! Fantastic - thanks a lot :) ATB, Mark.

Re: [PATCH v3 2/2] tests/9pfs: fix test dir for parallel tests

On Sun, 01 Nov 2020 20:14:16 +0100 Christian Schoenebeck wrote: > On Sonntag, 1. November 2020 18:44:44 CET Greg Kurz wrote: > > On Sun, 1 Nov 2020 15:37:12 +0100 > > > > Christian Schoenebeck wrote: > > > Use mkdtemp() to generate a unique directory for the 9p 'local' tests. > > > > > > This

Re: [PATCH v3 0/2] 9pfs: test suite fixes

On Sonntag, 1. November 2020 19:02:28 CET Mark Cave-Ayland wrote: > On 01/11/2020 15:12, Christian Schoenebeck wrote: > > Fixes test failures with the 9pfs 'local' tests as discussed with latest > > 9P PR. See the discussion of that PR v2 (Fri, Oct 30th) for details. > > > > In conjunction with

Re: [PATCH v3 2/2] tests/9pfs: fix test dir for parallel tests

On Sonntag, 1. November 2020 18:44:44 CET Greg Kurz wrote: > On Sun, 1 Nov 2020 15:37:12 +0100 > > Christian Schoenebeck wrote: > > Use mkdtemp() to generate a unique directory for the 9p 'local' tests. > > > > This fixes occasional 9p test failures when running 'make check -jN' if > > QEMU was

Re: [PULL 00/15] pc,pci,vhost,virtio: misc fixes

On Fri, 30 Oct 2020 at 14:11, Michael S. Tsirkin wrote: > > The following changes since commit 802427bcdae1ad2eceea8a8877ecad835e3f8fde: > > Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20201027-1' into staging (2020-10-29 > 11:40:04 +) > > are available in the

Re: [PATCH v3 0/2] 9pfs: test suite fixes

On 01/11/2020 15:12, Christian Schoenebeck wrote: Fixes test failures with the 9pfs 'local' tests as discussed with latest 9P PR. See the discussion of that PR v2 (Fri, Oct 30th) for details. In conjunction with Peter Xu's two migration patches (fixing occasional lockups of migration tests)

Re: [PATCH v3 2/2] tests/9pfs: fix test dir for parallel tests

On Sun, 1 Nov 2020 15:37:12 +0100 Christian Schoenebeck wrote: > Use mkdtemp() to generate a unique directory for the 9p 'local' tests. > > This fixes occasional 9p test failures when running 'make check -jN' if > QEMU was compiled for multiple target architectures, because the individual >

[PATCH v4] hw/riscv: microchip_pfsoc: Correct DDR memory map

From: Bin Meng When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10__. Address 0xC000_ and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_.

Re: [PATCH v3 1/2] tests/9pfs: make create/remove test dir public

On Sun, 1 Nov 2020 15:25:14 +0100 Christian Schoenebeck wrote: > Make functions create_local_test_dir() and remove_local_test_dir() > public. They're going to be used in the next patch. > > Signed-off-by: Christian Schoenebeck > --- Reviewed-by: Greg Kurz > tests/qtest/libqos/virtio-9p.c |

Re: [PATCH v3] hw/riscv: microchip_pfsoc: Correct DDR memory map

On Sun, Nov 1, 2020 at 8:51 AM Bin Meng wrote: > > Hi Alistair, > > On Mon, Nov 2, 2020 at 12:46 AM Alistair Francis wrote: > > > > On Sun, Nov 1, 2020 at 8:42 AM Bin Meng wrote: > > > > > > From: Bin Meng > > > > > > When system memory is larger than 1 GiB (high memory), PolarFire SoC > > >

Re: [PATCH v3] hw/riscv: microchip_pfsoc: Correct DDR memory map

Hi Alistair, On Mon, Nov 2, 2020 at 12:46 AM Alistair Francis wrote: > > On Sun, Nov 1, 2020 at 8:42 AM Bin Meng wrote: > > > > From: Bin Meng > > > > When system memory is larger than 1 GiB (high memory), PolarFire SoC > > maps it at address 0x10__. Address 0xC000_ and above is >

Re: [PATCH v3] hw/riscv: microchip_pfsoc: Correct DDR memory map

On Sun, Nov 1, 2020 at 8:42 AM Bin Meng wrote: > > From: Bin Meng > > When system memory is larger than 1 GiB (high memory), PolarFire SoC > maps it at address 0x10__. Address 0xC000_ and above is > aliased to the same 1 GiB low memory with different cache attributes. > > At present

[PATCH v3] hw/riscv: microchip_pfsoc: Correct DDR memory map

From: Bin Meng When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10__. Address 0xC000_ and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_.

Re: [PULL 00/18] riscv-to-apply queue

On Sun, Nov 1, 2020 at 10:02 PM Peter Maydell wrote: > > On Thu, 29 Oct 2020 at 14:25, Alistair Francis > wrote: > > > > The following changes since commit c0444009147aa935d52d5acfc6b70094bb42b0dd: > > > > Merge remote-tracking branch 'remotes/armbru/tags/pull-qmp-2020-10-27' > > into

[PATCH v2 2/2] iotests: rewrite iotest 240 in python

The recent changes that brought RCU delayed device deletion, broke few tests and this test breakage went unnoticed. Fix this test by rewriting it in python (which allows to wait for DEVICE_DELETED events before continuing). Signed-off-by: Maxim Levitsky --- tests/qemu-iotests/240 | 228

[PATCH v2 0/2] Assorted fixes to tests that were broken by recent scsi changes

While most of the patches in V1 of this series are already merged upstream, the patch that fixes iotest 240 was broken on s390 and was not accepted. This is an updated version of this patch, based on Paulo's suggestion, that hopefully makes this iotest work on both x86 and s390. Best regards,

[PATCH v2 1/2] iotests: add filter_qmp_virtio_scsi function

filter_qmp_virtio_scsi can be used to filter virtio-scsi-pci/ccw differences. Note that this patch was only tested on x86. Suggested-by: Paolo Bonzini Signed-off-by: Maxim Levitsky --- tests/qemu-iotests/iotests.py | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v3 2/2] tests/9pfs: fix test dir for parallel tests

Use mkdtemp() to generate a unique directory for the 9p 'local' tests. This fixes occasional 9p test failures when running 'make check -jN' if QEMU was compiled for multiple target architectures, because the individual architecture's test suites would run in parallel and interfere with each

[PATCH v3 0/2] 9pfs: test suite fixes

Fixes test failures with the 9pfs 'local' tests as discussed with latest 9P PR. See the discussion of that PR v2 (Fri, Oct 30th) for details. In conjunction with Peter Xu's two migration patches (fixing occasional lockups of migration tests) overall situation appears to be smooth now:

[PATCH v3 1/2] tests/9pfs: make create/remove test dir public

Make functions create_local_test_dir() and remove_local_test_dir() public. They're going to be used in the next patch. Signed-off-by: Christian Schoenebeck --- tests/qtest/libqos/virtio-9p.c | 10 -- tests/qtest/libqos/virtio-9p.h | 10 ++ 2 files changed, 14 insertions(+), 6

Re: [PATCH v2 18/19] tcg/aarch64: Implement flush_idcache_range manually

On 10/31/20 6:25 PM, Joelle van Dyne wrote: > Another thing, for x86 (and maybe other archs), the icache is cache > coherent but does it apply if we are aliasing the memory address? I > think in that case, it's like we're doing a DMA right and still need > to do flushing+invalidating? No, it is

Re: [PULL 00/15] pc,pci,vhost,virtio: misc fixes

On Fri, 30 Oct 2020 at 14:33, wrote: > > Patchew URL: https://patchew.org/QEMU/20201030141136.1013521-1-...@redhat.com/ I'll apply this pullreq (unless it has other more serious issues), but could you look at the coding style warnings in a followup patch, please? > 9/15 Checking commit

Re: [PULL 00/18] riscv-to-apply queue

On Thu, 29 Oct 2020 at 14:25, Alistair Francis wrote: > > The following changes since commit c0444009147aa935d52d5acfc6b70094bb42b0dd: > > Merge remote-tracking branch 'remotes/armbru/tags/pull-qmp-2020-10-27' into > staging (2020-10-29 10:03:32 +) > > are available in the Git repository

[PATCH] hw/input/ps2.c: Remove remnants of printf debug

In commit 5edab03d4040 we added tracepoints to the ps2 keyboard and mouse emulation. However we didn't remove all the debug-by-printf support. In fact there is only one printf() remaining, and it is redundant with the trace_ps2_write_mouse() event next to it. Remove the printf() and the now-unused

Re: [PULL v2 01/16] tests/9pfs: fix test dir for parallel tests

On Samstag, 31. Oktober 2020 14:20:27 CET Christian Schoenebeck wrote: > On Freitag, 30. Oktober 2020 13:07:03 CET Christian Schoenebeck wrote: > > Use mkdtemp() to generate a unique directory for the 9p 'local' tests. > > > > This fixes occasional 9p test failures when running 'make check -jN'

Re: [PULL 0/5] Modules 20201029 patches

On Thu, 29 Oct 2020 at 11:16, Gerd Hoffmann wrote: > > The following changes since commit bbc48d2bcb9711614fbe751c2c5ae13e172fbca8: > > Merge remote-tracking branch 'remotes/philmd-gitlab/tags/renesas-20201027' > into staging (2020-10-28 16:25:31 +) > > are available in the Git repository

Re: [PULL 00/16] migration queue

On Samstag, 31. Oktober 2020 20:10:49 CET Christian Schoenebeck wrote: > On Samstag, 31. Oktober 2020 18:46:11 CET Peter Xu wrote: > > On Sat, Oct 31, 2020 at 05:26:28PM +, Peter Maydell wrote: > > > On Sat, 31 Oct 2020 at 16:12, Christian Schoenebeck > > > > > > wrote: > > > > On Montag,

Re: simple example of pci driver with dma

Hi Shaked, In the prob function, before you are trying to do any DMA operations with your device, you should call pci_enable_device and then pci_set_master. Also you might need to map the resources of your device. Check PCI driver documentation:

Re: Out-of-Process Device Emulation session at KVM Forum 2020

Il sab 31 ott 2020, 22:49 Michael S. Tsirkin ha scritto: > > > I still don't get why it must be opaque. > > > > If the device state format needs to be in the VMM then each device > > needs explicit enablement in each VMM (QEMU, cloud-hypervisor, etc). > > And QEMU cares why exactly? > QEMU

Re: [PATCH v2 01/19] tcg: Enhance flush_icache_range with separate data pointer

s->code_ptr and s->code_buf are 4 byte pointers on aarch64 so the cache flush is off by a factor of 4 diff --git a/tcg/tcg.c b/tcg/tcg.c index 44b923f5fe..2c4b66965b 100644 --- a/tcg/tcg.c +++ b/tcg/tcg.c @@ -4325,7 +4325,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb) /* flush