[PATCH v2 0/4] implement vcpu preempted check
kernellwp at gmail.com
Thu Jul 7 20:12:51 AEST 2016
2016-07-07 17:42 GMT+08:00 Peter Zijlstra <peterz at infradead.org>:
> On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote:
>> 2016-07-06 20:28 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>:
>> > Hmm, you're right. We can use bit 0 of struct kvm_steal_time's flags to
>> > indicate that pad is a "VCPU preempted" field; if pad is 1, the
>> > VCPU has been scheduled out since the last time the guest reset the bit.
>> > The guest can use an xchg to test-and-clear it. The bit can be
>> > accessed at any time, independent of the version field.
>> If one vCPU is preempted, and guest check it several times before this
>> vCPU is scheded in, then the first time we can get "vCPU is
>> preempted", however, since the field is cleared, the second time we
>> will get "vCPU is running".
>> Do you mean we should call record_steal_time() in both kvm_sched_in()
>> and kvm_sched_out() to record this field? Btw, if we should keep both
>> vcpu->preempted and kvm_steal_time's "vCPU preempted" field present
> I suspect you want something like so; except this has holes in.
> We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it
> after enabling it, this means that if we get preempted in between, the
> vcpu is reported as running even though it very much is not.
Paolo also point out this to me offline yesterday: "Please change
pad to "__u32 preempted; __u32 pad;" too, and remember to
update Documentation/virtual/kvm/msr.txt!". Btw, do this in preemption
notifier means that the vCPU is real preempted on host, however,
depends on vmexit is different semantic I think.
More information about the Linuxppc-dev