On Tue, 2023-01-10 at 15:10 +0100, Paolo Bonzini wrote: > On 1/10/23 13:55, David Woodhouse wrote: > > > However, I > > > completely forgot the sev_lock_vcpus_for_migration case, which is the > > > exception that... well, disproves the rule. > > > > > But because it's an exception and rarely happens in practice, lockdep > > didn't notice and keep me honest sooner? Can we take them in that order > > just for fun at startup, to make sure lockdep knows? > > Sure, why not. Out of curiosity, is this kind of "priming" a thing > elsewhere in the kernel? Dunno. Other people might know how to tell lockdep about it explicitly instead of purely empirically :) > > > Fortunately, it's pretty easy to introduce a new lock just for xen.c and > > > revert the docs patch. > > > > The wording of that made me hold off, on the expectation that if I did > > it myself, you'd probably beat me to it with a patch. But I don't see > > one yet. Shall I? > > No, I have already written it but didn't send it because I wanted to > test it on the real thing using your QEMU patches. :) But that was a > rabbit hole of its own, my Xen knowledge is somewhat outdated. The self-tests are much more likely to show it up than real usage, where all this stuff is fairly pedestrian. But that qemu branch should run fairly easily with any standard distro kernel and the command line I gave in e.g. https://lore.kernel.org/qemu-devel/20230110122042.1562155-1-dwmw2@xxxxxxxxxxxxx/ The trick is to pass it a SATA disk, because there's no "unplug" for those. And until we get the Xen PV disk back end working, you don't *want* to unplug the emulated one :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
