qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] a7d4b1: target/ppc: fix the PPC_BIT definitio


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] a7d4b1: target/ppc: fix the PPC_BIT definitions
Date: Fri, 21 Dec 2018 11:30:29 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: a7d4b1bf418acae58a3f0649c578cc0451136f46
      
https://github.com/qemu/qemu/commit/a7d4b1bf418acae58a3f0649c578cc0451136f46
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M target/ppc/cpu.h

  Log Message:
  -----------
  target/ppc: fix the PPC_BIT definitions

Change the PPC_BIT macro to use ULL instead of UL and the PPC_BIT32
and PPC_BIT8 not to use any suffix.

This fixes a compile breakage on windows.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 6187ec05edc240204935fdf0d89cded563fdeab4
      
https://github.com/qemu/qemu/commit/6187ec05edc240204935fdf0d89cded563fdeab4
  Author: David Gibson <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M target/ppc/cpu.h

  Log Message:
  -----------
  target/ppc: Remove silly GETFIELD/SETFIELD/MASK_TO_LSH macros

The (only) obvious use for these macros is constructing and parsing guest
visible register fields.  But the way they're constructed, they're only
valid when used on a *host* long, whose size shouldn't be visible to the
guest at all.

They also have no current users, so just get rid of them.

Signed-off-by: David Gibson <address@hidden>


  Commit: 3908a24fcb83913079d315de0ca6d598e8616dbb
      
https://github.com/qemu/qemu/commit/3908a24fcb83913079d315de0ca6d598e8616dbb
  Author: Serhii Popovych <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Fix ibm,max-associativity-domains property number of nodes

Laurent Vivier reported off by one with maximum number of NUMA nodes
provided by qemu-kvm being less by one than required according to
description of "ibm,max-associativity-domains" property in LoPAPR.

It appears that I incorrectly treated LoPAPR description of this
property assuming it provides last valid domain (NUMA node here)
instead of maximum number of domains.

  ### Before hot-add

  (qemu) info numa
  3 nodes
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 plugged: 0 MB
  node 1 cpus:
  node 1 size: 1024 MB
  node 1 plugged: 0 MB
  node 2 cpus:
  node 2 size: 0 MB
  node 2 plugged: 0 MB

  $ numactl -H
  available: 2 nodes (0-1)
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 free: 0 MB
  node 1 cpus:
  node 1 size: 999 MB
  node 1 free: 658 MB
  node distances:
  node   0   1
    0:  10  40
    1:  40  10

  ### Hot-add

  (qemu) object_add memory-backend-ram,id=mem0,size=1G
  (qemu) device_add pc-dimm,id=dimm1,memdev=mem0,node=2
  (qemu) [   87.704898] pseries-hotplug-mem: Attempting to hot-add 4 ...
  <there is no "Initmem setup node 2 [mem 0xHEX-0xHEX]">
  [   87.705128] lpar: Attempting to resize HPT to shift 21
  ... <HPT resize messages>

  ### After hot-add

  (qemu) info numa
  3 nodes
  node 0 cpus: 0
  node 0 size: 0 MB
  node 0 plugged: 0 MB
  node 1 cpus:
  node 1 size: 1024 MB
  node 1 plugged: 0 MB
  node 2 cpus:
  node 2 size: 1024 MB
  node 2 plugged: 1024 MB

  $ numactl -H
  available: 2 nodes (0-1)
  ^^^^^^^^^^^^^^^^^^^^^^^^
       Still only two nodes (and memory hot-added to node 0 below)
  node 0 cpus: 0
  node 0 size: 1024 MB
  node 0 free: 1021 MB
  node 1 cpus:
  node 1 size: 999 MB
  node 1 free: 658 MB
  node distances:
  node   0   1
    0:  10  40
    1:  40  10

After fix applied numactl(8) reports 3 nodes available and memory
plugged into node 2 as expected.

>From David Gibson:
------------------
  Qemu makes a distinction between "non NUMA" (nb_numa_nodes == 0) and
  "NUMA with one node" (nb_numa_nodes == 1).  But from a PAPR guests's
  point of view these are equivalent.  I don't want to present two
  different cases to the guest when we don't need to, so even though the
  guest can handle it, I'd prefer we put a '1' here for both the
  nb_numa_nodes == 0 and nb_numa_nodes == 1 case.

This consolidates everything discussed previously on mailing list.

Fixes: da9f80fbad21 ("spapr: Add ibm,max-associativity-domains property")
Reported-by: Laurent Vivier <address@hidden>
Signed-off-by: Serhii Popovych <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 4c5920af4e9e0bd4473a03da32371e1658d168c0
      
https://github.com/qemu/qemu/commit/4c5920af4e9e0bd4473a03da32371e1658d168c0
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M disas/ppc.c
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: tcg: Implement addex instruction

