Skip to content
Snippets Groups Projects
  1. Apr 06, 2022
  2. Apr 04, 2022
    • Frederic Barrat's avatar
      ppc/pnv: Fix number of registers in the PCIe controller on POWER9 · 7e515769
      Frederic Barrat authored
      
      The spec defines 3 registers, even though only index 0 and 2 are valid
      on POWER9. The same model is used on POWER10. Register 1 is defined
      there but we currently don't use it in skiboot. So we can keep
      reporting an error on write.
      
      Reported by Coverity (CID 1487176).
      
      Fixes: 4f9924c4 ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge")
      Suggested-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarFrederic Barrat <fbarrat@linux.ibm.com>
      Reviewed-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
      Message-Id: <20220401091925.770803-1-fbarrat@linux.ibm.com>
      Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      7e515769
    • Daniel Henrique Barboza's avatar
      hw/ppc: free env->tb_env in spapr_unrealize_vcpu() · ef95a244
      Daniel Henrique Barboza authored
      
      The timebase is allocated during spapr_realize_vcpu() and it's not
      freed. This results in memory leaks when doing vcpu unplugs:
      
      ==636935==
      ==636935== 144 (96 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 6
      ,461 of 8,135
      ==636935==    at 0x4897468: calloc (vg_replace_malloc.c:760)
      ==636935==    by 0x5077213: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.4)
      ==636935==    by 0x507757F: g_malloc0_n (in /usr/lib64/libglib-2.0.so.0.6400.4)
      ==636935==    by 0x93C3FB: cpu_ppc_tb_init (ppc.c:1066)
      ==636935==    by 0x97BC2B: spapr_realize_vcpu (spapr_cpu_core.c:268)
      ==636935==    by 0x97C01F: spapr_cpu_core_realize (spapr_cpu_core.c:337)
      ==636935==    by 0xD4626F: device_set_realized (qdev.c:531)
      ==636935==    by 0xD55273: property_set_bool (object.c:2273)
      ==636935==    by 0xD523DF: object_property_set (object.c:1408)
      ==636935==    by 0xD588B7: object_property_set_qobject (qom-qobject.c:28)
      ==636935==    by 0xD52897: object_property_set_bool (object.c:1477)
      ==636935==    by 0xD4579B: qdev_realize (qdev.c:333)
      ==636935==
      
      This patch adds a cpu_ppc_tb_free() helper in hw/ppc/ppc.c to allow us
      to free the timebase. This leak is then solved by calling
      cpu_ppc_tb_free() in spapr_unrealize_vcpu().
      
      Fixes: 6f4b5c3e ("spapr: CPU hot unplug support")
      Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
      Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Message-Id: <20220329124545.529145-2-danielhb413@gmail.com>
      Signed-off-by: default avatarCédric Le Goater <clg@kaod.org>
      ef95a244
  3. Mar 29, 2022
  4. Mar 28, 2022
    • Philippe Mathieu-Daudé's avatar
      main-loop: Disable block backend global state assertion on Cocoa · 47281859
      Philippe Mathieu-Daudé authored
      
      Since commit 0439c5a4 ("block/block-backend.c: assertions for
      block-backend") QEMU crashes when using Cocoa on Darwin hosts.
      
      Example on macOS:
      
        $ qemu-system-i386
        Assertion failed: (qemu_in_main_thread()), function blk_all_next, file block-backend.c, line 552.
        Abort trap: 6
      
      Looking with lldb:
      
        Assertion failed: (qemu_in_main_thread()), function blk_all_next, file block-backend.c, line 552.
        Process 76914 stopped
        * thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
           frame #4: 0x000000010057c2d4 qemu-system-i386`blk_all_next.cold.1
        at block-backend.c:552:5 [opt]
            549    */
            550   BlockBackend *blk_all_next(BlockBackend *blk)
            551   {
        --> 552       GLOBAL_STATE_CODE();
            553       return blk ? QTAILQ_NEXT(blk, link)
            554                  : QTAILQ_FIRST(&block_backends);
            555   }
        Target 1: (qemu-system-i386) stopped.
      
        (lldb) bt
        * thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
           frame #0: 0x00000001908c99b8 libsystem_kernel.dylib`__pthread_kill + 8
           frame #1: 0x00000001908fceb0 libsystem_pthread.dylib`pthread_kill + 288
           frame #2: 0x000000019083a314 libsystem_c.dylib`abort + 164
           frame #3: 0x000000019083972c libsystem_c.dylib`__assert_rtn + 300
         * frame #4: 0x000000010057c2d4 qemu-system-i386`blk_all_next.cold.1 at block-backend.c:552:5 [opt]
           frame #5: 0x00000001003c00b4 qemu-system-i386`blk_all_next(blk=<unavailable>) at block-backend.c:552:5 [opt]
           frame #6: 0x00000001003d8f04 qemu-system-i386`qmp_query_block(errp=0x0000000000000000) at qapi.c:591:16 [opt]
           frame #7: 0x000000010003ab0c qemu-system-i386`main [inlined] addRemovableDevicesMenuItems at cocoa.m:1756:21 [opt]
           frame #8: 0x000000010003ab04 qemu-system-i386`main(argc=<unavailable>, argv=<unavailable>) at cocoa.m:1980:5 [opt]
           frame #9: 0x00000001012690f4 dyld`start + 520
      
      As we are in passed release 7.0 hard freeze, disable the block
      backend assertion which, while being valuable during development,
      is not helpful to users. We'll restore this assertion immediately
      once 7.0 is released and work on a fix.
      
      Suggested-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Signed-off-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Reviewed-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Message-Id: <20220325183707.85733-1-philippe.mathieu.daude@gmail.com>
      47281859
  5. Mar 22, 2022
  6. Mar 21, 2022
  7. Mar 18, 2022
  8. Mar 16, 2022
  9. Mar 15, 2022
  10. 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
    • Marc-André Lureau's avatar
      ui/console: move dcl compatiblity check to a callback · a62c4a17
      Marc-André Lureau authored
      
      As expected from the "compatible_dcl" comment, a simple comparison of
      ops isn't enough. The following patch will fix a regression introduced
      by this limited check by extending the compatibility callback for
      egl-headless.
      
      For now, this patch simply replaces the the "compatible_dcl" ops pointer
      with a "dpy_gl_ctx_is_compatible_ctx" callback.
      
      Signed-off-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Acked-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      a62c4a17
  11. Mar 09, 2022
Loading