Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

On 12/07/2011 06:46 PM, Raghavendra K T wrote:

On 12/07/2011 08:22 PM, Avi Kivity wrote:

quoted

On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:

quoted

quoted

Also I think we can keep the kicked flag in vcpu->requests, no need
for
new storage.

Was going to suggest it but it violates the currently organized
processing of entries at the beginning of vcpu_enter_guest.

That is, this "kicked" flag is different enough from vcpu->requests
processing that a separate variable seems worthwhile (even more
different with convertion to MP_STATE at KVM_GET_MP_STATE).

IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
change due to apic re-evaluation).

Ok, So what I understand is we have to either :
1. retain current kick flag AS-IS but would have to make it migration
friendly. [I still have to get more familiar with migration side]
or
2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
vcpu->requests.

So what would be better? Please let me know.

IMO, KVM_REQ.

-- 
error compiling committee.c: too many arguments to function

On 12/08/2011 03:10 PM, Avi Kivity wrote:

On 12/07/2011 06:46 PM, Raghavendra K T wrote:

quoted

On 12/07/2011 08:22 PM, Avi Kivity wrote:

quoted

On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:

quoted

quoted

Also I think we can keep the kicked flag in vcpu->requests, no need
for
new storage.

Was going to suggest it but it violates the currently organized
processing of entries at the beginning of vcpu_enter_guest.

That is, this "kicked" flag is different enough from vcpu->requests
processing that a separate variable seems worthwhile (even more
different with convertion to MP_STATE at KVM_GET_MP_STATE).

IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
change due to apic re-evaluation).

Ok, So what I understand is we have to either :
1. retain current kick flag AS-IS but would have to make it migration
friendly. [I still have to get more familiar with migration side]
or
2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
vcpu->requests.

So what would be better? Please let me know.

IMO, KVM_REQ.

Ok, 'll continue in this direction. Hmm I think now the race condition 
should be kept in mind, pointed by Marcello.