RE: [PATCH v4 3/7] KVM: arm/arm64: Fix the documentation

Hello! > > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > > @@ -44,28 +44,29 @@ Groups: > >Attributes: > > The attr field of kvm_device_attr encodes two values: > > bits: | 63 40 | 39 .. 32 | 31

Re: [PATCH v2] KVM: nVMX: expose VPID capability to L1

On 9/29/15 6:39 PM, Paolo Bonzini wrote: On 29/09/2015 04:55, Wanpeng Li wrote: Expose VPID capability to L1. Signed-off-by: Wanpeng Li --- v1 -> v2: * set only VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT Thanks. I've checked more thoroughly your implementation against the

[PATCH v2 1/5] KVM: VMX: adjust interface to allocate/free_vpid

Adjust allocate/free_vid so that they can be reused for the nested vpid. Reviewed-by: Wincy Van Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git

[PATCH v2 2/5] KVM: VMX: introduce __vmx_flush_tlb to handle specific vpid

Introduce __vmx_flush_tlb() to handle specific vpid. It will be used by later patches, note that the "all context" variant can be mapped to vpid_sync_vcpu_single with vpid02 as the argument (a nice side effect of vpid02 design). Reviewed-by: Wincy Van Signed-off-by:

[PATCH v2 0/5] KVM: nVMX: nested VPID emulation

v1 -> v2: * set bit 32 of the VMX_EPT_VPID_CAP MSR * check against the supported types in the implementation of the INVVPID instruction * the memory operand must always be read even if it isn't needed (e.g., for type==global), similar to INVEPT * for single-context invalidation to

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On Thu, Oct 08, 2015 at 12:10:35PM +0300, Pavel Fedin wrote: > Hello! > [...] > > > The architecture defines how to address a specific CPU, and that's using > > the MPIDR, not inventing our own scheme, so that's what we should do. > > But doesn't the same apply to GICv2 then? It just happened

RE: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

Hello! > +The mpidr encoding is based on the affinity information in the > +architecture defined MPIDR, and the field is encoded as follows: > + | 63 56 | 55 48 | 47 40 | 39 32 | > + |Aff3|Aff2|Aff1|Aff0| One concern about

RE: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

Hello! Sorry for taking up your time, and thank you very much for the explanation. > I'd appreciate if you could try to read and understand the architecture > spec instead of randomly googling and quoting various bits of > irrelevant information. I give my apologizes for not having time to

[PATCH v2 5/5] KVM: nVMX: expose VPID capability to L1

Expose VPID capability to L1. For nested guests, we don't do anything specific for single context invalidation. Hence, only advertise support for global context invalidation. The major benefit of nested VPID comes from having separate vpids when switching between L1 and L2, and also when L2's

[PATCH v2 4/5] KVM: nVMX: nested VPID emulation

VPID is used to tag address space and avoid a TLB flush. Currently L0 use the same VPID to run L1 and all its guests. KVM flushes VPID when switching between L1 and L2. This patch advertises VPID to the L1 hypervisor, then address space of L1 and L2 can be separately treated and avoid TLB flush

[PATCH v2 3/5] KVM: nVMX: emulate the INVVPID instruction

Add the INVVPID instruction emulation. Reviewed-by: Wincy Van Signed-off-by: Wanpeng Li --- arch/x86/include/asm/vmx.h | 3 +++ arch/x86/kvm/vmx.c | 49 +- 2 files changed, 51 insertions(+), 1

Re: [PATCH] KVM: arm/arm64: Fix memory leak if timer initialization fails

On Tue, Oct 06, 2015 at 11:14:35AM +0300, Pavel Fedin wrote: > Jump to correct label and free kvm_host_cpu_state > > Signed-off-by: Pavel Fedin > --- > arch/arm/kvm/arm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/kvm/arm.c

RE: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

Hello! > > One concern about this... Does it already have "We are Bosses, we Decided > > it, It's not > subject to > > change, We do not care" status? > > That's a rather negative question. Sorry, didn't want to offend anyone. I just wanted to tell that i know that you, as maintainers,

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On Thu, Oct 08, 2015 at 10:17:09AM +0300, Pavel Fedin wrote: > Hello! > > > +The mpidr encoding is based on the affinity information in the > > +architecture defined MPIDR, and the field is encoded as follows: > > + | 63 56 | 55 48 | 47 40 | 39 32 | > > + |

Re: [PATCH v4 3/7] KVM: arm/arm64: Fix the documentation

On Thu, Oct 08, 2015 at 09:52:02AM +0300, Pavel Fedin wrote: > Hello! > > > > --- a/Documentation/virtual/kvm/devices/arm-vgic.txt > > > +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt > > > @@ -44,28 +44,29 @@ Groups: > > >Attributes: > > > The attr field of kvm_device_attr

