xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	xen-devel@lists.xen.org
Cc: andrew.cooper3@citrix.com, sherry.hurwitz@amd.com, jbeulich@suse.com
Subject: Re: [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers
Date: Tue, 3 Jan 2017 10:34:34 -0500	[thread overview]
Message-ID: <12c0832e-8177-ec19-463d-c74a5e993490@oracle.com> (raw)
In-Reply-To: <1483163161-2402-7-git-send-email-suravee.suthikulpanit@amd.com>


> +
> +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid)
> +{
> +    struct avic_log_apic_id_ent *entry, new_entry;
> +    u32 *bp = avic_get_bk_page_entry(v, APIC_DFR);

dfr would be a better name (and you use it in avic_handle_dfr_update()).

Also, 'logical' instead of 'log' in avic_log_apic_id_ent would be far
less confusing imo.

> +
> +    if ( !bp )
> +        return -EINVAL;
> +
> +    entry = avic_get_logical_id_entry(v, ldr, (*bp == APIC_DFR_FLAT));
> +    if (!entry)
> +        return -EINVAL;
> +
> +    new_entry = *entry;
> +    smp_rmb();
> +    new_entry.guest_phy_apic_id = g_phy_id;
> +    new_entry.valid = valid;
> +    *entry = new_entry;
> +    smp_wmb();
> +
> +    return 0;
> +}



> +
> +static int avic_handle_apic_id_update(struct vcpu *v, bool init)
> +{
> +    struct avic_phy_apic_id_ent *old, *new;
> +    struct arch_svm_struct *s = &v->arch.hvm_svm;
> +    u32 *apic_id_reg = avic_get_bk_page_entry(v, APIC_ID);
> +
> +    if ( !apic_id_reg )
> +        return -EINVAL;
> +
> +    old = s->avic_last_phy_id;
> +    ASSERT(old);
> +
> +    new = avic_get_phy_apic_id_ent(v, GET_APIC_PHYSICAL_ID(*apic_id_reg));
> +    if ( !new )
> +        return 0;
> +
> +    /* We need to move physical_id_entry to new offset */
> +    *new = *old;
> +    *((u64 *)old) = 0ULL;

This is pretty ugly. Can you define an invalid entry and assign it here
instead?

> +    s->avic_last_phy_id = new;
> +
> +    /*
> +     * Update the guest physical APIC ID in the logical
> +     * APIC ID table entry if LDR is already setup.
> +     */
> +    if ( v->arch.hvm_svm.avic_last_ldr )
> +        avic_handle_ldr_update(v);
> +
> +    return 0;
> +}
> +
> +static int avic_handle_dfr_update(struct vcpu *v)
> +{
> +    u32 mod;
> +    struct svm_domain *d = &v->domain->arch.hvm_domain.svm;
> +    u32 *dfr = avic_get_bk_page_entry(v, APIC_DFR);
> +
> +    if ( !dfr )
> +        return -EINVAL;
> +
> +    mod = (*dfr >> 28) & 0xFu;
> +
> +    spin_lock(&d->avic_ldr_mode_lock);
> +    if ( d->avic_ldr_mode != mod )
> +    {
> +        /*
> +         * We assume that all local APICs are using the same type.
> +         * If LDR mode changes, we need to flush the domain AVIC logical
> +         * APIC id table.
> +         */
> +        clear_domain_page(_mfn(d->avic_log_apic_id_table_mfn));
> +        smp_wmb();

Is this needed? I think clear_page() guarantees visibility/ordering (we
have SFENCE in clear_page_sse2() for this reason).


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-01-03 15:34 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-31  5:45 [PATCH v2 00/10] Introduce AMD SVM AVIC Suravee Suthikulpanit
2016-12-31  5:45 ` [PATCH v2 01/10] x86/HVM: Introduce struct hvm_pi_ops Suravee Suthikulpanit
2017-01-05  2:54   ` Tian, Kevin
2017-01-05  7:57     ` Jan Beulich
2017-01-05 15:51   ` Jan Beulich
2017-01-10  6:51     ` Suravee Suthikulpanit
2017-01-10  8:24       ` Jan Beulich
2017-01-10  9:45         ` Suravee Suthikulpanit
2016-12-31  5:45 ` [PATCH v2 02/10] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static Suravee Suthikulpanit
2017-01-05 15:53   ` Jan Beulich
2017-01-10  6:57     ` Suravee Suthikulpanit
2017-01-10  8:25       ` Jan Beulich
2016-12-31  5:45 ` [PATCH v2 03/10] x86/HVM: Call vlapic_destroy after vcpu_destroy Suravee Suthikulpanit
2017-01-05  2:56   ` Tian, Kevin
2017-01-05 15:56   ` Jan Beulich
2017-01-10  8:18     ` Suravee Suthikulpanit
2016-12-31  5:45 ` [PATCH v2 04/10] x86/SVM: Modify VMCB fields to add AVIC support Suravee Suthikulpanit
2016-12-31  5:45 ` [PATCH v2 05/10] x86/HVM/SVM: Add AVIC initialization code Suravee Suthikulpanit
2017-01-02 16:37   ` Andrew Cooper
2017-01-04 17:24     ` Suravee Suthikulpanit
2017-01-04 17:59       ` Andrew Cooper
2017-01-10  3:06     ` Suravee Suthikulpanit
2017-01-03 14:54   ` Boris Ostrovsky
2016-12-31  5:45 ` [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers Suravee Suthikulpanit
2017-01-02 17:28   ` Andrew Cooper
2017-01-05  4:07     ` Suravee Suthikulpanit
2017-01-03 15:34   ` Boris Ostrovsky [this message]
2017-01-05  6:41     ` Suravee Suthikulpanit
2016-12-31  5:45 ` [PATCH v2 07/10] x86/SVM: Add vcpu scheduling support for AVIC Suravee Suthikulpanit
2017-01-02 17:35   ` Andrew Cooper
2017-01-03 15:43   ` Boris Ostrovsky
2016-12-31  5:45 ` [PATCH v2 08/10] x86/SVM: Add interrupt management code via AVIC Suravee Suthikulpanit
2017-01-02 17:45   ` Andrew Cooper
2017-02-28 12:01     ` George Dunlap
2017-01-05 16:01   ` Jan Beulich
2016-12-31  5:46 ` [PATCH v2 09/10] x86/SVM: Hook up miscellaneous AVIC functions Suravee Suthikulpanit
2017-01-02 17:49   ` Andrew Cooper
2017-01-05 16:05   ` Jan Beulich
2017-01-10  8:35     ` Suravee Suthikulpanit
2017-01-10  9:00       ` Jan Beulich
2017-01-10 10:28         ` Suravee Suthikulpanit
2016-12-31  5:46 ` [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler Suravee Suthikulpanit
2017-01-03 16:01   ` Boris Ostrovsky
2017-01-03 16:04     ` Andrew Cooper
2017-01-05  8:00       ` Suravee Suthikulpanit
2017-01-05 16:07   ` Jan Beulich
2017-01-10 11:14     ` Suravee Suthikulpanit
2017-01-10 12:55       ` Jan Beulich

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=12c0832e-8177-ec19-463d-c74a5e993490@oracle.com \
    --to=boris.ostrovsky@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).