* [PATCH RFC 24/77] cxgb3: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 29 ++++++++++++-----------
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 915729c..bf14fd6 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3090,25 +3090,26 @@ static int cxgb_enable_msix(struct adapter *adap)
int vectors;
int i, err;
- vectors = ARRAY_SIZE(entries);
+ err = pci_msix_table_size(adap->pdev);
+ if (err < 0)
+ return err;
+
+ vectors = min_t(int, err, ARRAY_SIZE(entries));
+ if (vectors < (adap->params.nports + 1))
+ return -ENOSPC;
+
for (i = 0; i < vectors; ++i)
entries[i].entry = i;
- while ((err = pci_enable_msix(adap->pdev, entries, vectors)) > 0)
- vectors = err;
-
- if (!err && vectors < (adap->params.nports + 1)) {
- pci_disable_msix(adap->pdev);
- err = -ENOSPC;
- }
+ err = pci_enable_msix(adap->pdev, entries, vectors);
+ if (err)
+ return err;
- if (!err) {
- for (i = 0; i < vectors; ++i)
- adap->msix_info[i].vec = entries[i].vector;
- adap->msix_nvectors = vectors;
- }
+ for (i = 0; i < vectors; ++i)
+ adap->msix_info[i].vec = entries[i].vector;
+ adap->msix_nvectors = vectors;
- return err;
+ return 0;
}
static void print_port_info(struct adapter *adap, const struct adapter_info *ai)
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 21/77] csiostor: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/scsi/csiostor/csio_isr.c | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index abf20ab..b8a840e 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -512,6 +512,16 @@ csio_enable_msix(struct csio_hw *hw)
if (hw->flags & CSIO_HWF_USING_SOFT_PARAMS || !csio_is_hw_master(hw))
cnt = min_t(uint8_t, hw->cfg_niq, cnt);
+ rv = pci_msix_table_size(hw->pdev);
+ if (rv < 0)
+ return rv;
+
+ cnt = min(cnt, rv);
+ if (cnt < min) {
+ csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
+ return -ENOSPC;
+ }
+
entries = kzalloc(sizeof(struct msix_entry) * cnt, GFP_KERNEL);
if (!entries)
return -ENOMEM;
@@ -521,19 +531,15 @@ csio_enable_msix(struct csio_hw *hw)
csio_dbg(hw, "FW supp #niq:%d, trying %d msix's\n", hw->cfg_niq, cnt);
- while ((rv = pci_enable_msix(hw->pdev, entries, cnt)) >= min)
- cnt = rv;
+ rv = pci_enable_msix(hw->pdev, entries, cnt);
if (!rv) {
if (cnt < (hw->num_sqsets + extra)) {
csio_dbg(hw, "Reducing sqsets to %d\n", cnt - extra);
csio_reduce_sqsets(hw, cnt - extra);
}
} else {
- if (rv > 0)
- csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
-
kfree(entries);
- return -ENOSPC;
+ return rv;
}
/* Save off vectors */
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 57/77] pmcraid: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/scsi/pmcraid.c | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 1eb7b028..5c62d22 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4680,24 +4680,23 @@ pmcraid_register_interrupt_handler(struct pmcraid_instance *pinstance)
if ((pmcraid_enable_msix) &&
(pci_find_capability(pdev, PCI_CAP_ID_MSIX))) {
- int num_hrrq = PMCRAID_NUM_MSIX_VECTORS;
struct msix_entry entries[PMCRAID_NUM_MSIX_VECTORS];
+ int num_hrrq = ARRAY_SIZE(entries);
int i;
- for (i = 0; i < PMCRAID_NUM_MSIX_VECTORS; i++)
- entries[i].entry = i;
-
- rc = pci_enable_msix(pdev, entries, num_hrrq);
- if (rc < 0)
- goto pmcraid_isr_legacy;
/* Check how many MSIX vectors are allocated and register
* msi-x handlers for each of them giving appropriate buffer
*/
- if (rc > 0) {
- num_hrrq = rc;
- if (pci_enable_msix(pdev, entries, num_hrrq))
- goto pmcraid_isr_legacy;
- }
+ rc = pci_msix_table_size(pdev);
+ if (rc < 0)
+ goto pmcraid_isr_legacy;
+
+ num_hrrq = min(num_hrrq, rc);
+ for (i = 0; i < num_hrrq; i++)
+ entries[i].entry = i;
+
+ if (pci_enable_msix(pdev, entries, num_hrrq))
+ goto pmcraid_isr_legacy;
for (i = 0; i < num_hrrq; i++) {
pinstance->hrrq_vector[i].hrrq_id = i;
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 16/77] cciss: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/block/cciss.c | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index d2d95ff..80068a0 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4079,7 +4079,11 @@ static void cciss_interrupt_mode(ctlr_info_t *h)
goto default_int_mode;
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSIX)) {
- err = pci_enable_msix(h->pdev, cciss_msix_entries, 4);
+ err = pci_msix_table_size(h->pdev);
+ if (err < ARRAY_SIZE(cciss_msix_entries))
+ goto default_int_mode;
+ err = pci_enable_msix(h->pdev, cciss_msix_entries,
+ ARRAY_SIZE(cciss_msix_entries));
if (!err) {
h->intr[0] = cciss_msix_entries[0].vector;
h->intr[1] = cciss_msix_entries[1].vector;
@@ -4088,15 +4092,8 @@ static void cciss_interrupt_mode(ctlr_info_t *h)
h->msix_vector = 1;
return;
}
- if (err > 0) {
- dev_warn(&h->pdev->dev,
- "only %d MSI-X vectors available\n", err);
- goto default_int_mode;
- } else {
- dev_warn(&h->pdev->dev,
- "MSI-X init failed %d\n", err);
- goto default_int_mode;
- }
+ dev_warn(&h->pdev->dev, "MSI-X init failed %d\n", err);
+ goto default_int_mode;
}
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
if (!pci_enable_msi(h->pdev))
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 46/77] mlx4: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 60c9f4f..377a5ea 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -1852,8 +1852,16 @@ static void mlx4_enable_msi_x(struct mlx4_dev *dev)
int i;
if (msi_x) {
+ err = pci_msix_table_size(dev->pdev);
+ if (err < 0)
+ goto no_msi;
+
+ /* Try if at least 2 vectors are available */
nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs,
nreq);
+ nreq = min_t(int, nreq, err);
+ if (nreq < 2)
+ goto no_msi;
entries = kcalloc(nreq, sizeof *entries, GFP_KERNEL);
if (!entries)
@@ -1862,17 +1870,8 @@ static void mlx4_enable_msi_x(struct mlx4_dev *dev)
for (i = 0; i < nreq; ++i)
entries[i].entry = i;
- retry:
err = pci_enable_msix(dev->pdev, entries, nreq);
if (err) {
- /* Try again if at least 2 vectors are available */
- if (err > 1) {
- mlx4_info(dev, "Requested %d vectors, "
- "but only %d MSI-X vectors available, "
- "trying again\n", nreq, err);
- nreq = err;
- goto retry;
- }
kfree(entries);
goto no_msi;
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 42/77] lpfc: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Note, in case just one MSI-X vector was available the
error message "0484 PCI enable MSI-X failed 1" is
preserved to not break tools which might depend on it.
Also, not sure why in case of multiple MSI-Xs mode failed
the driver skips the single MSI-X mode and falls back to
single MSI mode.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/scsi/lpfc/lpfc_init.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 0803b84..d83a1a3 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8639,13 +8639,17 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
/* Configure MSI-X capability structure */
vectors = phba->cfg_fcp_io_channel;
-enable_msix_vectors:
- rc = pci_enable_msix(phba->pcidev, phba->sli4_hba.msix_entries,
- vectors);
- if (rc > 1) {
- vectors = rc;
- goto enable_msix_vectors;
- } else if (rc) {
+
+ rc = pci_msix_table_size(phba->pcidev);
+ if (rc < 0)
+ goto msg_fail_out;
+
+ vectors = min(vectors, rc);
+ if (vectors > 1)
+ rc = pci_enable_msix(phba->pcidev, phba->sli4_hba.msix_entries,
+ vectors);
+ if (rc) {
+msg_fail_out:
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0484 PCI enable MSI-X failed (%d)\n", rc);
goto vec_fail_out;
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 15/77] bnx2: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 27 ++++++++++++++-------------
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index e838a3f..c902627 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -6202,25 +6202,26 @@ bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
* is setup properly */
BNX2_RD(bp, BNX2_PCI_MSIX_CONTROL);
- for (i = 0; i < BNX2_MAX_MSIX_VEC; i++) {
- msix_ent[i].entry = i;
- msix_ent[i].vector = 0;
- }
-
total_vecs = msix_vecs;
#ifdef BCM_CNIC
total_vecs++;
#endif
- rc = -ENOSPC;
- while (total_vecs >= BNX2_MIN_MSIX_VEC) {
- rc = pci_enable_msix(bp->pdev, msix_ent, total_vecs);
- if (rc <= 0)
- break;
- if (rc > 0)
- total_vecs = rc;
+ rc = pci_msix_table_size(bp->pdev);
+ if (rc < 0)
+ return;
+
+ total_vecs = min(total_vecs, rc);
+ if (total_vecs < BNX2_MIN_MSIX_VEC)
+ return;
+
+ BUG_ON(total_vecs > ARRAY_SIZE(msix_ent));
+ for (i = 0; i < total_vecs; i++) {
+ msix_ent[i].entry = i;
+ msix_ent[i].vector = 0;
}
- if (rc != 0)
+ rc = pci_enable_msix(bp->pdev, msix_ent, total_vecs);
+ if (rc)
return;
msix_vecs = total_vecs;
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 45/77] megaraid: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 3020921..b5973e4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3727,18 +3727,16 @@ static int megasas_init_fw(struct megasas_instance *instance)
(unsigned int)num_online_cpus());
for (i = 0; i < instance->msix_vectors; i++)
instance->msixentry[i].entry = i;
- i = pci_enable_msix(instance->pdev, instance->msixentry,
- instance->msix_vectors);
- if (i >= 0) {
- if (i) {
- if (!pci_enable_msix(instance->pdev,
- instance->msixentry, i))
- instance->msix_vectors = i;
- else
- instance->msix_vectors = 0;
- }
- } else
+ i = pci_msix_table_size(instance->pdev);
+ if (i < 0) {
instance->msix_vectors = 0;
+ } else {
+ if (!pci_enable_msix(instance->pdev,
+ instance->msixentry, i))
+ instance->msix_vectors = i;
+ else
+ instance->msix_vectors = 0;
+ }
dev_info(&instance->pdev->dev, "[scsi%d]: FW supports"
"<%d> MSIX vector,Online CPUs: <%d>,"
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 59/77] qla2xxx: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/scsi/qla2xxx/qla_isr.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index df1b30b..6c11ab9 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2836,16 +2836,20 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct rsp_que *rsp)
for (i = 0; i < ha->msix_count; i++)
entries[i].entry = i;
- ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
- if (ret) {
+ ret = pci_msix_table_size(ha->pdev);
+ if (ret < 0) {
+ goto msix_failed;
+ } else {
if (ret < MIN_MSIX_COUNT)
goto msix_failed;
- ql_log(ql_log_warn, vha, 0x00c6,
- "MSI-X: Failed to enable support "
- "-- %d/%d\n Retry with %d vectors.\n",
- ha->msix_count, ret, ret);
- ha->msix_count = ret;
+ if (ret < ha->msix_count) {
+ ql_log(ql_log_warn, vha, 0x00c6,
+ "MSI-X: Failed to enable support "
+ "-- %d/%d\n Retry with %d vectors.\n",
+ ha->msix_count, ret, ret);
+ ha->msix_count = ret;
+ }
ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
if (ret) {
msix_failed:
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 70/77] vmci: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/misc/vmw_vmci/vmci_guest.c | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c b/drivers/misc/vmw_vmci/vmci_guest.c
index b3a2b76..af5caf8 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -377,19 +377,27 @@ static int vmci_enable_msix(struct pci_dev *pdev,
{
int i;
int result;
+ int nvec;
- for (i = 0; i < VMCI_MAX_INTRS; ++i) {
+ result = pci_msix_table_size(pdev);
+ if (result < 0)
+ return result;
+
+ nvec = min(result, VMCI_MAX_INTRS);
+ if (nvec < VMCI_MAX_INTRS)
+ nvec = 1;
+
+ for (i = 0; i < nvec; ++i) {
vmci_dev->msix_entries[i].entry = i;
vmci_dev->msix_entries[i].vector = i;
}
- result = pci_enable_msix(pdev, vmci_dev->msix_entries, VMCI_MAX_INTRS);
- if (result == 0)
- vmci_dev->exclusive_vectors = true;
- else if (result > 0)
- result = pci_enable_msix(pdev, vmci_dev->msix_entries, 1);
+ result = pci_enable_msix(pdev, vmci_dev->msix_entries, nvec);
+ if (result)
+ return result;
- return result;
+ vmci_dev->exclusive_vectors = true;
+ return 0;
}
/*
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 51/77] mthca: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/infiniband/hw/mthca/mthca_main.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_main.c b/drivers/infiniband/hw/mthca/mthca_main.c
index 87897b9..3d44ca4 100644
--- a/drivers/infiniband/hw/mthca/mthca_main.c
+++ b/drivers/infiniband/hw/mthca/mthca_main.c
@@ -854,17 +854,23 @@ static int mthca_enable_msi_x(struct mthca_dev *mdev)
struct msix_entry entries[3];
int err;
+ err = pci_msix_table_size(mdev->pdev);
+ if (err < 0)
+ return err;
+ if (err < ARRAY_SIZE(entries)) {
+ mthca_info(mdev, "Only %d MSI-X vectors available, "
+ "not using MSI-X\n", err);
+
+ return -ENOSPC;
+ }
+
entries[0].entry = 0;
entries[1].entry = 1;
entries[2].entry = 2;
err = pci_enable_msix(mdev->pdev, entries, ARRAY_SIZE(entries));
- if (err) {
- if (err > 0)
- mthca_info(mdev, "Only %d MSI-X vectors available, "
- "not using MSI-X\n", err);
+ if (err)
return err;
- }
mdev->eq_table.eq[MTHCA_EQ_COMP ].msi_x_vector = entries[0].vector;
mdev->eq_table.eq[MTHCA_EQ_ASYNC].msi_x_vector = entries[1].vector;
--
1.7.7.6
^ permalink raw reply related
* [PATCH RFC 52/77] niu: Update MSI/MSI-X interrupts enablement code
From: Alexander Gordeev @ 2013-10-02 10:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Alexander Gordeev,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Ingo Molnar,
Solarflare linux maintainers, netdev, Ralf Baechle, e1000-devel,
Martin Schwidefsky, linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
---
drivers/net/ethernet/sun/niu.c | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index f28460c..54c41b9 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -9051,26 +9051,28 @@ static void niu_try_msix(struct niu *np, u8 *ldg_num_map)
(np->port == 0 ? 3 : 1));
BUG_ON(num_irqs > (NIU_NUM_LDG / parent->num_ports));
-retry:
+ err = pci_msix_table_size(pdev);
+ if (err < 0)
+ goto fail;
+
+ num_irqs = min(num_irqs, err);
for (i = 0; i < num_irqs; i++) {
msi_vec[i].vector = 0;
msi_vec[i].entry = i;
}
err = pci_enable_msix(pdev, msi_vec, num_irqs);
- if (err < 0) {
- np->flags &= ~NIU_FLAGS_MSIX;
- return;
- }
- if (err > 0) {
- num_irqs = err;
- goto retry;
- }
+ if (err)
+ goto fail;
np->flags |= NIU_FLAGS_MSIX;
for (i = 0; i < num_irqs; i++)
np->ldg[i].irq = msi_vec[i].vector;
np->num_ldg = num_irqs;
+ return;
+
+fail:
+ np->flags &= ~NIU_FLAGS_MSIX;
}
static int niu_n2_irq_init(struct niu *np, u8 *ldg_num_map)
--
1.7.7.6
^ permalink raw reply related
* Re: Avoiding the dentry d_lock on final dput(), part deux: transactional memory
From: Andi Kleen @ 2013-10-02 14:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Waiman Long, Peter Zijlstra, Norton, Scott J, George Spelvin,
Linux Kernel Mailing List, Chandramouleeswaran, Aswin,
linux-fsdevel, ppc-dev, Ingo Molnar
In-Reply-To: <CA+55aFw6tOVMw=pKE_knj4BOwTi_JAX=4N=-5_WduykNPotdww@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 30, 2013 at 1:01 PM, Waiman Long <waiman.long@hp.com> wrote:
>>
>> I think this patch is worth a trial if relevant hardware is more widely
>> available. The TSX code certainly need to be moved to an architecture
>> specific area and should be runtime enabled using a static key. We also need
>> more TSX support infrastructure in place first.
>
> I think we can pick that up from Andi's patches, he should have that.
> Although that did have very x86-specific naming (ie "xbegin"). And I
> don't think he used "asm goto" to quite the same advantage as this -
> and I think we do want to make sure that the overhead is minimal.
FWIW my version #0 used asm goto directly, but I later switched to not
using it to support more compilers and higher level abstractions (locks
etc.) and use the same intrinsics as the user level guys are using.
The two extra instructions from not using asm goto for xbegin
don't matter all that much in the end.
That's the old asm goto stuff I wrote originally
(user level version):
https://github.com/andikleen/tsx-tools/blob/master/include/rtm-goto.h
There was also a kernel version of it that patched, right
now this is done in the main TSX patchkit like this:
https://git.kernel.org/cgit/linux/kernel/git/ak/linux-misc.git/commit/?h=hle312/rtm-base&id=9190346d57a9bc89e746aee774d07e54cd1e6e75
Essentially without RTM it just becomes and unconditional jump
to the abort handler, xabort is a nop, and xtest always returns 0.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* [PATCH] kvm: powerpc: book3s: Fix build break for BOOK3S_32
From: Aneesh Kumar K.V @ 2013-10-02 14:38 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
This was introduced by 85a0d845d8bb5df5d2669416212f56cbe1474c6b
arch/powerpc/kvm/book3s_pr.c: In function 'kvmppc_core_vcpu_create':
arch/powerpc/kvm/book3s_pr.c:1182:30: error: 'struct kvmppc_vcpu_book3s' has no member named 'shadow_vcpu'
make[1]: *** [arch/powerpc/kvm/book3s_pr.o] Error 1
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_pr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 8941885..6075dbd 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1179,7 +1179,7 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
#ifdef CONFIG_KVM_BOOK3S_32
vcpu->arch.shadow_vcpu =
- kzalloc(sizeof(*vcpu_book3s->shadow_vcpu), GFP_KERNEL);
+ kzalloc(sizeof(*vcpu->arch.shadow_vcpu), GFP_KERNEL);
if (!vcpu->arch.shadow_vcpu)
goto free_vcpu3s;
#endif
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Paolo Bonzini @ 2013-10-02 14:38 UTC (permalink / raw)
To: Alexander Graf
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm
In-Reply-To: <C4834CF8-F81C-4B82-B1A7-1751D50AADB7@suse.de>
Il 02/10/2013 16:36, Alexander Graf ha scritto:
>> >
>> > With Michael's earlier patch in this series, the hwrng is accessible by
>> > host userspace via /dev/hwrng, no?
> Yes, but there's not token from user space that gets passed into the
> kernel to check whether access is ok or not. So while QEMU may not have
> permission to open /dev/hwrng it could spawn a guest that opens it,
> drains all entropy out of it and thus stall other processes which try to
> fetch entropy, no?
>
> Maybe I haven't fully grasped the interface yet though :).
Yes, that's right. I don't think it's a huge problem, but it's another
point in favor of just doing the hypercall in userspace.
Paolo
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-02 14:37 UTC (permalink / raw)
To: Paolo Bonzini
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm
In-Reply-To: <524C2EAE.7090209@redhat.com>
On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
> Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > > The hwrng is accessible by host userspace via /dev/mem.
> >
> > A guest should live on the same permission level as a user space
> > application. If you run QEMU as UID 1000 without access to /dev/mem, why
> > should the guest suddenly be able to directly access a memory location
> > (MMIO) it couldn't access directly through a normal user space interface.
> >
> > It's basically a layering violation.
>
> With Michael's earlier patch in this series, the hwrng is accessible by
> host userspace via /dev/hwrng, no?
>
Access to which can be controlled by its permission. Permission of
/dev/kvm may be different. If we route hypercall via userspace and
configure qemu to get entropy from /dev/hwrng everything will fall
nicely together (except performance).
--
Gleb.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Alexander Graf @ 2013-10-02 14:36 UTC (permalink / raw)
To: Paolo Bonzini
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm
In-Reply-To: <524C2EAE.7090209@redhat.com>
On 02.10.2013, at 16:33, Paolo Bonzini wrote:
> Il 02/10/2013 16:08, Alexander Graf ha scritto:
>>> The hwrng is accessible by host userspace via /dev/mem.
>>=20
>> A guest should live on the same permission level as a user space
>> application. If you run QEMU as UID 1000 without access to /dev/mem, =
why
>> should the guest suddenly be able to directly access a memory =
location
>> (MMIO) it couldn't access directly through a normal user space =
interface.
>>=20
>> It's basically a layering violation.
>=20
> With Michael's earlier patch in this series, the hwrng is accessible =
by
> host userspace via /dev/hwrng, no?
Yes, but there's not token from user space that gets passed into the =
kernel to check whether access is ok or not. So while QEMU may not have =
permission to open /dev/hwrng it could spawn a guest that opens it, =
drains all entropy out of it and thus stall other processes which try to =
fetch entropy, no?
Maybe I haven't fully grasped the interface yet though :).
Alex
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Paolo Bonzini @ 2013-10-02 14:33 UTC (permalink / raw)
To: Alexander Graf
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm
In-Reply-To: <029A8D6C-C23C-42B2-8C26-D76B59E2C9DD@suse.de>
Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > The hwrng is accessible by host userspace via /dev/mem.
>
> A guest should live on the same permission level as a user space
> application. If you run QEMU as UID 1000 without access to /dev/mem, why
> should the guest suddenly be able to directly access a memory location
> (MMIO) it couldn't access directly through a normal user space interface.
>
> It's basically a layering violation.
With Michael's earlier patch in this series, the hwrng is accessible by
host userspace via /dev/hwrng, no?
Paolo
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-02 14:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <1380722275.12149.28.camel@concordia>
On Wed, Oct 02, 2013 at 11:57:55PM +1000, Michael Ellerman wrote:
> On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> > On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
> > >
> > > On 02.10.2013, at 11:11, Alexander Graf wrote:
> > >
> > > So how do you solve live migration between a kernel that has this patch and one that doesn't?
> > >
> > Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> > interface is disabled?
>
> Yes that is a valid point.
>
> We can't disable the interface at runtime, the guest detects its
> presence at boot.
>
> What will happen is the hcall will come through to QEMU, which will
> reject it with H_FUNCTION (~= ENOSYS).
>
> The current pseries-rng driver does not handle that case well, which is
> exactly why I sent patches to fix it recently.
>
> The only other option would be to feed it with /dev/random.
>
What about other way, if guest migrates from kvm that has no this
hypercall to one that has? We try to not change HW under guest during
migration.
> > Also hwrnd is MMIO in a host why guest needs to
> > use hypercall instead of emulating the device (in kernel or somewhere
> > else?).
>
> Because PAPR is a platform specification and it specifies that the
> interface is a hypervisor call. We can't just decide we want to do it
> differently.
Any insights on why it was specified this what. What is special about
hwrnd device that hypercall is needed to access it? I got that you didn't
just decide to implement it that way :) Also what will happen if guest
will find emulated hwrnd device, will it use it?
>
> > Another things is that on a host hwrnd is protected from
> > direct userspace access by virtue of been a device, but guest code (event
> > kernel mode) is userspace as far as hosts security model goes, so by
> > implementing this hypercall in a way that directly access hwrnd you
> > expose hwrnd to a userspace unconditionally. Why is this a good idea?
>
> I'm not sure I follow you.
>
> The hwrng is accessible by host userspace via /dev/mem.
>
Regular user has no access to /dev/mem, but he can start kvm guest and
gain access to the device.
--
Gleb.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Alexander Graf @ 2013-10-02 14:08 UTC (permalink / raw)
To: Michael Ellerman
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <1380722275.12149.28.camel@concordia>
On 02.10.2013, at 15:57, Michael Ellerman wrote:
> On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
>> On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
>>>=20
>>> On 02.10.2013, at 11:11, Alexander Graf wrote:
>>>=20
>>> So how do you solve live migration between a kernel that has this =
patch and one that doesn't?
>>>=20
>> Yes, I alluded to it in my email to Paul and Paolo asked also. How =
this
>> interface is disabled?=20
>=20
> Yes that is a valid point.
>=20
> We can't disable the interface at runtime, the guest detects its
> presence at boot.
>=20
> What will happen is the hcall will come through to QEMU, which will
> reject it with H_FUNCTION (~=3D ENOSYS).
>=20
> The current pseries-rng driver does not handle that case well, which =
is
> exactly why I sent patches to fix it recently.
>=20
> The only other option would be to feed it with /dev/random.
>=20
>> Also hwrnd is MMIO in a host why guest needs to
>> use hypercall instead of emulating the device (in kernel or somewhere
>> else?).=20
>=20
> Because PAPR is a platform specification and it specifies that the
> interface is a hypervisor call. We can't just decide we want to do it
> differently.
>=20
>> Another things is that on a host hwrnd is protected from
>> direct userspace access by virtue of been a device, but guest code =
(event
>> kernel mode) is userspace as far as hosts security model goes, so by
>> implementing this hypercall in a way that directly access hwrnd you
>> expose hwrnd to a userspace unconditionally. Why is this a good idea?=20=
>=20
> I'm not sure I follow you.
>=20
> The hwrng is accessible by host userspace via /dev/mem.
A guest should live on the same permission level as a user space =
application. If you run QEMU as UID 1000 without access to /dev/mem, why =
should the guest suddenly be able to directly access a memory location =
(MMIO) it couldn't access directly through a normal user space =
interface.
It's basically a layering violation.
Alex
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Michael Ellerman @ 2013-10-02 13:57 UTC (permalink / raw)
To: Gleb Natapov
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <20131002100224.GF17294@redhat.com>
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
> >
> > On 02.10.2013, at 11:11, Alexander Graf wrote:
> >
> > So how do you solve live migration between a kernel that has this patch and one that doesn't?
> >
> Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> interface is disabled?
Yes that is a valid point.
We can't disable the interface at runtime, the guest detects its
presence at boot.
What will happen is the hcall will come through to QEMU, which will
reject it with H_FUNCTION (~= ENOSYS).
The current pseries-rng driver does not handle that case well, which is
exactly why I sent patches to fix it recently.
The only other option would be to feed it with /dev/random.
> Also hwrnd is MMIO in a host why guest needs to
> use hypercall instead of emulating the device (in kernel or somewhere
> else?).
Because PAPR is a platform specification and it specifies that the
interface is a hypervisor call. We can't just decide we want to do it
differently.
> Another things is that on a host hwrnd is protected from
> direct userspace access by virtue of been a device, but guest code (event
> kernel mode) is userspace as far as hosts security model goes, so by
> implementing this hypercall in a way that directly access hwrnd you
> expose hwrnd to a userspace unconditionally. Why is this a good idea?
I'm not sure I follow you.
The hwrng is accessible by host userspace via /dev/mem.
cheers
^ permalink raw reply
* Re: [PATCH 1/2][v7] powerpc/mpc85xx:Add initial device tree support of T104x
From: Prabhakar Kushwaha @ 2013-10-02 12:31 UTC (permalink / raw)
To: Scott Wood; +Cc: Varun Sethi, linuxppc-dev, Poonam Aggrwal, Priyanka Jain
In-Reply-To: <1380657408.10618.52.camel@snotra.buserror.net>
On 10/02/2013 01:26 AM, Scott Wood wrote:
> On Tue, 2013-10-01 at 08:56 +0530, Prabhakar Kushwaha wrote:
>> On 10/01/2013 01:17 AM, Scott Wood wrote:
>>> On Mon, 2013-09-30 at 12:24 +0530, Prabhakar Kushwaha wrote:
>>>> - Removed l2switch. It will be added later
>>> Why?
>> I am not aware of bindings required for l2switch as we are not working
>> on the driver.
>> Earlier I thought of putting a place holder. but as you suggested to put
>> bindings in documentation.
>> It will be good if it is put by actual driver owner.
> Is there a reason to believe the binding will be complicated?
>
> Does any such "driver owner" exist yet?
I don't know, as I am unaware of l2switch driver.
>
>>>> +sata@220000 {
>>>> + fsl,iommu-parent = <&pamu0>;
>>>> + fsl,liodn-reg = <&guts 0x550>; /* SATA1LIODNR */
>>>> +};
>>>> +/include/ "qoriq-sata2-1.dtsi"
>>>> +sata@221000 {
>>>> + fsl,iommu-parent = <&pamu0>;
>>>> + fsl,liodn-reg = <&guts 0x554>; /* SATA2LIODNR */
>>>> +};
>>> Whitespace
>> do we have any scripts which check for whitespace as checkpatch never
>> give any warning/error.
>> it is a very silly mistake which I am doing continuously :(
> checkpatch doesn't check dts files.
Manual check :(
>>>> +/include/ "t1040si-post.dtsi"
>>> Should at least have a comment indicating that eventually this should
>>> hold the l2 switch node.
>> yes. Ideally it should be.
>> but if I put a comment then I believe this patch will not be completed.
>> it will think as a RFC.
>> as I believe putting of TODO is generally for RFC patches.
> As is, one would wonder why the separate file exists at all.
>
> The TODO is there whether you have a comment acknowledging it or
> not. :-)
>
>
I agree. I will add a comments.
Regards,
Prabhakar
^ permalink raw reply
* Re: [PATCH] powerpc/iommu: use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table()
From: Thadeu Lima de Souza Cascardo @ 2013-10-02 12:32 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, Anton Blanchard, Paul Mackerras
In-Reply-To: <20131001210453.GB4065@linux.vnet.ibm.com>
On Tue, Oct 01, 2013 at 02:04:53PM -0700, Nishanth Aravamudan wrote:
> Under heavy (DLPAR?) stress, we tripped this panic() in
> arch/powerpc/kernel/iommu.c::iommu_init_table():
>
> page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
> if (!page)
> panic("iommu_init_table: Can't allocate %ld bytes\n",
> sz);
>
> Before the panic() we got a page allocation failure for an order-2
> allocation. There appears to be memory free, but perhaps not in the
> ATOMIC context. I looked through all the call-sites of
> iommu_init_table() and didn't see any obvious reason to need an ATOMIC
> allocation. Most call-sites in fact have an explicit GFP_KERNEL
> allocation shortly before the call to iommu_init_table(), indicating we
> are not in an atomic context. There is some indirection for some paths,
> but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
>
> With this change under the same conditions, we have not been able to
> reproduce the panic.
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 0adab06..572bb5b 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -661,7 +661,7 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> /* number of bytes needed for the bitmap */
> sz = BITS_TO_LONGS(tbl->it_size) * sizeof(unsigned long);
>
> - page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
> + page = alloc_pages_node(nid, GFP_KERNEL, get_order(sz));
> if (!page)
> panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
> tbl->it_map = page_address(page);
I didn't respond to the previous message, but also checked if there were
any history on the logs, and found this was as it is from the start. I
also found no other reasons why it needs to be atomic. Therefore,
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-02 10:02 UTC (permalink / raw)
To: Alexander Graf
Cc: tytso, kvm, linuxppc-dev, linux-kernel, kvm-ppc, herbert,
Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <3CBF5732-E7EE-4C96-8132-6D7B77270DAF@suse.de>
On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
>
> On 02.10.2013, at 11:11, Alexander Graf wrote:
>
> >
> > On 02.10.2013, at 11:06, Benjamin Herrenschmidt wrote:
> >
> >> On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
> >>
> >>>
> >>> Thanks. Any chance you can give some numbers of a kernel hypercall and
> >>> a userspace hypercall on Power, so we have actual data? For example a
> >>> hypercall that returns H_PARAMETER as soon as possible.
> >>
> >> I don't have (yet) numbers at hand but we have basically 3 places where
> >> we can handle hypercalls:
> >>
> >> - Kernel real mode. This is where most of our MMU stuff goes for
> >> example unless it needs to trigger a page fault in Linux. This is
> >> executed with translation disabled and the MMU still in guest context.
> >> This is the fastest path since we don't take out the other threads nor
> >> perform any expensive context change. This is where we put the
> >> "accelerated" H_RANDOM as well.
> >>
> >> - Kernel virtual mode. That's a full exit, so all threads are out and
> >> MMU switched back to host Linux. Things like vhost MMIO emulation goes
> >> there, page faults, etc...
> >>
> >> - Qemu. This adds the round trip to userspace on top of the above.
> >
> > Right, and the difference for the patch in question is really whether we handle in in kernel virtual mode or in QEMU, so the bulk of the overhead (kicking threads out of guest context, switching MMU context, etc) happens either way.
> >
> > So the additional overhead when handling it in QEMU here really boils down to the user space roundtrip (plus another random number read roundtrip).
>
> Ah, sorry, I misread the patch. You're running the handler in real mode of course :).
>
> So how do you solve live migration between a kernel that has this patch and one that doesn't?
>
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall instead of emulating the device (in kernel or somewhere
else?). Another things is that on a host hwrnd is protected from
direct userspace access by virtue of been a device, but guest code (event
kernel mode) is userspace as far as hosts security model goes, so by
implementing this hypercall in a way that directly access hwrnd you
expose hwrnd to a userspace unconditionally. Why is this a good idea?
--
Gleb.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Alexander Graf @ 2013-10-02 9:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <668E4650-BC22-4CBF-A282-E7875DF29DB6@suse.de>
On 02.10.2013, at 11:11, Alexander Graf wrote:
>=20
> On 02.10.2013, at 11:06, Benjamin Herrenschmidt wrote:
>=20
>> On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
>>=20
>>>=20
>>> Thanks. Any chance you can give some numbers of a kernel hypercall =
and
>>> a userspace hypercall on Power, so we have actual data? For example =
a
>>> hypercall that returns H_PARAMETER as soon as possible.
>>=20
>> I don't have (yet) numbers at hand but we have basically 3 places =
where
>> we can handle hypercalls:
>>=20
>> - Kernel real mode. This is where most of our MMU stuff goes for
>> example unless it needs to trigger a page fault in Linux. This is
>> executed with translation disabled and the MMU still in guest =
context.
>> This is the fastest path since we don't take out the other threads =
nor
>> perform any expensive context change. This is where we put the
>> "accelerated" H_RANDOM as well.
>>=20
>> - Kernel virtual mode. That's a full exit, so all threads are out and
>> MMU switched back to host Linux. Things like vhost MMIO emulation =
goes
>> there, page faults, etc...
>>=20
>> - Qemu. This adds the round trip to userspace on top of the above.
>=20
> Right, and the difference for the patch in question is really whether =
we handle in in kernel virtual mode or in QEMU, so the bulk of the =
overhead (kicking threads out of guest context, switching MMU context, =
etc) happens either way.
>=20
> So the additional overhead when handling it in QEMU here really boils =
down to the user space roundtrip (plus another random number read =
roundtrip).
Ah, sorry, I misread the patch. You're running the handler in real mode =
of course :).
So how do you solve live migration between a kernel that has this patch =
and one that doesn't?
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox