On 15.10.24 10:12, Heiko Carstens wrote:
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.
Okay, I see your point: it would allow for removing the program check
handling from the STORAGE LIMIT invocation.
... if only we wouldn't need the exact same program check handling for
the new query subfunction :P
--
Cheers,
David / dhildenb
