* Re: [RFC/PATCH 2/4] powerpc: ptrace can set DABR on both 32 and 64 bits
From: Benjamin Herrenschmidt @ 2007-05-30 12:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <AB7DD12D-76D5-43D8-90BF-904C7C85205E@kernel.crashing.org>
On Wed, 2007-05-30 at 07:44 -0500, Kumar Gala wrote:
> On May 30, 2007, at 3:05 AM, Benjamin Herrenschmidt wrote:
>
> > Allow ptrace to set dabr in the thread structure for both 32 and 64
> > bits,
> > though only 64 bits actually uses that field, it's actually defined
> > in both.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Can you make these -EIO for CONFIG_BOOKE for now.
I suppose best is to define set_dabr to have a result code...
The std DABR format is good enough to carry a generic setting whatever
the HW implementation is I think.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Felix Domke @ 2007-05-30 11:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1180524227.19517.256.camel@localhost.localdomain>
>> Anyway, please don't. It is *not* portable.
> What are you talking about ? Really, I mean, I'm not sure I understand
> what you mean :-)
Segher stated that there is no portable way of detecting whether 64bit
instructions are available, and said that just trying a 64bit insn (and
catching the SIGILL if thre cpu is 32bit) is probably the most portable
way to do so. (Or did i got *that* wrong? If so, please ignore.)
Now my objection is that the "SIGILL"-way is not only ugly, but can be
easily *wrong*, as there are certain possibilities (Book-E 64bit,
non-64bit-aware OS, ...) when the CPU might not throw an exception. (My
"ffmpeg with vmx"-experience shows this is a real world issue, although
the situation is a bit different there, i agree, since vmx opcodes are
not exclusively reserved for vmx)
Yes, those hwcap-bits should care for this. Are they portable/usable,
even on older systems?
Felix
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Hiroyuki Machida @ 2007-05-30 12:48 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <91D21C34-3D3C-4A1F-9B2E-08F336B7EFC4@kernel.crashing.org>
2007/5/30, Kumar Gala <galak@kernel.crashing.org>:
>
> On May 30, 2007, at 6:44 AM, Benjamin Herrenschmidt wrote:
>
> > On Wed, 2007-05-30 at 00:32 -0500, Kumar Gala wrote:
> >>> I think actually it would be useful to have the saving/restoring of
> >>> the high 32 bits controlled by a prctl, so that programs have to ask
> >>> explicitly for the new behaviour (and programs that don't want to
> >> use
> >>> the high 32 bits don't incur the extra overhead).
> >>
> >> I like this, it means we can error if HW doesn't support it and
> >> requires applications to do something specific to enable the feature.
> >
> > Yeah well.... I liked the prctl at first.. but then, I though
> > twice :-)
> >
> > Thing is, a typical usage pattern would be some library having a hand
> > optimized tigh loop or something like that using 64 bits registers. An
> > example, would be some memcpy-type thing in glibc.
> >
> > You don't want those things to do prctl's all over the place on behalf
> > of the host application.
>
> Yeah, I can see that being a pain. However, how would the AT_HWCAP
> make this any easier on the library to detect? (I might have missed
> that discussion of that magic in the thread).
>
I think same framework as proposed at follwoing URLs, works.
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
http://sources.redhat.com/ml/libc-alpha/2006-01/msg00094.html
Hiroyuki..
^ permalink raw reply
* Re: [RFC/PATCH 2/4] powerpc: ptrace can set DABR on both 32 and 64 bits
From: Kumar Gala @ 2007-05-30 12:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070530080526.36115DDFC8@ozlabs.org>
On May 30, 2007, at 3:05 AM, Benjamin Herrenschmidt wrote:
> Allow ptrace to set dabr in the thread structure for both 32 and 64
> bits,
> though only 64 bits actually uses that field, it's actually defined
> in both.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Can you make these -EIO for CONFIG_BOOKE for now.
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 12:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180526992.19517.277.camel@localhost.localdomain>
>>> Actually, it's the opposite... the prctl becomes a problem if you
>> have
>>> libs wanting to use 64 bits for optims
>>
>> The host application, or the dynamic loader, can call
>> the prctl() when it loads the DSO that needs it.
>
> Provided you know it does... and with static binaries it gets harder...
A mechanism like what is done for executable stacks
can be used, so you end up with something in the ELF
headers that tells you. Not that I like this particular
mechanism.
>> In almost all cases this should all be transparent
>> for the user IMHO, based on some ELF flag.
>
> You reckon ? I was wondering about that ... maybe we should define some
> ELF personality for that ...
>
> But that means that existing programs wouldn't get it even while some
> libs they depend on might have such optims without the program knowing
> about it ...
Like I said, the dynamic loader should do the work
in such cases.
> Also, if I can avoid changing glibc ... (you know how hard it is !)
No really? Tell me about it? :-)
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 12:30 UTC (permalink / raw)
To: Becky Bruce
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <77D9DB04-FAD3-48EF-9159-5EA92BB366E5@freescale.com>
>> If what you're
>> saying is true in the 2.03 POWER ISA, even for server
>> class implementations, that would be very unfortunate.
>
> I believe Category:Server implementations are required to behave as
> you expect. Category:Embedded implementations may have different
> behavior. Like it or not, BookE *is* part of the Power architecture,
> and there are going to be 64-bit implementations of BookE that we need
> to take into account.
Sure. How about we worry about this when support for
such CPUs is added _at all_ to Linux; for this issue,
the only required change would be to refuse the prctl()
call, right?
>> If you mean Book I 1.5.2, that is for embedded class
>> (i.e., BookE) CPUs only.
>
> I think that's exactly what Kumar's talking about. The assumption that
> all 64-bit Power processors will use those upper bits in some
> meaningful way is not valid. Also, ld and std do not architecturally
> "just work" on BookE implementations running in 32b mode. Those
> instructions are part of the 64-bit category in 2.03, and may illop on
> BookE processors running in 32b mode.
Sounds like it will be a lovely effort to add support for
such CPUs to Linux.
Segher
^ permalink raw reply
* Re: [PATCH v2]: Fix e500 v2 core reboot bug
From: Kumar Gala @ 2007-05-30 12:25 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1180503967.12577.20.camel@localhost.localdomain>
On May 30, 2007, at 12:46 AM, Zang Roy-r61911 wrote:
> On Wed, 2007-05-30 at 10:40, Kumar Gala wrote:
>> On May 29, 2007, at 9:34 PM, Zang Roy-r61911 wrote:
>>
>>> On Wed, 2007-05-30 at 03:29, Kumar Gala wrote:
>>>> On May 28, 2007, at 9:36 PM, Zang Roy-r61911 wrote:
>>>>
>>>>> Fix the e500 v2 core reset bug.
>>>>> For e500 v2 core, a new reset control register is added to
>>>>> reset the core.
>>>>> On 85xx CDS board with e500 v2 core, normal reboot code will
>>>>> induce DDR block in u-boot. This patch fixes this bug. It is
>>>>> also tested on legacy e500 v1 core.
>>>>
>>>> what happens on an e500 based 85xx system?
>>>
>>> Without this patch on MPC8548CDS board, after key in "reboot"
>> command,
>>> the u-boot will hang at DDR init. See the following log without this
>>> patch:
>>
>> Sorry I meant what happens on a e500 v1 based 85xx system w/this
>> patch.
>
> E500 V1 core can boot up normally with/without this patch. Such as
> 8555CDS system.
Sure, but what happens when you reboot on e500v1 based part?
[snip]
>>>> I'm not terrible happy with blindly writing to rstcr.
>>>>
>>> I can understand you.
>>> But I jut want to make things simple and workable.
>>> Any idea?
>>
>> one idea would be for us to add a property on the soc node.
>> Something like has-rstcr or something similar in a guts node?
> I have seen your suggestion before to add a property in device tree.
> But I still think the current implementation is simple.
While it simple you are depending on the fact that a given
implementation may or may not have something at the particular
offset. Who knows if 8599 or some future part could put the 'cause
my part to smoke and self-destruct' at the same offset in the future :)
> Anyway, I can try your suggestion.
I'm thinking have a guts block and putting a property in it makes the
most sense.
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Kumar Gala @ 2007-05-30 12:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras, Steve Munroe,
Anton Blanchard
In-Reply-To: <1180525484.19517.266.camel@localhost.localdomain>
On May 30, 2007, at 6:44 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2007-05-30 at 00:32 -0500, Kumar Gala wrote:
>>> I think actually it would be useful to have the saving/restoring of
>>> the high 32 bits controlled by a prctl, so that programs have to ask
>>> explicitly for the new behaviour (and programs that don't want to
>> use
>>> the high 32 bits don't incur the extra overhead).
>>
>> I like this, it means we can error if HW doesn't support it and
>> requires applications to do something specific to enable the feature.
>
> Yeah well.... I liked the prctl at first.. but then, I though
> twice :-)
>
> Thing is, a typical usage pattern would be some library having a hand
> optimized tigh loop or something like that using 64 bits registers. An
> example, would be some memcpy-type thing in glibc.
>
> You don't want those things to do prctl's all over the place on behalf
> of the host application.
Yeah, I can see that being a pain. However, how would the AT_HWCAP
make this any easier on the library to detect? (I might have missed
that discussion of that magic in the thread).
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Kumar Gala @ 2007-05-30 12:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <20070530100438.GB24586@lst.de>
On May 30, 2007, at 5:04 AM, Christoph Hellwig wrote:
> On Tue, May 29, 2007 at 02:04:02PM -0500, Becky Bruce wrote:
>> I think that's exactly what Kumar's talking about. The assumption
>> that all 64-bit Power processors will use those upper bits in some
>> meaningful way is not valid. Also, ld and std do not architecturally
>> "just work" on BookE implementations running in 32b mode. Those
>> instructions are part of the 64-bit category in 2.03, and may illop
>> on BookE processors running in 32b mode.
>
> Then Bens suggest mode will only work on the sane IBM processors and
> not the braindead freescale ones. Wouldn't be the first time.
This isn't sane vs braindead. Its one thing if this was some quirk
of an implementation, but we are talking about what the architecture
does and doesn't allow. There a reasonable reason that a processor
for the embedded processor would be able to save power in 32-bit mode
by not powering the upper bits of the register file.
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 12:09 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <fa74d8c78910a77c011f9e72dd750d19@kernel.crashing.org>
On Wed, 2007-05-30 at 14:07 +0200, Segher Boessenkool wrote:
> > Actually, it's the opposite... the prctl becomes a problem if you
> have
> > libs wanting to use 64 bits for optims
>
> The host application, or the dynamic loader, can call
> the prctl() when it loads the DSO that needs it.
Provided you know it does... and with static binaries it gets harder...
> In almost all cases this should all be transparent
> for the user IMHO, based on some ELF flag.
You reckon ? I was wondering about that ... maybe we should define some
ELF personality for that ...
But that means that existing programs wouldn't get it even while some
libs they depend on might have such optims without the program knowing
about it ...
Also, if I can avoid changing glibc ... (you know how hard it is !)
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Felix Domke @ 2007-05-30 12:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <6468abfee21ce75c5d86676350b09c88@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> Just call them and trap the SEGV ;-) You can check the
>>>> aux vector of course, or ask glibc -- but the SEGV way
>>>> is the only really portable way. Strange world :-)
>>> SIGILL you mean ? :-)
>> Anyway, please don't. It is *not* portable.
> It is simple and *quite* portable. [...]
>> [ffmpeg]
> To be fair, ffmpeg has had this test since before there
> were proper ways to detect AltiVec on Linux/glibc.
That's *exactly* my point:
If you don't provide a real, portable, useful way *now* for detecting
compatibility with 64bit insn, people (=ffmpeg, mplayer first) *will*
invent their own way of detecting it, possibly using SIGILL, faster than
you could imagine.
Please avoid that this time. And please declare the use of SIGILL for
detecting extensions as plainly wrong, not as a "bad workaround, but
still better than what's available". If you can't be sure that an
extension will work as expected (for example because there is just no
interface to query the OS for it), then simply don't use it. If this is
going to be a performance problem, bug the kernel people to fix it.
(Sorry, this is the point of view of myself a pure *user*. I don't want
to debug crashing programs with incorrect memcpy results because some
program decided on its own that it's safe to use this extension when it
wasn't.)
>> And: What will happen if you manage to run your code under an operating
>> system which doesn't even save the upper bits at all on interrupts? You
>> can't check for that with SIGILL.
> Sure you can, do some loop with a data-dependent branch
> in there that detects corruption of that high half reg.
> If you really want a SIGILL you can just generate one ;-)
> A test like this is never 100% of course.
Tell that those people who have a SIGILL check in their "production" code.
Felix
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 12:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180526470.19517.274.camel@localhost.localdomain>
>> This prctl() is needed if you want to support DSOs containing
>> 64-bit insns. It would be nice to have some ELF flag as well
>> though, so most of this can be handled automatically.
>
> Actually, it's the opposite... the prctl becomes a problem if you have
> libs wanting to use 64 bits for optims
The host application, or the dynamic loader, can call
the prctl() when it loads the DSO that needs it.
In almost all cases this should all be transparent
for the user IMHO, based on some ELF flag.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 12:01 UTC (permalink / raw)
To: Kumar Gala
Cc: Ulrich Weigand, Paul Mackerras, Steve Munroe, Anton Blanchard,
linuxppc-dev list
In-Reply-To: <ADB2DAF4-B25F-462D-B552-531D706F57BE@kernel.crashing.org>
>> I think actually it would be useful to have the saving/restoring of
>> the high 32 bits controlled by a prctl, so that programs have to ask
>> explicitly for the new behaviour (and programs that don't want to use
>> the high 32 bits don't incur the extra overhead).
>
> I like this, it means we can error if HW doesn't support it and
> requires applications to do something specific to enable the feature.
It also means every such application has to make sure
it calls the prctl() before running any 64-bit insns.
No one will get this right unless support for this
is put into the ELF loader.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 12:01 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <ce91696e7837282dd93df408461a64fb@kernel.crashing.org>
On Wed, 2007-05-30 at 13:59 +0200, Segher Boessenkool wrote:
> This prctl() is needed if you want to support DSOs containing
> 64-bit insns. It would be nice to have some ELF flag as well
> though, so most of this can be handled automatically.
Actually, it's the opposite... the prctl becomes a problem if you have
libs wanting to use 64 bits for optims
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 11:59 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Anton Blanchard
In-Reply-To: <18012.61822.197988.279764@cargo.ozlabs.ibm.com>
> I think actually it would be useful to have the saving/restoring of
> the high 32 bits controlled by a prctl, so that programs have to ask
> explicitly for the new behaviour (and programs that don't want to use
> the high 32 bits don't incur the extra overhead).
This prctl() is needed if you want to support DSOs containing
64-bit insns. It would be nice to have some ELF flag as well
though, so most of this can be handled automatically.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 11:54 UTC (permalink / raw)
To: Felix Domke; +Cc: linuxppc-dev list
In-Reply-To: <465C9F04.4070202@elitedvb.net>
>>> Just call them and trap the SEGV ;-) You can check the
>>> aux vector of course, or ask glibc -- but the SEGV way
>>> is the only really portable way. Strange world :-)
>> SIGILL you mean ? :-)
> Anyway, please don't. It is *not* portable.
It is simple and *quite* portable. "Real" applications
of course should just ask the C library about this,
somewhere deep inside a maze of #ifdefs for all the OSes
supported. A job for autoxxxx I guess.
> Or can you guarantee that no CPU ever will implement a.) only a 64bit
> subset or b.) other instructions using the same encoding as the 64bit
> insn you will use for testing?
I don't understand a); and no CPU _should_ do b), but we
all know that bad things happen sometimes.
> I still remember the pain of trying to tell that ffmpeg that my CPU
> can't do real altivec, even when it implements some parts of it without
> SIGILLing (which ffmpeg used for testing).
To be fair, ffmpeg has had this test since before there
were proper ways to detect AltiVec on Linux/glibc.
> And: What will happen if you manage to run your code under an operating
> system which doesn't even save the upper bits at all on interrupts? You
> can't check for that with SIGILL.
Sure you can, do some loop with a data-dependent branch
in there that detects corruption of that high half reg.
If you really want a SIGILL you can just generate one ;-)
A test like this is never 100% of course.
> And i'd still like to see some decent ILP32LL64 support.
GCC has supported this for a long time now, it seems the
last few pieces needed from the kernel and userland support
are falling into place now. Hurray!
> Maybe even with
> a new "native 64bit" datatype (how ugly), in order to not break the
> ABI.
> I just want to call my hand-optimized 64bit assembler code with 64bit
> arguments.
> How does OS X handle this? Don't they have the same problem there?
AFAIK Darwin saves full 64-bit GPRs on a 64-bit CPU always.
An application can ask for 64-bit signal frames by giving
the SA_64REGSET flag in sa_flags to sigaction().
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 11:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <3cbbec8c34b1beabb091c343132730d5@kernel.crashing.org>
On Wed, 2007-05-30 at 13:40 +0200, Segher Boessenkool wrote:
>
> > I personally don't care about gdb seeing those or anything like
> that,
> > those would be strictly local asm optimisations, at least that's my
> > point of view on the matter.
>
> GDB can step into asm though, it will have to know
> about it for full functionality.
It can already... there are ptrace hooks to get both halves if you are a
32 bits gdb and the 64 bits ptrace will return the full 64 bits. There
is no way to know wether an app or a lib is using both halves or not
though.
> Perhaps something in a test suite somewhere; other
> than that, nothing important I suspect. Well some
> version of some JVM will abuse it I'm sure ;-)
That's what I was worried about :-)
Ben.
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-05-30 11:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20070530101348.GD24586@lst.de>
On Wed, 2007-05-30 at 12:13 +0200, Christoph Hellwig wrote:
>
> For any sane hypervisor or hardware the copy should be worth
> than that. Then again a sane hardware or hypervisor would support
> SG requests..
Agreed... Sony should fix that, it's a bit ridiculous.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 11:44 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras, Steve Munroe,
Anton Blanchard
In-Reply-To: <ADB2DAF4-B25F-462D-B552-531D706F57BE@kernel.crashing.org>
On Wed, 2007-05-30 at 00:32 -0500, Kumar Gala wrote:
> > I think actually it would be useful to have the saving/restoring of
> > the high 32 bits controlled by a prctl, so that programs have to ask
> > explicitly for the new behaviour (and programs that don't want to
> use
> > the high 32 bits don't incur the extra overhead).
>
> I like this, it means we can error if HW doesn't support it and
> requires applications to do something specific to enable the feature.
Yeah well.... I liked the prctl at first.. but then, I though twice :-)
Thing is, a typical usage pattern would be some library having a hand
optimized tigh loop or something like that using 64 bits registers. An
example, would be some memcpy-type thing in glibc.
You don't want those things to do prctl's all over the place on behalf
of the host application.
Ben.
^ permalink raw reply
* Re: [Patch ] Kexec Kdump support for POWER6
From: Benjamin Herrenschmidt @ 2007-05-30 11:43 UTC (permalink / raw)
To: sachinp; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <465D099B.3020207@in.ibm.com>
On Wed, 2007-05-30 at 10:50 +0530, Sachin P. Sant wrote:
> Paul, here is the final version of the patch with all review
> comments incorporated.
>
> Thanks
> -Sachin
>
>
> plain text document attachment (kexec-kdump-support-on-POWER6)
> * On Power machines supporting VRMA, Kexec/Kdump does not work.
> * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
> * Make sure these hpte entries are left untouched.
> *
> * This patch also adds plpar_pte_read_raw() on the lines of
> * plpar_pte_remove_raw().
>
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530
> +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-29 10:45:34.000000000 +0530
> @@ -373,12 +373,23 @@ static void pSeries_lpar_hptab_clear(voi
> {
> unsigned long size_bytes = 1UL << ppc64_pft_size;
> unsigned long hpte_count = size_bytes >> 4;
> - unsigned long dummy1, dummy2;
> + unsigned long dummy1, dummy2, dword0;
> + long lpar_rc;
> int i;
>
> /* TODO: Use bulk call */
> - for (i = 0; i < hpte_count; i++)
> - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
> + for (i = 0; i < hpte_count; i++) {
> + /* dont remove HPTEs with VRMA mappings */
> + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
> + &dummy1, &dummy2);
> + if (lpar_rc == H_NOT_FOUND) {
> + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
> + if (!lpar_rc && ((dword0 & HPTE_V_VRMA_MASK)
> + != HPTE_V_VRMA_MASK))
> + /* Can be hpte for 1TB Seg. So remove it */
> + plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
> + }
> + }
> }
>
> /*
> diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
> --- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530
> +++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530
> @@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign
> return rc;
> }
>
> +/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */
> +static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex,
> + unsigned long *old_pteh_ret, unsigned long *old_ptel_ret)
> +{
> + long rc;
> + unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
> +
> + rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex);
> +
> + *old_pteh_ret = retbuf[0];
> + *old_ptel_ret = retbuf[1];
> +
> + return rc;
> +}
> +
> static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
> unsigned long avpn)
> {
> diff -Naurp a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
> --- a/include/asm-powerpc/mmu-hash64.h 2007-05-19 09:36:17.000000000 +0530
> +++ b/include/asm-powerpc/mmu-hash64.h 2007-05-29 10:46:22.000000000 +0530
> @@ -94,6 +94,9 @@ extern char initial_stab[];
> #define HPTE_R_C ASM_CONST(0x0000000000000080)
> #define HPTE_R_R ASM_CONST(0x0000000000000100)
>
> +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000)
> +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff000000)
> +
> /* Values for PP (assumes Ks=0, Kp=1) */
> /* pp0 will always be 0 for linux */
> #define PP_RWXX 0 /* Supervisor read/write, User none */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH 5/5] Set IDE in ULI1575 to not native mode.
From: Benjamin Herrenschmidt @ 2007-05-30 11:40 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C307514@zch01exm26.fsl.freescale.net>
On Wed, 2007-05-30 at 10:25 +0800, Zhang Wei-r63237 wrote:
>
> If the driver does not probe the irq itself, the driver will get wrong
> irq for lagecy IDE device.
Sorry, I didn't understand... care to explain in more details ?
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 11:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180475055.19517.206.camel@localhost.localdomain>
>> Also if you want to debug this code (see long long variables
>> correctly from
>> GDB or even see the upper 32-bits of GPRs) you will need an ABI
>> change so
>> that GDB/DWARF knows what to do.
>
> I personally don't care about gdb seeing those or anything like that,
> those would be strictly local asm optimisations, at least that's my
> point of view on the matter.
GDB can step into asm though, it will have to know
about it for full functionality.
> I intend not to extend or change the shape of ucontext neither. I'll
> add
> the highregs after the ucontext32 on the compat signal frame, the only
> change/addition is the use of a pad field to point to it and maybe
> setting a flag that was previously unused and always 0 to indicate that
> it's there.
>
> Do you see any possible compatibility problem there ? Do you know of
> any
> piece of software that makes hard assumptions on the shape and size of
> a
> complete signal frame (not just the ucontext part of it) ?
Perhaps something in a test suite somewhere; other
than that, nothing important I suspect. Well some
version of some JVM will abuse it I'm sure ;-)
Segher
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-30 11:36 UTC (permalink / raw)
To: Josh Boyer
Cc: Alexandre Bounine, David Gibson, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <1180466979.3360.69.camel@zod.rchland.ibm.com>
> We're adding these compatible properties to DTS files and the drivers
> at
> the same time. Unless (until?) there are firmwares for these boards
> that start specifying something else in a real device tree, it really
> doesn't matter much.
Sure. So you have time to work out things now, I
suggest you take advantage of that :-)
> Not that there's anything wrong with your
> reasoning. Just seems like we're trying really hard to define
> something
> "correctly" when we control what's on both sides :).
Right now, and in your case, you do. OTOH, the
goal is to have the DTS be a well-established
stable interface between the firmware/bootloader/
bootwrapper and the kernel; there is no room for
either side of that interface playing dirty tricks,
not on any board ;-)
Also, the DTS files in the kernel source tree should
server as a best-of-breed example for people doing
custom device trees for their own boards. We better
whip them into good shape or we'll all look foolish...
Segher
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Benjamin Herrenschmidt @ 2007-05-30 11:24 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1180475149.19517.209.camel@localhost.localdomain>
On Wed, 2007-05-30 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > It looks like GDB will expect VRSAVE at offset 33*16 (length 4
> bytes)
> > in the area returned by PTRACE_GETVRREGS, for both 32-bit and
> 64-bit
> > applications:
>
> I have to check exactly what's going on there, it might be correct in
> both cases, I just remember that the code did something subtely
> different but it might result in the same thing. I'll double check
> today.
It was indeed correct in both cases, it just stupidly did direct ulong
refs on 32 bits and cast to u32 on 64 bits, which I consolidated into a
single implementation that uses u32 for vrsave so it should work fine.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 11:23 UTC (permalink / raw)
To: Felix Domke; +Cc: linuxppc-dev list
In-Reply-To: <465C9F04.4070202@elitedvb.net>
> Anyway, please don't. It is *not* portable.
What are you talking about ? Really, I mean, I'm not sure I understand
what you mean :-)
> Or can you guarantee that no CPU ever will implement a.) only a 64bit
> subset or b.) other instructions using the same encoding as the 64bit
> insn you will use for testing?
Well, the idea is that we do expose via AT_HWCAP that the ppc64 insn set
is supported. I reckon we might just strip that bit for 32 bits
processes if they can't do 64 bits insn, no need to even get another
one.
> I still remember the pain of trying to tell that ffmpeg that my CPU
> can't do real altivec, even when it implements some parts of it without
> SIGILLing (which ffmpeg used for testing).
Yeah well, ffmpeg is crap, news at 11... there are ways to test wether
you have altivec or not (and more than one) but it looks like most
ffmpeg packages around don't care.
> And: What will happen if you manage to run your code under an operating
> system which doesn't even save the upper bits at all on interrupts? You
> can't check for that with SIGILL.
What are you talking about ? (bis) :-)
> Having a decent way (like aux/glibc) would also solve the problem with
> "incompatible CPUs", which you mentioned.
Ugh ?
Ben.
^ permalink raw reply
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