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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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