[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241015081212.7641-A-hca@linux.ibm.com>
Date: Tue, 15 Oct 2024 10:12:12 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-s390@...r.kernel.org, virtualization@...ts.linux.dev,
linux-doc@...r.kernel.org, kvm@...r.kernel.org,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>, Thomas Huth <thuth@...hat.com>,
Cornelia Huck <cohuck@...hat.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Eugenio PĂ©rez <eperezma@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v2 2/7] Documentation: s390-diag.rst: make diag500 a
generic KVM hypercall
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.
Powered by blists - more mailing lists