1. 29 1月, 2018 4 次提交
    • S
      target/ppc/spapr_caps: Add new tristate cap safe_cache · 8f38eaf8
      Suraj Jitindar Singh 提交于
      Add new tristate cap cap-cfpc to represent the cache flush on privilege
      change capability.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      8f38eaf8
    • S
      target/ppc/spapr_caps: Add support for tristate spapr_capabilities · 6898aed7
      Suraj Jitindar Singh 提交于
      spapr_caps are used to represent the level of support for various
      capabilities related to the spapr machine type. Currently there is
      only support for boolean capabilities.
      
      Add support for tristate capabilities by implementing their get/set
      functions. These capabilities can have the values 0, 1 or 2
      corresponding to broken, workaround and fixed.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      6898aed7
    • S
      target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] · 8acc2ae5
      Suraj Jitindar Singh 提交于
      Add three new kvm capabilities used to represent the level of host support
      for three corresponding workarounds.
      
      Host support for each of the capabilities is queried through the
      new ioctl KVM_PPC_GET_CPU_CHAR which returns four uint64 quantities. The
      first two, character and behaviour, represent the available
      characteristics of the cpu and the behaviour of the cpu respectively.
      The second two, c_mask and b_mask, represent the mask of known bits for
      the character and beheviour dwords respectively.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      [dwg: Correct some compile errors due to name change in final kernel
       patch version]
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      8acc2ae5
    • G
      spapr_pci: fix MSI/MSIX selection · 9cbe305b
      Greg Kurz 提交于
      In various place we don't correctly check if the device supports MSI or
      MSI-X. This can cause devices to be advertised with MSI support, even
      if they only support MSI-X (like virtio-pci-* devices for example):
      
                      ethernet@0 {
                              ibm,req#msi = <0x1>; <--- wrong!
      			.
      			ibm,loc-code = "qemu_virtio-net-pci:0000:00:00.0";
      			.
      			ibm,req#msi-x = <0x3>;
                      };
      
      Worse, this can also cause the "ibm,change-msi" RTAS call to corrupt the
      PCI status and cause migration to fail:
      
        qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x6
          read: 0 device: 10 cmask: 10 wmask: 0 w1cmask:0
                                    ^^
                 PCI_STATUS_CAP_LIST bit which is assumed to be constant
      
      This patch changes spapr_populate_pci_child_dt() to properly check for
      MSI support using msi_present(): this ensures that PCIDevice::msi_cap
      was set by msi_init() and that msi_nr_vectors_allocated() will look at
      the right place in the config space.
      
      Checking PCIDevice::msix_entries_nr is enough for MSI-X but let's add
      a call to msix_present() there as well for consistency.
      
      It also changes rtas_ibm_change_msi() to select the appropriate MSI
      type in Function 1 instead of always selecting plain MSI. This new
      behaviour is compliant with LoPAPR 1.1, as described in "Table 71.
      ibm,change-msi Argument Call Buffer":
      
        Function 1: If Number Outputs is equal to 3, request to set to a new
                 number of MSIs (including set to 0).
                 If the “ibm,change-msix-capable” property exists and Number
                 Outputs is equal to 4, request is to set to a new number of
                 MSI or MSI-X (platform choice) interrupts (including set to
                 0).
      
      Since MSI is the the platform default (LoPAPR 6.2.3 MSI Option), let's
      check for MSI support first.
      
      And finally, it checks the input parameters are valid, as described in
      LoPAPR 1.1 "R1–7.3.10.5.1–3":
      
        For the MSI option: The platform must return a Status of -3 (Parameter
        error) from ibm,change-msi, with no change in interrupt assignments if
        the PCI configuration address does not support MSI and Function 3 was
        requested (that is, the “ibm,req#msi” property must exist for the PCI
        configuration address in order to use Function 3), or does not support
        MSI-X and Function 4 is requested (that is, the “ibm,req#msi-x” property
        must exist for the PCI configuration address in order to use Function 4),
        or if neither MSIs nor MSI-Xs are supported and Function 1 is requested.
      
      This ensures that the ret_intr_type variable contains a valid MSI type
      for this device, and that spapr_msi_setmsg() won't corrupt the PCI status.
      Signed-off-by: NGreg Kurz <groug@kaod.org>
      Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      9cbe305b
  2. 27 1月, 2018 5 次提交
  3. 26 1月, 2018 22 次提交
  4. 25 1月, 2018 9 次提交