RE: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Hello! > Yes, I am looking at merging this. From the discussion with Pavel I > remember some things that I disagreed with, so I may propose a follow-up > patch. I will give this a try tomorrow. I reply to this thread, because this relates to the whole changeset. After the merge, some pieces

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 8 October 2015 at 10:10, Pavel Fedin wrote: > Sorry, didn't want to offend anyone. I just wanted to tell that i know > that you, as maintainers, have much more power than i do, and you can > always say "it's political decision, we just want it and that's final", > and if

RE: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

Hello! > Well, compatibility with GICv2 is the biggest mistake we made when > designing the GICv3 architecture. And that's why our emulation doesn't > give a damn about v2 compatibility. Ok, i see your arguments, and after that it becomes a matter of personal taste. Three beat one, i go your

Re: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

On Thu, Oct 08, 2015 at 12:15:06PM +0100, Andre Przywara wrote: > Hi, > > On 08/10/15 11:56, Marc Zyngier wrote: > > On 08/10/15 11:14, Christoffer Dall wrote: > >> Hi Pavel, > >> > >> On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote: > >>> Current KVM code has lots of old

RE: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Hello! > I don't mind the simplification (Andre was already removing the > piggybacking stuff as part of his ITS series). I'm a bit more cautious > about the sync_elrsr stuff, but that's mostly because I've only read the > patch in a superficial way. If you are really afraid of it, you can

Re: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

On 08/10/15 11:14, Christoffer Dall wrote: > Hi Pavel, > > On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote: >> Current KVM code has lots of old redundancies, which can be cleaned up. >> This patchset is actually a better alternative to >>

RE: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Hello! > I am a bit worries about how/if this is going to conflict with the ITS > series and other patches in flight touchignt he vgic. Just to note: of course i test them together. This works fine at least with vITS v2, where it replaces patch 0001 from the original series. I guess it should

AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

Dear KVM Developers: I am Xiang Song from UCloud company. We currently encounter a weird phenomenon about Qemu-KVM IOthread. We recently try to use Linux AIO from guest OS and find that the IOthread mechanism of Qemu-KVM will reorder I/O requests from guest OS even when the AIO write

Re: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Hi Pavel, On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote: > Current KVM code has lots of old redundancies, which can be cleaned up. > This patchset is actually a better alternative to > http://www.spinics.net/lists/arm-kernel/msg430726.html, which allows to > keep piggy-backed LRs.

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 08/10/15 10:28, Christoffer Dall wrote: > On Thu, Oct 08, 2015 at 12:10:35PM +0300, Pavel Fedin wrote: >> Hello! >> > [...] >> >>> The architecture defines how to address a specific CPU, and that's using >>> the MPIDR, not inventing our own scheme, so that's what we should do. >> >> But

Re: [PATCH 0/2] KVM: arm/arm64: Clean up some obsolete code

Hi, On 08/10/15 11:56, Marc Zyngier wrote: > On 08/10/15 11:14, Christoffer Dall wrote: >> Hi Pavel, >> >> On Fri, Oct 02, 2015 at 05:44:27PM +0300, Pavel Fedin wrote: >>> Current KVM code has lots of old redundancies, which can be cleaned up. >>> This patchset is actually a better alternative to

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On Thu, Oct 08, 2015 at 03:28:40PM +0300, Pavel Fedin wrote: > Hello! > > > Well, compatibility with GICv2 is the biggest mistake we made when > > designing the GICv3 architecture. And that's why our emulation doesn't > > give a damn about v2 compatibility. > > Ok, i see your arguments, and

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 08/10/15 13:45, Pavel Fedin wrote: > Hello! > >> There's no rush, I don't think this will make it into v4.4 anyhow > > Did you mean 4.3 here? No, that'd be really 4.4. 4.3 has closed 4 weeks ago, and 4.4 is about to open. This work is unlikely to make it before 4.5 TBH. Thanks,

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 8 October 2015 at 13:45, Pavel Fedin wrote: >> Speaking of which, does the QEMU side of this patch set require first >> adding the GICv3 emulation for the data structures or is there a >> stand-alone migration patch set somewhere? > > I rolled it out a week ago: >

RE: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

Hello! > There's no rush, I don't think this will make it into v4.4 anyhow Did you mean 4.3 here? > Speaking of which, does the QEMU side of this patch set require first > adding the GICv3 emulation for the data structures or is there a > stand-alone migration patch set somewhere? I rolled

Re: [PATCH 10/15] arm64: kvm: Fix {V}TCR_EL2_TG0 mask

