search for: record_steal_time

...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 > simultaneous? I suspect you want something like so; except this has holes in. We clear KVM_ST_PAD_PREE...

...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 > simultaneous? I suspect you want something like so; except this has holes in. We clear KVM_ST_PAD_PREE...

On 06/07/2016 14:08, Wanpeng Li wrote: > 2016-07-06 18:44 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: >> >> >> On 06/07/2016 08:52, Peter Zijlstra wrote: >>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >>>> change fomr v1: >>>> a simplier definition of default vcpu_is_preempted >>>> skip mahcine

On 06/07/2016 14:08, Wanpeng Li wrote: > 2016-07-06 18:44 GMT+08:00 Paolo Bonzini <pbonzini at redhat.com>: >> >> >> On 06/07/2016 08:52, Peter Zijlstra wrote: >>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: >>>> change fomr v1: >>>> a simplier definition of default vcpu_is_preempted >>>> skip mahcine

...lse anway. Old KVMs won't have the feature, so we could also assign only when KVM reports it, but that requires extra definitions and the performance gain is fairly small, so I'm ok with this. > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > @@ -2057,6 +2057,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu) > &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) > return; > > + vcpu->arch.st.steal.preempted = 0; > + > if (vcpu->arch.st.steal.version & 1) > vcpu->arch.st.steal.version += 1; /* first time write, random junk *...

...lse anway. Old KVMs won't have the feature, so we could also assign only when KVM reports it, but that requires extra definitions and the performance gain is fairly small, so I'm ok with this. > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > @@ -2057,6 +2057,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu) > &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) > return; > > + vcpu->arch.st.steal.preempted = 0; > + > if (vcpu->arch.st.steal.version & 1) > vcpu->arch.st.steal.version += 1; /* first time write, random junk *...

...mpted, 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 >> simultaneous? > > I suspect you want something like so; except this has holes in. >...

...on; __u32 flags; - __u32 pad[12]; + __u8 preempted; + __u8 u8_pad[3]; + __u32 pad[11]; }; #define KVM_STEAL_ALIGNMENT_BITS 5 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e375235..f06e115 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2057,6 +2057,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu) &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) return; + vcpu->arch.st.steal.preempted = 0; + if (vcpu->arch.st.steal.version & 1) vcpu->arch.st.steal.version += 1; /* first time write, random junk */ @@ -2810,8 +2812,22 @@ void kvm...

...t 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 simultaneous? Regards, Wanpeng Li

...ck 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 >>> simultaneous? >> >> I suspect you want something like so; except thi...

...ck 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 >>> simultaneous? >> >> I suspect you want something like so; except thi...

...RT_SPINLOCKS + pv_lock_ops.vcpu_is_preempted = kvm_vcpu_is_preempted; +#endif } if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6c633de..a627537 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2057,6 +2057,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu) &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) return; + vcpu->arch.st.steal.preempted = 0; + if (vcpu->arch.st.steal.version & 1) vcpu->arch.st.steal.version += 1; /* first time write, random junk */ @@ -2810,8 +2812,24 @@ void kvm...

..._ops); +EXPORT_SYMBOL (pv_vcpu_ops); EXPORT_SYMBOL (pv_cpu_ops); EXPORT_SYMBOL (pv_mmu_ops); EXPORT_SYMBOL_GPL(pv_info); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6c633de..0ffc5aa 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2057,6 +2057,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu) &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) return; + vcpu->arch.st.steal.preempted = 0; + if (vcpu->arch.st.steal.version & 1) vcpu->arch.st.steal.version += 1; /* first time write, random junk */ @@ -2812,6 +2814,16 @@ void kvm...

change from v4: spilt x86 kvm vcpu preempted check into two patches. add documentation patch. add x86 vcpu preempted check patch under xen add s390 vcpu preempted check patch change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc,

change from v4: spilt x86 kvm vcpu preempted check into two patches. add documentation patch. add x86 vcpu preempted check patch under xen add s390 vcpu preempted check patch change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc,

change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion.

change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion.

change from v6: fix typos and remove uncessary comments. change from v5: spilt x86/kvm patch into guest/host part. introduce kvm_write_guest_offset_cached. fix some typos. rebase patch onto 4.9.2 change from v4: spilt x86 kvm vcpu preempted check into two patches. add documentation patch. add x86 vcpu preempted check patch under xen add s390 vcpu preempted check patch change from v3:

change from v6: fix typos and remove uncessary comments. change from v5: spilt x86/kvm patch into guest/host part. introduce kvm_write_guest_offset_cached. fix some typos. rebase patch onto 4.9.2 change from v4: spilt x86 kvm vcpu preempted check into two patches. add documentation patch. add x86 vcpu preempted check patch under xen add s390 vcpu preempted check patch change from v3:

The 5-patch series to follow this email extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks, based on Xen's implementation. One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick another vcpu out of halt state. The blocking of vcpu is done using halt() in (lock_spinning) slowpath. Changes in V4: - reabsed to 3.2.0 pre. - use APIC