On 12/08/2011 03:10 PM, Avi Kivity wrote:
On 12/07/2011 06:46 PM, Raghavendra K T wrote:
On 12/07/2011 08:22 PM, Avi Kivity wrote:
On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
