Re: [PATCH v3 2/2] target/riscv: Restrict midelegh access to S-mode harts

I intended to separate the S-mode and M-mode handling. Do you think this change could improve performance? Thanks, Jay Chang On Tue, Jul 1, 2025 at 11:46 AM Nutty Liu wrote: > On 7/1/2025 11:00 AM, Jay Chang wrote: > > RISC-V AIA Spec states: > > "For a machine-level en

[PATCH v3 0/2] Add S-mode checks for delegation-related CSRs

updated predicate in aia_smode32. Change log: V3: * Add cover letter Jay Chang (2): target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts target/riscv: Restrict midelegh access to S-mode harts target/riscv/csr.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) -- 2.48.1

[PATCH v3 1/2] target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts

deleg registers should not exist." Add smode predicate to ensure these CSRs are only accessible when S-mode is supported. Reviewed-by: Frank Chang Reviewed-by: Alistair Francis Signed-off-by: Jay Chang --- target/riscv/csr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --gi

[PATCH v3 2/2] target/riscv: Restrict midelegh access to S-mode harts

me as Smaia except excluding the machine-level CSRs and behavior not directly visible to supervisor level." Since midelegh is an AIA machine-mode CSR, add Smaia extension check in aia_smode32 predicate. Reviewed-by: Frank Chang Reviewed-by: Alistair Francis Signed-off-by: Jay Chang --- ta

Re: [PATCH v2 1/2] target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts

Hi, Gentle ping on this patch. Thanks, Jay Chang On Tue, Apr 1, 2025 at 6:34 PM Jay Chang wrote: > RISC-V Privileged Spec states: > "In harts with S-mode, the medeleg and mideleg registers must exist, and > setting a bit in medeleg or mideleg will delegate the corresponding

[PATCH v5 2/2] target/riscv: Make PMP region count configurable

behavior. A new CPU parameter num-pmp-regions has been introduced to the QEMU command line. For example: -cpu rv64, g=true, c=true, pmp=true, num-pmp-regions=8 Signed-off-by: Jay Chang Reviewed-by: Frank Chang --- target/riscv/cpu.c| 48

[PATCH v5 0/2] Extend and configure PMP region count

uld set its own default if they want. (based on feedback from Daniel) Jay Chang (2): target/riscv: Extend PMP region up to 64 target/riscv: Make PMP region count configurable target/riscv/cpu.c| 48 ++- target/riscv/cpu.h| 3 +- target/ri

[PATCH v5 1/2] target/riscv: Extend PMP region up to 64

According to the RISC-V Privileged Specification (version >1.12), RV32 supports 16 CSRs (pmpcfg0–pmpcfg15) to configure 64 PMP regions (pmpaddr0–pmpaddr63). Signed-off-by: Jay Chang Reviewed-by: Frank Chang Reviewed-by: Alistair Francis Reviewed-by: Daniel Henrique Barboza --- target/ri

Re: [PATCH v4 2/2] target/riscv: Make PMP region count configurable

*Hi Daniel,* You're absolutely right — thanks for pointing it out and providing the fix! Would you like me to send out a v5 patch incorporating your changes? Best Regards Jay Chang On Thu, Jun 5, 2025 at 2:20 AM Daniel Henrique Barboza < dbarb...@ventanamicro.com> wrote: >

[PATCH v3 0/2] Extend and configure PMP region count

pmp-regions`. This allows platforms to adjust the number of PMP regions without relying on a fixed default value. If unspecified, the default remains 16 to preserve compatibility. Change log: V3: * Changed `pmp_regions` type from `uint16_t` to `uint8_t` * Introduced `OLD_MAX_RISCV_PMPS` macro

[PATCH v4 2/2] target/riscv: Make PMP region count configurable

behavior. A new CPU parameter num-pmp-regions has been introduced to the QEMU command line. For example: -cpu rv64, g=true, c=true, pmp=true, num-pmp-regions=8 Signed-off-by: Jay Chang Reviewed-by: Frank Chang --- target/riscv/cpu.c| 54

[PATCH v4 1/2] target/riscv: Extend PMP region up to 64

According to the RISC-V Privileged Specification (version >1.12), RV32 supports 16 CSRs (pmpcfg0–pmpcfg15) to configure 64 PMP regions (pmpaddr0–pmpaddr63). Signed-off-by: Jay Chang Reviewed-by: Frank Chang Reviewed-by: Alistair Francis Reviewed-by: Daniel Henrique Barboza --- target/ri

[PATCH v4 0/2] Extend and configure PMP region count

pmp-regions`. This allows platforms to adjust the number of PMP regions without relying on a fixed default value. If unspecified, the default remains 16 to preserve compatibility. Change log: V4: * Changed `pmp_regions` type from `uint16_t` to `uint8_t` * Introduced `OLD_MAX_RISCV_PMPS` macro

