Re: [PATCH] KVM: VMX: CPU frequency scaling for intel x86_64 KVM guests

[David Woodhouse]

On Tue, 2022-05-31 at 20:11 +0200, Paolo Bonzini wrote:
> On 5/31/22 13:43, Metin Kaya wrote:
> > Thanks, Jack.
> > 
> > Reviewed-by: Metin Kaya <metikaya@xxxxxxxxxxxx>
> > 
> 
> Please try a bit harder.  "Reviewed-by" is neither "this matches what's 
> been forever in the Amazon kernel" 

Oh, it hasn't made it to the Amazon kernel yet. I have started
threatening to *eat* people who even submit stuff to the internal
kernel for review without first posting it upstream.

That does mean you get to see it sooner, which is a mixed blessing :)

> - does not even *apply* to the upstream kernel, because it uses 
> (presumably Amazon-specific) CAP numbers above 10000
> 
> - does not work if the vCPU is moved from one physical CPU to another
> 
> - does not work if the intel_pstate driver writes to MSR_HWP_REQUEST
> 
> - does not include documentation for the new capability
> 
> - does not include a selftest
> 
> - is unacceptable anyway because, as mentioned in the cover letter, it 
> isn't undone when the process exits

That's a useful summary; thank you. I think we should definitely focus
on integrating with cpufreq too.

Is this even a KVM thing?

I don't think we really want to do the change on every vmexit/enter. We
could *maybe* make a case for doing it on entry and then removing the
limit when either returning to *userspace* or scheduling?

But I think even that probably isn't needed. Just let the VMM run at
the same frequency too, as a per-process setting.

> Jack, please understand that I am not really blaming you in any way, and 
> ask some of your colleagues with upstream kernel experience (Alex Graf, 
> David Woodhouse, Filippo Sironi, Jan Schoenherr, Amit Shah are the ones 
> I know) which patches could be good targets for including upstream.

Indeed. As a straw man there are worse ways to start the discussion.
Thanks, Jack.

Attachment: smime.p7s
Description: S/MIME cryptographic signature