From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>, Thomas Huth <thuth@redhat.com>
Cc: qemu-s390x@nongnu.org,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Eric Farman" <farman@linux.ibm.com>,
"Matthew Rosato" <mjrosato@linux.ibm.com>,
qemu-devel@nongnu.org, "David Hildenbrand" <david@redhat.com>,
"Cédric Le Goater" <clg@kaod.org>,
"Halil Pasic" <pasic@linux.ibm.com>
Subject: Re: [PATCH v2] hw/s390x: Fix a possible crash with passed-through virtio devices
Date: Tue, 18 Nov 2025 15:53:55 +0100 [thread overview]
Message-ID: <87ecpvqtmk.fsf@redhat.com> (raw)
In-Reply-To: <20251118152411.37a06f7a.pasic@linux.ibm.com>
On Tue, Nov 18 2025, Halil Pasic <pasic@linux.ibm.com> wrote:
> Hm, the -EINVAL is put into GPR2 which is 'Host Cookie' according to the
> virtio specification:
> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-2260002
>
> Unfortunately, I did not find any words in the spec according to which
> GPR2 can be used to indicate errors. There does seem to be handling in
> the linux driver for that. It basically says negative is bad, but I can't
> see that in the spec. It just says "For each notification, the driver
> SHOULD use GPR4 to pass the host cookie received in GPR2 from the previous
> notification."
>
> Maybe we want to update the spec to reflect what is in the filed.
Saying that the driver SHOULD check GPR2 for negative error values is
probably fine, since it matches what is already out
there. (Unfortunately, we can't mandate it without either a new feature
bit or a new revision, and that would be overkill IMHO.)
For the device, we say "The device MAY return a 64-bit host cookie in
GPR2 to speed up the notification execution." -- the spec should
probably also say that the device MAY return a negative error code.
next prev parent reply other threads:[~2025-11-18 14:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 9:39 [PATCH v2] hw/s390x: Fix a possible crash with passed-through virtio devices Thomas Huth
2025-11-18 11:52 ` Cornelia Huck
2025-11-18 12:09 ` Thomas Huth
2025-11-18 12:15 ` Cornelia Huck
2025-11-18 12:02 ` Halil Pasic
2025-11-18 12:28 ` Thomas Huth
2025-11-18 14:24 ` Halil Pasic
2025-11-18 14:53 ` Cornelia Huck [this message]
2025-11-18 14:25 ` Cornelia Huck
2025-11-18 14:48 ` Thomas Huth
2025-11-18 15:19 ` Eric Farman
2025-11-18 22:56 ` Halil Pasic
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=87ecpvqtmk.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clg@kaod.org \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.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).