Re: [PATCH] Bugfix: powerpc/eeh: Create eeh sysfs entry in post_init()

2014-06-25 Thread Wei Yang 
On Wed, Jun 25, 2014 at 03:33:12PM +1000, Gavin Shan wrote:
On Tue, Jun 24, 2014 at 11:32:07PM -0400, Mike Qiu wrote:

[ cc Richard ]

Eeh sysfs entry created must be after EEH_ENABLED been set
in eeh_subsystem_flags.

In PowerNV platform, it try to create sysfs entry before
EEH_ENABLED been set, when boot up. So nothing will be
created for eeh in sysfs.


Could you please make the commit log more clear? :-)

I guess the issue is introduced by commit 2213fb1 (
powerpc/eeh: Skip eeh sysfs when eeh is disabled). The
commit checks EEH is enabled while creating PCI device
EEH sysfs files. If not, the sysfs files won't be created.
That's to avoid warning reported during PCI hotplug.

The problem you're reporting (if I understand completely):
You don't see the sysfs files after the system boots up.
If it's the case, you probably need following changes in
arch/powerpc/platforms/powernv/pci.c::pnv_pci_ioda_fixup().
Could you have a try with it?

#ifdef CONFIG_EEH
   eeh_probe_mode_set(EEH_PROBE_MODE_DEV);
-  eeh_addr_cache_build();
   eeh_init();
+  eeh_addr_cache_build();
#endif


I think this is a more proper fix.

BTW, I have one confusion in this mode set.

eeh_init()
  - eeh_ops-dev_probe()
 - powernv_eeh_dev_probe()
- eeh_set_enable(true)   - here the eeh is marked enabled

We can see this flag would be set for each pci_dev. So is it possible to make
this set only once?

Eventually PowerNV/pSeries have same function call sequence:

- Set EEH probe mode
- Doing probe (with device node or PCI device)
- Build address cache.

Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c 
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 8ad0c5b..5f95581 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -136,6 +136,9 @@ static int ioda_eeh_post_init(struct pci_controller *hose)
  struct pnv_phb *phb = hose-private_data;
  int ret;

+ /* Creat sysfs after EEH_ENABLED been set */
+ eeh_add_sysfs_files(hose-bus);
+
  /* Register OPAL event notifier */
  if (!ioda_eeh_nb_init) {
  ret = opal_notifier_register(ioda_eeh_nb);

Thanks,
Gavin

-- 
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Bugfix: powerpc/eeh: Create eeh sysfs entry in post_init()

2014-06-25 Thread Gavin Shan 
On Wed, Jun 25, 2014 at 02:23:53PM +0800, Wei Yang wrote:
On Wed, Jun 25, 2014 at 03:33:12PM +1000, Gavin Shan wrote:
On Tue, Jun 24, 2014 at 11:32:07PM -0400, Mike Qiu wrote:

[ cc Richard ]

Eeh sysfs entry created must be after EEH_ENABLED been set
in eeh_subsystem_flags.

In PowerNV platform, it try to create sysfs entry before
EEH_ENABLED been set, when boot up. So nothing will be
created for eeh in sysfs.


Could you please make the commit log more clear? :-)

I guess the issue is introduced by commit 2213fb1 (
powerpc/eeh: Skip eeh sysfs when eeh is disabled). The
commit checks EEH is enabled while creating PCI device
EEH sysfs files. If not, the sysfs files won't be created.
That's to avoid warning reported during PCI hotplug.

The problem you're reporting (if I understand completely):
You don't see the sysfs files after the system boots up.
If it's the case, you probably need following changes in
arch/powerpc/platforms/powernv/pci.c::pnv_pci_ioda_fixup().
Could you have a try with it?

#ifdef CONFIG_EEH
  eeh_probe_mode_set(EEH_PROBE_MODE_DEV);
- eeh_addr_cache_build();
  eeh_init();
+ eeh_addr_cache_build();
#endif


I think this is a more proper fix.

BTW, I have one confusion in this mode set.

eeh_init()
  - eeh_ops-dev_probe()
 - powernv_eeh_dev_probe()
- eeh_set_enable(true)   - here the eeh is marked enabled

We can see this flag would be set for each pci_dev. So is it possible to make
this set only once?


It shouldn't be a problem because there might not have PCI devices
supporting EEH in the guest. All PCI devices are emulated.

