I agree with Segher. We already know we have opportunities to do a better
job with shrink-wrapping (pushing this kind of useless activity down past
early exits), so having examples of code to look at to improve this would
be useful.
-- Bill
Bill Schmidt, Ph.D.
Linux on Power Toolchain
IBM Linux
On Fri, Aug 07, 2015 at 03:54:48PM +1000, Gavin Shan wrote:
>On Fri, Aug 07, 2015 at 01:44:33PM +0800, Wei Yang wrote:
>>On Fri, Aug 07, 2015 at 01:43:01PM +1000, Gavin Shan wrote:
>>>On Fri, Aug 07, 2015 at 10:33:33AM +0800, Wei Yang wrote:
On Fri, Aug 07, 2015 at 11:36:56AM +1000, Gavin Shan
The relation between CONFIG_PPC_HAS_HASH_64K and CONFIG_PPC_64K_PAGES is
painfully complicated.
But if we rearrange it enough we can see that PPC_HAS_HASH_64K
essentially depends on PPC_STD_MMU_64 && PPC_64K_PAGES.
We can then notice that PPC_HAS_HASH_64K is used in files that are only
built for
For config options with only a single value, guarding the single value
with 'if' is the same as adding a 'depends' statement. And it's more
standard to just use 'depends'.
And if the option has both an 'if' guard and a 'depends' we can collapse
them into a single 'depends' by combining them with &
Now that support for 64k pages with a 4K kernel is removed, this code is
unreachable.
CONFIG_PPC_HAS_HASH_64K can only be true when CONFIG_PPC_64K_PAGES is
also true.
But when CONFIG_PPC_64K_PAGES is true we include pte-hash64.h which
includes pte-hash64-64k.h, which defines both pte_pagesize_ind
Back in the olden days we added support for using 64K pages to map the
SPU (Synergistic Processing Unit) local store on Cell, when the main
kernel was using 4K pages.
This was useful at the time because distros were using 4K pages, but
using 64K pages on the SPUs could reduce TLB pressure there.
The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
PAGE_SIZE.
However when built with a 4K PAGE_SIZE there is an additional config
option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
This
On Fri, Aug 07, 2015 at 01:44:33PM +0800, Wei Yang wrote:
>On Fri, Aug 07, 2015 at 01:43:01PM +1000, Gavin Shan wrote:
>>On Fri, Aug 07, 2015 at 10:33:33AM +0800, Wei Yang wrote:
>>>On Fri, Aug 07, 2015 at 11:36:56AM +1000, Gavin Shan wrote:
On Thu, Aug 06, 2015 at 09:41:41PM +0800, Wei Yang wr
On Fri, 2015-08-07 at 13:18 +1000, Daniel Axtens wrote:
> A few declarations were identified by sparse as needing to be static:
>
> /scratch/dja/linux-capi/drivers/misc/cxl/irq.c:408:6: warning: symbol
> 'afu_irq_name_free' was not declared. Should it be static?
> /scratch/dja/linux-capi/drivers/
On Fri, Aug 07, 2015 at 01:43:01PM +1000, Gavin Shan wrote:
>On Fri, Aug 07, 2015 at 10:33:33AM +0800, Wei Yang wrote:
>>On Fri, Aug 07, 2015 at 11:36:56AM +1000, Gavin Shan wrote:
>>>On Thu, Aug 06, 2015 at 09:41:41PM +0800, Wei Yang wrote:
On Thu, Aug 06, 2015 at 03:36:01PM +1000, Gavin Shan
On Fri, 2015-08-07 at 13:18 +1000, Daniel Axtens wrote:
> An IO address, tagged with __iomem, is passed to debugfs_create_file
> as private data. This requires that it be cast to void *. The cast
> creates a sparse warning:
> /scratch/dja/linux-capi/drivers/misc/cxl/debugfs.c:51:57: warning: cast
On Fri, 2015-08-07 at 13:18 +1000, Daniel Axtens wrote:
> Sparse identifies the following address space issues:
> /scratch/dja/linux-capi/drivers/misc/cxl/vphb.c:125:17: warning: incorrect
> type in assignment (different address spaces)
> /scratch/dja/linux-capi/drivers/misc/cxl/vphb.c:125:17:
On Fri, 2015-08-07 at 13:18 +1000, Daniel Axtens wrote:
> It's a good idea, and it brings us in line with the rest of arch/powerpc.
>
> Signed-off-by: Daniel Axtens
Acked-by: Michael Neuling
> ---
> drivers/misc/cxl/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/
On Fri, Aug 07, 2015 at 10:24:05AM +0800, Wei Yang wrote:
>On Fri, Aug 07, 2015 at 11:20:10AM +1000, Gavin Shan wrote:
>>On Thu, Aug 06, 2015 at 10:10:10PM +0800, Wei Yang wrote:
>>>On Thu, Aug 06, 2015 at 02:35:57PM +1000, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wr
On Fri, 2015-08-07 at 13:45 +1000, Andrew Donnellan wrote:
> Simplify the dma_get_required_mask call chain by moving it from pnv_phb to
> pci_controller_ops, similar to commit 763d2d8df1ee2b92ff09c
> ("powerpc/powernv: Move dma_set_mask from pnv_phb to pci_controller_ops").
>
> Previous call chain
Simplify the dma_get_required_mask call chain by moving it from pnv_phb to
pci_controller_ops, similar to commit 763d2d8df1ee2b92ff09c
("powerpc/powernv: Move dma_set_mask from pnv_phb to pci_controller_ops").
Previous call chain:
0) call dma_get_required_mask() (kernel/dma.c)
1) call ppc_md.
On Fri, Aug 07, 2015 at 10:33:33AM +0800, Wei Yang wrote:
>On Fri, Aug 07, 2015 at 11:36:56AM +1000, Gavin Shan wrote:
>>On Thu, Aug 06, 2015 at 09:41:41PM +0800, Wei Yang wrote:
>>>On Thu, Aug 06, 2015 at 03:36:01PM +1000, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:25:03AM +0800, Wei Yang wr
> Do you need to put this patch last so that you don't break bisecting the
> series?
>
The warnings fixed in the rest of the series are from sparse, not the
compiler, so they don't break building with -Werror.
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message par
On Fri, 2015-08-07 at 13:18 +1000, Daniel Axtens wrote:
> It's a good idea, and it brings us in line with the rest of arch/powerpc.
Do you need to put this patch last so that you don't break bisecting the
series?
Mikey
> Signed-off-by: Daniel Axtens
> ---
> drivers/misc/cxl/Makefile | 2 ++
>
An IO address, tagged with __iomem, is passed to debugfs_create_file
as private data. This requires that it be cast to void *. The cast
creates a sparse warning:
/scratch/dja/linux-capi/drivers/misc/cxl/debugfs.c:51:57: warning: cast removes
address space of expression
The address space marker is
Sparse identifies the following address space issues:
/scratch/dja/linux-capi/drivers/misc/cxl/vphb.c:125:17: warning: incorrect type
in assignment (different address spaces)
/scratch/dja/linux-capi/drivers/misc/cxl/vphb.c:125:17:expected void
volatile [noderef] *
/scratch/dja/linux-capi/driv
A few declarations were identified by sparse as needing to be static:
/scratch/dja/linux-capi/drivers/misc/cxl/irq.c:408:6: warning: symbol
'afu_irq_name_free' was not declared. Should it be static?
/scratch/dja/linux-capi/drivers/misc/cxl/irq.c:467:6: warning: symbol
'afu_register_hwirqs' was n
It's a good idea, and it brings us in line with the rest of arch/powerpc.
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/cxl/Makefile b/drivers/misc/cxl/Makefile
index 14e3f8219a11..6f484dfe78f9 100644
--- a/drivers/m
On Fri, Aug 7, 2015 at 2:02 AM, Scott Wood
wrote:
On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood
wrote:
> On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
> > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
> >
> > wrote:
> > >
On Thu, 2015-07-23 at 16:43 +1000, Ian Munsie wrote:
> From: Ian Munsie
>
> userspace programs using cxl currently have to use two strategies for
> dealing with MMIO errors simultaneously. They have to check every read
> for a return of all Fs in case the adapter has gone away and the kernel
>
Andy Lutomirski says:
Some dynamic loaders may be slightly faster if a GNU hash is
available.
This is unlikely to have any measurable effect on the time it takes
to resolve vdso symbols (since there are so few of them). In some
contexts, it can be a win for a different reason: if every
On Fri, Aug 07, 2015 at 11:36:56AM +1000, Gavin Shan wrote:
>On Thu, Aug 06, 2015 at 09:41:41PM +0800, Wei Yang wrote:
>>On Thu, Aug 06, 2015 at 03:36:01PM +1000, Gavin Shan wrote:
>>>On Wed, Aug 05, 2015 at 09:25:03AM +0800, Wei Yang wrote:
When M64 BAR is set to Single PE mode, the PE# assign
On Fri, Aug 07, 2015 at 11:23:54AM +1000, Gavin Shan wrote:
>On Thu, Aug 06, 2015 at 10:03:04PM +0800, Wei Yang wrote:
>>On Thu, Aug 06, 2015 at 03:28:51PM +1000, Gavin Shan wrote:
>>>On Wed, Aug 05, 2015 at 09:25:02AM +0800, Wei Yang wrote:
Each VF could have 6 BARs at most. When the total BAR
On Fri, Aug 07, 2015 at 11:20:10AM +1000, Gavin Shan wrote:
>On Thu, Aug 06, 2015 at 10:10:10PM +0800, Wei Yang wrote:
>>On Thu, Aug 06, 2015 at 02:35:57PM +1000, Gavin Shan wrote:
>>>On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
On PHB_IODA2, we enable SRIOV devices by mapping IOV
On Thursday 06 August 2015 06:35 PM, Anshuman Khandual wrote:
> This patch just replaces hard coded values with existing
Please drop "This patch just" and start with "Replace hard ..."
https://www.kernel.org/doc/Documentation/SubmittingPatches
Maddy
> DRCONF flags while procesing detec
On Thu, Aug 06, 2015 at 08:04:58PM +1000, Alexey Kardashevskiy wrote:
>On 08/05/2015 11:25 AM, Wei Yang wrote:
>>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>>BAR in Single PE mode to cover the number of VFs required to be enabled.
>>By doing so, several VFs would be i
On Thu, Aug 06, 2015 at 10:10:10PM +0800, Wei Yang wrote:
>On Thu, Aug 06, 2015 at 02:35:57PM +1000, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
>>>On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
>>>a SRIOV device's BAR is not 64-bit pref
On Thu, Aug 06, 2015 at 10:03:04PM +0800, Wei Yang wrote:
>On Thu, Aug 06, 2015 at 03:28:51PM +1000, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:25:02AM +0800, Wei Yang wrote:
>>>Each VF could have 6 BARs at most. When the total BAR size exceeds the
>>>gate, after expanding it will also exhaust
On Thu, Aug 06, 2015 at 08:07:01PM +1000, Gavin Shan wrote:
>On Thu, Aug 06, 2015 at 05:36:02PM +0800, Wei Yang wrote:
>>On Thu, Aug 06, 2015 at 03:20:25PM +1000, Gavin Shan wrote:
>>>On Wed, Aug 05, 2015 at 09:25:00AM +0800, Wei Yang wrote:
In current implementation, when VF BAR is bigger than
On Thu, Aug 06, 2015 at 09:41:41PM +0800, Wei Yang wrote:
>On Thu, Aug 06, 2015 at 03:36:01PM +1000, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:25:03AM +0800, Wei Yang wrote:
>>>When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
>>>discrete.
>>>
>>>This patch restructures th
On Thu, Aug 06, 2015 at 08:48:10AM -0500, Rob Herring wrote:
>On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
Thanks, Rob. All your comments will be covered in next revision.
Thanks,
Gavin
>> The PowerNV PCI hotplug driver is going to use the OF changeset
>> to manage the changed device sub-
On Thu, Aug 06, 2015 at 09:49:02PM +0800, Wei Yang wrote:
>On Thu, Aug 06, 2015 at 02:51:40PM +1000, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
>>>The alignment of IOV BAR on PowerNV platform is the total size of the IOV
>>>BAR. No matter whether the IOV BAR is tr
On Thu, Aug 06, 2015 at 08:15:55PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 07:41 PM, Wei Yang wrote:
>>On Thu, Aug 06, 2015 at 07:00:00PM +1000, Alexey Kardashevskiy wrote:
>>>On 08/06/2015 02:51 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
>The
On 08/07/2015 12:13 AM, Wei Yang wrote:
On Thu, Aug 06, 2015 at 05:47:42PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 04:57 PM, Gavin Shan wrote:
On Thu, Aug 06, 2015 at 04:10:21PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:35 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24
On Thu, Aug 06, 2015 at 06:24:38PM -0500, Scott Wood wrote:
> On Thu, 2015-08-06 at 09:52 -0700, Brian Norris wrote:
> > Who takes patches for drivers/memory/ again? I can take it via MTD if
> > no one else steps up.
> There's no maintainer listed. IIRC, when we previously discussed the patch
>
On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote:
> > The original loop was already optimal, as the comment said.
>
> The comment says that bdnz has zero overhead. That doesn't mean the adde
> won't stall waiting for the load result.
adde is execution serialising on those cores; it *a
On Thu, 2015-08-06 at 09:52 -0700, Brian Norris wrote:
> On Wed, May 20, 2015 at 09:17:11PM -0500, Scott Wood wrote:
> > From: Jaiprakash Singh
> >
> > IFC IO accressor are set at run time based
> > on IFC IP registers endianness.IFC node in
> > DTS file contains information about
> > endianness.
On vr, 2015-08-07 at 00:21 +0200, Paul Bolle wrote:
> On wo, 2015-08-05 at 14:16 +1000, Michael Ellerman wrote:
> > I also get an oops when removing windfarm_lm75_sensor, so I suspect there
> > are
> > gremlins in the module ref counting for windfarm.
>
> (This I haven't (yet) looked into.)
And
On Wed, 2015-08-05 at 23:39 -0500, Segher Boessenkool wrote:
> On Wed, Aug 05, 2015 at 09:31:41PM -0500, Scott Wood wrote:
> > On Wed, 2015-08-05 at 19:30 -0500, Segher Boessenkool wrote:
> > > On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote:
> > > > On the 8xx, load latency is 2 c
On wo, 2015-08-05 at 14:16 +1000, Michael Ellerman wrote:
> On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote:
> > windfarm_corex_exit() contains:
> > BUG_ON(wf_client_count != 0);
> >
> > I wonder why that, apparently. never triggered.
>
> Hmm interesting.
>
> A quick test here on an iMa
On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
> On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood
> wrote:
> > On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
> > > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
> > >
> > > wrote:
> > > > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao
This fixes error handling in the function mpic_set_default_irq_routing
by checking if the call to the function kvm_set_irq_routing has failed
and if so exit immediately to the caller by returning the error code
returned by the call to mpic_set_default_irq_routing.
Signed-off-by: Nicholas Krause
-
On Wed, May 20, 2015 at 09:17:11PM -0500, Scott Wood wrote:
> From: Jaiprakash Singh
>
> IFC IO accressor are set at run time based
> on IFC IP registers endianness.IFC node in
> DTS file contains information about
> endianness.
>
> Signed-off-by: Jaiprakash Singh
> Signed-off-by: Scott Wood
>
On Thu, 6 Aug 2015, Julien Grall wrote:
> On 06/08/15 12:06, Stefano Stabellini wrote:
> > On Thu, 6 Aug 2015, Julien Grall wrote:
> >> Hi,
> >>
> >>
> >> On 04/08/15 19:12, Julien Grall wrote:
> >>> diff --git a/include/xen/page.h b/include/xen/page.h
> >>> index c5ed20b..e7e1425 100644
> >>> ---
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> This changes of_fdt_unflatten_tree() so that it returns the allocated
> memory chunk for unflattened device-tree, which can be released once
> it's obsoleted.
>
> Signed-off-by: Gavin Shan
Acked-by: Rob Herring
> ---
> drivers/of/fdt.c
On Thu, Aug 06, 2015 at 05:47:42PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 04:57 PM, Gavin Shan wrote:
>>On Thu, Aug 06, 2015 at 04:10:21PM +1000, Alexey Kardashevskiy wrote:
>>>On 08/06/2015 02:35 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
>On
On Thu, Aug 06, 2015 at 02:35:57PM +1000, Gavin Shan wrote:
>On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
>>On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
>>a SRIOV device's BAR is not 64-bit prefetchable, this is not assigned from
>>M64 windwo, which means
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> unflatten_dt_node() is called recursively to unflatten FDT nodes
> with the assumption that FDT blob has only one root node, which
> isn't true when the FDT blob represents device sub-tree. This
> improves the function to supporting device sub-t
On Thu, Aug 06, 2015 at 03:28:51PM +1000, Gavin Shan wrote:
>On Wed, Aug 05, 2015 at 09:25:02AM +0800, Wei Yang wrote:
>>Each VF could have 6 BARs at most. When the total BAR size exceeds the
>>gate, after expanding it will also exhaust the M64 Window.
>>
>>This patch limits the boundary by checkin
On 07/29/2015 05:42 PM, Eric B Munson wrote:
With the refactored mlock code, introduce a new system call for mlock.
The new call will allow the user to specify what lock states are being
added. mlock2 is trivial at the moment, but a follow on patch will add
a new mlock state making it useful.
S
On Thu, Aug 06, 2015 at 02:51:40PM +1000, Gavin Shan wrote:
>On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
>>The alignment of IOV BAR on PowerNV platform is the total size of the IOV
>>BAR. No matter whether the IOV BAR is truncated or not, the total size
>>could be calculated by (vfs_e
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> The PowerNV PCI hotplug driver is going to use the OF changeset
> to manage the changed device sub-tree, which requires those OF
> changeset functions are exported.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/dynamic.c | 65
> ++
On Thu, Aug 06, 2015 at 03:36:01PM +1000, Gavin Shan wrote:
>On Wed, Aug 05, 2015 at 09:25:03AM +0800, Wei Yang wrote:
>>When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
>>discrete.
>>
>>This patch restructures the patch to allocate discrete PE# for VFs when M64
>>BAR is set t
On 08/04/2015 03:27 PM, Michael Ellerman wrote:
> On Mon, 2015-13-07 at 08:16:06 UTC, Anshuman Khandual wrote:
>> This patch enables facility unavailable exceptions for generic facility,
>> FPU, ALTIVEC and VSX in /proc/interrupts listing by incrementing their
>> newly added IRQ statistical counter
This patch just replaces hard coded values with existing
DRCONF flags while procesing detected LMBs from the device
tree. This does not change any functionality.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/kernel/prom.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --g
On Sun, Jul 26, 2015 at 10:40:37PM -0700, Sukadev Bhattiprolu wrote:
> @@ -3743,7 +3762,13 @@ static u64 perf_event_aggregate(struct perf_event
> *event, u64 *enabled,
> lockdep_assert_held(&event->child_mutex);
>
> list_for_each_entry(child, &event->child_list, child_list) {
> +#if
On 06/08/15 12:06, Stefano Stabellini wrote:
> On Thu, 6 Aug 2015, Julien Grall wrote:
>> Hi,
>>
>>
>> On 04/08/15 19:12, Julien Grall wrote:
>>> diff --git a/include/xen/page.h b/include/xen/page.h
>>> index c5ed20b..e7e1425 100644
>>> --- a/include/xen/page.h
>>> +++ b/include/xen/page.h
>>> @@ -
On Thu, Aug 06, 2015 at 05:47:42PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 04:57 PM, Gavin Shan wrote:
>>On Thu, Aug 06, 2015 at 04:10:21PM +1000, Alexey Kardashevskiy wrote:
>>>On 08/06/2015 02:35 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
>On
On Thu, 6 Aug 2015, Julien Grall wrote:
> Hi,
>
>
> On 04/08/15 19:12, Julien Grall wrote:
> > diff --git a/include/xen/page.h b/include/xen/page.h
> > index c5ed20b..e7e1425 100644
> > --- a/include/xen/page.h
> > +++ b/include/xen/page.h
> > @@ -3,9 +3,9 @@
> >
> > #include
> >
> > -stati
Hi,
On 04/08/15 19:12, Julien Grall wrote:
> diff --git a/include/xen/page.h b/include/xen/page.h
> index c5ed20b..e7e1425 100644
> --- a/include/xen/page.h
> +++ b/include/xen/page.h
> @@ -3,9 +3,9 @@
>
> #include
>
> -static inline unsigned long page_to_mfn(struct page *page)
> +static in
On 08/06/2015 07:41 PM, Wei Yang wrote:
On Thu, Aug 06, 2015 at 07:00:00PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:51 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No ma
Hi,
I'd also like to see this patch in the mainstream as it fixes a bug
appearing when we switch from vCPU context to hypervisor context (guest
crash).
Laurent
On 06/08/2015 03:25, Sam Bobroff wrote:
> Ping?
>
> I think I've addressed all the comments in this version. Is there anything
> else
On Thu, Aug 06, 2015 at 05:36:02PM +0800, Wei Yang wrote:
>On Thu, Aug 06, 2015 at 03:20:25PM +1000, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:25:00AM +0800, Wei Yang wrote:
>>>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>>>BAR in Single PE mode to cover the numbe
On 08/05/2015 11:25 AM, Wei Yang wrote:
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
Th
On Thu, Aug 06, 2015 at 07:00:00PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:51 PM, Gavin Shan wrote:
>>On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
>>>The alignment of IOV BAR on PowerNV platform is the total size of the IOV
>>>BAR. No matter whether the IOV BAR is truncate
On Thu, Aug 06, 2015 at 03:20:25PM +1000, Gavin Shan wrote:
>On Wed, Aug 05, 2015 at 09:25:00AM +0800, Wei Yang wrote:
>>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>>BAR in Single PE mode to cover the number of VFs required to be enabled.
>>By doing so, several VFs wo
On 08/06/2015 02:51 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:59AM +0800, Wei Yang wrote:
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is truncated or not, the total size
could be calculated by (vfs_expanded * VF size).
On 08/06/2015 04:57 PM, Gavin Shan wrote:
On Thu, Aug 06, 2015 at 04:10:21PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:35 PM, Gavin Shan wrote:
On Wed, Aug 05, 2015 at 09:24:58AM +0800, Wei Yang wrote:
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV
On 07/30/2015 07:41 PM, Johannes Weiner wrote:
On Thu, Jul 30, 2015 at 06:34:31PM +0200, Vlastimil Babka wrote:
numa_mem_id() is able to handle allocation from CPUs on memory-less nodes,
so it's a more robust fallback than the currently used numa_node_id().
Won't it fall through to the next cl
74 matches
Mail list logo