[PATCH v3 2/2] target/riscv: Make PMP region count configurable

behavior. A new CPU parameter num-pmp-regions has been introduced to the QEMU command line. For example: -cpu rv64, g=true, c=true, pmp=true, num-pmp-regions=8 Signed-off-by: Jay Chang Reviewed-by: Frank Chang --- target/riscv/cpu.c| 54

[PATCH v3 1/2] target/riscv: Extend PMP region up to 64

According to the RISC-V Privileged Specification (version >1.12), RV32 supports 16 CSRs (pmpcfg0–pmpcfg15) to configure 64 PMP regions (pmpaddr0–pmpaddr63). Signed-off-by: Jay Chang Reviewed-by: Frank Chang Reviewed-by: Alistair Francis Reviewed-by: Daniel Henrique Barboza --- target/ri

[PATCH v2 1/2] target/riscv: Extend PMP region up to 64

According to the RISC-V Privileged Specification (version >1.12), RV32 supports 16 CSRs (pmpcfg0–pmpcfg15) to configure 64 PMP regions (pmpaddr0–pmpaddr63). Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/cpu_bits.h | 60 +++ target/riscv/csr.c |

[PATCH v2 0/2] Extend and configure PMP region count

pmp-regions`. This allows platforms to adjust the number of PMP regions without relying on a fixed default value. If unspecified, the default remains 16 to preserve compatibility. change log: V2: * Rebase on riscv-to-apply.next Jay Chang (2): target/riscv: Extend PMP region up to 64 target/ri

[PATCH v2 2/2] target/riscv: Make PMP region count configurable

behavior. A new CPU parameter num-pmp-regions has been introduced to the QEMU command line. For example: -cpu rv64, g=true, c=true, pmp=true, num-pmp-regions=8 Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/cpu.c| 54

Re: [PATCH 2/2] target/riscv: Make PMP region count configurable

I will send v2 patch Jay Chang On Thu, Apr 24, 2025 at 6:55 PM Alistair Francis wrote: > On Mon, Apr 21, 2025 at 7:48 PM Jay Chang wrote: > > > > Previously, the number of PMP regions was hardcoded to 16 in QEMU. > > This patch replaces the fixed value with a ne

[PATCH 1/2] target/riscv: Extend PMP region up to 64

According to the RISC-V Privileged Specification (version >1.12), RV32 supports 16 CSRs (pmpcfg0–pmpcfg15) to configure 64 PMP regions (pmpaddr0–pmpaddr63). Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/cpu_bits.h | 60 +++ target/riscv/csr.c |

[PATCH 2/2] target/riscv: Make PMP region count configurable

behavior. A new CPU parameter num-pmp-regions has been introduced to the QEMU command line. For example: -cpu rv64, g=true, c=true, pmp=true, num-pmp-regions=8 Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/cpu.c | 46

[PATCH 0/2] Extend and configure PMP region count

pmp-regions`. This allows platforms to adjust the number of PMP regions without relying on a fixed default value. If unspecified, the default remains 16 to preserve compatibility. Jay Chang (2): target/riscv: Extend PMP region up to 64 target/riscv: Make PMP region count configurable target/ri

[PATCH 2/2] target/riscv: Restrict midelegh access to S-mode harts

me as Smaia except excluding the machine-level CSRs and behavior not directly visible to supervisor level." Since midelegh is an AIA machine-mode CSR, add Smaia extension check in aia_smode32 predicate. Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/csr.c | 7 +-- 1 fi

[PATCH v2 2/2] target/riscv: Restrict midelegh access to S-mode harts

me as Smaia except excluding the machine-level CSRs and behavior not directly visible to supervisor level." Since midelegh is an AIA machine-mode CSR, add Smaia extension check in aia_smode32 predicate. Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/csr.c | 7 +-- 1 fi

[PATCH v2 1/2] target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts

deleg registers should not exist." Add smode predicate to ensure these CSRs are only accessible when S-mode is supported. Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/csr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/riscv/csr.c b/ta

