On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote: > > > > Then can't we fix it by interrupting all CPUs right after LM? > > > > > > > > To me that seems like a cleaner approach - we then compartmentalize > > > > the ABI issue - kernel has its own ABI against userspace, > > > > devices have their own ABI against kernel. > > > > It'd mean we need a way to detect that interrupt was sent, > > > > maybe yet another counter inside that structure. > > > > > > > > WDYT? > > > > > > > > By the way the same idea would work for snapshots - > > > > some people wanted to expose that info to userspace, too. > > Those people included me. I wanted to interrupt all the vCPUs, even the > ones which were in userspace at the moment of migration, and have the > kernel deal with passing it on to userspace via a different ABI. > > It ends up being complex and intricate, and requiring a lot of new > kernel and userspace support. I gave up on it in the end for snapshots, > and didn't go there again for this.
ok I believe you, I am just curious how come you need userspace support - what I imagine would live completely in kernel ... > By contrast, a driver which merely exposes a page of MMIO space > identified by an ACPI device (without even the in-kernel PTP support) > could probably be fewer than a hundred lines of code. In an externally- > buildable module that goes back as far as RHEL8 or even further, > allowing users to just build and use it from their application. > > > was there supposed to be text here, or did you just like this > > so much you decided to repost my mail ;) > > Hm, weirdness. I've known Evolution get into a state where it sends > completely *empty* messages, but I've never seen it eat only my own > part before. I had definitely typed responses (along the lines of the > above) last time. mutt sucks less ;)
