On Mon, Oct 14, 2024 at 09:35:27PM +0200, David Hildenbrand wrote: > On 14.10.24 20:04, Heiko Carstens wrote: > > On Mon, Oct 14, 2024 at 04:46:14PM +0200, David Hildenbrand wrote: > > If so, it would be nice to document that too; but that is not > > necessarily your problem. > > I can squash: > > diff --git a/Documentation/virt/kvm/s390/s390-diag.rst b/Documentation/virt/kvm/s390/s390-diag.rst > index d9b7c6cbc99e..48a326d41cc0 100644 > --- a/Documentation/virt/kvm/s390/s390-diag.rst > +++ b/Documentation/virt/kvm/s390/s390-diag.rst > @@ -50,6 +50,9 @@ Upon completion of the DIAGNOSE instruction, general register 2 contains > the function's return code, which is either a return code or a subcode > specific value. > +If the specified subfunction is not supported, a SPECIFICATION exception > +will be triggered. > + Looks good. Thanks! > > I guess we won't see too many new diag 500 subcodes, or would it make > > sense to implement some query subcode? > > In the context of STORAGE LIMIT, a "query" subfunction is not really beneficial: > > it's either one invocation of "query", conditionally followed by one invocation of "STORAGE LIMIT" > vs. one invocation of "STORAGE LIMIT". > > Once there might be a bunch of other subfunctions, a "query" might make more sense. "If only there would be a query subcode available, so that the program check handling would not be necessary; but in particular my new subcode is not worth adding it" :) Anyway, I do not care too much.
