[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] DESIGN: CPUID part 3
>>> On 12.06.17 at 16:02, <andrew.cooper3@xxxxxxxxxx> wrote: > 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. Hmm, I don't see a problem converting formats 3..6 to formats 0 or 2. I also don't think any misbehavior can possibly result when converting 2 to 3 by simply always loading a fixed value into the mis-prediction bit. Whether 2 can be converted sensibly to 4..6 would need to be determined. Format 1 clearly is the odd one out, conversion to/from which would only be reasonable if we assumed flat addressing everywhere (which obviously we can assume as long as a guest stays in 64-bit mode). It is also clear that format 6 won't survive the addition of 5-level page tables, as there aren't enough bits to store a meaningful cycle count. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |