Re: [PATCH v4 1/2] i386: Add Intel Processor Trace feature support

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Mar 12, 2018 at 09:07:41AM +0000, Kang, Luwei wrote:
> > > +
> > > +        if (!eax_0 ||
> > > +           ((ebx_0 & INTEL_PT_MINIMAL_EBX) != INTEL_PT_MINIMAL_EBX) ||
> > > +           ((ecx_0 & INTEL_PT_MINIMAL_ECX) != INTEL_PT_MINIMAL_ECX) ||
> > > +           ((eax_1 & INTEL_PT_MTC_BITMAP) != INTEL_PT_MTC_BITMAP) ||
> > > +           ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> > > +                                           INTEL_PT_ADDR_RANGES_NUM) ||
> > > +           ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> > > +                (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
> > 
> > I still don't see a check to ensure the host has bit 31 on ecx_0 set to 0, as I mentioned when reviewing v3.
> 
> Hi Eduardo,
>     Thanks for the code review. I don't quite understand here why bit31 must same with host (meaning we must reject a host
> where ecx_0 & (1 << 31) is set).

If the guest sees the bit set to 0, it will expect IP payloads
with RIP values, but the host CPU will generate IP payloads with
LIP values.  I assume KVM won't do RIP<->LIP translation on the
packets generated by the host before the guest sees them, will
it?


>     Do you mean PT must be disabled in guest when host bit31 is set? 
>     Bit 31: If 1, generated packets which contain IP payloads have LIP values, which include the CS base component.
>     I can't find any special on this bit. Could you help clarify?

As far as I understand, this bit is special because KVM can't
emulate a value that's different from the host.

-- 
Eduardo