* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 2:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730012650.GB24931@suse.de>
On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> We will change to a BSD 3 clause license header. Our legal counsel is
>> >> talking to Synopsis to make this change.
>> >
>> > Why BSD? =C2=A0You do realize what that means when combined within the=
body
>> > of the kernel, right?
>> >
>>
>> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hil driver.
>
> What specific driver is this?
FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> And are you sure that all of the contributors to the code agree with
> this licensing change? =C2=A0Are you going to require contributors to
> dual-license their changes?
>
> If so, why keep it BSD, what does that get you?
FKAN: for one thing, to make it future proof on other submissions.
>
>> > Are you going to be expecting others to contribute back to the code
>> > under this license, or will you accept the fact that future
>> > contributions from the community will cause the license to change?
>
>
> You didn't answer this question, which is a very important one before I
> can accept this driver.
FKAN: Yes, all of the above. Our legal is working on that. I thought by def=
ault
GPL defines the above statement.
>
>> >> We will resubmit once this is in place. Please let me know if you hav=
e
>> >> any additional concerns.
>> >
>> > My main concern is that you, and everyone else involved in the driver,
>> > never considered the license of the code in the first place and expect=
ed
>> > the kernel community to accept it as-is, placing the problem on us.
>>
>> FKAN: Please don't think this is the case, we gone through this exercise
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with Denx.
>
> What is "Denx"?
FKAN: U-Boot Denx.de
>
>> We had legal looking into the header before submission
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to them and the kernel.
>
> Then what happened here? =C2=A0Just curious as to how the driver was publ=
ic
> for so long before someone realized this.
>
FKAN: this was few years back. At the time we had the header changed
so it was BSD like to be accepted by Denx.
>> > What will be done in the future to prevent this from happening again?
>>
>> FKAN: agreed, once bitten .... :)
>
> That didn't answer the question :)
FKAN: we have a system of checks for every patch that goes out. I will send
out a guideline to all reviewer to make sure the header
follow kernel precedence.
Legal is quite aware of the issue now too.
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: David Gibson @ 2010-07-30 1:38 UTC (permalink / raw)
To: Grant Likely
Cc: Mitch Bradley, Matthew McClintock, Kumar Gala, linuxppc-dev,
Timur Tabi
In-Reply-To: <AANLkTilDcYYbsH-6f0_HlX9WwaOwG24w1CfhRLplZKS7@mail.gmail.com>
On Thu, Jul 15, 2010 at 01:18:21PM -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@freescale.com> wrote:
> > On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> >> > Yes. Where would we get a list of memreserve sections?
> >>
> >> I would say the list of reserves that are not under the control of
> >> Linux should be explicitly described in the device tree proper. For
> >> instance, if you have a region that firmware depends on, then have a
> >> node for describing the firmware and a property stating the memory
> >> regions that it depends on. The memreserve regions can be generated
> >> from that.
> >
> > Ok, so we could traverse the tree node-by-bode for a
> > persistent-memreserve property and add them to the /memreserve/ list in
> > the kexec user space tools?
Well.. I don't think it should be this way as a matter of spec. But
you could use a property as an interim stash for memreserve
information.
I agree that the precise defined semantics of the memreserve regions
is kind of fuzzy and non-obvious. Here's how I believe they need to
work:
memory in a reserved region must *never* be touched by the OS
(or subsequent kexec-invoked OSes) unless something else in the device
tree explicitly instructs it how
There already exist several mechanisms for instructing the OS to use
particular reserved regions for particular purposes: e.g. the initrd
properties, and the spin-table properties. More such mechanisms might
be added in future ePAPR (or whatever) revisions. But if the OS
version doesn't understand such a future mechanism, it must fall back
to assuming that the memory is reserved in perpetuity.
Now, some of these mechanisms (implicitly) permit the OS to re-use the
reserved memory after it's done using them as instructed (initrd is
the most obvious one). In that case the OS can re-add the reserved
space to it's general pools, and excise it from the reserved space for
subsequent kexec()-style boots. However that's (potentially) a more
complex process than just removing an entry - the initial firmware is
free to combine adjacent reserved regions into one reserve entry, or
even to cover a single reserved region with multiple entries. So in
order to do this manipulation you will need an allocator of sorts that
does the region reservation/dereservation correctly handling the
semantics on a byte-by-byte basis.
You should also be careful that the regions you're handling do
actually lie in memory space. Linux doesn't support this right now,
but I do have an experimental patch that allows the initrd properties
to point to (e.g.) flash instead of RAM. In that case the initrd
wouldn't have to lie in an explicitly reserved region, and obviously
could not be returned to the general pool after use.
> I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
> David Gibson, and other device tree experts on whether or not that
> exact property naming is a good one.
>
> Write up a proposed binding (you can use devicetree.org). Post it for
> review (make sure you cc: both devicetree-discuss and linuxppc-dev, as
> well as cc'ing the people listed above.)
>
> >> > Should we export
> >> > the reserve sections instead of the device tree location?
> >>
> >> It shouldn't really be something that the kernel is explicitly
> >> exporting because it is a characteristic of the board design. It is
> >> something that belongs in the tree-proper. ie. when you extract the
> >> tree you have data telling what the region is, and why it is reserved.
> >
> > Agreed.
> >
> >>
> >> > We just need a
> >> > way to preserve what was there at boot to pass to the new kernel.
> >>
> >> Yet there is no differentiation between the board-dictated memory
> >> reserves and the things that U-Boot/Linux made an arbitrary decision
> >> on. The solution should focus not on "can I throw this one away?" but
> >> rather "Is this one I should keep?" :-) A subtle difference, I know,
> >> but it changes the way you approach the solution.
> >
> > Fair enough. I think the above solution will work nicely, and I can
> > start implementing something if you agree - if I interpreted your idea
> > correctly. Although it should not require any changes to the kernel
> > proper.
>
> Correct.
>
> g.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
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
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 1:26 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTikSH8_QXV2qsBR+vxsjvQwNdx2st3vfbRpfsMff@mail.gmail.com>
On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
> Hi Greg:
>
> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> >> Hi Greg:
> >>
> >> We will change to a BSD 3 clause license header. Our legal counsel is
> >> talking to Synopsis to make this change.
> >
> > Why BSD? You do realize what that means when combined within the body
> > of the kernel, right?
> >
>
> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
> Hil driver.
What specific driver is this?
And are you sure that all of the contributors to the code agree with
this licensing change? Are you going to require contributors to
dual-license their changes?
If so, why keep it BSD, what does that get you?
> > Are you going to be expecting others to contribute back to the code
> > under this license, or will you accept the fact that future
> > contributions from the community will cause the license to change?
You didn't answer this question, which is a very important one before I
can accept this driver.
> >> We will resubmit once this is in place. Please let me know if you have
> >> any additional concerns.
> >
> > My main concern is that you, and everyone else involved in the driver,
> > never considered the license of the code in the first place and expected
> > the kernel community to accept it as-is, placing the problem on us.
>
> FKAN: Please don't think this is the case, we gone through this exercise
> with Denx.
What is "Denx"?
> We had legal looking into the header before submission
> to them and the kernel.
Then what happened here? Just curious as to how the driver was public
for so long before someone realized this.
> > What will be done in the future to prevent this from happening again?
>
> FKAN: agreed, once bitten .... :)
That didn't answer the question :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
From: David Gibson @ 2010-07-30 1:23 UTC (permalink / raw)
To: Matthew McClintock; +Cc: Kumar Gala, linuxppc-dev, Timur Tabi
In-Reply-To: <1279211961.31679.11.camel@localhost>
On Thu, Jul 15, 2010 at 11:39:21AM -0500, Matthew McClintock wrote:
> On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
> > > Thanks for taking a look. My first thought was to just blow away all
> > the
> > > memreserve regions and start over. But, there are reserve regions
> > for
> > > other things that I might not want to blow away. For example, on
> > mpc85xx
> > > SMP systems we have an additional reserve region for our boot page.
> >
> > What is your starting point? Where does the device tree (and
> > memreserve list) come from
> > that you're passing to kexec? My first impression is that if you have
> > to scrub the memreserve list, then the source being used to
> > obtain the memreserves is either faulty or unsuitable to the task.
>
> I'm pulling the device tree passed in via u-boot and passing it to
> kexec. It is the most complete device tree and requires the least amount
> of fixup.
>
> I have to scrub two items, the ramdisk/initrd and the device tree
> because upon kexec'ing the kernel we have the ability to pass in new
> ramdisk/initrd and device tree. They can also live at different
> physical addresses for the second reboot.
> The initrd addresses are already exposed, so we can
> update/remove/reuse that entry, we just need a way for kexec to
> determine the current device tree address so it can replace the
> correct memreserve region for the kexec'ing kernels' device tree.
Ok, be careful with this. You do have the information you need, but
you might have to split an existing entry. Having a single reserve
entry to cover the initrd would be typical, but it doesn't have to
happen that way - e.g. if a firmware reserves a big region for its own
purposes, and places the initrd within that region.
Also, the latest specs do *not* require the device tree itself to be
mem reserved.
> The whole problem comes from repeatedly kexec'ing, we need to make
> sure we don't keep losing blobs of memory to reserve regions (so we
> can't just blindly add). We also need to make sure we don't lose
> other memreserve regions that might be important for other things
> (so we can't just blow them all away).
--
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
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 1:19 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730005045.GB22683@suse.de>
Hi Greg:
On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> We will change to a BSD 3 clause license header. Our legal counsel is
>> talking to Synopsis to make this change.
>
> Why BSD? =C2=A0You do realize what that means when combined within the bo=
dy
> of the kernel, right?
>
FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP
Hil driver.
> Are you going to be expecting others to contribute back to the code
> under this license, or will you accept the fact that future
> contributions from the community will cause the license to change?
>
>> We will resubmit once this is in place. Please let me know if you have
>> any additional concerns.
>
> My main concern is that you, and everyone else involved in the driver,
> never considered the license of the code in the first place and expected
> the kernel community to accept it as-is, placing the problem on us.
FKAN: Please don't think this is the case, we gone through this exercise
with Denx. We had legal looking into the header before submission
to them and the kernel.
>
> What will be done in the future to prevent this from happening again?
FKAN: agreed, once bitten .... :)
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-07-30 0:50 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <AANLkTikDpxcOj=TgD5697HOzPOanECGd4G6QaXZmoS98@mail.gmail.com>
On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We will change to a BSD 3 clause license header. Our legal counsel is
> talking to Synopsis to make this change.
Why BSD? You do realize what that means when combined within the body
of the kernel, right?
Are you going to be expecting others to contribute back to the code
under this license, or will you accept the fact that future
contributions from the community will cause the license to change?
> We will resubmit once this is in place. Please let me know if you have
> any additional concerns.
My main concern is that you, and everyone else involved in the driver,
never considered the license of the code in the first place and expected
the kernel community to accept it as-is, placing the problem on us.
What will be done in the future to prevent this from happening again?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: David Daney @ 2010-07-30 0:42 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, linux-usb, gregkh
In-Reply-To: <12803633233020-git-send-email-fchen@apm.com>
On 07/28/2010 05:28 PM, Fushen Chen wrote:
> [PATCH 1/2 v1.04]
.
.
.
PATCH 1/2 seems to not have made it to linux-usb@vger.kernel.org. I
suspect that a spam filter got it.
Could you remove whatever there is in the patch that triggers the
filter? Or failing that, change the filter so we can all see the patch?
Thanks,
David Daney
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-30 0:41 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <3296.1280448512@neuling.org>
Michael Neuling wrote:
> In message <4C511216.30109@ozlabs.org> you wrote:
>> When CPU hotplug is used, some CPUs may be offline at the time a kexec is
>> performed. The subsequent kernel may expect these CPUs to be already running
> ,
>> and will declare them stuck. On pseries, there's also a soft-offline (cede)
>> state that CPUs may be in; this can also cause problems as the kexeced kernel
>> may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
>>
>> This patch kicks each present offline CPU awake before the kexec, so that
>> none are lost to these assumptions in the subsequent kernel.
>
> There are a lot of cleanups in this patch. The change you are making
> would be a lot clearer without all the additional cleanups in there. I
> think I'd like to see this as two patches. One for cleanups and one for
> the addition of wake_offline_cpus().
Okay, I can split this. Typofixy-add-debug in one, wake_offline_cpus in another.
> Other than that, I'm not completely convinced this is the functionality
> we want. Do we really want to online these cpus? Why where they
> offlined in the first place? I understand the stuck problem, but is the
> solution to online them, or to change the device tree so that the second
> kernel doesn't detect them as stuck?
Well... There are two cases. If a CPU is soft-offlined on pseries, it must be woken from that cede loop (in platforms/pseries/hotplug-cpu.c) as we're replacing code under its feet. We could either special-case the wakeup from this cede loop to get that CPU to RTAS "stop-self" itself properly. (Kind of like a "wake to die".)
So that leaves hard-offline CPUs (perhaps including the above): I don't know why they might have been offlined. If it's something serious, like fire, they'd be removed from the present set too (and thus not be considered in this restarting case). We could add a mask to the CPU node to show which of the threads (if any) are running, and alter the startup code to start everything if this mask doesn't exist (non-kexec) or only online currently-running threads if the mask is present. That feels a little weird.
My reasoning for restarting everything was: The first time you boot, all of your present CPUs are started up. When you reboot, any CPUs you offlined for fun are restarted. Kexec is (in this non-crash sense) a user-initiated 'quick reboot', so I reasoned that it should look the same as a 'hard reboot' and your new invocation would have all available CPUs running as is usual.
Cheers,
Matt
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-07-30 0:14 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100726231616.GA25342@suse.de>
Hi Greg:
We will change to a BSD 3 clause license header. Our legal counsel is
talking to Synopsis to make this change. We will resubmit once this
is in place. Please let me know if you have any additional concerns.
Feng Kan
Applied Micro
On Mon, Jul 26, 2010 at 4:16 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jul 26, 2010 at 04:05:49PM -0700, Feng Kan wrote:
>> Hi Greg:
>>
>> We are having our legal revisit this again. What would you advise us
>> to do at this point?
>
> I thought I was very clear below as to what is needed.
>
>> Disclose the agreement or have someone with legal authority reply this
>> thread.
>
> Neither will resolve the end issue, right?
>
>> Perhaps something in the header that states Applied Micro verified
>> with Synopsys to use this code for GPL purpose.
>
> No, that will just make it messier. =C2=A0Someone needs to delete all of =
the
> mess in the file, put the proper license information for what the code
> is being licensed under (whatever it is), and provide a signed-off-by
> from a person from Synopsys and APM that can speak for the company that
> they agree that the code can properly be placed into the Linux kernel.
>
> thanks,
>
> greg k-h
>
--=20
Feng Kan
^ permalink raw reply
* Re: [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Michael Neuling @ 2010-07-30 0:08 UTC (permalink / raw)
To: Matt Evans; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <4C511216.30109@ozlabs.org>
In message <4C511216.30109@ozlabs.org> you wrote:
> When CPU hotplug is used, some CPUs may be offline at the time a kexec is
> performed. The subsequent kernel may expect these CPUs to be already running
,
> and will declare them stuck. On pseries, there's also a soft-offline (cede)
> state that CPUs may be in; this can also cause problems as the kexeced kernel
> may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
>
> This patch kicks each present offline CPU awake before the kexec, so that
> none are lost to these assumptions in the subsequent kernel.
There are a lot of cleanups in this patch. The change you are making
would be a lot clearer without all the additional cleanups in there. I
think I'd like to see this as two patches. One for cleanups and one for
the addition of wake_offline_cpus().
Other than that, I'm not completely convinced this is the functionality
we want. Do we really want to online these cpus? Why where they
offlined in the first place? I understand the stuck problem, but is the
solution to online them, or to change the device tree so that the second
kernel doesn't detect them as stuck?
Mikey
>
> Signed-off-by: Matt Evans <matt@ozlabs.org>
> ---
> v2: Added FIXME comment noting a possible problem with incorrectly
> started secondary CPUs, following feedback from Milton.
>
> arch/powerpc/kernel/machine_kexec_64.c | 55 ++++++++++++++++++++++++++++--
-
> 1 files changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/mac
hine_kexec_64.c
> index 4fbb3be..37f805e 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -15,6 +15,8 @@
> #include <linux/thread_info.h>
> #include <linux/init_task.h>
> #include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/cpu.h>
>
> #include <asm/page.h>
> #include <asm/current.h>
> @@ -181,7 +183,20 @@ static void kexec_prepare_cpus_wait(int wait_state)
> int my_cpu, i, notified=-1;
>
> my_cpu = get_cpu();
> - /* Make sure each CPU has atleast made it to the state we need */
> + /* Make sure each CPU has at least made it to the state we need.
> + *
> + * FIXME: There is a (slim) chance of a problem if not all of the CPUs
> + * are correctly onlined. If somehow we start a CPU on boot with RTAS
> + * start-cpu, but somehow that CPU doesn't write callin_cpu_map[] in
> + * time, the boot CPU will timeout. If it does eventually execute
> + * stuff, the secondary will start up (paca[].cpu_start was written) an
d
> + * get into a peculiar state. If the platform supports
> + * smp_ops->take_timebase(), the secondary CPU will probably be spinnin
g
> + * in there. If not (i.e. pseries), the secondary will continue on and
> + * try to online itself/idle/etc. If it survives that, we need to find
> + * these possible-but-not-online-but-should-be CPUs and chaperone them
> + * into kexec_smp_wait().
> + */
> for_each_online_cpu(i) {
> if (i == my_cpu)
> continue;
> @@ -189,9 +204,9 @@ static void kexec_prepare_cpus_wait(int wait_state)
> while (paca[i].kexec_state < wait_state) {
> barrier();
> if (i != notified) {
> - printk( "kexec: waiting for cpu %d (physical"
> - " %d) to enter %i state\n",
> - i, paca[i].hw_cpu_id, wait_state);
> + printk(KERN_INFO "kexec: waiting for cpu %d "
> + "(physical %d) to enter %i state\n",
> + i, paca[i].hw_cpu_id, wait_state);
> notified = i;
> }
> }
> @@ -199,9 +214,32 @@ static void kexec_prepare_cpus_wait(int wait_state)
> mb();
> }
>
> -static void kexec_prepare_cpus(void)
> +/*
> + * We need to make sure each present CPU is online. The next kernel will sc
an
> + * the device tree and assume primary threads are online and query secondary
> + * threads via RTAS to online them if required. If we don't online primary
> + * threads, they will be stuck. However, we also online secondary threads a
s we
> + * may be using 'cede offline'. In this case RTAS doesn't see the secondary
> + * threads as offline -- and again, these CPUs will be stuck.
> + *
> + * So, we online all CPUs that should be running, including secondary thread
s.
> + */
> +static void wake_offline_cpus(void)
> {
> + int cpu = 0;
>
> + for_each_present_cpu(cpu) {
> + if (!cpu_online(cpu)) {
> + printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
> + cpu);
> + cpu_up(cpu);
> + }
> + }
> +}
> +
> +static void kexec_prepare_cpus(void)
> +{
> + wake_offline_cpus();
> smp_call_function(kexec_smp_down, NULL, /* wait */0);
> local_irq_disable();
> mb(); /* make sure IRQs are disabled before we say they are */
> @@ -215,7 +253,10 @@ static void kexec_prepare_cpus(void)
> if (ppc_md.kexec_cpu_down)
> ppc_md.kexec_cpu_down(0, 0);
>
> - /* Before removing MMU mapings make sure all CPUs have entered real mod
e */
> + /*
> + * Before removing MMU mappings make sure all CPUs have entered real
> + * mode:
> + */
> kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
>
> put_cpu();
> @@ -284,6 +325,8 @@ void default_machine_kexec(struct kimage *image)
> if (crashing_cpu == -1)
> kexec_prepare_cpus();
>
> + pr_debug("kexec: Starting switchover sequence.\n");
> +
> /* switch to a staticly allocated stack. Based on irq stack code.
> * XXX: the task struct will likely be invalid once we do the copy!
> */
> --
> 1.6.3.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
From: Wolfgang Denk @ 2010-07-29 21:20 UTC (permalink / raw)
To: galak, Kim Phillips; +Cc: linuxppc-dev, Ilya Yanok
In-Reply-To: <4C48B384.1020006@emcraft.com>
Dear Kumar & Kim,
any comments on this issue?
Thanks.
In message <4C48B384.1020006@emcraft.com> Ilya Yanok wrote:
> Hi Kumar, Kim, Josh, everybody,
>
> I hope to disturb you but I haven't got any reply for my first posting...
>
> I've found that MSI work correctly with older kernels on my MPC8308RDB
> board and don't work with newer ones. After bisecting I've found that
> the source of the problem is commit 3da34aa:
>
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>
> Its feasible based on how the PCI address map is setup that the region
> of PCI address space used for MSIs differs for each PHB on the same
> SoC.
>
> Instead of assuming that the address mappes to CCSRBAR 1:1 we read
> PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx
> neigher in the kernel nor in U-Boot (that makes me think that all 83xx
> can be affected).
> I'm not actually an PCI expert so I've just tried to write IMMR base
> address to the BAR0 register from the U-Boot to get the correct address
> but this doesn't help.
> Please direct me how to init 83xx PCIE controller to make it compatible
> with this patch.
>
> Kim, I think MPC8315E is affected too, could you please test it?
>
> Thanks in advance.
>
> Regards, Ilya.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A good aphorism is too hard for the tooth of time, and is not worn
away by all the centuries, although it serves as food for every
epoch. - Friedrich Wilhelm Nietzsche
_Miscellaneous Maxims and Opinions_ no. 168
^ permalink raw reply
* [PATCH] of/address: Clean up function declarations
From: Grant Likely @ 2010-07-29 19:04 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
This patch moves the declaration of of_get_address(), of_get_pci_address(),
and of_pci_address_to_resource() out of arch code and into the common
linux/of_address header file.
This patch also fixes some of the asm/prom.h ordering issues. It still
includes some header files that it ideally shouldn't be, but at least the
ordering is consistent now so that of_* overrides work.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/microblaze/include/asm/prom.h | 33 +++++++-------------
arch/powerpc/include/asm/prom.h | 49 +++++++----------------------
arch/powerpc/kernel/legacy_serial.c | 1 +
arch/powerpc/kernel/pci-common.c | 1 +
arch/powerpc/platforms/52xx/lite5200.c | 1 +
arch/powerpc/platforms/amigaone/setup.c | 3 +-
arch/powerpc/platforms/iseries/mf.c | 1 +
arch/powerpc/platforms/powermac/feature.c | 2 +
drivers/char/bsr.c | 1 +
drivers/net/fsl_pq_mdio.c | 1 +
drivers/net/xilinx_emaclite.c | 2 +
drivers/serial/uartlite.c | 1 +
drivers/spi/mpc512x_psc_spi.c | 1 +
drivers/spi/mpc52xx_psc_spi.c | 1 +
drivers/spi/xilinx_spi_of.c | 1 +
drivers/usb/gadget/fsl_qe_udc.c | 1 +
drivers/video/controlfb.c | 2 +
drivers/video/offb.c | 3 +-
include/linux/of_address.h | 32 +++++++++++++++++++
19 files changed, 74 insertions(+), 63 deletions(-)
diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h
index cb9c3dd..101fa09 100644
--- a/arch/microblaze/include/asm/prom.h
+++ b/arch/microblaze/include/asm/prom.h
@@ -20,11 +20,6 @@
#ifndef __ASSEMBLY__
#include <linux/types.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_fdt.h>
-#include <linux/proc_fs.h>
-#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/atomic.h>
@@ -52,25 +47,9 @@ extern void pci_create_OF_bus_map(void);
* OF address retreival & translation
*/
-/* Extract an address from a device, returns the region size and
- * the address space flags too. The PCI version uses a BAR number
- * instead of an absolute index
- */
-extern const u32 *of_get_address(struct device_node *dev, int index,
- u64 *size, unsigned int *flags);
-extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
- u64 *size, unsigned int *flags);
-
-extern int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r);
-
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
-#else
-static inline unsigned long pci_address_to_pio(phys_addr_t address)
-{
- return (unsigned long)-1;
-}
+#define pci_address_to_pio pci_address_to_pio
#endif /* CONFIG_PCI */
/* Parse the ibm,dma-window property of an OF node into the busno, phys and
@@ -99,8 +78,18 @@ extern const void *of_get_mac_address(struct device_node *np);
* resolving using the OF tree walking.
*/
struct pci_dev;
+struct of_irq;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
+
+/* These includes are put at the bottom because they may contain things
+ * that are overridden by this file. Ideally they shouldn't be included
+ * by this file, but there are a bunch of .c files that currently depend
+ * on it. Eventually they will be cleaned up. */
+#include <linux/of_fdt.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
#endif /* _ASM_MICROBLAZE_PROM_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 55bccc0..ae26f2e 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -17,11 +17,6 @@
* 2 of the License, or (at your option) any later version.
*/
#include <linux/types.h>
-#include <linux/of_fdt.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/proc_fs.h>
-#include <linux/platform_device.h>
#include <asm/irq.h>
#include <asm/atomic.h>
@@ -49,41 +44,9 @@ extern void pci_create_OF_bus_map(void);
extern u64 of_translate_dma_address(struct device_node *dev,
const u32 *in_addr);
-/* Extract an address from a device, returns the region size and
- * the address space flags too. The PCI version uses a BAR number
- * instead of an absolute index
- */
-extern const u32 *of_get_address(struct device_node *dev, int index,
- u64 *size, unsigned int *flags);
-#ifdef CONFIG_PCI
-extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
- u64 *size, unsigned int *flags);
-#else
-static inline const u32 *of_get_pci_address(struct device_node *dev,
- int bar_no, u64 *size, unsigned int *flags)
-{
- return NULL;
-}
-#endif /* CONFIG_PCI */
-
-#ifdef CONFIG_PCI
-extern int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r);
-#else
-static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
- struct resource *r)
-{
- return -ENOSYS;
-}
-#endif /* CONFIG_PCI */
-
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
-#else
-static inline unsigned long pci_address_to_pio(phys_addr_t address)
-{
- return (unsigned long)-1;
-}
+#define pci_address_to_pio pci_address_to_pio
#endif /* CONFIG_PCI */
/* Parse the ibm,dma-window property of an OF node into the busno, phys and
@@ -122,9 +85,19 @@ static inline int of_node_to_nid(struct device_node *device) { return 0; }
* resolving using the OF tree walking.
*/
struct pci_dev;
+struct of_irq;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
extern void of_instantiate_rtc(void);
+/* These includes are put at the bottom because they may contain things
+ * that are overridden by this file. Ideally they shouldn't be included
+ * by this file, but there are a bunch of .c files that currently depend
+ * on it. Eventually they will be cleaned up. */
+#include <linux/of_fdt.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 035ada5..c1fd0f9 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -4,6 +4,7 @@
#include <linux/serial_core.h>
#include <linux/console.h>
#include <linux/pci.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <asm/io.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 5b38f6a..9021c4a 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -21,6 +21,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/of_address.h>
#include <linux/mm.h>
#include <linux/list.h>
#include <linux/syscalls.h>
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 6d584f4..de55bc0 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
#include <asm/time.h>
diff --git a/arch/powerpc/platforms/amigaone/setup.c b/arch/powerpc/platforms/amigaone/setup.c
index fb4eb0d..03aabc0 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -13,12 +13,13 @@
*/
#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/seq_file.h>
#include <generated/utsrelease.h>
#include <asm/machdep.h>
#include <asm/cputable.h>
-#include <asm/prom.h>
#include <asm/pci-bridge.h>
#include <asm/i8259.h>
#include <asm/time.h>
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index d2c1d49..33e5fc7 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -30,6 +30,7 @@
#include <linux/init.h>
#include <linux/completion.h>
#include <linux/delay.h>
+#include <linux/proc_fs.h>
#include <linux/dma-mapping.h>
#include <linux/bcd.h>
#include <linux/rtc.h>
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 9e1b9fd..75eec03 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -21,6 +21,8 @@
#include <linux/delay.h>
#include <linux/kernel.h>
#include <linux/sched.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/spinlock.h>
#include <linux/adb.h>
#include <linux/pmu.h>
diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index 89d871e..9191713 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -23,6 +23,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
+#include <linux/fs.h>
#include <linux/module.h>
#include <linux/cdev.h>
#include <linux/list.h>
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index b4c41d7..f53f850 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -35,6 +35,7 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index d04c5b2..b2c2f39 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -20,7 +20,7 @@
#include <linux/skbuff.h>
#include <linux/io.h>
#include <linux/slab.h>
-
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <linux/of_mdio.h>
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index 8acccd5..caf085d 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -21,6 +21,7 @@
#include <asm/io.h>
#if defined(CONFIG_OF) && (defined(CONFIG_PPC32) || defined(CONFIG_MICROBLAZE))
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
diff --git a/drivers/spi/mpc512x_psc_spi.c b/drivers/spi/mpc512x_psc_spi.c
index 1bb4315..10baac3 100644
--- a/drivers/spi/mpc512x_psc_spi.c
+++ b/drivers/spi/mpc512x_psc_spi.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/interrupt.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index bd81ff9..66d1701 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -16,6 +16,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/interrupt.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/workqueue.h>
#include <linux/completion.h>
diff --git a/drivers/spi/xilinx_spi_of.c b/drivers/spi/xilinx_spi_of.c
index 87cda09..f53d3f6 100644
--- a/drivers/spi/xilinx_spi_of.c
+++ b/drivers/spi/xilinx_spi_of.c
@@ -29,6 +29,7 @@
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/of_device.h>
#include <linux/of_spi.h>
diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
index 82506ca..9648b75 100644
--- a/drivers/usb/gadget/fsl_qe_udc.c
+++ b/drivers/usb/gadget/fsl_qe_udc.c
@@ -32,6 +32,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/moduleparam.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/dma-mapping.h>
#include <linux/usb/ch9.h>
diff --git a/drivers/video/controlfb.c b/drivers/video/controlfb.c
index 49fcbe8..c225dcc 100644
--- a/drivers/video/controlfb.c
+++ b/drivers/video/controlfb.c
@@ -40,6 +40,8 @@
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/pci.h>
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index 46dda7d..cb163a5 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -19,13 +19,14 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/interrupt.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/pci.h>
#include <asm/io.h>
-#include <asm/prom.h>
#ifdef CONFIG_PPC64
#include <asm/pci-bridge.h>
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index cc567df..8aea06f 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -8,5 +8,37 @@ extern int of_address_to_resource(struct device_node *dev, int index,
struct resource *r);
extern void __iomem *of_iomap(struct device_node *device, int index);
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern const u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+
+#ifndef pci_address_to_pio
+static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
+#define pci_address_to_pio pci_address_to_pio
+#endif
+
+#ifdef CONFIG_PCI
+extern const u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
+#else /* CONFIG_PCI */
+static inline int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r)
+{
+ return -ENOSYS;
+}
+
+static inline const u32 *of_get_pci_address(struct device_node *dev,
+ int bar_no, u64 *size, unsigned int *flags)
+{
+ return NULL;
+}
+#endif /* CONFIG_PCI */
+
+
#endif /* __OF_ADDRESS_H */
^ permalink raw reply related
* [PATCH] of: Provide default of_node_to_nid() implementation.
From: Grant Likely @ 2010-07-29 19:04 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
of_node_to_nid() is only relevant in a few architectures. Don't force
everyone to implement it anyway.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
v3: make -1 the default return value and let powerpc override it to 0 when
CONFIG_NUMA not set.
arch/microblaze/include/asm/topology.h | 10 ----------
arch/powerpc/include/asm/prom.h | 7 +++++++
arch/powerpc/include/asm/topology.h | 7 -------
arch/sparc/include/asm/prom.h | 3 +--
include/linux/of.h | 5 +++++
5 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/microblaze/include/asm/topology.h b/arch/microblaze/include/asm/topology.h
index 96bcea5..5428f33 100644
--- a/arch/microblaze/include/asm/topology.h
+++ b/arch/microblaze/include/asm/topology.h
@@ -1,11 +1 @@
#include <asm-generic/topology.h>
-
-#ifndef _ASM_MICROBLAZE_TOPOLOGY_H
-#define _ASM_MICROBLAZE_TOPOLOGY_H
-
-struct device_node;
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-#endif /* _ASM_MICROBLAZE_TOPOLOGY_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index da7dd63..55bccc0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -103,6 +103,13 @@ struct device_node *of_find_next_cache_node(struct device_node *np);
/* Get the MAC address */
extern const void *of_get_mac_address(struct device_node *np);
+#ifdef CONFIG_NUMA
+extern int of_node_to_nid(struct device_node *device);
+#else
+static inline int of_node_to_nid(struct device_node *device) { return 0; }
+#endif
+#define of_node_to_nid of_node_to_nid
+
/**
* of_irq_map_pci - Resolve the interrupt for a PCI device
* @pdev: the device whose interrupt is to be resolved
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 32adf72..09dd38c 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -41,8 +41,6 @@ static inline int cpu_to_node(int cpu)
cpu_all_mask : \
node_to_cpumask_map[node])
-int of_node_to_nid(struct device_node *device);
-
struct pci_bus;
#ifdef CONFIG_PCI
extern int pcibus_to_node(struct pci_bus *bus);
@@ -94,11 +92,6 @@ extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
#else
-static inline int of_node_to_nid(struct device_node *device)
-{
- return 0;
-}
-
static inline void dump_numa_cpu_topology(void) {}
static inline int sysfs_add_device_to_node(struct sys_device *dev, int nid)
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index c82a7da..291f125 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -43,8 +43,7 @@ extern int of_getintprop_default(struct device_node *np,
extern int of_find_in_proplist(const char *list, const char *match, int len);
#ifdef CONFIG_NUMA
extern int of_node_to_nid(struct device_node *dp);
-#else
-#define of_node_to_nid(dp) (-1)
+#define of_node_to_nid of_node_to_nid
#endif
extern void prom_build_devicetree(void);
diff --git a/include/linux/of.h b/include/linux/of.h
index b0756f3..cad7cf0 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -146,6 +146,11 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
#define OF_BAD_ADDR ((u64)-1)
+#ifndef of_node_to_nid
+static inline int of_node_to_nid(struct device_node *np) { return -1; }
+#define of_node_to_nid of_node_to_nid
+#endif
+
extern struct device_node *of_find_node_by_name(struct device_node *from,
const char *name);
#define for_each_node_by_name(dn, name) \
^ permalink raw reply related
* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: Greg KH @ 2010-07-29 17:22 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <AANLkTik35G2Th-1jN3jtx3Mn-rPNNfe3CDQgCdijHG8z@mail.gmail.com>
On Thu, Jul 29, 2010 at 09:26:12AM -0700, Fushen Chen wrote:
> > [PATCH 1/2 v1.04]
> > 1. License information is under clarification.
>
> I meant that APM is still working with Synopys to resolve the GPL License.
> There is no result yet.
Then I would be very careful in posting the code like you have done. As
it is, the code is not something that can be legally posted or used in
any device, and you might be held liable for it :(
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH 4/6] regulator: Remove owner field from attribute initialization in regulator core driver
From: Mark Brown @ 2010-07-29 17:15 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nick Cheng, Jani Nikula, Linus Walleij, James Smart, linuxppc-dev,
Eric W. Biederman, Greg Kroah-Hartman, linux-kernel, Chris Wright,
Tejun Heo, James E.J. Bottomley, Richard Purdie, Alex Iannicelli,
Dmitry Torokhov, Jean Delvare, Paul Mackerras, Benjamin Thery,
linux-scsi, Liam Girdwood
In-Reply-To: <1280380166-29196-5-git-send-email-guenter.roeck@ericsson.com>
On Wed, Jul 28, 2010 at 10:09:24PM -0700, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* Re: [PATCH 0/2 v1.04] Add support for DWC OTG driver.
From: Fushen Chen @ 2010-07-29 16:26 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20100729030559.GA16667@suse.de>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
> [PATCH 1/2 v1.04]
> 1. License information is under clarification.
I meant that APM is still working with Synopys to resolve the GPL License.
There is no result yet.
I'll change this line to "License issue is resolved." if that happens.
I modified other part of the patch according to other reviewer's comment.
Thanks,
Fushen
On Wed, Jul 28, 2010 at 8:05 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Jul 28, 2010 at 05:28:41PM -0700, Fushen Chen wrote:
> > [PATCH 1/2 v1.04]
> > 1. License information is under clarification.
>
> What do you mean by this? I fail to see a change here, why just repost
> the same code again?
>
> What is being done to resolve the issues I outlined previously?
>
> greg k-h
>
[-- Attachment #2: Type: text/html, Size: 1084 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
From: Matthew McClintock @ 2010-07-29 16:03 UTC (permalink / raw)
To: Simon Horman; +Cc: linuxppc-dev, kexec
In-Reply-To: <20100729083324.GC10021@verge.net.au>
On Jul 29, 2010, at 3:33 AM, Simon Horman wrote:
> On Tue, Jul 20, 2010 at 03:14:58PM -0500, Matthew McClintock wrote:
>> This fixes --reuseinitrd and --ramdisk option for ppc32 on
>> uImage-ppc and Elf. It works for normal kexec as well as for
>> kdump.
>>
>> When using --reuseinitrd you need to specifify retain_initrd
>> on the command line. Also, if you are doing kdump you need to make
>> sure your initrd lives in the crashdump region otherwise the
>> kdump kernel will not be able to access it. The --ramdisk option
>> should always work.
>
> Thanks, I have applied this change.
> I had to do a minor merge on the Makefile,
> could you verify that the result is correct?
>
Tested and looks good.
-M
^ permalink raw reply
* [PATCH 6/7] KVM: PPC: Make long relocations be ulong
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
On Book3S KVM we directly expose some asm pointers to C code as
variables. These need to be relocated and thus break on relocatable
kernels.
To make sure we can at least build, let's mark them as long instead
of u32 where 64bit relocations don't work.
This fixes the following build error:
WARNING: 2 bad relocations^M
> c000000000008590 R_PPC64_ADDR32 .text+0x4000000000008460^M
> c000000000008594 R_PPC64_ADDR32 .text+0x4000000000008598^M
Please keep in mind that actually using KVM on a relocated kernel
might still break. This only fixes the compile problem.
Reported-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_book3s.h | 4 ++--
arch/powerpc/kvm/book3s_rmhandlers.S | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 00cf8b0..f04f516 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -132,8 +132,8 @@ extern void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr);
extern int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu);
extern pfn_t kvmppc_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn);
-extern u32 kvmppc_trampoline_lowmem;
-extern u32 kvmppc_trampoline_enter;
+extern ulong kvmppc_trampoline_lowmem;
+extern ulong kvmppc_trampoline_enter;
extern void kvmppc_rmcall(ulong srr0, ulong srr1);
extern void kvmppc_load_up_fpu(void);
extern void kvmppc_load_up_altivec(void);
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index 229d3d6..2b9c908 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -252,10 +252,10 @@ define_load_up(vsx)
.global kvmppc_trampoline_lowmem
kvmppc_trampoline_lowmem:
- .long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
+ PPC_LONG kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START
.global kvmppc_trampoline_enter
kvmppc_trampoline_enter:
- .long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
+ PPC_LONG kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START
#include "book3s_segment.S"
--
1.6.0.2
^ permalink raw reply related
* [PATCH 0/7] Rest of my KVM-PPC patch queue
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
During the past few weeks a couple of fixes have gathered in my queue. This
is a dump of everything that is not related to the PV framework.
Please apply on top of the PV stuff.
Alexander Graf (6):
KVM: PPC: Book3S_32 MMU debug compile fixes
KVM: PPC: RCU'ify the Book3s MMU
KVM: PPC: Add book3s_32 tlbie flush acceleration
KVM: PPC: Use MSR_DR for external load_up
KVM: PPC: Make long relocations be ulong
KVM: PPC: Move KVM trampolines before __end_interrupts
Gleb Natapov (1):
KVM: PPC: correctly check gfn_to_pfn() return value
arch/powerpc/include/asm/kvm_book3s.h | 4 +-
arch/powerpc/include/asm/kvm_host.h | 6 ++
arch/powerpc/kernel/exceptions-64s.S | 6 ++
arch/powerpc/kernel/head_64.S | 6 --
arch/powerpc/kvm/book3s_32_mmu.c | 4 +-
arch/powerpc/kvm/book3s_32_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_mmu_hpte.c | 118 ++++++++++++++++++++++++++-------
arch/powerpc/kvm/book3s_rmhandlers.S | 32 ++++++---
9 files changed, 133 insertions(+), 47 deletions(-)
^ permalink raw reply
* [PATCH 3/7] KVM: PPC: correctly check gfn_to_pfn() return value
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, Gleb Natapov, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
From: Gleb Natapov <gleb@redhat.com>
On failure gfn_to_pfn returns bad_page so use correct function to check
for that.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_32_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 05e8c9e..343452c 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -148,7 +148,7 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
/* Get host physical address for gpa */
hpaddr = kvmppc_gfn_to_pfn(vcpu, orig_pte->raddr >> PAGE_SHIFT);
- if (kvm_is_error_hva(hpaddr)) {
+ if (is_error_pfn(hpaddr)) {
printk(KERN_INFO "Couldn't get guest page for gfn %lx!\n",
orig_pte->eaddr);
return -EINVAL;
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 6cdd19a..672b149 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -102,7 +102,7 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *orig_pte)
/* Get host physical address for gpa */
hpaddr = kvmppc_gfn_to_pfn(vcpu, orig_pte->raddr >> PAGE_SHIFT);
- if (kvm_is_error_hva(hpaddr)) {
+ if (is_error_pfn(hpaddr)) {
printk(KERN_INFO "Couldn't get guest page for gfn %lx!\n", orig_pte->eaddr);
return -EINVAL;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH 5/7] KVM: PPC: Use MSR_DR for external load_up
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
Book3S_32 requires MSR_DR to be disabled during load_up_xxx while on Book3S_64
it's supposed to be enabled. I misread the code and disabled it in both cases,
potentially breaking the PS3 which has a really small RMA.
This patch makes KVM work on the PS3 again.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_rmhandlers.S | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index 506d5c3..229d3d6 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -202,8 +202,25 @@ _GLOBAL(kvmppc_rmcall)
#if defined(CONFIG_PPC_BOOK3S_32)
#define STACK_LR INT_FRAME_SIZE+4
+
+/* load_up_xxx have to run with MSR_DR=0 on Book3S_32 */
+#define MSR_EXT_START \
+ PPC_STL r20, _NIP(r1); \
+ mfmsr r20; \
+ LOAD_REG_IMMEDIATE(r3, MSR_DR|MSR_EE); \
+ andc r3,r20,r3; /* Disable DR,EE */ \
+ mtmsr r3; \
+ sync
+
+#define MSR_EXT_END \
+ mtmsr r20; /* Enable DR,EE */ \
+ sync; \
+ PPC_LL r20, _NIP(r1)
+
#elif defined(CONFIG_PPC_BOOK3S_64)
#define STACK_LR _LINK
+#define MSR_EXT_START
+#define MSR_EXT_END
#endif
/*
@@ -215,19 +232,12 @@ _GLOBAL(kvmppc_load_up_ ## what); \
PPC_STLU r1, -INT_FRAME_SIZE(r1); \
mflr r3; \
PPC_STL r3, STACK_LR(r1); \
- PPC_STL r20, _NIP(r1); \
- mfmsr r20; \
- LOAD_REG_IMMEDIATE(r3, MSR_DR|MSR_EE); \
- andc r3,r20,r3; /* Disable DR,EE */ \
- mtmsr r3; \
- sync; \
+ MSR_EXT_START; \
\
bl FUNC(load_up_ ## what); \
\
- mtmsr r20; /* Enable DR,EE */ \
- sync; \
+ MSR_EXT_END; \
PPC_LL r3, STACK_LR(r1); \
- PPC_LL r20, _NIP(r1); \
mtlr r3; \
addi r1, r1, INT_FRAME_SIZE; \
blr
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/7] KVM: PPC: RCU'ify the Book3s MMU
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
So far we've been running all code without locking of any sort. This wasn't
really an issue because I didn't see any parallel access to the shadow MMU
code coming.
But then I started to implement dirty bitmapping to MOL which has the video
code in its own thread, so suddenly we had the dirty bitmap code run in
parallel to the shadow mmu code. And with that came trouble.
So I went ahead and made the MMU modifying functions as parallelizable as
I could think of. I hope I didn't screw up too much RCU logic :-). If you
know your way around RCU and locking and what needs to be done when, please
take a look at this patch.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_host.h | 2 +
arch/powerpc/kvm/book3s_mmu_hpte.c | 78 ++++++++++++++++++++++++++--------
2 files changed, 61 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index e1da775..fafc71a 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -165,6 +165,7 @@ struct hpte_cache {
struct hlist_node list_pte;
struct hlist_node list_vpte;
struct hlist_node list_vpte_long;
+ struct rcu_head rcu_head;
u64 host_va;
u64 pfn;
ulong slot;
@@ -295,6 +296,7 @@ struct kvm_vcpu_arch {
struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
struct hlist_head hpte_hash_vpte_long[HPTEG_HASH_NUM_VPTE_LONG];
int hpte_cache_count;
+ spinlock_t mmu_lock;
#endif
};
diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c b/arch/powerpc/kvm/book3s_mmu_hpte.c
index 4868d4a..b643893 100644
--- a/arch/powerpc/kvm/book3s_mmu_hpte.c
+++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
@@ -60,68 +60,94 @@ void kvmppc_mmu_hpte_cache_map(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
{
u64 index;
+ spin_lock(&vcpu->arch.mmu_lock);
+
/* Add to ePTE list */
index = kvmppc_mmu_hash_pte(pte->pte.eaddr);
- hlist_add_head(&pte->list_pte, &vcpu->arch.hpte_hash_pte[index]);
+ hlist_add_head_rcu(&pte->list_pte, &vcpu->arch.hpte_hash_pte[index]);
/* Add to vPTE list */
index = kvmppc_mmu_hash_vpte(pte->pte.vpage);
- hlist_add_head(&pte->list_vpte, &vcpu->arch.hpte_hash_vpte[index]);
+ hlist_add_head_rcu(&pte->list_vpte, &vcpu->arch.hpte_hash_vpte[index]);
/* Add to vPTE_long list */
index = kvmppc_mmu_hash_vpte_long(pte->pte.vpage);
- hlist_add_head(&pte->list_vpte_long,
- &vcpu->arch.hpte_hash_vpte_long[index]);
+ hlist_add_head_rcu(&pte->list_vpte_long,
+ &vcpu->arch.hpte_hash_vpte_long[index]);
+
+ spin_unlock(&vcpu->arch.mmu_lock);
+}
+
+static void free_pte_rcu(struct rcu_head *head)
+{
+ struct hpte_cache *pte = container_of(head, struct hpte_cache, rcu_head);
+ kmem_cache_free(hpte_cache, pte);
}
static void invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
{
+ /* pte already invalidated? */
+ if (hlist_unhashed(&pte->list_pte))
+ return;
+
dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
pte->pte.eaddr, pte->pte.vpage, pte->host_va);
/* Different for 32 and 64 bit */
kvmppc_mmu_invalidate_pte(vcpu, pte);
+ spin_lock(&vcpu->arch.mmu_lock);
+
+ hlist_del_init_rcu(&pte->list_pte);
+ hlist_del_init_rcu(&pte->list_vpte);
+ hlist_del_init_rcu(&pte->list_vpte_long);
+
+ spin_unlock(&vcpu->arch.mmu_lock);
+
if (pte->pte.may_write)
kvm_release_pfn_dirty(pte->pfn);
else
kvm_release_pfn_clean(pte->pfn);
- hlist_del(&pte->list_pte);
- hlist_del(&pte->list_vpte);
- hlist_del(&pte->list_vpte_long);
-
vcpu->arch.hpte_cache_count--;
- kmem_cache_free(hpte_cache, pte);
+ call_rcu(&pte->rcu_head, free_pte_rcu);
}
static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
{
struct hpte_cache *pte;
- struct hlist_node *node, *tmp;
+ struct hlist_node *node;
int i;
+ rcu_read_lock();
+
for (i = 0; i < HPTEG_HASH_NUM_VPTE_LONG; i++) {
struct hlist_head *list = &vcpu->arch.hpte_hash_vpte_long[i];
- hlist_for_each_entry_safe(pte, node, tmp, list, list_vpte_long)
+ hlist_for_each_entry_rcu(pte, node, list, list_vpte_long)
invalidate_pte(vcpu, pte);
}
+
+ rcu_read_unlock();
}
static void kvmppc_mmu_pte_flush_page(struct kvm_vcpu *vcpu, ulong guest_ea)
{
struct hlist_head *list;
- struct hlist_node *node, *tmp;
+ struct hlist_node *node;
struct hpte_cache *pte;
/* Find the list of entries in the map */
list = &vcpu->arch.hpte_hash_pte[kvmppc_mmu_hash_pte(guest_ea)];
+ rcu_read_lock();
+
/* Check the list for matching entries and invalidate */
- hlist_for_each_entry_safe(pte, node, tmp, list, list_pte)
+ hlist_for_each_entry_rcu(pte, node, list, list_pte)
if ((pte->pte.eaddr & ~0xfffUL) == guest_ea)
invalidate_pte(vcpu, pte);
+
+ rcu_read_unlock();
}
void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
@@ -156,33 +182,41 @@ void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
static void kvmppc_mmu_pte_vflush_short(struct kvm_vcpu *vcpu, u64 guest_vp)
{
struct hlist_head *list;
- struct hlist_node *node, *tmp;
+ struct hlist_node *node;
struct hpte_cache *pte;
u64 vp_mask = 0xfffffffffULL;
list = &vcpu->arch.hpte_hash_vpte[kvmppc_mmu_hash_vpte(guest_vp)];
+ rcu_read_lock();
+
/* Check the list for matching entries and invalidate */
- hlist_for_each_entry_safe(pte, node, tmp, list, list_vpte)
+ hlist_for_each_entry_rcu(pte, node, list, list_vpte)
if ((pte->pte.vpage & vp_mask) == guest_vp)
invalidate_pte(vcpu, pte);
+
+ rcu_read_unlock();
}
/* Flush with mask 0xffffff000 */
static void kvmppc_mmu_pte_vflush_long(struct kvm_vcpu *vcpu, u64 guest_vp)
{
struct hlist_head *list;
- struct hlist_node *node, *tmp;
+ struct hlist_node *node;
struct hpte_cache *pte;
u64 vp_mask = 0xffffff000ULL;
list = &vcpu->arch.hpte_hash_vpte_long[
kvmppc_mmu_hash_vpte_long(guest_vp)];
+ rcu_read_lock();
+
/* Check the list for matching entries and invalidate */
- hlist_for_each_entry_safe(pte, node, tmp, list, list_vpte_long)
+ hlist_for_each_entry_rcu(pte, node, list, list_vpte_long)
if ((pte->pte.vpage & vp_mask) == guest_vp)
invalidate_pte(vcpu, pte);
+
+ rcu_read_unlock();
}
void kvmppc_mmu_pte_vflush(struct kvm_vcpu *vcpu, u64 guest_vp, u64 vp_mask)
@@ -206,21 +240,25 @@ void kvmppc_mmu_pte_vflush(struct kvm_vcpu *vcpu, u64 guest_vp, u64 vp_mask)
void kvmppc_mmu_pte_pflush(struct kvm_vcpu *vcpu, ulong pa_start, ulong pa_end)
{
- struct hlist_node *node, *tmp;
+ struct hlist_node *node;
struct hpte_cache *pte;
int i;
dprintk_mmu("KVM: Flushing %d Shadow pPTEs: 0x%lx - 0x%lx\n",
vcpu->arch.hpte_cache_count, pa_start, pa_end);
+ rcu_read_lock();
+
for (i = 0; i < HPTEG_HASH_NUM_VPTE_LONG; i++) {
struct hlist_head *list = &vcpu->arch.hpte_hash_vpte_long[i];
- hlist_for_each_entry_safe(pte, node, tmp, list, list_vpte_long)
+ hlist_for_each_entry_rcu(pte, node, list, list_vpte_long)
if ((pte->pte.raddr >= pa_start) &&
(pte->pte.raddr < pa_end))
invalidate_pte(vcpu, pte);
}
+
+ rcu_read_unlock();
}
struct hpte_cache *kvmppc_mmu_hpte_cache_next(struct kvm_vcpu *vcpu)
@@ -259,6 +297,8 @@ int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_vpte_long,
ARRAY_SIZE(vcpu->arch.hpte_hash_vpte_long));
+ spin_lock_init(&vcpu->arch.mmu_lock);
+
return 0;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/7] KVM: PPC: Add book3s_32 tlbie flush acceleration
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
On Book3s_32 the tlbie instruction flushed effective addresses by the mask
0x0ffff000. This is pretty hard to reflect with a hash that hashes ~0xfff, so
to speed up that target we should also keep a special hash around for it.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_host.h | 4 +++
arch/powerpc/kvm/book3s_mmu_hpte.c | 40 ++++++++++++++++++++++++++++++----
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index fafc71a..bba3b9b 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -42,9 +42,11 @@
#define HPTEG_CACHE_NUM (1 << 15)
#define HPTEG_HASH_BITS_PTE 13
+#define HPTEG_HASH_BITS_PTE_LONG 12
#define HPTEG_HASH_BITS_VPTE 13
#define HPTEG_HASH_BITS_VPTE_LONG 5
#define HPTEG_HASH_NUM_PTE (1 << HPTEG_HASH_BITS_PTE)
+#define HPTEG_HASH_NUM_PTE_LONG (1 << HPTEG_HASH_BITS_PTE_LONG)
#define HPTEG_HASH_NUM_VPTE (1 << HPTEG_HASH_BITS_VPTE)
#define HPTEG_HASH_NUM_VPTE_LONG (1 << HPTEG_HASH_BITS_VPTE_LONG)
@@ -163,6 +165,7 @@ struct kvmppc_mmu {
struct hpte_cache {
struct hlist_node list_pte;
+ struct hlist_node list_pte_long;
struct hlist_node list_vpte;
struct hlist_node list_vpte_long;
struct rcu_head rcu_head;
@@ -293,6 +296,7 @@ struct kvm_vcpu_arch {
#ifdef CONFIG_PPC_BOOK3S
struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
+ struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];
struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
struct hlist_head hpte_hash_vpte_long[HPTEG_HASH_NUM_VPTE_LONG];
int hpte_cache_count;
diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c b/arch/powerpc/kvm/book3s_mmu_hpte.c
index b643893..02c64ab 100644
--- a/arch/powerpc/kvm/book3s_mmu_hpte.c
+++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
@@ -45,6 +45,12 @@ static inline u64 kvmppc_mmu_hash_pte(u64 eaddr)
return hash_64(eaddr >> PTE_SIZE, HPTEG_HASH_BITS_PTE);
}
+static inline u64 kvmppc_mmu_hash_pte_long(u64 eaddr)
+{
+ return hash_64((eaddr & 0x0ffff000) >> PTE_SIZE,
+ HPTEG_HASH_BITS_PTE_LONG);
+}
+
static inline u64 kvmppc_mmu_hash_vpte(u64 vpage)
{
return hash_64(vpage & 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
@@ -66,6 +72,11 @@ void kvmppc_mmu_hpte_cache_map(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
index = kvmppc_mmu_hash_pte(pte->pte.eaddr);
hlist_add_head_rcu(&pte->list_pte, &vcpu->arch.hpte_hash_pte[index]);
+ /* Add to ePTE_long list */
+ index = kvmppc_mmu_hash_pte_long(pte->pte.eaddr);
+ hlist_add_head_rcu(&pte->list_pte_long,
+ &vcpu->arch.hpte_hash_pte_long[index]);
+
/* Add to vPTE list */
index = kvmppc_mmu_hash_vpte(pte->pte.vpage);
hlist_add_head_rcu(&pte->list_vpte, &vcpu->arch.hpte_hash_vpte[index]);
@@ -99,6 +110,7 @@ static void invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
spin_lock(&vcpu->arch.mmu_lock);
hlist_del_init_rcu(&pte->list_pte);
+ hlist_del_init_rcu(&pte->list_pte_long);
hlist_del_init_rcu(&pte->list_vpte);
hlist_del_init_rcu(&pte->list_vpte_long);
@@ -150,10 +162,28 @@ static void kvmppc_mmu_pte_flush_page(struct kvm_vcpu *vcpu, ulong guest_ea)
rcu_read_unlock();
}
-void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
+static void kvmppc_mmu_pte_flush_long(struct kvm_vcpu *vcpu, ulong guest_ea)
{
- u64 i;
+ struct hlist_head *list;
+ struct hlist_node *node;
+ struct hpte_cache *pte;
+
+ /* Find the list of entries in the map */
+ list = &vcpu->arch.hpte_hash_pte_long[
+ kvmppc_mmu_hash_pte_long(guest_ea)];
+ rcu_read_lock();
+
+ /* Check the list for matching entries and invalidate */
+ hlist_for_each_entry_rcu(pte, node, list, list_pte_long)
+ if ((pte->pte.eaddr & 0x0ffff000UL) == guest_ea)
+ invalidate_pte(vcpu, pte);
+
+ rcu_read_unlock();
+}
+
+void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
+{
dprintk_mmu("KVM: Flushing %d Shadow PTEs: 0x%lx & 0x%lx\n",
vcpu->arch.hpte_cache_count, guest_ea, ea_mask);
@@ -164,9 +194,7 @@ void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
kvmppc_mmu_pte_flush_page(vcpu, guest_ea);
break;
case 0x0ffff000:
- /* 32-bit flush w/o segment, go through all possible segments */
- for (i = 0; i < 0x100000000ULL; i += 0x10000000ULL)
- kvmppc_mmu_pte_flush(vcpu, guest_ea | i, ~0xfffUL);
+ kvmppc_mmu_pte_flush_long(vcpu, guest_ea);
break;
case 0:
/* Doing a complete flush -> start from scratch */
@@ -292,6 +320,8 @@ int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
/* init hpte lookup hashes */
kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_pte,
ARRAY_SIZE(vcpu->arch.hpte_hash_pte));
+ kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_pte_long,
+ ARRAY_SIZE(vcpu->arch.hpte_hash_pte_long));
kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_vpte,
ARRAY_SIZE(vcpu->arch.hpte_hash_vpte));
kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_vpte_long,
--
1.6.0.2
^ permalink raw reply related
* [PATCH 7/7] KVM: PPC: Move KVM trampolines before __end_interrupts
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
When using a relocatable kernel we need to make sure that the trampline code
and the interrupt handlers are both copied to low memory. The only way to do
this reliably is to put them in the copied section.
This patch should make relocated kernels work with KVM.
KVM-Stable-Tag
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kernel/exceptions-64s.S | 6 ++++++
arch/powerpc/kernel/head_64.S | 6 ------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 3e423fb..a0f25fb 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -299,6 +299,12 @@ slb_miss_user_pseries:
b . /* prevent spec. execution */
#endif /* __DISABLED__ */
+/* KVM's trampoline code needs to be close to the interrupt handlers */
+
+#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
+#include "../kvm/book3s_rmhandlers.S"
+#endif
+
.align 7
.globl __end_interrupts
__end_interrupts:
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 844a44b..d3010a3 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -166,12 +166,6 @@ exception_marker:
#include "exceptions-64s.S"
#endif
-/* KVM trampoline code needs to be close to the interrupt handlers */
-
-#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
-#include "../kvm/book3s_rmhandlers.S"
-#endif
-
_GLOBAL(generic_secondary_thread_init)
mr r24,r3
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/7] KVM: PPC: Book3S_32 MMU debug compile fixes
From: Alexander Graf @ 2010-07-29 13:04 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280408662-10328-1-git-send-email-agraf@suse.de>
Due to previous changes, the Book3S_32 guest MMU code didn't compile properly
when enabling debugging.
This patch repairs the broken code paths, making it possible to define DEBUG_MMU
and friends again.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_32_mmu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_32_mmu.c b/arch/powerpc/kvm/book3s_32_mmu.c
index a7d121a..5bf4bf8 100644
--- a/arch/powerpc/kvm/book3s_32_mmu.c
+++ b/arch/powerpc/kvm/book3s_32_mmu.c
@@ -104,7 +104,7 @@ static hva_t kvmppc_mmu_book3s_32_get_pteg(struct kvmppc_vcpu_book3s *vcpu_book3
pteg = (vcpu_book3s->sdr1 & 0xffff0000) | hash;
dprintk("MMU: pc=0x%lx eaddr=0x%lx sdr1=0x%llx pteg=0x%x vsid=0x%x\n",
- vcpu_book3s->vcpu.arch.pc, eaddr, vcpu_book3s->sdr1, pteg,
+ kvmppc_get_pc(&vcpu_book3s->vcpu), eaddr, vcpu_book3s->sdr1, pteg,
sre->vsid);
r = gfn_to_hva(vcpu_book3s->vcpu.kvm, pteg >> PAGE_SHIFT);
@@ -269,7 +269,7 @@ no_page_found:
dprintk_pte("KVM MMU: No PTE found (sdr1=0x%llx ptegp=0x%lx)\n",
to_book3s(vcpu)->sdr1, ptegp);
for (i=0; i<16; i+=2) {
- dprintk_pte(" %02d: 0x%x - 0x%x (0x%llx)\n",
+ dprintk_pte(" %02d: 0x%x - 0x%x (0x%x)\n",
i, pteg[i], pteg[i+1], ptem);
}
}
--
1.6.0.2
^ 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