[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: sched=null vwfi=native and call_rcu()
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 <sstabellini@xxxxxxxxxx> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |