On 12/06/17 14:29, Jan Beulich wrote: >>>> On 12.06.17 at 15:07, <andrew.coop...@citrix.com> wrote: >> On 08/06/17 14:47, Jan Beulich wrote: >>>>>> On 08.06.17 at 15:12, <andrew.coop...@citrix.com> 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
