From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Cédric Le Goater" <clg@kaod.org>, qemu-ppc@nongnu.org
Cc: <qemu-devel@nongnu.org>,
"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
"Frederic Barrat" <frederic.barrat@fr.ibm.com>
Subject: Re: [PATCH 1/4] pnv/chiptod: Add POWER9/10 chiptod model
Date: Wed, 14 Jun 2023 15:30:14 +1000 [thread overview]
Message-ID: <CTC4K105L91Y.YIIZVUGP786T@wheely> (raw)
In-Reply-To: <69c9cd27-87b5-3864-1ae2-a6b01a26086e@kaod.org>
On Tue Jun 6, 2023 at 12:57 AM AEST, Cédric Le Goater wrote:
> On 6/4/23 01:36, Nicholas Piggin wrote:
> > diff --git a/hw/ppc/pnv_chiptod.c b/hw/ppc/pnv_chiptod.c
> > new file mode 100644
> > index 0000000000..04ef703e0f
> > --- /dev/null
> > +++ b/hw/ppc/pnv_chiptod.c
> > @@ -0,0 +1,488 @@
> > +/*
> > + * QEMU PowerPC PowerNV Emulation of some CHIPTOD behaviour
> > + *
> > + * Copyright (c) 2022-2023, IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License, version 2, as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, see <http://www.gnu.org/licenses/>.
>
> You can simplify the header with
>
> * SPDX-License-Identifier: GPL-2.0-or-later
Sure.
> > +
> > +static void chiptod_power9_send_remotes(PnvChipTOD *chiptod)
>
> Adding a class handler could be an alternative implementation.
Might be a good idea, I'll see how it looks.
> > +{
> > + PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > + int i;
> > +
> > + for (i = 0; i < pnv->num_chips; i++) {
>
> There are a few other models (XIVE, XIVE2) which loop on the chips,
> is it time to introduce a pnv_foreach_chip(fn, data) routine ?
>
>
> > + Pnv9Chip *chip9 = PNV9_CHIP(pnv->chips[i]);
> > + if (&chip9->chiptod != chiptod) {
> > + chip9->chiptod.tod_state = tod_running;
> > + }
> > + }
> > +}
[snip]
> > + case TOD_TX_TTYPE_CTRL_REG:
> > + if (val & PPC_BIT(35)) { /* SCOM addressing */
> > + uint32_t addr = val >> 32;
> > + uint32_t reg = addr & 0xfff;
> > + PnvCore *pc;
> > +
> > + if (reg != PC_TOD) {
> > + qemu_log_mask(LOG_GUEST_ERROR, "pnv_chiptod: SCOM addressing: "
> > + "unimplemented slave register 0x%" PRIx32 "\n",
> > + reg);
> > + return;
> > + }
> > +
> > + /*
> > + * This may not deal with P10 big-core addressing at the moment.
> > + * The big-core code in skiboot syncs small cores, but it targets
> > + * the even PIR (first small-core) when syncing second small-core.
> > + */
> > + pc = pnv_get_vcpu_by_xscom_base(chiptod->chip, addr & ~0xfff);
>
> hmm, couldn't we map xscom subregions, one for each thread instead ?
I'm not sure what you mean. This scom-addressing uses the xscom
address of the core's PC unit (where its time facilities are) to
point nest chiptod transfers to cores.
>
> > + if (pc) {
> > + /*
> > + * If TCG implements SMT, TFMR is a per-core SPR and should
> > + * be updated such that it is reflected in all threads.
> > + * Same for TB if the chiptod model ever actually adjusted it.
> > + */
> > + chiptod->slave_cpu_target = pc->threads[0];
>
> ah ! SMT is implemented :) The xscom subregions would help to get the
> CPU pointer.
I think I may be mistaken at least in the "get_vcpu" part. I think
it should be get core, I don't know if chiptod is capable of addressing
threads individually.
I could test it with SMT patches and see what skiboot does.
> > +static int pnv_chiptod_dt_xscom(PnvXScomInterface *dev, void *fdt,
> > + int xscom_offset,
> > + const char compat[], size_t compat_size)
> > +{
> > + PnvChipTOD *chiptod = PNV_CHIPTOD(dev);
> > + g_autofree char *name = NULL;
> > + int offset;
> > + uint32_t lpc_pcba = PNV9_XSCOM_CHIPTOD_BASE;
>
> lpc ?
Shh don't tell anybody I mostly code via copy and paste :P
[snip]
> > +static void pnv_chiptod_realize(DeviceState *dev, Error **errp)
> > +{
> > + static bool got_primary = false;
> > + static bool got_secondary = false;
> > +
> > + PnvChipTOD *chiptod = PNV_CHIPTOD(dev);
> > + PnvChipTODClass *pctc = PNV_CHIPTOD_GET_CLASS(chiptod);
> > +
> > + if (!got_primary) {
> > + got_primary = true;
> > + chiptod->primary = true;
> > + chiptod->pss_mss_ctrl_reg |= PPC_BIT(1); /* TOD is master */
> > + } else if (!got_secondary) {
> > + got_secondary = true;
> > + chiptod->secondary = true;
> > + }
>
> It would be cleaner to introduce "primary" and "secondary" properties
> defined by the model realizing the PnvChipTOD objects.
Hum. There's a few hard-coded primaries on chip_id == 0 already
in the tree. I don't know how closely related they are, chiptod
can set other chips as primary AFAIK but maybe it just makes
sense to make primary a chip property.
I might dig a bit more into what we (and other IBM firmware) want
to test or expect with these primaries. Maybe another pass to
tidy all that up can be done.
[...]
> > +#ifndef PPC_PNV_CHIPTOD_H
> > +#define PPC_PNV_CHIPTOD_H
> > +
> > +#include "qom/object.h"
> > +
> > +#define TYPE_PNV_CHIPTOD "pnv-chiptod"
> > +OBJECT_DECLARE_TYPE(PnvChipTOD, PnvChipTODClass, PNV_CHIPTOD)
> > +#define TYPE_PNV9_CHIPTOD TYPE_PNV_CHIPTOD "-POWER9"
> > +DECLARE_INSTANCE_CHECKER(PnvChipTOD, PNV9_CHIPTOD, TYPE_PNV9_CHIPTOD)
> > +#define TYPE_PNV10_CHIPTOD TYPE_PNV_CHIPTOD "-POWER10"
> > +DECLARE_INSTANCE_CHECKER(PnvChipTOD, PNV10_CHIPTOD, TYPE_PNV10_CHIPTOD)
> > +
> > +enum tod_state {
>
> PnvChipTODState would be better naming.
Agree.
Thanks,
Nick
next prev parent reply other threads:[~2023-06-14 5:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-03 23:36 [PATCH 0/4] ppc/pnv: Add chiptod and core timebase state machine models Nicholas Piggin
2023-06-03 23:36 ` [PATCH 1/4] pnv/chiptod: Add POWER9/10 chiptod model Nicholas Piggin
2023-06-05 14:57 ` Cédric Le Goater
2023-06-14 5:30 ` Nicholas Piggin [this message]
2023-06-14 7:01 ` Cédric Le Goater
2023-06-03 23:36 ` [PATCH 2/4] target/ppc: Tidy POWER book4 SPR registration Nicholas Piggin
2023-06-05 14:58 ` Cédric Le Goater
2023-06-03 23:36 ` [PATCH 3/4] target/ppc: add TFMR SPR implementation with read and write helpers Nicholas Piggin
2023-06-14 8:38 ` Cédric Le Goater
2023-06-03 23:36 ` [PATCH 4/4] target/ppc: Implement core timebase state machine and TFMR Nicholas Piggin
2023-06-14 8:55 ` Cédric Le Goater
2023-06-06 13:59 ` [PATCH 0/4] ppc/pnv: Add chiptod and core timebase state machine models Cédric Le Goater
2023-06-14 5:14 ` Nicholas Piggin
2023-06-14 8:54 ` Cédric Le Goater
2023-06-15 2:18 ` Nicholas Piggin
2023-06-15 9:45 ` Cédric Le Goater
2023-06-22 7:30 ` Cédric Le Goater
2023-06-22 9:54 ` Nicholas Piggin
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=CTC4K105L91Y.YIIZVUGP786T@wheely \
--to=npiggin@gmail.com \
--cc=clg@kaod.org \
--cc=dbarboza@ventanamicro.com \
--cc=frederic.barrat@fr.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.