[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 03/28] semihosting: implement a semihosting c
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH v2 03/28] semihosting: implement a semihosting console |
Date: |
Fri, 24 May 2019 11:56:26 +0100 |
On Fri, 24 May 2019 at 11:46, Alex Bennée <address@hidden> wrote:
>
>
> Peter Maydell <address@hidden> writes:
>
> > On Thu, 23 May 2019 at 11:39, Alex Bennée <address@hidden> wrote:
> > I'm not sure about the "no callback" part of this API. The operation
> > here is genuinely asynchronous and providing no mechanism for the
> > caller to be able to say "ok, now wait til it completes" doesn't
> > seem like a good plan.
>
> Well the caller doesn't really get a choice. At least in system mode
> gdbstub does a vm_stop(RUN_STATE_DEBUG) and brings everything to a halt
> anyway. All we've removed is the ability to tack on a callback (which
> can get run in all sorts of contexts) when we restart.
gdb_do_syscall() is asynchronous -- it arranges for the syscall
to happen, but makes no guarantee about when it will finish.
At the moment the gdb_do_syscall() API allows the caller
to cope with this asynchronousness, because when the callback
is called the syscall has definitely finished. As it happens
the callers are buggy in that they don't actually do the
sync that they need to do, but we could fix that bug (ie post
a semaphore in the callback function, and wait on it after
the gdb_do_syscall() call). The API for this new function
doesn't allow us to do that.
> I could just drop the API here and allow the semihosting API to call
> gdb_do_syscallv directly?
I think we should either make the implementation of the function
properly synchronous (ie do the post-semaphore-in-callback,
wait-on-it-after-gdb_do_syscallv thing in the implementation,
or have an API that lets callers do it.
Perhaps we should just make gdb_do_syscall really be
synchronous (ie have it do the semaphore stuff)? We
only actually use it in semihosting, and I think all
those cases require that the operation completes before
we can resume execution of the guest CPU. So doing the
synchronization in one place in the gdb code would be
simpler than doing it separately in all the callers...
thanks
-- PMM
- [Qemu-devel] [PATCH v2 08/28] target/arm: correct return values for WRITE/READ in arm-semi, (continued)
- [Qemu-devel] [PATCH v2 08/28] target/arm: correct return values for WRITE/READ in arm-semi, Alex Bennée, 2019/05/23
- [Qemu-devel] [PATCH v2 09/28] target/mips: only build mips-semi for softmmu, Alex Bennée, 2019/05/23
- [Qemu-devel] [PATCH v2 17/28] tests/tcg/aarch64: add system boot.S, Alex Bennée, 2019/05/23
- [Qemu-devel] [PATCH v2 11/28] MAINTAINERS: update for semihostings new home, Alex Bennée, 2019/05/23
- [Qemu-devel] [PATCH v2 03/28] semihosting: implement a semihosting console, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 04/28] semihosting: enable chardev backed output for console, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 15/28] tests/tcg/multiarch: add hello world system test, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 05/28] target/arm: fixup some of the commentary for arm-semi, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 07/28] target/arm: add LOG_UNIMP messages to arm-semi, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 10/28] target/mips: convert UHI_plog to use common semihosting code, Alex Bennée, 2019/05/23
[Qemu-devel] [PATCH v2 13/28] tests/docker: Test more components on the Fedora default image, Alex Bennée, 2019/05/23