* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Eric W. Biederman @ 2018-04-15 15:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linus Torvalds, Dave Martin, Linux Kernel Mailing List,
Dmitry V. Levin, sparclinux, ppc-dev, linux-arm-kernel
In-Reply-To: <20180415131206.GR16141@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> 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 <Dave.Martin@arm.com> 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 functional decision based on the value, though that's
>> > not proof...
>>
>> Yeah. I've seen code that cares about SIGFPE deeply, but it's almost
>> invariably about some emulated environment (eg Java VM, or CPU
>> emulation).
>>
>> And the siginfo data is basically never good enough for those
>> environments anyway on its own, so they will go and look at the actual
>> instruction that caused the fault and the register state instead,
>> because they need *all* the information.
>>
>> The cases that use si_code are the ones that just trapped signals in
>> order to give a more helpful abort message.
>>
>> So I could certainly imagine that si_code is actually used by somebody
>> who then decides to actuall act differently on it, but aside from
>> perhaps printing out a different message, it sounds far-fetched.
>
> Okay, in that case let's just use FPE_FLTINV. That makes the patch
> easily back-portable for stable kernels.
If we want to I don't think backporting 266da65e9156 ("signal: Add
FPE_FLTUNK si_code for undiagnosable fp exceptions") would be at
all difficult.
What it is changing has been stable for quite a while. The surroundings
might change and so it might require some trivial manual fixup but I
don't expect any problems.
Not that I want to derail the consensus but if we want to backport
similar fixes for arm64 or the other architectures that wind up using
FPE_FLTUNK for their fix we would need to backport 266da65e9156 anyway.
Eric
^ permalink raw reply
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Mike Rapoport @ 2018-04-15 17:29 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jonathan Corbet, Andrew Morton, Andrey Ryabinin,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Tony Luck,
Fenghua Yu, Ralf Baechle, James Hogan, Michael Ellerman,
Alexander Viro, linux-kernel, linux-doc, kasan-dev, linux-alpha,
linux-ia64, linux-mips, linuxppc-dev, linux-fsdevel, linux-mm
In-Reply-To: <20180413202108.GA30271@bombadil.infradead.org>
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.
> > > The documents that fit well into a certain topic could be linked there. For
> > > instance:
> >
> > ...but this sounds like just the opposite...?
> >
> > I've had this conversation with folks in a number of subsystems.
> > Everybody wants to keep their documentation together in one place - it's
> > easier for the developers after all. But for the readers I think it's
> > objectively worse. It perpetuates the mess that Documentation/ is, and
> > forces readers to go digging through all kinds of inappropriate material
> > in the hope of finding something that tells them what they need to know.
> >
> > So I would *really* like to split the documentation by audience, as has
> > been done for a number of other kernel subsystems (and eventually all, I
> > hope).
> >
> > I can go ahead and apply the RST conversion, that seems like a step in
> > the right direction regardless. But I sure hope we don't really have to
> > keep it as an unorganized jumble of stuff...
>
> I've started on Documentation/core-api/memory.rst which covers just
> memory allocation. So far it has the Overview and GFP flags sections
> written and an outline for 'The slab allocator', 'The page allocator',
> 'The vmalloc allocator' and 'The page_frag allocator'. And typing this
> up, I realise we need a 'The percpu allocator'. I'm thinking that this
> is *not* the right document for the DMA memory allocators (although it
> should link to that documentation).
>
> I suspect the existing Documentation/vm/ should probably stay as an
> unorganised jumble of stuff. Developers mostly talking to other MM
> developers. Stuff that people outside the MM fraternity should know
> about needs to be centrally documented. By all means convert it to
> ReST ... I don't much care, and it may make it easier to steal bits
> or link to it from the organised documentation.
The existing Documentation/vm contains different types of documents. Some
are indeed "Developers mostly talking to other MM developers". Some are
really user/administrator guides. Others are somewhat in between.
I took another look at what's there and I think we can actually move part
of Documentation/vm to Documentation/admin-guide. We can add
Documentation/admin-guide/vm/ and title it "Memory Management Tuning" or
something like that. And several files, e.g. hugetlbpage, ksm, soft-dirty
can be moved there.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Mike Rapoport @ 2018-04-15 17:36 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Morton, Andrey Ryabinin, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Tony Luck, Fenghua Yu, Ralf Baechle,
James Hogan, Michael Ellerman, Alexander Viro, linux-kernel,
linux-doc, kasan-dev, linux-alpha, linux-ia64, linux-mips,
linuxppc-dev, linux-fsdevel, linux-mm
In-Reply-To: <20180413135551.0e6d1b12@lwn.net>
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 <rppt@linux.vnet.ibm.com> wrote:
>
> > My thinking was to start with mechanical RST conversion and then to start
> > working on the contents and ordering of the documentation. Some of the
> > existing files, e.g. ksm.txt, can be moved as is into the appropriate
> > places, others, like transhuge.txt should be at least split into admin/user
> > and developer guides.
> >
> > Another problem with many of the existing mm docs is that they are rather
> > developer notes and it wouldn't be really straight forward to assign them
> > to a particular topic.
>
> All this sounds good.
>
> > 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.
> > The documents that fit well into a certain topic could be linked there. For
> > instance:
>
> ...but this sounds like just the opposite...?
>
> I've had this conversation with folks in a number of subsystems.
> Everybody wants to keep their documentation together in one place - it's
> easier for the developers after all. But for the readers I think it's
> objectively worse. It perpetuates the mess that Documentation/ is, and
> forces readers to go digging through all kinds of inappropriate material
> in the hope of finding something that tells them what they need to know.
>
> So I would *really* like to split the documentation by audience, as has
> been done for a number of other kernel subsystems (and eventually all, I
> hope).
>
> I can go ahead and apply the RST conversion, that seems like a step in
> the right direction regardless. But I sure hope we don't really have to
> keep it as an unorganized jumble of stuff...
I didn't mean we should keep it as unorganized jumble of stuff and I agree
that splitting the documentation by audience is better because developers
are already know how to find it :)
I just thought that putting the doc into the place should not be done
immediately after mechanical ReST conversion but rather after improving the
contents. Although I'd agree that part of the documentation in
Documentation/vm is in pretty good shape already.
> Thanks,
>
> jon
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER
From: Linus Torvalds @ 2018-04-15 18:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Dave Martin, Linux Kernel Mailing List, Dmitry V. Levin,
sparclinux, ppc-dev, linux-arm-kernel, Russell King - ARM Linux,
linux-arch
In-Reply-To: <87604sa2fu.fsf_-_@xmission.com>
(
On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
<ebiederm@xmission.com> 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 too (eg "kzalloc()" or whatever).
And this series brings in a lot of new users.
Honestly, both "clear_siginfo()" and "copy_siginfo()" are crazy
interfaces. They may have made sense when converting code, but not so
much now.
If we want to have a function that initializes a siginfo, I think it
should _actually_ initialize it, and at least take the two fields that
a siginfo has to have to be valid: si_signo and si_code.
So I'd rather see a patch that does something like this:
- clear_siginfo(info);
- info->si_signo = sig;
- info->si_errno = 0;
- info->si_code = SI_USER;
- info->si_pid = 0;
- info->si_uid = 0;
+ init_siginfo(info, sig, SI_USER);
which at least makes that function be *worth* something, not just a
bad spelling of memset. It's not just the removal of pointless "set to
zero", it's the whole concept of "this function actually makes a valid
siginfo", which is lacking in the existing function.
(Yeah, yeah, si_errno is "generic" too and always part of a siginfo,
but nobody cares. It's pretty much always set to zero, it would be
stupid to add that interface to the "init_siginfo()" function. So just
clearing it is fine, the one or two places that want to set it to some
silly value can do it themselves).
Then your series would incidentally also:
(a) make for fewer lines overall, rather than add lines
(b) make it clear that we always initialize si_code, which now *must*
be a valid value with all the recent siginfo changes.
Hmm?
The other thing we should do is to get rid of the stupid padding.
Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
completely insane, when it's always just zero in the kernel.
So put that _pad[] thing inside #ifndef __KERNEL__, and make
copy_siginfo_to_user() write the padding zeroes when copying to user
space. The reason for the padding is "future expansion", so we do want
to tell the user space that it's maybe up to 128 bytes in size, but if
we don't fill it all, we shouldn't waste time and memory on clearing
the padding internally.
I'm certainly *hoping* nobody depends on the whole 128 bytes in
rt_sigqueueinfo(). In theory you can fill it all (as long as si_code
is negative), but the man-page only says "si_value", and the compat
function doesn't copy any more than that either, so any user that
tries to fill in more than si_value is already broken. In fact, it
might even be worth enforcing that in rt_sigqueueinfo(), just to see
if anybody plays any games..
On x86-64, without the pointless padding, the size of 'struct siginfo'
inside the kernel would be 48 bytes. That's quite a big difference for
something that is often allocated on the kernel stack.
So I'm certainly willing to make those kinds of changes, but let's
make them real *improvements* now, ok? Wasn't that the point of all
the cleanups in the end?
Linus
^ permalink raw reply
* Re: [PATCH] ibmvnic: Clear pending interrupt after device reset
From: Thomas Falcon @ 2018-04-15 23:46 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, jallen, nfont, benh
In-Reply-To: <1523834853-15448-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
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 but an "EOI-pending"
> flag for the interrupt line is still set in firmware. No further
> interrupts will be sent until that flag is cleared, effectively
> freezing that queue. To workaround this, the driver will disable the
> hardware interrupt and send an H_EOI signal prior to re-enabling it.
> This will flush the pending EOI and allow the driver to continue
> operation.
Excuse me, I misspelled the linuxppc-dev email address.
Tom
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/ibm/ibmvnic.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
> index f84a920..ef7995fc 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -1034,16 +1034,14 @@ static int __ibmvnic_open(struct net_device *netdev)
> netdev_dbg(netdev, "Enabling rx_scrq[%d] irq\n", i);
> if (prev_state == VNIC_CLOSED)
> enable_irq(adapter->rx_scrq[i]->irq);
> - else
> - enable_scrq_irq(adapter, adapter->rx_scrq[i]);
> + enable_scrq_irq(adapter, adapter->rx_scrq[i]);
> }
>
> for (i = 0; i < adapter->req_tx_queues; i++) {
> netdev_dbg(netdev, "Enabling tx_scrq[%d] irq\n", i);
> if (prev_state == VNIC_CLOSED)
> enable_irq(adapter->tx_scrq[i]->irq);
> - else
> - enable_scrq_irq(adapter, adapter->tx_scrq[i]);
> + enable_scrq_irq(adapter, adapter->tx_scrq[i]);
> }
>
> rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
> @@ -1184,6 +1182,7 @@ static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter)
> if (adapter->tx_scrq[i]->irq) {
> netdev_dbg(netdev,
> "Disabling tx_scrq[%d] irq\n", i);
> + disable_scrq_irq(adapter, adapter->tx_scrq[i]);
> disable_irq(adapter->tx_scrq[i]->irq);
> }
> }
> @@ -1193,6 +1192,7 @@ static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter)
> if (adapter->rx_scrq[i]->irq) {
> netdev_dbg(netdev,
> "Disabling rx_scrq[%d] irq\n", i);
> + disable_scrq_irq(adapter, adapter->rx_scrq[i]);
> disable_irq(adapter->rx_scrq[i]->irq);
> }
> }
> @@ -2601,12 +2601,19 @@ static int enable_scrq_irq(struct ibmvnic_adapter *adapter,
> {
> struct device *dev = &adapter->vdev->dev;
> unsigned long rc;
> + u64 val;
>
> if (scrq->hw_irq > 0x100000000ULL) {
> dev_err(dev, "bad hw_irq = %lx\n", scrq->hw_irq);
> return 1;
> }
>
> + val = (0xff000000) | scrq->hw_irq;
> + rc = plpar_hcall_norets(H_EOI, val);
> + if (rc)
> + dev_err(dev, "H_EOI FAILED irq 0x%llx. rc=%ld\n",
> + val, rc);
> +
> rc = plpar_hcall_norets(H_VIOCTL, adapter->vdev->unit_address,
> H_ENABLE_VIO_INTERRUPT, scrq->hw_irq, 0, 0);
> if (rc)
^ permalink raw reply
* [PATCH] ibmvnic: Clear pending interrupt after device reset
From: Thomas Falcon @ 2018-04-15 23:53 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, jallen, nfont, benh, Thomas Falcon
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 still set in firmware. No further
interrupts will be sent until that flag is cleared, effectively
freezing that queue. To workaround this, the driver will disable the
hardware interrupt and send an H_EOI signal prior to re-enabling it.
This will flush the pending EOI and allow the driver to continue
operation.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index f84a920..ef7995fc 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1034,16 +1034,14 @@ static int __ibmvnic_open(struct net_device *netdev)
netdev_dbg(netdev, "Enabling rx_scrq[%d] irq\n", i);
if (prev_state == VNIC_CLOSED)
enable_irq(adapter->rx_scrq[i]->irq);
- else
- enable_scrq_irq(adapter, adapter->rx_scrq[i]);
+ enable_scrq_irq(adapter, adapter->rx_scrq[i]);
}
for (i = 0; i < adapter->req_tx_queues; i++) {
netdev_dbg(netdev, "Enabling tx_scrq[%d] irq\n", i);
if (prev_state == VNIC_CLOSED)
enable_irq(adapter->tx_scrq[i]->irq);
- else
- enable_scrq_irq(adapter, adapter->tx_scrq[i]);
+ enable_scrq_irq(adapter, adapter->tx_scrq[i]);
}
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
@@ -1184,6 +1182,7 @@ static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter)
if (adapter->tx_scrq[i]->irq) {
netdev_dbg(netdev,
"Disabling tx_scrq[%d] irq\n", i);
+ disable_scrq_irq(adapter, adapter->tx_scrq[i]);
disable_irq(adapter->tx_scrq[i]->irq);
}
}
@@ -1193,6 +1192,7 @@ static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter)
if (adapter->rx_scrq[i]->irq) {
netdev_dbg(netdev,
"Disabling rx_scrq[%d] irq\n", i);
+ disable_scrq_irq(adapter, adapter->rx_scrq[i]);
disable_irq(adapter->rx_scrq[i]->irq);
}
}
@@ -2601,12 +2601,19 @@ static int enable_scrq_irq(struct ibmvnic_adapter *adapter,
{
struct device *dev = &adapter->vdev->dev;
unsigned long rc;
+ u64 val;
if (scrq->hw_irq > 0x100000000ULL) {
dev_err(dev, "bad hw_irq = %lx\n", scrq->hw_irq);
return 1;
}
+ val = (0xff000000) | scrq->hw_irq;
+ rc = plpar_hcall_norets(H_EOI, val);
+ if (rc)
+ dev_err(dev, "H_EOI FAILED irq 0x%llx. rc=%ld\n",
+ val, rc);
+
rc = plpar_hcall_norets(H_VIOCTL, adapter->vdev->unit_address,
H_ENABLE_VIO_INTERRUPT, scrq->hw_irq, 0, 0);
if (rc)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] ibmvnic: Clear pending interrupt after device reset
From: David Miller @ 2018-04-16 0:55 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev, jallen, nfont, benh
In-Reply-To: <1523836416-16531-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
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 interrupt is lost but an "EOI-pending"
> flag for the interrupt line is still set in firmware. No further
> interrupts will be sent until that flag is cleared, effectively
> freezing that queue. To workaround this, the driver will disable the
> hardware interrupt and send an H_EOI signal prior to re-enabling it.
> This will flush the pending EOI and allow the driver to continue
> operation.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Hey Thomas, I see two copies of this patch posted. Any special
reason for that?
Thanks.
^ permalink raw reply
* Re: [PATCH] ibmvnic: Clear pending interrupt after device reset
From: Thomas Falcon @ 2018-04-16 1:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20180415.205512.1546339550911332998.davem@davemloft.net>
On 04/15/2018 07:55 PM, David Miller wrote:
> From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> 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 interrupt is lost but an "EOI-pending"
>> flag for the interrupt line is still set in firmware. No further
>> interrupts will be sent until that flag is cleared, effectively
>> freezing that queue. To workaround this, the driver will disable the
>> hardware interrupt and send an H_EOI signal prior to re-enabling it.
>> This will flush the pending EOI and allow the driver to continue
>> operation.
>>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> Hey Thomas, I see two copies of this patch posted. Any special
> reason for that?
>
> Thanks.
>
Sorry, I misspelled one of the email addresses and mistakenly resent it. Please ignore this one.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER
From: Eric W. Biederman @ 2018-04-16 2:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Martin, Linux Kernel Mailing List, Dmitry V. Levin,
sparclinux, ppc-dev, linux-arm-kernel, Russell King - ARM Linux,
linux-arch
In-Reply-To: <CA+55aFw1gmfFH1o+oWMo4TnU5hEczAOiY1g=eMxqYZmy9JqDYw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> (
>
> On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
> <ebiederm@xmission.com> 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 do
not match SI_USER.
The copy_siginfo_to_user32 never handled that so we don't need to worry
about that. All of the signals that abuse si_code 0 go through
force_sig_info so signalfd can not catch them. Which means that only
copy_siginfo_to_user needs to be worried about.
Last time I was benchmarking I could not see a difference between
copying the entire siginfo and only a small part so I don't see
the point of optimizing now.
For an actual cleanup I intend to go farther than you are proposing and
convert everthing to the set of helper functions I have added to
kernel/signal.c force_sig_fault, force_sig_mceerr, force_sig_bnderr,
force_sig_pkuerr.
When I am done there will be maybe 5 instances of clear_siginfo outside
of those helper functions. At which point I won't care if we remove
clear_siginfo and just use memset. That is a real improvement
that looks something like: "105 files changed, 933 insertions(+), 1698 deletions(-)"
That is my end goal with all of this.
You complained to me about regressions and you are right with the
current handling of FPE_FIXME TRAP_FIXME the code is not bug compatible
with old versions of linux, and people have noticed.
What this patchset represents is the bare minimum needed to convert
copy_siginfo_to_user to a copy_to_user, and remove the possibility
of regressions.
To that end I need to ensure every struct siginfo in the entire
kernel is memset to 0. A structure initializer is absolutely
not enough. So I don't mind people thinking clear_siginfo is necessary.
To that end clear_siginfo where it does not take the size of
struct siginfo as a parameter is much less suceptible to typos,
and allows me to ensure every instance of struct siginfo is fully
initialized.
I fully intend to remove practically every instance of struct siginfo
from the architecture specific code, and use the aforementioned helpers.
The trouble is that some of the architecture code need refactoring
for that to happen. Even your proposed init_siginfo can't be widely
used as a common pattern is to fill in siginfo partially in the
code with si_code and si_signo being filled in almost last.
So in short. I intend to remove most of these clear_siginfo calls when
I remove the siginfos later. This series is focused on making
copy_siginfo_to_user simple enough we don't need to use siginfo_layout,
and thus can be fully backwards compatibile with ourselves and we won't
need to worry about regressions. I have aimed to keep this simple
enough we can merge this after -rc1 because we don't want regressions.
Eric
ps. I intend to place this change first in my series wether or not it makes
it into -rc2 so that I can be certain we remove any possible regressions
in behavior on the buggy architectures. Then I can take my time and
ensure the non-trivial changes of refactoring etc are done carefully so
I don't introduce other bugs. I need that so I can sleep at night.
pps. I can look at some of your other suggestions but cleverness leads
to regressions, and if you are going to complain at me harshly when I
have been being careful and taking things seriously I am not
particularly willing to take unnecessary chances.
^ permalink raw reply
* Re: [PATCH RFC 1/1] KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
From: David Gibson @ 2018-04-16 4:09 UTC (permalink / raw)
To: Sam Bobroff; +Cc: linuxppc-dev, kvm, kvm-ppc, paulus, clg
In-Reply-To: <70974cfb62a7f09a53ec914d2909639884228244.1523516498.git.sam.bobroff@au1.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 8018 bytes --]
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 offsets to grow beyond KVM_MAX_VCPUS
> even though the VCPU ID is less than KVM_MAX_VCPU_ID.
>
> To address this, "pack" the VCORE ID and XIVE offsets by using
> knowledge of the way the VCPU IDs will be used when there are less
> guest threads per core than the core stride. The primary thread of
> each core will always be used first. Then, if the guest uses more than
> one thread per core, these secondary threads will sequentially follow
> the primary in each core.
>
> So, the only way an ID above KVM_MAX_VCPUS can be seen, is if the
> VCPUs are being spaced apart, so at least half of each core is empty
> and IDs between KVM_MAX_VCPUS and (KVM_MAX_VCPUS * 2) can be mapped
> into the second half of each core (4..7, in an 8-thread core).
>
> Similarly, if IDs above KVM_MAX_VCPUS * 2 are seen, at least 3/4 of
> each core is being left empty, and we can map down into the second and
> third quarters of each core (2, 3 and 5, 6 in an 8-thread core).
>
> Lastly, if IDs above KVM_MAX_VCPUS * 4 are seen, only the primary
> threads are being used and 7/8 of the core is empty, allowing use of
> the 1, 3, 5 and 7 thread slots.
>
> (Strides less than 8 are handled similarly.)
>
> This allows the VCORE ID or offset to be calculated quickly from the
> VCPU ID or XIVE server numbers, without access to the VCPU structure.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
> Hello everyone,
>
> I've tested this on P8 and P9, in lots of combinations of host and guest
> threading modes and it has been fine but it does feel like a "tricky"
> approach, so I still feel somewhat wary about it.
>
> I've posted it as an RFC because I have not tested it with guest native-XIVE,
> and I suspect that it will take some work to support it.
>
> arch/powerpc/include/asm/kvm_book3s.h | 19 +++++++++++++++++++
> arch/powerpc/kvm/book3s_hv.c | 14 ++++++++++----
> arch/powerpc/kvm/book3s_xive.c | 9 +++++++--
> 3 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
> index 376ae803b69c..1295056d564a 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -368,4 +368,23 @@ extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
> #define SPLIT_HACK_MASK 0xff000000
> #define SPLIT_HACK_OFFS 0xfb000000
>
> +/* Pack a VCPU ID from the [0..KVM_MAX_VCPU_ID) space down to the
> + * [0..KVM_MAX_VCPUS) space, while using knowledge of the guest's core stride
> + * (but not it's actual threading mode, which is not available) to avoid
> + * collisions.
> + */
> +static inline u32 kvmppc_pack_vcpu_id(struct kvm *kvm, u32 id)
> +{
> + const int block_offsets[MAX_SMT_THREADS] = {0, 4, 2, 6, 1, 5, 3, 7};
I'd suggest 1,3,5,7 at the end rather than 1,5,3,7 - accomplishes
roughly the same thing, but I think makes the pattern more obvious.
> + int stride = kvm->arch.emul_smt_mode > 1 ?
> + kvm->arch.emul_smt_mode : kvm->arch.smt_mode;
AFAICT from BUG_ON()s etc. at the callsites, kvm->arch.smt_mode must
always be 1 when this is called, so the conditional here doesn't seem
useful.
> + int block = (id / KVM_MAX_VCPUS) * (MAX_SMT_THREADS / stride);
> + u32 packed_id;
> +
> + BUG_ON(block >= MAX_SMT_THREADS);
> + packed_id = (id % KVM_MAX_VCPUS) + block_offsets[block];
> + BUG_ON(packed_id >= KVM_MAX_VCPUS);
> + return packed_id;
> +}
It took me a while to wrap my head around the packing function, but I
think I got there in the end. It's pretty clever.
One thing bothers me, though. This certainly packs things under
KVM_MAX_VCPUS, but not necessarily under the actual number of vcpus.
e.g. KVM_MAC_VCPUS==16, 8 vcpus total, stride 8, 2 vthreads/vcore (as
qemu sees it), gives both unpacked IDs (0, 1, 8, 9, 16, 17, 24, 25)
and packed ids of (0, 1, 8, 9, 4, 5, 12, 13) - leaving 2, 3, 6, 7
etc. unused.
So again, the question is what exactly are these remapped IDs useful
for. If we're indexing into a bare array of structures of size
KVM_MAX_VCPUS then we're *already* wasting a bunch of space by having
more entries than vcpus. If we're indexing into something sparser,
then why is the remapping worthwhile?
> +
> #endif /* __ASM_KVM_BOOK3S_H__ */
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 9cb9448163c4..49165cc90051 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1762,7 +1762,7 @@ static int threads_per_vcore(struct kvm *kvm)
> return threads_per_subcore;
> }
>
> -static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
> +static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int id)
> {
> struct kvmppc_vcore *vcore;
>
> @@ -1776,7 +1776,7 @@ static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
> init_swait_queue_head(&vcore->wq);
> vcore->preempt_tb = TB_NIL;
> vcore->lpcr = kvm->arch.lpcr;
> - vcore->first_vcpuid = core * kvm->arch.smt_mode;
> + vcore->first_vcpuid = id;
> vcore->kvm = kvm;
> INIT_LIST_HEAD(&vcore->preempt_list);
>
> @@ -1992,12 +1992,18 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
> mutex_lock(&kvm->lock);
> vcore = NULL;
> err = -EINVAL;
> - core = id / kvm->arch.smt_mode;
> + if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> + BUG_ON(kvm->arch.smt_mode != 1);
> + core = kvmppc_pack_vcpu_id(kvm, id);
> + } else {
> + core = id / kvm->arch.smt_mode;
> + }
> if (core < KVM_MAX_VCORES) {
> vcore = kvm->arch.vcores[core];
> + BUG_ON(cpu_has_feature(CPU_FTR_ARCH_300) && vcore);
> if (!vcore) {
> err = -ENOMEM;
> - vcore = kvmppc_vcore_create(kvm, core);
> + vcore = kvmppc_vcore_create(kvm, id & ~(kvm->arch.smt_mode - 1));
> kvm->arch.vcores[core] = vcore;
> kvm->arch.online_vcores++;
> }
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index f9818d7d3381..681dfe12a5f3 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -317,6 +317,11 @@ static int xive_select_target(struct kvm *kvm, u32 *server, u8 prio)
> return -EBUSY;
> }
>
> +static u32 xive_vp(struct kvmppc_xive *xive, u32 server)
> +{
> + return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
> +}
> +
I'm finding the XIVE indexing really baffling. There are a bunch of
other places where the code uses (xive->vp_base + NUMBER) directly.
If those are host side references, I guess they don't need updates for
this.
But if that's the case, then how does indexing into the same array
with both host and guest server numbers make sense?
> static u8 xive_lock_and_mask(struct kvmppc_xive *xive,
> struct kvmppc_xive_src_block *sb,
> struct kvmppc_xive_irq_state *state)
> @@ -1084,7 +1089,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
> pr_devel("Duplicate !\n");
> return -EEXIST;
> }
> - if (cpu >= KVM_MAX_VCPUS) {
> + if (cpu >= KVM_MAX_VCPU_ID) {
> pr_devel("Out of bounds !\n");
> return -EINVAL;
> }
> @@ -1098,7 +1103,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
> xc->xive = xive;
> xc->vcpu = vcpu;
> xc->server_num = cpu;
> - xc->vp_id = xive->vp_base + cpu;
> + xc->vp_id = xive_vp(xive, cpu);
> xc->mfrr = 0xff;
> xc->valid = true;
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards
From: Christian Zigotzky @ 2018-04-16 4:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: Bjorn Helgaas, Bjorn Helgaas, linux-pci, Olof Johansson,
linuxppc-dev
In-Reply-To: <87tvtbg0i9.fsf@concordia.ellerman.id.au>
Hi Michael,
Many thanks for your help. Did you merge Olof=E2=80=98s patch? I still have t=
o patch the 4.17 source code.
Thanks,
Christian
Sent from my iPhone
> On 19. Mar 2018, at 23:32, Michael Ellerman <mpe@ellerman.id.au> wrote:
>=20
> Bjorn Helgaas <helgaas@kernel.org> writes:
>=20
>>> On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
>>> Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for=
>>> Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set=
by
>>> quirks or the "pci=3Dpcie_scan_all"
>>> kernel parameter) only affected Switch Downstream Ports, not Root Ports.=
The
>>> problem is, that we have to add always the boot argument "pci=3Dpcie_sca=
n_all"
>>> for using Bjorn's improvements. Without the boot argument
>>> "pci=3Dpcie_scan_all", the kernel doesn't boot on P.A. Semi boards with S=
B600
>>> chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi=E2=80=99=
s
>>> PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
>>> connected to the SB600 anymore. Olof Johansson has created a patch for
>>> executing "pci=3Dpcie_scan_all" automatically on P.A. Semi boards. With h=
is
>>> patch, we don't need to add 'pci=3Dpcie_scan_all' to the kernel boot arg=
uments
>>> anymore.
>>=20
>> The patch looks fine, but I need a signed-off-by line before I can apply
>> it. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it/tree/Documentation/process/submitting-patches.rst
>=20
> I'm happy to take it, I've been meaning to check if Olof sent a SOB in
> his original mail but haven't got to it.
>=20
> ...
>=20
> Yes, he did, see below.
>=20
> So I'll merge that, I'll add a Tested-by for you Christian.
>=20
> Christian please don't remove any of the tags when submitting other
> peoples' patches in future.
>=20
> cheers
>=20
>=20
> =46rom a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
> From: Olof Johansson <olof@lixom.net>
> Date: Sat, 2 Dec 2017 14:56:36 -0800
> Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
>=20
> Needed on Amiga X1000 with SB600.
>=20
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> arch/powerpc/platforms/pasemi/pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>=20
> diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/=
pasemi/pci.c
> index 5ff6108..ea54ed2 100644
> --- a/arch/powerpc/platforms/pasemi/pci.c
> +++ b/arch/powerpc/platforms/pasemi/pci.c
> @@ -224,6 +224,8 @@ void __init pas_pci_init(void)
> return;
> }
>=20
> + pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS):
> +
> for (np =3D NULL; (np =3D of_get_next_child(root, np)) !=3D NULL;)
> if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
> of_node_get(np);
^ permalink raw reply
* [PATCH v2 0/5] KVM TLB flushing improvements (for radix)
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
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:
- Fixed a bug where I mixed up PRS values, leading to guest page
fault hangs.
- Fixed up the hash cases that still need to be done in real-mode.
- Dropped the hash changes including the interesting case of a
hash tlbie issued by a radix host, for mixed mode support.
This has survived some stress testing over the weekend now, so
it should be ready for wider review.
Thanks,
Nick
Nicholas Piggin (5):
KVM: PPC: Book3S HV: radix use correct tlbie sequence in
kvmppc_radix_tlbie_page
powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM
KVM: PPC: Book3S HV: radix use the Linux TLB flush function in
kvmppc_radix_tlbie_page
KVM: PPC: Book3S HV: radix handle process scoped LPID flush in C, with
relocation on
KVM: PPC: Book3S HV: radix do not clear partition scoped page table
when page fault races with other vCPUs.
.../include/asm/book3s/64/tlbflush-radix.h | 6 +
arch/powerpc/kvm/book3s_64_mmu_radix.c | 78 ++++-----
arch/powerpc/kvm/book3s_hv.c | 26 +++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 13 +-
arch/powerpc/mm/tlb-radix.c | 160 ++++++++++++++++++
5 files changed, 238 insertions(+), 45 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/5] KVM: PPC: Book3S HV: radix use correct tlbie sequence in kvmppc_radix_tlbie_page
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180416043240.8796-1-npiggin@gmail.com>
The standard eieio ; tlbsync ; ptesync must follow tlbie to ensure it
is ordered with respect to subsequent operations.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
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_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 5d9bafe9a371..81d5ad26f9a1 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -160,7 +160,7 @@ static void kvmppc_radix_tlbie_page(struct kvm *kvm, unsigned long addr,
if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG))
asm volatile(PPC_TLBIE_5(%0, %1, 0, 0, 1)
: : "r" (addr), "r" (kvm->arch.lpid) : "memory");
- asm volatile("ptesync": : :"memory");
+ asm volatile("eieio ; tlbsync ; ptesync": : :"memory");
}
unsigned long kvmppc_radix_update_pte(struct kvm *kvm, pte_t *ptep,
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/5] powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180416043240.8796-1-npiggin@gmail.com>
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 <npiggin@gmail.com>
---
.../include/asm/book3s/64/tlbflush-radix.h | 6 +
arch/powerpc/mm/tlb-radix.c | 160 ++++++++++++++++++
2 files changed, 166 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 19b45ba6caf9..12c02c0e5a4b 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -51,4 +51,10 @@ extern void radix__flush_tlb_all(void);
extern void radix__flush_tlb_pte_p9_dd1(unsigned long old_pte, struct mm_struct *mm,
unsigned long address);
+extern void radix__flush_tlb_lpid_page(unsigned int lpid,
+ unsigned long addr,
+ unsigned long page_size);
+extern void radix__local_flush_tlb_lpid(unsigned int lpid);
+extern void radix__local_flush_tlb_lpid_guest(unsigned int lpid);
+
#endif
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 2fba6170ab3f..c2b001dc4dd9 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -119,6 +119,39 @@ static inline void __tlbie_pid(unsigned long pid, unsigned long ric)
trace_tlbie(0, 0, rb, rs, ric, prs, r);
}
+static inline void __tlbiel_lpid(unsigned long lpid, int set,
+ unsigned long ric)
+{
+ unsigned long rb,rs,prs,r;
+
+ rb = PPC_BIT(52); /* IS = 2 */
+ rb |= set << PPC_BITLSHIFT(51);
+ rs = 0; /* LPID comes from LPIDR */
+ prs = 0; /* partition scoped */
+ r = 1; /* radix format */
+
+ asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
+ : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
+ trace_tlbie(lpid, 1, rb, rs, ric, prs, r);
+}
+
+static inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
+ unsigned long ric)
+{
+ unsigned long rb,rs,prs,r;
+
+ rb = PPC_BIT(52); /* IS = 2 */
+ rb |= set << PPC_BITLSHIFT(51);
+ rs = 0; /* LPID comes from LPIDR */
+ prs = 1; /* process scoped */
+ r = 1; /* radix format */
+
+ asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
+ : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
+ trace_tlbie(lpid, 1, rb, rs, ric, prs, r);
+}
+
+
static inline void __tlbiel_va(unsigned long va, unsigned long pid,
unsigned long ap, unsigned long ric)
{
@@ -151,6 +184,22 @@ static inline void __tlbie_va(unsigned long va, unsigned long pid,
trace_tlbie(0, 0, rb, rs, ric, prs, r);
}
+static inline void __tlbie_lpid_va(unsigned long va, unsigned long lpid,
+ unsigned long ap, unsigned long ric)
+{
+ unsigned long rb,rs,prs,r;
+
+ rb = va & ~(PPC_BITMASK(52, 63));
+ rb |= ap << PPC_BITLSHIFT(58);
+ rs = lpid;
+ prs = 0; /* partition scoped */
+ r = 1; /* radix format */
+
+ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
+ : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
+ trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
+}
+
static inline void fixup_tlbie(void)
{
unsigned long pid = 0;
@@ -162,6 +211,16 @@ static inline void fixup_tlbie(void)
}
}
+static inline void fixup_tlbie_lpid(unsigned long lpid)
+{
+ unsigned long va = ((1UL << 52) - 1);
+
+ if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) {
+ asm volatile("ptesync": : :"memory");
+ __tlbie_lpid_va(va, lpid, mmu_get_ap(MMU_PAGE_64K), RIC_FLUSH_TLB);
+ }
+}
+
/*
* We use 128 set in radix mode and 256 set in hpt mode.
*/
@@ -215,6 +274,62 @@ static inline void _tlbie_pid(unsigned long pid, unsigned long ric)
asm volatile("eieio; tlbsync; ptesync": : :"memory");
}
+static inline void _tlbiel_lpid(unsigned long lpid, unsigned long ric)
+{
+ int set;
+
+ VM_BUG_ON(mfspr(SPRN_LPID) != lpid);
+
+ asm volatile("ptesync": : :"memory");
+
+ /*
+ * Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
+ * also flush the entire Page Walk Cache.
+ */
+ __tlbiel_lpid(lpid, 0, ric);
+
+ /* For PWC, only one flush is needed */
+ if (ric == RIC_FLUSH_PWC) {
+ asm volatile("ptesync": : :"memory");
+ return;
+ }
+
+ /* For the remaining sets, just flush the TLB */
+ for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
+ __tlbiel_lpid(lpid, set, RIC_FLUSH_TLB);
+
+ asm volatile("ptesync": : :"memory");
+ asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
+}
+
+static inline void _tlbiel_lpid_guest(unsigned long lpid, unsigned long ric)
+{
+ int set;
+
+ VM_BUG_ON(mfspr(SPRN_LPID) != lpid);
+
+ asm volatile("ptesync": : :"memory");
+
+ /*
+ * Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
+ * also flush the entire Page Walk Cache.
+ */
+ __tlbiel_lpid_guest(lpid, 0, ric);
+
+ /* For PWC, only one flush is needed */
+ if (ric == RIC_FLUSH_PWC) {
+ asm volatile("ptesync": : :"memory");
+ return;
+ }
+
+ /* For the remaining sets, just flush the TLB */
+ for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
+ __tlbiel_lpid_guest(lpid, set, RIC_FLUSH_TLB);
+
+ asm volatile("ptesync": : :"memory");
+}
+
+
static inline void __tlbiel_va_range(unsigned long start, unsigned long end,
unsigned long pid, unsigned long page_size,
unsigned long psize)
@@ -269,6 +384,17 @@ static inline void _tlbie_va(unsigned long va, unsigned long pid,
asm volatile("eieio; tlbsync; ptesync": : :"memory");
}
+static inline void _tlbie_lpid_va(unsigned long va, unsigned long lpid,
+ unsigned long psize, unsigned long ric)
+{
+ unsigned long ap = mmu_get_ap(psize);
+
+ asm volatile("ptesync": : :"memory");
+ __tlbie_lpid_va(va, lpid, ap, ric);
+ fixup_tlbie_lpid(lpid);
+ asm volatile("eieio; tlbsync; ptesync": : :"memory");
+}
+
static inline void _tlbie_va_range(unsigned long start, unsigned long end,
unsigned long pid, unsigned long page_size,
unsigned long psize, bool also_pwc)
@@ -535,6 +661,40 @@ static int radix_get_mmu_psize(int page_size)
return psize;
}
+/*
+ * Flush partition scoped LPID address translation for all CPUs.
+ */
+void radix__flush_tlb_lpid_page(unsigned int lpid,
+ unsigned long addr,
+ unsigned long page_size)
+{
+ int psize = radix_get_mmu_psize(page_size);
+
+ _tlbie_lpid_va(addr, lpid, psize, RIC_FLUSH_TLB);
+}
+EXPORT_SYMBOL_GPL(radix__flush_tlb_lpid_page);
+
+/*
+ * Flush partition scoped translations from LPID (=LPIDR)
+ */
+void radix__local_flush_tlb_lpid(unsigned int lpid)
+{
+ _tlbiel_lpid(lpid, RIC_FLUSH_ALL);
+}
+EXPORT_SYMBOL_GPL(radix__local_flush_tlb_lpid);
+
+/*
+ * Flush process scoped translations from LPID (=LPIDR).
+ * Important difference, the guest normally manages its own translations,
+ * but some cases e.g., vCPU CPU migration require KVM to flush.
+ */
+void radix__local_flush_tlb_lpid_guest(unsigned int lpid)
+{
+ _tlbiel_lpid_guest(lpid, RIC_FLUSH_ALL);
+}
+EXPORT_SYMBOL_GPL(radix__local_flush_tlb_lpid_guest);
+
+
static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
unsigned long end, int psize);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 3/5] KVM: PPC: Book3S HV: radix use the Linux TLB flush function in kvmppc_radix_tlbie_page
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180416043240.8796-1-npiggin@gmail.com>
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 <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 81d5ad26f9a1..dab6b622011c 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -139,28 +139,16 @@ int kvmppc_mmu_radix_xlate(struct kvm_vcpu *vcpu, gva_t eaddr,
return 0;
}
-#ifdef CONFIG_PPC_64K_PAGES
-#define MMU_BASE_PSIZE MMU_PAGE_64K
-#else
-#define MMU_BASE_PSIZE MMU_PAGE_4K
-#endif
-
static void kvmppc_radix_tlbie_page(struct kvm *kvm, unsigned long addr,
unsigned int pshift)
{
- int psize = MMU_BASE_PSIZE;
-
- if (pshift >= PMD_SHIFT)
- psize = MMU_PAGE_2M;
- addr &= ~0xfffUL;
- addr |= mmu_psize_defs[psize].ap << 5;
- asm volatile("ptesync": : :"memory");
- asm volatile(PPC_TLBIE_5(%0, %1, 0, 0, 1)
- : : "r" (addr), "r" (kvm->arch.lpid) : "memory");
- if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG))
- asm volatile(PPC_TLBIE_5(%0, %1, 0, 0, 1)
- : : "r" (addr), "r" (kvm->arch.lpid) : "memory");
- asm volatile("eieio ; tlbsync ; ptesync": : :"memory");
+ unsigned long psize = PAGE_SIZE;
+
+ if (pshift)
+ psize = 1UL << pshift;
+
+ addr &= ~(psize - 1);
+ radix__flush_tlb_lpid_page(kvm->arch.lpid, addr, psize);
}
unsigned long kvmppc_radix_update_pte(struct kvm *kvm, pte_t *ptep,
--
2.17.0
^ permalink raw reply related
* [PATCH v2 4/5] KVM: PPC: Book3S HV: radix handle process scoped LPID flush in C, with relocation on
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180416043240.8796-1-npiggin@gmail.com>
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 RIC=2 flush once on
the first set flushed, which matches the rest of the Linux flushing.
This does not change semantics of the flush.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_hv.c | 26 +++++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 13 ++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 81e2ea882d97..c1660df41190 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2901,6 +2901,32 @@ static noinline void kvmppc_run_core(struct kvmppc_vcore *vc)
for (sub = 0; sub < core_info.n_subcores; ++sub)
spin_unlock(&core_info.vc[sub]->lock);
+ if (kvm_is_radix(vc->kvm)) {
+ int tmp = pcpu;
+
+ /*
+ * Do we need to flush the process scoped TLB for the LPAR?
+ *
+ * On POWER9, individual threads can come in here, but the
+ * TLB is shared between the 4 threads in a core, hence
+ * invalidating on one thread invalidates for all.
+ * Thus we make all 4 threads use the same bit here.
+ *
+ * Hash must be flushed in realmode in order to use tlbiel.
+ */
+ mtspr(SPRN_LPID, vc->kvm->arch.lpid);
+ isync();
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300))
+ tmp &= ~0x3UL;
+
+ if (cpumask_test_cpu(tmp, &vc->kvm->arch.need_tlb_flush)) {
+ radix__local_flush_tlb_lpid_guest(vc->kvm->arch.lpid);
+ /* Clear the bit after the TLB flush */
+ cpumask_clear_cpu(tmp, &vc->kvm->arch.need_tlb_flush);
+ }
+ }
+
/*
* Interrupts will be enabled once we get into the guest,
* so tell lockdep that we're about to enable interrupts.
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index bd63fa8a08b5..d4c7bb3e777e 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -636,6 +636,10 @@ kvmppc_hv_entry:
/* Primary thread switches to guest partition. */
cmpwi r6,0
bne 10f
+
+ /* Radix has already switched LPID and flushed core TLB */
+ bne cr7,22f
+
lwz r7,KVM_LPID(r9)
BEGIN_FTR_SECTION
ld r6,KVM_SDR1(r9)
@@ -647,7 +651,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
mtspr SPRN_LPID,r7
isync
- /* See if we need to flush the TLB */
+ /* See if we need to flush the TLB. Hash has to be done in RM */
lhz r6,PACAPACAINDEX(r13) /* test_bit(cpu, need_tlb_flush) */
BEGIN_FTR_SECTION
/*
@@ -674,15 +678,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
li r7,0x800 /* IS field = 0b10 */
ptesync
li r0,0 /* RS for P9 version of tlbiel */
- bne cr7, 29f
28: tlbiel r7 /* On P9, rs=0, RIC=0, PRS=0, R=0 */
addi r7,r7,0x1000
bdnz 28b
- b 30f
-29: PPC_TLBIEL(7,0,2,1,1) /* for radix, RIC=2, PRS=1, R=1 */
- addi r7,r7,0x1000
- bdnz 29b
-30: ptesync
+ ptesync
23: ldarx r7,0,r6 /* clear the bit after TLB flushed */
andc r7,r7,r8
stdcx. r7,0,r6
--
2.17.0
^ permalink raw reply related
* [PATCH v2 5/5] KVM: PPC: Book3S HV: radix do not clear partition scoped page table when page fault races with other vCPUs.
From: Nicholas Piggin @ 2018-04-16 4:32 UTC (permalink / raw)
To: kvm-ppc; +Cc: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20180416043240.8796-1-npiggin@gmail.com>
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 guest threads can hit page faults for the
same addresses, this can happen when KSM or THP takes out a commonly
used page. gRA zero (the interrupt vectors and important kernel text)
was a common one. Multiple CPUs will page fault and contend on the
same lock, when one CPU sets up the page table and releases the lock,
the next will find the new entry and invalidate it before installing
its own, which causes other page faults which invalidate that entry,
etc.
The solution to this is to avoid invalidating the entry or flushing
TLBs in case of a race. The pte may still need bits updated, but
those are to add R/C or relax access restrictions so no flush is
required.
This solves the page fault / tlbie storms.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 52 ++++++++++++++++----------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index dab6b622011c..2d3af22f90dd 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -199,7 +199,6 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
pud_t *pud, *new_pud = NULL;
pmd_t *pmd, *new_pmd = NULL;
pte_t *ptep, *new_ptep = NULL;
- unsigned long old;
int ret;
/* Traverse the guest's 2nd-level tree, allocate new levels needed */
@@ -243,6 +242,7 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
pmd = pmd_offset(pud, gpa);
if (pmd_is_leaf(*pmd)) {
unsigned long lgpa = gpa & PMD_MASK;
+ pte_t old_pte = *pmdp_ptep(pmd);
/*
* If we raced with another CPU which has just put
@@ -252,18 +252,22 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
ret = -EAGAIN;
goto out_unlock;
}
- /* Valid 2MB page here already, remove it */
- old = kvmppc_radix_update_pte(kvm, pmdp_ptep(pmd),
- ~0UL, 0, lgpa, PMD_SHIFT);
- kvmppc_radix_tlbie_page(kvm, lgpa, PMD_SHIFT);
- if (old & _PAGE_DIRTY) {
- unsigned long gfn = lgpa >> PAGE_SHIFT;
- struct kvm_memory_slot *memslot;
- memslot = gfn_to_memslot(kvm, gfn);
- if (memslot && memslot->dirty_bitmap)
- kvmppc_update_dirty_map(memslot,
- gfn, PMD_SIZE);
+
+ /* PTE was previously valid, so update it */
+ if (pte_val(old_pte) == pte_val(pte)) {
+ ret = -EAGAIN;
+ goto out_unlock;
}
+
+ /* Make sure we're weren't trying to take bits away */
+ WARN_ON_ONCE(pte_pfn(old_pte) != pte_pfn(pte));
+ WARN_ON_ONCE((pte_val(old_pte) & ~pte_val(pte)) &
+ (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE));
+
+ kvmppc_radix_update_pte(kvm, pmdp_ptep(pmd),
+ 0, pte_val(pte), lgpa, PMD_SHIFT);
+ ret = 0;
+ goto out_unlock;
} else if (level == 1 && !pmd_none(*pmd)) {
/*
* There's a page table page here, but we wanted
@@ -274,6 +278,8 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
goto out_unlock;
}
if (level == 0) {
+ pte_t old_pte;
+
if (pmd_none(*pmd)) {
if (!new_ptep)
goto out_unlock;
@@ -281,13 +287,21 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
new_ptep = NULL;
}
ptep = pte_offset_kernel(pmd, gpa);
- if (pte_present(*ptep)) {
- /* PTE was previously valid, so invalidate it */
- old = kvmppc_radix_update_pte(kvm, ptep, _PAGE_PRESENT,
- 0, gpa, 0);
- kvmppc_radix_tlbie_page(kvm, gpa, 0);
- if (old & _PAGE_DIRTY)
- mark_page_dirty(kvm, gpa >> PAGE_SHIFT);
+ old_pte = *ptep;
+ if (pte_present(old_pte)) {
+ /* PTE was previously valid, so update it */
+ if (pte_val(old_pte) == pte_val(pte)) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
+
+ /* Make sure we're weren't trying to take bits away */
+ WARN_ON_ONCE(pte_pfn(old_pte) != pte_pfn(pte));
+ WARN_ON_ONCE((pte_val(old_pte) & ~pte_val(pte)) &
+ (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE));
+
+ kvmppc_radix_update_pte(kvm, ptep, 0,
+ pte_val(pte), gpa, 0);
}
kvmppc_radix_set_pte_at(kvm, gpa, ptep, pte);
} else {
--
2.17.0
^ permalink raw reply related
* [PATCHv2 0/3] post the event cpux add/remove besides online/offline during hotplug
From: Pingfan Liu @ 2018-04-16 6:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Hari Bathini
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: dynmamically to create/destroy the file physical_id
during hotplug
powerpc/cpu: post the event cpux add/remove instead of online/offline
during hotplug
arch/powerpc/include/asm/smp.h | 1 +
arch/powerpc/kernel/sysfs.c | 26 ++++++++++++++------------
arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 +++
drivers/cpuidle/cpuidle-powernv.c | 2 ++
drivers/cpuidle/cpuidle-pseries.c | 2 ++
5 files changed, 22 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCHv2 1/3] powerpc/cpuidle: dynamically register/unregister cpuidle_device during hotplug
From: Pingfan Liu @ 2018-04-16 6:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Hari Bathini
In-Reply-To: <1523860508-19364-1-git-send-email-kernelfans@gmail.com>
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 <kernelfans@gmail.com>
Reviewed-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
drivers/cpuidle/cpuidle-powernv.c | 2 ++
drivers/cpuidle/cpuidle-pseries.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 1a8234e..962c944 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -144,6 +144,7 @@ static int powernv_cpuidle_cpu_online(unsigned int cpu)
struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
if (dev && cpuidle_get_driver()) {
+ cpuidle_register_device(dev);
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
@@ -159,6 +160,7 @@ static int powernv_cpuidle_cpu_dead(unsigned int cpu)
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
+ cpuidle_unregister_device(dev);
}
return 0;
}
diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index 9e56bc4..a53be8a 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -193,6 +193,7 @@ static int pseries_cpuidle_cpu_online(unsigned int cpu)
struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
if (dev && cpuidle_get_driver()) {
+ cpuidle_register_device(dev);
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
@@ -208,6 +209,7 @@ static int pseries_cpuidle_cpu_dead(unsigned int cpu)
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
+ cpuidle_unregister_device(dev);
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCHv2 2/3] powerpc/cpu: dynmamically to create/destroy the file physical_id during hotplug
From: Pingfan Liu @ 2018-04-16 6:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Hari Bathini
In-Reply-To: <1523860508-19364-1-git-send-email-kernelfans@gmail.com>
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 <kernelfans@gmail.com>
Reported-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/kernel/sysfs.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 04d0bbd..a05ab5e 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -716,6 +716,16 @@ static struct device_attribute pa6t_attrs[] = {
#endif /* HAS_PPC_PMC_PA6T */
#endif /* HAS_PPC_PMC_CLASSIC */
+/* Only valid if CPU is present. */
+static ssize_t show_physical_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, dev);
+
+ return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
+}
+static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
+
static int register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
@@ -723,6 +733,8 @@ static int register_cpu_online(unsigned int cpu)
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ device_create_file(&c->dev, &dev_attr_physical_id);
+
/* For cpus present at boot a reference was already grabbed in register_cpu() */
if (!s->of_node)
s->of_node = of_get_cpu_node(cpu, NULL);
@@ -816,6 +828,7 @@ static int unregister_cpu_online(unsigned int cpu)
BUG_ON(!c->hotpluggable);
+ device_remove_file(s, &dev_attr_physical_id);
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_remove_file(s, &dev_attr_smt_snooze_delay);
@@ -1017,16 +1030,6 @@ static void register_nodes(void)
#endif
-/* Only valid if CPU is present. */
-static ssize_t show_physical_id(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct cpu *cpu = container_of(dev, struct cpu, dev);
-
- return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
-}
-static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
-
static int __init topology_init(void)
{
int cpu, r;
@@ -1049,7 +1052,6 @@ static int __init topology_init(void)
if (cpu_online(cpu) || c->hotpluggable) {
register_cpu(c, cpu);
- device_create_file(&c->dev, &dev_attr_physical_id);
}
}
r = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "powerpc/topology:online",
--
2.7.4
^ permalink raw reply related
* [PATCHv2 3/3] powerpc/cpu: post the event cpux add/remove instead of online/offline during hotplug
From: Pingfan Liu @ 2018-04-16 6:35 UTC (permalink / raw)
To: linuxppc-dev
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Hari Bathini
In-Reply-To: <1523860508-19364-1-git-send-email-kernelfans@gmail.com>
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 rebuilt correctly, we may hang on 2nd kernel due to
lack the info of boot-cpu-hwid in dtb.
The steps to trigger the bug: (suppose 8 threads/core)
drmgr -c cpu -r -q 1
systemctl restart kdump.service
drmgr -c cpu -a -q 1
taskset -c 11 sh -c "echo c > /proc/sysrq-trigger"
Then, failure info:
[ 205.299528] SysRq : Trigger a crash
[ 205.299551] Unable to handle kernel paging request for data at address 0x00000000
[ 205.299558] Faulting instruction address: 0xc0000000006001a0
[ 205.299564] Oops: Kernel access of bad area, sig: 11 [#1]
[ 205.299569] SMP NR_CPUS=2048 NUMA pSeries
[ 205.299575] Modules linked in: macsec sctp_diag sctp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter xfs libcrc32c sg
pseries_rng binfmt_misc ip_tables ext4 mbcache jbd2 sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[ 205.299658] CPU: 11 PID: 2521 Comm: bash Not tainted 3.10.0-799.el7.ppc64le #1
[ 205.299664] task: c00000017bcd15e0 ti: c00000014f410000 task.ti: c00000014f410000
[ 205.299670] NIP: c0000000006001a0 LR: c000000000600ddc CTR: c000000000600180
[ 205.299676] REGS: c00000014f413a70 TRAP: 0300 Not tainted (3.10.0-799.el7.ppc64le)
[ 205.299681] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28222822 XER: 00000001
[ 205.299696] CFAR: c000000000009368 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
GPR00: c000000000600dbc c00000014f413cf0 c000000001263200 0000000000000063
GPR04: c0000000019ca818 c0000000019db5f8 00000000000000c2 c00000000140aa30
GPR08: 0000000000000007 0000000000000001 0000000000000000 c00000000140fc60
GPR12: c000000000600180 c000000007b36300 0000000010139e58 0000000040000000
GPR16: 000000001013b5d0 0000000000000000 00000000101306fc 0000000010139de4
GPR20: 0000000010139de8 0000000010093150 0000000000000000 0000000000000000
GPR24: 000000001013b5e0 00000000100fa0e8 0000000000000007 c0000000011af1c8
GPR28: 0000000000000063 c0000000011af588 c000000001179ba8 0000000000000002
[ 205.299770] NIP [c0000000006001a0] sysrq_handle_crash+0x20/0x30
[ 205.299776] LR [c000000000600ddc] write_sysrq_trigger+0x10c/0x230
[ 205.299781] Call Trace:
[ 205.299786] [c00000014f413cf0] [c000000000600dbc] write_sysrq_trigger+0xec/0x230 (unreliable)
[ 205.299794] [c00000014f413d90] [c0000000003eb2c4] proc_reg_write+0x84/0x120
[ 205.299801] [c00000014f413dd0] [c000000000330a80] SyS_write+0x150/0x400
[ 205.299808] [c00000014f413e30] [c00000000000a184] system_call+0x38/0xb4
[ 205.299813] Instruction dump:
[ 205.299816] 409effb8 7fc3f378 4bfff381 4bffffac 3c4c00c6 38423080 3d42fff1 394a6930
[ 205.299827] 39200001 912a0000 7c0004ac 39400000 <992a0000> 4e800020 60000000 60420000
[ 205.299838] ---[ end trace f590a5dbd3f63aab ]---
[ 205.301812]
[ 205.301829] Sending IPI to other CPUs
[ 205.302846] IPI complete
I'm in purgatory
-- > hang up here
This patch uses the interface register_/unregister_cpu to fix the problem
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Reported-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 1 +
arch/powerpc/kernel/sysfs.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index fac963e..3ef730d 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -35,6 +35,7 @@ extern int spinning_secondaries;
extern void cpu_die(void);
extern int cpu_to_chip_id(int cpu);
+DECLARE_PER_CPU(struct cpu, cpu_devices);
#ifdef CONFIG_SMP
struct smp_ops_t {
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index a05ab5e..dbbcc96 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -26,7 +26,7 @@
#include <asm/lppaca.h>
#endif
-static DEFINE_PER_CPU(struct cpu, cpu_devices);
+DEFINE_PER_CPU(struct cpu, cpu_devices);
/*
* SMT snooze delay stuff, 64-bit only for now
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 652d3e96..27a1551 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -367,6 +367,7 @@ static int dlpar_online_cpu(struct device_node *dn)
cpu_maps_update_done();
timed_topology_update(1);
find_and_online_cpu_nid(cpu);
+ register_cpu(&per_cpu(cpu_devices, cpu), cpu);
rc = device_online(get_cpu_device(cpu));
if (rc)
goto out;
@@ -541,6 +542,8 @@ static int dlpar_offline_cpu(struct device_node *dn)
rc = device_offline(get_cpu_device(cpu));
if (rc)
goto out;
+ unregister_cpu(container_of(get_cpu_device(cpu),
+ struct cpu, dev));
cpu_maps_update_begin();
break;
--
2.7.4
^ permalink raw reply related
* [PATCH V1 00/11] powerpc/mm/book3s64: Support for split pmd ptlock
From: Aneesh Kumar K.V @ 2018-04-16 11:27 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
This patch series add split pmd pagetable lock for book3s64. nohash64 also should
be able to switch to this. I need to workout the code dependency. This series
also migh have broken the build on platforms otherthan book3s64. I am sending this early
to get feedback on whether we should continue with the approach.
We switch the pmd allocator to use something similar to what we already use for
level 4 pagetable allocation. We get an order 0 page and divide that to fragments
and hand over fragments when we get request for a pmd pagetable. The pmd lock is
now stashed in the struct page backing the allocated page.
The series helps in reducing lock contention on mm->page_table_lock.
without patch
32.72% mmap_bench [kernel.vmlinux] [k] do_raw_spin_lock
|
---do_raw_spin_lock
|
--32.68%--0
|
|--15.82%--pte_fragment_alloc
| |
| --15.79%--do_huge_pmd_anonymous_page
| __handle_mm_fault
| handle_mm_fault
| __do_page_fault
| handle_page_fault
| test_mmap
| test_mmap
| start_thread
| __clone
|
|--14.95%--do_huge_pmd_anonymous_page
| __handle_mm_fault
| handle_mm_fault
| __do_page_fault
| handle_page_fault
| test_mmap
| test_mmap
| start_thread
| __clone
|
with patch
12.89% mmap_bench [kernel.vmlinux] [k] do_raw_spin_lock
|
---do_raw_spin_lock
|
--12.83%--0
|
|--3.21%--pagevec_lru_move_fn
| __lru_cache_add
| |
| --2.74%--do_huge_pmd_anonymous_page
| __handle_mm_fault
| handle_mm_fault
| __do_page_fault
| handle_page_fault
| test_mmap
| test_mmap
| start_thread
| __clone
|
|--3.11%--do_huge_pmd_anonymous_page
| __handle_mm_fault
| handle_mm_fault
| __do_page_fault
| handle_page_fault
| test_mmap
| test_mmap
| start_thread
| __clone
.....
|
--0.55%--pte_fragment_alloc
|
--0.55%--do_huge_pmd_anonymous_page
__handle_mm_fault
handle_mm_fault
__do_page_fault
handle_page_fault
test_mmap
test_mmap
start_thread
__clone
Aneesh Kumar K.V (11):
powerpc/mm/book3s64: Move book3s64 code to pgtable-book3s64
powerpc/kvm: Switch kvm pmd allocator to custom allocator
powerpc/mm: Use pmd_lockptr instead of opencoding it
powerpc/mm: Rename pte fragment functions
powerpc/mm/book3e/64: Remove unsupported 64Kpage size from 64bit booke
powerpc/mm/nohash: Remove pte fragment dependency from nohash
powerpc/mm/book3s64/4k: Switch 4k pagesize config to use pagetable
fragment
powerpc/book3s64/mm: Simplify the rcu callback for page table free
powerpc/mm: Implement helpers for pagetable fragment support at PMD
level
powerpc/mm: Use page fragments for allocation page table at PMD level
powerpc/book3s64: Enable split pmd ptlock.
arch/powerpc/include/asm/book3s/64/hash-4k.h | 8 +-
arch/powerpc/include/asm/book3s/64/hash-64k.h | 7 +
arch/powerpc/include/asm/book3s/64/hash.h | 10 -
arch/powerpc/include/asm/book3s/64/mmu.h | 7 +-
arch/powerpc/include/asm/book3s/64/pgalloc.h | 46 +---
arch/powerpc/include/asm/book3s/64/pgtable.h | 20 +-
arch/powerpc/include/asm/book3s/64/radix-4k.h | 3 +
arch/powerpc/include/asm/book3s/64/radix-64k.h | 4 +
arch/powerpc/include/asm/mmu-book3e.h | 6 -
arch/powerpc/include/asm/nohash/64/pgalloc.h | 95 +++-----
arch/powerpc/include/asm/nohash/64/pgtable-64k.h | 57 -----
arch/powerpc/include/asm/nohash/64/pgtable.h | 8 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 36 ++-
arch/powerpc/mm/hash_utils_64.c | 3 +-
arch/powerpc/mm/mmu_context_book3s64.c | 39 +++-
arch/powerpc/mm/pgtable-book3s64.c | 267 ++++++++++++++++++++++-
arch/powerpc/mm/pgtable-hash64.c | 8 +-
arch/powerpc/mm/pgtable-radix.c | 5 +-
arch/powerpc/mm/pgtable_64.c | 171 ---------------
arch/powerpc/platforms/Kconfig.cputype | 4 +
20 files changed, 427 insertions(+), 377 deletions(-)
delete mode 100644 arch/powerpc/include/asm/nohash/64/pgtable-64k.h
--
2.14.3
^ permalink raw reply
* [PATCH] powerpc/8xx: Build fix with Hugetlbfs enabled
From: Aneesh Kumar K.V @ 2018-04-16 11:27 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V, Christophe LEROY
In-Reply-To: <20180416112724.9677-1-aneesh.kumar@linux.ibm.com>
8xx use slice code when hugetlbfs is enabled. We missed a header include on
8xx which resulted in the below build failure.
config: mpc885_ads_defconfig + CONFIG_HUGETLBFS
CC arch/powerpc/mm/slice.o
arch/powerpc/mm/slice.c: In function 'slice_get_unmapped_area':
arch/powerpc/mm/slice.c:655:2: error: implicit declaration of function 'need_extra_context' [-Werror=implicit-function-declaration]
arch/powerpc/mm/slice.c:656:3: error: implicit declaration of function 'alloc_extended_context' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/mm/slice.o] Error 1
make: *** [arch/powerpc/mm] Error 2
on PPC64 the mmu_context.h was included via linux/pkeys.h
CC: Christophe LEROY <christophe.leroy@c-s.fr>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/slice.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 9cd87d11fe4e..205fe557ca10 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -35,6 +35,7 @@
#include <asm/mmu.h>
#include <asm/copro.h>
#include <asm/hugetlb.h>
+#include <asm/mmu_context.h>
static DEFINE_SPINLOCK(slice_convert_lock);
--
2.14.3
^ permalink raw reply related
* [PATCH V1 01/11] powerpc/mm/book3s64: Move book3s64 code to pgtable-book3s64
From: Aneesh Kumar K.V @ 2018-04-16 11:27 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180416112724.9677-1-aneesh.kumar@linux.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Only code movement and avoid #ifdef.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/pgtable-book3s64.c | 54 ++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/pgtable_64.c | 56 --------------------------------------
2 files changed, 54 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/mm/pgtable-book3s64.c b/arch/powerpc/mm/pgtable-book3s64.c
index 518518fb7c45..35913b0b6d56 100644
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@ -9,10 +9,13 @@
#include <linux/sched.h>
#include <linux/mm_types.h>
+#include <linux/memblock.h>
#include <misc/cxl-base.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
+#include <asm/trace.h>
+#include <asm/powernv.h>
#include "mmu_decl.h"
#include <trace/events/thp.h>
@@ -171,3 +174,54 @@ int __meminit remove_section_mapping(unsigned long start, unsigned long end)
return hash__remove_section_mapping(start, end);
}
#endif /* CONFIG_MEMORY_HOTPLUG */
+
+void __init mmu_partition_table_init(void)
+{
+ unsigned long patb_size = 1UL << PATB_SIZE_SHIFT;
+ unsigned long ptcr;
+
+ BUILD_BUG_ON_MSG((PATB_SIZE_SHIFT > 36), "Partition table size too large.");
+ partition_tb = __va(memblock_alloc_base(patb_size, patb_size,
+ MEMBLOCK_ALLOC_ANYWHERE));
+
+ /* Initialize the Partition Table with no entries */
+ memset((void *)partition_tb, 0, patb_size);
+
+ /*
+ * update partition table control register,
+ * 64 K size.
+ */
+ ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
+ mtspr(SPRN_PTCR, ptcr);
+ powernv_set_nmmu_ptcr(ptcr);
+}
+
+void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
+ unsigned long dw1)
+{
+ unsigned long old = be64_to_cpu(partition_tb[lpid].patb0);
+
+ partition_tb[lpid].patb0 = cpu_to_be64(dw0);
+ partition_tb[lpid].patb1 = cpu_to_be64(dw1);
+
+ /*
+ * Global flush of TLBs and partition table caches for this lpid.
+ * The type of flush (hash or radix) depends on what the previous
+ * use of this partition ID was, not the new use.
+ */
+ asm volatile("ptesync" : : : "memory");
+ if (old & PATB_HR) {
+ asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
+ "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
+ asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
+ "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
+ trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
+ } else {
+ asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
+ "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
+ trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 0);
+ }
+ /* do we need fixup here ?*/
+ asm volatile("eieio; tlbsync; ptesync" : : : "memory");
+}
+EXPORT_SYMBOL_GPL(mmu_partition_table_set_entry);
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 9bf659d5078c..a41784dd2042 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -33,7 +33,6 @@
#include <linux/swap.h>
#include <linux/stddef.h>
#include <linux/vmalloc.h>
-#include <linux/memblock.h>
#include <linux/slab.h>
#include <linux/hugetlb.h>
@@ -47,13 +46,11 @@
#include <asm/smp.h>
#include <asm/machdep.h>
#include <asm/tlb.h>
-#include <asm/trace.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/sections.h>
#include <asm/firmware.h>
#include <asm/dma.h>
-#include <asm/powernv.h>
#include "mmu_decl.h"
@@ -429,59 +426,6 @@ void pgtable_free_tlb(struct mmu_gather *tlb, void *table, int shift)
}
#endif
-#ifdef CONFIG_PPC_BOOK3S_64
-void __init mmu_partition_table_init(void)
-{
- unsigned long patb_size = 1UL << PATB_SIZE_SHIFT;
- unsigned long ptcr;
-
- BUILD_BUG_ON_MSG((PATB_SIZE_SHIFT > 36), "Partition table size too large.");
- partition_tb = __va(memblock_alloc_base(patb_size, patb_size,
- MEMBLOCK_ALLOC_ANYWHERE));
-
- /* Initialize the Partition Table with no entries */
- memset((void *)partition_tb, 0, patb_size);
-
- /*
- * update partition table control register,
- * 64 K size.
- */
- ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
- mtspr(SPRN_PTCR, ptcr);
- powernv_set_nmmu_ptcr(ptcr);
-}
-
-void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
- unsigned long dw1)
-{
- unsigned long old = be64_to_cpu(partition_tb[lpid].patb0);
-
- partition_tb[lpid].patb0 = cpu_to_be64(dw0);
- partition_tb[lpid].patb1 = cpu_to_be64(dw1);
-
- /*
- * Global flush of TLBs and partition table caches for this lpid.
- * The type of flush (hash or radix) depends on what the previous
- * use of this partition ID was, not the new use.
- */
- asm volatile("ptesync" : : : "memory");
- if (old & PATB_HR) {
- asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
- "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
- asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
- "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
- trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
- } else {
- asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
- "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
- trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 0);
- }
- /* do we need fixup here ?*/
- asm volatile("eieio; tlbsync; ptesync" : : : "memory");
-}
-EXPORT_SYMBOL_GPL(mmu_partition_table_set_entry);
-#endif /* CONFIG_PPC_BOOK3S_64 */
-
#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
--
2.14.3
^ permalink raw reply related
* [PATCH V1 02/11] powerpc/kvm: Switch kvm pmd allocator to custom allocator
From: Aneesh Kumar K.V @ 2018-04-16 11:27 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180416112724.9677-1-aneesh.kumar@linux.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
In the next set of patches, we will switch pmd allocator to use page fragments
and the locking will be updated to split pmd ptlock. We want to avoid using
fragments for partition-scoped table. Use slab cache similar to level 4 table
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 36 +++++++++++++++++++++++++++++-----
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index a57eafec4dc2..ccdf3761eec0 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -200,6 +200,7 @@ void kvmppc_radix_set_pte_at(struct kvm *kvm, unsigned long addr,
}
static struct kmem_cache *kvm_pte_cache;
+static struct kmem_cache *kvm_pmd_cache;
static pte_t *kvmppc_pte_alloc(void)
{
@@ -217,6 +218,16 @@ static inline int pmd_is_leaf(pmd_t pmd)
return !!(pmd_val(pmd) & _PAGE_PTE);
}
+static pmd_t *kvmppc_pmd_alloc(void)
+{
+ return kmem_cache_alloc(kvm_pmd_cache, GFP_KERNEL);
+}
+
+static void kvmppc_pmd_free(pmd_t *pmdp)
+{
+ kmem_cache_free(kvm_pmd_cache, pmdp);
+}
+
static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
unsigned int level, unsigned long mmu_seq)
{
@@ -239,7 +250,7 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
if (pud && pud_present(*pud) && !pud_huge(*pud))
pmd = pmd_offset(pud, gpa);
else if (level <= 1)
- new_pmd = pmd_alloc_one(kvm->mm, gpa);
+ new_pmd = kvmppc_pmd_alloc();
if (level == 0 && !(pmd && pmd_present(*pmd) && !pmd_is_leaf(*pmd)))
new_ptep = kvmppc_pte_alloc();
@@ -382,7 +393,7 @@ static int kvmppc_create_pte(struct kvm *kvm, pte_t pte, unsigned long gpa,
if (new_pud)
pud_free(kvm->mm, new_pud);
if (new_pmd)
- pmd_free(kvm->mm, new_pmd);
+ kvmppc_pmd_free(new_pmd);
if (new_ptep)
kvmppc_pte_free(new_ptep);
return ret;
@@ -758,7 +769,7 @@ void kvmppc_free_radix(struct kvm *kvm)
kvmppc_pte_free(pte);
pmd_clear(pmd);
}
- pmd_free(kvm->mm, pmd_offset(pud, 0));
+ kvmppc_pmd_free(pmd_offset(pud, 0));
pud_clear(pud);
}
pud_free(kvm->mm, pud_offset(pgd, 0));
@@ -770,20 +781,35 @@ void kvmppc_free_radix(struct kvm *kvm)
static void pte_ctor(void *addr)
{
- memset(addr, 0, PTE_TABLE_SIZE);
+ memset(addr, 0, RADIX_PTE_TABLE_SIZE);
+}
+
+static void pmd_ctor(void *addr)
+{
+ memset(addr, 0, RADIX_PMD_TABLE_SIZE);
}
int kvmppc_radix_init(void)
{
- unsigned long size = sizeof(void *) << PTE_INDEX_SIZE;
+ unsigned long size = sizeof(void *) << RADIX_PTE_INDEX_SIZE;
kvm_pte_cache = kmem_cache_create("kvm-pte", size, size, 0, pte_ctor);
if (!kvm_pte_cache)
return -ENOMEM;
+
+ size = sizeof(void *) << RADIX_PMD_INDEX_SIZE;
+
+ kvm_pmd_cache = kmem_cache_create("kvm-pmd", size, size, 0, pmd_ctor);
+ if (!kvm_pmd_cache) {
+ kmem_cache_destroy(kvm_pte_cache);
+ return -ENOMEM;
+ }
+
return 0;
}
void kvmppc_radix_exit(void)
{
kmem_cache_destroy(kvm_pte_cache);
+ kmem_cache_destroy(kvm_pmd_cache);
}
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox