On 06/01/2020 16:37, Jan Beulich wrote: > While the PM doesn't say so, this assumes that the MPERF value read this > way gets scaled similarly to its reading through RDMSR. > > Also introduce the SVM related constants at this occasion. > > Signed-off-by: Jan Beulich <[email protected]> > --- > RFC: Andrew promised to take care of the CPUID side of this; will need > re-basing over his work once available. > TBD: There are indications that the CPUID field used may be just 8 bits > wide.
Getting there. The movement of CPU_POLICY into the migrate stream is a substantial step in the right direction. I've got half a mind to use RDPRU as the first real "need to opt-in" feature, seeing as there currently isn't an answer for how APERF/MPERF is virtualisation-safe in the first place, and how exposing it in userspace is any better. Perhaps better would be to make APERF/MPERF opt-in to begin with (so it starts ceasing to exist for VMs by default, but in a backwards compatible way), and then derive RDPRU as dependent on APERF/MPERF. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