Implement the addex instruction introduced in ISA V3.00 in qemu tcg.

The add extended using alternate carry bit (addex) instruction performs
the same operation as the add extended (adde) instruction, but using the
overflow (ov) field in the fixed point exception register (xer) as the
carry in and out instead of the carry (ca) field.

The instruction has a Z23-form, not an XO form, as follows:

    ------------------------------------------------------------------
    |   31   |   RT   |   RA   |   RB   |   CY   |     170     |  0  |
    ------------------------------------------------------------------
    0        6        11       16       21       23            31    32

However since the only valid form of the instruction defined so far is
CY = 0, we can treat this like an XO form instruction.

There is no dot form (addex.) of the instruction and the summary overflow
(so) bit in the xer is not modified by this instruction.

For simplicity we reuse the gen_op_arith_add function and add a function
argument to specify where the carry in input should come from and the
carry out output be stored (note must be the same location).

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 118abc71ed900e7a2cafa3c12eb39b0184f2ba22
      
https://github.com/qemu/qemu/commit/118abc71ed900e7a2cafa3c12eb39b0184f2ba22
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: drop redundant statement in spapr_populate_drconf_memory()

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: cc226c068f985e7788fcbf21e146efe54402eda1
      
https://github.com/qemu/qemu/commit/cc226c068f985e7788fcbf21e146efe54402eda1
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  target/ppc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: dec4ec40a110a43bf6304b9c4ee25663d059029d
      
https://github.com/qemu/qemu/commit/dec4ec40a110a43bf6304b9c4ee25663d059029d
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr_iommu.c
    M hw/ppc/spapr_vio.c

  Log Message:
  -----------
  spapr: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 779db4c7ca4b2aa3902fcfaab0fcb19fc78638e2
      
https://github.com/qemu/qemu/commit/779db4c7ca4b2aa3902fcfaab0fcb19fc78638e2
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/ppc405_boards.c

  Log Message:
  -----------
  ppc405_boards: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: c4f46986fc856dc1d50d21e2ad617ae845e4ab16
      
https://github.com/qemu/qemu/commit/c4f46986fc856dc1d50d21e2ad617ae845e4ab16
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/ppc405_uc.c

  Log Message:
  -----------
  ppc405_uc: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 30f8ec76309e7b7ce235f4e544553d078a88ce5e
      
https://github.com/qemu/qemu/commit/30f8ec76309e7b7ce235f4e544553d078a88ce5e
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/ppc440_bamboo.c

  Log Message:
  -----------
  ppc440_bamboo: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Edgar E. Iglesias <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 0989e6d1f265c04efa07db52617793e9862ed159
      
https://github.com/qemu/qemu/commit/0989e6d1f265c04efa07db52617793e9862ed159
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/sam460ex.c

  Log Message:
  -----------
  sam460ex: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 57aa218818c06c3fd7e10b5b6e1cbccdca6790ab
      
https://github.com/qemu/qemu/commit/57aa218818c06c3fd7e10b5b6e1cbccdca6790ab
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/virtex_ml507.c

  Log Message:
  -----------
  virtex_ml507: use g_new(T, n) instead of g_malloc(sizeof(T) * n)

Because it is a recommended coding practice (see HACKING).

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Edgar E. Iglesias <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 9929301ee12fb2bc8afe0d954cb1b58a8b1e8880
      
https://github.com/qemu/qemu/commit/9929301ee12fb2bc8afe0d954cb1b58a8b1e8880
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/mac_newworld.c
    M include/hw/ppc/openpic.h

  Log Message:
  -----------
  mac_newworld: simplify IRQ wiring

The OpenPIC have 5 outputs per connected CPU. The machine init code hence
needs a bi-dimensional array (smp_cpu lines, 5 columns) to wire up the irqs
between the PIC and the CPUs.

The current code first allocates an array of smp_cpus pointers to qemu_irq
type, then it allocates another array of smp_cpus * 5 qemu_irq and fills the
first array with pointers to each line of the second array. This is rather
convoluted.

Simplify the logic by introducing a structured type that describes all the
OpenPIC outputs for a single CPU, ie, fixed size of 5 qemu_irq, and only
allocate a smp_cpu sized array of those.

This also allows to use g_new(T, n) instead of g_malloc(sizeof(T) * n)
as recommended in HACKING.

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 2104d4f5bc8f296b3f6f9272bceb8ecfb9581043
      
https://github.com/qemu/qemu/commit/2104d4f5bc8f296b3f6f9272bceb8ecfb9581043
  Author: Greg Kurz <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/e500.c

  Log Message:
  -----------
  e500: simplify IRQ wiring

