qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: correct argument num


From: Peter Maydell
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] linux-user: correct argument number for sys_mremap and sys_splice
Date: Tue, 23 Jul 2013 18:33:27 +0100

On 23 July 2013 18:18, Michael Tokarev <address@hidden> wrote:
> 23.07.2013 21:00, Petar Jovanovic wrote:
>> From: Petar Jovanovic <address@hidden>
>>
>> sys_mremap missed 5th argument (new_address), which caused examples that
>> remap to a specific address to fail.
>> sys_splice missed 5th and 6th argument which caused different examples to
>> fail.
>> This change has an effect on MIPS target only.
>
> While splice is obvious and appears to be correct, with mremap I'm not
> this sure.

This table in QEMU corresponds to the table in the kernel
in arch/mips/kernel/scall32-o32.S and should generally have
the same numbers in it.

The fix to mremap corresponds to Linux kernel commit 7dbdf43c
(from 2006); the fix to splice is 08d30879 (from 2008).

> On the other hand, sys_open is also declared as having 3
> arguments while the 3rd one (mode) is also optional,

Yes. All the number-of-arguments param does is cause
the main.c code to fish the extra arguments out of the stack,
since the MIPS 32 bit ABI doesn't have enough registers for
all of them to be in registers. If the argument is optional
and isn't used in this case, it means we've just copied
garbage as the arg6/7/8 param to do_syscall(), which is
exactly the same situation as if the guest ABI put all
syscall args in registers.

> until your last comment which states that the change has only effect
> on MIPS.  Which is quite puzzling to me

It's trivially obvious that it only has effect on MIPS,
because it's patching a piece of code which is inside
an #ifdef TARGET_MIPS guard.

Petar: I think it would be a good idea if you checked
the whole of our table against a recent kernel and made
sure we're in sync for everything, rather than fixing
things one at a time.

Reviewed-by: Peter Maydell <address@hidden>

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]