Re: [PATCH 2/2] target/riscv: Restrict midelegh access to S-mode harts

Thanks for the feedback! You're right — I missed initializing csr_priv. In this case, we only want to check for privilege M-mode CSRs along with the smaia condition. I’ll fix it by adding: "int csr_priv = get_field(csrno, 0x300);" Jay On Wed, Mar 19, 2025 at 8:59 PM Daniel H

[PATCH 1/2] target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts

deleg registers should not exist." Add smode predicate to ensure these CSRs are only accessible when S-mode is supported. Reviewed-by: Frank Chang Signed-off-by: Jay Chang --- target/riscv/csr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/riscv/csr.c b/ta

Re: [PATCH V2] hw/intc: Handle software disabling of APIC correctly

On Wed, Sep 07, 2022 at 11:14:11PM +0530, Jay Khandkar wrote: > When the local APIC is in a software disabled state, all local interrupt > sources must be masked and all attempts to unmask them should be > ignored. Currently, we don't do either. Fix this by handling it

Re: [PATCH] hw/intc: Handle software disabling of APIC correctly

Have sent in v2. On Wed, Aug 17, 2022 at 4:20 PM Michael S. Tsirkin wrote: > On Fri, Jul 29, 2022 at 11:04:47PM +0530, Jay Khandkar wrote: > > On Fri, Jul 29, 2022 at 06:09:01PM +0100, Peter Maydell wrote: > > > On Tue, 12 Jul 2022 at 19:38, Jay Khandkar > wrote: > >

[PATCH V2] hw/intc: Handle software disabling of APIC correctly

When the local APIC is in a software disabled state, all local interrupt sources must be masked and all attempts to unmask them should be ignored. Currently, we don't do either. Fix this by handling it correctly in apic_mem_write(). Signed-off-by: Jay Khandkar --- hw/intc/apic.c | 8 ++

Re: [PATCH] hw/intc: Handle software disabling of APIC correctly

On Fri, Jul 29, 2022 at 06:09:01PM +0100, Peter Maydell wrote: > On Tue, 12 Jul 2022 at 19:38, Jay Khandkar wrote: > > > > When the local APIC is in a software disabled state, all local interrupt > > sources must be masked and all attempts to unmask them should be > > i

Re: [PATCH] hw/intc: Handle software disabling of APIC correctly

Ping? On Tue, 12 Jul 2022, 19:49 Jay Khandkar, wrote: > When the local APIC is in a software disabled state, all local interrupt > sources must be masked and all attempts to unmask them should be > ignored. Currently, we don't do either. Fix this by handling it > correctly

[PATCH] hw/intc: Handle software disabling of APIC correctly

When the local APIC is in a software disabled state, all local interrupt sources must be masked and all attempts to unmask them should be ignored. Currently, we don't do either. Fix this by handling it correctly in apic_mem_write(). Signed-off-by: Jay Khandkar --- hw/intc/apic.c

RE: Question about delaying dirty log stop to next vm_start

Hi Yi, > -Original Message- > From: Yi Sun [mailto:yi.y@linux.intel.com] > Sent: Monday, August 2, 2021 3:54 PM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; sanjay.k.ku...@intel.com; > yi.l@intel.com; yi.y@linux.intel.com > Su

RE: [PATCH] migration: Count new_dirty instead of real_dirty

Hi Keqian, > -Original Message- > From: zhukeqian > Sent: Monday, June 15, 2020 11:19 AM > To: qemu-devel@nongnu.org; qemu-...@nongnu.org; Paolo Bonzini > ; Zhoujian (jay) > Cc: Juan Quintela ; Chao Fan ; > Wanghaibin (D) > Subject: Re: [PATCH] migration: Co

