date:20140414

Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect

2014-04-14 Thread Alexander Graf



On 13.04.14 04:27, Liu ping fan wrote:

On Fri, Apr 11, 2014 at 10:03 PM, Alexander Graf ag...@suse.de wrote:

On 11.04.2014, at 13:45, Liu Ping Fan pingf...@linux.vnet.ibm.com wrote:


When we mark pte with _PAGE_NUMA we already call 
mmu_notifier_invalidate_range_start
and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
guest hpte entries.

What happens when we don't? Why do we need the check? Why isn't it done 
implicitly? What happens when we treat a NUMA marked page as non-present? Why 
does it work out for us?

Assume you have no idea what PAGE_NUMA is, but try to figure out what this 
patch does and whether you need to cherry-pick it into your downstream kernel. 
The description as is still is not very helpful for that. It doesn't even 
explain what really changes with this patch applied.


Yeah.  what about appending the following description?  Can it make
the context clear?
Guest should not setup a hpte for the page whose pte is marked with
_PAGE_NUMA, so on the host, the numa-fault mechanism can take effect
to check whether the page is placed correctly or not.


Try to come up with a text that answers the following questions in order:

  - What does _PAGE_NUMA mean?
  - How does page migration with _PAGE_NUMA work?
  - Why should we not map pages when _PAGE_NUMA is set?
  - Which part of what needs to be done did the previous _PAGE_NUMA 
patch address?

  - What's the situation without this patch?
  - Which scenario does this patch fix?

Once you have a text that answers those, you should have a good patch 
description :).


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Change MINSIGSTKSZ and SIGSTKSIZE

2014-04-14 Thread Alan Modra

On Sat, Apr 12, 2014 at 02:59:55AM -0700, Haren Myneni wrote:
Alan,
LTP test (signalstack02) is failing.

Ignore the stupid test. Do *NOT* change the kernel value to match
glibc. The two sets of constants are independent.

The glibc constants are for user code, to allocate correctly sized
signal stacks for all known kernels. These constants are therefore
the maximum values needed for known kernels.

The kernel constants are to check that user code is setting up a large
enough signal stack *for that specific kernel, and user binary*. If
you make the kernel constants match current glibc, then old binaries
that don't use htm or vsx will fail when run on a newer kernel.

Ideally the kernel would detect whether a binary was going to use htm
or vsx and adjust the minimum sizes, but it's a wee bit difficult for
the kernel to know that ahead of time.

This test expects -ENOMEM from
kernel when passing less than stack size (passing 4095). MINSIGSTKSZ in
signal.h (glibc) is changed to 4096 to support VSX changes
(https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f7c399cff5bd04ee9dc117fb6b0f39597dc047c6)
We should also change these values in kernel to match with glibc. Any
issues?

diff --git a/arch/powerpc/include/uapi/asm/signal.h
b/arch/powerpc/include/uapi/
index 6c69ee9..18f498e 100644
--- a/arch/powerpc/include/uapi/asm/signal.h
+++ b/arch/powerpc/include/uapi/asm/signal.h
@@ -85,8 +85,8 @@ typedef struct {

#define SA_RESTORER0x0400U

-#define MINSIGSTKSZ2048
-#define SIGSTKSZ 8192
+#define MINSIGSTKSZ4096
+#define SIGSTKSZ 16384

Thanks
Haren

--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] PCI/MSI: Phase out pci_enable_msi_block()

2014-04-14 Thread Alexander Gordeev

There are no users of pci_enable_msi_block() function have
left. Obsolete it in favor of pci_enable_msi_range() and
pci_enable_msi_exact() functions.

Up until now, when enabling MSI mode for a device, a single
successful call to arch_msi_check_device() was followed by
a single call to arch_setup_msi_irqs() function.

Yet, if arch_msi_check_device() returned success we should be
able to call arch_setup_msi_irqs() multiple times - while it
returns a number of MSI vectors that could have been allocated
(a third state).

This update makes use of the assumption described above. It
could have broke things had the architectures done any pre-
allocations or switch to some state in a call to function
arch_msi_check_device(). But because arch_msi_check_device()
is expected stateless and MSI resources are allocated in a
follow-up call to arch_setup_msi_irqs() we should be fine.

Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: linux-m...@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/msi.c   |   79 +-
 include/linux/pci.h |5 +--
 2 files changed, 34 insertions(+), 50 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 955ab79..fc669ab 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -883,50 +883,6 @@ int pci_msi_vec_count(struct pci_dev *dev)
 }
 EXPORT_SYMBOL(pci_msi_vec_count);
 
-/**
- * pci_enable_msi_block - configure device's MSI capability structure
- * @dev: device to configure
- * @nvec: number of interrupts to configure
- *
- * Allocate IRQs for a device with the MSI capability.
- * This function returns a negative errno if an error occurs.  If it
- * is unable to allocate the number of interrupts requested, it returns
- * the number of interrupts it might be able to allocate.  If it successfully
- * allocates at least the number of interrupts requested, it returns 0 and
- * updates the @dev's irq member to the lowest new interrupt number; the
- * other interrupt numbers allocated to this device are consecutive.
- */
-int pci_enable_msi_block(struct pci_dev *dev, int nvec)
-{
-   int status, maxvec;
-
-   if (dev-current_state != PCI_D0)
-   return -EINVAL;
-
-   maxvec = pci_msi_vec_count(dev);
-   if (maxvec  0)
-   return maxvec;
-   if (nvec  maxvec)
-   return maxvec;
-
-   status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
-   if (status)
-   return status;
-
-   WARN_ON(!!dev-msi_enabled);
-
-   /* Check whether driver already requested MSI-X irqs */
-   if (dev-msix_enabled) {
-   dev_info(dev-dev, can't enable MSI 
-(MSI-X already enabled)\n);
-   return -EINVAL;
-   }
-
-   status = msi_capability_init(dev, nvec);
-   return status;
-}
-EXPORT_SYMBOL(pci_enable_msi_block);
-
 void pci_msi_shutdown(struct pci_dev *dev)
 {
struct msi_desc *desc;
@@ -1132,14 +1088,45 @@ void pci_msi_init_pci_dev(struct pci_dev *dev)
  **/
 int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
 {
-   int nvec = maxvec;
+   int nvec;
int rc;
 
+   if (dev-current_state != PCI_D0)
+   return -EINVAL;
+
+   WARN_ON(!!dev-msi_enabled);
+
+   /* Check whether driver already requested MSI-X irqs */
+   if (dev-msix_enabled) {
+   dev_info(dev-dev,
+can't enable MSI (MSI-X already enabled)\n);
+   return -EINVAL;
+   }
+
if (maxvec  minvec)
return -ERANGE;
 
+   nvec = pci_msi_vec_count(dev);
+   if (nvec  0)
+   return nvec;
+   else if (nvec  minvec)
+   return -EINVAL;
+   else if (nvec  maxvec)
+   nvec = maxvec;
+
+   do {
+   rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
+   if (rc  0) {
+   return rc;
+   } else if (rc  0) {
+   if (rc  minvec)
+   return -ENOSPC;
+   nvec = rc;
+   }
+   } while (rc);
+
do {
-   rc = pci_enable_msi_block(dev, nvec);
+   rc = msi_capability_init(dev, nvec);
if (rc  0) {
return rc;
} else if (rc  0) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..d8104f4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1158,7 +1158,6 @@ struct msix_entry {
 
 #ifdef CONFIG_PCI_MSI
 int pci_msi_vec_count(struct pci_dev *dev);
-int pci_enable_msi_block(struct pci_dev *dev, int nvec);
 void pci_msi_shutdown(struct pci_dev *dev);
 void pci_disable_msi(struct pci_dev *dev);
 int pci_msix_vec_count(struct pci_dev *dev);
@@ -1188,8 +1187,6 @@ static inline int pci_enable_msix_exact(struct pci_dev 
*dev,
 }

49 matches

Mail list logo