Re: Semihosting, arm, riscv, ppc and common code

[Peter Maydell]

On Thu, 16 Jan 2020 at 02:01, Benjamin Herrenschmidt
<address@hidden> wrote:
>
> On Wed, 2020-01-15 at 13:32 +0000, Peter Maydell wrote:
> > On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt
> > <address@hidden> wrote:
> > > On Tue, 2020-01-14 at 09:59 +0000, Peter Maydell wrote:
> > > > Note that semihosting is not a "here's a handy QEMU feature"
> > > > thing. It's an architecture-specific API and ABI, which should
> > > > be defined somewhere in a standard external to QEMU.
> > >
> > > There is no such standard for powerpc today that I know of.
> >
> > So you need to write one down somewhere. You're proposing
> > an ABI which will be implemented by multiple implementors
> > and used by multiple consumers. That needs a spec, not
> > just code. I don't want to see more semihosting implementations
> > added to QEMU that don't have a specification written
> > down somewhere.
>
> That's ok, I can probably get openpower to put a link to the ARM one
> somewhere :-)

Minimally, you need to say:
 * this architecture follows version x of the Arm semihosting
   spec [and give URL]
 * specify the equivalent things to the 'The semihosting interface'
   part of the Arm spec:
    - instruction that causes the trap
    - what the OPERATION NUMBER REGISTER, PARAMETER REGISTER
      and RETURN REGISTER are for your architecture
    - what the data block field size is (32 or 64 bit)
 * say whether your SYS_EXIT is doing the silly 32-bit Arm
   thing or the more sensible allow-app-to-specify-exit-status
   64-bit Arm thing (you should choose the latter!)
 * if you want to make either of the 'semihosting extensions'
   (which fix missing features) mandatory, say so here
 * does your architecture need to define some SYS_EXIT
   codes? The Arm ones have a lot of arm-specific stuff
   like "stopped because of prefetch abort"...

> > The point about the mistakes is that you can't easily fix
> > them by adding extensions, because the core of the biggest
> > mistake is "we didn't provide a good way to allow extensions to
> > be added and probed for by the user". So we had to implement
> > an ugly and hard to implement mechanism instead.
> >  New
> > architectures could mandate providing the good way from the start
> > and avoid the painful-to-implement approach entirely.
> > (I think RISCV has already missed this window of opportunity,
> > which is a shame.)
>
> It is done and so now we have two architectures using that standard, I
> think the value in using the same overweight the value in fixing it but
> yes, we should try to agree on a method of extending at least. Is it
> really that hard ?

It's hard if you don't do it from the start. This is why the
Arm spec's feature-query API is "open a magic filename" --
we couldn't guarantee that existing implementations wouldn't
blow up/crash/etc if the guest code attempted a new "query
feature" semihosting call that didn't exist. If you can
reliably say "all implementations of semihosting for this
arch will fail ENOSYS on unknown semihosting calls", or if
you put in a get-feature-flags call from the start, you don't
have that problem. Otherwise you're stuck with doing it the
way the Arm version does (which requires your implementation
to actually track file handles so it can distinguish "magic
feature-flag file" from "normal host file"; it can't just
pass through host fds/handles to the guest).

Similarly, actually specifying errnos is only easy if you do it
before any implementations.

> IE. We could add a new call for capabilities that takes a pointer to
> a region which we pre-zero before calling in the client and if remains
> zero after the call, then the new stuff isn't there for example. That
> sort of stuff is easy, or am I missing something ?

The problem is if you do "call" and then the implementation
does "kill the VM" or "drop the user into the debugger"...

thanks
-- PMM