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.
> > >
> > > 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.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
