From: Amit Shah <amit@kernel.org>
To: Halil Pasic <pasic@linux.ibm.com>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>
Cc: stable@vger.kernel.org,
Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Subject: Re: [PATCH 1/1] virtio_console: fix missing byte order handling for cols and rows
Date: Wed, 16 Apr 2025 15:49:40 +0200 [thread overview]
Message-ID: <4913ceb31b31feeec906636a1a64d46ea6c6e94e.camel@kernel.org> (raw)
In-Reply-To: <20250322002954.3129282-1-pasic@linux.ibm.com>
On Sat, 2025-03-22 at 01:29 +0100, Halil Pasic wrote:
> As per virtio spec the fields cols and rows are specified as little
> endian. Although there is no legacy interface requirement that would
> state that cols and rows need to be handled as native endian when
> legacy
> interface is used, unlike for the fields of the adjacent struct
> virtio_console_control, I decided to err on the side of caution based
> on some non-conclusive virtio spec repo archaeology and opt for using
> virtio16_to_cpu() much like for virtio_console_control.event.
> Strictly
> by the letter of the spec virtio_le_to_cpu() would have been
> sufficient.
> But when the legacy interface is not used, it boils down to the same.
>
> And when using the legacy interface, the device formatting these as
> little endian when the guest is big endian would surprise me more
> than
> it using guest native byte order (which would make it compatible with
> the current implementation). Nevertheless somebody trying to
> implement
> the spec following it to the letter could end up forcing little
> endian
> byte order when the legacy interface is in use. So IMHO this
> ultimately
> needs a judgement call by the maintainers.
The patch looks fine to me, but can you reword this message to say what
you chose and why (and not have the bit about judgment call by
maintainers in there)? If it sounds right, it'll be acked and merged.
If not, we'll work to ensure it's all good -- so the judgment calls
happen on the list, rather than mentioning this way in the commit.
Thanks,
Amit
next prev parent reply other threads:[~2025-04-16 13:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 0:29 Halil Pasic
2025-03-24 17:56 ` Maximilian Immanuel Brandtner
2025-04-02 15:26 ` Halil Pasic
2025-04-02 15:40 ` Michael S. Tsirkin
2025-04-16 13:49 ` Amit Shah [this message]
2025-04-22 10:39 ` 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=4913ceb31b31feeec906636a1a64d46ea6c6e94e.camel@kernel.org \
--to=amit@kernel.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxbr@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=virtualization@lists.linux.dev \
/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
all inboxes | Powered by JetHome®