From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <danielhb413@gmail.com>,
qemu-ppc@nongnu.org, clg@kaod.org, david@gibson.dropbear.id.au
Subject: [PATCH v3 08/10] pnv_phb4.c: check stack->phb not NULL in phb4_update_regions()
Date: Mon, 10 Jan 2022 11:33:44 -0300 [thread overview]
Message-ID: <20220110143346.455901-9-danielhb413@gmail.com> (raw)
In-Reply-To: <20220110143346.455901-1-danielhb413@gmail.com>
The last step before enabling user creatable pnv-phb4 devices still has
to do with specific XSCOM initialization code in pnv_phb4_stk_realize().
'stack->nest_regs_mr' is being init regardless of the existence of
'stack->phb', which is verified only when trying to realize the phb.
Its MemoryRegionOps,'pnv_pec_stk_nest_xscom_ops', uses
pnv_pec_stk_nest_xscom_write() as a write callback. When trying to write
the PEC_NEST_STK_BAR_EN reg, pnv_pec_stk_update_map() is called. Inside
this function, pnv_phb4_update_regions() is called twice. This function
uses stack->phb to manipulate memory regions of the phb.
When enabling user creatable phb4s, a stack that doesn't have an
associated phb (i.e. will have stack->phb = NULL) will cause a SIGINT
during boot in pnv_phb4_update_regions(). To deal with this we have
some options, including:
- check for stack->phb being not NULL in pnv_phb4_update_regions();
- change the order of the XSCOM initialization to avoid initializing
'stack->nest_regs_mr' if 'stack->phb' is NULL. This can have unintended
side-effects: there are several other regs that are being read/written
in these memory regions, and we would forbid all read/write operations
in these regs because of writes in PEC_NEST_STK_BAR_EN being problematic;
- move the XSCOM init code to phb4_realize() like the previous patch
did with 'stack->phb_regs_mr'. Besides having the same potential side
effects than the previous alternative, a lot of code would need to be
moved from pnv_phb4_pec.c to pnv_phb4.c because all the memory region
code is static.
Being the option that is less intrusive and innocus of the alternatives,
this patch keeps the XSCOM initialization as is in
pnv_phb4_stk_realize() and check for 'stack->phb' being NULL in
pnv_phb4_update_regions().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
hw/pci-host/pnv_phb4.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 152911a285..fc23a96b7f 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1472,6 +1472,17 @@ void pnv_phb4_update_regions(PnvPhb4PecStack *stack)
{
PnvPHB4 *phb = stack->phb;
+ /*
+ * This will happen when there's no phb associated with the stack.
+ * pnv_pec_stk_realize() will init the nested xscom address space
+ * (stack->nest_regs_mr) that uses pnv_phb4_update_regions(), via
+ * pnv_pec_stk_update_map(), which in turn is the write callback of
+ * the PEC_NEST_STK_BAR_EN reg in pnv_pec_stk_nest_xscom_write().
+ */
+ if (!stack->phb) {
+ return;
+ }
+
/* Unmap first always */
if (memory_region_is_mapped(&phb->mr_regs)) {
memory_region_del_subregion(&stack->phbbar, &phb->mr_regs);
--
2.33.1
next prev parent reply other threads:[~2022-01-10 14:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 14:33 [PATCH v3 00/10] user creatable pnv-phb4 devices Daniel Henrique Barboza
2022-01-10 14:33 ` [PATCH v3 01/10] pnv_phb4.c: introduce pnv_phb4_set_stack_phb_props() Daniel Henrique Barboza
2022-01-10 14:33 ` [PATCH v3 02/10] pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.c Daniel Henrique Barboza
2022-01-10 14:33 ` [PATCH v3 03/10] pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom() Daniel Henrique Barboza
2022-01-10 14:33 ` [PATCH v3 04/10] pnv_phb4_pec.c: remove stack 'phb-id' alias Daniel Henrique Barboza
2022-01-10 15:49 ` Cédric Le Goater
2022-01-10 16:27 ` Daniel Henrique Barboza
2022-01-10 16:42 ` Cédric Le Goater
2022-01-10 14:33 ` [PATCH v3 05/10] pnv_phb4_pec.c: move phb4 properties setup to pec_realize() Daniel Henrique Barboza
2022-01-10 15:58 ` Cédric Le Goater
2022-01-10 14:33 ` [PATCH v3 06/10] ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack Daniel Henrique Barboza
2022-01-10 15:52 ` Cédric Le Goater
2022-01-10 14:33 ` [PATCH v3 07/10] ppc/pnv: move PHB4 related XSCOM init to phb4_realize() Daniel Henrique Barboza
2022-01-10 15:57 ` Cédric Le Goater
2022-01-10 16:11 ` Daniel Henrique Barboza
2022-01-10 14:33 ` Daniel Henrique Barboza [this message]
2022-01-10 15:59 ` [PATCH v3 08/10] pnv_phb4.c: check stack->phb not NULL in phb4_update_regions() Cédric Le Goater
2022-01-10 14:33 ` [PATCH v3 09/10] ppc/pnv: Introduce user creatable pnv-phb4 devices Daniel Henrique Barboza
2022-01-10 16:12 ` Cédric Le Goater
2022-01-10 14:33 ` [PATCH v3 10/10] pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS name Daniel Henrique Barboza
2022-01-10 16:25 ` [PATCH v3 00/10] user creatable pnv-phb4 devices Cédric Le Goater
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=20220110143346.455901-9-danielhb413@gmail.com \
--to=danielhb413@gmail.com \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--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.