Eventually PowerNV/pSeries have same function call sequence:

- Set EEH probe mode
- Doing probe (with device node or PCI device)
- Build address cache.

Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c 
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 8ad0c5b..5f95581 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -136,6 +136,9 @@ static int ioda_eeh_post_init(struct pci_controller 
*hose)
 struct pnv_phb *phb = hose-private_data;
 int ret;

+/* Creat sysfs after EEH_ENABLED been set */
+eeh_add_sysfs_files(hose-bus);
+
 /* Register OPAL event notifier */
 if (!ioda_eeh_nb_init) {
 ret = opal_notifier_register(ioda_eeh_nb);

Thanks,
Gavin

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] KVM: PPC: BOOK3S: HV: Use base page size when comparing against slb value

2014-06-25 Thread Alexander Graf 


On 15.06.14 20:47, Aneesh Kumar K.V wrote:

With guests supporting Multiple page size per segment (MPSS),
hpte_page_size returns the actual page size used. Add a new function to
return base page size and use that to compare against the the page size
calculated from SLB. Without this patch a hpte lookup can fail since
we are comparing wrong page size in kvmppc_hv_find_lock_hpte.

Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com


Thanks, applied to for-3.16.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code

2014-06-25 Thread Marek Szyprowski 

Hello,

On 2014-06-18 22:51, Andrew Morton wrote:

On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim iamjoonsoo@lge.com wrote:

v2:
   - Although this patchset looks very different with v1, the end result,
   that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7.

This patchset is based on linux-next 20140610.

Thanks for taking care of this. I will test it with my setup and if
everything goes well, I will take it to my -next tree. If any branch
is required for anyone to continue his works on top of those patches,
let me know, I will also prepare it.

Hello,

I'm glad to hear that. :)
But, there is one concern. As you already know, I am preparing further
patches (Aggressively allocate the pages on CMA reserved memory). It
may be highly related to MM branch and also slightly depends on this CMA
changes. In this case, what is the best strategy to merge this
patchset? IMHO, Anrew's tree is more appropriate branch. If there is
no issue in this case, I am willing to develope further patches based
on your tree.

That's probably easier.  Marek, I'll merge these into -mm (and hence
-next and git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
and shall hold them pending you review/ack/test/etc, OK?


Ok. I've tested them and they work fine. I'm sorry that you had to wait for
me for a few days. You can now add:

Acked-and-tested-by: Marek Szyprowski m.szyprow...@samsung.com

I've also rebased my pending patches onto this set (I will send them soon).

The question is now if you want to keep the discussed patches in your 
-mm tree,

or should I take them to my -next branch. If you like to keep them, I assume
you will also take the patches which depends on the discussed changes.

Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code

2014-06-25 Thread Andrew Morton 
On Wed, 25 Jun 2014 14:33:56 +0200 Marek Szyprowski m.szyprow...@samsung.com 
wrote:

  That's probably easier.  Marek, I'll merge these into -mm (and hence
  -next and git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
  and shall hold them pending you review/ack/test/etc, OK?
 
 Ok. I've tested them and they work fine. I'm sorry that you had to wait for
 me for a few days. You can now add:
 
 Acked-and-tested-by: Marek Szyprowski m.szyprow...@samsung.com

Thanks.

 I've also rebased my pending patches onto this set (I will send them soon).
 
 The question is now if you want to keep the discussed patches in your 
 -mm tree,
 or should I take them to my -next branch. If you like to keep them, I assume
 you will also take the patches which depends on the discussed changes.

Yup, that works.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration

2014-06-25 Thread Alexander Graf 


On 06.06.14 02:20, Alexey Kardashevskiy wrote:

On 06/05/2014 09:57 PM, Alexander Graf wrote:

On 05.06.14 09:25, Alexey Kardashevskiy wrote:

This reserves 2 capability numbers.

This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.

Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's tree
(correct?).

They would just go via my tree, but only be actually allocated (read:
mergable to qemu) when they hit Paolo's tree.

In fact, I don't think it makes sense to split them off at all.


So? Are these patches going anywhere? Thanks.


So? Are you going to address the comments?


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] New PAPR hypercall plus individual hypercall enables, v3

2014-06-25 Thread Alexander Graf 


On 02.06.14 03:02, Paul Mackerras wrote:

This patch series adds a way for userspace to control which sPAPR
hypercalls get handled by kernel handlers vs. being sent up to
userspace, and then adds an implementation of a new hypercall,
H_SET_MODE.

This version updates the documentation in api.txt as requested.

The series is against the queue branch of the kvm tree.  I would like
these patches to go into 3.16 if possible.


Thanks, applied to kvm-ppc-queue. I don't think there's a bug fix in 
here that would warrant them in 3.16 still :).



Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] New PAPR hypercall plus individual hypercall enables, v3

