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 >> 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. Best regards, Yang -- 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
