On Tue, Dec 25, 2012 at 08:24:43AM +0000, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2012-12-25:
> > On Tue, Dec 25, 2012 at 07:46:53AM +0000, Zhang, Yang Z wrote:
> >> Gleb Natapov wrote on 2012-12-25:
> >>> On Tue, Dec 25, 2012 at 07:25:15AM +0000, Zhang, Yang Z wrote:
> >>>> Gleb Natapov wrote on 2012-12-25:
> >>>>> On Tue, Dec 25, 2012 at 06:42:59AM +0000, Zhang, Yang Z wrote:
> >>>>>> Gleb Natapov wrote on 2012-12-25:
> >>>>>>> On Mon, Dec 24, 2012 at 11:53:37PM +0000, Zhang, Yang Z wrote:
> >>>>>>>> Gleb Natapov wrote on 2012-12-24:
> >>>>>>>>> On Mon, Dec 24, 2012 at 02:35:35AM +0000, Zhang, Yang Z wrote:
> >>>>>>>>>> Zhang, Yang Z wrote on 2012-12-24:
> >>>>>>>>>>> Gleb Natapov wrote on 2012-12-20:
> >>>>>>>>>>>> On Mon, Dec 17, 2012 at 01:30:50PM +0800, Yang Zhang wrote:
> >>>>>>>>>>>>> basically to benefit from apicv, we need clear MSR bitmap for
> >>>>>>>>>>>>> corresponding x2apic MSRs:
> >>>>>>>>>>>>> 0x800 - 0x8ff: no read intercept for apicv register
> >>>>>>>>>>>>> virtualization TPR,EOI,SELF-IPI: no write intercept for
> >>>>>>>>>>>>> virtual interrupt
> >>> delivery
> >>>>>>>>>>>> We do not set "Virtualize x2APIC mode" bit in secondary
> >>>>>>>>>>>> execution control. If I read the spec correctly without that
> >>>>>>>>>>>> those MSR read/writes will go straight to physical local APIC.
> >>>>>>>>>>> Right. Now it cannot get benefit, but we may enable it in
> >>>>>>>>>>> future and then we can benefit from it.
> >>>>>>>>> Without enabling it you cannot disable MSR intercept for x2apic
> >>>>>>>>> MSRs.
> >>>>>>>>>
> >>>>>>>>>> how about to add the following check:
> >>>>>>>>>> if (apicv_enabled && virtual_x2apic_enabled)
> >>>>>>>>>> clear_msr();
> >>>>>>>>>>
> >>>>>>>>> I do not understand what do you mean here.
> >>>>>>>> In this patch, it will clear MSR bitmap(0x800 -0x8ff) when apicv
> > enabled.
> >>> As
> >>>>> you
> >>>>>>> said, since kvm doesn't set "virtualize x2apic mode", APIC register
> >>>>>>> virtualization never take effect. So we need to clear MSR bitmap only
> >>>>>>> when apicv enabled and virtualize x2apic mode set.
> >>>>>>>>
> >>>>>>> But currently it is never set.
> >>>>>> So you think the third patch is not necessary currently? Unless we
> >>>>>> enabled "virtualize x2apic mode".
> >>>>>>
> >>>>> Without third patch vid will not work properly if a guest is in x2apic
> >>>>> mode. Actually second and third patches need to be reordered to not have
> >>>>> a windows where x2apic is broken. The problem is that this patch itself
> >>>>> is buggy since it does not set "virtualize x2apic mode" flag. It should
> >>>>> set the flag if vid is enabled and if the flag cannot be set vid should
> >>>>> be forced off.
> >>>> In what conditions this flag cannot be set? I think the only case is
> >>>> that KVM
> >>> doesn't expose the x2apic capability to guest, if this is true, the
> >>> guest will never use x2apic and we still can use vid.
> >>>>
> >>> We can indeed set "virtualize x2apic mode" unconditionally since it does
> >>> not take any effect if x2apic MSRs are intercepted.
> >> No. Since "Virtual APIC access" must be cleared if "virtualize x2apic
> >> mode" is set,
> > and if guest still use xAPIC, then there should be lots of ept violations
> > for apic
> > access emulation. This will hurt performance.
> > Stupid HW, why this pointless limitation? Can you point me where SDM says
> > that?
> Vol 3, 26.2.1.1
>
Thanks.
> >> We should only set "virtualize x2apic mode" when guest really uses
> >> x2apic(guest set bit 11 of APIC_BASE_MSR).
> >>
> > Looks like SDM force us to.
> >
And we can disable x2apic MSR interception only after "virtualize x2apic
mode" is set i.e when guest sets bit 11 of APIC_BASE_MSR.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
