Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 04:03:39PM +0100, Martin Schwidefsky wrote:
> On Mon, 4 Jan 2016 14:20:42 +0100
> Peter Zijlstra  wrote:
> 
> > On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> > > On s390 read_barrier_depends, smp_read_barrier_depends
> > > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> > > asm-generic variants exactly. Drop the local definitions and pull in
> > > asm-generic/barrier.h instead.
> > > 
> > > This is in preparation to refactoring this code area.
> > > 
> > > Signed-off-by: Michael S. Tsirkin 
> > > Acked-by: Arnd Bergmann 
> > > ---
> > >  arch/s390/include/asm/barrier.h | 10 ++
> > >  1 file changed, 2 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/s390/include/asm/barrier.h 
> > > b/arch/s390/include/asm/barrier.h
> > > index 7ffd0b1..c358c31 100644
> > > --- a/arch/s390/include/asm/barrier.h
> > > +++ b/arch/s390/include/asm/barrier.h
> > > @@ -30,14 +30,6 @@
> > >  #define smp_rmb()rmb()
> > >  #define smp_wmb()wmb()
> > >  
> > > -#define read_barrier_depends()   do { } while (0)
> > > -#define smp_read_barrier_depends()   do { } while (0)
> > > -
> > > -#define smp_mb__before_atomic()  smp_mb()
> > > -#define smp_mb__after_atomic()   smp_mb()
> > 
> > As per:
> > 
> >   lkml.kernel.org/r/20150921112252.3c2937e1@mschwide
> > 
> > s390 should change this to barrier() instead of smp_mb() and hence
> > should not use the generic versions.
>  
> Yes, we wanted to simplify this. Thanks for the reminder, I'll queue
> a patch.

Could you base on my patchset maybe, to avoid conflicts,
and I'll merge it?
Or if it's just replacing these 2 with barrier() I can do this
myself easily.

> -- 
> blue skies,
>Martin.
> 
> "Reality continues to ruin my life." - Calvin.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] checkpatch: add virt barriers

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 08:47:53AM -0800, Joe Perches wrote:
> On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote:
> > Add virt_ barriers to list of barriers to check for
> > presence of a comment.
> 
> Are these virt_ barriers used anywhere?
> 
> I see some virtio_ barrier like uses.

They will be :) They are added and used by patchset
arch: barrier cleanup + barriers for virt

See
http://article.gmane.org/gmane.linux.kernel.virtualization/26555


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

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> > 
> > > > My only concern is that it gives people an additional handle onto a
> > > > "new" set of barriers - just because they're prefixed with __*
> > > > unfortunately doesn't stop anyone from using it (been there with
> > > > other arch stuff before.)
> > > > 
> > > > I wonder whether we should consider making the smp memory barriers
> > > > inline functions, so these __smp_xxx() variants can be undef'd
> > > > afterwards, thereby preventing drivers getting their hands on these
> > > > new macros?
> > > 
> > > That'd be tricky to do cleanly since asm-generic depends on
> > > ifndef to add generic variants where needed.
> > > 
> > > But it would be possible to add a checkpatch test for this.
> > 
> > Wasn't the whole purpose of these things for 'drivers' (namely
> > virtio/xen hypervisor interaction) to use these?
> 
> Ah, I see, you add virt_*mb() stuff later on for that use case.
> 
> So, assuming everybody does include asm-generic/barrier.h, you could
> simply #undef the __smp version at the end of that, once we've generated
> all the regular primitives from it, no?

Maybe I misunderstand, but I don't think so:

-->
#define __smp_xxx FOO
#define smp_xxx __smp_xxx
#undef __smp_xxx

smp_xxx
<--

resolves to __smp_xxx, not FOO.

That's why I went the checkpatch way.


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

Re: [RFC PATCH v2 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

[Alex Williamson]

On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
> Current vfio-pci implementation disallows to mmap MSI-X
> table in case that user get to touch this directly.
> 
> However, EEH mechanism can ensure that a given pci device
> can only shoot the MSIs assigned for its PE. So we think
> it's safe to expose the MSI-X table to userspace because
> the exposed MSI-X table can't be used to do harm to other
> memory space.
> 
> And with MSI-X table mmapped, some performance issues which
> are caused when PCI adapters have critical registers in the
> same page as the MSI-X table also can be resolved.
> 
> So this patch adds a Kconfig option, VFIO_PCI_MMAP_MSIX,
> to support for mmapping MSI-X table.
> 
> Signed-off-by: Yongji Xie 
> ---
>  drivers/vfio/pci/Kconfig|4 
>  drivers/vfio/pci/vfio_pci.c |6 --
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> index 02912f1..67b0a2c 100644
> --- a/drivers/vfio/pci/Kconfig
> +++ b/drivers/vfio/pci/Kconfig
> @@ -23,6 +23,10 @@ config VFIO_PCI_MMAP
>   depends on VFIO_PCI
>   def_bool y if !S390
>  
> +config VFIO_PCI_MMAP_MSIX
> + depends on VFIO_PCI_MMAP
> + def_bool y if EEH

Does CONFIG_EEH necessarily mean the EEH is enabled?  Could the system
not support EEH or could EEH be disabled via kernel commandline
options?

> +
>  config VFIO_PCI_INTX
>   depends on VFIO_PCI
>   def_bool y if !S390
> diff --git a/drivers/vfio/pci/vfio_pci.c
> b/drivers/vfio/pci/vfio_pci.c
> index 09b3805..d536985 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -555,7 +555,8 @@ static long vfio_pci_ioctl(void *device_data,
>   IORESOURCE_MEM && (info.size >=
> PAGE_SIZE ||
>   pci_resource_page_aligned)) {
>   info.flags |=
> VFIO_REGION_INFO_FLAG_MMAP;
> - if (info.index == vdev->msix_bar) {
> + if
> (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP_MSIX) &&
> + info.index == vdev->msix_bar) {
>   ret =
> msix_sparse_mmap_cap(vdev, );
>   if (ret)
>   return ret;
> @@ -967,7 +968,8 @@ static int vfio_pci_mmap(void *device_data,
> struct vm_area_struct *vma)
>   if (phys_len < PAGE_SIZE || req_start + req_len > phys_len)
>   return -EINVAL;
>  
> - if (index == vdev->msix_bar) {
> + if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP_MSIX) &&
> + index == vdev->msix_bar) {
>   /*
>    * Disallow mmaps overlapping the MSI-X table; users
> don't
>    * get to touch this directly.  We could find
> somewhere

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

Re: [RFC PATCH v2 1/3] PCI: Add support for enforcing all MMIO BARs to be page aligned

[Alex Williamson]

On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
> When vfio passthrough a PCI device of which MMIO BARs
> are smaller than PAGE_SIZE, guest will not handle the
> mmio accesses to the BARs which leads to mmio emulations
> in host.
> 
> This is because vfio will not allow to passthrough one
> BAR's mmio page which may be shared with other BARs.
> 
> To solve this performance issue, this patch adds a kernel
> parameter "pci=resource_page_aligned=on" to enforce
> the alignments of all MMIO BARs to be at least PAGE_SIZE,
> so that one BAR's mmio page would not be shared with other
> BARs. We can also disable it through kernel parameter
> "pci=resource_page_aligned=off".

Shouldn't this somehow be associated with the realloc option?  I don't
think PCI code will attempt to reprogram anything unless it needs to
otherwise.

> For the default value of this parameter, we think it should be
> arch-independent, so we add a macro PCI_RESOURCE_PAGE_ALIGNED
> to change it. And we define this macro to enable this parameter
> by default on PPC64 platform which can easily hit this
> performance issue because its PAGE_SIZE is 64KB.
> 
> Signed-off-by: Yongji Xie 
> ---
>  Documentation/kernel-parameters.txt |4 
>  arch/powerpc/include/asm/pci.h  |   11 +++
>  drivers/pci/pci.c   |   17 +
>  drivers/pci/pci.h   |7 ++-
>  include/linux/pci.h |2 ++
>  5 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 742f69d..a53aaee 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2857,6 +2857,10 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   PAGE_SIZE is used as alignment.
>   PCI-PCI bridge can be specified, if resource
>   windows need to be expanded.
> + resource_page_aligned=  Enable/disable enforcing the alignment
> + of all PCI devices' memory resources to be
> + at least PAGE_SIZE.
> + Format: { "on" | "off" }
>   ecrc=   Enable/disable PCIe ECRC (transaction layer
>   end-to-end CRC checking).
>   bios: Use BIOS/firmware settings. This is the
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 3453bd8..27bff59 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -136,6 +136,17 @@ extern pgprot_t  pci_phys_mem_access_prot(struct file 
> *file,
>    unsigned long pfn,
>    unsigned long size,
>    pgprot_t prot);
> +#ifdef CONFIG_PPC64
> +
> +/* For PPC64, We enforce all PCI MMIO BARs to be page aligned
> + * by default. This would be helpful to improve performance
> + * when we passthrough a PCI device of which BARs are smaller
> + * than PAGE_SIZE(64KB). And we can use bootcmd
> + * "pci=resource_page_aligned=off" to disable it.
> + */
> +#define PCI_ENABLE_RESOURCE_PAGE_ALIGNED
> +
> +#endif

This should be done with something like HAVE_PCI_DEFAULT_RESOURCE_PAGE_
ALIGNED in arch/powerpc/include/asm

>  #define HAVE_ARCH_PCI_RESOURCE_TO_USER
>  extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 314db8c..9f14ba5 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -99,6 +99,13 @@ u8 pci_cache_line_size;
>   */
>  unsigned int pcibios_max_latency = 255;
>  
> +#ifdef PCI_ENABLE_RESOURCE_PAGE_ALIGNED
> +bool pci_resource_page_aligned = true;
> +#else
> +bool pci_resource_page_aligned;
> +#endif
> +EXPORT_SYMBOL(pci_resource_page_aligned);

Couldn't this be done in a single line with IS_ENABLED() macro?

Should this symbol be GPL-only?

> +
>  /* If set, the PCIe ARI capability will not be used. */
>  static bool pcie_ari_disabled;
>  
> @@ -4746,6 +4753,14 @@ static ssize_t pci_resource_alignment_store(struct 
> bus_type *bus,
>  BUS_ATTR(resource_alignment, 0644, pci_resource_alignment_show,
>   pci_resource_alignment_store);
>  
> +static void pci_resource_get_page_aligned(char *str)
> +{
> + if (!strncmp(str, "off", 3))
> + pci_resource_page_aligned = false;
> + else if (!strncmp(str, "on", 2))
> + pci_resource_page_aligned = true;
> +}
> +
>  static int __init pci_resource_alignment_sysfs_init(void)
>  {
>   return bus_create_file(_bus_type,
> @@ -4859,6 +4874,8 @@ static int __init pci_setup(char *str)
>   } else if (!strncmp(str, "resource_alignment=", 19)) {
>   

Re: [PATCH v2 22/32] s390: define __smp_xxx

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 02:45:25PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 31, 2015 at 09:08:38PM +0200, Michael S. Tsirkin wrote:
> > This defines __smp_xxx barriers for s390,
> > for use by virtualization.
> > 
> > Some smp_xxx barriers are removed as they are
> > defined correctly by asm-generic/barriers.h
> > 
> > Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers
> > unconditionally on this architecture.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > Acked-by: Arnd Bergmann 
> > ---
> >  arch/s390/include/asm/barrier.h | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/s390/include/asm/barrier.h 
> > b/arch/s390/include/asm/barrier.h
> > index c358c31..fbd25b2 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -26,18 +26,21 @@
> >  #define wmb()  barrier()
> >  #define dma_rmb()  mb()
> >  #define dma_wmb()  mb()
> > -#define smp_mb()   mb()
> > -#define smp_rmb()  rmb()
> > -#define smp_wmb()  wmb()
> > -
> > -#define smp_store_release(p, v)
> > \
> > +#define __smp_mb() mb()
> > +#define __smp_rmb()rmb()
> > +#define __smp_wmb()wmb()
> > +#define smp_mb()   __smp_mb()
> > +#define smp_rmb()  __smp_rmb()
> > +#define smp_wmb()  __smp_wmb()
> 
> Why define the smp_*mb() primitives here? Would not the inclusion of
> asm-generic/barrier.h do this?

No because the generic one is a nop on !SMP, this one isn't.

Pls note this patch is just reordering code without making
functional changes.
And at the moment, on s390 smp_xxx barriers are always non empty.

Some of this could be sub-optimal, but
since on s390 Linux always runs on a hypervisor,
I am not sure it's safe to use the generic version -
in other words, it just might be that for s390 smp_ and virt_
barriers must be equivalent.

If in fact this turns out to be wrong, I can pick up
a patch to change this, but I'd rather make this
a patch on top so that my patches are testable
just by compiling and comparing the binary.

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

Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 02:20:42PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> > On s390 read_barrier_depends, smp_read_barrier_depends
> > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> > asm-generic variants exactly. Drop the local definitions and pull in
> > asm-generic/barrier.h instead.
> > 
> > This is in preparation to refactoring this code area.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > Acked-by: Arnd Bergmann 
> > ---
> >  arch/s390/include/asm/barrier.h | 10 ++
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/s390/include/asm/barrier.h 
> > b/arch/s390/include/asm/barrier.h
> > index 7ffd0b1..c358c31 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -30,14 +30,6 @@
> >  #define smp_rmb()  rmb()
> >  #define smp_wmb()  wmb()
> >  
> > -#define read_barrier_depends() do { } while (0)
> > -#define smp_read_barrier_depends() do { } while (0)
> > -
> > -#define smp_mb__before_atomic()smp_mb()
> > -#define smp_mb__after_atomic() smp_mb()
> 
> As per:
> 
>   lkml.kernel.org/r/20150921112252.3c2937e1@mschwide
> 
> s390 should change this to barrier() instead of smp_mb() and hence
> should not use the generic versions.

Thanks Peter!

OK so I will just rename this to __smp_mb__before_atomic and
__smp_mb__after_atomic but keep them around.

I'm not changing these - that's best left to s390 maintainers.

Should I add a TODO comment to change them to barrier so
we don't forget?

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

Re: [PATCH 1/3] checkpatch.pl: add missing memory barriers

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote:
> On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote:
> > SMP-only barriers were missing in checkpatch.pl
> > 
> > Refactor code slightly to make adding more variants easier.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  scripts/checkpatch.pl | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 2b3c228..0245bbe 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -5116,7 +5116,14 @@ sub process {
> >     }
> >     }
> >  # check for memory barriers without a comment.
> > -   if ($line =~ 
> > /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/)
> >  {
> > +
> > +   my @barriers = ('mb', 'rmb', 'wmb', 'read_barrier_depends');
> > +   my @smp_barriers = ('smp_store_release', 'smp_load_acquire', 
> > 'smp_store_mb');
> > +
> > +   @smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
> 
> I think using map, which so far checkpatch doesn't use,
> makes smp_barriers harder to understand and it'd be
> better to enumerate them.

Okay - I'll rewrite using foreach.

> > +   my $all_barriers = join('|', (@barriers, @smp_barriers));
> > +
> > +   if ($line =~ /\b($all_barriers)\(/) {
> 
> It would be better to use /\b$all_barriers\s*\(/
> as there's no reason for the capture and there
> could be a space between the function and the
> open parenthesis.

That's the way it was - space before ( will trigger other
warnings. But sure, ok.

> 
> >     if (!ctx_has_comment($first_line, $linenr)) {
> >     WARN("MEMORY_BARRIER",
> >      "memory barrier without comment\n" . 
> > $herecurr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Michael S. Tsirkin]

On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
> On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> 
> > > My only concern is that it gives people an additional handle onto a
> > > "new" set of barriers - just because they're prefixed with __*
> > > unfortunately doesn't stop anyone from using it (been there with
> > > other arch stuff before.)
> > > 
> > > I wonder whether we should consider making the smp memory barriers
> > > inline functions, so these __smp_xxx() variants can be undef'd
> > > afterwards, thereby preventing drivers getting their hands on these
> > > new macros?
> > 
> > That'd be tricky to do cleanly since asm-generic depends on
> > ifndef to add generic variants where needed.
> > 
> > But it would be possible to add a checkpatch test for this.
> 
> Wasn't the whole purpose of these things for 'drivers' (namely
> virtio/xen hypervisor interaction) to use these?

My take out from discussion with you was that virtualization is probably
the only valid use-case.  So at David Miller's suggestion there's a
patch later in the series that adds virt_ wrappers and these are
then used by virtio xen and later maybe others.

> And I suppose most of virtio would actually be modules, so you cannot do
> what I did with preempt_enable_no_resched() either.
> 
> But yes, it would be good to limit the use of these things.

Right so the trick is checkpatch warns about use of
__smp_xxx and hopefully people are not crazy enough
to use virt_xxx variants for non-virtual drivers.

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

[PATCH] powerpc/fsl-pci: Correct the comparison of the LTSSM

[Zhiqiang Hou]

From: Hou Zhiqiang 

Only the value PCIE_LTSSM_L0 stands for the link is up, instead
of >= PCIE_LTSSM_L0.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/sysdev/fsl_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 610f472..1595f55 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -73,7 +73,7 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
   PCIE_LTSSM, 4, );
else
early_read_config_dword(hose, 0, 0, PCIE_LTSSM, );
-   if (val < PCIE_LTSSM_L0)
+   if (val != PCIE_LTSSM_L0)
return 1;
} else {
struct ccsr_pci __iomem *pci = hose->private_data;
-- 
2.1.0.27.g96db324

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

[PATCH v2] perf/probe: Search both .eh_frame and .debug_frame sections for probe location

[Hemant Kumar]

perf probe through debuginfo__find_probes() in util/probe-finder.c
checks for the functions' frame descriptions in either .eh_frame section
of an ELF or the .debug_frame. The check is based on whether either one
of these sections is present. Depending on distro, toolchain defaults,
architetcutre, build flags, etc., CFI might be found in either .eh_frame
and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if
present, may not be complete and may miss some descriptions. Therefore,
to be sure, to find the CFI covering an address we will always have to
investigate both if available.

For e.g., in powerpc, this may happen :
 $ gcc -g bin.c -o bin

 $ objdump --dwarf ./bin
 <1><145>: Abbrev Number: 7 (DW_TAG_subprogram)
<146>   DW_AT_external: 1
<146>   DW_AT_name: (indirect string, offset: 0x9e): main
<14a>   DW_AT_decl_file   : 1
<14b>   DW_AT_decl_line   : 39
<14c>   DW_AT_prototyped  : 1
<14c>   DW_AT_type: <0x57>
<150>   DW_AT_low_pc  : 0x17b8

If the .eh_frame and .debug_frame are checked for the same binary, we
will find that, .eh_frame (although present) doesn't contain a
description for "main" function.
But, .debug_frame has a description :

00d8 0024  FDE cie= pc=17b8..1838
  DW_CFA_advance_loc: 16 to 17c8
  DW_CFA_def_cfa_offset: 144
  DW_CFA_offset_extended_sf: r65 at cfa+16
...

Due to this (since, perf checks whether .eh_frame is present and goes on
searching for that address inside that frame), perf is unable to process
the probes :
 # perf probe -x ./bin main
Failed to get call frame on 0x17b8
  Error: Failed to add events.

To avoid this issue, we need to check both the sections (.eh_frame and
.debug_frame), which is done in this patch.

Note that, we can always force everything into both .eh_frame and
.debug_frame by :
 $ gcc bin.c -fasynchronous-unwind-tables  -fno-dwarf2-cfi-asm -g -o bin

Signed-off-by: Hemant Kumar 
---
Changes since v1:
- pf->cfi is now cached as pf->cfi_eh and pf->cfi_dbg depending on the source 
of CFI
  (Suggested by Mark Wielard).

 tools/perf/util/probe-finder.c | 63 +-
 tools/perf/util/probe-finder.h |  5 +++-
 2 files changed, 42 insertions(+), 26 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 05012bb..71bf27e 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -685,9 +685,10 @@ static int call_probe_finder(Dwarf_Die *sc_die, struct 
probe_finder *pf)
pf->fb_ops = NULL;
 #if _ELFUTILS_PREREQ(0, 142)
} else if (nops == 1 && pf->fb_ops[0].atom == DW_OP_call_frame_cfa &&
-  pf->cfi != NULL) {
+  (pf->cfi_eh != NULL || pf->cfi_dbg != NULL)) {
Dwarf_Frame *frame;
-   if (dwarf_cfi_addrframe(pf->cfi, pf->addr, ) != 0 ||
+   if ((dwarf_cfi_addrframe(pf->cfi_eh, pf->addr, ) != 0 &&
+(dwarf_cfi_addrframe(pf->cfi_dbg, pf->addr, ) != 0)) 
||
dwarf_frame_cfa(frame, >fb_ops, ) != 0) {
pr_warning("Failed to get call frame on 0x%jx\n",
   (uintmax_t)pf->addr);
@@ -1013,8 +1014,7 @@ static int pubname_search_cb(Dwarf *dbg, Dwarf_Global 
*gl, void *data)
return DWARF_CB_OK;
 }
 
-/* Find probe points from debuginfo */
-static int debuginfo__find_probes(struct debuginfo *dbg,
+static int debuginfo__find_probe_location(struct debuginfo *dbg,
  struct probe_finder *pf)
 {
struct perf_probe_point *pp = >pev->point;
@@ -1023,27 +1023,6 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
Dwarf_Die *diep;
int ret = 0;
 
-#if _ELFUTILS_PREREQ(0, 142)
-   Elf *elf;
-   GElf_Ehdr ehdr;
-   GElf_Shdr shdr;
-
-   /* Get the call frame information from this dwarf */
-   elf = dwarf_getelf(dbg->dbg);
-   if (elf == NULL)
-   return -EINVAL;
-
-   if (gelf_getehdr(elf, ) == NULL)
-   return -EINVAL;
-
-   if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
-   shdr.sh_type == SHT_PROGBITS) {
-   pf->cfi = dwarf_getcfi_elf(elf);
-   } else {
-   pf->cfi = dwarf_getcfi(dbg->dbg);
-   }
-#endif
-
off = 0;
pf->lcache = intlist__new(NULL);
if (!pf->lcache)
@@ -1106,6 +1085,40 @@ found:
return ret;
 }
 
+/* Find probe points from debuginfo */
+static int debuginfo__find_probes(struct debuginfo *dbg,
+ struct probe_finder *pf)
+{
+   int ret = 0;
+
+#if _ELFUTILS_PREREQ(0, 142)
+   Elf *elf;
+   GElf_Ehdr ehdr;
+   GElf_Shdr shdr;
+
+   if (pf->cfi_eh || pf->cfi_dbg)
+   return debuginfo__find_probe_location(dbg, pf);
+
+   /* Get the call frame information from this dwarf */
+   elf = 

Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers

[David Vrabel]

On 31/12/15 19:10, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.

Acked-by: David Vrabel 

If you're feeling particularly keen there's a rmb() consume_one_event()
in drivers/xen/events/events_fifo.c that can be converted to virt_rmb()
as well.

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

Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers

[David Vrabel]

On 31/12/15 19:10, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.

Acked-by: David Vrabel 

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

[PATCH 2/3] checkpatch: check for __smp outside barrier.h

[Michael S. Tsirkin]

Introduction of __smp barriers cleans up a bunch of duplicate code, but
it gives people an additional handle onto a "new" set of barriers - just
because they're prefixed with __* unfortunately doesn't stop anyone from
using it (as happened with other arch stuff before.)

Add a checkpatch test so it will trigger a warning.

Reported-by: Russell King 
Signed-off-by: Michael S. Tsirkin 
---
 scripts/checkpatch.pl | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0245bbe..e3f9ad9 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5130,6 +5130,17 @@ sub process {
}
}
 
+   my @underscore_smp_barriers = map {"__" . $_} @smp_barriers;
+   my $underscore_all_barriers = join('|', 
@underscore_smp_barriers);
+
+   if ($realfile !~ m@^include/asm-generic/@ &&
+   $realfile !~ m@/barrier\.h$@ &&
+   $line =~ m/\b($underscore_all_barriers)\(/ &&
+   $line !~ 
m/^.\s*\#\s*define\s+($underscore_all_barriers)\(/) {
+   WARN("MEMORY_BARRIER",
+"__smp memory barriers shouldn't be used outside 
barrier.h and asm-generic\n" . $herecurr);
+   }
+
 # check for waitqueue_active without a comment.
if ($line =~ /\bwaitqueue_active\s*\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
-- 
MST

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

[PATCH 3/3] checkpatch: add virt barriers

[Michael S. Tsirkin]

Add virt_ barriers to list of barriers to check for
presence of a comment.

Signed-off-by: Michael S. Tsirkin 
---
 scripts/checkpatch.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3f9ad9..5fb6ef7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5121,7 +5121,8 @@ sub process {
my @smp_barriers = ('smp_store_release', 'smp_load_acquire', 
'smp_store_mb');
 
@smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
-   my $all_barriers = join('|', (@barriers, @smp_barriers));
+   my @virt_barriers = map {my $l = $_; $l =~ s/smp_/virt_/; $l} 
@smp_barriers;
+   my $all_barriers = join('|', (@barriers, @smp_barriers, 
@virt_barriers));
 
if ($line =~ /\b($all_barriers)\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
-- 
MST

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

[PATCH 0/3] checkpatch: handling of memory barriers

[Michael S. Tsirkin]

As part of memory barrier cleanup, this patchset
extends checkpatch to make it easier to stop
incorrect memory barrier usage.

This applies on top of my series
arch: barrier cleanup + barriers for virt
and will be included in the next version of the series.

Michael S. Tsirkin (3):
  checkpatch.pl: add missing memory barriers
  checkpatch: check for __smp outside barrier.h
  checkpatch: add virt barriers

 scripts/checkpatch.pl | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

-- 
MST

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

Re: [PATCH v2 34/34] xen/io: use virt_xxx barriers

[Stefano Stabellini]

On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin 

Reviewed-by: Stefano Stabellini 


>  include/xen/interface/io/ring.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
> index 7dc685b..21f4fbd 100644
> --- a/include/xen/interface/io/ring.h
> +++ b/include/xen/interface/io/ring.h
> @@ -208,12 +208,12 @@ struct __name##_back_ring { 
> \
>  
>  
>  #define RING_PUSH_REQUESTS(_r) do {  \
> -wmb(); /* back sees requests /before/ updated producer index */  \
> +virt_wmb(); /* back sees requests /before/ updated producer index */ 
> \
>  (_r)->sring->req_prod = (_r)->req_prod_pvt;  
> \
>  } while (0)
>  
>  #define RING_PUSH_RESPONSES(_r) do { \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +virt_wmb(); /* front sees responses /before/ updated producer index */   
> \
>  (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;  
> \
>  } while (0)
>  
> @@ -250,9 +250,9 @@ struct __name##_back_ring {   
> \
>  #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {
> \
>  RING_IDX __old = (_r)->sring->req_prod;  \
>  RING_IDX __new = (_r)->req_prod_pvt; \
> -wmb(); /* back sees requests /before/ updated producer index */  \
> +virt_wmb(); /* back sees requests /before/ updated producer index */ 
> \
>  (_r)->sring->req_prod = __new;   \
> -mb(); /* back sees new requests /before/ we check req_event */   \
> +virt_mb(); /* back sees new requests /before/ we check req_event */  
> \
>  (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <
> \
>(RING_IDX)(__new - __old));\
>  } while (0)
> @@ -260,9 +260,9 @@ struct __name##_back_ring {   
> \
>  #define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do {   
> \
>  RING_IDX __old = (_r)->sring->rsp_prod;  \
>  RING_IDX __new = (_r)->rsp_prod_pvt; \
> -wmb(); /* front sees responses /before/ updated producer index */
> \
> +virt_wmb(); /* front sees responses /before/ updated producer index */   
> \
>  (_r)->sring->rsp_prod = __new;   \
> -mb(); /* front sees new responses /before/ we check rsp_event */ \
> +virt_mb(); /* front sees new responses /before/ we check rsp_event */
> \
>  (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) <
> \
>(RING_IDX)(__new - __old));\
>  } while (0)
> @@ -271,7 +271,7 @@ struct __name##_back_ring {   
> \
>  (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
>  if (_work_to_do) break;  \
>  (_r)->sring->req_event = (_r)->req_cons + 1; \
> -mb();\
> +virt_mb();   
> \
>  (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
> \
>  } while (0)
>  
> @@ -279,7 +279,7 @@ struct __name##_back_ring {   
> \
>  (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);   
> \
>  if (_work_to_do) break;  \
>  (_r)->sring->rsp_event = (_r)->rsp_cons + 1; \
> -mb();\
> +virt_mb();   
> \
>  (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);   
> \
>  } while (0)
>  
> -- 
> MST
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers

[Stefano Stabellini]

On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin 

Reviewed-by: Stefano Stabellini 

Are you also going to take care of

drivers/xen/grant-table.c
drivers/xen/evtchn.c
drivers/xen/events/events_fifo.c
drivers/xen/xen-scsiback.c
drivers/xen/tmem.c
drivers/xen/xen-pciback/pci_stub.c
drivers/xen/xen-pciback/pciback_ops.c

?


>  drivers/xen/xenbus/xenbus_comms.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..ecdecce 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
>   avail = len;
>  
>   /* Must write data /after/ reading the consumer index. */
> - mb();
> + virt_mb();
>  
>   memcpy(dst, data, avail);
>   data += avail;
>   len -= avail;
>  
>   /* Other side must not see new producer until data is there. */
> - wmb();
> + virt_wmb();
>   intf->req_prod += avail;
>  
>   /* Implies mb(): other side will see the updated producer. */
> @@ -180,14 +180,14 @@ int xb_read(void *data, unsigned len)
>   avail = len;
>  
>   /* Must read data /after/ reading the producer index. */
> - rmb();
> + virt_rmb();
>  
>   memcpy(data, src, avail);
>   data += avail;
>   len -= avail;
>  
>   /* Other side must not see free space until we've copied out */
> - mb();
> + virt_mb();
>   intf->rsp_cons += avail;
>  
>   pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
> -- 
> MST
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] checkpatch.pl: add missing memory barriers

[Michael S. Tsirkin]

SMP-only barriers were missing in checkpatch.pl

Refactor code slightly to make adding more variants easier.

Signed-off-by: Michael S. Tsirkin 
---
 scripts/checkpatch.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2b3c228..0245bbe 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5116,7 +5116,14 @@ sub process {
}
}
 # check for memory barriers without a comment.
-   if ($line =~ 
/\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/)
 {
+
+   my @barriers = ('mb', 'rmb', 'wmb', 'read_barrier_depends');
+   my @smp_barriers = ('smp_store_release', 'smp_load_acquire', 
'smp_store_mb');
+
+   @smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
+   my $all_barriers = join('|', (@barriers, @smp_barriers));
+
+   if ($line =~ /\b($all_barriers)\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
WARN("MEMORY_BARRIER",
 "memory barrier without comment\n" . 
$herecurr);
-- 
MST

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

[PATCH v3 2/2] cpufreq: powernv: Redesign the presentation of throttle notification

[Shilpasri G Bhat]

Replace the throttling event console messages to perf trace point
"power:powernv_throttle" and throttle counter stats which are
exported in sysfs in /sys/devices/system/cpu/cpufreq/chipN. The
newly added sysfs files are as follows:

1)/sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
  This gives the throttle stats for each of the available frequencies.
  The throttle stat of a frequency is the total number of times the max
  frequency is reduced to that frequency.
  # cat /sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
  4023000 0
  399 0
  3956000 1
  3923000 0
  389 0
  3857000 2
  3823000 0
  379 0
  3757000 2
  3724000 1
  369 1
  ...

2)/sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
  This directory contains throttle reason files. Each file gives the
  total number of times the max frequency is throttled, except for
  'throttle_reset', which gives the total number of times the max
  frequency is unthrottled after being throttled.
  # cd /sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
  # cat cpu_over_temperature
  7
  # cat occ_reset
  0
  # cat over_current
  0
  # cat power_cap
  0
  # cat power_supply_failure
  0
  # cat throttle_reset
  7

3)/sys/devices/system/cpu/cpufreq/chip0/throttle_stat
  This gives the total number of events of max frequency throttling to
  lower frequencies in the turbo range of frequencies and the sub-turbo(at
  and below nominal) range of frequencies.
  # cat /sys/devices/system/cpu/cpufreq/chip0/throttle_stat
  turbo 7
  sub-turbo 0

Signed-off-by: Shilpasri G Bhat 
---
Changes from v2:
- Fixed kbuild test warning.
drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return
value of 'kstrtoint', declared with attribute warn_unused_result
[-Wunused-result]

Changes from v1:
- Added a kobject to struct chip
- Grouped the throttle reasons under a separate attribute_group and
  exported each reason as individual file.
- Moved the sysfs files from /sys/devices/system/node/nodeN to
  /sys/devices/system/cpu/cpufreq/chipN
- As suggested by Paul Clarke replaced 'Nominal' with 'sub-turbo' and
  char * throttle_reason[][30] by const char * const throttle_reason[].
- Modified the commit message.

 drivers/cpufreq/powernv-cpufreq.c | 256 +++---
 1 file changed, 213 insertions(+), 43 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index cb50138..5574f06 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -43,12 +44,37 @@
 static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
 static bool rebooting, throttled, occ_reset;
 
+static const char * const throttle_reason[] = {
+   "No throttling",
+   "Power Cap",
+   "Processor Over Temperature",
+   "Power Supply Failure",
+   "Over Current",
+   "OCC Reset"
+};
+
+enum throt_reason_type {
+   NO_THROTTLE = 0,
+   POWERCAP,
+   CPU_OVERTEMP,
+   POWER_SUPPLY_FAILURE,
+   OVERCURRENT,
+   OCC_RESET_THROTTLE
+};
+
 static struct chip {
unsigned int id;
bool throttled;
cpumask_t mask;
struct work_struct throttle;
bool restore;
+   /* Pmax throttle stats */
+   int throt_reason;
+   int throt_turbo;
+   int throt_nominal;
+   int reason[OCC_MAX_THROTTLE_STATUS + 1];
+   int *pstate_stat;
+   struct kobject *kobj;
 } *chips;
 
 static int nr_chips;
@@ -309,11 +335,11 @@ static inline unsigned int get_nominal_index(void)
return powernv_pstate_info.max - powernv_pstate_info.nominal;
 }
 
-static void powernv_cpufreq_throttle_check(void *data)
+static void powernv_cpufreq_read_pmax(void *data)
 {
unsigned int cpu = smp_processor_id();
unsigned long pmsr;
-   int pmsr_pmax, i;
+   int pmsr_pmax, i, index;
 
pmsr = get_pmspr(SPRN_PMSR);
 
@@ -321,28 +347,43 @@ static void powernv_cpufreq_throttle_check(void *data)
if (chips[i].id == cpu_to_chip_id(cpu))
break;
 
-   /* Check for Pmax Capping */
pmsr_pmax = (s8)PMSR_MAX(pmsr);
if (pmsr_pmax != powernv_pstate_info.max) {
if (chips[i].throttled)
-   goto next;
+   return;
chips[i].throttled = true;
-   if (pmsr_pmax < powernv_pstate_info.nominal)
-   pr_crit("CPU %d on Chip %u has Pmax reduced below 
nominal frequency (%d < %d)\n",
-   cpu, chips[i].id, pmsr_pmax,
+   if (pmsr_pmax < powernv_pstate_info.nominal) {
+   pr_warn_once("CPU %d on Chip %u has Pmax reduced below 
nominal frequency (%d < %d)\n",
+cpu, chips[i].id, pmsr_pmax,

[PATCH v3 0/2] cpufreq: powernv: Redesign the presentation of throttle notification

[Shilpasri G Bhat]

In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the
CPU when the chip crosses its thermal and power limits. Currently,
powernv-cpufreq driver detects and reports this event as a console
message. Some boxes may not sustain the max turbo frequency in all
conditions and can be throttled frequently. This can lead to the
flooding of console with throttle messages. So this patchset aims to
redesign the presentation of this event via sysfs counters and
tracepoints. 

This patchset will add a perf trace point "power:powernv_throttle" and
sysfs throttle counter stats in /sys/devices/system/cpu/cpufreq/chipN.

Changes from v2:
- Fixed kbuild test warning.
drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return
value of 'kstrtoint', declared with attribute warn_unused_result
[-Wunused-result]

Shilpasri G Bhat (2):
  cpufreq: powernv/tracing: Add powernv_throttle tracepoint
  cpufreq: powernv: Redesign the presentation of throttle notification

 drivers/cpufreq/powernv-cpufreq.c | 256 +++---
 include/trace/events/power.h  |  22 
 kernel/trace/power-traces.c   |   1 +
 3 files changed, 236 insertions(+), 43 deletions(-)

-- 
1.9.3

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

[PATCH v3 1/2] cpufreq: powernv/tracing: Add powernv_throttle tracepoint

[Shilpasri G Bhat]

This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.

Signed-off-by: Shilpasri G Bhat 
CC: Ingo Molnar 
CC: Steven Rostedt 
---
No changes from v2.

Changes from v1:
- Export the tracepoint

 include/trace/events/power.h | 22 ++
 kernel/trace/power-traces.c  |  1 +
 2 files changed, 23 insertions(+)

diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..19e5030 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -38,6 +38,28 @@ DEFINE_EVENT(cpu, cpu_idle,
TP_ARGS(state, cpu_id)
 );
 
+TRACE_EVENT(powernv_throttle,
+
+   TP_PROTO(int chip_id, const char *reason, int pmax),
+
+   TP_ARGS(chip_id, reason, pmax),
+
+   TP_STRUCT__entry(
+   __field(int, chip_id)
+   __string(reason, reason)
+   __field(int, pmax)
+   ),
+
+   TP_fast_assign(
+   __entry->chip_id = chip_id;
+   __assign_str(reason, reason);
+   __entry->pmax = pmax;
+   ),
+
+   TP_printk("Chip %d Pmax %d %s", __entry->chip_id,
+ __entry->pmax, __get_str(reason))
+);
+
 TRACE_EVENT(pstate_sample,
 
TP_PROTO(u32 core_busy,
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index eb4220a..81b8745 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -15,4 +15,5 @@
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume);
 EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle);
+EXPORT_TRACEPOINT_SYMBOL_GPL(powernv_throttle);
 
-- 
1.9.3

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

Pull request: scottwood/linux.git next

[Scott Wood]

Highlights include moving QE code out of arch/powerpc (to be shared with
arm), device tree updates, and minor fixes.

Sorry for sending this in so late and not getting to everything in my
queue -- in addition to the holidays I've been slowed down by email
troubles and a broken arm.

The following changes since commit e9d764f803964a54ca7da4a67d124fe824ebd80a:

  powerpc/pseries: Enable kernel CPU dlpar from sysfs (2015-12-17 22:41:03 
+1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next

for you to fetch changes up to 44451d4d8f0e35153b3e7e3d40e198f2cf9ac36a:

  MAINTAINERS: Update Scott Wood's e-mail address (2015-12-31 12:57:26 -0600)


Daniel Walker (1):
  powerpc/85xx: mpc85xx ADS: remove pci exclude

Harninder Rai (2):
  powerpc/fsl: Add PCI node in device tree of bsc9132qds
  powerpc/85xx: Add PCIe controller support for bsc9132qds

Hongtao Jia (3):
  dt-bindings: Add QorIQ TMU thermal bindings
  powerpc/mpc85xx: Add TMU device tree support for T1040/T1042
  powerpc/mpc85xx: Add TMU device tree support for T1023/T1024

Igal Liberman (1):
  powerpc/mpc85xx: Update B4 FMan MURAM size

Raghav Dogra (1):
  powerpc/fsl_lbc: removal of dead code

Scott Wood (2):
  powerpc/e6500: add locking to hugetlb
  MAINTAINERS: Update Scott Wood's e-mail address

Zhao Qiang (7):
  genalloc:support memory-allocation with bytes-alignment to genalloc
  genalloc:support allocating specific region
  CPM/QE: use genalloc to manage CPM/QE muram
  QE/CPM: move muram management functions to qe_common
  QE: use subsys_initcall to init qe
  QE: Move QE from arch/powerpc to drivers/soc
  powerpc/p1010rdb: Update dts for pcie interrupt-map

li pengbo (1):
  powerpc/85xx: Enable TWR_P102x in mpc85xx_basic_defconfig

 .../devicetree/bindings/thermal/qoriq-thermal.txt  |  63 ++
 MAINTAINERS|   7 +-
 arch/powerpc/Kconfig   |   2 -
 arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |   5 +
 arch/powerpc/boot/dts/fsl/bsc9132qds.dts   |  15 ++
 arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi  |  28 +++
 arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi   |   1 +
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi|  16 ++
 arch/powerpc/boot/dts/fsl/t1023rdb.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi|  86 
 arch/powerpc/boot/dts/fsl/t1024qds.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1024rdb.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1024si-post.dtsi|   2 +-
 arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi |   2 +
 arch/powerpc/boot/dts/fsl/t1040d4rdb.dts   |   2 +-
 arch/powerpc/boot/dts/fsl/t1040qds.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1040rdb.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|  94 +
 arch/powerpc/boot/dts/fsl/t1042d4rdb.dts   |   2 +-
 arch/powerpc/boot/dts/fsl/t1042qds.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1042rdb.dts |   2 +-
 arch/powerpc/boot/dts/fsl/t1042rdb_pi.dts  |   2 +-
 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi|   2 +-
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi |   4 +
 arch/powerpc/configs/mpc85xx_basic_defconfig   |   1 +
 arch/powerpc/include/asm/cpm.h |  44 +---
 arch/powerpc/mm/hugetlbpage-book3e.c   |  46 
 arch/powerpc/platforms/83xx/km83xx.c   |   6 +-
 arch/powerpc/platforms/83xx/misc.c |   2 +-
 arch/powerpc/platforms/83xx/mpc832x_mds.c  |   6 +-
 arch/powerpc/platforms/83xx/mpc832x_rdb.c  |   6 +-
 arch/powerpc/platforms/83xx/mpc836x_mds.c  |   6 +-
 arch/powerpc/platforms/83xx/mpc836x_rdk.c  |   7 +-
 arch/powerpc/platforms/85xx/bsc913x_qds.c  |   8 +-
 arch/powerpc/platforms/85xx/common.c   |   3 +-
 arch/powerpc/platforms/85xx/corenet_generic.c  |   2 +-
 arch/powerpc/platforms/85xx/mpc85xx_ads.c  |  15 --
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |   4 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |   4 +-
 arch/powerpc/platforms/85xx/twr_p102x.c|   4 +-
 arch/powerpc/platforms/Kconfig |  13 +-
 arch/powerpc/sysdev/Makefile   |   1 -
 arch/powerpc/sysdev/cpm_common.c   | 158 +-
 arch/powerpc/sysdev/fsl_lbc.c  |   2 -
 arch/powerpc/sysdev/fsl_pci.c  |  13 ++
 drivers/net/ethernet/freescale/fsl_pq_mdio.c   |   2 +-
 drivers/net/ethernet/freescale/ucc_geth.c  |   8 +-
 drivers/net/ethernet/freescale/ucc_geth.h  |   8 +-
 drivers/soc/Kconfig|   1 +
 drivers/soc/Makefile   |   1 +
 

Re: [PATCH v2 20/32] metag: define __smp_xxx

[James Hogan]

Hi Michael,

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> This defines __smp_xxx barriers for metag,
> for use by virtualization.
> 
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not
> use the existing fence() macro since that is defined differently between
> SMP and !SMP.  For this reason, this patch introduces a wrapper
> metag_fence() that doesn't depend on CONFIG_SMP.
> fence() is then defined using that, depending on CONFIG_SMP.

I'm not a fan of the inconsistent commit message wrapping. I wrap to 72
columns (although I now notice SubmittingPatches says to use 75...).

> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 
> ---
>  arch/metag/include/asm/barrier.h | 32 +++-
>  1 file changed, 15 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/metag/include/asm/barrier.h 
> b/arch/metag/include/asm/barrier.h
> index b5b778b..84880c9 100644
> --- a/arch/metag/include/asm/barrier.h
> +++ b/arch/metag/include/asm/barrier.h
> @@ -44,13 +44,6 @@ static inline void wr_fence(void)
>  #define rmb()barrier()
>  #define wmb()mb()
>  
> -#ifndef CONFIG_SMP
> -#define fence()  do { } while (0)
> -#define smp_mb()barrier()
> -#define smp_rmb()   barrier()
> -#define smp_wmb()   barrier()
> -#else

!SMP kernel text differs, but only because of new presence of unused
metag_fence() inline function. If I #if 0 that out, then it matches, so
thats fine.

> -
>  #ifdef CONFIG_METAG_SMP_WRITE_REORDERING
>  /*
>   * Write to the atomic memory unlock system event register (command 0). This 
> is
> @@ -60,26 +53,31 @@ static inline void wr_fence(void)
>   * incoherence). It is therefore ineffective if used after and on the same
>   * thread as a write.
>   */
> -static inline void fence(void)
> +static inline void metag_fence(void)
>  {
>   volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK;
>   barrier();
>   *flushptr = 0;
>   barrier();
>  }
> -#define smp_mb()fence()
> -#define smp_rmb()   fence()
> -#define smp_wmb()   barrier()
> +#define __smp_mb()metag_fence()
> +#define __smp_rmb()   metag_fence()
> +#define __smp_wmb()   barrier()
>  #else
> -#define fence()  do { } while (0)
> -#define smp_mb()barrier()
> -#define smp_rmb()   barrier()
> -#define smp_wmb()   barrier()
> +#define metag_fence()do { } while (0)
> +#define __smp_mb()barrier()
> +#define __smp_rmb()   barrier()
> +#define __smp_wmb()   barrier()

Whitespace is now messed up. Admitedly its already inconsistent
tabs/spaces, but it'd be nice if the definitions at least still all
lined up. You're touching all the definitions which use spaces anyway,
so feel free to convert them to tabs while you're at it.

Other than those niggles, it looks sensible to me:
Acked-by: James Hogan 

Cheers
James

>  #endif
> +
> +#ifdef CONFIG_SMP
> +#define fence() metag_fence()
> +#else
> +#define fence()  do { } while (0)
>  #endif
>  
> -#define smp_mb__before_atomic()  barrier()
> -#define smp_mb__after_atomic()   barrier()
> +#define __smp_mb__before_atomic()barrier()
> +#define __smp_mb__after_atomic() barrier()
>  
>  #include 
>  
> -- 
> MST
> 


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

Re: [PATCH 3/3] checkpatch: add virt barriers

[Joe Perches]

On Mon, 2016-01-04 at 23:07 +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 04, 2016 at 08:47:53AM -0800, Joe Perches wrote:
> > On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote:
> > > Add virt_ barriers to list of barriers to check for
> > > presence of a comment.
> > 
> > Are these virt_ barriers used anywhere?
> > 
> > I see some virtio_ barrier like uses.
> 
> They will be :) They are added and used by patchset
>   arch: barrier cleanup + barriers for virt
> 
> See
> http://article.gmane.org/gmane.linux.kernel.virtualization/26555

Ah, OK, thanks.

Are the virtio_ barriers going away?
If not, maybe those should be added too.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] checkpatch.pl: add missing memory barriers

[Joe Perches]

On Mon, 2016-01-04 at 22:45 +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote:
> > On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote:
> > > SMP-only barriers were missing in checkpatch.pl
> > > 
> > > Refactor code slightly to make adding more variants easier.
> > > 
> > > Signed-off-by: Michael S. Tsirkin 
> > > ---
> > >  scripts/checkpatch.pl | 9 -
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index 2b3c228..0245bbe 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -5116,7 +5116,14 @@ sub process {
> > >   }
> > >   }
> > >  # check for memory barriers without a comment.
> > > - if ($line =~ 
> > > /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/)
> > >  {
> > > +
> > > + my @barriers = ('mb', 'rmb', 'wmb', 'read_barrier_depends');
> > > + my @smp_barriers = ('smp_store_release', 'smp_load_acquire', 
> > > 'smp_store_mb');
> > > +
> > > + @smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);
> > 
> > I think using map, which so far checkpatch doesn't use,
> > makes smp_barriers harder to understand and it'd be
> > better to enumerate them.
> 
> Okay - I'll rewrite using foreach.
> 

I think using the qr form (like 'our $Attribute' and
a bunch of others) is the general style that should
be used for checkpatch.

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

Re: [RFC PATCH v2 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

[Benjamin Herrenschmidt]

On Mon, 2016-01-04 at 14:07 -0700, Alex Williamson wrote:
> On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
> > Current vfio-pci implementation disallows to mmap MSI-X
> > table in case that user get to touch this directly.
> > 
> > However, EEH mechanism can ensure that a given pci device
> > can only shoot the MSIs assigned for its PE. So we think
> > it's safe to expose the MSI-X table to userspace because
> > the exposed MSI-X table can't be used to do harm to other
> > memory space.
> > 
> > And with MSI-X table mmapped, some performance issues which
> > are caused when PCI adapters have critical registers in the
> > same page as the MSI-X table also can be resolved.
> > 
> > So this patch adds a Kconfig option, VFIO_PCI_MMAP_MSIX,
> > to support for mmapping MSI-X table.
> > 
> > Signed-off-by: Yongji Xie 
> > ---
> >  drivers/vfio/pci/Kconfig|4 
> >  drivers/vfio/pci/vfio_pci.c |6 --
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> > index 02912f1..67b0a2c 100644
> > --- a/drivers/vfio/pci/Kconfig
> > +++ b/drivers/vfio/pci/Kconfig
> > @@ -23,6 +23,10 @@ config VFIO_PCI_MMAP
> >     depends on VFIO_PCI
> >     def_bool y if !S390
> >  
> > +config VFIO_PCI_MMAP_MSIX
> > +   depends on VFIO_PCI_MMAP
> > +   def_bool y if EEH
> 
> Does CONFIG_EEH necessarily mean the EEH is enabled?  Could the
> system
> not support EEH or could EEH be disabled via kernel commandline
> options?

EEH is definitely the wrong thing to test here anyway. What needs to be
tested is that the PCI Host bridge supports filtering of MSIs, so
ideally this should be some kind of host bridge attribute set by the
architecture backend.

This can happen with or without CONFIG_EEH and you are right,
CONFIG_EEH can be enabled and the machine not support it.

Any IODA bridge will support this.

Cheers,
Ben.

> > +
> >  config VFIO_PCI_INTX
> >     depends on VFIO_PCI
> >     def_bool y if !S390
> > diff --git a/drivers/vfio/pci/vfio_pci.c
> > b/drivers/vfio/pci/vfio_pci.c
> > index 09b3805..d536985 100644
> > --- a/drivers/vfio/pci/vfio_pci.c
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -555,7 +555,8 @@ static long vfio_pci_ioctl(void *device_data,
> >     IORESOURCE_MEM && (info.size >=
> > PAGE_SIZE ||
> >     pci_resource_page_aligned)) {
> >     info.flags |=
> > VFIO_REGION_INFO_FLAG_MMAP;
> > -   if (info.index == vdev->msix_bar)
> > {
> > +   if
> > (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP_MSIX) &&
> > +   info.index == vdev->msix_bar)
> > {
> >     ret =
> > msix_sparse_mmap_cap(vdev, );
> >     if (ret)
> >     return ret;
> > @@ -967,7 +968,8 @@ static int vfio_pci_mmap(void *device_data,
> > struct vm_area_struct *vma)
> >     if (phys_len < PAGE_SIZE || req_start + req_len >
> > phys_len)
> >     return -EINVAL;
> >  
> > -   if (index == vdev->msix_bar) {
> > +   if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP_MSIX) &&
> > +   index == vdev->msix_bar) {
> >     /*
> >      * Disallow mmaps overlapping the MSI-X table;
> > users
> > don't
> >      * get to touch this directly.  We could find
> > somewhere
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc64: select HAVE_CONTEXT_TRACKING by default

[Shi, Yang]

Hi folks,

Any comment on this is appreciated.

Thanks,
Yang


On 12/9/2015 2:43 PM, Yang Shi wrote:

The functionality of context tracking has been implemented by PPC64 and
HAVE_CONTEXT_TRACKING was selected by pseries by default.
Actually, it is applicale to all PPC64 platforms, so select it in PPC64
generic Kconfig.

NO_HZ_FULL depends on it, with this change NO_HZ_FULL could be enabled
for all PPC64 machines.

Signed-off-by: Yang Shi 
---
Following the instruction in Documentation/timers/NO_HZ.txt, I tested full nohz
on my FSL T2080 target, the below trace log shows it works well.

user_loop-574   [001] d..1   137.044892: tick_stop: success=yes msg=
user_loop-574   [001] d.h1   138.044880: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=137796002092
user_loop-574   [001] d.h1   139.044880: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=138796002129
user_loop-574   [001] d.h1   140.044880: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=139796002219
user_loop-574   [001] d.h1   141.044880: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=140796002229
user_loop-574   [001] d.h1   142.044879: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=141796002159
user_loop-574   [001] d.h1   143.044879: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=142796002142
user_loop-574   [001] d.h1   144.044878: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=143796002046
user_loop-574   [001] d.h1   145.044878: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=144796002189
user_loop-574   [001] d.h1   146.044878: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=145796002199
user_loop-574   [001] d.h1   147.044880: hrtimer_expire_entry: 
hrtimer=c0007fd22d10 function=.tick_sched_timer now=146796003836

It shows the timer tick just comes in every second.

It should be low risk to have problem on other PPC64 targets, although they are
not tested.

  arch/powerpc/platforms/Kconfig.cputype | 1 +
  arch/powerpc/platforms/pseries/Kconfig | 1 -
  2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 142dff5..7b25dd1 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -3,6 +3,7 @@ config PPC64
default n
select HAVE_VIRT_CPU_ACCOUNTING
select ZLIB_DEFLATE
+   select HAVE_CONTEXT_TRACKING
help
  This option selects whether a 32-bit or a 64-bit kernel
  will be built.
diff --git a/arch/powerpc/platforms/pseries/Kconfig 
b/arch/powerpc/platforms/pseries/Kconfig
index bec90fb..6853148 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -17,7 +17,6 @@ config PPC_PSERIES
select PPC_UDBG_16550
select PPC_NATIVE
select PPC_DOORBELL
-   select HAVE_CONTEXT_TRACKING
select HOTPLUG_CPU if SMP
select ARCH_RANDOM
select PPC_DOORBELL



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

Re: [PATCH v2 15/32] powerpc: define __smp_xxx

[Boqun Feng]

Hi Michael,

On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote:
> This defines __smp_xxx barriers for powerpc
> for use by virtualization.
> 
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> This reduces the amount of arch-specific boiler-plate code.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 
> ---
>  arch/powerpc/include/asm/barrier.h | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/barrier.h 
> b/arch/powerpc/include/asm/barrier.h
> index 980ad0c..c0deafc 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -44,19 +44,11 @@
>  #define dma_rmb()__lwsync()
>  #define dma_wmb()__asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
> :"memory")
>  
> -#ifdef CONFIG_SMP
> -#define smp_lwsync() __lwsync()
> +#define __smp_lwsync()   __lwsync()
>  

so __smp_lwsync() is always mapped to lwsync, right?

> -#define smp_mb() mb()
> -#define smp_rmb()__lwsync()
> -#define smp_wmb()__asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
> :"memory")
> -#else
> -#define smp_lwsync() barrier()
> -
> -#define smp_mb() barrier()
> -#define smp_rmb()barrier()
> -#define smp_wmb()barrier()
> -#endif /* CONFIG_SMP */
> +#define __smp_mb()   mb()
> +#define __smp_rmb()  __lwsync()
> +#define __smp_wmb()  __asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
> :"memory")
>  
>  /*
>   * This is a barrier which prevents following instructions from being
> @@ -67,18 +59,18 @@
>  #define data_barrier(x)  \
>   asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory");
>  
> -#define smp_store_release(p, v)  
> \
> +#define __smp_store_release(p, v)
> \
>  do { \
>   compiletime_assert_atomic_type(*p); \
> - smp_lwsync();   \
> + __smp_lwsync(); \

, therefore this will emit an lwsync no matter SMP or UP.

Another thing is that smp_lwsync() may have a third user(other than
smp_load_acquire() and smp_store_release()):

http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877

I'm OK to change my patch accordingly, but do we really want
smp_lwsync() get involved in this cleanup? If I understand you
correctly, this cleanup focuses on external API like smp_{r,w,}mb(),
while smp_lwsync() is internal to PPC.

Regards,
Boqun

>   WRITE_ONCE(*p, v);  \
>  } while (0)
>  
> -#define smp_load_acquire(p)  \
> +#define __smp_load_acquire(p)
> \
>  ({   \
>   typeof(*p) ___p1 = READ_ONCE(*p);   \
>   compiletime_assert_atomic_type(*p); \
> - smp_lwsync();   \
> + __smp_lwsync(); \
>   ___p1;  \
>  })
>  
> -- 
> MST
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> On s390 read_barrier_depends, smp_read_barrier_depends
> smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> asm-generic variants exactly. Drop the local definitions and pull in
> asm-generic/barrier.h instead.
> 
> This is in preparation to refactoring this code area.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 
> ---
>  arch/s390/include/asm/barrier.h | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> index 7ffd0b1..c358c31 100644
> --- a/arch/s390/include/asm/barrier.h
> +++ b/arch/s390/include/asm/barrier.h
> @@ -30,14 +30,6 @@
>  #define smp_rmb()rmb()
>  #define smp_wmb()wmb()
>  
> -#define read_barrier_depends()   do { } while (0)
> -#define smp_read_barrier_depends()   do { } while (0)
> -
> -#define smp_mb__before_atomic()  smp_mb()
> -#define smp_mb__after_atomic()   smp_mb()

As per:

  lkml.kernel.org/r/20150921112252.3c2937e1@mschwide

s390 should change this to barrier() instead of smp_mb() and hence
should not use the generic versions.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 22/32] s390: define __smp_xxx

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:08:38PM +0200, Michael S. Tsirkin wrote:
> This defines __smp_xxx barriers for s390,
> for use by virtualization.
> 
> Some smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> Note: smp_mb, smp_rmb and smp_wmb are defined as full barriers
> unconditionally on this architecture.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 
> ---
>  arch/s390/include/asm/barrier.h | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> index c358c31..fbd25b2 100644
> --- a/arch/s390/include/asm/barrier.h
> +++ b/arch/s390/include/asm/barrier.h
> @@ -26,18 +26,21 @@
>  #define wmb()barrier()
>  #define dma_rmb()mb()
>  #define dma_wmb()mb()
> -#define smp_mb() mb()
> -#define smp_rmb()rmb()
> -#define smp_wmb()wmb()
> -
> -#define smp_store_release(p, v)  
> \
> +#define __smp_mb()   mb()
> +#define __smp_rmb()  rmb()
> +#define __smp_wmb()  wmb()
> +#define smp_mb() __smp_mb()
> +#define smp_rmb()__smp_rmb()
> +#define smp_wmb()__smp_wmb()

Why define the smp_*mb() primitives here? Would not the inclusion of
asm-generic/barrier.h do this?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Peter Zijlstra]

On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:

> > My only concern is that it gives people an additional handle onto a
> > "new" set of barriers - just because they're prefixed with __*
> > unfortunately doesn't stop anyone from using it (been there with
> > other arch stuff before.)
> > 
> > I wonder whether we should consider making the smp memory barriers
> > inline functions, so these __smp_xxx() variants can be undef'd
> > afterwards, thereby preventing drivers getting their hands on these
> > new macros?
> 
> That'd be tricky to do cleanly since asm-generic depends on
> ifndef to add generic variants where needed.
> 
> But it would be possible to add a checkpatch test for this.

Wasn't the whole purpose of these things for 'drivers' (namely
virtio/xen hypervisor interaction) to use these?

And I suppose most of virtio would actually be modules, so you cannot do
what I did with preempt_enable_no_resched() either.

But yes, it would be good to limit the use of these things.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 20/32] metag: define __smp_xxx

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> +#ifdef CONFIG_SMP
> +#define fence() metag_fence()
> +#else
> +#define fence()  do { } while (0)
>  #endif

James, it strikes me as odd that fence() is a no-op instead of a
barrier() for UP, can you verify/explain?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:09:47PM +0200, Michael S. Tsirkin wrote:
> At the moment, xchg on sh only supports 4 and 1 byte values, so using it
> from smp_store_mb means attempts to store a 2 byte value using this
> macro fail.
> 
> And happens to be exactly what virtio drivers want to do.
> 
> Check size and fall back to a slower, but safe, WRITE_ONCE+smp_mb.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  arch/sh/include/asm/barrier.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/sh/include/asm/barrier.h b/arch/sh/include/asm/barrier.h
> index f887c64..0cc5735 100644
> --- a/arch/sh/include/asm/barrier.h
> +++ b/arch/sh/include/asm/barrier.h
> @@ -32,7 +32,15 @@
>  #define ctrl_barrier()   __asm__ __volatile__ 
> ("nop;nop;nop;nop;nop;nop;nop;nop")
>  #endif
>  
> -#define __smp_store_mb(var, value) do { (void)xchg(, value); } while (0)
> +#define __smp_store_mb(var, value) do { \
> + if (sizeof(var) != 4 && sizeof(var) != 1) { \
> +  WRITE_ONCE(var, value); \
> + __smp_mb(); \
> + } else { \
> + (void)xchg(, value);  \
> + } \
> +} while (0)

So SH is an orphaned arch, which is also why I did not comment on using
xchg() for the UP smp_store_mb() thing.

But I really think we should try fixing the xchg() implementation
instead of this duct-tape.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 11/32] mips: reuse asm-generic/barrier.h

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:07:10PM +0200, Michael S. Tsirkin wrote:
> -#define smp_store_release(p, v)  
> \
> -do { \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb();   \
> - WRITE_ONCE(*p, v);  \
> -} while (0)
> -
> -#define smp_load_acquire(p)  \
> -({   \
> - typeof(*p) ___p1 = READ_ONCE(*p);   \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb();   \
> - ___p1;  \
> -})

David Daney wanted to use fancy new MIPS barriers to provide better
implementations of this.

This patch isn't in the way of that, just a FYI.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Peter Zijlstra]

On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
> On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> 
> > > My only concern is that it gives people an additional handle onto a
> > > "new" set of barriers - just because they're prefixed with __*
> > > unfortunately doesn't stop anyone from using it (been there with
> > > other arch stuff before.)
> > > 
> > > I wonder whether we should consider making the smp memory barriers
> > > inline functions, so these __smp_xxx() variants can be undef'd
> > > afterwards, thereby preventing drivers getting their hands on these
> > > new macros?
> > 
> > That'd be tricky to do cleanly since asm-generic depends on
> > ifndef to add generic variants where needed.
> > 
> > But it would be possible to add a checkpatch test for this.
> 
> Wasn't the whole purpose of these things for 'drivers' (namely
> virtio/xen hypervisor interaction) to use these?

Ah, I see, you add virt_*mb() stuff later on for that use case.

So, assuming everybody does include asm-generic/barrier.h, you could
simply #undef the __smp version at the end of that, once we've generated
all the regular primitives from it, no?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
> > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote:
> > 
> > > > My only concern is that it gives people an additional handle onto a
> > > > "new" set of barriers - just because they're prefixed with __*
> > > > unfortunately doesn't stop anyone from using it (been there with
> > > > other arch stuff before.)
> > > > 
> > > > I wonder whether we should consider making the smp memory barriers
> > > > inline functions, so these __smp_xxx() variants can be undef'd
> > > > afterwards, thereby preventing drivers getting their hands on these
> > > > new macros?
> > > 
> > > That'd be tricky to do cleanly since asm-generic depends on
> > > ifndef to add generic variants where needed.
> > > 
> > > But it would be possible to add a checkpatch test for this.
> > 
> > Wasn't the whole purpose of these things for 'drivers' (namely
> > virtio/xen hypervisor interaction) to use these?
> 
> Ah, I see, you add virt_*mb() stuff later on for that use case.
> 
> So, assuming everybody does include asm-generic/barrier.h, you could
> simply #undef the __smp version at the end of that, once we've generated
> all the regular primitives from it, no?

Not so simple - that's why I mentioned using inline functions.

The new smp_* _macros_ are:

+#define smp_mb()   __smp_mb()

which means if we simply #undef __smp_mb(), smp_mb() then points at
something which is no longer available, and we'll end up with errors
saying that __smp_mb() doesn't exist.

My suggestion was to change:

#ifndef smp_mb
#define smp_mb()__smp_mb()
#endif

to:

#ifndef smp_mb
static inline void smp_mb(void)
{
__smp_mb();
}
#endif

which then means __smp_mb() and friends can be #undef'd afterwards.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers

[Peter Zijlstra]

On Thu, Dec 31, 2015 at 09:10:01PM +0200, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/xen/xenbus/xenbus_comms.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..ecdecce 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
>   avail = len;
>  
>   /* Must write data /after/ reading the consumer index. */
> - mb();
> + virt_mb();
>  

So its possible to remove this barrier entirely, see the "CONTROL
DEPENDNCIES" chunk of memory-barrier.txt.

But do that in a separate patch series and only if you really really
need the performance.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 20/32] metag: define __smp_xxx

[Peter Zijlstra]

On Mon, Jan 04, 2016 at 03:25:58PM +, James Hogan wrote:
> It is used along with the metag specific __global_lock1() (global
> voluntary lock between hw threads) whenever a write is performed, and by
> smp_mb/smp_rmb to try to catch other cases, but I've never been
> confident this fixes every single corner case, since there could be
> other places where multiple CPUs perform unsynchronised writes to the
> same memory location, and expect cache not to become incoherent at that
> location.

Ah, yuck, I thought blackfin was the only one attempting !coherent SMP.
And yes, this is bound to break in lots of places in subtle ways. We
very much assume cache coherency for SMP in generic code.

> It seemed to be sufficient to achieve stability however, and SMP on Meta
> Linux never made it into a product anyway, since the other hw thread
> tended to be used for RTOS stuff, so it didn't seem worth extending the
> generic barrier API for it.

*phew*, should we take it out then, just to be sure nobody accidentally
tries to use it then?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 20/32] metag: define __smp_xxx

[James Hogan]

Hi Peter,

On Mon, Jan 04, 2016 at 02:41:28PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> > +#ifdef CONFIG_SMP
> > +#define fence() metag_fence()
> > +#else
> > +#define fence()do { } while (0)
> >  #endif
> 
> James, it strikes me as odd that fence() is a no-op instead of a
> barrier() for UP, can you verify/explain?

fence() is an unfortunate workaround for a specific issue on a certain
SoC, where writes from different hw threads get reordered outside of the
core, resulting in incoherency between RAM and cache. It has slightly
different semantics to the normal SMP barriers, since I was assured it
is required before a write rather than after it.

Here's the comment:

> This is needed before a write to shared memory in a critical section,
> to prevent external reordering of writes before the fence on other
> threads with writes after the fence on this thread (and to prevent the
> ensuing cache-memory incoherence). It is therefore ineffective if used
> after and on the same thread as a write.

It is used along with the metag specific __global_lock1() (global
voluntary lock between hw threads) whenever a write is performed, and by
smp_mb/smp_rmb to try to catch other cases, but I've never been
confident this fixes every single corner case, since there could be
other places where multiple CPUs perform unsynchronised writes to the
same memory location, and expect cache not to become incoherent at that
location.

It seemed to be sufficient to achieve stability however, and SMP on Meta
Linux never made it into a product anyway, since the other hw thread
tended to be used for RTOS stuff, so it didn't seem worth extending the
generic barrier API for it.

Cheers
James


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

Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

[Martin Schwidefsky]

On Mon, 4 Jan 2016 14:20:42 +0100
Peter Zijlstra  wrote:

> On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote:
> > On s390 read_barrier_depends, smp_read_barrier_depends
> > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> > asm-generic variants exactly. Drop the local definitions and pull in
> > asm-generic/barrier.h instead.
> > 
> > This is in preparation to refactoring this code area.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > Acked-by: Arnd Bergmann 
> > ---
> >  arch/s390/include/asm/barrier.h | 10 ++
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/s390/include/asm/barrier.h 
> > b/arch/s390/include/asm/barrier.h
> > index 7ffd0b1..c358c31 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -30,14 +30,6 @@
> >  #define smp_rmb()  rmb()
> >  #define smp_wmb()  wmb()
> >  
> > -#define read_barrier_depends() do { } while (0)
> > -#define smp_read_barrier_depends() do { } while (0)
> > -
> > -#define smp_mb__before_atomic()smp_mb()
> > -#define smp_mb__after_atomic() smp_mb()
> 
> As per:
> 
>   lkml.kernel.org/r/20150921112252.3c2937e1@mschwide
> 
> s390 should change this to barrier() instead of smp_mb() and hence
> should not use the generic versions.
 
Yes, we wanted to simplify this. Thanks for the reminder, I'll queue
a patch.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

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

Re: [PATCH 1/3] checkpatch.pl: add missing memory barriers

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote:
> On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote:
> > +   my $all_barriers = join('|', (@barriers, @smp_barriers));
> > +
> > +   if ($line =~ /\b($all_barriers)\(/) {
> 
> It would be better to use /\b$all_barriers\s*\(/
> as there's no reason for the capture and there
> could be a space between the function and the
> open parenthesis.

I think you mean

/\b(?:$all_barriers)\s*\(/

as 'all_barriers' will be:

mb|wmb|rmb|smp_mb|smp_wmb|smp_rmb

and putting that into your suggestion results in:

/\bmb|wmb|rmb|smp_mb|smp_wmb|smp_rmb\s*\(/

which is clearly wrong - the \b only applies to 'mb' and the \s*\( only
applies to smp_rmb.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] checkpatch.pl: add missing memory barriers

[Joe Perches]

On Mon, 2016-01-04 at 16:11 +, Russell King - ARM Linux wrote:
> On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote:
> > On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote:
> > > + my $all_barriers = join('|', (@barriers, @smp_barriers));
> > > +
> > > + if ($line =~ /\b($all_barriers)\(/) {
> > 
> > It would be better to use /\b$all_barriers\s*\(/
> > as there's no reason for the capture and there
> > could be a space between the function and the
> > open parenthesis.
> 
> I think you mean
> 
>   /\b(?:$all_barriers)\s*\(/
> 
> as 'all_barriers' will be:
> 
>   mb|wmb|rmb|smp_mb|smp_wmb|smp_rmb
> 
> and putting that into your suggestion results in:
> 
>   /\bmb|wmb|rmb|smp_mb|smp_wmb|smp_rmb\s*\(/
> 
> which is clearly wrong - the \b only applies to 'mb' and the \s*\( only
> applies to smp_rmb.

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

Re: [PATCH v2 20/32] metag: define __smp_xxx

[James Hogan]

On Mon, Jan 04, 2016 at 04:30:36PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 04, 2016 at 03:25:58PM +, James Hogan wrote:
> > It is used along with the metag specific __global_lock1() (global
> > voluntary lock between hw threads) whenever a write is performed, and by
> > smp_mb/smp_rmb to try to catch other cases, but I've never been
> > confident this fixes every single corner case, since there could be
> > other places where multiple CPUs perform unsynchronised writes to the
> > same memory location, and expect cache not to become incoherent at that
> > location.
> 
> Ah, yuck, I thought blackfin was the only one attempting !coherent SMP.
> And yes, this is bound to break in lots of places in subtle ways. We
> very much assume cache coherency for SMP in generic code.

Well, its usually completely coherent, its just a bit dodgy in a
particular hardware corner case, which was pretty hard to hit, even
without these workarounds.

> 
> > It seemed to be sufficient to achieve stability however, and SMP on Meta
> > Linux never made it into a product anyway, since the other hw thread
> > tended to be used for RTOS stuff, so it didn't seem worth extending the
> > generic barrier API for it.
> 
> *phew*, should we take it out then, just to be sure nobody accidentally
> tries to use it then?

SMP support on this SoC you mean? I doubt it'll be a problem tbh, and
it'd work fine in QEMU when emulating this SoC, so I'd prefer to keep it
in.

Cheers
James


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

Re: [PATCH 1/3] checkpatch.pl: add missing memory barriers

[Joe Perches]

On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote:
> SMP-only barriers were missing in checkpatch.pl
> 
> Refactor code slightly to make adding more variants easier.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  scripts/checkpatch.pl | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 2b3c228..0245bbe 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5116,7 +5116,14 @@ sub process {
>   }
>   }
>  # check for memory barriers without a comment.
> - if ($line =~ 
> /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/)
>  {
> +
> + my @barriers = ('mb', 'rmb', 'wmb', 'read_barrier_depends');
> + my @smp_barriers = ('smp_store_release', 'smp_load_acquire', 
> 'smp_store_mb');
> +
> + @smp_barriers = (@smp_barriers, map {"smp_" . $_} @barriers);

I think using map, which so far checkpatch doesn't use,
makes smp_barriers harder to understand and it'd be
better to enumerate them.

> + my $all_barriers = join('|', (@barriers, @smp_barriers));
> +
> + if ($line =~ /\b($all_barriers)\(/) {

It would be better to use /\b$all_barriers\s*\(/
as there's no reason for the capture and there
could be a space between the function and the
open parenthesis.


>   if (!ctx_has_comment($first_line, $linenr)) {
>   WARN("MEMORY_BARRIER",
>    "memory barrier without comment\n" . 
> $herecurr);

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

Re: [PATCH v2 10/32] metag: reuse asm-generic/barrier.h

[James Hogan]

On Thu, Dec 31, 2015 at 09:07:02PM +0200, Michael S. Tsirkin wrote:
> On metag dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends,
> smp_read_barrier_depends, smp_store_release and smp_load_acquire  match
> the asm-generic variants exactly. Drop the local definitions and pull in
> asm-generic/barrier.h instead.
> 
> This is in preparation to refactoring this code area.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Looks good, and confirmed no text change (once patch 1 is applied that
is).

Acked-by: James Hogan 

Thanks
James

> ---
>  arch/metag/include/asm/barrier.h | 25 ++---
>  1 file changed, 2 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/metag/include/asm/barrier.h 
> b/arch/metag/include/asm/barrier.h
> index 172b7e5..b5b778b 100644
> --- a/arch/metag/include/asm/barrier.h
> +++ b/arch/metag/include/asm/barrier.h
> @@ -44,9 +44,6 @@ static inline void wr_fence(void)
>  #define rmb()barrier()
>  #define wmb()mb()
>  
> -#define dma_rmb()rmb()
> -#define dma_wmb()wmb()
> -
>  #ifndef CONFIG_SMP
>  #define fence()  do { } while (0)
>  #define smp_mb()barrier()
> @@ -81,27 +78,9 @@ static inline void fence(void)
>  #endif
>  #endif
>  
> -#define read_barrier_depends()   do { } while (0)
> -#define smp_read_barrier_depends()   do { } while (0)
> -
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } 
> while (0)
> -
> -#define smp_store_release(p, v)  
> \
> -do { \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb();   \
> - WRITE_ONCE(*p, v);  \
> -} while (0)
> -
> -#define smp_load_acquire(p)  \
> -({   \
> - typeof(*p) ___p1 = READ_ONCE(*p);   \
> - compiletime_assert_atomic_type(*p); \
> - smp_mb();   \
> - ___p1;  \
> -})
> -
>  #define smp_mb__before_atomic()  barrier()
>  #define smp_mb__after_atomic()   barrier()
>  
> +#include 
> +
>  #endif /* _ASM_METAG_BARRIER_H */
> -- 
> MST
> 


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

Re: [PATCH 3/3] checkpatch: add virt barriers

[Joe Perches]

On Mon, 2016-01-04 at 13:37 +0200, Michael S. Tsirkin wrote:
> Add virt_ barriers to list of barriers to check for
> presence of a comment.

Are these virt_ barriers used anywhere?

I see some virtio_ barrier like uses.

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