RE: [PATCH] kvm: support to get/set dirty log initial-all-set capability

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, June 12, 2020 5:28 PM > To: Zhoujian (jay) ; qemu-devel@nongnu.org; > k...@vger.kernel.org > Cc: m...@redhat.com; coh...@redhat.com; pet...@redhat.com; Wangxin > (Alexander,

RE: [PATCH] kvm: support to get/set dirty log initial-all-set capability

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Wednesday, March 18, 2020 6:48 PM > To: Zhoujian (jay) ; qemu-devel@nongnu.org; > k...@vger.kernel.org > Cc: m...@redhat.com; coh...@redhat.com; pet...@redhat.com; wangxin (U) &

Question about vhost-user-gpu on Arm64

seems not to be supported by arm("On arm systems display devices with a pci memory bar do not work", also documented in [1]). I maybe missed something, may I ask that does vhost-user-gpu supported on arm64? Thanks, Jay Zhou [1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/

[PATCH] kvm: support to get/set dirty log initial-all-set capability

Since the new capability KVM_DIRTY_LOG_INITIALLY_SET of KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 has been introduced in the kernel, tweak the userspace side to detect and enable this capability. Signed-off-by: Jay Zhou --- accel/kvm/kvm-all.c | 21 ++--- linux-headers/linux/kvm.h

RE: RFC: Split EPT huge pages in advance of dirty logging

From: Peter Feiner [mailto:pfei...@google.com] Sent: Tuesday, March 3, 2020 12:29 AM To: Zhoujian (jay) Cc: Ben Gardon ; Peter Xu ; k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com; dgilb...@redhat.com; quint...@redhat.com; Liujinsong (Paul) ; linfeng (M) ; wangxin (U

RE: RFC: Split EPT huge pages in advance of dirty logging

> -Original Message- > From: Peter Feiner [mailto:pfei...@google.com] > Sent: Saturday, February 22, 2020 8:19 AM > To: Junaid Shahid > Cc: Ben Gardon ; Zhoujian (jay) > ; Peter Xu ; > k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com; > dg

RE: [edk2-devel] A problem with live migration of UEFI virtual machines

e image to round it upto 4 MB at the dest side (With some modification of qemu_ram_resize in QEMU to avoid length mismatch error report)? The physical address assigned to ovmf region will change from 0xffe00000 - 0x to 0xffc0 - 0x, after the OS has started I see this range will be recycled and assigned to other PCI devices(using the command "cat /proc/iomem") by guest OS. So, this range change seems that will not affect the guest I think. But if the code of OVMF is running when paused at the src side then will it be continued to run at the dest side, I'm not sure... So, may I ask that would it be feasible or compatible for option (1) when live migration between different ovmf sizes? Thanks. Regards, Jay Zhou

RE: RFC: Split EPT huge pages in advance of dirty logging

> -Original Message- > From: Peter Feiner [mailto:pfei...@google.com] > Sent: Saturday, February 22, 2020 8:19 AM > To: Junaid Shahid > Cc: Ben Gardon ; Zhoujian (jay) > ; Peter Xu ; > k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com; > dg

RE: RFC: Split EPT huge pages in advance of dirty logging

> -Original Message- > From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, February 21, 2020 2:17 AM > To: Ben Gardon > Cc: Zhoujian (jay) ; Junaid Shahid > ; k...@vger.kernel.org; qemu-devel@nongnu.org; > pbonz...@redhat.com; dgilb...@redhat.com; quint...@red

RE: RFC: Split EPT huge pages in advance of dirty logging

> -Original Message- > From: Peter Xu [mailto:pet...@redhat.com] > Sent: Thursday, February 20, 2020 1:19 AM > To: Zhoujian (jay) > Cc: k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com; > dgilb...@redhat.com; quint...@redhat.com; Liujinsong (Pa

RE: RFC: Split EPT huge pages in advance of dirty logging

Hi Peter, > -Original Message- > From: Peter Xu [mailto:pet...@redhat.com] > Sent: Wednesday, February 19, 2020 1:43 AM > To: Zhoujian (jay) > Cc: k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com; > dgilb...@redhat.com; quint...@redhat.com; Liujinsong

RFC: Split EPT huge pages in advance of dirty logging

e time in [1] bigger than 20s, it will be result in soft-lockup. I know it is a little hacking to do so, but my question is: is this worth trying to split EPT huge pages in advance of dirty logging? Any advice will be appreciated, thanks. Regards, Jay Zhou

Re: [Qemu-devel] [RFC PATCH] vl: fix migration when watchdog expires

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, August 14, 2018 9:07 PM > To: Zhoujian (jay) ; Dr. David Alan Gilbert > > Cc: qemu-devel@nongnu.org; quint...@redhat.com; wangxin (U) > > Subject: Re: [RFC PATCH] vl: fix

Re: [Qemu-devel] [RFC PATCH] vl: fix migration when watchdog expires

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, August 14, 2018 9:07 PM > To: Zhoujian (jay) ; Dr. David Alan Gilbert > > Cc: qemu-devel@nongnu.org; quint...@redhat.com; wangxin (U) > > Subject: Re: [RFC PATCH] vl: fix

Re: [Qemu-devel] [RFC PATCH] vl: fix migration when watchdog expires

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, August 14, 2018 8:02 PM > To: Dr. David Alan Gilbert > Cc: Zhoujian (jay) ; qemu-devel@nongnu.org; > quint...@redhat.com; wangxin (U) > Subject: Re: [RFC PATCH] vl: fix mi

Re: [Qemu-devel] [RFC PATCH] vl: fix migration when watchdog expires

> -Original Message- > From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com] > Sent: Tuesday, August 14, 2018 7:52 PM > To: Paolo Bonzini > Cc: Zhoujian (jay) ; qemu-devel@nongnu.org; > quint...@redhat.com; wangxin (U) > Subject: Re: [RFC PATCH] vl: fix mi

[Qemu-devel] [RFC PATCH] vl: fix migration when watchdog expires

: invalid runstate transition: 'prelaunch' -> 'postmigrate' Aborted The run state transition is RUN_STATE_FINISH_MIGRATE to RUN_STATE_PRELAUNCH, then the migration thread aborted when it tries to set RUN_STATE_POSTMIGRATE. There is a race between the main loop thread and the migrat

Re: [Qemu-devel] [PATCH] cryptodev: remove dead code

Hi Paolo, I've posted a patch before, pls see https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg05215.html which reviewed by Stefan https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg01549.html It seems that it hasn't been merged. Could you pick it up pls? Re

[Qemu-devel] [PATCH] memory: delete struct AddressSpaceOps

Since struct AddressSpaceOps isn't used anywhere else, so just delete it. Signed-off-by: Jay Zhou --- memory.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/memory.c b/memory.c index fc7f9b7..94b91f9 100644 --- a/memory.c +++ b/memory.c @@ -220,8 +220,6 @@ struct FlatRange {

Re: [Qemu-devel] [PATCH RESEND v10] vhost: used_memslots refactoring

n to solve it since my limited knowledge. But the counting for vhost-user and vhost-kernel's used_memslots are okay now, I think. Pls let me know if there're issues to be dealt with. Regards, Jay > -Original Message----- > From: Zhoujian (jay) > Sent: Tuesday, March 27, 2

[Qemu-devel] [PATCH] backends/cryptodev: fix coverity issue

This patch removes the dead code, which fixes Coverity (CID 1390600) issue. Signed-off-by: Jay Zhou --- backends/cryptodev-vhost-user.c | 5 - 1 file changed, 5 deletions(-) diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c index 862d4f2..67e65c6 100644 --- a

Re: [Qemu-devel] [PULL 10/13] cryptodev: add vhost-user as a new cryptodev backend

Hi Peter, > -Original Message- > From: Peter Maydell [mailto:peter.mayd...@linaro.org] > Sent: Saturday, April 28, 2018 12:15 AM > To: Michael S. Tsirkin > Cc: QEMU Developers ; Gonglei (Arei) > ; longpeng ; Zhoujian (jay) > ; Paolo Bonzini > Subject: Re: [PU

[Qemu-devel] [PATCH RESEND v10] vhost: used_memslots refactoring

t will be failed to hotplug a new DIMM device since vhost_has_free_slot() finds no free slot left. It should be successful if only part of memory slots have file descriptor, so setting used memslots for vhost-user and vhost-kernel respectively. Signed-off-by: Igor Mammedov Signed-off-by: Jay Zhou

[Qemu-devel] [PATCH v10] vhost: used_memslots refactoring

t will be failed to hotplug a new DIMM device since vhost_has_free_slot() finds no free slot left. It should be successful if only part of memory slots have file descriptor, so setting used memslots for vhost-user and vhost-kernel respectively. Signed-off-by: Igor Mammedov Signed-off-by: Jay Zhou

Re: [Qemu-devel] [PATCH v9] vhost: used_memslots refactoring

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, March 20, 2018 8:36 PM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy, Euler) >

Re: [Qemu-devel] [PATCH v9] vhost: used_memslots refactoring

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, March 20, 2018 11:14 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy, Euler) >

Re: [Qemu-devel] [PATCH v9] vhost: used_memslots refactoring

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, March 20, 2018 10:51 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy, Euler) >

Re: [Qemu-devel] [PATCH v9] vhost: used_memslots refactoring

Hi Michael, > -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, March 20, 2018 9:34 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy,

Re: [Qemu-devel] [PATCH] vhost-user: avoid misaligned access

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Saturday, March 17, 2018 2:20 AM > To: qemu-devel@nongnu.org > Cc: Zhoujian (jay) > Subject: [PATCH] vhost-user: avoid misaligned access > > We can't pass a pointer to mem

Re: [Qemu-devel] [PATCH v8 2/2] vhost: used_memslots refactoring

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Friday, March 02, 2018 12:17 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy, Euler) >

