On 05.10.2023 20:58, Andrew Cooper wrote: > 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.
This has never been a requirement. Plus you had ample time to raise such a request. > 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. I disagree; to me this is a nice-to-have, not a requirement. > 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. To be honest, had it been clear that you expect a per-domain control, I probably would not have taken on this piece of work. > 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? Documentation is as for sibling interfaces - as much or as little as we have in the public headers. I did test all of this with XTF, but I've pretty much given up posting XTF patches, seeing how even XSA tests and alike never made it anywhere. Jan
