On 17/12/19 10:51, Alex Bennée wrote:
>>> Secondly if the vCPU is paused (via console or gdbstub) we need to
>>> unwind from our blocking position and be in a position to restart
>>> cleanly.
>> Perhaps if fifo8_is_empty(&c->fifo) the CPU could update the PC back to
>> the SVC instruction and enter
Paolo Bonzini writes:
> On 17/12/19 09:38, Alex Bennée wrote:
>> Thread 3 (Thread 0x7f8b1959e700 (LWP 14017)):
>> #0 0x7f8b2ada900c in futex_wait_cancelable (private=0, expected=0,
>> futex_word=0x56213f5482e8 ) at
>> ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1 0x7f8b
On 17/12/19 09:38, Alex Bennée wrote:
> Thread 3 (Thread 0x7f8b1959e700 (LWP 14017)):
> #0 0x7f8b2ada900c in futex_wait_cancelable (private=0, expected=0,
> futex_word=0x56213f5482e8 ) at
> ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1 0x7f8b2ada900c in __pthread_cond_wait_c
Keith Packard writes:
> Provides a blocking call to read a character from the console using
> semihosting.chardev, if specified. This takes some careful command
> line options to use stdio successfully as the serial ports, monitor
> and semihost all want to use stdio. Here's a sample set of com
Peter Maydell writes:
> It's on my queue to review if nobody else gets to it first, but since
> we're in freeze right now it won't be landing til after the release
> happens (expected mid-December).
Thanks in advance! I'll get started pushing questions about the RISC-V
semihosting ABI into that
On Thu, 14 Nov 2019 at 22:27, Keith Packard wrote:
>
> Richard Henderson writes:
>
> > For semi-hosting, it seems even better if the semi-hosting syscall
> > instruction
> > is not "real", because you're explicitly requesting services from "unreal"
> > hardware. It should be specified to genera
Richard Henderson writes:
> For semi-hosting, it seems even better if the semi-hosting syscall instruction
> is not "real", because you're explicitly requesting services from "unreal"
> hardware. It should be specified to generate a SIGILL type of exception
> anywhere semi-hosting is not enabled
On Thu, 14 Nov 2019 at 20:52, Richard Henderson
wrote:
> Yet another reason why I prefer any semi-hosting call to use an encoding that
> is otherwise reserved illegal.
>
> For this, you have to make up your mind: is it important to execute the
> instructions as specified by the ISA, or as specifie
On 11/14/19 8:29 PM, Peter Maydell wrote:
> On Thu, 14 Nov 2019 at 19:18, Richard Henderson
> wrote:
>> - If the sequence crosses a page, then so be it. Because of
>> step 1, this only happens when we *must* cross a page, and
>> will have recognized any paging exception anyway.
>> T
On Thu, 14 Nov 2019 at 19:18, Richard Henderson
wrote:
> - If the sequence crosses a page, then so be it. Because of
> step 1, this only happens when we *must* cross a page, and
> will have recognized any paging exception anyway.
> The generic parts of qemu will handle proper invali
On Thu, 14 Nov 2019 at 17:47, Peter Maydell wrote:
> The ARM semihosting ABI also has a number of warts
> which are basically historical legacy. With a clean
> sheet you get to avoid some of them. (Notably you could
> skip the whole 'negotiate presence of extensions' business
> by just getting th
On 11/14/19 5:14 PM, Peter Maydell wrote:
> On Fri, 25 Oct 2019 at 20:15, Keith Packard wrote:
>> There seems to be convergence on a pretty simple interface which uses
>> ebreak surrounded by a couple of specific no-ops:
>>
>> slli x0, x0, 0x1f
>> ebreak
>> srai x0, x0, 0x7
>>
>>
On Thu, 14 Nov 2019 at 18:05, Keith Packard wrote:
>
> Peter Maydell writes:
>
> > I had an idle glance at this implementation, and this:
> >
> >uint32_t pre = opcode_at(&ctx->base, ctx->base.pc_next - 4);
> >uint32_t ebreak = opcode_at(&ctx->base, ctx->base.pc_next);
> >uint32_t post
Peter Maydell writes:
> I had an idle glance at this implementation, and this:
>
>uint32_t pre = opcode_at(&ctx->base, ctx->base.pc_next - 4);
>uint32_t ebreak = opcode_at(&ctx->base, ctx->base.pc_next);
>uint32_t post = opcode_at(&ctx->base, ctx->base.pc_next + 4);
>
> (where opcode_
On Thu, 14 Nov 2019 at 17:39, Keith Packard wrote:
>
> Peter Maydell writes:
>
> > That defines the instruction sequence used to make a semihosting
> > call, but not the specification of what the calls are:
> > * what call numbers perform which functions
> > * how arguments are passed to the ca
Alistair Francis writes:
> This sounds like something that the platform spec should contain.
I'm frankly happy with it specifying the semantics by reference to the
ARM docs -- that way we can easily share existing code without concern
about subtle semantic differences.
The only thing that would
Peter Maydell writes:
> That defines the instruction sequence used to make a semihosting
> call, but not the specification of what the calls are:
> * what call numbers perform which functions
> * how arguments are passed to the call (registers? parameter
>blocks in memory? other?)
> * the
On Fri, 25 Oct 2019 at 20:15, Keith Packard wrote:
> There seems to be convergence on a pretty simple interface which uses
> ebreak surrounded by a couple of specific no-ops:
>
> slli x0, x0, 0x1f
> ebreak
> srai x0, x0, 0x7
>
> There are implementations in rust and openocd, and
On Mon, Nov 11, 2019 at 6:51 AM Peter Maydell wrote:
>
> On Tue, 5 Nov 2019 at 05:10, Keith Packard wrote:
> >
> > Peter Maydell writes:
> >
> > > I'm going to push for somebody actually writing out a
> > > document and putting it somewhere that we can point to
> > > and say "that's the authorit
On Tue, 5 Nov 2019 at 05:10, Keith Packard wrote:
>
> Peter Maydell writes:
>
> > I'm going to push for somebody actually writing out a
> > document and putting it somewhere that we can point to
> > and say "that's the authoritative spec", please...
> > it doesn't have to be a big formal thing, b
Peter Maydell writes:
> I'm going to push for somebody actually writing out a
> document and putting it somewhere that we can point to
> and say "that's the authoritative spec", please...
> it doesn't have to be a big formal thing, but I do
> think you want it written down, because the whole poin
Peter Maydell writes:
> I'm going to push for somebody actually writing out a
> document and putting it somewhere that we can point to
> and say "that's the authoritative spec", please...
> it doesn't have to be a big formal thing, but I do
> think you want it written down, because the whole poin
On Fri, 25 Oct 2019 at 20:15, Keith Packard wrote:
>
> Peter Maydell writes:
>
> > Is there a specification for RISC-V semihosting? This is
> > likely to be my first question when the support comes
> > round for review, so you can have it early :-) We'd
> > prefer to implement specified interfac
Peter Maydell writes:
> Is there a specification for RISC-V semihosting? This is
> likely to be my first question when the support comes
> round for review, so you can have it early :-) We'd
> prefer to implement specified interfaces, not random
> ad-hoc "this seems to be what newlib wants to se
Patchew URL: https://patchew.org/QEMU/20191024224622.12371-1-kei...@keithp.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!
Patchew URL: https://patchew.org/QEMU/20191024224622.12371-1-kei...@keithp.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
On Fri, 25 Oct 2019 at 17:40, Keith Packard wrote:
>
> Alex Bennée writes:
>
> > I can see the use for this but I'd like to know what you are testing
> > with. We only have very basic smoketests in check-tcg but I've tested
> > with the latest arm-semihosting tests and they are all fine so no
> >
Keith Packard writes:
> Alex Bennée writes:
>
>> Please keep version history bellow --- so they get dropped when the
>> patch is applied.
>
> Sure, I'll edit the mail before sending. In my repo, I'm leaving the
> version history in git so I can keep track of it.
It's OK to keep the history i
Alex Bennée writes:
> I can see the use for this but I'd like to know what you are testing
> with. We only have very basic smoketests in check-tcg but I've tested
> with the latest arm-semihosting tests and they are all fine so no
> regressions there.
I'm adding semihosting support to picolibc
(
Keith Packard writes:
> Provides a blocking call to read a character from the console using
> semihosting.chardev, if specified. This takes some careful command
> line options to use stdio successfully as the serial ports, monitor
> and semihost all want to use stdio. Here's a sample set of com
On 24/10/19 19:33, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20191023192640.13125-1-kei...@keithp.com/
>
>
>
> Hi,
>
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker installed,
Patchew URL: https://patchew.org/QEMU/20191023192640.13125-1-kei...@keithp.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
Patchew URL: https://patchew.org/QEMU/20191023192640.13125-1-kei...@keithp.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!
Paolo Bonzini writes:
> Please take a look at include/qemu/fifo8.h instead of rolling your own
> ring buffer. Note that it is not thread-safe so you'll have to keep
> that part.
Sorry for not looking around sooner, and thanks for the pointer.
I've also cleaned up the other issues.
> Kudos for
On 22/10/19 20:12, Keith Packard wrote:
> $ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial chardev:stdio0
> -semihosting-config enable=on,chardev=stdio0 -mon
> chardev=stdio0,mode=readline
>
> It might be nice if this could be shortened, but it certainly provides
> the necessary option
Paolo Bonzini writes:
Thanks so much for looking at this patch.
> I'm a bit confused, why is it not using semihosting_get_chardev? That
> would be
>
> -chardev stdio,id=semihost
> -semihosting-config on,chardev=semihost
Because I didn't realize the semihosting code already had a Ch
On 22/10/19 05:13, Keith Packard wrote:
> Provides a blocking call to read a character from the console by hooking
> into the console input chain. This happens *after* any uart has hooked in,
> so specifying -semihost overrides input to any emulated uarts.
>
> Signed-off-by: Keith Packard
I'm a
37 matches
Mail list logo