On Tue, Sep 15, 2015 at 04:41:19PM +0100, Suzuki K. Poulose wrote: > From: "Suzuki K. Poulose" > > {V}TCR_EL2_TG0 is a 2bit wide field, where: > > 00 - 4K > 01 - 64K > 10 - 16K > > But we use only 1 bit, which has worked well so far since > we never cared about 16K.

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote: > On 07/10/15 09:26, Christoffer Dall wrote: > > Hi Suzuki, > > > > On Tue, Sep 15, 2015 at 04:41:12PM +0100, Suzuki K. Poulose wrote: > >> From: "Suzuki K. Poulose" > >> > >> Introduce helpers for finding the

Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

On Thu, 10/08 19:59, charlie.song wrote: > Dear KVM Developers: > I am Xiang Song from UCloud company. We currently encounter a weird > phenomenon about Qemu-KVM IOthread. > We recently try to use Linux AIO from guest OS and find that the IOthread > mechanism of Qemu-KVM will reorder

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On Thu, Oct 08, 2015 at 06:22:34PM +0100, Suzuki K. Poulose wrote: > On 08/10/15 15:45, Christoffer Dall wrote: > >On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote: > >>I just had a chat with Catalin, who did shed some light on this. > >>It all has to do with rounding up. What you

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

On 08/10/15 15:45, Christoffer Dall wrote: On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote: On 07/10/15 09:26, Christoffer Dall wrote: Hi Suzuki, I just had a chat with Catalin, who did shed some light on this. It all has to do with rounding up. What you would like to have

Re: Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

On Fri, 10/09 11:25, charlie.song wrote: > At 2015-10-08 23:37:02, "Fam Zheng" wrote: > >On Thu, 10/08 19:59, charlie.song wrote: > >> Dear KVM Developers: > >> I am Xiang Song from UCloud company. We currently encounter a weird > >> phenomenon about Qemu-KVM IOthread. >

[PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

async_pf_execute() seems to be missing a memory barrier which might cause the waker to not notice the waiter and miss sending a wake_up as in the following figure. async_pf_executekvm_vcpu_block

Re: Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

At 2015-10-08 23:37:02, "Fam Zheng" wrote: >On Thu, 10/08 19:59, charlie.song wrote: >> Dear KVM Developers: >> I am Xiang Song from UCloud company. We currently encounter a weird >> phenomenon about Qemu-KVM IOthread. >> We recently try to use Linux AIO from guest OS

Re: Re: Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

At 2015-10-09 12:33:20, "charlie.song" wrote: >At 2015-10-09 12:16:03, "Fam Zheng" wrote: >>On Fri, 10/09 11:25, charlie.song wrote: >>> At 2015-10-08 23:37:02, "Fam Zheng" wrote: >>> >On Thu, 10/08 19:59, charlie.song wrote: >>> >> Dear

Re: Re: Re: AIO requests may be disordered by Qemu-kvm iothread with disk cache=writethrough, Bug or Feature?

At 2015-10-09 12:16:03, "Fam Zheng" wrote: >On Fri, 10/09 11:25, charlie.song wrote: >> At 2015-10-08 23:37:02, "Fam Zheng" wrote: >> >On Thu, 10/08 19:59, charlie.song wrote: >> >> Dear KVM Developers: >> >> I am Xiang Song from UCloud company. We

[PATCH v2 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

KVM uses eoi_exit_bitmap to track vectors that need an action on EOI. The problem is that IOAPIC can be reconfigured while an interrupt with old configuration is pending and eoi_exit_bitmap only remembers the newest configuration; thus EOI from the pending interrupt is not recognized.

Re: [PATCH] KVM: x86: don't notify userspace IOAPIC on edge EOI

2015-10-08 20:30+0200, Radim Krčmář: > On real hardware, edge-triggered interrupts don't set a bit in TMR, > which means that IOAPIC isn't notified on EOI. Do the same here. > > Staying in guest/kernel mode after edge EOI is what we want for most > devices. If some bugs could be nicely worked

[PATCH v2 0/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

v2: * rewritten [1/2] and * refactored [2/2], all thanks to Paolo's comments This problem is not fixed for split userspace part as I think that it would be better to solve that by excluding edge interrupts from eoi_exit_bitmap (see the next patch in kvm-list for discussion). Radim Krčmář (2):

[PATCH v2 1/2] kvm: x86: set KVM_REQ_EVENT when updating IRR

After moving PIR to IRR, the interrupt needs to be delivered manually. Reported-by: Paolo Bonzini Cc: Signed-off-by: Radim Krčmář --- v2: completely rewritten arch/x86/kvm/lapic.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH] KVM: x86: don't notify userspace IOAPIC on edge EOI

On real hardware, edge-triggered interrupts don't set a bit in TMR, which means that IOAPIC isn't notified on EOI. Do the same here. Staying in guest/kernel mode after edge EOI is what we want for most devices. If some bugs could be nicely worked around with edge EOI notifications, we should