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. -- error compiling committee.c: too many arguments to function -- 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
