Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. May 13, 2022
  3. May 08, 2022
  5. Apr 20, 2022
  7. Apr 06, 2022
  9. Mar 21, 2022
  11. Mar 14, 2022
    • Cédric Le Goater's avatar
      ppc/pnv: Remove user-created PHB{3,4,5} devices · 9c10d86f
      Cédric Le Goater authored 
      
On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI adapter on a slot. Nevertheless, having user-created
PHBs in QEMU seemed to be a good idea for testing purposes :

 1. having a limited set of PHBs speedups boot time.
 2. it is useful to be able to mimic a partially broken topology you
    some time have to deal with during bring-up.

PowerNV is also used for distro install tests and having libvirt
support eases these tasks. libvirt prefers to run the machine with
-nodefaults to be sure not to drag unexpected devices which would need
to be defined in the domain file without being specified on the QEMU
command line. For this reason :

 3. -nodefaults should not include default PHBs

User-created PHB{3,4,5} devices satisfied all these needs but reality
proves to be a bit more complex, internally when modeling such
devices, and externally when dealing with the user interface.

Req 1. and 2. can be simply addressed differently with a machine option:
"phb-mask=<uint>", which QEMU would use to enable/disable PHB device
nodes when creating the device tree.

For Req 3., we need to make sure we are taking the right approach. It
seems that we should expose a new type of user-created PHB device, a
generic virtualized one, that libvirt would use and not one depending
on the processor revision. This needs more thinking.

For now, remove user-created PHB{3,4,5} devices. All the cleanups we
did are not lost and they will be useful for the next steps.

Fixes: 5bc67b05 ("ppc/pnv: Introduce user creatable pnv-phb4 devices")
Fixes: 1f6a88ff ("ppc/pnv: Introduce support for user created PHB3 devices")
Reviewed-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: default avatarFrederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
Message-Id: <20220314130514.529931-1-clg@kaod.org>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      9c10d86f
    • Frederic Barrat's avatar
      ppc/pnv: Introduce a pnv-phb5 device to match root port · d3df1f64
      Frederic Barrat authored 
      
We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and
POWER9 respectively. POWER10 uses version 5 of the PHB. It is very
close to the PHB4 from POWER9, at least in our model and we could
almost keep using the PHB4 model. However the matching root port
pnv-phb5-root-port is specific to POWER10 so to avoid confusion as
well as making it easy to introduce differences later, we create a
pnv-phb5 class, which is mostly an alias for pnv-phb4 for now.

With this patch, the command line for a user-created PHB on powernv10
becomes:
  -machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port

Fixes: 623575e1 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: default avatarFrederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      d3df1f64
  13. Mar 02, 2022
  15. Jan 28, 2022
  17. Jan 18, 2022
  19. Jan 12, 2022
    • Daniel Henrique Barboza's avatar
      ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write() · f83460bb
      Daniel Henrique Barboza authored 
      
pnv_pec_stk_pci_xscom_write() is pnv_pec_stk_pci_xscom_ops write
callback. It writes values into regs in the stack->nest_regs[] array.
The pnv_pec_stk_pci_xscom_read read callback, on the other hand, returns
values of the stack->pci_regs[]. In fact, at this moment, the only use
of stack->pci_regs[] is in pnv_pec_stk_pci_xscom_read(). There's no code
that is written anything in stack->pci_regs[], which is suspicious.

Considering that stack->nest_regs[] is widely used by the nested
MemoryOps pnv_pec_stk_nest_xscom_ops, in both read and write callbacks,
the conclusion is that we're writing the wrong array in
pnv_pec_stk_pci_xscom_write(). This function should write stack->pci_regs[]
instead.

Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: default avatarFrederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220111200132.633896-2-danielhb413@gmail.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      f83460bb
    • Daniel Henrique Barboza's avatar
      ppc/pnv: turn pnv_phb4_update_regions() into static · 7e1e0912
      Daniel Henrique Barboza authored 
      
Its only callers are inside pnv_phb4.c.

Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-6-danielhb413@gmail.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      7e1e0912
    • Daniel Henrique Barboza's avatar
      ppc/pnv: Introduce user creatable pnv-phb4 devices · 5bc67b05
      Daniel Henrique Barboza authored 
      
This patch introduces pnv-phb4 user creatable devices that are created
in a similar manner as pnv-phb3 devices, allowing the user to interact
with the PHBs directly instead of creating PCI Express Controllers that
will create a certain amount of PHBs per controller index.

We accomplish this by doing the following:

- add a pnv_phb4_get_stack() helper to retrieve which stack an user
created phb4 would occupy;

- when dealing with an user created pnv-phb4 (detected by checking if
phb->stack is NULL at the start of phb4_realize()), retrieve its stack
and initialize its properties as done in stk_realize();

- use 'defaults_enabled()' in stk_realize() to avoid creating and
initializing a 'stack->phb' qdev that might be overwritten by an user
created pnv-phb4 device. This process is wrapped into a new helper
called pnv_pec_stk_default_phb_realize().

Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-5-danielhb413@gmail.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      5bc67b05
    • Daniel Henrique Barboza's avatar
      ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack · dc8e2914
      Daniel Henrique Barboza authored 
      
At this moment, stack->phb is the plain PnvPHB4 device itself instead of
a pointer to the device. This will present a problem when adding user
creatable devices because we can't deal with this struct and the
realize() callback from the user creatable device.

We can't get rid of this attribute, similar to what we did when enabling
pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs
to access stack->phb to do its job. This function is called twice in
pnv_pec_stk_update_map(), which is one of the nested xscom write
callbacks (via pnv_pec_stk_nest_xscom_write()). In fact,
pnv_pec_stk_update_map() code comment is explicit about how the order of
the unmap/map operations relates with the PHB subregions.

All of this indicates that this code is tied together in a way that we
either go on a crusade, featuring lots of refactories and redesign and
considerable pain, to decouple stack and phb mapping, or we allow stack
update_map operations to access the associated PHB as it is today even
after introducing pnv-phb4 user devices.

This patch chooses the latter. Instead of getting rid of stack->phb,
turn it into a PHB pointer. This will allow us to assign an user created
PHB to an existing stack later. In this process,
pnv_pec_stk_instance_init() is removed because stack->phb is being
initialized in stk_realize() instead.

Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220111131027.599784-4-danielhb413@gmail.com>
Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      dc8e2914