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
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 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
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
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
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
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
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(),
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
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: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
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
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
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
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.
>
>
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
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 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
> > > ---
> > >
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
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
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
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
> >
> >
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
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
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 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
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ář
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
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
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
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
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
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
>
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
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:
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
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:
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
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
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
> >
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-axm55xx_defconfig (attached as .config)
41 matches
Mail list logo