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