From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"Paolo Abeni" <pabeni@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Jonathan Corbet" <corbet@lwn.net>,
kvm@vger.kernel.org, virtualization@lists.linux.dev,
linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/3] virtio: dwords->qwords
Date: Sun, 12 Oct 2025 15:17:50 -0400 [thread overview]
Message-ID: <20251012151345-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <36501d9c-9db9-45e6-9a77-1efd530545ee@lunn.ch>
On Sun, Oct 12, 2025 at 04:39:06PM +0200, Andrew Lunn wrote:
> > > DeviceFeaturesSel 0x014
> > >
> > > Device (host) features word selection.
> > > Writing to this register selects a set of 32 device feature bits accessible by reading from DeviceFeatures.
> > >
> > > and
> > >
> > > DriverFeaturesSel 0x024
> > >
> > > Activated (guest) features word selection
> > > Writing to this register selects a set of 32 activated feature bits accessible by writing to DriverFeatures.
> > >
> > > I would interpret this as meaning a feature word is a u32. Hence a
> > > DWORD is a u64, as the current code uses.
> > >
> > > Andrew
> >
> >
> > Hmm indeed.
> > At the same time, pci transport has:
> >
> > u8 padding[2]; /* Pad to full dword. */
> >
> > and i2c has:
> >
> > The \field{padding} is used to pad to full dword.
> >
> > both of which use dword to mean 32 bit.
> >
> > This comes from PCI which also does not define word but uses it
> > to mean 16 bit.
>
> Yes, reading the spec, you need to consider the context 'word' is used
> in. Maybe this is something which can be cleaned up, made uniform
> across the whole document?
Yes and thanks for bringing this to my attention.
So MMIO can be "features set selection"
And pci can be "pad to 32 bit".
Less work than defining "word".
> > I don't have the problem changing everything to some other
> > wording completely but "chunk" is uninformative, and
> > more importantly does not give a clean way to refer to
> > 2 chunks and 4 chunks.
> > Similarly, if we use "word" to mean 32 bit there is n clean
> > way to refer to 16 bits which we use a lot.
> >
> >
> > using word as 16 bit has the advantage that you
> > can say byte/word/dword/qword and these do not
> > cause too much confusion.
>
> > So I am still inclined to align everything on pci terminology
> > but interested to hear what alternative you suggest.
>
> How about something simple:
>
> #define VIRTIO_FEATURES_DU32WORDS 2
> #define VIRTIO_FEATURES_U32WORDS (VIRTIO_FEATURES_D32WORDS * 2)
>
> or, if the spec moves away from using 'word':
>
> #define VIRTIO_FEATURES_U64S 2
> #define VIRTIO_FEATURES_U32S (VIRTIO_FEATURES_U32S * 2)
>
> The coding style says not to use Hungarian notation, but here it
> actually make sense, and avoids the ambiguity in the spec.
>
> Andrew
I mean we can just define number of bits. Open-code / 32 or / 64
as needed. Hmm?
--
MST
next prev parent reply other threads:[~2025-10-12 19:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 11:24 [PATCH 0/3] feature related cleanups Michael S. Tsirkin
2025-10-09 11:24 ` [PATCH 1/3] virtio: dwords->qwords Michael S. Tsirkin
2025-10-09 12:31 ` Andrew Lunn
2025-10-09 13:37 ` Michael S. Tsirkin
2025-10-11 17:25 ` Andrew Lunn
2025-10-11 17:42 ` Michael S. Tsirkin
2025-10-11 18:52 ` Andrew Lunn
2025-10-12 7:26 ` Michael S. Tsirkin
2025-10-12 14:39 ` Andrew Lunn
2025-10-12 19:17 ` Michael S. Tsirkin [this message]
2025-10-09 11:24 ` [PATCH 2/3] virtio: words->dwords Michael S. Tsirkin
2025-10-09 11:24 ` [PATCH 3/3] vhost: use checked versions of VIRTIO_BIT Michael S. Tsirkin
2025-10-09 12:47 ` Andrew Lunn
2025-10-09 12:54 ` Michael S. Tsirkin
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=20251012151345-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=andrew@lunn.ch \
--cc=corbet@lwn.net \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.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).