First of all, kudos - with current qemu tree qemu-alpha-system is
working pretty well - debian install and a *lot* of builds work just fine.
As in, getting from lenny to pretty complete squeeze toolchain, including gcj,
openjdk6 and a lot of crap needed to satisfy build-deps of those, plus
On Tue, Jun 24, 2014 at 05:34:23AM +0100, Al Viro wrote:
> First of all, kudos - with current qemu tree qemu-alpha-system is
> working pretty well - debian install and a *lot* of builds work just fine.
> As in, getting from lenny to pretty complete squeeze toolchain, incl
On Tue, Jun 24, 2014 at 11:33:32AM -0700, Richard Henderson wrote:
> > return (unsigned long)x;// SVCTQ/SVC
CVTTQ/SVC, of course...
> Clearly a gross misunderstanding of what bits are actually computed, never
> mind
> what gets signale
On Tue, Jun 24, 2014 at 11:23:01AM -0700, Richard Henderson wrote:
> > env->error_code = error;
> > if (retaddr) {
> > cpu_restore_state(cs, retaddr);
> > + env->pc += 4;
>
> This one needs a different fix, since dynamic_excp is also used from
> alpha_cpu_unassigned_access, an
On Tue, Jun 24, 2014 at 01:57:52PM -0700, Richard Henderson wrote:
> On 06/24/2014 01:32 PM, Al Viro wrote:
> > If you have any ideas for testing, I do have working hw (the box that is
> > currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
> > I make no p
On Sun, Apr 12, 2015 at 12:42:35PM -, Eric Van Hensbergen wrote:
> In other words, it only uses the open fd to derrive a path and then
> executes the getattr off of that path. If that path no longer exists
> (because of unlink or remove) then you are hosed. In my understanding, the
> "work a
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
> Well, technically fid 3 isn't 'open', only fid 2 is open - at least
> according to the protocol. fid 3 and fid 2 are both clones of fid 1.
> However, thanks for the alternative workaround. If you get a chance, can
> you check
to kfree that string immediately
after that. Easier to just feed that string to nd_set_link() and _not_
kfree it until ->put_link() (which becomes kfree_put_link() in that case).
Signed-off-by: Al Viro
---
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 099c771..48d35d8 100644
--- a/fs/9p/v
On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
> On 06/24/2014 02:24 PM, Al Viro wrote:
> > Al, off to figure out the black magic TCG is using to generate calls...
>
> If you've a helper
>
> DEF_HELPER_1(halt, void, i64)
>
> then
>
On Wed, Jun 25, 2014 at 10:27:11AM +0100, Peter Maydell wrote:
> I think it's OK to put extra float_flags in, provided you can define
> their semantics in terms that make sense for more than one
> architecture (even if only one arch actually happens to need them).
> The input_denormal/output_denor
On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote:
> On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
> > On 06/24/2014 02:24 PM, Al Viro wrote:
> > > Al, off to figure out the black magic TCG is using to generate calls...
> >
> > If you
On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
> Looks good.
>
> I've split it up into a couple of smaller patches, made some sylistic tweaks
> and pushed it to
>
> git://github.com/rth7680/qemu.git axp-next
>
> I'm starting to do some testing now, but a glance though woul
On Mon, Jun 30, 2014 at 09:56:35PM +0100, Al Viro wrote:
> FWIW, it might be better to do what float64_to_int64_round_to_zero() is doing
> -
> i.e.
> if (shift >= 0) {
> if (shift < 64)
> ret = frac << shift;
>
On Tue, Jul 01, 2014 at 05:34:45AM +0100, Al Viro wrote:
> VAX operations are serious mess, but I'm not sure if we have them actually
> used anywhere in Linux kernel or userland. Always possible, of course, but...
Grr... Truncated mail, sorry. Missing part:
_If_ we decide that we
On Tue, Jul 01, 2014 at 10:03:06AM -0700, Richard Henderson wrote:
> On 06/30/2014 01:56 PM, Al Viro wrote:
> > On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
> >
> >> Looks good.
> >>
> >> I've split it up into a couple of s
On Tue, Jul 01, 2014 at 11:30:19AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:23 AM, Peter Maydell wrote:
> > On 1 July 2014 18:50, Al Viro wrote:
> >> Which glibc version? Better yet, could you throw preprocessed source
> >> my way? UP1000 box is not in
On Wed, Jul 02, 2014 at 05:05:08AM +0100, Al Viro wrote:
> OK, DS10 resurrected and so far seems to be stable (I'll know by tomorrow;
> there's a possibility that chipset heatsink is dodgy, but so far it seems
> to be doing OK). That gives us a EV6 box.
>
> Which glib
On Wed, Jul 02, 2014 at 06:50:27AM +0100, Al Viro wrote:
> AFAICS, it leaves two possibilities - EV45 (AS200) vs. EV6 (DS10) and EV67
> (qemu) _or_ some change in the kernel. I'll build 3.x kernel for DS10 and
> post the results; shouldn't take long...
Actually, it's sim
> I'm interested in the results of the following test.
DS10:
/su : 1/3 -i---
/sui : 1/3 -i---
/su : min*min -i--u
/sui : min*min -i--u
/: (long)4.5 -i---
/sv : (long)4.5 -i---
/svi : (long)4.5 -i---
/: (long)max -i---
/sv : (long)max
On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:17 PM, Al Viro wrote:
> > If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
> > better not use FPCR.INE - *all* variants of actual hardware (at least from
>
More bugs: addl/v should sign-extend the result, as addl does.
As it is, we have
uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
ari
On Thu, Jul 03, 2014 at 07:51:04AM +0100, Al Viro wrote:
> FWIW, why not just generate
> trunc_i64_i32 tmp, va
> trunc_i64_i32 tmp2, vb
> muls2_i32 tmp2, tmp, tmp, tmp2
> ext32s_i64 vc, tmp2
> maybe_overflow_32 tmp
> where maybe_overflow throws I
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
> > Grr... Wrong check, obviously - we want to check that tmp + MSB(tmp2) is 0.
> > Something like
> > setcond_32 tmp2, tmp2, zero, TCG_COND_LT
> > add_i32 tmp, tmp2, tmp
> > callhelper_IOV_if_n
On Fri, Jul 04, 2014 at 12:05:37AM +0100, Peter Maydell wrote:
> On 3 July 2014 23:47, Al Viro wrote:
> > How can that be correct? Suppose a = b = 0. We get
> > tcg_gen_eqv_i64(tmp, va, vb); -> tmp = -1
> > tcg_gen_mov_i64(tmp2, va); -> tmp2 = 0
>
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
> I believe I have a tidy solution to these /v insns. New patch set shortly.
OK, looks sane. Next (trivial) bug: in translate_one()
case 0xF800:
/* WH64 */
/* No-op */
break;
should be
On Thu, Jul 03, 2014 at 09:30:05PM -0700, Richard Henderson wrote:
> > Another one is probably not worth bothering - PERR, CTPOP, CTLZ, UNPKBx and
> > PKxB
> > don't accept literal argument. For one thing, as(1) won't let you generate
> > those, so it would have to be explicit
> > .long 0x70
Denorms fun:
a) softfloat.c raises flags we don't care about. So checking that
FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
false positives that way.
b) DNZ has effect *only* for /S insns. Without /S denorm means INV and
that's it. FPCR.INV isn't set, at that.
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
> d) at least on EV6 and EV67 DNOD *still* trips INV. According to the
> manual suppression of INV by DNOD is optional. And while their text
> might be interpreted as "INV is suppressed if operation with denorm
> w
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
> a) softfloat.c raises flags we don't care about. So checking that
> FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
> false positives that way.
>
> b) DNZ has effect *only* for /S insns. Without
On Sat, Jul 05, 2014 at 10:09:51PM +0100, Al Viro wrote:
> Anyway, the current delta (on top of 26f86) follows; seems to get IEEE
> insns behave on non-finite arguments as they do on 21264. The main
> exception is that register bitmask supplied to trap isn't calculated in
>
On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote:
> A couple of points here:
>
> 1) We should never raise this in user-only mode. In that mode, we emulate the
> whole fpu stack, all the way through from HW to the OS completion handler.
How is that different from other cases wher
On Mon, Jul 07, 2014 at 09:20:28AM -0700, Richard Henderson wrote:
> > How is that different from other cases where we have an exception raised
> > by an fp operation?
>
> In all other cases we know we're going to send SIGFPE. That's either through
> a
> non /S insn which the kernel wouldn't tou
On Tue, Jul 08, 2014 at 07:54:36AM +0100, Al Viro wrote:
> On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
> > On 07/07/2014 09:20 PM, Al Viro wrote:
> > > and I'm reasonably sure that this is what they did internally. You are
> > > proposing
On Tue, Jul 08, 2014 at 11:12:20AM -0700, Richard Henderson wrote:
> On 07/08/2014 09:13 AM, Al Viro wrote:
> > Frankly, I suspect that it's better to have qemu-system-alpha behave like
> > the actual hardware does (including "FPCR.DNOD can't be set") and keep
On Tue, Jul 08, 2014 at 12:04:10PM -0700, Richard Henderson wrote:
> > Just one thing - 0x1f will make 32bit hosts whine about integer
> > constant being too large. So will 0x1ful, unfortunately - it
> > really ought to be ull.
> >
>
> I did use ull on the branch.
Aha..
On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
> The code we have currently may well be buggy, but the correct
It is ;-/ We set TARGET_FPE_FLTINV unconditionally there. BTW, what's
the reason why all these cpu_loop() instances can't go into
linux-user//something? Is that just b
On Tue, Jul 08, 2014 at 09:59:33PM -0700, Richard Henderson wrote:
> On 07/08/2014 01:20 PM, Al Viro wrote:
> > Aha... So you've caught that one already... I've looked at your branch;
> > AFAICS, the only thing missing there is treating stores to FPCR.DNOD in
> >
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
> > Incidentally, combination of --enable-gprof and (default) --enable-pie
> > won't build - it dies with ld(1) complaining about relocs in gcrt1.o.
>
> This sounds like a toolchain bug to me :-)
Debian stable/amd64, gcc 4.7.2, binut
On Wed, Jul 09, 2014 at 08:14:12AM -0700, Richard Henderson wrote:
> On 07/08/2014 10:47 PM, Al Viro wrote:
> > So env->fpcr_flush_to_zero = env->fpcr_dnod & env->fpcr_undz; is another
> > bug - needs s/dnod/unfd/ there...
>
> That's exactly wh
On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
> On 07/07/2014 09:20 PM, Al Viro wrote:
> > and I'm reasonably sure that this is what they did internally. You are
> > proposing to do 4 cases in all their messy glory in qemu itself...
>
> Yes. Prim
On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
On 8 July 2014 18:20, Al Viro wrote:
> > On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
> >
> >> > Incidentally, combination of --enable-gprof and (default) --enable-pie
> >>
41 matches
Mail list logo