2014-06-25 Thread Paul Mackerras 
On Wed, Jun 25, 2014 at 11:46:10PM +0200, Alexander Graf wrote:
 
 On 02.06.14 03:02, Paul Mackerras wrote:
 This patch series adds a way for userspace to control which sPAPR
 hypercalls get handled by kernel handlers vs. being sent up to
 userspace, and then adds an implementation of a new hypercall,
 H_SET_MODE.
 
 This version updates the documentation in api.txt as requested.
 
 The series is against the queue branch of the kvm tree.  I would like
 these patches to go into 3.16 if possible.
 
 Thanks, applied to kvm-ppc-queue. I don't think there's a bug fix in here
 that would warrant them in 3.16 still :).

I agree.  It would be good to get a stable assignment of the number
for KVM_CAP_PPC_ENABLE_HCALL so we can start getting the qemu patches
upstream, though.

Paul.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration

2014-06-25 Thread Alexey Kardashevskiy 
On 06/26/2014 07:12 AM, Alexander Graf wrote:
 
 On 06.06.14 02:20, Alexey Kardashevskiy wrote:
 On 06/05/2014 09:57 PM, Alexander Graf wrote:
 On 05.06.14 09:25, Alexey Kardashevskiy wrote:
 This reserves 2 capability numbers.

 This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.

 Please advise how to proceed with these patches as I suspect that
 first two should go via Paolo's tree while the last one via Alex Graf's
 tree
 (correct?).
 They would just go via my tree, but only be actually allocated (read:
 mergable to qemu) when they hit Paolo's tree.

 In fact, I don't think it makes sense to split them off at all.

 So? Are these patches going anywhere? Thanks.
 
 So? Are you going to address the comments?

Sorry, I cannot find here anything to fix. Ben asked some questions, I
answered and there were no objections. What do I miss this time?...


-- 
Alexey
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 2/3] powerpc/powernv: Support PCI error injection

2014-06-25 Thread Stewart Smith 
Gavin Shan gws...@linux.vnet.ibm.com writes:
 On Mon, Jun 23, 2014 at 04:36:44PM +1000, Michael Neuling wrote:
On Mon, 2014-06-23 at 12:14 +1000, Gavin Shan wrote:
 The patch implements one OPAL firmware sysfs file to support PCI error
 injection: /sys/firmware/opal/errinjct, which will be used like the
 way described as follows.
 
 According to PAPR spec, there are 3 RTAS calls related to error injection:
 ibm,open-errinjct: allocate token prior to doing error injection.
 ibm,close-errinjct: release the token allocated from ibm,open-errinjct.
 ibm,errinjct: do error injection.
 
 Sysfs file /sys/firmware/opal/errinjct accepts strings that have fixed
 format ei_token  For now, we only support 32-bits and 64-bits
 PCI error injection and they should have following strings written to
 /sys/firmware/opal/errinjct as follows. We don't have corresponding
 sysfs files for ibm,open-errinjct and ibm,close-errinjct, which
 means that we rely on userland to maintain the token by itself.

This sounds cool.  

Can you document the sysfs interface in Documentation/powerpc?


 Yeah, Documentation/powerpc/eeh-pci-error-recovery.txt needs update
 as Ben suggested. It's something in my list :-)

It should probably also/instead be in
Documentation/ABI/(testing|stable)/sysfs-firmware-opal-errinjct  as this
seems to be where sysfs bits get documented.

Also, considering that we're specifically looking at PCI error
injection, should the sysfs name be /sys/firmware/opal/pci-error-inject
instead?

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 2/3] powerpc/powernv: Support PCI error injection

2014-06-25 Thread Stewart Smith 
Gavin Shan gws...@linux.vnet.ibm.com writes:
 +static struct kobj_attribute errinjct_attr =
 + __ATTR(errinjct, 0600, NULL, errinjct_store);

May also be good to have a read method that either lists current
injected errors? I guess it depends on if they're one time errors or
persistent errors too.

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html