On Thu, Sep 30, 2010, Zachary Amsden wrote about "Re: TSC in nested SVM and VMX": > 1) When reading an MSR, we are not emulating the L2 guest; we are > DIRECTLY reading the MSR for the L1 emulation. Any emulation of the L2 > guest is actually done by the code running /inside/ the L1 emulation, so > MSR reads for the L2 guest are handed by L1, and MSR reads for the L1 > guest are handled by L0, which is this code. >... > So if we are currently running nested, the L1 tsc_offset is stored in > the nested.hsave field; the vmcb which is active is polluted by the L2 > guest offset, which would be incorrect to return to the L1 emulation. Thanks for the detailed explanation. It seems, then, that the nested VMX logic is somewhat different from that of the nested SVM. In nested VMX, if a function gets called when running L1, the current VMCS will be that of L1 (aka vmcs01), not of its guest L2 (and I'm not even sure *which* L2 that would be when there are multiple L2 guests for the one L1). Nadav. -- Nadav Har'El | Friday, Oct 1 2010, 23 Tishri 5771 nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |What's tiny, yellow and very dangerous? A http://nadav.harel.org.il |canary with the super-user password. -- 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
