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

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

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 cannot be trapped here. Correct emulation is

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

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 longer directly associated with storage inside vCPU

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

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 --- arch/arm64/kvm/sys_regs.c

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

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 --- arch/arm/kvm/psci.c | 20

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

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 SP corruption on write. The problem has been

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

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

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 SP corruption on write. The problem has been

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

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 --- arch/arm64/kvm/sys_regs.c

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

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 cannot be trapped here. Correct emulation is

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

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 Reviewed-by: Marc Zyngier ---

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

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 longer directly associated with storage inside vCPU

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

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 --- arch/arm/kvm/psci.c | 20

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

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 SP corruption on write. The problem has been

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

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 longer directly associated with storage inside vCPU

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

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 cannot be trapped here. Correct emulation is

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

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. Signed-off-by: Pavel Fedin --- arch/arm64/kvm/sys_regs.c| 38

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

[PATCH v3 2/3] target-i386: Use xsave structs for ext_save_area

This doesn't introduce any change in the code, as the offsets and struct sizes match what was present in the table. This can be validated by the QEMU_BUILD_BUG_ON lines on target-i386/cpu.h, which ensures the struct sizes and offsets match the existing values in ext_save_area. Signed-off-by:

[PATCH v3 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes

target-i386/cpu.c:ext_save_area uses magic numbers for the xsave area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave() uses offset macros and bit manipulation to access the xsave area. This series changes both to use C structs for those operations. I still need to figure out a way to

[PATCH v3 1/3] target-i386: Define structs for layout of xsave area

Add structs that define the layout of the xsave areas used by Intel processors. Add some QEMU_BUILD_BUG_ON lines to ensure the structs match the XSAVE_* macros in target-i386/kvm.c and the offsets and sizes at target-i386/cpu.c:ext_save_areas. Signed-off-by: Eduardo Habkost

[PATCH v3 3/3] target-i386: kvm: Use X86XSaveArea struct for xsave save/load

Instead of using offset macros and bit operations in a uint32_t array, use the X86XSaveArea struct to perform the loading/saving operations in kvm_put_xsave() and kvm_get_xsave(). Signed-off-by: Eduardo Habkost --- Changes v1 -> v2: * Use uint8_t pointers when loading/saving

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.

[PATCH 1/5] arm64: KVM: Correctly handle zero register during MMIO

From: Pavel Fedin 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 cannot

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

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 between two registers. The last patch from Ard is a fix for a

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

[GIT PULL] KVM fixes for 4.4-rc4

Linus, The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8: Linux 4.4-rc3 (2015-11-29 18:58:26 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

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,

[PATCH 5/5] ARM/arm64: KVM: correct PTE uncachedness check

From: Ard Biesheuvel Commit e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's uncachedness") modified the logic to test whether a HYP or stage-2 mapping needs flushing, from [incorrectly] interpreting the page table attributes to [incorrectly] checking whether

[PATCH 3/5] arm64: KVM: Correctly handle zero register in system register accesses

From: Pavel Fedin 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 longer directly

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

From: Pavel Fedin 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 Reviewed-by: Marc

[PATCH 2/5] arm64: KVM: Remove const from struct sys_reg_params

From: Pavel Fedin 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: [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

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

On 12/04/2015 08:38 PM, Paolo Bonzini wrote: 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

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

> >> we are now comparing enum with enum which are the same type. > >> With the change you are proposing we will compare enum > >> with u32 which are different. > > This is only an issue in C++. > > > >> Original suggestion from Andrey was safe in this respect. > > Sure, but it makes code less