2017-04-05 20:29+0200, Paolo Bonzini:
> On 05/04/2017 19:45, Christoffer Dall wrote:
But the problem is that kvm_make_all_cpus_request() only sends IPIs to
CPUs where the mode was different from OUTSIDE_GUEST_MODE, so there it's
about !OUTSIDE_GUEST_MODE rather than !IN_GUEST_MODE, s
2017-04-05 19:39+0200, Christoffer Dall:
> On Wed, Apr 05, 2017 at 03:10:50PM +0200, Radim Krčmář wrote:
>> 2017-04-04 18:41+0200, Andrew Jones:
>> > 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: R
On Fri, Mar 31, 2017 at 4:16 PM, Radha Mohan wrote:
> On Thu, Mar 30, 2017 at 9:47 AM, Laszlo Ersek wrote:
>> On 03/29/17 20:56, Christoffer Dall wrote:
>>> On Tue, Mar 28, 2017 at 01:24:15PM -0700, Radha Mohan wrote:
On Tue, Mar 28, 2017 at 1:16 PM, Christoffer Dall wrote:
> Hi Radha,
On 05/04/2017 19:39, Christoffer Dall wrote:
>> Uses of vcpu->requests should already have barriers that take care of
>> the ordering. I think the main reason for READ_ONCE() is to tell
>> programmers that requests are special, but predictable.
>
> I don't know what to do with "special, but pre
On 05/04/2017 19:45, Christoffer Dall wrote:
>>> But the problem is that kvm_make_all_cpus_request() only sends IPIs to
>>> CPUs where the mode was different from OUTSIDE_GUEST_MODE, so there it's
>>> about !OUTSIDE_GUEST_MODE rather than !IN_GUEST_MODE, so there's some
>>> subtlety here which I
On Wed, Apr 05, 2017 at 04:11:40PM +0200, Radim Krčmář wrote:
> 2017-04-04 19:23+0200, Christoffer Dall:
> > 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:
> >> > On Fri, Mar 31, 2017 at 06:06:51PM +0200, Andrew J
On Wed, Apr 05, 2017 at 03:10:50PM +0200, Radim Krčmář wrote:
> 2017-04-04 18:41+0200, Andrew Jones:
> > 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 vcp
2017-04-05 12:13+0200, Christoffer Dall:
> Hi Paolo and Radim,
>
> Please pull a handfull of fixes for the next -rc release of v4.11.
>
> They include:
> - Addressing a problem with GICv3 userspace save/restore
> - Clarify GICv2 userspace save/restore ABI
> - Be more careful in clearing GIC LR
2017-04-04 19:23+0200, Christoffer Dall:
> 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:
>> > On Fri, Mar 31, 2017 at 06:06:51PM +0200, Andrew Jones wrote:
>> > > +and will definitely see the request, or is outside
2017-04-04 18:41+0200, Andrew Jones:
> 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
On 05/04/2017 09:09, Christoffer Dall wrote:
>>> - In the explanation you wrote, you use the term 'we' a lot, but when
>>>talking about SMP barriers, I think it only makes sense to talk about
>>>actions and observations between multiple CPUs and we have to be
>>>specific about which
On Wed, Apr 05, 2017 at 01:03:36PM +0200, Christoffer Dall wrote:
> On Wed, Apr 05, 2017 at 10:50:05AM +0200, Andrew Jones wrote:
> > On Tue, Apr 04, 2017 at 09:44:39PM +0200, Christoffer Dall wrote:
> > > On Fri, Mar 31, 2017 at 06:06:58PM +0200, Andrew Jones wrote:
> > > > Cache the MPIDR in the
On Wed, Apr 05, 2017 at 10:50:05AM +0200, Andrew Jones wrote:
> On Tue, Apr 04, 2017 at 09:44:39PM +0200, Christoffer Dall wrote:
> > 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 re
Hi Paolo and Radim,
Please pull a handfull of fixes for the next -rc release of v4.11.
They include:
- Addressing a problem with GICv3 userspace save/restore
- Clarify GICv2 userspace save/restore ABI
- Be more careful in clearing GIC LRs
- Add missing synchronization primitive to our MMU han
On Wed, Apr 05, 2017 at 11:12:12AM +0200, Andrew Jones wrote:
> On Wed, Apr 05, 2017 at 10:50:05AM +0200, Christoffer Dall wrote:
> > On Wed, Apr 05, 2017 at 10:35:59AM +0200, Andrew Jones wrote:
> > > On Tue, Apr 04, 2017 at 09:42:08PM +0200, Christoffer Dall wrote:
> > > > On Fri, Mar 31, 2017 at
This series is the second version of the rework of the patches to support
architected timers with a userspace irqchip sent by Alexander Graf [1].
We first cleanup some of the timer code to make it easier to understand
what is being done in the later patches, and then define the ABI,
implement time
From: Christoffer Dall
Currently we check if we have an in-kernel irqchip and if the vgic was
properly implemented several places in the arch timer code. But, we
already predicate our enablement of the arm timers on having a valid
and initialized gic, so we can simply check if the timers are ena
From: Christoffer Dall
When not using an in-kernel VGIC, but instead emulating an interrupt
controller in userspace, we should report the PMU overflow status to
that userspace interrupt controller using the KVM_CAP_ARM_USER_IRQ
feature.
Signed-off-by: Christoffer Dall
---
arch/arm/kvm/arm.c
From: Christoffer Dall
Now when we support both the virtual timer and PMU reporting interrupts
to userspace, we can advertise this support.
Signed-off-by: Christoffer Dall
---
arch/arm/kvm/arm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
From: Alexander Graf
We have 2 modes for dealing with interrupts in the ARM world. We can
either handle them all using hardware acceleration through the vgic or
we can emulate a gic in user space and only drive CPU IRQ pins from
there.
Unfortunately, when driving IRQs from user space, we never t
From: Alexander Graf
If you're running with a userspace gic or other interrupt constroller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only constru
On Wed, Apr 05, 2017 at 10:50:05AM +0200, Christoffer Dall wrote:
> On Wed, Apr 05, 2017 at 10:35:59AM +0200, Andrew Jones wrote:
> > On Tue, Apr 04, 2017 at 09:42:08PM +0200, Christoffer Dall wrote:
> > > On Fri, Mar 31, 2017 at 06:06:57PM +0200, Andrew Jones wrote:
> > > > From: Levente Kurusa
>
On Tue, Apr 04, 2017 at 09:44:39PM +0200, Christoffer Dall wrote:
> 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
On Wed, Apr 05, 2017 at 10:35:59AM +0200, Andrew Jones wrote:
> On Tue, Apr 04, 2017 at 09:42:08PM +0200, Christoffer Dall wrote:
> > 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
On Tue, Apr 04, 2017 at 09:42:08PM +0200, Christoffer Dall wrote:
> 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 se
On Wed, Apr 05, 2017 at 02:14:11AM +0200, Alexander Graf wrote:
>
>
> 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 h
On Tue, Apr 04, 2017 at 10:10:15PM +0200, Paolo Bonzini wrote:
>
>
> 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 t
27 matches
Mail list logo
