* kvm's vapic
@ 2012-01-29 15:37 Jan Kiszka
2012-01-29 15:51 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2012-01-29 15:37 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti, Gleb Natapov; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kvm's vapic
2012-01-29 15:37 kvm's vapic Jan Kiszka
@ 2012-01-29 15:51 ` Avi Kivity
2012-01-29 15:52 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Avi Kivity @ 2012-01-29 15:51 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, Gleb Natapov, kvm
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kvm's vapic
2012-01-29 15:51 ` Avi Kivity
@ 2012-01-29 15:52 ` Avi Kivity
2012-01-29 15:55 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Avi Kivity @ 2012-01-29 15:52 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, Gleb Natapov, kvm
On 01/29/2012 05:51 PM, Avi Kivity wrote:
> > 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.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kvm's vapic
2012-01-29 15:52 ` Avi Kivity
@ 2012-01-29 15:55 ` Jan Kiszka
2012-01-29 16:27 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2012-01-29 15:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, Gleb Natapov, kvm
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
On 2012-01-29 16:52, Avi Kivity wrote:
> On 01/29/2012 05:51 PM, Avi Kivity wrote:
>>> 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.
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kvm's vapic
2012-01-29 15:55 ` Jan Kiszka
@ 2012-01-29 16:27 ` Avi Kivity
2012-01-29 16:31 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Avi Kivity @ 2012-01-29 16:27 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, Gleb Natapov, kvm
On 01/29/2012 05:55 PM, Jan Kiszka wrote:
> On 2012-01-29 16:52, Avi Kivity wrote:
> > On 01/29/2012 05:51 PM, Avi Kivity wrote:
> >>> 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.
>
> 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.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kvm's vapic
2012-01-29 16:27 ` Avi Kivity
@ 2012-01-29 16:31 ` Jan Kiszka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2012-01-29 16:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, Gleb Natapov, kvm
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
On 2012-01-29 17:27, Avi Kivity wrote:
> On 01/29/2012 05:55 PM, Jan Kiszka wrote:
>> On 2012-01-29 16:52, Avi Kivity wrote:
>>> On 01/29/2012 05:51 PM, Avi Kivity wrote:
>>>>> 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.
>>
>> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-29 16:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-29 15:37 kvm's vapic Jan Kiszka
2012-01-29 15:51 ` Avi Kivity
2012-01-29 15:52 ` Avi Kivity
2012-01-29 15:55 ` Jan Kiszka
2012-01-29 16:27 ` Avi Kivity
2012-01-29 16:31 ` Jan Kiszka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox