Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-16 Thread Marc Zyngier
On 16/04/18 11:05, Shannon Zhao wrote: > > > On 2018/4/11 9:30, Shannon Zhao wrote: >> >> On 2018/4/10 23:37, Marc Zyngier wrote: [...] I don't mind either way. If you can be bothered to write a proper commit log for this, I'll take it. What I'd really want is Shannon to indicate

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-16 Thread Shannon Zhao
On 2018/4/11 9:30, Shannon Zhao wrote: > > On 2018/4/10 23:37, Marc Zyngier wrote: >> > On 10/04/18 16:24, Mark Rutland wrote: >>> >> On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: >>> On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: > I think we

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Shannon Zhao
On 2018/4/10 23:37, Marc Zyngier wrote: > On 10/04/18 16:24, Mark Rutland wrote: >> On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: >>> On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: I think we also need to update kvm->arch.vttbr before updating

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Christoffer Dall
On Tue, Apr 10, 2018 at 04:37:12PM +0100, Marc Zyngier wrote: > On 10/04/18 16:24, Mark Rutland wrote: > > On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: > >> On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: > >>> I think we also need to update kvm->arch.vttbr

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Marc Zyngier
On 10/04/18 16:24, Mark Rutland wrote: > On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: >> On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: >>> I think we also need to update kvm->arch.vttbr before updating >>> kvm->arch.vmid_gen, otherwise another CPU can come in,

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Christoffer Dall
On Tue, Apr 10, 2018 at 04:24:20PM +0100, Mark Rutland wrote: > On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: > > On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: > > > I think we also need to update kvm->arch.vttbr before updating > > > kvm->arch.vmid_gen,

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Mark Rutland
On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote: > On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: > > I think we also need to update kvm->arch.vttbr before updating > > kvm->arch.vmid_gen, otherwise another CPU can come in, see that the > > vmid_gen is up-to-date,

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Christoffer Dall
On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote: > On Mon, Apr 09, 2018 at 10:51:39PM +0200, Christoffer Dall wrote: > > On Mon, Apr 09, 2018 at 06:07:06PM +0100, Marc Zyngier wrote: > > > Before entering the guest, we check whether our VMID is still > > > part of the current

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-10 Thread Mark Rutland
On Mon, Apr 09, 2018 at 10:51:39PM +0200, Christoffer Dall wrote: > On Mon, Apr 09, 2018 at 06:07:06PM +0100, Marc Zyngier wrote: > > Before entering the guest, we check whether our VMID is still > > part of the current generation. In order to avoid taking a lock, > > we start with checking that

Re: [PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-09 Thread Christoffer Dall
On Mon, Apr 09, 2018 at 06:07:06PM +0100, Marc Zyngier wrote: > Before entering the guest, we check whether our VMID is still > part of the current generation. In order to avoid taking a lock, > we start with checking that the generation is still current, and > only if not current do we take the

[PATCH] KVM: arm/arm64: Close VMID generation race

2018-04-09 Thread Marc Zyngier
Before entering the guest, we check whether our VMID is still part of the current generation. In order to avoid taking a lock, we start with checking that the generation is still current, and only if not current do we take the lock, recheck, and update the generation and VMID. This leaves open a