From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: andrew.cooper3@citrix.com, sherry.hurwitz@amd.com,
jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [RFC PATCH 7/9] x86/SVM: Add vcpu scheduling support for AVIC
Date: Fri, 14 Oct 2016 11:31:03 -0400 [thread overview]
Message-ID: <20161014153102.GC11650@localhost.localdomain> (raw)
In-Reply-To: <1474264368-4104-8-git-send-email-suravee.suthikulpanit@amd.com>
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@amd.com>
> ---
> 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@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-10-14 15:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 5:52 [RFC PATCH 0/9] Introduce AMD SVM AVIC Suravee Suthikulpanit
2016-09-19 5:52 ` [RFC PATCH 1/9] x86/HVM: Introduce struct hvm_pi_ops Suravee Suthikulpanit
2016-10-12 17:01 ` Konrad Rzeszutek Wilk
2016-09-19 5:52 ` [RFC PATCH 2/9] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static Suravee Suthikulpanit
2016-10-12 19:00 ` Konrad Rzeszutek Wilk
2016-09-19 5:52 ` [RFC PATCH 3/9] x86/HVM: Call vlapic_destroy after vcpu_destroy Suravee Suthikulpanit
2016-10-12 19:02 ` Konrad Rzeszutek Wilk
2016-12-22 11:09 ` Jan Beulich
2016-09-19 5:52 ` [RFC PATCH 4/9] x86/SVM: Modify VMCB fields to add AVIC support Suravee Suthikulpanit
2016-10-12 19:07 ` Konrad Rzeszutek Wilk
2016-12-22 11:11 ` Jan Beulich
2016-12-26 5:55 ` Suravee Suthikulpanit
2016-09-19 5:52 ` [RFC PATCH 5/9] x86/HVM/SVM: Add AVIC initialization code Suravee Suthikulpanit
2016-10-12 20:02 ` Konrad Rzeszutek Wilk
2016-11-17 16:05 ` Suravee Suthikulpanit
2016-11-17 17:18 ` Konrad Rzeszutek Wilk
2016-11-17 18:32 ` Suravee Suthikulpanit
2016-11-17 16:55 ` Suravee Suthikulpanit
2016-11-17 17:19 ` Konrad Rzeszutek Wilk
2016-10-14 14:03 ` Konrad Rzeszutek Wilk
2016-12-22 11:16 ` Jan Beulich
2016-12-28 3:36 ` Suravee Suthikulpanit
2016-09-19 5:52 ` [RFC PATCH 6/9] x86/SVM: Add AVIC vmexit handlers Suravee Suthikulpanit
2016-10-14 15:20 ` Konrad Rzeszutek Wilk
2016-12-12 10:34 ` Suravee Suthikulpanit
2017-01-07 1:24 ` Konrad Rzeszutek Wilk
2016-12-22 11:25 ` Jan Beulich
2016-09-19 5:52 ` [RFC PATCH 7/9] x86/SVM: Add vcpu scheduling support for AVIC Suravee Suthikulpanit
2016-10-14 15:31 ` Konrad Rzeszutek Wilk [this message]
2016-10-24 11:19 ` Jan Beulich
2016-12-22 11:32 ` Jan Beulich
2016-09-19 5:52 ` [RFC PATCH 8/9] x86/SVM: Add interrupt management code via AVIC Suravee Suthikulpanit
2016-10-14 15:44 ` Konrad Rzeszutek Wilk
2016-12-22 11:36 ` Jan Beulich
2016-09-19 5:52 ` [RFC PATCH 9/9] x86/SVM: Hook up miscellaneous AVIC functions Suravee Suthikulpanit
2016-10-14 15:46 ` Konrad Rzeszutek Wilk
2016-12-22 11:38 ` Jan Beulich
2016-09-19 13:09 ` [RFC PATCH 0/9] Introduce AMD SVM AVIC Konrad Rzeszutek Wilk
2016-09-19 16:21 ` Suravee Suthikulpanit
2016-09-20 14:34 ` Boris Ostrovsky
2016-12-04 7:40 ` Suravee Suthikulpanit
2016-12-22 11:38 ` Jan Beulich
2016-12-28 6:30 ` Suravee Suthikulpanit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161014153102.GC11650@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=sherry.hurwitz@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.