Hi,
On 17/01/2022 15:13, Juergen Gross wrote:
On 17.01.22 12:05, George Dunlap wrote:
On Jan 14, 2022, at 9:01 PM, Stefano Stabellini
<sstabell...@kernel.org> wrote:
On Fri, 14 Jan 2022, Dario Faggioli wrote:
On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
On Thu, 6 Jan 2022, Julien Grall wrote:
Alternatively, we can submit the series as ARM-only... But I fear that
the x86 side of things would then be easily forgotten. :-(
I agree with you on this, but at the same time we are having problems
with customers in the field -- it is not like we can wait to solve the
problem on ARM any longer. And the issue is certainly far less likely to
happen on x86 (there is no vwfi=native, right?) In other words, I think
it is better to have half of the solution now to solve the worst part of
the problem than to wait more months for a full solution.
Well, it all depends on how your guest OS works A "malicious" guest that
will configure the vCPU to busy loop without wfi will result to the same
problem (this is one of the reason why NULL scheduler is not security
supported).
An x86 equivalent of vwfi=native could be implemented easily, but
AFAIK nobody has asked for it yet. I agree that we need to fix if for
ARM, and so in the absence of someone with the time to fix up the x86
side, I think fixing ARM-only is the way to go.
It would be good if we could add appropriate comments warning anyone
who implements `hlt=native` on x86 the problems they’ll face and how
to fix them. Not sure the best place to do that; in the VMX / SVM
code that sets the exit for HLT &c?
But wouldn't a guest in a busy loop on x86 with NULL scheduler suffer
from the same problem?
This is not a problem on x86 because there will always an exit to the
hypervisor a timed interval (IIRC for some rendezvous?). On Arm, using
the NULL scheduler will result to a completely tickless hypervisor.
Cheers,
--
Julien Grall