Re: kvm's vapic
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 > 0x8xxx or 0xExxx. > > 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]000 + 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 signature.asc Description: OpenPGP digital signature
Re: kvm's vapic
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 > >>> 0x8xxx or 0xExxx. > >>> > >>> 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]000 + 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm's vapic
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 >>> 0x8xxx or 0xExxx. >>> >>> 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]000 + 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 signature.asc Description: OpenPGP digital signature
Re: kvm's vapic
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 > > 0x8xxx or 0xExxx. > > > > 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]000 + phys should filter out most non-Windows OSes. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm's vapic
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 > 0x8xxx or 0xExxx. > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
