A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top A: Yes Q: Should I trim all irrelevant context? On Thu, 27 Jun 2019, Xiaoyao Li wrote: > > Do you have any comments on this one as the policy of how to expose split lock > detection (emulate TEST_CTL) for guest changed. > > This patch makes the implementation as below: > > Host |Guest |Actual value in guest |split lock happen in guest > ------------------------------------------------------------------ > on |off | on |report #AC to userspace > |on | on |inject #AC back to guest > ------------------------------------------------------------------ > off |off | off |No #AC > |on | on |inject #AC back to guest A: Because it's way better to provide implementation details and useless references to the SDM. Q: What's the reason that this table is _NOT_ part of the changelog? > In case 2, when split lock detection of both host and guest on, if there is a > split lock is guest, it will inject #AC back to userspace. Then if #AC is from > guest userspace apps, guest kernel sends SIGBUS to userspace apps instead of > whole guest killed by host. If #AC is from guest kernel, guest kernel may > clear it's split lock bit in test_ctl msr and re-execute the instruction, then > it goes into case 1, the #AC will report to host userspace, e.g., QEMU. The real interesting question is whether the #AC on split lock prevents the actual bus lock or not. If it does then the above is fine. If not, then it would be trivial for a malicious guest to set the SPLIT_LOCK_ENABLE bit and "handle" the exception pro forma, return to the offending instruction and trigger another one. It lowers the rate, but that doesn't make it any better. The SDM is as usual too vague to be useful. Please clarify. Thanks, tglx
