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