The OpenPIC have 5 outputs per connected CPU. The machine init code hence
needs a bi-dimensional array (smp_cpu lines, 5 columns) to wire up the irqs
between the PIC and the CPUs.

The current code first allocates an array of smp_cpus pointers to qemu_irq
type, then it allocates another array of smp_cpus * 5 qemu_irq and fills the
first array with pointers to each line of the second array. This is rather
convoluted.

Simplify the logic by introducing a structured type that describes all the
OpenPIC outputs for a single CPU, ie, fixed size of 5 qemu_irq, and only
allocate a smp_cpu sized array of those.

This also allows to use g_new(T, n) instead of g_malloc(sizeof(T) * n)
as recommended in HACKING.

Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 02e3ff548d2379c16990bac9cb84833231e0d20f
      
https://github.com/qemu/qemu/commit/02e3ff548d2379c16990bac9cb84833231e0d20f
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M default-configs/ppc64-softmmu.mak
    M hw/intc/Makefile.objs
    A hw/intc/xive.c
    A include/hw/ppc/xive.h

  Log Message:
  -----------
  ppc/xive: introduce a XIVE interrupt source model

The first sub-engine of the overall XIVE architecture is the Interrupt
Virtualization Source Engine (IVSE). An IVSE can be integrated into
another logic, like in a PCI PHB or in the main interrupt controller
to manage IPIs.

Each IVSE instance is associated with an Event State Buffer (ESB) that
contains a two bit state entry for each possible event source. When an
event is signaled to the IVSE, by MMIO or some other means, the
associated interrupt state bits are fetched from the ESB and
modified. Depending on the resulting ESB state, the event is forwarded
to the IVRE sub-engine of the controller doing the routing.

Each supported ESB entry is associated with either a single or a
even/odd pair of pages which provides commands to manage the source:
to EOI, to turn off the source for instance.

On a sPAPR machine, the O/S will obtain the page address of the ESB
entry associated with a source and its characteristic using the
H_INT_GET_SOURCE_INFO hcall. On PowerNV, a similar OPAL call is used.

The xive_source_notify() routine is in charge forwarding the source
event notification to the routing engine. It will be filled later on.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 5fd9ef18a9707c17d0f1d4262a76fa878edb65c3
      
https://github.com/qemu/qemu/commit/5fd9ef18a9707c17d0f1d4262a76fa878edb65c3
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h

  Log Message:
  -----------
  ppc/xive: add support for the LSI interrupt sources

The 'sent' status of the LSI interrupt source is modeled with the 'P'
bit of the ESB and the assertion status of the source is maintained
with an extra bit under the main XiveSource object. The type of the
source is stored in the same array for practical reasons.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Fix style nit]
Signed-off-by: David Gibson <address@hidden>


  Commit: 5e79b155a8ca342cb6ccfcd2a779e200d34f2a9f
      
https://github.com/qemu/qemu/commit/5e79b155a8ca342cb6ccfcd2a779e200d34f2a9f
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h

  Log Message:
  -----------
  ppc/xive: introduce the XiveNotifier interface

The XiveNotifier offers a simple interface, between the XiveSource
object and the main interrupt controller of the machine. It will
forward event notifications to the XIVE Interrupt Virtualization
Routing Engine (IVRE).

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Adjust type name string for XiveNotifier]
Signed-off-by: David Gibson <address@hidden>


  Commit: 7ff7ea928039e418dfa584c91f3f78512284a79a
      
https://github.com/qemu/qemu/commit/7ff7ea928039e418dfa584c91f3f78512284a79a
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h
    A include/hw/ppc/xive_regs.h

  Log Message:
  -----------
  ppc/xive: introduce the XiveRouter model

The XiveRouter models the second sub-engine of the XIVE architecture :
the Interrupt Virtualization Routing Engine (IVRE).

The IVRE handles event notifications of the IVSE and performs the
interrupt routing process. For this purpose, it uses a set of tables
stored in system memory, the first of which being the Event Assignment
Structure (EAS) table.

The EAT associates an interrupt source number with an Event Notification
Descriptor (END) which will be used in a second phase of the routing
process to identify a Notification Virtual Target.

The XiveRouter is an abstract class which needs to be inherited from
to define a storage for the EAT, and other upcoming tables.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Folded in parts of a later fix by Cédric fixing field access]
[dwg: Fix style nits]
Signed-off-by: David Gibson <address@hidden>


  Commit: e4ddaac67f1fbdeea207fe28d71dca744832377b
      
https://github.com/qemu/qemu/commit/e4ddaac67f1fbdeea207fe28d71dca744832377b
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h
    M include/hw/ppc/xive_regs.h

  Log Message:
  -----------
  ppc/xive: introduce the XIVE Event Notification Descriptors

To complete the event routing, the IVRE sub-engine uses a second table
containing Event Notification Descriptor (END) structures.

