** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Status in QEMU:
Nope, looks good here. As a note to other commenters, this won't work
unless you are using a kernel compiled with the 4k page size -- default
for PPC64 is 64k.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
This bug has been moved to "Fix committed" before v2.9.0 has been
release ... so could we move this to "Fix released" now? Or is there
still something left to do here?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Changed in: qemu
Status: In Progress => Fix Committed
** Changed in: qemu
Assignee: Timothy Pearson (kb9vqf) => pranith (bobby-prani)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I tried QEMU with these patches [qemu-x86_64 version 2.6.94
(v2.7.0-rc4-dirty)] but found the same errors as before:
bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self,
tid) != ppid' failed.
setup_frame: not implemented
setup_frame: not implemented
qemu: uncaught
Patch series sent to mailing list here:
http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05334.html
In particular, this patch handles the original signal handler problem:
http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05335.html
** Changed in: qemu
Status: New => In
Finally figured it out!
It's the page size. qemu user mode does NOT support a host page that is
greater than 4k on x86/x86_64 systems, despite some claims to the
contrary on older documentation pages.
I'll be updating the patch to print a clear warning on failure instead
of allowing corrupt
So after some further debugging effort it turns out while the page
allocator is unaware of the mapping (looks like the x86_64 NPTL
implementation never maps the thread ID memory?), g2h() does work on the
address, and in this case they map to the same value. I'll probably
submit a patch using g2h
qemu can locate the guest page with that address but it has a flags
field of all zero (no access, invalid). Any ideas?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using
No, put_user_u32() is correct and __put_user() would be wrong.
child_tidptr is a value passed directly from the guest in a register, so
it is a guest pointer, not a host pointer.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On closer inspection maybe it's not that odd...the parent and child tid
pointers are in abi, not target, space. I'm going to assume direct
assignment is correct (using __put_user()) and proceed from there.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
OK, the fundamental problem is that do_fork() uses put_user_u32() on
child_tidptr, but child_tidptr appears to be a host pointer. Treating
it as a host pointer (direct assignment) allows fork to proceed, but
this seems a bit odd to say the least.
Still investigating.
--
You received this bug
If you've got working code for the signal handlers you can submit those
as patches now if you like.
(http://wiki.qemu.org/Contribute/SubmitAPatch has info on the formatting
hoops.) We have a feature freeze for QEMU 2.7 coming up on the 28th
June, so before then would be ideal.
Judging by the
Yes, I saw that -- implementing the signal handlers fixed the hang and a
few other problems, but the assertion and subsequent SIGABORT/SIGSEGV
are still present. Currently attempting to track down the fork()
issues.
--
You received this bug notification because you are a member of qemu-
By the way there is probably a bug in what we're doing with fork/clone
that's causing the initial assertion, as well as the missing signal
handling problem.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Changed in: qemu
Assignee: (unassigned) => Timothy Pearson (kb9vqf)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Status in
linux-user/signal.c has a collection of functions for creating a signal
frame on the stack before taking a signal, and then reading the data out
of it on return from a signal. The four entry points from the rest of
QEMU are setup_frame(), setup_rt_frame(), do_sigreturn() and
do_rt_sigreturn(). We
Can you point me to the correct location in the codebase / any available
resources on these handlers? I might be able to tackle this at a later
date, but am not currently familiar with qemu's codebase.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
I don't know of any plans to do so. They would not be difficult to
implement (500 lines of code or so at most I guess), but on the other
hand they've been unimplemented for some years. They fall into the
category of "nobody who wants them has cared enough to write the code
yet", I'm afraid.
--
Are there any plans to implement these signal handlers?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Status in QEMU:
New
Bug
We don't have an implementation of the target-specific signal handling
code for the x86-64 guest. Anything that cares about signals therefore
won't work with this target.
In general the x86-64 guest support for linux-user isn't very good; ARM
or AArch64 guest should behave rather better.
--
You
21 matches
Mail list logo
