Re: [PATCH 0/6] VSOCK: revert virtio-vsock until device spec is finalized

From: Stefan Hajnoczi Date: Tue, 8 Dec 2015 19:57:30 +0800 > Please revert for now. Please don't revert it piece by piece like this. Instead, send me one big revert commit that undoes the whole thing. There is even a merge commit that you can use to create that revert

Re: [PATCH v6 14/21] KVM: ARM64: Add reset and access handlers for PMOVSSET and PMOVSCLR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use > reset_unknown for its reset handler. Add a new case to emulate writing > PMOVSSET or PMOVSCLR register. > > When writing non-zero value to

Re: [PATCH v6 15/21] KVM: ARM64: Add reset and access handlers for PMUSERENR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > The reset value of PMUSERENR_EL0 is UNKNOWN, use reset_unknown. > > Signed-off-by: Shannon Zhao > --- > arch/arm64/kvm/sys_regs.c | 5 +++-- > 1 file changed, 3 insertions(+), 2

Re: [PATCH] vhost: vsock: select CONFIG_VHOST

On Tue, Dec 08, 2015 at 04:46:08PM +0100, Arnd Bergmann wrote: > When building the new vsock code without vhost, we get a build error: > > drivers/built-in.o: In function `vhost_vsock_flush': > :(.text+0x24d29c): undefined reference to `vhost_poll_flush' > > This adds an explicit 'select' like

Re: [PATCH v6 11/21] KVM: ARM64: Add access handler for PMXEVCNTR register

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Accessing PMXEVCNTR register is mapped to the PMEVCNTRn or PMCCNTR which > is selected by PMSELR. > > Signed-off-by: Shannon Zhao > --- > arch/arm64/kvm/sys_regs.c | 44

Re: [PATCH] vhost: vsock: select CONFIG_VHOST

