On Wed, 2020-01-15 at 13:32 +0000, Peter Maydell wrote: > On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt > <b...@kernel.crashing.org> 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 :-) > 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 ? 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 ? Cheers, Ben.
