From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org, "Michael Tsirkin" <mst@redhat.com>,
"Fan Ni" <fan.ni@samsung.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
linuxarm@huawei.com
Subject: Re: [PATCH 2/4] hw/cxl: Use available size parameter to index into register arrays.
Date: Mon, 18 Sep 2023 13:29:26 +0100 [thread overview]
Message-ID: <20230918132926.00005c97@Huawei.com> (raw)
In-Reply-To: <d1eac212-91c4-a78d-abbd-15d24a732680@tls.msk.ru>
On Thu, 14 Sep 2023 15:54:54 +0300
Michael Tokarev <mjt@tls.msk.ru> wrote:
> 13.09.2023 18:05, Jonathan Cameron via wrote:
> > Indexing has to be done into an array with the right size elements.
> > As such, the size parameter always matches the array element size
> > and can be used in place of the longer sizeof(*array)
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > ---
> > hw/cxl/cxl-component-utils.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/cxl/cxl-component-utils.c b/hw/cxl/cxl-component-utils.c
> > index f3bbf0fd13..089e10b232 100644
> > --- a/hw/cxl/cxl-component-utils.c
> > +++ b/hw/cxl/cxl-component-utils.c
> > @@ -76,7 +76,7 @@ static uint64_t cxl_cache_mem_read_reg(void *opaque, hwaddr offset,
> > if (cregs->special_ops && cregs->special_ops->read) {
> > return cregs->special_ops->read(cxl_cstate, offset, size);
> > } else {
> > - return cregs->cache_mem_registers[offset / sizeof(*cregs->cache_mem_registers)];
> > + return cregs->cache_mem_registers[offset / size];
>
> This is a though one, and smells wrong.
>
> Though because it is not at all obvious where this "size" value comes from,
> have to find usage(s) of this function (cache_mem_ops) and think twice about
> the other parameters in there. Also having in mind the previous comparison
> with 8. In this part of the code, size should always be =4, but it takes
> hard time to figure this out.
>
> Wrong - no, because of the above - the only 2 possible values are 4 and 8,
> but it's difficult to see what's going on, and you're making it worse.
>
> Original code was at least clear you're getting a single register from
> an array of registers, with new code it is not clear at all.
Fair point.
>
> What I'd probably use here is to add comment that size can be either 4 or 8,
> and use a switch similar to what you've used in first patch in this series.
> And have a static_assert(sizeof(register) == 4) or something like that
> here in this second branch.
Good idea.
>
> So it is something like:
>
> static uint64_t cxl_cache_mem_read_reg(void *opaque, hwaddr offset,
> unsigned size)
> {
> CXLComponentState *cxl_cstate = opaque;
> ComponentRegisters *cregs = &cxl_cstate->crb;
>
> switch (size) {
> case 8:
> qemu_log_mask(LOG_UNIMP,
> "CXL 8 byte cache mem registers not implemented\n");
> return 0;
>
> case 4:
> if (cregs->special_ops && cregs->special_ops->read) {
> return cregs->special_ops->read(cxl_cstate, offset, 4);
> } else {
> return cregs->cache_mem_registers[offset /
> sizeof(*cregs->cache_mem_registers)];
> }
>
> default:
> /* this routine is called with size being either 4 or 8 only */
> g_assert_not_reached();
> }
> }
>
> Note: I especially left the sizeof() here, instead of using a previously
> suggested static_assert() - because a register can be implemented using
> larger integers on the host, it does not need to be 4 bytes, - but only
> low 4 bytes can actually be used.
I don't follow. Here cache_mem_registers is an array of uint32_t so
it is going to be 4 bytes on any host! Obviously that's not true for
registers in general.
So I've added the assert as it is always valid and made it a / 4
Note I ended up with just using size in the first place because I was
planning to add a local variable that was always the same size and that was silly.
>
> This does not shorten the line (it does by wrapping it up), but it keep
> code correct and more understandable. Adding size parameter there makes
> it much more cryptic.
>
> Here and in other places.
>
> This is just an example, not a suggestion.
It makes sense. Sorry - thought I'd sent this last week!
Jonathan
>
> /mjt
>
next prev parent reply other threads:[~2023-09-18 12:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-13 15:05 [PATCH 0/4] hw/cxl: Line length reduction and related Jonathan Cameron via
2023-09-13 15:05 ` [PATCH 1/4] hw/cxl: Use a switch to explicitly check size in caps_reg_read() Jonathan Cameron via
2023-09-13 15:13 ` Philippe Mathieu-Daudé
2023-09-13 15:05 ` [PATCH 2/4] hw/cxl: Use available size parameter to index into register arrays Jonathan Cameron via
2023-09-14 12:54 ` Michael Tokarev
2023-09-18 12:29 ` Jonathan Cameron via [this message]
2023-09-13 15:05 ` [PATCH 3/4] hw/cxl: CXLDVSECPortExtensions renamed to CXLDVSECPortExt Jonathan Cameron via
2023-09-14 5:44 ` Philippe Mathieu-Daudé
2023-09-13 15:05 ` [PATCH 4/4] hw/cxl: Line length reductions Jonathan Cameron via
2023-09-14 12:57 ` Michael Tokarev
2023-09-15 17:01 ` Jonathan Cameron via
2023-09-15 17:07 ` Jonathan Cameron via
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=20230918132926.00005c97@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=fan.ni@samsung.com \
--cc=linuxarm@huawei.com \
--cc=mjt@tls.msk.ru \
--cc=mst@redhat.com \
--cc=philmd@linaro.org \
/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).