From: "Michael S. Tsirkin" Date: Tue, 8 Dec 2015 18:09:44 +0200 > On Tue, Dec 08, 2015 at 04:46:08PM +0100, Arnd Bergmann wrote: >> When building the new vsock code without vhost, we get a build error: >> >> drivers/built-in.o: In function `vhost_vsock_flush': >>

[PATCH v10 5/6] target-arm: kvm - re-inject guest debug exceptions

If we can't find details for the debug exception in our debug state then we can assume the exception is due to debugging inside the guest. To inject the exception into the guest state we re-use the TCG exception code (do_interrupt). However while guest debugging is in effect we currently can't

Re: [PATCH v6 18/21] KVM: ARM64: Add PMU overflow interrupt routing

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > When calling perf_event_create_kernel_counter to create perf_event, > assign a overflow handler. Then when perf event overflows, call > kvm_vcpu_kick() to sync the interrupt. Please update the commit

Re: [PATCH v6 21/21] KVM: ARM64: Add a new kvm ARM PMU device

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement > the kvm_device_ops for it. > > Signed-off-by: Shannon Zhao > --- >

Re: [PATCH v6 17/21] KVM: ARM64: Add helper to handle PMCR register bits

On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > According to ARMv8 spec, when writing 1 to PMCR.E, all counters are > enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are > disabled. When writing 1 to PMCR.P, reset all event counters, not >

Re: [PATCH v6 00/21] KVM: ARM64: Add guest PMU support

Shannon, On 08/12/15 12:47, Shannon Zhao wrote: > From: Shannon Zhao > > This patchset adds guest PMU support for KVM on ARM64. It takes > trap-and-emulate approach. When guest wants to monitor one event, it > will be trapped by KVM and KVM will call perf_event API to

Re: [PATCH v6 07/21] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function

On 2015/12/8 23:43, Marc Zyngier wrote: > On 08/12/15 12:47, Shannon Zhao wrote: >> From: Shannon Zhao >> +/** >> + * kvm_pmu_get_counter_value - get PMU counter value >> + * @vcpu: The vcpu pointer >> + * @select_idx: The counter index >> + */ >> +u64

Re: [PATCH v2 0/5] Add virtio transport for AF_VSOCK

On Fri, Dec 04, 2015 at 09:45:04AM +0200, Michael S. Tsirkin wrote: > On Wed, Dec 02, 2015 at 02:43:58PM +0800, Stefan Hajnoczi wrote: > > 1. The 3-way handshake isn't necessary over a reliable transport > > (virtqueue). > >Spoofing packets is also impossible so the security aspects of the

Re: [PATCH 0/6] VSOCK: revert virtio-vsock until device spec is finalized

On Tue, Dec 08, 2015 at 11:26:55AM -0500, David Miller wrote: > From: Stefan Hajnoczi > Date: Tue, 8 Dec 2015 19:57:30 +0800 > > > Please revert for now. > > Please don't revert it piece by piece like this. > > Instead, send me one big revert commit that undoes the whole

Re: [PATCH v2] Revert "Merge branch 'vsock-virtio'"

From: Stefan Hajnoczi Date: Wed, 9 Dec 2015 10:51:12 +0800 > This reverts commit 0d76d6e8b2507983a2cae4c09880798079007421 and merge > commit c402293bd76fbc93e52ef8c0947ab81eea3ae019, reversing changes made > to c89359a42e2a49656451569c382eed63e781153c. > > The virtio-vsock

Re: [PATCH 1/1] KVM: PPC: Increase memslots to 320

On Wed, Nov 04, 2015 at 10:03:48AM +0100, Thomas Huth wrote: > Only using 32 memslots for KVM on powerpc is way too low, you can > nowadays hit this limit quite fast by adding a couple of PCI devices > and/or pluggable memory DIMMs to the guest. > x86 already increased the limit to 512 in total,

Re: [PATCH 1/1] KVM: PPC: Increase memslots to 320

On Wed, Nov 04, 2015 at 10:03:48AM +0100, Thomas Huth wrote: > Only using 32 memslots for KVM on powerpc is way too low, you can > nowadays hit this limit quite fast by adding a couple of PCI devices > and/or pluggable memory DIMMs to the guest. > x86 already increased the limit to 512 in total,

RE: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

Hello! > I messed up the "load into xzr" test royally in the last attached patch. > It was quite wrong. Yes, because "mov %0, xzr" is not trapped. > I have now tested > > asm volatile( > "str %3, [%1]\n\t" > "ldr wzr, [%1]\n\t" > "str wzr, [%2]\n\t" > "ldr %0, [%2]\n\t"

Re: [PATCH v5 03/21] KVM: ARM64: Add offset defines for PMU registers

On 07/12/15 14:31, Shannon Zhao wrote: > > > On 2015/12/7 22:06, Marc Zyngier wrote: >> On 03/12/15 06:11, Shannon Zhao wrote: >>> From: Shannon Zhao >>> >>> We are about to trap and emulate acccesses to each PMU register >> >> s/acccesses/accesses/ >> >>> individually.

Re: [PATCH v5 03/21] KVM: ARM64: Add offset defines for PMU registers

On 2015/12/7 22:06, Marc Zyngier wrote: On 03/12/15 06:11, Shannon Zhao wrote: From: Shannon Zhao We are about to trap and emulate acccesses to each PMU register s/acccesses/accesses/ individually. This adds the context offsets for the AArch64 PMU registers and

Re: [PATCH v5 00/21] KVM: ARM64: Add guest PMU support

Hi Marc, On 2015/12/7 22:11, Marc Zyngier wrote: Shannon, On 03/12/15 06:11, Shannon Zhao wrote: From: Shannon Zhao This patchset adds guest PMU support for KVM on ARM64. It takes trap-and-emulate approach. When guest wants to monitor one event, it will be trapped

Re: [PATCH v5 21/21] KVM: ARM64: Add a new kvm ARM PMU device

On 07/12/15 14:37, Shannon Zhao wrote: > > > On 2015/12/7 21:56, Marc Zyngier wrote: >>> +static int kvm_arm_pmu_set_attr(struct kvm_device *dev, + struct kvm_device_attr *attr) +{ + switch (attr->group) { + case KVM_DEV_ARM_PMU_GRP_IRQ: { +

Re: [PATCH v5 11/21] KVM: ARM64: Add reset and access handlers for PMCNTENSET and PMCNTENCLR register

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use > reset_unknown for its reset handler. Add a new case to emulate writing > PMCNTENSET or PMCNTENCLR register. > > When writing to

Re: [PATCH v5 08/21] KVM: ARM64: Add reset and access handlers for PMXEVTYPER register

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > Since the reset value of PMXEVTYPER is UNKNOWN, use reset_unknown or > reset_unknown_cp15 for its reset handler. Add access handler which > emulates writing and reading PMXEVTYPER register. When writing to >

Re: [PATCH v5 21/21] KVM: ARM64: Add a new kvm ARM PMU device

On 2015/12/7 21:56, Marc Zyngier wrote: +static int kvm_arm_pmu_set_attr(struct kvm_device *dev, >+ struct kvm_device_attr *attr) >+{ >+ switch (attr->group) { >+ case KVM_DEV_ARM_PMU_GRP_IRQ: { >+ int __user *uaddr = (int __user *)(long)attr->addr; >+

Re: [PATCH v5 00/21] KVM: ARM64: Add guest PMU support

On 07/12/15 14:47, Shannon Zhao wrote: > Hi Marc, > > On 2015/12/7 22:11, Marc Zyngier wrote: >> Shannon, >> >> On 03/12/15 06:11, Shannon Zhao wrote: >>> From: Shannon Zhao >>> >>> This patchset adds guest PMU support for KVM on ARM64. It takes >>> trap-and-emulate

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor argument. I highly doubt Microsoft is interested in having to modify all

Re: [PATCH v5 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > Here we plan to support virtual PMU for guest by full software > emulation, so define some basic structs and functions preparing for > futher steps. Define struct kvm_pmc for performance monitor counter and

Re: [PATCH v5 21/21] KVM: ARM64: Add a new kvm ARM PMU device

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement > the kvm_device_ops for it. > > Signed-off-by: Shannon Zhao > --- >

Re: [PATCH v5 00/21] KVM: ARM64: Add guest PMU support

Shannon, On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > This patchset adds guest PMU support for KVM on ARM64. It takes > trap-and-emulate approach. When guest wants to monitor one event, it > will be trapped by KVM and KVM will call perf_event API to

Re: [PATCH v5 04/21] KVM: ARM64: Add reset and access handlers for PMCR_EL0 register

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > Add reset handler which gets host value of PMCR_EL0 and make writable > bits architecturally UNKNOWN except PMCR.E to zero. Add a common access > handler for PMU registers which emulates writing and reading

Re: [PATCH v5 03/21] KVM: ARM64: Add offset defines for PMU registers

On 03/12/15 06:11, Shannon Zhao wrote: > From: Shannon Zhao > > We are about to trap and emulate acccesses to each PMU register s/acccesses/accesses/ > individually. This adds the context offsets for the AArch64 PMU > registers and their AArch32 counterparts. > >

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

Hi Mario, On 07/12/15 16:40, Mario Smarduch wrote: > Hi Marc, > > On 12/7/2015 2:53 AM, Marc Zyngier wrote: >> Implement the vgic-v3 save restore as a direct translation of >> the assembly code version. >> >> Signed-off-by: Marc Zyngier >> --- >>

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On 07/12/15 17:18, Mario Smarduch wrote: > > > On 12/7/2015 8:52 AM, Marc Zyngier wrote: >> Hi Mario, >> >> On 07/12/15 16:40, Mario Smarduch wrote: >>> Hi Marc, >>> >>> On 12/7/2015 2:53 AM, Marc Zyngier wrote: Implement the vgic-v3 save restore as a direct translation of the assembly

Re: [PATCH v5 02/21] KVM: ARM64: Define PMU data structure for each vcpu

On 07/12/15 15:05, Marc Zyngier wrote: > On 03/12/15 06:11, Shannon Zhao wrote: >> From: Shannon Zhao >> >> Here we plan to support virtual PMU for guest by full software >> emulation, so define some basic structs and functions preparing for >> futher steps. Define struct

live migration vs device assignment (was Re: [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC)

reset at destination sounds better. If combining with surprise removal in 2 above, maybe pretend to linux that there was a fatal error on the device, and have linux re-initialize it? To me this sounds better as it will survive across minor device changes src/dst. Still won't survive if driver h

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On 12/7/2015 8:52 AM, Marc Zyngier wrote: > Hi Mario, > > On 07/12/15 16:40, Mario Smarduch wrote: >> Hi Marc, >> >> On 12/7/2015 2:53 AM, Marc Zyngier wrote: >>> Implement the vgic-v3 save restore as a direct translation of >>> the assembly code version. >>> >>> Signed-off-by: Marc Zyngier

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

NDEX(11)], > ICH_LR11_EL2); > + case 10: > + write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)], > ICH_LR10_EL2); > + case 9: > + write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)], ICH_LR9_EL2); > + case 8: > + write_gicreg(cpu_if->vgic_l

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote: > On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: > > On 12/5/2015 1:07 AM, Alexander Duyck wrote: > >>> > >>> > >>> We still need to support Windows guest for migration and this is why our > >>> patches

Re: [PATCH v3 01/22] arm64: Add macros to read/write system registers

On Mon, Dec 07, 2015 at 10:53:17AM +, Marc Zyngier wrote: > From: Mark Rutland > > Rather than crafting custom macros for reading/writing each system > register provide generics accessors, read_sysreg and write_sysreg, for > this purpose. > > Unlike read_cpuid, calls

Re: [PATCH v3 01/22] arm64: Add macros to read/write system registers

On Mon, Dec 07, 2015 at 05:35:20PM +, Catalin Marinas wrote: > On Mon, Dec 07, 2015 at 10:53:17AM +, Marc Zyngier wrote: > > From: Mark Rutland > > > > Rather than crafting custom macros for reading/writing each system > > register provide generics accessors,

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: > On 12/5/2015 1:07 AM, Alexander Duyck wrote: >>> >>> >>> We still need to support Windows guest for migration and this is why our >>> patches keep all changes in the driver since it's impossible to change >>> Windows

RE: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

Hello! > But, if Pavel doesn't > mind trying them out on his system, then it'd be good to know if they > reproduce there. I'd like to find out if it's a test case problem or > something else strange going on with environments. Does not build, applied to master: --- cut ---

RE: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

Hello! > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > issue didn't reproduce for me. It's quite possible my test cases are > flawed, so I'm not making any claims about the validity of the series This is indeed very interesting, so i'll take a look at it. For now

RE: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

Hello! > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > issue didn't reproduce for me. It's quite possible my test cases are > flawed Indeed they are, a very little thing fell through again... :) It's not just SP, it's SP_EL0. And you never initialize it to anything

Re: powerpc/64: Include KVM guest test in all interrupt vectors

On Thu, 2015-12-11 at 05:44:42 UTC, Paul Mackerras wrote: > Currently, if HV KVM is configured but PR KVM isn't, we don't include > a test to see whether we were interrupted in KVM guest context for the > set of interrupts which get delivered directly to the guest by hardware > if they occur in

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On 20/11/15 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted by >

Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

On 20/11/15 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted by >

Re: [PATCH v3 01/22] arm64: Add macros to read/write system registers

On 07/12/15 17:45, Mark Rutland wrote: > On Mon, Dec 07, 2015 at 05:35:20PM +, Catalin Marinas wrote: >> On Mon, Dec 07, 2015 at 10:53:17AM +, Marc Zyngier wrote: >>> From: Mark Rutland >>> >>> Rather than crafting custom macros for reading/writing each system >>>

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Mon, Dec 07, 2015 at 04:36:31PM -0600, Andrew Jones wrote: > On Mon, Dec 07, 2015 at 11:36:28AM +0300, Pavel Fedin wrote: > > Hello! > > > > > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > > > issue didn't reproduce for me. It's quite possible my test cases are > >

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On 12/7/2015 10:20 AM, Marc Zyngier wrote: > On 07/12/15 18:05, Mario Smarduch wrote: >> >> >> On 12/7/2015 9:37 AM, Marc Zyngier wrote: [...] >>> >> >> I was thinking something like 'current_lr[VGIC_V3_LR_INDEX(...)]'. > > That doesn't change anything, the compiler is perfectly able to >

Re: [PATCH v3 06/22] arm64: KVM: Implement timer save/restore

On 12/7/2015 2:53 AM, Marc Zyngier wrote: > Implement the timer save restore as a direct translation of > the assembly code version. > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/hyp/Makefile | 1 + > arch/arm64/kvm/hyp/hyp.h | 3 ++ >

Re: [PATCH kernel 3/9] KVM: PPC: Rework H_PUT_TCE/H_GET_TCE handlers

On Tue, Sep 15, 2015 at 08:49:33PM +1000, Alexey Kardashevskiy wrote: > This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have one > exit path. This allows next patch to add locks nicely. I don't see a problem with the actual code, but it doesn't seem to match this description: I still

Re: [PATCH kernel 1/9] rcu: Define notrace version of list_for_each_entry_rcu

On Tue, Sep 15, 2015 at 08:49:31PM +1000, Alexey Kardashevskiy wrote: > This defines list_for_each_entry_rcu_notrace and list_entry_rcu_notrace > which use rcu_dereference_raw_notrace instead of rcu_dereference_raw. > This allows using list_for_each_entry_rcu_notrace in real mode (MMU is off). >

Re: [PATCH kernel 1/9] rcu: Define notrace version of list_for_each_entry_rcu

On Tue, Sep 15, 2015 at 08:49:31PM +1000, Alexey Kardashevskiy wrote: > This defines list_for_each_entry_rcu_notrace and list_entry_rcu_notrace > which use rcu_dereference_raw_notrace instead of rcu_dereference_raw. > This allows using list_for_each_entry_rcu_notrace in real mode (MMU is off). >

Re: [PATCH kernel 3/9] KVM: PPC: Rework H_PUT_TCE/H_GET_TCE handlers

On Tue, Sep 15, 2015 at 08:49:33PM +1000, Alexey Kardashevskiy wrote: > This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have one > exit path. This allows next patch to add locks nicely. I don't see a problem with the actual code, but it doesn't seem to match this description: I still

Re: [PATCH kernel 4/9] KVM: PPC: Use RCU for arch.spapr_tce_tables

On Tue, Sep 15, 2015 at 08:49:34PM +1000, Alexey Kardashevskiy wrote: > At the moment spapr_tce_tables is not protected against races. This makes > use of RCU-variants of list helpers. As some bits are executed in real > mode, this makes use of just introduced list_for_each_entry_rcu_notrace(). >

Re: [PATCH kernel 2/9] KVM: PPC: Make real_vmalloc_addr() public

On Tue, Sep 15, 2015 at 08:49:32PM +1000, Alexey Kardashevskiy wrote: > This helper translates vmalloc'd addresses to linear addresses. > It is only used by the KVM MMU code now and resides in the HV KVM code. > We will need it further in the TCE code and the DMA memory preregistration > code

Re: [PATCH kernel 4/9] KVM: PPC: Use RCU for arch.spapr_tce_tables

On Tue, Sep 15, 2015 at 08:49:34PM +1000, Alexey Kardashevskiy wrote: > At the moment spapr_tce_tables is not protected against races. This makes > use of RCU-variants of list helpers. As some bits are executed in real > mode, this makes use of just introduced list_for_each_entry_rcu_notrace(). >

Re: [PATCH kernel 2/9] KVM: PPC: Make real_vmalloc_addr() public

On Tue, Sep 15, 2015 at 08:49:32PM +1000, Alexey Kardashevskiy wrote: > This helper translates vmalloc'd addresses to linear addresses. > It is only used by the KVM MMU code now and resides in the HV KVM code. > We will need it further in the TCE code and the DMA memory preregistration > code

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Mon, Dec 07, 2015 at 11:47:44AM +0300, Pavel Fedin wrote: > Hello! > > > But, if Pavel doesn't > > mind trying them out on his system, then it'd be good to know if they > > reproduce there. I'd like to find out if it's a test case problem or > > something else strange going on with

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Mon, Dec 07, 2015 at 12:48:12PM +0300, Pavel Fedin wrote: > Hello! > > > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > > issue didn't reproduce for me. It's quite possible my test cases are > > flawed > > Indeed they are, a very little thing fell through again...

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Mon, Dec 07, 2015 at 03:58:11PM -0600, Andrew Jones wrote: > On Mon, Dec 07, 2015 at 12:48:12PM +0300, Pavel Fedin wrote: > > Hello! > > > > > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > > > issue didn't reproduce for me. It's quite possible my test cases are > >

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Mon, Dec 07, 2015 at 11:36:28AM +0300, Pavel Fedin wrote: > Hello! > > > FYI, I tried writing test cases for this issue with kvm-unit-tests. The > > issue didn't reproduce for me. It's quite possible my test cases are > > flawed, so I'm not making any claims about the validity of the series >

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On 12/7/2015 9:37 AM, Marc Zyngier wrote: > On 07/12/15 17:18, Mario Smarduch wrote: >> >> >> On 12/7/2015 8:52 AM, Marc Zyngier wrote: >>> Hi Mario, >>> >>> On 07/12/15 16:40, Mario Smarduch wrote: Hi Marc, On 12/7/2015 2:53 AM, Marc Zyngier wrote: > Implement the vgic-v3

Re: [PATCH v3 05/22] arm64: KVM: Implement vgic-v3 save/restore

On 07/12/15 18:05, Mario Smarduch wrote: > > > On 12/7/2015 9:37 AM, Marc Zyngier wrote: >> On 07/12/15 17:18, Mario Smarduch wrote: >>> >>> >>> On 12/7/2015 8:52 AM, Marc Zyngier wrote: Hi Mario, On 07/12/15 16:40, Mario Smarduch wrote: > Hi Marc, > > On 12/7/2015

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Mon, Dec 7, 2015 at 9:39 AM, Michael S. Tsirkin wrote: > On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote: >> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: >> > On 12/5/2015 1:07 AM, Alexander Duyck wrote: >> > If can't do that, we

Re: [PATCH] VSOCK: fix returnvar.cocci warnings

From: Julia Lawall Date: Sun, 6 Dec 2015 06:56:23 +0100 (CET) > Remove unneeded variable used to store return value. > > Generated by: scripts/coccinelle/misc/returnvar.cocci > > CC: Asias He > Signed-off-by: Fengguang Wu >

Re: [PATCH] VSOCK: fix returnvar.cocci warnings

On Sun, Dec 06, 2015 at 06:56:23AM +0100, Julia Lawall wrote: > Remove unneeded variable used to store return value. > > Generated by: scripts/coccinelle/misc/returnvar.cocci > > CC: Asias He > Signed-off-by: Fengguang Wu > Signed-off-by: Julia Lawall

Re: [v2,2/9] powerpc/smp: Add smp_muxed_ipi_set_message

On Wed, 2015-25-11 at 23:44:49 UTC, "Suresh E. Warrier" wrote: > smp_muxed_ipi_message_pass() invokes smp_ops->cause_ipi, which > updates the MFFR through an ioremapped address, to cause the > IPI. Because of this real mode callers cannot call > smp_muxed_ipi_message_pass() for IPI messaging.

Re: [v2,3/9] powerpc/powernv: Add icp_native_cause_ipi_rm

Subject would be better as "powerpc/xics". On Wed, 2015-25-11 at 23:44:50 UTC, "Suresh E. Warrier" wrote: > Function to cause an IPI. Requires kvm_hstate.xics_phys > to be initialized with physical address of XICS. Please expand the change log a bit, this is a bit terse. > diff --git

Re: [PATCH 00/11] KVM: x86: track guest page access

Ping... Paolo, any comment? On 12/02/2015 01:00 AM, Xiao Guangrong wrote: On 12/01/2015 06:17 PM, Paolo Bonzini wrote: On 30/11/2015 19:26, Xiao Guangrong wrote: This patchset introduces the feature which allows us to track page access in guest. Currently, only write access tracking

Re: PAX: size overflow detected in function __vhost_add_used_n drivers/vhost/vhost.c:1517

On 5 Dec 2015 at 20:51, Toralf Förster wrote: > run into the following at a 64bit hardened stable Gentoo Linux while > running the following command at the host (probably just the ssh login > was it yet) : > > $ cd ~/devel/linux/; git archive --prefix linux-4.4.x/ v4.4-rc3 | (ssh > root@n22kvm

Re: [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC

On Fri, Dec 04, 2015 at 02:42:36PM +0800, Lan, Tianyu wrote: > > On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote: > >>>We hope > >>>to find a better way to make SRIOV NIC work in these cases and this is > >>>worth to do since SRIOV NIC provides better network performance compared > >>>with PV

Re: [PATCH] KVM: arm/arm64: Revert to old way of checking for device mapping in stage2_flush_ptes().

On 4 December 2015 at 02:58, Ben Hutchings wrote: > On Wed, 2015-12-02 at 18:41 +0100, Ard Biesheuvel wrote: >> Hi Pavel, >> >> Thanks for getting to the bottom of this. >> >> On 1 December 2015 at 14:03, Pavel Fedin wrote: >> > This function takes

Re: [PATCH v2 3/4] KVM: arm64: Correctly handle zero register in system register accesses

Hi Pavel, On 04/12/15 10:25, Pavel Fedin wrote: > System register accesses also use zero register for Rt == 31, and > therefore using it will also result in getting SP value instead. This > patch makes them also using new accessors, introduced by the previous > patch. Since register value is no

Re: [PATCH v2 4/4] KVM: arm64: Get rid of old vcpu_reg()

On 04/12/15 10:26, Pavel Fedin wrote: > Using oldstyle vcpu_reg() accessor is proven to be inappropriate and > unsafe on ARM64. This patch converts the rest of use cases to new > accessors and completely removes vcpu_reg() on ARM64. > > Signed-off-by: Pavel Fedin

RE: [PATCH v2 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

Hello! > Thanks a lot for respining this quickly. I just had a few minor > comments, so this is almost ready to go. If you can fix that Damn, the rest of reviews got stuck somewhere and arrived later, so i've just sent v3 without wrap fix. Will correct it. Kind regards, Pavel Fedin Expert

Re: [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC

On 12/4/2015 4:05 PM, Michael S. Tsirkin wrote: I haven't read it, but I would like to note you can't rely on research papers. If you propose a patch to be merged you need to measure what is its actual effect on modern linux at the end of 2015. Sure. Will do that. -- To unsubscribe from this

Re: [PATCH v2 2/4] KVM: arm64: Remove const from struct sys_reg_params

Hi Pavel, On 04/12/15 10:25, Pavel Fedin wrote: > Further rework is going to introduce a dedicated storage for transfer > register value in struct sys_reg_params. Before doing this we have to > remove all 'const' modifiers from it. I think you are being a bit overzealous here, and a few const

RE: [PATCH v2 2/4] KVM: arm64: Remove const from struct sys_reg_params

Hello! > I think you are being a bit overzealous here, and a few const can > legitimately be kept, see below. :) Yes, i've just commanded "search and replace" to the editor. Fixing... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from

Re: [PATCH v2 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On 04/12/15 10:25, Pavel Fedin wrote: > ARM64 CPU has zero register which is read-only, with a value of 0. > However, KVM currently incorrectly recognizes it being SP (because > Rt == 31, and in struct user_pt_regs 'regs' array is followed by SP), > resulting in invalid value being read, or even

Re: [Qemu-devel] [PATCH v3 0/3] target-i386: add memory protection-key support

On Wed, Nov 18, 2015 at 10:20:14AM +0800, Huaitong Han wrote: > Changes in v3: > *Fix cpuid_7_0_ecx_feature_name error. > > Changes in v2: > *Fix memcpy error for xsave state. > *Fix TCG_7_0_ECX_FEATURES to 0. > *Make subjects more readable. > > The protection-key feature provides an additional

Re: [PATCH v4 1/4] KVM: arm64: Correctly handle zero register during MMIO

On 04/12/15 12:03, Pavel Fedin wrote: > On ARM64 register index of 31 corresponds to both zero register and SP. > However, all memory access instructions, use ZR as transfer register. SP > is used only as a base register in indirect memory addressing, or by > register-register arithmetics, which

Re: [PATCH 01/23] userfaultfd: linux/Documentation/vm/userfaultfd.txt

Hi Andrea, On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote: > On 05/14/2015 07:30 PM, Andrea Arcangeli wrote: >> Add documentation. > > Hi Andrea, > > I do not recall... Did you write a man page also for this new system call? No response to my last mail, so I'll try again... Did you

Re: [PATCH] kvm: Dump guest rIP when the guest tried something unsupported

On 20/11/2015 19:52, Borislav Petkov wrote: > From: Borislav Petkov > > It looks like this in action: > > kvm [5197]: vcpu0, guest rIP: 0x810187ba unhandled rdmsr: 0xc001102 > > and helps to pinpoint quickly where in the guest we did the unsupported > thing. > >

Re: [PATCH v2 1/9] drivers/hv: replace enum hv_message_type by u32

On 12/02/2015 03:22 PM, Paolo Bonzini wrote: On 30/11/2015 17:22, Andrey Smetanin wrote: enum hv_message_type inside struct hv_message, hv_post_message is not size portable. Replace enum by u32. It's only non-portable inside structs. Okay to apply just these: @@ -172,7 +174,7 @@ union

Re: [PATCH] VSOCK: mark virtio_transport.ko experimental

On Fri, Dec 04, 2015 at 11:49:18AM +0800, Stefan Hajnoczi wrote: > Be explicit that the virtio_transport.ko code implements a draft virtio > specification that is still subject to change. > > Signed-off-by: Stefan Hajnoczi > --- > If you'd rather wait until the device

Re: [PATCH v4 2/4] KVM: arm64: Remove const from struct sys_reg_params

On 04/12/15 12:03, Pavel Fedin wrote: > Further rework is going to introduce a dedicated storage for transfer > register value in struct sys_reg_params. Before doing this we have to > remove 'const' modifiers from it in all accessor functions and their > callers. > > Signed-off-by: Pavel Fedin

Re: [PATCH v2 1/9] drivers/hv: replace enum hv_message_type by u32

On 04/12/2015 15:33, Denis V. Lunev wrote: > On 12/02/2015 03:22 PM, Paolo Bonzini wrote: >> >> On 30/11/2015 17:22, Andrey Smetanin wrote: >>> enum hv_message_type inside struct hv_message, hv_post_message >>> is not size portable. Replace enum by u32. >> It's only non-portable inside structs.

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/04/2015 08:32 AM, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor

Re: [PATCH v2 1/9] drivers/hv: replace enum hv_message_type by u32

On 04/12/2015 17:55, Denis V. Lunev wrote: > On 12/04/2015 05:41 PM, Paolo Bonzini wrote: >> >> On 04/12/2015 15:33, Denis V. Lunev wrote: >>> On 12/02/2015 03:22 PM, Paolo Bonzini wrote: On 30/11/2015 17:22, Andrey Smetanin wrote: > enum hv_message_type inside struct hv_message,

Re: [GIT PULL] KVM/ARM fixes for 4.4-rc4

On 04/12/2015 18:17, Marc Zyngier wrote: > Hi Paolo, > > This pull request contains a number of fixes for 4.4-rc4 (or -rc5 if > we already missed the boat). > > The first part is a very nice catch from Pavel, who noticed that we > were not dealing very well (if at all) with the aliasing

Re: [PATCH 01/23] userfaultfd: linux/Documentation/vm/userfaultfd.txt

Hello Michael, On Fri, Dec 04, 2015 at 04:50:03PM +0100, Michael Kerrisk (man-pages) wrote: > Hi Andrea, > > On 09/11/2015 10:47 AM, Michael Kerrisk (man-pages) wrote: > > On 05/14/2015 07:30 PM, Andrea Arcangeli wrote: > >> Add documentation. > > > > Hi Andrea, > > > > I do not recall... Did

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

Hi Michael & Alexander: Thanks a lot for your comments and suggestions. We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. Following is my idea to do DMA tracking. Inject event to VF

Re: [Qemu-devel] [PATCH v8 0/5] implement vNVDIMM

On 16.11.2015 13:50, Xiao Guangrong wrote: NVDIMM (A Non-Volatile Dual In-line Memory Module) is going to be supported on Intel's platform. Hi. One question: do this mean, that your qemu emulated nvidimm - pmem solution will work only on Intel host? -- Best regards, Vladimir * now,

Re: [PATCH v2 1/9] drivers/hv: replace enum hv_message_type by u32

On 12/04/2015 05:41 PM, Paolo Bonzini wrote: On 04/12/2015 15:33, Denis V. Lunev wrote: On 12/02/2015 03:22 PM, Paolo Bonzini wrote: On 30/11/2015 17:22, Andrey Smetanin wrote: enum hv_message_type inside struct hv_message, hv_post_message is not size portable. Replace enum by u32. It's

Re: [PATCH v2] vhost: replace % with & on data path

On Mon, Nov 30, 2015 at 11:15:23AM +0200, Michael S. Tsirkin wrote: > We know vring num is a power of 2, so use & > to mask the high bits. > > Signed-off-by: Michael S. Tsirkin > --- The generated code switches from DIV -> masking, source is clearer as well. Tested-by:

Re: [PATCH v4 0/4] KVM: arm64: BUG FIX: Correctly handle zero register transfers

On Fri, Dec 04, 2015 at 03:03:10PM +0300, Pavel Fedin wrote: > ARM64 CPU has zero register which is read-only, with a value of 0. > However, KVM currently incorrectly recognizes it being SP (because > Rt == 31, and in struct user_pt_regs 'regs' array is followed by SP), > resulting in invalid

Re: [Qemu-devel] [PATCH v8 0/5] implement vNVDIMM

On 12/05/2015 12:38 AM, Vladimir Sementsov-Ogievskiy wrote: On 16.11.2015 13:50, Xiao Guangrong wrote: NVDIMM (A Non-Volatile Dual In-line Memory Module) is going to be supported on Intel's platform. Hi. One question: do this mean, that your qemu emulated nvidimm - pmem solution will work

<    2   3   4   5   6   7   8   9   10   11   >