[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 7/9] x86/SVM: Add vcpu scheduling support for AVIC
On Mon, Sep 19, 2016 at 12:52:46AM -0500, Suravee Suthikulpanit wrote: > Add hooks to manage AVIC data structure during vcpu scheduling. > > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> > --- > xen/arch/x86/hvm/svm/avic.c | 82 > +++++++++++++++++++++++++++++++++++++++++++++ > xen/arch/x86/hvm/svm/svm.c | 10 ++++++ > 2 files changed, 92 insertions(+) > > diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c > index 90df181..cd8a9d4 100644 > --- a/xen/arch/x86/hvm/svm/avic.c > +++ b/xen/arch/x86/hvm/svm/avic.c > @@ -45,6 +45,83 @@ avic_get_phy_ait_entry(struct vcpu *v, int index) > } > > /*************************************************************** > + * AVIC VCPU SCHEDULING > + */ > +static void avic_vcpu_load(struct vcpu *v) > +{ > + struct arch_svm_struct *s = &v->arch.hvm_svm; > + int h_phy_apic_id; > + struct svm_avic_phy_ait_entry entry; > + > + if ( !svm_avic || !s->avic_phy_id_cache ) > + return; > + > + if ( test_bit(_VPF_blocked, &v->pause_flags) ) > + return; > + > + /* Note: APIC ID = 0xff is used for broadcast. Please put the Note: .. on a newline. So you have it like so: /* * Note: ... > + * APIC ID > 0xff is reserved. > + */ > + h_phy_apic_id = cpu_data[v->processor].apicid; > + if ( h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX ) What does that mean to the guest? I presume it means it will always get an VMEXIT b/c the is_running is not set? Meaning whatever guest ends up unhappily on an physical CPU with the APIC ID of 255 is screwed :-(? Perhaps at bootup time when SVM AVIC is initialized we have a check for APIC ID of 255 and put a blurb saying: "You have CPU%u with APIC ID 255. That value for SVM AVIC is reserved which has the unfortunate consequence that AVIC is disabled on CPU%u." So that the admin can perhaps schedule/pin dom0 on that CPU? > + return; > + > + entry = *(s->avic_phy_id_cache); Perhaps instead of '_cache' say '_last' ? Like 'avic_last_phy_id'? > + smp_rmb(); > + entry.host_phy_apic_id = h_phy_apic_id; > + entry.is_running = 1; > + *(s->avic_phy_id_cache) = entry; > + smp_wmb(); > +} > + > +static void avic_vcpu_put(struct vcpu *v) > +{ > + struct arch_svm_struct *s = &v->arch.hvm_svm; > + struct svm_avic_phy_ait_entry entry; > + > + if ( !svm_avic || !s->avic_phy_id_cache ) > + return; > + > + entry = *(s->avic_phy_id_cache); > + smp_rmb(); > + entry.is_running = 0; > + *(s->avic_phy_id_cache) = entry; > + smp_wmb(); > +} > + > +static void avic_vcpu_resume(struct vcpu *v) > +{ > + struct svm_avic_phy_ait_entry entry; > + struct arch_svm_struct *s = &v->arch.hvm_svm; > + > + if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache ) > + return; > + > + ASSERT(!test_bit(_VPF_blocked, &v->pause_flags)); > + > + entry = *(s->avic_phy_id_cache); > + smp_rmb(); > + entry.is_running = 1; > + *(s->avic_phy_id_cache)= entry; ^ Please add a space here. > + smp_wmb(); > +} > + > +static void avic_vcpu_block(struct vcpu *v) > +{ > + struct svm_avic_phy_ait_entry entry; > + struct arch_svm_struct *s = &v->arch.hvm_svm; > + > + if ( !svm_avic_vcpu_enabled(v) || !s->avic_phy_id_cache ) > + return; > + Should there be a corresponding ASSERT? Or is that done after these hooks are called? > + entry = *(s->avic_phy_id_cache); > + smp_rmb(); > + entry.is_running = 0; > + *(s->avic_phy_id_cache) = entry; > + smp_wmb(); > +} > + > +/*************************************************************** > * AVIC APIs > */ > int svm_avic_dom_init(struct domain *d) > @@ -97,6 +174,11 @@ int svm_avic_dom_init(struct domain *d) > clear_domain_page(_mfn(mfn)); > d->arch.hvm_domain.svm.avic_phy_ait_mfn = mfn; > > + d->arch.hvm_domain.pi_ops.pi_switch_to = avic_vcpu_put; > + d->arch.hvm_domain.pi_ops.pi_switch_from = avic_vcpu_load; > + d->arch.hvm_domain.pi_ops.vcpu_block = avic_vcpu_block; > + d->arch.hvm_domain.pi_ops.pi_do_resume = avic_vcpu_resume; > + > return ret; > err_out: > svm_avic_dom_destroy(d); > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 409096a..aafbfa1 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1011,6 +1011,10 @@ static void svm_ctxt_switch_from(struct vcpu *v) > svm_tsc_ratio_save(v); > > svm_sync_vmcb(v); > + > + if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_from ) > + v->domain->arch.hvm_domain.pi_ops.pi_switch_from(v); > + > svm_vmload(per_cpu(root_vmcb, cpu)); > > /* Resume use of ISTs now that the host TR is reinstated. */ > @@ -1050,6 +1054,9 @@ static void svm_ctxt_switch_to(struct vcpu *v) > svm_lwp_load(v); > svm_tsc_ratio_load(v); > > + if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_to ) > + v->domain->arch.hvm_domain.pi_ops.pi_switch_to(v); > + > if ( cpu_has_rdtscp ) > wrmsrl(MSR_TSC_AUX, hvm_msr_tsc_aux(v)); > } > @@ -1095,6 +1102,9 @@ static void noreturn svm_do_resume(struct vcpu *v) > vmcb_set_vintr(vmcb, intr); > } > > + if ( v->domain->arch.hvm_domain.pi_ops.pi_do_resume ) > + v->domain->arch.hvm_domain.pi_ops.pi_do_resume(v); > + > hvm_do_resume(v); > > reset_stack_and_jump(svm_asm_do_resume); > -- > 1.9.1 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > https://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |