Re: [Xen-devel] DESIGN: CPUID part 3

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/06/17 14:42, Jan Beulich wrote:
>>>> On 12.06.17 at 15:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 12/06/17 14:29, Jan Beulich wrote:
>>>>>> On 12.06.17 at 15:07, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 08/06/17 14:47, Jan Beulich wrote:
>>>>>>>> On 08.06.17 at 15:12, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> The `disable_migrate` field shall be dropped.  The concept of 
>>>>>> migrateability
>>>>>> is not boolean; it is a large spectrum, all of which needs to be managed 
>>>>>> by
>>>>>> the toolstack.  The simple case is picking the common subset of features
>>>>>> between the source and destination.  This becomes more complicated e.g. 
>>>>>> if 
>> the
>>>>>> guest uses LBR/LER, at which point the toolstack needs to consider 
>>>>>> hardware
>>>>>> with the same LBR/LER format in addition to just the plain features.
>>>>> Not sure about this - by intercepting the MSR accesses to the involved
>>>>> MSRs, it would be possible to mimic the LBR/LER format expected by
>>>>> the guest even if different from that of the host.
>>>> LER yes, but how would you emulate LBR?
>>>>
>>>> You could set DBG_CTL.BTF/EFLAGS.TF and intercept #DB, but this would be
>>>> visible to the guest via pushf/popf.  It would also interfere with a
>>>> guest trying to single-step itself.
>>> I don't understand: LBR is an MSR just like LER, and hence the
>>> guest can't avoid using RDMSR to read its contents. If we
>>> intercept that read, we can give them whatever format is
>>> needed, without a need to intercept anything else. But maybe
>>> I'm not seeing what you're getting at.
>> To emulate it, we need to sample state at the point that the last
>> exception or branch happened.
>>
>> You can't reverse the current value in hardware at the point of the
>> guest reading the LBR MSR to the value it should have been under a
>> different format.
> Aren't we talking about correct (or at least unproblematic) top
> bits of the value only? In which case the actual address bits
> can be taken as is, and only the top bits need adjustment.

I'm completely confused.

My original statement was "if the guest uses LBR/LER, then migration
needs to be restricted to hardware with an identical LBR format".

You countered that, saying we could emulate LBR/LER as an alternative. 
The implication here is that we could alter the LBR format via
emulation, by cooking the value observed when the guest reads the LBR MSRs.

For the record, the formats are:

Software should query an architectural MSR IA32_PERF_CAPABILITIES[5:0]
about the format of the address that is stored in the LBR stack. Four
formats are defined by the following encoding:
* 000000B (32-bit record format) — Stores 32-bit offset in current CS of
respective source/destination,
* 000001B (64-bit LIP record format) — Stores 64-bit linear address of
respective source/destination,
* 000010B (64-bit EIP record format) — Stores 64-bit offset (effective
address) of respective source/destination.
* 000011B (64-bit EIP record format) and Flags — Stores 64-bit offset
(effective address) of respective source/destination. Misprediction info
is reported in the upper bit of 'FROM' registers in the LBR stack. See
LBR stack details below for flag support and definition.
* 000100B (64-bit EIP record format), Flags and TSX — Stores 64-bit
offset (effective address) of respective source/destination.
Misprediction and TSX info are reported in the upper bits of ‘FROM’
registers in the LBR stack.
* 000101B (64-bit EIP record format), Flags, TSX, LBR_INFO — Stores
64-bit offset (effective address) of respective source/destination.
Misprediction, TSX, and elapsed cycles since the last LBR update are
reported in the LBR_INFO MSR stack.
* 000110B (64-bit EIP record format), Flags, Cycles — Stores 64-bit
linear address (CS.Base + effective address) of respective
source/destination. Misprediction info is reported in the upper bits of
17-16 Vol. 3BDEBUG, BRANCH PROFILE, TSC, AND RESOURCE MONITORING
FEATURES 'FROM' registers in the LBR stack. Elapsed cycles since the
last LBR update are reported in the upper 16 bits of the 'TO' registers
in the LBR stack (see Section 17.6).

In general, I don't see any sensible way of being able to convert
between these formats at the point of an RDMSR.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel