Re: kvm's vapic

[Avi Kivity <avi@redhat.com>]

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