An END specifies on which Event Queue (EQ) the event notification
data, defined in the associated EAS, should be posted when an
exception occurs. It also defines which Notification Virtual Target
(NVT) should be notified.

The Event Queue is a memory page provided by the O/S defining a
circular buffer, one per server and priority couple, containing Event
Queue entries. These are 4 bytes long, the first bit being a
'generation' bit and the 31 following bits the END Data field. They
are pulled by the O/S when the exception occurs.

The END Data field is a way to set an invariant logical event source
number for an IRQ. On sPAPR machines, it is set with the
H_INT_SET_SOURCE_CONFIG hcall when the EISN flag is used.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Fold in a later fix from Cédric fixing field accessors]
Signed-off-by: David Gibson <address@hidden>


  Commit: 482969d680b7ae9c903198db2b7ff1984361e0a0
      
https://github.com/qemu/qemu/commit/482969d680b7ae9c903198db2b7ff1984361e0a0
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: initialize VSMT before initializing the IRQ backend

We will need to use xics_max_server_number() to create the sPAPRXive
object modeling the interrupt controller of the machine which is
created before the CPUs.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
[dwg: Fix style nit]
Signed-off-by: David Gibson <address@hidden>


  Commit: fab397d84ab62b99f6e18ce3618f9f85c30f79c5
      
https://github.com/qemu/qemu/commit/fab397d84ab62b99f6e18ce3618f9f85c30f79c5
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h

  Log Message:
  -----------
  spapr: introduce a spapr_irq_init() routine

Initialize the MSI bitmap from it as this will be necessary for the
sPAPR IRQ backend for XIVE.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 1a518e7693c9691b1b26865d1da9cd217e67bcd8
      
https://github.com/qemu/qemu/commit/1a518e7693c9691b1b26865d1da9cd217e67bcd8
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: export and rename the xics_max_server_number() routine

The XIVE sPAPR IRQ backend will use it to define the number of ENDs of
the IC controller.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: fcfbc18d00b10335310c9665edd6e04f2d152be8
      
https://github.com/qemu/qemu/commit/fcfbc18d00b10335310c9665edd6e04f2d152be8
  Author: Paul A. Clarke <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M target/ppc/translate/vmx-ops.inc.c

  Log Message:
  -----------
  Changes requirement for "vsubsbs" instruction

Changes requirement for "vsubsbs" instruction, which has been supported
since ISA 2.03. (Please see section 5.9.1.2 of ISA 2.03)

Reported-by: Paul A. Clarke <address@hidden>
Signed-off-by: Paul A. Clarke <address@hidden>
Signed-off-by: Leonardo Bras <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 002686be42784fdce4c1c8ecd1987ddf740cab77
      
https://github.com/qemu/qemu/commit/002686be42784fdce4c1c8ecd1987ddf740cab77
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h

  Log Message:
  -----------
  ppc/xive: add support for the END Event State Buffers

The Event Notification Descriptor (END) XIVE structure also contains
two Event State Buffers providing further coalescing of interrupts,
one for the notification event (ESn) and one for the escalation events
(ESe). A MMIO page is assigned for each to control the EOI through
loads only. Stores are not allowed.

The END ESBs are modeled through an object resembling the 'XiveSource'
It is stateless as the END state bits are backed into the XiveEND
structure under the XiveRouter and the MMIO accesses follow the same
rules as for the XiveSource ESBs.

END ESBs are not supported by the Linux drivers neither on OPAL nor on
sPAPR. Nevetherless, it provides a mean to study the question in the
future and validates a bit more the XIVE model.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Fold in a later fix for field access]
Signed-off-by: David Gibson <address@hidden>


  Commit: 207d9fe98510eaac575bfde8d1be58137e9a22ff
      
https://github.com/qemu/qemu/commit/207d9fe98510eaac575bfde8d1be58137e9a22ff
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h
    M include/hw/ppc/xive_regs.h

  Log Message:
  -----------
  ppc/xive: introduce the XIVE interrupt thread context

Each POWER9 processor chip has a XIVE presenter that can generate four
different exceptions to its threads:

  - hypervisor exception,
  - O/S exception
  - Event-Based Branch (EBB)
  - msgsnd (doorbell).

Each exception has a state independent from the others called a Thread
Interrupt Management context. This context is a set of registers which
lets the thread handle priority management and interrupt acknowledgment
among other things. The most important ones being :

  - Interrupt Priority Register  (PIPR)
  - Interrupt Pending Buffer     (IPB)
  - Current Processor Priority   (CPPR)
  - Notification Source Register (NSR)

