On 01/29/2012 05:37 PM, Jan Kiszka wrote: > Hi all, > > I'm studying the TPR access optimization in qemu-kvm for quite a while > now. It's one of the, well, let's call it "hardest" parts of qemu-kvm I > dealt with so far. But it's slowly getting clearer. I'll be happy to answer questions here or on IRC. > > One thing I'm wondering now: This is practically targeting only 32-bit > Windows, right? Correct. 64-bit Windows uses cr8, which can be selectively intercepted according to the priority of a pending interrupt, if any, so it doesn't cause any excessive exits. > Already the assumption that we find a CPU index at > fs:0x51 is apparently hard-coding this. Or that kernel code is at > 0x8xxxxxxx or 0xExxxxxxx. > > But what makes sure that we aren't patching some other obscure OS that > doesn't comply with our assumptions but triggers the TPR access reports > nevertheless? Not much, but we've never had an issue. > Is there a way to detect the supported target OSes > reliably before patching anything? Otherwise this feature has to remain > off by default in upstream, I suppose. We could match fields with known values in the PCR, see http://www.reverse-engineering.info/SystemInformation/GetVarXP.pdf. Off-by-default dooms XP users to unusable performance on AMD hardware. -- error compiling committee.c: too many arguments to function -- 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
