On Fri, Apr 07, 2017 at 07:47:29PM +0800, Paolo Bonzini wrote:
>
>
> On 06/04/2017 22:14, Christoffer Dall wrote:
> >> So it seems like there are no races after all in KVM/ARM code
> >
> > No races after Drew's fix has been applied to set vcpu->mode =
> > IN_GUEST_MODE, before checking the pause
On 06/04/2017 22:14, Christoffer Dall wrote:
>> So it seems like there are no races after all in KVM/ARM code
>
> No races after Drew's fix has been applied to set vcpu->mode =
> IN_GUEST_MODE, before checking the pause flag, correct? (I think that's
> what the spin model below is modeling).
On Wed, Apr 05, 2017 at 01:37:10PM +0200, Paolo Bonzini wrote:
>
>
> 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
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 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
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 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 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 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 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 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 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
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 initially enter
the guest, it will exit immediately
19 matches
Mail list logo