These registers are accessible through a specific MMIO region, called
the Thread Interrupt Management Area (TIMA), four aligned pages, each
exposing a different view of the registers. First page (page address
ending in 0b00) gives access to the entire context and is reserved for
the ring 0 view for the physical thread context. The second (page
address ending in 0b01) is for the hypervisor, ring 1 view. The third
(page address ending in 0b10) is for the operating system, ring 2
view. The fourth (page address ending in 0b11) is for user level, ring
3 view.

The thread interrupt context is modeled with a XiveTCTX object
containing the values of the different exception registers. The TIMA
region is mapped at the same address for each CPU.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: af53dbf6227a78a25ead654998fd8caf46639810
      
https://github.com/qemu/qemu/commit/af53dbf6227a78a25ead654998fd8caf46639810
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M include/hw/ppc/xive.h
    M include/hw/ppc/xive_regs.h

  Log Message:
  -----------
  ppc/xive: introduce a simplified XIVE presenter

The last sub-engine of the XIVE architecture is the Interrupt
Virtualization Presentation Engine (IVPE). On HW, the IVRE and the
IVPE share elements, the Power Bus interface (CQ), the routing table
descriptors, and they can be combined in the same HW logic. We do the
same in QEMU and combine both engines in the XiveRouter for
simplicity.

When the IVRE has completed its job of matching an event source with a
Notification Virtual Target (NVT) to notify, it forwards the event
notification to the IVPE sub-engine. The IVPE scans the thread
interrupt contexts of the Notification Virtual Targets (NVT)
dispatched on the HW processor threads and if a match is found, it
signals the thread. If not, the IVPE escalates the notification to
some other targets and records the notification in a backlog queue.

The IVPE maintains the thread interrupt context state for each of its
NVTs not dispatched on HW processor threads in the Notification
Virtual Target table (NVTT).

The model currently only supports single NVT notifications.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Folded in fix for field accessors]
Signed-off-by: David Gibson <address@hidden>


  Commit: cdd4de68edb6745d35e2a9e14c32f9a588c1fee7
      
https://github.com/qemu/qemu/commit/cdd4de68edb6745d35e2a9e14c32f9a588c1fee7
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c

  Log Message:
  -----------
  ppc/xive: notify the CPU when the interrupt priority is more privileged

After the event data was enqueued in the O/S Event Queue, the IVPE
raises the bit corresponding to the priority of the pending interrupt
in the register IBP (Interrupt Pending Buffer) to indicate there is an
event pending in one of the 8 priority queues. The Pending Interrupt
Priority Register (PIPR) is also updated using the IPB. This register
represent the priority of the most favored pending notification.

The PIPR is then compared to the the Current Processor Priority
Register (CPPR). If it is more favored (numerically less than), the
CPU interrupt line is raised and the EO bit of the Notification Source
Register (NSR) is updated to notify the presence of an exception for
the O/S. The check needs to be done whenever the PIPR or the CPPR are
changed.

The O/S acknowledges the interrupt with a special load in the Thread
Interrupt Management Area. If the EO bit of the NSR is set, the CPPR
takes the value of PIPR. The bit number in the IBP corresponding to
the priority of the pending interrupt is reseted and so is the EO bit
of the NSR.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
[dwg: Fix style nits]
Signed-off-by: David Gibson <address@hidden>


  Commit: 3aa597f6505b4d7b62a1b77ab95a233dd5c7c5f0
      
https://github.com/qemu/qemu/commit/3aa597f6505b4d7b62a1b77ab95a233dd5c7c5f0
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M default-configs/ppc64-softmmu.mak
    M hw/intc/Makefile.objs
    A hw/intc/spapr_xive.c
    A include/hw/ppc/spapr_xive.h

  Log Message:
  -----------
  spapr/xive: introduce a XIVE interrupt controller

sPAPRXive models the XIVE interrupt controller of the sPAPR machine.
It inherits from the XiveRouter and provisions storage for the routing
tables :

  - Event Assignment Structure (EAS)
  - Event Notification Descriptor (END)

The sPAPRXive model incorporates an internal XiveSource for the IPIs
and for the interrupts of the virtual devices of the guest. This model
is consistent with XIVE architecture which also incorporates an
internal IVSE for IPIs and accelerator interrupts in the IVRE
sub-engine.

The sPAPRXive model exports two memory regions, one for the ESB
trigger and management pages used to control the sources and one for
the TIMA pages. They are mapped by default at the addresses found on
chip 0 of a baremetal system. This is also consistent with the XIVE
architecture which defines a Virtualization Controller BAR for the
internal IVSE ESB pages and a Thread Managment BAR for the TIMA.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
[dwg: Fold in field accessor fixes]
Signed-off-by: David Gibson <address@hidden>


  Commit: 0cddee8d488667a7de60e75f76ead8cffe613d75
      
