From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>, Thomas Huth <thuth@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
qemu-devel@nongnu.org, Eric Farman <farman@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
qemu-s390x@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Ilya Leoshkevich <iii@linux.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>
Subject: Re: [PATCH v1 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT
Date: Mon, 30 Sep 2024 13:11:31 +0200 [thread overview]
Message-ID: <10165d22-c3e8-4db1-9874-8b63ca59afe9@linux.ibm.com> (raw)
In-Reply-To: <20240927200525.5a90f172.pasic@linux.ibm.com>
Am 27.09.24 um 20:05 schrieb Halil Pasic:
> On Thu, 12 Sep 2024 10:19:00 +0200
> Thomas Huth <thuth@redhat.com> wrote:
>
>>> diff --git a/hw/s390x/s390-hypercall.h b/hw/s390x/s390-hypercall.h
>>> index b7ac29f444..f0ca62bcbb 100644
>>> --- a/hw/s390x/s390-hypercall.h
>>> +++ b/hw/s390x/s390-hypercall.h
>>> @@ -18,6 +18,7 @@
>>> #define DIAG500_VIRTIO_RESET 1 /* legacy */
>>> #define DIAG500_VIRTIO_SET_STATUS 2 /* legacy */
>>> #define DIAG500_VIRTIO_CCW_NOTIFY 3 /* KVM_S390_VIRTIO_CCW_NOTIFY */
>>> +#define DIAG500_STORAGE_LIMIT 4
>>>
>>> int handle_diag_500(CPUS390XState *env);
>>
>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>>
>> Sounds very reasonable to me - but it would be good to get an
>> Ack/Reviewed-by from IBM folks here (in case they prefer a different
>> interface)... hope they'll join the discussion!
>>
>> Thomas
>
> According to Documentation/virt/kvm/s390/s390-diag.rst in the
> linux source tree DIAG 500 is for kvm virtio funcions.
>
> Based on the commit message this storagelimit DIAG is rather loosely
> tied to virtio if at all, so from that perspective DIAG may not be a
> perfect fit. OTOH I don't see a better fit either. I would prefer to
> have Christian's opinion on this. I have no strong opinion myself.
Some remarks:
500 with a new subcode would work, it is marked as KVM hypervisor call
in our docs. 501 was used in the past for software breakpoints.
So we could use 502 as the next free one (This is reserved for KVM).
We do have kvm_stat counters for 500, not sure if people debugging virtio
will care.
The only important question for me is, what code is generated by gcc for
the switch statement and will any variant slow down the virtio doorbell.
diag.c has
if (!vcpu->kvm->arch.css_support ||
(vcpu->run->s.regs.gprs[1] != KVM_S390_VIRTIO_CCW_NOTIFY))
return -EOPNOTSUPP;
So 500+4 should probably not cause any harm apart from branch prediction
going wrong the first 2 or 3 notifies.
502 will make kvm_s390_handle_diag larger.
So I tend to go with 500+4.
next prev parent reply other threads:[~2024-09-30 11:12 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 17:57 [PATCH v1 00/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 01/14] s390x/s390-virtio-ccw: don't crash on weird RAM sizes David Hildenbrand
2024-09-11 11:28 ` Janosch Frank
2024-09-11 12:38 ` David Hildenbrand
2024-09-11 12:46 ` Thomas Huth
2024-09-11 12:54 ` David Hildenbrand
2024-09-11 11:58 ` Thomas Huth
2024-09-12 20:28 ` Eric Farman
2024-09-23 9:19 ` David Hildenbrand
2024-09-23 15:36 ` Thomas Huth
2024-09-23 15:39 ` David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 02/14] s390x/s390-virtio-hcall: remove hypercall registration mechanism David Hildenbrand
2024-09-11 16:02 ` Thomas Huth
2024-09-10 17:57 ` [PATCH v1 03/14] s390x/s390-virtio-hcall: prepare for more diag500 hypercalls David Hildenbrand
2024-09-11 17:04 ` Thomas Huth
2024-09-12 13:22 ` Nina Schoetterl-Glausch
2024-09-17 10:45 ` David Hildenbrand
2024-09-17 10:50 ` David Hildenbrand
2024-09-17 11:02 ` David Hildenbrand
2024-09-17 12:59 ` Nina Schoetterl-Glausch
2024-09-10 17:57 ` [PATCH v1 04/14] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2024-09-11 17:05 ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 05/14] s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to machine code David Hildenbrand
2024-09-12 8:07 ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 06/14] s390x: introduce s390_get_memory_limit() David Hildenbrand
2024-09-12 8:10 ` Thomas Huth
2024-09-16 13:20 ` Nina Schoetterl-Glausch
2024-09-17 11:23 ` David Hildenbrand
2024-09-17 12:48 ` Nina Schoetterl-Glausch
2024-09-23 9:20 ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT David Hildenbrand
2024-09-12 8:19 ` Thomas Huth
2024-09-12 10:54 ` Janosch Frank
2024-09-27 18:05 ` Halil Pasic
2024-09-27 18:34 ` David Hildenbrand
2024-09-30 11:11 ` Christian Borntraeger [this message]
2024-09-30 12:57 ` Halil Pasic
2024-10-01 9:15 ` Christian Borntraeger
2024-10-01 13:31 ` Halil Pasic
2024-10-01 14:35 ` Christian Borntraeger
2024-09-30 13:13 ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 08/14] s390x/s390-stattrib-kvm: prepare memory devices and sparse memory layouts David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 09/14] s390x/s390-skeys: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 10/14] s390x/pv: check initial, not maximum RAM size David Hildenbrand
2024-09-24 16:22 ` Nina Schoetterl-Glausch
2024-09-24 20:17 ` David Hildenbrand
2024-09-26 9:04 ` David Hildenbrand
2024-09-30 11:15 ` Christian Borntraeger
2024-09-30 11:37 ` Claudio Imbrenda
2024-09-30 13:14 ` David Hildenbrand
2024-09-30 13:26 ` Claudio Imbrenda
2024-09-10 17:58 ` [PATCH v1 11/14] s390x/s390-virtio-ccw: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 12/14] s390x: introduce s390_get_max_pagesize() David Hildenbrand
2024-09-26 10:22 ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 13/14] s390x/virtio-ccw: add support for virtio based memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 14/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 18:33 ` [PATCH v1 00/14] " Michael S. Tsirkin
2024-09-10 18:45 ` David Hildenbrand
2024-09-11 11:49 ` Janosch Frank
2024-09-11 12:28 ` David Hildenbrand
2024-09-11 14:04 ` Michael S. Tsirkin
2024-09-11 15:38 ` Cornelia Huck
2024-09-11 19:09 ` David Hildenbrand
2024-09-27 18:20 ` Halil Pasic
2024-09-27 18:29 ` David Hildenbrand
2024-09-30 21:49 ` Halil Pasic
2024-10-01 8:54 ` David Hildenbrand
2024-10-02 9:04 ` Janosch Frank
2024-10-07 12:23 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10165d22-c3e8-4db1-9874-8b63ca59afe9@linux.ibm.com \
--to=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).