I see this series has been committed. But it's broken in a really fundamental way.
This is a new extension with persistent side effects to an existing part of the guest ABI. Yet there doesn't appear to be any enumeration that the interface is available to begin with. Requiring the guest to probe subops, and having no way to disable it on a per-domain basis is unacceptable, and has exploded on us more times than I care to count in security fixes alone, and that doesn't even cover the issues Amazon have reported over the years. 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? This is engineering principles so basic that they do go without saying. ~Andrew