https://github.com/qemu/qemu/commit/0cddee8d488667a7de60e75f76ead8cffe613d75
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/spapr_xive.c

  Log Message:
  -----------
  spapr/xive: use the VCPU id as a NVT identifier

The IVPE scans the O/S CAM line of the XIVE thread interrupt contexts
to find a matching Notification Virtual Target (NVT) among the NVTs
dispatched on the HW processor threads.

On a real system, the thread interrupt contexts are updated by the
hypervisor when a Virtual Processor is scheduled to run on a HW
thread. Under QEMU, the model will emulate the same behavior by
hardwiring the NVT identifier in the thread context registers at
reset.

The NVT identifier used by the sPAPRXive model is the VCPU id. The END
identifier is also derived from the VCPU id. A set of helpers doing
the conversion between identifiers are provided for the hcalls
configuring the sources and the ENDs.

The model does not need a NVT table but the XiveRouter NVT operations
are provided to perform some extra checks in the routing algorithm.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 8994e91e963ed8ba6abd9c2afbb3d6be6f323ab5
      
https://github.com/qemu/qemu/commit/8994e91e963ed8ba6abd9c2afbb3d6be6f323ab5
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr_rtas_ddw.c

  Log Message:
  -----------
  spapr-iommu: Always advertise the maximum possible DMA window size

When deciding about the huge DMA window, the typical Linux pseries guest
uses the maximum allowed RAM size as the upper limit. We did the same
on QEMU side to match that logic. Now we are going to support a GPU RAM
pass through which is not available at the guest boot time as it requires
the guest driver interaction. As the result, the guest requests a smaller
window than it should. Therefore the guest needs to be patched to
understand this new memory and so does QEMU.

Instead of reimplementing here whatever solution we choose for the guest,
this advertises the biggest possible window size limited by 32 bit
(as defined by LoPAPR). Since the window size has to be power-of-two
(the create rtas call receives a window shift, not a size),
this uses 0x8000.0000 as the maximum number of TCEs possible (rather than
32bit maximum of 0xffff.ffff).

This is safe as:
1. The guest visible emulated table is allocated in KVM (actual pages
are allocated in page fault handler) and QEMU (actual pages are allocated
when updated);
2. The hardware table (and corresponding userspace address table)
supports sparse allocation and also checks for locked_vm limit so
it is unable to cause the host any damage.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: dcc345b61ebe499f8f707de2535c2790c52cc703
      
https://github.com/qemu/qemu/commit/dcc345b61ebe499f8f707de2535c2790c52cc703
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_irq.h

  Log Message:
  -----------
  spapr: introduce a new machine IRQ backend for XIVE

The XIVE IRQ backend uses the same layout as the new XICS backend but
covers the full range of the IRQ number space. The IRQ numbers for the
CPU IPIs are allocated at the bottom of this space, below 4K, to
preserve compatibility with XICS which does not use that range.

This should be enough given that the maximum number of CPUs is 1024
for the sPAPR machine under QEMU. For the record, the biggest POWER8
or POWER9 system has a maximum of 1536 HW threads (16 sockets, 192
cores, SMT8).

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 23bcd5eb9a472cc7bd147403d9ba18e293ee6adc
      
https://github.com/qemu/qemu/commit/23bcd5eb9a472cc7bd147403d9ba18e293ee6adc
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/spapr_xive.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_xive.h

  Log Message:
  -----------
  spapr: add hcalls support for the XIVE exploitation interrupt mode

The different XIVE virtualization structures (sources and event queues)
are configured with a set of Hypervisor calls :

 - H_INT_GET_SOURCE_INFO

   used to obtain the address of the MMIO page of the Event State
   Buffer (ESB) entry associated with the source.

 - H_INT_SET_SOURCE_CONFIG

   assigns a source to a "target".

 - H_INT_GET_SOURCE_CONFIG

   determines which "target" and "priority" is assigned to a source

 - H_INT_GET_QUEUE_INFO

   returns the address of the notification management page associated
   with the specified "target" and "priority".

 - H_INT_SET_QUEUE_CONFIG

   sets or resets the event queue for a given "target" and "priority".
   It is also used to set the notification configuration associated
   with the queue, only unconditional notification is supported for
   the moment. Reset is performed with a queue size of 0 and queueing
   is disabled in that case.

 - H_INT_GET_QUEUE_CONFIG

   returns the queue settings for a given "target" and "priority".

 - H_INT_RESET

   resets all of the guest's internal interrupt structures to their
   initial state, losing all configuration set via the hcalls
   H_INT_SET_SOURCE_CONFIG and H_INT_SET_QUEUE_CONFIG.

 - H_INT_SYNC

   issue a synchronisation on a source to make sure all notifications
   have reached their queue.

