qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace f


From: Kang, Luwei
Subject: Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support
Date: Mon, 22 Jan 2018 10:36:29 +0000

> > On Thu, Jan 18, 2018 at 03:44:49PM +0100, Paolo Bonzini wrote:
> >> On 18/01/2018 15:37, Eduardo Habkost wrote:
> >>> On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
> >>>> On 18/01/2018 14:24, Eduardo Habkost wrote:
> >>>>> However, if there's a simple way to make it possible to migrate
> >>>>> between hosts with different CPUID[14h] data, it would be even
> >>>>> better.  With the current KVM intel-pt implementation, what
> >>>>> happens if the CPUID[14h] data seen by the guest doesn't match
> >>>>> exactly the CPUID[14h] leaves from the host?
> >>>>
> >>>> Some bits in there can be treated as CPU features (e.g. EBX bit 0
> >>>> "CR3 filtering support").  Probably we should handle these in KVM right 
> >>>> now.
> >>>> KVM needs to compute a mask of valid 1 bits for IA32_RTIT_CTL based
> >>>> on CPUID, and apply it when the MSR is written.
> >>>
> >>> Does this mean QEMU can't set CPUID values that won't match the host
> >>> with the existing implementation, or this won't matter for
> >>> well-behaved guests that don't try to set reserved bits on the MSRs?
> >>
> >> All the features could be handled exactly like regular feature bits.
> >> If QEMU sets them incorrectly and "enforce" is not used, bad things
> >> happen but it's the user's fault.
> >
> > Oh, I mean setting the bit to 0 when it's 1 on the host (if it's
> > 0 on the host, QEMU would never set it anyway).  Is it safe to do it
> > with the current KVM intel-pt implementation?
> 
> It's not, but it's (very) easy to fix.

Hi Paolo,
    Do you mean there need to add some check before setting IA32_RTIT_CTL MSR 
in KVM because some bits of this MSR is depend on the result of CPUID[14]. Any 
attempts to change these reserved bit should cause a #GP.

> >
> >>
> >>>
> >>>>                                               It also needs to
> >>>> whitelist bits like we do for other feature words.  These include:
> >>>>
> >>>> - CPUID[EAX=14h,ECX=0].EBX
> >>>>
> >>>> - CPUID[EAX=14h,ECX=0].ECX except bit 31
> >>>>
> >>>> - CPUID[EAX=14h,ECX=1].EAX bits 16:31 (if
> >>>> CPUID[EAX=14h,ECX=0].EBX[3]=1)
> >>>>
> >>>> - CPUID[EAX=14h,ECX=1].EBX (if CPUID[EAX=14h,ECX=0].EBX[1]=1)
> >>>
> >>> What do you mean by whitelist?
> >>
> >> KVM needs to tell QEMU the bits it knows about.

I think kvm_arch_get_supported_cpuid() function can get the result of CPUID[14] 
from KVM. Is this the whitelist what you mentioned?

Thanks,
Luwei Kang

> >
> > So KVM isn't currently doing it on GET_SUPPORTED_CPUID?  Oops.
> >
> >
> >>
> >>>> Others, currently only CPUID[EAX=14h,ECX=0].ECX[31] must match,
> >>>> there is no way to emulate the "wrong" value.
> >>>
> >>> In this case we could make it configurable but require the host and
> >>> guest value to always match.
> >>>
> >>> This might be an obstacle to enabling intel-pt by default (because
> >>> it could make VMs not migratable to newer hosts), but may allow the
> >>> feature to be configured in a predictable way.
> >>
> >> Yeah, but consider that virtualized PT anyway would only be enabled
> >> on Ice Lake processors.  It's a few years away anyway!
> >>
> >>>> Others, currently only CPUID[EAX=14h,ECX=1].EAX[2:0] are numeric
> >>>> values, and it's possible to emulate a lower value than the one in the 
> >>>> processor.
> >>>
> >>> This could be handled by QEMU.  There's no requirement that all
> >>> GET_SUPPORTED_CPUID values should be validated by simple bit
> >>> masking.
> >>
> >> Good!
> >>
> >> Paolo
> >


reply via email to

[Prev in Thread] Current Thread [Next in Thread]