On 06/10/2023 9:00 am, Roger Pau Monné wrote: > On Thu, Oct 05, 2023 at 07:58:50PM +0100, Andrew Cooper wrote: >> Henry: Blocker for 4.18. The absolutely bare minimum necessary to >> avoid reversion is some kind of positive enumeration that the two new >> hypercalls are available. >> >> Otherwise I will be #if 0'ing out the new hypercalls before this ABI >> mistake gets set in stone. >> >> >> If this were x86-only it would need to be a CPUID flag, but it will need >> to be something arch-agnostic in this case. The series should not have >> come without a proper per-domain control and toolstack integration, but >> everything else can be retrofitted in an emergency. >> >> And on a related note, where is the documentation describing this new >> feature? Some tests perhaps, or any single implementation of the guest >> side interface? > Not that I know, I was expecting Jan to post that once he gets back > from PTO. > > I already noted somewhere that I wasn't able to test myself because I > couldn't find any Linux side patches to test the feature with, and I > didn't have time to write ones myself (was expecting Jan to have the > Linux side done already for testing reasons).
Big new feature, getting merged after RC1 and feature freeze, with no enumeration and no disable. How did this not set off massive alarm bells? I was about to say that this is a disaster waiting to happen, except OSSTest has beaten me to it. This "new feature" managed to regress existing behaviour of something it was trying not to change, and that's in an area that even I wouldn't expect to put in a disable. I'm very sorely tempted to insist that this gets disabled by default in 4.18. It's clear that it isn't in a fit state, and the absence of any testing whatsoever means it is likely to explode on the first guest kernel which tries to use the new interface. And to be clear, disabled-by-default is a question for Henry and Henry alone, as the person ultimately responsible for 4.18. ~Andrew