Calls that still need to be addressed :

   H_INT_SET_OS_REPORTING_LINE
   H_INT_GET_OS_REPORTING_LINE

See the code for more documentation on each hcall.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
[dwg: Folded in fix for field accessors]
Signed-off-by: David Gibson <address@hidden>


  Commit: 6e21de4a50fa1caf163e12a6c90424b750119f96
      
https://github.com/qemu/qemu/commit/6e21de4a50fa1caf163e12a6c90424b750119f96
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/spapr_xive.c
    M hw/intc/xics_spapr.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h
    M include/hw/ppc/spapr_xive.h
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  spapr: add device tree support for the XIVE exploitation mode

The XIVE interface for the guest is described in the device tree under
the "interrupt-controller" node. A couple of new properties are
specific to XIVE :

 - "reg"

   contains the base address and size of the thread interrupt
   managnement areas (TIMA), for the User level and for the Guest OS
   level. Only the Guest OS level is taken into account today.

 - "ibm,xive-eq-sizes"

   the size of the event queues. One cell per size supported, contains
   log2 of size, in ascending order.

 - "ibm,xive-lisn-ranges"

   the IRQ interrupt number ranges assigned to the guest for the IPIs.

and also under the root node :

 - "ibm,plat-res-int-priorities"

   contains a list of priorities that the hypervisor has reserved for
   its own use. OPAL uses the priority 7 queue to automatically
   escalate interrupts for all other queues (DD2.X POWER9). So only
   priorities [0..6] are allowed for the guest.

Extend the sPAPR IRQ backend with a new handler to populate the DT
with the appropriate "interrupt-controller" node.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Fix style nits]
Signed-off-by: David Gibson <address@hidden>


  Commit: 1a937ad7e7a1b4eef37c967cbaeeda5ec5b90855
      
https://github.com/qemu/qemu/commit/1a937ad7e7a1b4eef37c967cbaeeda5ec5b90855
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/xive.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h
    M include/hw/ppc/xive.h

  Log Message:
  -----------
  spapr: allocate the interrupt thread context under the CPU core

Each interrupt mode has its own specific interrupt presenter object,
that we store under the CPU object, one for XICS and one for XIVE.

Extend the sPAPR IRQ backend with a new handler to support them both.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 1c53b06c0309104f30ca2c5e1d1e89ddc38de080
      
https://github.com/qemu/qemu/commit/1c53b06c0309104f30ca2c5e1d1e89ddc38de080
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h

  Log Message:
  -----------
  spapr: extend the sPAPR IRQ backend for XICS migration

Introduce a new sPAPR IRQ handler to handle resend after migration
when the machine is using a KVM XICS interrupt controller model.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: b2e22477166a7f8a32b95317dea747f8af7a807f
      
https://github.com/qemu/qemu/commit/b2e22477166a7f8a32b95317dea747f8af7a807f
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/intc/spapr_xive.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr_irq.h
    M include/hw/ppc/spapr_xive.h

  Log Message:
  -----------
  spapr: add a 'reset' method to the sPAPR IRQ backend

For the time being, the XIVE reset handler updates the OS CAM line of
the vCPU as it is done under a real hypervisor when a vCPU is
scheduled to run on a HW thread. This will let the XIVE presenter
engine find a match among the NVTs dispatched on the HW threads.

This handler will become even more useful when we introduce the
machine supporting both interrupt modes, XIVE and XICS. In this
machine, the interrupt mode is chosen by the CAS negotiation process
and activated after a reset.

Signed-off-by: Cédric Le Goater <address@hidden>
[dwg: Fix style nits]
Signed-off-by: David Gibson <address@hidden>


  Commit: db592b5b16b4f2821b8bb3f4f46825d660d2d4c2
      
https://github.com/qemu/qemu/commit/db592b5b16b4f2821b8bb3f4f46825d660d2d4c2
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_irq.h

  Log Message:
  -----------
  spapr: add an extra OV5 field to the sPAPR IRQ backend

The interrupt modes supported by the hypervisor are advertised to the
guest with new bits definitions of the option vector 5 of property
"ibm,arch-vec-5-platform-support. The byte 23 bits 0-1 of the OV5 are
defined as follow :

  0b00   PAPR 2.7 and earlier (Legacy systems)
  0b01   XIVE Exploitation mode only
  0b10   Either available

If the client/guest selects the XIVE interrupt mode, it informs the
hypervisor by returning the value 0b01 in byte 23 bits 0-1. A 0b00
value indicates the use of the XICS interrupt mode (Legacy systems).

The sPAPR IRQ backend is extended with these definitions and the
values are directly used to populate the "ibm,arch-vec-5-platform-support"
property. The interrupt mode is advertised under TCG and under KVM.
Although a KVM XIVE device is not yet available, the machine can still
operate with kernel_irqchip=off. However, we apply a restriction on
the CPU which is required to be a POWER9 when a XIVE interrupt
controller is in use.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 3ba3d0bc338262f5a23c17e2b6e899da59a544d6
      
