kvm's vapic
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.
One thing I'm wondering now: This is practically targeting only 32-bit Windows, right? 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? 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.
Jan
Quoted 5 lines · Jan Kiszka
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Avi Kivity
Quoted 7 lines
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.
Checking that the bios is mapped at 0x[8e]0000000 + phys should filter out most non-Windows OSes.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 5 lines · Avi Kivity
Quoted 4 lines · Avi Kivity
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Checking that the bios is mapped at 0x[8e]0000000 + phys should filter out most non-Windows OSes.
Possibly.
What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there?
Jan
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Avi Kivity
Quoted 7 lines
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.
Quoted 7 lines
Quoted 2 lines
Checking that the bios is mapped at 0x[8e]0000000 + phys should filter out most non-Windows OSes.
Possibly.
What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there?
We don't. But things like the IDT/GTD/TSS and especially SelfPcr look like good candidates.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 16 lines · Avi Kivity
Quoted 15 lines · Jan Kiszka
Quoted 13 lines · Avi Kivity
Quoted 9 lines · Avi Kivity
Quoted 7 lines
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.
Checking that the bios is mapped at 0x[8e]0000000 + phys should filter out most non-Windows OSes.
Quoted 8 lines
Quoted 4 lines
Possibly.
What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there?
We don't. But things like the IDT/GTD/TSS and especially SelfPcr look like good candidates.
So fs.base should be SelfPcr? Will check.
Jan