[Qemu-devel] [PATCH v9] vhost: used_memslots refactoring

te the "used_memslots" global variable, and add it for vhost-user and vhost-kernel separately - refine the function, commit log - used_memslots refactoring Signed-off-by: Igor Mammedov Signed-off-by: Jay Zhou Signed-off-by: Liuzhe --- hw/virtio/vhost-backend.c | 15 +++

[Qemu-devel] [PATCH v5] tap: setting error appropriately when calling net_init_tap_one()

fd should not be closed just because vhost failed to open or initialize but without vhostforce flag. So the followed up device_add can fall back to userspace virtio successfully. Suggested-by: Michael S. Tsirkin Suggested-by: Igor Mammedov Suggested-by: Jason Wang Signed-off-by: Jay Zhou

Re: [Qemu-devel] [PATCH v4] tap: setting error appropriately when calling net_init_tap_one()

> -Original Message- > From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Friday, March 02, 2018 2:30 PM > To: Zhoujian (jay) ; qemu-devel@nongnu.org > Cc: Huangweidong (C) ; m...@redhat.com; Gonglei > (Arei) ; imamm...@redhat.com; wangxin (U) > > Subject: Re

Re: [Qemu-devel] [PATCH v8 2/2] vhost: used_memslots refactoring

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Friday, March 02, 2018 12:17 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) ; Liuzhe (Ahriy, Euler) >

