When vfio passthroughs 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. Otherwise,
ther
When using resource_alignment kernel parameter, the current implement
reassigns the alignment by changing resources' size which can
potentially break some drivers. For example, the driver uses the size
to locate some register whose length is related to the size.
This saves the increased sizes in p
We would call pci_reassigndev_resource_alignment() before
pci_init_capabilities(). So the requested alignment would
never work for IOV BARs. And it's also meaningless to do
so.
Signed-off-by: Yongji Xie
---
drivers/pci/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
This series introduces a way for PCI resource allocator to force
MMIO BARs not to share PAGE_SIZE. This would make sense to VFIO
driver. Because current VFIO implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs which may share the same page
with other BARs for security reasons. Thu
On Wed, Oct 26, 2016 at 7:52 AM, Michael Ellerman wrote:
> Cyril Bur writes:
>
>> On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote:
>>> s/ALIVEC/ALTIVEC/
>>>
>>
>> Oops, nice catch
>>
>>> Signed-off-by: Valentin Rothberg
>>
>> Reviewed-by: Cyril Bur
>
> How did we not notice? Sounds l
Cyril Bur writes:
> On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote:
>> s/ALIVEC/ALTIVEC/
>>
>
> Oops, nice catch
>
>> Signed-off-by: Valentin Rothberg
>
> Reviewed-by: Cyril Bur
How did we not notice? Sounds like we need a new selftest.
Looks like this should have:
Fixes: dc16b5
pci_update_resource() might be called to update (shift) IOV BARs
in PPC PowerNV specific pcibios_sriov_enable() when enabling PF's
SRIOV capability. At that point, the PF have been functional if
the SRIOV is enabled through sysfs entry "sriov_numvfs". The PF's
memory decoding (0x2 in PCI_COMMAND) s
This moves pcibios_sriov_enable() to the point before VF and VF BARs
are enabled on PowerNV platform. Also, pci_update_resource() is used
to update IOV BARs on PowerNV platform, the PF might have been functional
when the function is called. We shouldn't disable PF's memory decoding
at that point. I
In current implementation, pcibios_sriov_enable() is used by PPC
PowerNV platform only. In PowerNV specific pcibios_sriov_enable(),
PF's IOV BARs might be updated (shifted) by pci_update_resource().
It means the IOV BARs aren't ready for decoding incoming memory
address until pcibios_sriov_enable()
On Mon, Oct 24, 2016 at 10:51:13PM -0500, Bjorn Helgaas wrote:
>On Tue, Oct 25, 2016 at 12:47:28PM +1100, Gavin Shan wrote:
>> On Mon, Oct 24, 2016 at 09:03:16AM -0500, Bjorn Helgaas wrote:
>> >On Mon, Oct 24, 2016 at 10:28:02AM +1100, Gavin Shan wrote:
>> >> On Fri, Oct 21, 2016 at 11:50:34AM -050
On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote:
I still believe we need your changes, I was wondering if we've tested
it against normal memory nodes and checked if any memblock
allocations end up there. Michael showed me some memblock
allocations on node 1 of a two node machine with
We recently encountered a bug where a few customers using ibmveth on the
same LPAR hit an issue where a TCP session hung when large receive was
enabled. Closer analysis revealed that the session was stuck because the
one side was advertising a zero window repeatedly.
We narrowed this down to the
On 26/10/16 02:55, Reza Arbab wrote:
> On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote:
>> After the ack, I realized there were some more checks needed, IOW
>> questions for you :)
>
> Hey! No takebacks!
>
I still believe we need your changes, I was wondering if we've tested
it ag
:
> On 09/21/2016 09:17 AM, Michael Bringmann wrote:
>> architecture.vec5 features: The boot-time memory management needs to
>> know the form of the "ibm,dynamic-memory-v2" property early during
>> scanning of the flattened device tree. This patch moves execution of
>> the function pseries_probe_f
On 26/10/16 02:55, Reza Arbab wrote:
> On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote:
>> After the ack, I realized there were some more checks needed, IOW
>> questions for you :)
>
> Hey! No takebacks!
>
I still believe we need your changes, I was wondering if we've tested
it ag
This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signe
Several properties in the DRC device tree format are replaced by
more compact representations to allow, for example, for the encoding
of vast amounts of memory, and or reduced duplication of information
in related data structures.
"ibm,drc-info": This property, when present, replaces the following
>> + u16 hdr_len = ETH_HLEN + sizeof(struct tcphdr);
> Compiler may optmize this, but maybe move hdr_len to [*] ?>
There are other places in the stack where a u16 is used for the
same purpose. So I'll rather stick to that convention.
I'll make the other formatting changes you suggested and
r
This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and
commit 2ae416b142b6 ("mm: new mm hook framework").
It also keeps the same functionality of mremapping vDSO blob with
introducing vm_special_mapping mremap op for powerpc.
Cc: Laurent Dufour
Cc: Benjamin Herrenschmidt
Cc: Paul Mac
unsubscribe
On 10/24/2016 09:00 PM, Joe Perches wrote:
> At some point, pr_warning will be removed so all logging messages use
> a consistent _warn style.
>
> Update arch/powerpc/
> arch/powerpc/platforms/ps3/device-init.c| 12 +---
> arch/powerpc/platforms/ps3/mm.c | 4 ++--
On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote:
After the ack, I realized there were some more checks needed, IOW
questions for you :)
Hey! No takebacks!
The short answer is that neither of these is a concern.
Longer; if you use "movable_node", x86 can identify these nodes at bo
Common code with allocation/initialization of vDSO's pagelist.
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/k
Impact: cleanup
I also switched usage of printk(KERNEL_,...) on pr_(...)
and used pr_fmt() macro for "vDSO{32,64}: " prefix.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Sign
This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and
commit 2ae416b142b6 ("mm: new mm hook framework").
It also keeps the same functionality of mremapping vDSO blob with
introducing vm_special_mapping mremap op for powerpc.
Cc: Laurent Dufour
Cc: Benjamin Herrenschmidt
Cc: Paul Mac
This will allow to introduce mremap hook (the next patch).
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c|
I'll be easier to introduce vm_special_mapping struct in
a smaller map_vdso() function (see the next patches).
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Si
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 11 +++
1 file changed, 3 insertions(+),
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 19 +++
1 file changed, 7 inserti
Cleanup patches for vDSO on powerpc.
Originally, I wanted to add vDSO remapping on arm/aarch64 and
I decided to cleanup that part on powerpc.
I've add a hook for vm_ops for vDSO just like I did for x86.
Other changes - reduce exhaustive code duplication.
No visible to userspace changes expected.
T
On 25/10/16 15:44, Sören Brinkmann wrote:
> On Tue, 2016-10-25 at 12:49:33 +0200, Thomas Gleixner wrote:
>> On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote:
>>> On 10/21/2016 10:48 AM, Marc Zyngier wrote:
Shouldn't you return an error if irq is zero?
>>>
>>> I'll add the following fo
On Tue, 2016-10-25 at 12:49:33 +0200, Thomas Gleixner wrote:
> On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote:
> > On 10/21/2016 10:48 AM, Marc Zyngier wrote:
> > > Shouldn't you return an error if irq is zero?
> > >
> >
> > I'll add the following for the error case
> >
> > pr_err("%s:
On 10/24/2016 05:02 PM, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in pr_debug message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On 11/10/16 23:26, Balbir Singh wrote:
>
>
> On 07/10/16 05:36, Reza Arbab wrote:
>> Currently, CONFIG_MOVABLE_NODE depends on X86_64. In preparation to
>> enable it for other arches, we need to factor a detail which is unique
>> to x86 out of the generic mm code.
>>
>> Specifically, as documen
Hi Paul,
On Fri, Oct 21, 2016 at 08:04:17PM +1100, Paul Mackerras wrote:
> This fixes a race condition where one thread that is entering or
> leaving a power-saving state can inadvertently ignore the lock bit
> that was set by another thread, and potentially also clear it.
> The core_idle_lock_hel
On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote:
> On 10/21/2016 10:48 AM, Marc Zyngier wrote:
> > Shouldn't you return an error if irq is zero?
> >
>
> I'll add the following for the error case
>
> pr_err("%s: Parent exists but interrupts property not defined\n" ,
> __func__);
Pleas
On Tue, Oct 25, 2016 at 04:13:41PM +1100, Jon Maxwell wrote:
> We recently encountered a bug where a few customers using ibmveth on the
> same LPAR hit an issue where a TCP session hung when large receive was
> enabled. Closer analysis revealed that the session was stuck because the
> one side wa
Hi Paul,
[Added Shreyas's current e-mail address ]
On Fri, Oct 21, 2016 at 08:03:05PM +1100, Paul Mackerras wrote:
> Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering
> nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one
> thread entering a KVM guest could s
Hi,
Thanks for the review.
Some comments in-line.
On 10/21/2016 10:48 AM, Marc Zyngier wrote:
On 17/10/16 17:52, Zubair Lutfullah Kakakhel wrote:
The MIPS based xilfpga platform has the following IRQ structure
Peripherals --> xilinx_intcontroller -> mips_cpu_int controller
Add support for th
Balbir Singh writes:
> FYI, these checks were temporary to begin with
>
> I found this in git history
>
> b226e462124522f2f23153daff31c311729dfa2f (powerpc: don't add memory to empty
> node/zone)
Nice thanks for digging it up.
commit b226e462124522f2f23153daff31c311729dfa2f
Author: Mike
Peter,
here is v2 with some improved patch descriptions and some fixes. The
previous version has survived one day of linux-next and I only changed
small parts.
So unless there is some other issue, feel free to pull (or to apply
the patches) to tip/locking.
The following changes since commit 07d9a
For spinning loops people do often use barrier() or cpu_relax().
For most architectures cpu_relax and barrier are the same, but on
some architectures cpu_relax can add some latency.
For example on power,sparc64 and arc, cpu_relax can shift the CPU
towards other hardware threads in an SMT environmen
As there are no users left, we can remove cpu_relax_lowlatency.
Signed-off-by: Christian Borntraeger
---
arch/alpha/include/asm/processor.h | 1 -
arch/arc/include/asm/processor.h| 2 --
arch/arm/include/asm/processor.h| 1 -
arch/arm64/include/asm/processor.h | 1 -
ar
stop_machine seemed to be the only important place for yielding during
cpu_relax. This was fixed by using cpu_relax_yield. Therefore, we can
now redefine cpu_relax to be a barrier instead on s390, making s390
identical to all other architectures.
Signed-off-by: Christian Borntraeger
---
arch/s39
Some time ago commit 57f2ffe14fd125c2 ("s390: remove diag 44 calls
from cpu_relax()") did stop cpu_relax on s390 yielding to the
hypervisor.
As it turns out this made stop_machine run really slow on virtualized
overcommited systems. For example the kprobes test during bootup took
several seconds
With the s390 special case of a yielding cpu_relax implementation gone,
we can now remove all users of cpu_relax_lowlatency and replace them
with cpu_relax.
Signed-off-by: Christian Borntraeger
---
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/vhost/net.c | 4 ++--
On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote:
> On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote:
> > Hm, still behaves for me like I reported for v2:
> > http://marc.info/?l=linux-scsi&m=147637177902937&w=2
>
> Hi Steffen,
>
> Can you please try the following o
47 matches
Mail list logo
