From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Yang Zhang <yang.z.zhang@intel.com>,
kvm@vger.kernel.org, haitao.shan@intel.com,
xiantao.zhang@intel.com, Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH v11 2/3] x86, apicv: add virtual x2apic support
Date: Mon, 21 Jan 2013 20:16:18 -0200 [thread overview]
Message-ID: <20130121221618.GE10985@amt.cnet> (raw)
In-Reply-To: <20130121213420.GA8427@redhat.com>
On Mon, Jan 21, 2013 at 11:34:20PM +0200, Gleb Natapov wrote:
> On Mon, Jan 21, 2013 at 07:21:13PM -0200, Marcelo Tosatti wrote:
> > On Mon, Jan 21, 2013 at 10:21:14PM +0200, Gleb Natapov wrote:
> > > > > }
> > > > > +
> > > > > + vcpu->arch.apic_base = value;
> > > >
> > > > Simpler to have
> > > >
> > > > if (apic_x2apic_mode(apic)) {
> > > > ...
> > > > kvm_x86_ops->set_virtual_x2apic_mode(vcpu, true);
> > > > } else {
> > > > kvm_x86_ops->set_virtual_x2apic_mode(vcpu, false);
> > > > }
> > > >
> > > This will not work during cpu init. That was discussed on one of
> > > the previous iterations of the patch. When this code is called during
> > > vcpu init vmcs is not loaded yet so set_virtual_x2apic_mode() cannot
> > > write into it.
> >
> > Are you saying that the logic to write on bit value change is due to
> > ordering with cpu init or that the callback is at the wrong place?
> >
> The logic is because of ordering with cpu init.
OK. Still must move this conditional callback after assignment of apic_base.
> > > > Why not disable write intercept for all MSRs which represent APIC registers
> > > > that are virtualized? Why TPR is special?
> > > >
> > > This patch goes before vid is enabled. At this point only TPR is
> > > vitalized. If APIC_WRITE exit will be generated on unhandled MSR write
> > > then we can disable intercept for all x2apic MSRs here.
> >
> > -ENOPARSE, please be more verbose. "unhandled MSR write" ?
> By unhandled I mean unintercepted. Write to x2apic MSR will either
> generate MSR write exit if msr bitmap says so and then x2apic MSR will
> be handled just like today, or, if we disable intercept, it will
> generate APIC_WRITE exit (need to consult SDM here, not sure about it).
> One is not really preferable to the other.
It will generate APIC_WRITE, for example, if due to EOI virtualization
exiting.
The question is, why is intercept for EOI MSR address (0x80B) not being
disabled here, while TPR is? I don't see intercept disabled by other
patches either.
APIC_WRITE exit (conditional, see EOI virtualization page) is
preferable to MSR write exit (unconditional).
next prev parent reply other threads:[~2013-01-22 2:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 10:21 [PATCH v11 0/3] x86, apicv: Add APIC virtualization support Yang Zhang
2013-01-16 10:21 ` [PATCH v11 1/3] x86, apicv: add APICv register " Yang Zhang
2013-01-16 10:21 ` [PATCH v11 2/3] x86, apicv: add virtual x2apic support Yang Zhang
2013-01-17 13:22 ` Gleb Natapov
2013-01-18 1:49 ` Zhang, Yang Z
2013-01-21 19:59 ` Marcelo Tosatti
2013-01-21 20:21 ` Gleb Natapov
2013-01-21 21:21 ` Marcelo Tosatti
2013-01-21 21:34 ` Gleb Natapov
2013-01-21 22:16 ` Marcelo Tosatti [this message]
2013-01-22 0:33 ` Marcelo Tosatti
2013-01-22 3:37 ` Zhang, Yang Z
2013-01-22 9:45 ` Gleb Natapov
2013-01-22 9:42 ` Gleb Natapov
2013-01-22 12:21 ` Zhang, Yang Z
2013-01-22 15:55 ` Gleb Natapov
2013-01-22 23:13 ` Marcelo Tosatti
2013-01-23 0:35 ` Zhang, Yang Z
2013-01-23 10:29 ` Gleb Natapov
2013-01-16 10:21 ` [PATCH v11 3/3] x86, apicv: add virtual interrupt delivery support Yang Zhang
2013-01-17 1:26 ` Zhang, Yang Z
2013-01-20 12:51 ` Gleb Natapov
2013-01-21 0:49 ` Zhang, Yang Z
2013-01-21 5:03 ` Gleb Natapov
2013-01-21 7:18 ` Zhang, Yang Z
2013-01-21 21:08 ` Marcelo Tosatti
2013-01-23 0:45 ` Zhang, Yang Z
2013-01-23 10:33 ` Gleb Natapov
2013-01-23 10:52 ` Zhang, Yang Z
2013-01-21 21:05 ` Marcelo Tosatti
2013-01-21 21:18 ` Gleb Natapov
2013-01-21 21:54 ` Marcelo Tosatti
2013-01-22 3:38 ` Zhang, Yang Z
2013-01-16 10:27 ` [PATCH v11 0/3] x86, apicv: Add APIC virtualization support Gleb Natapov
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=20130121221618.GE10985@amt.cnet \
--to=mtosatti@redhat.com \
--cc=gleb@redhat.com \
--cc=haitao.shan@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=xiantao.zhang@intel.com \
--cc=yang.z.zhang@intel.com \
/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