[Qemu-devel] [PATCH RESEND v8 1/4] cryptodev: add vhost-user as a new cryptodev backend

From: Gonglei Usage: -chardev socket,id=charcrypto0,path=/path/to/your/socket -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends

[Qemu-devel] [PATCH RESEND v8 0/4] cryptodev: add vhost support

From: Gonglei I posted the RFC verion a few months ago for DPDK vhost-crypto implmention, and now it's time to send the formal version. Because we need an user space scheme for better performance. The vhost user crypto server side patches had been sent to DPDK community, pls see [PATCH v2 00/10

Re: [Qemu-devel] [PATCH v8 0/4] cryptodev: add vhost support

The Intel guy Fan Zhang(CCed) reported a config issue when enabling and testing vhost_crypto, so I resend this version, thanks! Regards, Jay > -Original Message- > From: Zhoujian (jay) > Sent: Tuesday, February 27, 2018 2:33 PM > To: qemu-devel@nongnu.org > Cc: m...@re

[Qemu-devel] [PATCH RESEND v8 3/4] cryptodev-vhost-user: add crypto session handler

From: Gonglei Introduce two vhost-user meassges: VHOST_USER_CREATE_CRYPTO_SESSION and VHOST_USER_CLOSE_CRYPTO_SESSION. At this point, the QEMU side support crypto operation in cryptodev host-user backend. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou

[Qemu-devel] [PATCH RESEND v8 2/4] cryptodev: add vhost support

works. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends/cryptodev-builtin.c | 1 + backends/cryptodev-vhost-user.c | 16 +++ backends/cryptodev-vhost.c| 258 ++ hw/virtio/virtio-cry

[Qemu-devel] [PATCH RESEND v8 4/4] cryptodev-vhost-user: set the key length

From: Gonglei Signed-off-by: Gonglei --- backends/cryptodev-vhost-user.c | 4 include/sysemu/cryptodev-vhost-user.h | 3 +++ 2 files changed, 7 insertions(+) diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c index 9cd06c4..862d4f2 100644 --- a/backends/c

Re: [Qemu-devel] [PATCH v4] tap: setting error appropriately when calling net_init_tap_one()

Ping ... > -Original Message- > From: Zhoujian (jay) > Sent: Tuesday, February 06, 2018 8:54 PM > To: qemu-devel@nongnu.org > Cc: jasow...@redhat.com; m...@redhat.com; imamm...@redhat.com; Huangweidong > (C) > ; wangxin (U) ; Gonglei > (Arei) ; Zhoujian (jay) &

[Qemu-devel] [PATCH v8 0/2] vhost: used_memslots limit check fixes and refactoring

