Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 1068 +--
target-ppc/translate/vmx-impl.c | 829 ++
target-ppc/translate/vmx-ops.c
This is no longer necessary as the helpers will properly retrieve
the return address when needed.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mmu_helper.c | 12 ++--
target-ppc/translate.c | 1 -
2 files changed, 6 insertions(+), 7 deletions(-)
Instead of relying on NIP having been updated already.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/fpu_helper.c | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/target-ppc/fpu_help
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 1205 +---
target-ppc/translate/fp-impl.c | 1098
target-ppc/translate/fp
No other change
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/fpu_helper.c | 122
1 file changed, 61 insertions(+), 61 deletions(-)
diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index d
This is no longer necessary as the helpers will properly retrieve
the return address when needed. Also remove gen_update_current_nip()
which didn't seem to make much sense to me.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/cpu.h| 1 -
targ
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 994 +---
target-ppc/translate/vsx-impl.c | 721 +
target-ppc/translate/vsx-ops.c
to the right instruction when taking
the fault.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/excp_helper.c | 8
target-ppc/mem_helper.c | 26 --
target-ppc/translate.c | 18 --
3 files changed, 32 insertions(
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 365 +---
target-ppc/translate/dfp-impl.c | 212 +++
target-ppc/translate/dfp-ops.c
This is no longer necessary as the helpers will properly retrieve
the return address.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate/fp-impl.c | 28
target-ppc/translate/vsx-impl.c | 6 --
2 files changed, 34 del
, we'll go through them in subsequent
patches.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
--
v2. Fix raise_exception_ra() to properly pass raddr
---
target-ppc/cpu.h | 8
target-ppc/excp_helper.c | 51
2
On Wed, 2016-07-27 at 12:19 +1000, David Gibson wrote:
> twi etc will generally resume from the next instruction if they trap,
> yes? In which case I'm a bit confused by the nip - 4. But possibly I
> just haven't correctly followed all the nip update logic changed by
> this patch.
>From the ISA
On Wed, 2016-07-27 at 12:47 +1000, David Gibson wrote:
> > +#if defined(HOST_WORDS_BIGENDIAN)
> > + memcpy(>gpr[reg], src, adjlen);
> > + reg += (adjlen >> 2);
> > + addr = addr_add(env, addr, adjlen);
> > +#else
> > + while(adjlen) {
> > + env->gpr[reg++] =
On Wed, 2016-07-27 at 12:36 +1000, David Gibson wrote:
> > - do_dcbz(env, addr, dcbz_size, GETPC());
> > + /* Try fast path translate */
> > + haddr = tlb_vaddr_to_host(env, addr, MMU_DATA_STORE, env->dmmu_idx);
>
> It worries me slightly that this doesn't take any length to verify. I
>
On Wed, 2016-07-27 at 12:33 +1000, David Gibson wrote:
>
> Should you be returning true here?
>
> Without it, IIUC, the functions below will generate the unconditional
> trap, then generate more code to actually test the condition and trap
> again.
You are right, we generate dead code, will
On Wed, 2016-07-27 at 12:30 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:18AM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > The current alignment exception generation tries to load the opcode
> > to put in DSISR from a context where a cpu_ldl_code() is re
On Wed, 2016-07-27 at 12:26 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:15AM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > This is no longer necessary as the helpers will properly retrieve
> > the return address when needed.
>
> Is this right?
On Wed, 2016-07-27 at 12:21 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:12AM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > This is no longer necessary as the helpers will properly retrieve
> > the return address when needed
>
> Well, the helpers are
On Wed, 2016-07-27 at 12:19 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:10AM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > We make env->nip almost always point to the faulting instruction,
> > thus avoiding a mess of "store_current" vs "
On Wed, 2016-07-27 at 12:04 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:07AM +1000, Benjamin Herrenschmidt
> wrote:
> > Instead, pass GETPC() result to the corresponding helpers. This
> > requires a bit of fiddling to get the PC (hopefully) right in
> > th
On Wed, 2016-07-27 at 12:00 +1000, David Gibson wrote:
> On Wed, Jul 27, 2016 at 08:21:06AM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > We don't implement imprecise FP exceptions and using store_current
> > which sets SRR1 to the *previous* instruction never makes sense
On Wed, 2016-07-27 at 11:57 +1000, David Gibson wrote:
> > -void helper_float_check_status(CPUPPCState *env)
> > +static __attribute__((noinline)) void
> do_float_check_status(CPUPPCState *env,
> > +
> uintptr_t raddr)
>
> Why do you need
On Wed, 2016-07-27 at 11:50 +1000, David Gibson wrote:
>
> > +void raise_exception_err(CPUPPCState *env, uint32_t exception,
> > + uint32_t error_code)
> > +{
> > +raise_exception_err_ra(env, exception, error_code, 0);
> > +}
> > +
> > +void raise_exception(CPUPPCState
We don't need to call a helper for trap always and trap never
which are used by Linux under some circumstances.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 48 ++--
1 file changed, 42 insertions
Use a single translate when not crossing a page boundary and avoid
going through layers of helpers. MacOS uses those instructions
a lot, so does OpenBIOS.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.
Instead, pass GETPC() result to the corresponding helpers.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.c | 9 +
target-ppc/translate.c | 4
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/target-ppc/mem_helper.c b/
Use tlb_vaddr_to_host to do a fast path single translate for
the whole cache line. Also make the reservation check match
the entire range.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.c | 46 +-
targ
Move the NIP update to after the conditional branch so that we
don't do it if we aren't going to take the alignment exception
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/
Some operations aren't allowed in LE mode, use a helper rather than
open coding the exception generation.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/targ
Just generate an alignment interrupt
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index df9a5bd..3a6de20
-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/helper.h | 2 ++
target-ppc/mem_helper.c | 60 +
target-ppc/translate/vmx-impl.c | 38 --
target-ppc/translate/vmx-ops.c | 4 +--
4
We were one instruction off
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 5288e02..57e9a12 100644
--- a/targ
.
There are a couple of cases of alignment interrupts that won't set
anything, the ones coming from access to direct store segments, but
that doesn't happen in practice, nobody used direct store segments
and they are gone from newer chips.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.
We need to pass it to the raise helper since we don't update it
before the calls.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mmu-hash64.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/target-ppc/mmu-hash64.c b/targ
This is no longer necessary as the helpers will properly retrieve
the return address when needed.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/excp_helper.c | 6 --
target-ppc/translate.c | 8
2 files changed, 4 insertions(+), 10 del
Instead, pass GETPC() result to the corresponding helpers.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.c | 11 ++-
target-ppc/translate.c | 6 --
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/target-ppc/mem_help
translator was
setting env->nip to ctx->nip - 4 (ie. the *current* instruction)
but the program check exception handler would branch to
"store_current" which applies another -4 offset.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
linux-user/main.c
This is no longer necessary as the helpers will properly retrieve
the return address when needed. Also remove gen_update_current_nip()
which didn't seem to make much sense to me.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/cpu.h| 1 -
targ
We don't use it so let's not generate the updates.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 57e9a12..fcff24a
This is no longer necessary as the helpers will properly retrieve
the return address when needed
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/timebase_helper.c | 23 +--
target-ppc/translate.c | 12
2 files chang
We don't implement imprecise FP exceptions and using store_current
which sets SRR1 to the *previous* instruction never makes sense
for these. So let's be truthful and make them precise, which is
allowed by the architecture.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.
This is no longer necessary as the helpers will properly retrieve
the return address when needed.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mmu_helper.c | 12 ++--
target-ppc/translate.c | 1 -
2 files changed, 6 insertions(+), 7 deletions(-)
No other change
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/fpu_helper.c | 122
1 file changed, 61 insertions(+), 61 deletions(-)
diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index d
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 1069 +--
target-ppc/translate/vmx-impl.c | 829 ++
target-ppc/translate/vmx-ops.c
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 994 +---
target-ppc/translate/vsx-impl.c | 721 +
target-ppc/translate/vsx-ops.c
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 1205 +---
target-ppc/translate/fp-impl.c | 1098
target-ppc/translate/fp
This is no longer necessary as the helpers will properly retrieve
the return address.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate/fp-impl.c | 28
target-ppc/translate/vsx-impl.c | 6 --
2 files changed, 34 del
to the right instruction when taking
the fault.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/excp_helper.c | 8
target-ppc/mem_helper.c | 26 --
target-ppc/translate.c | 18 --
3 files changed, 32 insertions(
Instead of relying on NIP having been updated already.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/fpu_helper.c | 63 +
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/target-ppc/fpu_help
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 1328 +--
target-ppc/translate/spe-impl.c | 1229
target-ppc/translate/spe
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mmu_helper.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index 3eb3cd7..80cc262 100644
--- a/target-ppc/mmu_helper.c
+++ b/targ
Instead of relying on NIP having been updated already
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/fpu_helper.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index e1f600a..8
, we'll go through them in subsequent
patches.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/cpu.h | 8
target-ppc/excp_helper.c | 51
2 files changed, 42 insertions(+), 17 deletions(-)
diff
We forgot to do gen_update_nip() for these like we do with other
helpers. Fix this, but in a more efficient way by passing the RA
to the accessors instead so the overhead is only taken on faults.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.
Makes things a bit more manageable
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/translate.c | 365 +---
target-ppc/translate/dfp-impl.c | 212 +++
target-ppc/translate/dfp-ops.c
On Tue, 2016-07-26 at 06:12 +0530, Richard Henderson wrote:
> The return address argument to the softmmu template helpers was
> confused. In the legacy case, we wanted to indicate that there
> is no return address, and so passed in NULL. However, we then
> immediately subtracted GETPC_ADJ from
We forgot to do gen_update_nip() for these like we do with other
helpers. Fix this, but in a more efficient way by passing the RA
to the accessors instead so the overhead is only taken on faults.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
target-ppc/mem_helper.
On Tue, 2016-07-26 at 06:12 +0530, Richard Henderson wrote:
> The return address argument to the softmmu template helpers was
> confused. In the legacy case, we wanted to indicate that there
> is no return address, and so passed in NULL. However, we then
> immediately subtracted GETPC_ADJ from
On Tue, 2016-07-26 at 08:42 +1000, Benjamin Herrenschmidt wrote:
> We do something a bit different on ppc where we store the access type
> before every access, however the DSISR case is special in that on
> older
> CPUs, it's expected to contains a whole subset of the opcode whic
On Mon, 2016-07-25 at 23:19 +0100, Peter Maydell wrote:
> > For example we have one in powerpc_excp() to read the faulting
> > instruction, though that *should* never fail it's till not great.
>
> Mmm. Strictly speaking you can't guarantee that that load will
> work, because the code you're
On Mon, 2016-07-25 at 17:12 +0200, Tristan Gingold wrote:
> >
> > The code as writte will take the exception before the FPR is
> > updated,
> > I *think*, or am I missing something here ?
>
> This looks like an oversight. In our tests, we don't read the fpr.
BTW. Do you happen to have some
On Mon, 2016-07-25 at 19:42 +0530, Richard Henderson wrote:
> For some targets, we also restore part of the flags computation with this
> mechanism. With more trickery, ARM is (intending to?) compute exception
> syndrome information with this. As I understand it, this is very much akin
> to
On Mon, 2016-07-25 at 19:30 +0530, Richard Henderson wrote:
> > Or can they also be called outside of that context ?
>
> No, not without a valid return address.
>
> E.g. it's not valid to have one helper call another, and for the second
> helper
> use GETPC. For this, typically, one must
On Mon, 2016-07-25 at 19:05 +0530, Richard Henderson wrote:
> > An additional note is that if FE0/FE1 are 0, we still in some case
> > leave an exception behind in cs->exception_index. Now, I *think*
> > that's ok, it will just be silently dropped at some point, but I am not
> > 100% certain as
Hi folks !
I could use a bit of help determining if something is quite right in
TCG emulation of FP ops.
Fabien, Tristan, you submitted a patch back in 2013:
db72c9f256ae70b30c5d5985234f085df4226c55 "powerpc: correctly handle fpu
exceptions" which effectively makes any of the exceptions
On Mon, 2016-07-25 at 06:04 +0530, Richard Henderson wrote:
> I noticed a related problem recently, while working on the cmpxchg patch set.
>
> In my opinion, we should (1) merge GETRA and GETPC so there's no confusion
> between the two, (2) push all adjustment down to the final moment before
On Mon, 2016-07-25 at 10:46 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote:
> >
> > These functions would have to be always_inline for this to work.
> > Otherwise you
> > could get the helper's PC, not the TCG call
On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote:
> These functions would have to be always_inline for this to work.
> Otherwise you
> could get the helper's PC, not the TCG caller's PC.
>
> But let's try to fix this the other way.
I could use some help there as I don't really
On Sun, 2016-07-24 at 22:51 +1000, Benjamin Herrenschmidt wrote:
>
> FYI: This probably completely wrong patch (but it was easier than
> hacking all the helpers) fixed the problem for me. With this (and the
> video driver I wrote that I will publish asap), I can now reliably
>
On Sun, 2016-07-24 at 22:42 +1000, Benjamin Herrenschmidt wrote:
>
> What *did* work was to copy what x86 does, which is to change my
> helper_stvebx() to not use cpu_stb_data at all, but instead use
> cpu_stb_data_ra(, GETPC()), which mimmics what x86 does for some
> of
Hi !
I need help from TCG experts here. I was chasing down a bug causing
some stuff to crash when using vector ops with a ppc32 guest on x86,
but pulling that string led to a whole mess that *may* be affecting a
pile of architetures unless I'm misunderstanding something...
So basically what
On Sat, 2016-07-09 at 10:16 +0200, Cédric Le Goater wrote:
> The login prompt is reached with a full Darwin disk image.
>
> So I must be missing a scenario :/
Yes same here, Darwin worked fine, but I did reproduce the problem with
OS 9. See the fix I sent.
Cheers,
Ben.
On Sat, 2016-07-09 at 13:41 +1000, Benjamin Herrenschmidt wrote:
> MacOS uses an architecturally illegal MSR combination that
> seems nonetheless supported by 32-bit processors, which is
> to have MSR[PR]=1 and one or more of MSR[DR/IR/EE]=0.
>
> This adds support for it. To work p
by the qemu TLB.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
v2. Use the correct flags
target-ppc/helper_regs.h | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/target-ppc/helper_regs.h b/targ
On Sat, 2016-07-09 at 13:22 +1000, Benjamin Herrenschmidt wrote:
> MacOS uses an architecturally illegal MSR combination that
> seems nonetheless supported by 32-bit processors, which is
> to have MSR[PR]=1 and one or more of MSR[DR/IR/EE]=0.
>
> This adds support for it. To work p
by the qemu TLB.
Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
---
This applies on top of the existing "ppc: Enforce setting
MSR:EE, IR and DR when MSR:PR is set" patch, so don't revert it,
and fixes booting MacOS 9.
Mark: I haven't reproduced your problem with
On Sat, 2016-07-09 at 13:00 +1000, Benjamin Herrenschmidt wrote:
> > Additionally, hreg_compute_mem_idx() will treat PR=1 as DR=1/IR=1
> > as well ! That means that if those old processors allow PR=1 and IR
> > or DR=0 and MacOS uses it, we do have a TLB coherency problem in
On Sat, 2016-07-09 at 12:52 +1000, Benjamin Herrenschmidt wrote:
>
> Additionally, hreg_compute_mem_idx() will treat PR=1 as DR=1/IR=1
> as well ! That means that if those old processors allow PR=1 and IR
> or DR=0 and MacOS uses it, we do have a TLB coherency problem in
> qemu.
On Sat, 2016-07-09 at 12:46 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2016-07-09 at 01:43 +0100, Mark Cave-Ayland wrote:
> > On 01/07/16 07:41, David Gibson wrote:
> >
> > > From: Benjamin Herrenschmidt
> > >
> > > The architecture speci
On Sat, 2016-07-09 at 01:43 +0100, Mark Cave-Ayland wrote:
> On 01/07/16 07:41, David Gibson wrote:
>
> > From: Benjamin Herrenschmidt
> >
> > The architecture specifies that any instruction that sets MSR:PR will also
> > set MSR:EE, IR and DR.
.../...
>
On Thu, 2016-07-07 at 11:12 +1000, David Gibson wrote:
> I'm not comfortable with this. SMT may only be used for pseries at
> the moment, but the SMT possibilities are absolutely a constraint of
> the CPU itself, not the machine type. It seems more logical to me to
> check this in the CPU code.
On Wed, 2016-07-06 at 09:53 +0200, Cédric Le Goater wrote:
>
> Thanks for the details, sorry for the noise :/
>
> Are there any OSes using it ?
I initially found the problem with trying to run some AIX diag CD
images that were floating around ;-) I think I re-found it at some
point with some
On Wed, 2016-07-06 at 08:57 +0200, Cédric Le Goater wrote:
>
> > The -1 result is now handled in the JITed code to do the right
> thing
> > (well, afaik).
>
> well, no. It should be a 0 when the slb is not found, and thus no
> machine check. That is how I understand :
Right, which is afaik
On Tue, 2016-07-05 at 19:23 +0200, Cédric Le Goater wrote:
>
>
> So, I was trying today to reconciliate the powernv patchset with
> the current HEAD of qemu when I bumped into the old version of this
> patch. I checked the specs and when no slb are found, rt should
> just be 0. The machine
On Tue, 2016-07-05 at 15:32 +1000, David Gibson wrote:
> On Tue, Jul 05, 2016 at 03:10:34PM +1000, David Gibson wrote:
> > The following changes since commit
> > 11659423113d2fbcf055085b5e8285d590addfaa:
> >
> > Merge remote-tracking branch 'remotes/kraxel/tags/pull-seabios-
> > 20160704-3'
On Tue, 2016-07-05 at 15:10 +1000, David Gibson wrote:
> From: Benjamin Herrenschmidt <b...@kernel.crashing.org>
>
> We need to ignore the segment page size and essentially treat
> all pages as coming from a 4K segment.
NAK
The arguments are still wrong to ppc_hash64_pteg_se
ash" but split up for clarity and with some unnnecessary renames
> removed.
>
> David Gibson (3):
> target-ppc: Correct page size decoding in ppc_hash64_pteg_search()
> target-ppc: Simplify HPTE matching
> target-ppc: Return page shift from PTEG search
All 3:
On Fri, 2016-07-01 at 09:10 +0200, Cédric Le Goater wrote:
> Here is a little serie with API cleanups and fixes for large page and
> VRMA. Previous patches which added the support did not take into
> account the segment page size attribute.
I've done a slightly different patch that subsumes 1...3
On Thu, 2016-06-30 at 18:01 +0200, Cédric Le Goater wrote:
> +static uint32_t ppc_hash64_pte_size_decode(PowerPCCPU *cpu, uint64_t
> pte0,
> + uint64_t pte1, uint32_t
> slb_pshift)
> {
> - switch (slb_pshift) {
> - case 12:
> - return 12;
> -
On Thu, 2016-06-30 at 20:56 +1000, Anton Blanchard wrote:
> Hi,
>
> > From: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> >
> > We were always advertising only 4K & 16M. Additionally the code wasn't
> > properly matching the page size with t
=0 leverages the PowerISA admonition that the reserved
> encodings might change program priority, providing a slight "future
> proofing".
>
> Signed-off-by: Aaron Larson <alar...@ddci.com>
Acked-by: Benjamin Herrenschmidt <b...@kerne.crashing.org>
> ---
>
On Wed, 2016-06-29 at 13:37 +1000, David Gibson wrote:
> AFAICT xirr_owner will be lost on migration, which will break things.
> That will need to be transferred on migration, somehow. If it can be
> recalculated from existing data in post_load() that would be ideal,
> otherwise we'll have to
On Wed, 2016-06-29 at 12:41 +1000, David Gibson wrote:
> > + /* Actually we don't support unbounded RMA anymore since
> we
> > + * added proper emulation of HV mode. The max we can get
> is
> > + * 16G which also happens to be what we configure for PAPR
> > + * mode
On Mon, 2016-06-27 at 16:48 +1000, David Gibson wrote:
> > I wonder if prom_init should "touch" the entire kernel for safety,
> > but in any case, OpenBIOS need that fix urgently.
>
> Ah, ok, I hadn't realized that OpenBIOS still failed to boot, just
> later in the process with this hunk left
On Mon, 2016-06-27 at 14:48 +1000, David Gibson wrote:
> I'm a bit dubious about this, since I'm not sure info pic really has
> much purpose at all. I posted a patch a while back to remove it
> entirely, but it didn't go far for lack of interested, and so far I
> didn't get time to revisit it and
On Thu, 2016-06-23 at 15:48 +1000, David Gibson wrote:
> From: Benjamin Herrenschmidt <b...@kernel.crashing.org>
>
> This reworks emulation of the various "rfi" variants. I removed
> some masking bits that I couldn't make sense of, the only bit that
> I am a
On Tue, 2016-06-21 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> > A quick check with "info mtree" shows that this area of memory is
> > PCI
> > configuration space. There was a patch added to uninorth in
On Tue, 2016-06-21 at 09:21 +0100, Mark Cave-Ayland wrote:
> A quick check with "info mtree" shows that this area of memory is PCI
> configuration space. There was a patch added to uninorth in order to
> suppress some PCI warnings on Darwin boot found by going over the source
> to the Darwin
On Mon, 2016-06-20 at 18:02 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-06-20 at 17:08 +1000, Benjamin Herrenschmidt wrote:
> >
> > That fixed, it dies elsewhere in something related to page faults,
> > still digging.
> >
> Next problem: Darwin kernel
On Mon, 2016-06-20 at 08:17 +0200, Cédric Le Goater wrote:
>
> The current patch does not need fixing. I will send the OpenBIOS
> patch
> shortly after I have looked at the FPU exception.
>
> Linux ppc behaves the same on a 970. So we will need to fix the
> 'rfi's there also.
What do you mean
301 - 400 of 1227 matches
Mail list logo