https://github.com/qemu/qemu/commit/3ba3d0bc338262f5a23c17e2b6e899da59a544d6
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_irq.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: introduce an 'ic-mode' machine option

This option is used to select the interrupt controller mode (XICS or
XIVE) with which the machine will operate. XICS being the default
mode for now.

When running a machine with the XIVE interrupt mode backend, the guest
OS is required to have support for the XIVE exploitation mode. In the
case of legacy OS, the mode selected by CAS should be XICS and the OS
should fail to boot. However, QEMU could possibly detect it, terminate
the boot process and reset to stop in the SLOF firmware. This is not
yet handled.

Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 34a6b015a98733a4b32881777dafd70156c5a322
      
https://github.com/qemu/qemu/commit/34a6b015a98733a4b32881777dafd70156c5a322
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: change default CPU type to POWER9

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: b62c6e1237fb5ca2563f7e72b66ac0c40ff7a714
      
https://github.com/qemu/qemu/commit/b62c6e1237fb5ca2563f7e72b66ac0c40ff7a714
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M MAINTAINERS

  Log Message:
  -----------
  MAINTAINERS: PPC: add a XIVE section

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 891ff9f4a371da2dbd5244590eb35e8d803e18d8
      
https://github.com/qemu/qemu/commit/891ff9f4a371da2dbd5244590eb35e8d803e18d8
  Author: Peter Maydell <address@hidden>
  Date:   2018-12-21 (Fri, 21 Dec 2018)

  Changed paths:
    M MAINTAINERS
    M default-configs/ppc64-softmmu.mak
    M disas/ppc.c
    M hw/intc/Makefile.objs
    A hw/intc/spapr_xive.c
    M hw/intc/xics_spapr.c
    A hw/intc/xive.c
    M hw/ppc/e500.c
    M hw/ppc/mac_newworld.c
    M hw/ppc/ppc405_boards.c
    M hw/ppc/ppc405_uc.c
    M hw/ppc/ppc440_bamboo.c
    M hw/ppc/sam460ex.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c
    M hw/ppc/spapr_iommu.c
    M hw/ppc/spapr_irq.c
    M hw/ppc/spapr_rtas_ddw.c
    M hw/ppc/spapr_vio.c
    M hw/ppc/virtex_ml507.c
    M include/hw/ppc/openpic.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_irq.h
    A include/hw/ppc/spapr_xive.h
    M include/hw/ppc/xics.h
    A include/hw/ppc/xive.h
    A include/hw/ppc/xive_regs.h
    M target/ppc/cpu.h
    M target/ppc/translate.c
    M target/ppc/translate/vmx-ops.inc.c
    M target/ppc/translate_init.inc.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20181221' into 
staging

ppc patch queue 2018-12-21

This pull request supersedes the one from 2018-12-13.

This is a revised first ppc pull request for qemu-4.0.  Highlights
are:

 * Most of the code for the POWER9 "XIVE" interrupt controller
   (not complete yet, but we're getting there)
 * A number of g_new vs. g_malloc cleanups
 * Some IRQ wiring cleanups
 * A fix for how we advertise NUMA nodes to the guest for pseries

# gpg: Signature made Fri 21 Dec 2018 05:34:12 GMT
# gpg:                using RSA key 6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-4.0-20181221: (40 commits)
  MAINTAINERS: PPC: add a XIVE section
  spapr: change default CPU type to POWER9
  spapr: introduce an 'ic-mode' machine option
  spapr: add an extra OV5 field to the sPAPR IRQ backend
  spapr: add a 'reset' method to the sPAPR IRQ backend
  spapr: extend the sPAPR IRQ backend for XICS migration
  spapr: allocate the interrupt thread context under the CPU core
  spapr: add device tree support for the XIVE exploitation mode
  spapr: add hcalls support for the XIVE exploitation interrupt mode
  spapr: introduce a new machine IRQ backend for XIVE
  spapr-iommu: Always advertise the maximum possible DMA window size
  spapr/xive: use the VCPU id as a NVT identifier
  spapr/xive: introduce a XIVE interrupt controller
  ppc/xive: notify the CPU when the interrupt priority is more privileged
  ppc/xive: introduce a simplified XIVE presenter
  ppc/xive: introduce the XIVE interrupt thread context
  ppc/xive: add support for the END Event State Buffers
  Changes requirement for "vsubsbs" instruction
  spapr: export and rename the xics_max_server_number() routine
  spapr: introduce a spapr_irq_init() routine
  ...

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/15763776bfc1...891ff9f4a371
      **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]