v8: - rebased on the master v7: - rebased on the master v2 ... v6: - delete the "used_memslots" global variable, and add it for vhost-user and vhost-kernel separately - refine the function, commit log - used_memslots refactoring Jay Zhou (2): vhost: fix memslot limit che

[Qemu-devel] [PATCH v8 1/2] vhost: fix memslot limit check

Since used_memslots will be updated to the actual value after registering memory listener for the first time, move the memslots limit checking to the right place. Reviewed-by: Igor Mammedov Signed-off-by: Jay Zhou --- hw/virtio/vhost.c | 19 --- 1 file changed, 12 insertions

[Qemu-devel] [PATCH v8 2/2] vhost: used_memslots refactoring

t will be failed to hotplug a new DIMM device since vhost_has_free_slot() finds no free slot left. It should be successful if only part of memory slots have file descriptor, so setting used memslots for vhost-user and vhost-kernel respectively. Signed-off-by: Igor Mammedov Signed-off-by: Jay Zhou

[Qemu-devel] [PATCH v8 0/4] cryptodev: add vhost support

From: Gonglei I posted the RFC verion a few months ago for DPDK vhost-crypto implmention, and now it's time to send the formal version. Because we need an user space scheme for better performance. The vhost user crypto server side patches had been sent to DPDK community, pls see [RFC PATCH 0/6]

[Qemu-devel] [PATCH v8 4/4] cryptodev-vhost-user: set the key length

From: Gonglei Signed-off-by: Gonglei --- backends/cryptodev-vhost-user.c | 4 include/sysemu/cryptodev-vhost-user.h | 3 +++ 2 files changed, 7 insertions(+) diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c index 9cd06c4..862d4f2 100644 --- a/backends/c

[Qemu-devel] [PATCH v8 3/4] cryptodev-vhost-user: add crypto session handler

From: Gonglei Introduce two vhost-user meassges: VHOST_USER_CREATE_CRYPTO_SESSION and VHOST_USER_CLOSE_CRYPTO_SESSION. At this point, the QEMU side support crypto operation in cryptodev host-user backend. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou

[Qemu-devel] [PATCH v8 2/4] cryptodev: add vhost support

works. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends/cryptodev-builtin.c | 1 + backends/cryptodev-vhost-user.c | 16 +++ backends/cryptodev-vhost.c| 258 ++ hw/virtio/virtio-cry

[Qemu-devel] [PATCH v8 1/4] cryptodev: add vhost-user as a new cryptodev backend

From: Gonglei Usage: -chardev socket,id=charcrypto0,path=/path/to/your/socket -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends

[Qemu-devel] [PATCH v7 1/4] cryptodev: add vhost-user as a new cryptodev backend

From: Gonglei Usage: -chardev socket,id=charcrypto0,path=/path/to/your/socket -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends

[Qemu-devel] [PATCH v7 4/4] cryptodev-vhost-user: set the key length

From: Gonglei Signed-off-by: Gonglei --- backends/cryptodev-vhost-user.c | 4 include/sysemu/cryptodev-vhost-user.h | 3 +++ 2 files changed, 7 insertions(+) diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c index 9cd06c4..862d4f2 100644 --- a/backends/c

[Qemu-devel] [PATCH v7 0/4] cryptodev: add vhost support

From: Gonglei I posted the RFC verion a few months ago for DPDK vhost-crypto implmention, and now it's time to send the formal version. Because we need an user space scheme for better performance. The vhost user crypto server side patches had been sent to DPDK community, pls see [RFC PATCH 0/6]

[Qemu-devel] [PATCH v7 2/4] cryptodev: add vhost support

works. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou --- backends/cryptodev-builtin.c | 1 + backends/cryptodev-vhost-user.c | 16 +++ backends/cryptodev-vhost.c| 258 ++ hw/virtio/virtio-cry

[Qemu-devel] [PATCH v7 3/4] cryptodev-vhost-user: add crypto session handler

From: Gonglei Introduce two vhost-user meassges: VHOST_USER_CREATE_CRYPTO_SESSION and VHOST_USER_CLOSE_CRYPTO_SESSION. At this point, the QEMU side support crypto operation in cryptodev host-user backend. Signed-off-by: Gonglei Signed-off-by: Longpeng(Mike) Signed-off-by: Jay Zhou

