On 08.05.2020 23:04, Andrew Cooper wrote: > On 05/05/2020 09:20, Jan Beulich wrote: >> If the hardware can handle accesses, we should allow it to do so. This >> way we can expose EFRO to HVM guests, > > I'm reminded now of the conversation I'm sure we've had before, although > I have a feeling it was on IRC. > > APERF/MPERF (including the EFRO interface on AMD) are free running > counters but only in C0. The raw values are not synchronised across > threads. > > A vCPU which gets rescheduled has a 50% chance of finding the one or > both values going backwards, and a 100% chance of totally bogus calculation. > > There is no point exposing APERF/MPERF to guests. It can only be used > safely in hypervisor context, on AMD hardware with a CLGI/STGI region, > or on Intel hardware in an NMI handler if you trust that a machine check > isn't going to ruin your day. > > VMs have no way of achieving the sampling requirements, and has a fair > chance of getting a plausible-but-wrong answer. > > The only possibility to do this safely is on a VM which is pinned to > pCPU for its lifetime, but even I'm unconvinced of the correctness. > > I don't think we should be exposing this functionality to guests at all, > although I might be persuaded if someone wanting to use it in a VM can > provide a concrete justification of why the above problems won't get in > their way.
Am I getting it right then that here you're reverting what you've said on patch 10: "I'm tempted to suggest that we offer EFRO on Intel ..."? And hence your request is to drop both that and this patch? Jan
