From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH v4 2/4] x86/HVM: fix ID handling of x2APIC emulation
Date: Wed, 24 Sep 2014 11:42:51 +0100 [thread overview]
Message-ID: <5422A02B.1070205@citrix.com> (raw)
In-Reply-To: <54205A3F020000780003723E@mail.emea.novell.com>
On 22/09/14 16:19, Jan Beulich wrote:
>>>> On 22.09.14 at 16:30, <andrew.cooper3@citrix.com> wrote:
>> On 18/09/14 15:44, Jan Beulich wrote:
>>> @@ -656,6 +650,8 @@ static int vlapic_reg_write(struct vcpu
>>> struct vlapic *vlapic = vcpu_vlapic(v);
>>> int rc = X86EMUL_OKAY;
>>>
>>> + memset(&vlapic->loaded, 0, sizeof(vlapic->loaded));
>> This is slightly expensive to do for each register write. Why does this
>> clobbering need to be here? Could it not be....
> No, clearing this state can't be done in the load functions themselves
> (or else we wouldn't need the state in the first place. This, however,
> is more obvious with the follow-up addition I mailed in reply to the
> patch here, adding an "else" path to lapic_load_fixup(). That code
> wouldn't work as intended if we cleared the state early.
>
> If writing 12 bytes to memory would really turn out expensive, we
> may end up having to limit the clearing to certain register writes,
> but I was really instead considering to also do the clearing on
> register reads.
>
>>> +static void lapic_load_fixup(struct vlapic *vlapic)
>>> +{
>>> + uint32_t id = vlapic->loaded.id;
>>> +
>>> + if ( vlapic_x2apic_mode(vlapic) &&
>>> + id && vlapic->loaded.ldr == 1 &&
>>> + /* Further checks are optional: ID != 0 contradicts LDR == 1. */
>>> + GET_xAPIC_ID(id) == vlapic_vcpu(vlapic)->vcpu_id * 2 &&
>>> + id == SET_xAPIC_ID(GET_xAPIC_ID(id)) )
>>> + set_x2apic_id(vlapic);
>> ... in here, where we have positively identified whether fixup is needed
>> or not.
> For full context, here's the full intended function again:
>
> +static void lapic_load_fixup(struct vlapic *vlapic)
> +{
> + uint32_t id = vlapic->loaded.id;
> +
> + if ( vlapic_x2apic_mode(vlapic) && id && vlapic->loaded.ldr == 1 &&
> + /* Further checks are optional: ID != 0 contradicts LDR == 1. */
> + GET_xAPIC_ID(id) == vlapic_vcpu(vlapic)->vcpu_id * 2 &&
> + id == SET_xAPIC_ID(GET_xAPIC_ID(id)) )
> + set_x2apic_id(vlapic);
> + else /* Undo an eventual earlier fixup. */
> + {
> + vlapic_set_reg(vlapic, APIC_ID, id);
> + vlapic_set_reg(vlapic, APIC_LDR, vlapic->loaded.ldr);
> + }
> +}
How about dropping the optional checks, as "id && vlapic->loaded.ldr ==
1" covers the broken hypervisor case?
The "id = vcpu_id * 2" is a broken assumption which I do need to fix as
part of the cpuid infrastructure improvements, which would then break
this check for a broken Xen.
Furthermore, vlapic_x2apic_mode(vlapic) contradicts the use of
{GET,SET}_xAPIC_ID().
~Andrew
next prev parent reply other threads:[~2014-09-24 10:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 14:35 [PATCH v4 0/4] x86/HVM: fix various aspects of APIC emulation Jan Beulich
2014-09-18 14:43 ` [PATCH v4 1/4] x86/HVM: fix miscellaneous aspects of x2APIC emulation Jan Beulich
2014-09-22 13:14 ` Andrew Cooper
2014-09-22 13:40 ` Jan Beulich
2014-09-23 16:56 ` Andrew Cooper
2014-09-24 8:02 ` Jan Beulich
2014-09-18 14:44 ` [PATCH v4 2/4] x86/HVM: fix ID handling " Jan Beulich
2014-09-19 6:09 ` Jan Beulich
2014-09-22 14:30 ` Andrew Cooper
2014-09-22 15:19 ` Jan Beulich
2014-09-24 10:42 ` Andrew Cooper [this message]
2014-09-24 11:41 ` Jan Beulich
2014-09-24 12:10 ` Andrew Cooper
2014-09-18 14:44 ` [PATCH v4 3/4] x86/HVM: a few type adjustments Jan Beulich
2014-09-18 14:45 ` [PATCH v4 4/4] x86/vlapic: don't silently accept bad vectors 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=5422A02B.1070205@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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.