Re: [Qemu-devel] [PATCH v6 2/4] cryptodev: add vhost support

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Wednesday, February 14, 2018 12:44 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C) > ; stefa...@redhat.com; pa...@linux.vnet.ibm.com; > longpeng

Re: [Qemu-devel] [PATCH v6 0/4] cryptodev: add vhost support

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Wednesday, February 14, 2018 12:47 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C) > ; stefa...@redhat.com; pa...@linux.vnet.ibm.com; > longpeng

Re: [Qemu-devel] [PATCH v6 1/4] cryptodev: add vhost-user as a new cryptodev backend

> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Wednesday, February 14, 2018 12:46 AM > To: Zhoujian (jay) > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C) > ; stefa...@redhat.com; pa...@linux.vnet.ibm.com; > longpeng

Re: [Qemu-devel] [PULL 00/26] virtio, vhost, pci, pc: features, fixes and cleanups

atches disables virtio-crypto > build on non linux which used to be enabled. > > This has been silently done by a patch which was supposed to merely add a > vhost crypto device, I'm sorry I missed that in the review. Hi Michael, Peter Sorry for the late response and the trouble I have made, I just returned from a vacation. Thanks for your help and pointing out the root cause, I should explicitly put the config change of virtio-crypto into a separate patch to make review much easier. > > I've dropped the crypto vhost patches from the pull request for now. Will fix the issue in the next version, sorry again for the inconvenience. Regards, Jay > > Pushed with the same name - should be fine now. > > -- > MST

[Qemu-devel] [PATCH v4] tap: setting error appropriately when calling net_init_tap_one()

failed to open or initialize but without vhostforce flag. So the followed up device_add can fall back to userspace virtio successfully. Suggested-by: Michael S. Tsirkin Suggested-by: Igor Mammedov Suggested-by: Jason Wang Signed-off-by: Jay Zhou --- v4: - reduce duplication - close the fd by

Re: [Qemu-devel] [PATCH v3] tap: close fd conditionally when error occured

Hi Jason, > -Original Message- > From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Tuesday, February 06, 2018 5:29 PM > To: Zhoujian (jay) ; qemu-devel@nongnu.org > Cc: m...@redhat.com; imamm...@redhat.com; Huangweidong (C) > ; wangxin (U) ; Gonglei > (Arei) >

[Qemu-devel] [PATCH v3] tap: close fd conditionally when error occured

failed to open or initialize but without vhostforce flag. So the followed up device_add can fall back to userspace virtio successfully. Suggested-by: Michael S. Tsirkin Suggested-by: Igor Mammedov Suggested-by: Jason Wang Signed-off-by: Jay Zhou --- net/tap.c | 44

Re: [Qemu-devel] [PATCH v2] tap: close fd conditionally when error occured

Hi Jason, On 2018/2/2 14:56, Jason Wang wrote: On 2018年02月02日 11:53, Jay Zhou wrote: Hi Jason, On 2018/2/2 11:11, Jason Wang wrote: On 2018年01月26日 11:08, Jay Zhou wrote: If netdev_add tap,id=net0,...,vhost=on failed in net_init_tap_one(), the followed up device_add virtio-net-pci,netdev

Re: [Qemu-devel] [PATCH v2] tap: close fd conditionally when error occured

Hi Jason, On 2018/2/2 11:11, Jason Wang wrote: On 2018年01月26日 11:08, Jay Zhou wrote: If netdev_add tap,id=net0,...,vhost=on failed in net_init_tap_one(), the followed up device_add virtio-net-pci,netdev=net0 will fail too, prints: TUNSETOFFLOAD ioctl() failed: Bad file descriptor

Re: [Qemu-devel] [PATCH v6 0/4] cryptodev: add vhost support

On 2018/2/2 1:06, Michael S. Tsirkin wrote: Yes, I plan to merge it in the next pull. Pls don't assume anything until it's merged upstream though, some issues surface late. Okay, I see. Thanks for reviewing! Regards, Jay On Thu, Feb 01, 2018 at 11:29:15AM +, Zhoujian (jay)

Re: [Qemu-devel] [PATCH v6 0/4] cryptodev: add vhost support

Hi Michael, I am wondering whether this version is OK for you? Any comment will be appreciated, thanks. Regards, Jay > -Original Message- > From: Zhoujian (jay) > Sent: Sunday, January 21, 2018 8:55 PM > To: qemu-devel@nongnu.org > Cc: m...@redhat.com; pbonz...@redhat.co

  1   2   3   >