On 16/10/19 13:49, Thomas Gleixner wrote: > On Wed, 16 Oct 2019, Paolo Bonzini wrote: >> Yes it does. But Sean's proposal, as I understand it, leads to the >> guest receiving #AC when it wasn't expecting one. So for an old guest, >> as soon as the guest kernel happens to do a split lock, it gets an >> unexpected #AC and crashes and burns. And then, after much googling and >> gnashing of teeth, people proceed to disable split lock detection. > > I don't think that this was what he suggested/intended. Xiaoyao's reply suggests that he also understood it like that. >> In all of these cases, the common final result is that split-lock >> detection is disabled on the host. So might as well go with the >> simplest one and not pretend to virtualize something that (without core >> scheduling) is obviously not virtualizable. > > You are completely ignoring any argument here and just leave it behind your > signature (instead of trimming your reply). I am not ignoring them, I think there is no doubt that this is the intended behavior. I disagree that Sean's patches achieve it, however. >>> 1) Sane guest >>> >>> Guest kernel has #AC handler and you basically prevent it from >>> detecting malicious user space and killing it. You also prevent #AC >>> detection in the guest kernel which limits debugability. > > That's a perfectly fine situation. Host has #AC enabled and exposes the > availability of #AC to the guest. Guest kernel has a proper handler and > does the right thing. So the host _CAN_ forward #AC to the guest and let it > deal with it. For that to work you need to expose the MSR so you know the > guest state in the host. > > Your lazy 'solution' just renders #AC completely useless even for > debugging. > >>> 2) Malicious guest >>> >>> Trigger #AC to disable the host detection and then carry out the DoS >>> attack. > > With your proposal you render #AC useless even on hosts which have SMT > disabled, which is just wrong. There are enough good reasons to disable > SMT. My lazy "solution" only applies to SMT enabled. When SMT is either not supported, or disabled as in "nosmt=force", we can virtualize it like the posted patches have done so far. > I agree that with SMT enabled the situation is truly bad, but we surely can > be smarter than just disabling it globally unconditionally and forever. > > Plus we want a knob which treats guests triggering #AC in the same way as > we treat user space, i.e. kill them with SIGBUS. Yes, that's a valid alternative. But if SMT is possible, I think the only sane possibilities are global disable and SIGBUS. SIGBUS (or better, a new KVM_RUN exit code) can be acceptable for debugging guests too. Paolo
