On Wed, 16 Oct 2019, Xiaoyao Li wrote: > On 10/16/2019 7:58 PM, Paolo Bonzini wrote: > > > 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. > > > > Do we really need to divide it into two cases of SMT enabled and SMT disabled? Yes. See the matrix I just sent. > > > 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. > > If SIGBUS, why need to globally disable? See the matrix I just sent. > When there is an #AC due to split-lock in guest, KVM only has below two > choices: > 1) inject back into guest. > - If kvm advertise this feature to guest, and guest kernel is latest, and > guest kernel must enable it too. It's the happy case that guest can handler it > on its own purpose. > - Any other cases, guest get an unexpected #AC and crash. That's just wrong for obvious reasons. > 2) report to userspace (I think the same like a SIGBUS) No. What guarantees that userspace qemu handles the SIGBUS sanely? > So for simplicity, we can do what Paolo suggested that don't advertise this > feature and report #AC to userspace when an #AC due to split-lock in guest > *but* we never disable the host's split-lock detection due to guest's > split-lock. No, you can't. Guess what happens when you just boot some existing guest on a #AC enabled host without having updated qemu to handle the exit code/SIGBUS. It simply will crash and burn in nonsensical ways. Same as reinjecting it into the guest and letting it crash. Thanks, tglx