Paolo Bonzini wrote on 2015-08-03: > > > On 03/08/2015 04:37, Zhang, Yang Z wrote: >>>> Only virtualized APIC register reads use the virtual TMR >>>> registers (SDM >>>> 29.4.2 or 29.5), but these just read data from the corresponding >>>> field in the virtual APIC page. >> >> 24.11.4 Software Access to Related Structures In addition to data in >> the VMCS region itself, VMX non-root operation can be controlled by >> data structures that are referenced by pointers in a VMCS (for >> example, the I/O bitmaps). While the pointers to these data >> structures are parts of the VMCS, the data structures themselves are >> not. They are not accessible using VMREAD and VMWRITE but by >> ordinary memory writes. > > I don't think the TMR fields of the virtual-APIC page are among the > data structures that _controls_ VMX non-root operations, because: > > * it is not part of the virtualized APIC state is listed in 29.1.1 > > * read accesses from the APIC-access page simply return data from the > corresponding page offset on the virtual-APIC page using the memory > access type stored in IA32_VMX_BASIC_MSR. I think this explicitly > says that the effects of 24.11.1 (especially non-deterministic > behavior after a write) do not apply here. > > In any case, the TMR behavior introduced by the APICv patches is > completely different from the hardware behavior, so it has to be fixed. But any real problem with it? > The alternative is to inject level-triggered interrupts > synchronously, without using posted interrupts. > > I'll write some testcases to understand the functioning of TMR in the > virtual-APIC page, but the manual seems clear to me. Currently, no existing hardware will use TMR and will not cause any problem.(That's the reason why we leave it in Xen).But we don't know whether future hardware will use it or not(SDM always keeps changing :)).And per 24.11.4's description, the perfect solution is don't modify it. btw, IIRC, only TMR doesn't follow the rule. All other VMCS accesses are issued in right VMCS context. > > Paolo 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
