On Mon, Apr 03, 2017 at 05:28:45PM +0200, Christoffer Dall wrote:
> Hi Drew,
>
> On Fri, Mar 31, 2017 at 06:06:49PM +0200, Andrew Jones wrote:
> > This series fixes some hard to produce races by introducing the use of
> > vcpu requests. It also fixes a couple easier to produce races, ones
> > tha
On Mon, Apr 03, 2017 at 06:51:02PM +0100, Marc Zyngier wrote:
> On 03/04/17 18:32, Christoffer Dall wrote:
> > On Fri, Mar 24, 2017 at 03:01:23PM +, Marc Zyngier wrote:
> >> On 24/03/17 14:34, Christoffer Dall wrote:
> >>> On Tue, Mar 21, 2017 at 07:20:49PM +, Marc Zyngier wrote:
> We
Hi Suzuki,
On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
> In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
> unmap_stage2_range() on the entire memory range for the guest. This could
> cause problems with other callers (e.g, munmap on a memslot) trying to
On 03/04/17 22:15, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git master
head: 1f1c45c6f66a586ca420ca02cbd93a35690394f9
commit: f9d9eb7f7a2c7e388861fe1cdb253f63e63555fe [1/3] kvm: arm/arm64: Fix
locking for kvm_free_stage2_pgd
config: arm-axm
On 04/04/17 11:14, Suzuki K Poulose wrote:
> On 03/04/17 22:15, kbuild test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
>> master
>> head: 1f1c45c6f66a586ca420ca02cbd93a35690394f9
>> commit: f9d9eb7f7a2c7e388861fe1cdb253f63e63555fe [1/3] kvm: arm/arm
Hi Christoffer,
On 04/04/17 11:13, Christoffer Dall wrote:
Hi Suzuki,
On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problem
On Tue, Apr 04, 2017 at 11:28:09AM +0100, Marc Zyngier wrote:
> On 04/04/17 11:14, Suzuki K Poulose wrote:
> > On 03/04/17 22:15, kbuild test robot wrote:
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> >> master
> >> head: 1f1c45c6f66a586ca420ca02cbd93a35690394f
Hi Marc,
On Mon, Apr 03, 2017 at 07:37:33PM +0100, Marc Zyngier wrote:
> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM
> could do with some TLC (it cannot perform a soft-restart at HYP, and
> has holes in the hyp-stub support in a number of places). In general,
> it would be d
On Tue, Apr 04, 2017 at 11:35:35AM +0100, Suzuki K Poulose wrote:
> Hi Christoffer,
>
> On 04/04/17 11:13, Christoffer Dall wrote:
> >Hi Suzuki,
> >
> >On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
> >>In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
> >>u
On 31/03/17 17:06, Andrew Jones wrote:
> This not only ensures visibility of changes to pause by using
> atomic ops, but also plugs a small race where a vcpu could get its
> pause state enabled just after its last check before entering the
> guest. With this patch, while the vcpu will still initial
On Tue, Apr 04, 2017 at 02:39:19PM +0100, Marc Zyngier wrote:
> On 31/03/17 17:06, Andrew Jones wrote:
> > This not only ensures visibility of changes to pause by using
> > atomic ops, but also plugs a small race where a vcpu could get its
> > pause state enabled just after its last check before en
On 04/04/2017 16:47, Andrew Jones wrote:
>>> -#define KVM_REQ_VCPU_EXIT 8
>>> +#define KVM_REQ_PAUSE 8
>> Small nit: can we have a #define for this 8? KVM_REQ_ARCH_BASE, or
>> something along those lines?
> Sounds good to me. Should I even do something like
>
> #define KVM_REQ_AR
On 04/04/17 15:51, Paolo Bonzini wrote:
>
>
> On 04/04/2017 16:47, Andrew Jones wrote:
-#define KVM_REQ_VCPU_EXIT 8
+#define KVM_REQ_PAUSE 8
>>> Small nit: can we have a #define for this 8? KVM_REQ_ARCH_BASE, or
>>> something along those lines?
>> Sounds good to me. Should
Hi Drew,
On Fri, Mar 31, 2017 at 06:06:51PM +0200, Andrew Jones wrote:
> Signed-off-by: Andrew Jones
> ---
> Documentation/virtual/kvm/vcpu-requests.rst | 114
>
> 1 file changed, 114 insertions(+)
> create mode 100644 Documentation/virtual/kvm/vcpu-requests.rst
>
On Fri, Mar 31, 2017 at 06:06:50PM +0200, Andrew Jones wrote:
> From: Radim Krčmář
>
> A first step in vcpu->requests encapsulation.
Could we have a note here on why we need to access vcpu->requests using
READ_ONCE now?
Thanks,
-Christoffer
>
> Signed-off-by: Radim Krčmář
> Signed-off-by: An
On Fri, Mar 31, 2017 at 06:06:52PM +0200, Andrew Jones wrote:
> Make sure we don't leave vcpu requests we don't intend to
> handle later set in the request bitmap. If we don't clear
> them, then kvm_request_pending() may return true when we
> don't want it to.
>
> Signed-off-by: Andrew Jones
> Ac
On Fri, Mar 31, 2017 at 06:06:53PM +0200, Andrew Jones wrote:
> This not only ensures visibility of changes to pause by using
> atomic ops, but also plugs a small race where a vcpu could get its
> pause state enabled just after its last check before entering the
> guest. With this patch, while the
On Tue, Apr 04, 2017 at 09:27:46AM +0200, Andrew Jones wrote:
> On Mon, Apr 03, 2017 at 05:28:45PM +0200, Christoffer Dall wrote:
> > Hi Drew,
> >
> > On Fri, Mar 31, 2017 at 06:06:49PM +0200, Andrew Jones wrote:
> > > This series fixes some hard to produce races by introducing the use of
> > > vc
On 04/04/2017 18:04, Christoffer Dall wrote:
>> For pause, only the requester should do the clearing.
This suggests that maybe this should not be a request. The request
would be just the need to act on a GIC command, exactly as before this patch.
What I don't understand is:
>> With this patch
On Tue, Apr 04, 2017 at 05:30:14PM +0200, Christoffer Dall wrote:
> On Fri, Mar 31, 2017 at 06:06:50PM +0200, Andrew Jones wrote:
> > From: Radim Krčmář
> >
> > A first step in vcpu->requests encapsulation.
>
> Could we have a note here on why we need to access vcpu->requests using
> READ_ONCE n
On Tue, Apr 04, 2017 at 05:24:03PM +0200, Christoffer Dall wrote:
> Hi Drew,
>
> On Fri, Mar 31, 2017 at 06:06:51PM +0200, Andrew Jones wrote:
> > Signed-off-by: Andrew Jones
> > ---
> > Documentation/virtual/kvm/vcpu-requests.rst | 114
> >
> > 1 file changed, 114
On Tue, Apr 04, 2017 at 05:34:01PM +0200, Christoffer Dall wrote:
> On Fri, Mar 31, 2017 at 06:06:52PM +0200, Andrew Jones wrote:
> > Make sure we don't leave vcpu requests we don't intend to
> > handle later set in the request bitmap. If we don't clear
> > them, then kvm_request_pending() may retu
On Tue, Apr 04, 2017 at 04:51:40PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 16:47, Andrew Jones wrote:
> >>> -#define KVM_REQ_VCPU_EXIT8
> >>> +#define KVM_REQ_PAUSE8
> >> Small nit: can we have a #define for this 8? KVM_REQ_ARCH_BASE, or
> >> something along those line
On Wed, Mar 29, 2017 at 09:41:47AM +0100, Will Deacon wrote:
> On Tue, Mar 28, 2017 at 10:29:31PM +0200, Christoffer Dall wrote:
> > On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> > > On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> > > > On Fri, Mar 10, 2017 at 06:3
On Tue, Apr 04, 2017 at 06:24:36PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 18:04, Christoffer Dall wrote:
> >> For pause, only the requester should do the clearing.
>
> This suggests that maybe this should not be a request. The request
> would be just the need to act on a GIC command, e
On Tue, Apr 04, 2017 at 07:06:00PM +0200, Andrew Jones wrote:
> On Tue, Apr 04, 2017 at 05:24:03PM +0200, Christoffer Dall wrote:
> > Hi Drew,
> >
> > On Fri, Mar 31, 2017 at 06:06:51PM +0200, Andrew Jones wrote:
> > > Signed-off-by: Andrew Jones
> > > ---
> > > Documentation/virtual/kvm/vcpu-re
On 04/04/2017 19:19, Christoffer Dall wrote:
> On Tue, Apr 04, 2017 at 06:24:36PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 04/04/2017 18:04, Christoffer Dall wrote:
For pause, only the requester should do the clearing.
>>
>> This suggests that maybe this should not be a request. The request
On 04/04/2017 19:23, Christoffer Dall wrote:
>> I think all !IN_GUEST_MODE should behave the same, so I was avoiding
>> the use of EXITING_GUEST_MODE and OUTSIDE_GUEST_MODE, which wouldn't be
>> hard to address, but then I'd also have to address
>> READING_SHADOW_PAGE_TABLES, which may complicate
On Fri, Mar 31, 2017 at 06:06:54PM +0200, Andrew Jones wrote:
> Like pause, replacing power_off with a vcpu request ensures
> visibility of changes and avoids the final race before entering
> the guest.
I think it's worth explaining the race in the commit message first, just
briefly.
>
> Signed-
On Fri, Mar 31, 2017 at 06:06:55PM +0200, Andrew Jones wrote:
> Don't use request-less VCPU kicks when injecting IRQs, as a VCPU
> kick meant to trigger the interrupt injection could be sent while
> the VCPU is outside guest mode, which means no IPI is sent, and
> after it has called kvm_vgic_flush
On Fri, Mar 31, 2017 at 06:06:56PM +0200, Andrew Jones wrote:
> Refactor PMU overflow handling in order to remove the request-less
> vcpu kick. Now, since kvm_vgic_inject_irq() uses vcpu requests,
> there should be no chance that a kick sent at just the wrong time
> (between the VCPU's call to kvm
On Tue, Apr 04, 2017 at 07:35:11PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 19:19, Christoffer Dall wrote:
> > On Tue, Apr 04, 2017 at 06:24:36PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 04/04/2017 18:04, Christoffer Dall wrote:
> For pause, only the requester should do the clear
On Tue, Apr 04, 2017 at 06:04:17PM +0200, Christoffer Dall wrote:
> On Fri, Mar 31, 2017 at 06:06:53PM +0200, Andrew Jones wrote:
> > This not only ensures visibility of changes to pause by using
> > atomic ops, but also plugs a small race where a vcpu could get its
> > pause state enabled just aft
On 04/04/2017 19:57, Christoffer Dall wrote:
>> Right. That code does
>>
>> tmp->arch.power_off = true;
>> kvm_vcpu_kick(tmp);
>>
>> and I think what's really missing in arm.c is the "if (vcpu->mode ==
>> EXITING_GUEST_MODE)" check that is found in x86.c. Then pa
On Tue, Apr 04, 2017 at 07:35:11PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 19:19, Christoffer Dall wrote:
> > On Tue, Apr 04, 2017 at 06:24:36PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 04/04/2017 18:04, Christoffer Dall wrote:
> For pause, only the requester should do the clear
On Tue, Apr 04, 2017 at 07:42:08PM +0200, Christoffer Dall wrote:
> On Fri, Mar 31, 2017 at 06:06:55PM +0200, Andrew Jones wrote:
> > Don't use request-less VCPU kicks when injecting IRQs, as a VCPU
> > kick meant to trigger the interrupt injection could be sent while
> > the VCPU is outside guest
On Tue, Apr 04, 2017 at 07:46:12PM +0200, Christoffer Dall wrote:
> On Fri, Mar 31, 2017 at 06:06:56PM +0200, Andrew Jones wrote:
> > Refactor PMU overflow handling in order to remove the request-less
> > vcpu kick. Now, since kvm_vgic_inject_irq() uses vcpu requests,
> > there should be no chance
On Tue, Apr 04, 2017 at 08:15:09PM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2017 19:57, Christoffer Dall wrote:
> >> Right. That code does
> >>
> >> tmp->arch.power_off = true;
> >> kvm_vcpu_kick(tmp);
> >>
> >> and I think what's really missing in arm.c is the
On 31/03/2017 18:06, Andrew Jones wrote:
> Don't use request-less VCPU kicks when injecting IRQs, as a VCPU
> kick meant to trigger the interrupt injection could be sent while
> the VCPU is outside guest mode, which means no IPI is sent, and
> after it has called kvm_vgic_flush_hwstate(), meaning
On 04/04/2017 19:42, Christoffer Dall wrote:
>
> this is not going to be called when we don't have the vgic, which means
> that if vcpu_interrupt_line() is used as you modify it above, the
> request will never get cleared.
Heh, I'll stop pretending I can give positive reviews of ARM patches and
On 04/04/2017 20:18, Andrew Jones wrote:
>> My understanding is that KVM-ARM is using KVM_REQ_VCPU_EXIT simply to
>> reuse the smp_call_function_many code in kvm_make_all_cpus_request.
>> Once you add EXITING_GUEST_MODE, ARM can just add a new function
>> kvm_kick_all_cpus and use it for both pau
On Tue, Apr 04, 2017 at 07:57:18PM +0200, Andrew Jones wrote:
> On Tue, Apr 04, 2017 at 06:04:17PM +0200, Christoffer Dall wrote:
> > On Fri, Mar 31, 2017 at 06:06:53PM +0200, Andrew Jones wrote:
> > > This not only ensures visibility of changes to pause by using
> > > atomic ops, but also plugs a
On Tue, Apr 04, 2017 at 08:29:18PM +0200, Andrew Jones wrote:
> On Tue, Apr 04, 2017 at 07:46:12PM +0200, Christoffer Dall wrote:
> > On Fri, Mar 31, 2017 at 06:06:56PM +0200, Andrew Jones wrote:
> > > Refactor PMU overflow handling in order to remove the request-less
> > > vcpu kick. Now, since k
On Fri, Mar 31, 2017 at 06:06:57PM +0200, Andrew Jones wrote:
> From: Levente Kurusa
>
> When two vcpus issue PSCI_CPU_ON on the same core at the same time,
> then it's possible for them to both enter the target vcpu's setup
> at the same time. This results in unexpected behaviors at best,
> and
On Fri, Mar 31, 2017 at 06:06:58PM +0200, Andrew Jones wrote:
> Cache the MPIDR in the vcpu structure to fix potential races that
> can arise between vcpu reset and the extraction of the MPIDR from
> the sys-reg array.
I don't understand the race, sorry.
Can you be more specific in where this goe
On 04/04/2017 21:04, Christoffer Dall wrote:
> - (On a related work, I suddenly felt it weird that
>kvm_make_all_cpus_request() doesn't wake up sleeping VCPUs, but only
>sends an IPI; does this mean that calling this function should be
>followed by a kick() for each VCPU? Maybe Radi
Hi James,
thanks for the patch, have you consider to told Qemu or KVM tools
the reason for this bus error(SEA/SEI)?
when Qemu or KVM tools get this SIGBUS signal, it do not know receive
this SIGBUS due to SEA or SEI.
OR KVM only send this SIGBUS when encounter SEA? if so, for the SEI
case, how
On 21.02.17 12:41, Christoffer Dall wrote:
Hi Alex,
On Fri, Feb 03, 2017 at 05:51:18PM +, Peter Maydell wrote:
On 3 February 2017 at 14:56, Christoffer Dall wrote:
From: Christoffer Dall
We have 2 modes for dealing with interrupts in the ARM world. We can
either handle them all using
48 matches
Mail list logo