On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote:
> > > implemented as DMA API which the virtio core understands. There is no
> > > need for an IOMMU to be involved for the device representation in this
> > > case IMHO.
> >
> > This whole virtio translation issue is a mess.
On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote:
> >
> > Most uses I've seen do nothing more than use the FPE_xyz value to
> > format diagnostic messages while dying. I struggled to find code that
> > made a meaningful function
Linus,
Would you consider the patchset below for -rc2?
Dealing with the aliases of SI_USER has been a challenge as we have had
a b0rked ABI in some cases since 2.5.
So far no one except myself has suggested that changing the si_code of
from 0 to something else for those problematic aliases of S
Call clear_siginfo to ensure every stack allocated siginfo is properly
initialized before being passed to the signal sending functions.
Note: It is not safe to depend on C initializers to initialize struct
siginfo on the stack because C is allowed to skip holes when
initializing a structure.
The
Now that every instance of struct siginfo is now initialized it is no
longer necessary to copy struct siginfo piece by piece to userspace
but instead the entire structure can be copied.
As well as making the code simpler and more efficient this means that
copy_sinfo_to_user no longer cares which
After more experience with the cases where no one the si_code of 0 is
used both as a signal specific si_code, and as SI_USER it appears that
no one cares about the signal specific si_code case and the good
solution is to just fix the architectures by using a different si_code.
In none of the conv
Russell King - ARM Linux writes:
> On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
>> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote:
>> >
>> > Most uses I've seen do nothing more than use the FPE_xyz value to
>> > format diagnostic messages while dying. I struggled to find
On Fri, Apr 13, 2018 at 01:21:08PM -0700, Matthew Wilcox wrote:
> On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> > > I believe that keeping the mm docs together will give better visibility of
> > > what (little) mm documentation we have and will make the updates easier.
> > > Th
On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> Sorry for the silence, I'm pedaling as fast as I can, honest...
>
> On Sun, 1 Apr 2018 09:38:58 +0300
> Mike Rapoport wrote:
>
> > My thinking was to start with mechanical RST conversion and then to start
> > working on the conte
(
On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
wrote:
>
> Would you consider the patchset below for -rc2?
Ugh.
I have an irrational dislike of "clear_siginfo()". It's a nasty broken
interface, which just mis-spells "memset()", and makes it non-obvious
that you could clear it other ways to
On 04/15/2018 06:27 PM, Thomas Falcon wrote:
> Due to a firmware bug, the hypervisor can send an interrupt to a
> transmit or receive queue just prior to a partition migration, not
> allowing the device enough time to handle it and send an EOI. When
> the partition migrates, the interrupt is lost b
Due to a firmware bug, the hypervisor can send an interrupt to a
transmit or receive queue just prior to a partition migration, not
allowing the device enough time to handle it and send an EOI. When
the partition migrates, the interrupt is lost but an "EOI-pending"
flag for the interrupt line is st
From: Thomas Falcon
Date: Sun, 15 Apr 2018 18:53:36 -0500
> Due to a firmware bug, the hypervisor can send an interrupt to a
> transmit or receive queue just prior to a partition migration, not
> allowing the device enough time to handle it and send an EOI. When
> the partition migrates, the inte
On 04/15/2018 07:55 PM, David Miller wrote:
> From: Thomas Falcon
> Date: Sun, 15 Apr 2018 18:53:36 -0500
>
>> Due to a firmware bug, the hypervisor can send an interrupt to a
>> transmit or receive queue just prior to a partition migration, not
>> allowing the device enough time to handle it and
Linus Torvalds writes:
> (
>
> On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
> wrote:
>>
>> Would you consider the patchset below for -rc2?
>
> Ugh.
The point of this series is to squash the potential for regressions even
from the weird broken code that fills in fields for si_code 0 that d
On Thu, Apr 12, 2018 at 05:02:06PM +1000, Sam Bobroff wrote:
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> because the VCORE ID and XIVE
Hi Michael,
Many thanks for your help. Did you merge Olof‘s patch? I still have to patch
the 4.17 source code.
Thanks,
Christian
Sent from my iPhone
> On 19. Mar 2018, at 23:32, Michael Ellerman wrote:
>
> Bjorn Helgaas writes:
>
>>> On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigo
This series moves some of the radix mode TLB flushing into
powerpc/mm, which allows them them to implement the powerpc:tlbie
tracepoints for KVM invalidations.
This also fixes a partition scoped page fault performance issue
that was found by looking at partition scoped tlbie traces.
Since v1:
- F
The standard eieio ; tlbsync ; ptesync must follow tlbie to ensure it
is ordered with respect to subsequent operations.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_rad
Implement a local TLB flush for invalidating an LPID with variants for
process or partition scope. And a global TLB flush for invalidating
a partition scoped page of an LPID.
These will be used by KVM in subsequent patches.
Signed-off-by: Nicholas Piggin
---
.../include/asm/book3s/64/tlbflush-r
This has the advantage of consolidating TLB flush code in fewer
places, and it also implements powerpc:tlbie trace events.
1GB pages should be handled without further modification.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 26 +++---
1 file
The radix guest code can has fewer restrictions about what context it
can run in, so move this flushing out of assembly and have it use the
Linux TLB flush implementations introduced previously.
This allows powerpc:tlbie trace events to be used.
This changes the tlbiel sequence to only execute RI
When running a SMP radix guest, KVM can get into page fault / tlbie
storms -- hundreds of thousands to the same address from different
threads -- due to partition scoped page faults invalidating the
page table entry if it was found to be already set up by a racing
CPU.
What can happen is that gues
v1->v2:
-1.improve the commit log and explain the reproducing of bug in [3/3]
-2.re-fragment the series, and [3/3] is the motivation, while [1~2/3] are
preparation.
Pingfan Liu (3):
powerpc/cpuidle: dynamically register/unregister cpuidle_device during
hotplug
powerpc/cpu: dynmam
cpuidle_device is touched during the cpu hotplug. In order to cope with the
incoming
patch [3/3], which causes the dir /sys/../cpuX is created/destroyed during
hotplug,
we also need to create the file cpuX/cpuidle dynamically.
Signed-off-by: Pingfan Liu
Reviewed-by: Hari Bathini
---
drivers/c
In order to cope with the incoming patch [3/3], which causes the dir
/sys/../cpuX is created/destroyed during hotplug, we also need to create
the file cpuX/physical_id dynamically.
Signed-off-by: Pingfan Liu
Reported-by: Hari Bathini
Reviewed-by: Hari Bathini
---
arch/powerpc/kernel/sysfs.c |
Technically speaking, echo 1/0 > cpuX/online is only a subset of cpu
hotplug/unplug, i.e. add/remove. The latter one includes the physical
adding/removing of a cpu device. Some user space tools such as kexec-tools
resort to the event add/remove to automatically rebuild dtb.
If the dtb is not rebuil
27 matches
Mail list logo
