Josh Kunz <j...@google.com> writes:
> Thanks for the responses Alex. I'm working on your comments, but > wanted to clarify some of the points you brought up before mailing a > second version. Responses inline. > > On Tue, Jun 16, 2020 at 9:08 AM Alex Bennée <alex.ben...@linaro.org> wrote: >> Which by the way fail on some targets: >> >> TEST linux-test on alpha >> /home/alex/lsrc/qemu.git/tests/tcg/multiarch/linux-test.c:709: child did >> not receive PDEATHSIG on parent death >> make[2]: *** [../Makefile.target:153: run-linux-test] Error 1 >> make[1]: *** [/home/alex/lsrc/qemu.git/tests/tcg/Makefile.qemu:76: >> run-guest-tests] Error 2 >> make: *** [/home/alex/lsrc/qemu.git/tests/Makefile.include:851: >> run-tcg-tests-alpha-linux-user] Error 2 >> >> Have you managed a clean check-tcg with docker enabled so all the guest >> architectures get tested? > > I've gotten this Alpha failure to reproduce on my local build and I'm > working on a fix. Thanks for pointing this out. I'll make sure I get a > clean `make check-tcg` for `linux-test` on all guest architectures. > >> > In this patch, I've employed an alternative approach: spawning a thread >> > an "stealing" its TLS image for use in the child process. This approach >> > leaves a dangling thread while the TLS image is in use, but by design >> > that thread will not become schedulable until after the TLS data is no >> > longer in-use by the child (as described in a moment). Therefore, it >> > should cause relatively minimal overhead. When considered in the larger >> > context, this seems like a reasonable tradeoff. >> >> *sharp intake of breath* >> >> OK so the solution to the complexity of handling threads is to add more >> threads? cool cool cool.... > > The solution to the complexity of shared memory, but yeah, not my > favorite either. I was kinda hoping that someone on the list would > explain why this approach is clearly wrong. > >> > * Non-standard libc extension to allow creating TLS images independent >> > of threads. This would allow us to just `clone` the child directly >> > instead of this complicated maneuver. Though we probably would still >> > need the cleanup logic. For libcs, TLS image allocation is tightly >> > connected to thread stack allocation, which is also arch-specific. I >> > do not have enough experience with libc development to know if >> > maintainers of any popular libcs would be open to supporting such an >> > API. Additionally, since it will probably take years before a libc >> > fix would be widely deployed, we need an interim solution anyways. >> >> We could consider a custom lib stub that intercepts calls to the guests >> original libc and replaces it with a QEMU aware one? > > Unfortunately the problem here is host libc, rather than guest libc. > We need to make TLS variables in QEMU itself work, so intercepting > guest libc calls won't help much. Or am I misunderstanding the point? Hold up - I'm a little confused now. Why does the host TLS affect the guest TLS? We have complete control over the guests view of the world so we should be able to control it's TLS storage. >> Have you considered a daemon which could co-ordinate between the >> multiple processes that are sharing some state? > > Not really for the `CLONE_VM` support added in this patch series. I > have considered trying to pull tcg out of the guest process, but not > very seriously, since it seems like a pretty heavyweight approach. > Especially compared to the solution included in this series. Do you > think there's a simpler approach that involves using a daemon to do > coordination? I'm getting a little lost now. Exactly what state are we trying to share between two QEMU guests which are now in separate execution contexts? -- Alex Bennée
