Adding New, Unsupported ISA to Qemu

Adding New, Unsupported ISA to Qemu

[Hanson, Seth via]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]


Hello,


I'm looking for in-depth documentation pertaining to how an unsupported 16 bit RISC ISA can be emulated in Qemu.


I've referenced this:


https://wiki.qemu.org/Documentation/TCG


and have been hoping there's additional, related documentation that I've overlooked.


Please advise.



Respectfully,

Seth

[-- Attachment #2: Type: text/html, Size: 927 bytes --]

Re: Adding New, Unsupported ISA to Qemu

[Alex Bennée]

Hanson, Seth via <qemu-devel@nongnu.org> writes:

> Hello,
>
>
> I'm looking for in-depth documentation pertaining to how an unsupported 16 bit RISC ISA can be emulated in Qemu.
>
>
> I've referenced this:
>
>
> https://wiki.qemu.org/Documentation/TCG

I've updated the wiki page to include links to all the TCG documentation
that exists in the source tree. The will hopefully give you a bit more
of an overview of how things go together.

> and have been hoping there's additional, related documentation that I've overlooked.
>
>
> Please advise.

Generally for new targets the guidance is to do what the newer and more
actively maintained front-ends do. In short a new front-end should:

  * use the common translator_loop
  * should probably use decodetree to reduce boilerplate
  * for system emulation emulate a real life device
  * have someone willing to maintain it once merged

Ideally we like to include at least some basic smoke tests for the
platform (tests/tcg/multiarch/system) which will require a publicly
available toolchain which can be wrapped up in our docker build system.

--
Alex Bennée

Re: Adding New, Unsupported ISA to Qemu

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Mon, Nov 04, 2019 at 11:50:11PM +0000, Hanson, Seth via wrote:
> I'm looking for in-depth documentation pertaining to how an unsupported 16 bit RISC ISA can be emulated in Qemu.
> 
> I've referenced this:
> 
> https://wiki.qemu.org/Documentation/TCG
> 
> and have been hoping there's additional, related documentation that I've overlooked.

The general advice I've seen is:

1. Look at existing TCG targets to learn how to implement aspects of
   your ISA.

2. If you are unfamiliar with emulation, CPU ISA, or just-in-time
   compiler concepts, try to read up on them and then look back at the
   QEMU code.  Things will be clearer.

You're welcome to join #qemu IRC on irc.oftc.net to ask questions.

Good luck!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Adding New, Unsupported ISA to Qemu

[Peter Maydell]

On Tue, 5 Nov 2019 at 16:44, Stefan Hajnoczi <stefanha@gmail.com> wrote
> The general advice I've seen is:
>
> 1. Look at existing TCG targets to learn how to implement aspects of
>    your ISA.

...and *don't* look at older/less maintained targets (including
x86), as they have a lot of bad habits you don't want to copy.
Using 'decodetree' is probably a good idea.

> 2. If you are unfamiliar with emulation, CPU ISA, or just-in-time
>    compiler concepts, try to read up on them and then look back at the
>    QEMU code.  Things will be clearer.

I would also add
3.  Don't expect getting this implemented and upstream to be easy.

(Apologies if the following sounds pessimistic and off-putting;
but I would prefer people to have a clear understanding of
what they're getting into and not assume the chances of
success are higher than they might actually be.)

"New TCG target" is an unlucky combination of:
 (1) it's quite a lot of work in pure amount-of-code terms
 (2) because it is a big feature it is not a good choice as a "first
   contribution to the project", but new targets often are proposed
   and written by people who don't have any previous history of
   writing QEMU code
 (3) we already have targets for the common CPU ISAs, so
   anything new is likely to be obscure and not have many people
   who care about it either in our userbase or in our dev community.
   (riscv is the obvious recent exception here, as it is clearly relevant
   as a new architecture and has attracted multiple people to work
   on it and contribute both code and reviews)

1 and 2 mean that code review of a new TCG target is a lot
of work, and 3 means it's not clear how much return the project
gets for that investment :-(

There is not a large community of upstream developers who are
interested in maintaining a lot of obscure guest architectures:
we essentially rely on the goodwill and not-entirely-work-time
of just a few people when it comes to reviewing new TCG targets.
That means that patchsets often hang around on list for a long
time without getting attention.

Our past historical experience has often been that when people
contribute TCG targets, we do a lot of work on our end with
code review and helping to get the code into upstream QEMU, and
then these people more or less disappear, leaving us with the
burden of something we have to support and no help doing it.
If in general people submitting new TCG targets were all
*helping each other*, passing on what they learned to the
next person along, contributing code review, updating older
code as QEMU APIs improve/churn, etc, then I think I'd feel
differently about this. But to be honest mostly I find myself
thinking "oh dear, not another one".

We already have two new TCG ports with patches on list
which are kind of stalled due to not having enough existing
upstream QEMU devs who can/will code review them (and
another which hasn't had patches posted but might do soon).
The odds for your new port having a happier future don't seem
too great to me :-(

thanks
-- PMM

Re: Adding New, Unsupported ISA to Qemu

[Palmer Dabbelt]

On Tue, 05 Nov 2019 08:42:53 PST (-0800), stefanha@gmail.com wrote:
> On Mon, Nov 04, 2019 at 11:50:11PM +0000, Hanson, Seth via wrote:
>> I'm looking for in-depth documentation pertaining to how an unsupported 16 bit RISC ISA can be emulated in Qemu.
>> 
>> I've referenced this:
>> 
>> https://wiki.qemu.org/Documentation/TCG
>> 
>> and have been hoping there's additional, related documentation that I've overlooked.
>
> The general advice I've seen is:
>
> 1. Look at existing TCG targets to learn how to implement aspects of
>    your ISA.

Michael wrote a pair of blogs describing our port.  They're part of the "All 
Aboard" series, which details the RISC-V ports of the various core software 
components (binutils, GCC, glibc, Linux, and QEMU):

     https://www.sifive.com/blog/risc-v-qemu-part-1-privileged-isa-hifive1-virtio
     https://www.sifive.com/blog/risc-v-qemu-part-2-the-risc-v-qemu-port-is-upstream

It's a whole different thing than the documentation and is two years out of 
date, but it at least provides some perspective on why certain things in our 
port were done the way they were in caesy ou end up looking at the code.>

> 2. If you are unfamiliar with emulation, CPU ISA, or just-in-time
>    compiler concepts, try to read up on them and then look back at the
>    QEMU code.  Things will be clearer.
>
> You're welcome to join #qemu IRC on irc.oftc.net to ask questions.
>
> Good luck!
>
> Stefan

Re: [EXTERNAL] Re: Adding New, Unsupported ISA to Qemu

[Hanson, Seth via]

Gentlemen,

Thank you for your input. 


Peter,

I completely understand your concern. Rest assured, this project is entirely internal and requires no code contribution, unit testing, etc. from QEMU devs. We simply want to garner as much documentation as possible to ensure optimal conversion/compatibility. My team and I have already completed a majority of our instruction set mapping into TCG. Lately however, we've encountered issues with floating point operations. 

I noticed in the TCG Readme that floating point operations are no longer officially supported but were previously (per the last paragraph in 4.1).

Can you please provide documentation for implementing the latter?


Regards,
Seth


________________________________________
From: Peter Maydell <peter.maydell@linaro.org>
Sent: Tuesday, November 5, 2019 1:55 PM
To: Stefan Hajnoczi
Cc: Hanson, Seth; qemu-devel@nongnu.org
Subject: [EXTERNAL] Re: Adding New, Unsupported ISA to Qemu

On Tue, 5 Nov 2019 at 16:44, Stefan Hajnoczi <stefanha@gmail.com> wrote
> The general advice I've seen is:
>
> 1. Look at existing TCG targets to learn how to implement aspects of
>    your ISA.

...and *don't* look at older/less maintained targets (including
x86), as they have a lot of bad habits you don't want to copy.
Using 'decodetree' is probably a good idea.

> 2. If you are unfamiliar with emulation, CPU ISA, or just-in-time
>    compiler concepts, try to read up on them and then look back at the
>    QEMU code.  Things will be clearer.

I would also add
3.  Don't expect getting this implemented and upstream to be easy.

(Apologies if the following sounds pessimistic and off-putting;
but I would prefer people to have a clear understanding of
what they're getting into and not assume the chances of
success are higher than they might actually be.)

"New TCG target" is an unlucky combination of:
 (1) it's quite a lot of work in pure amount-of-code terms
 (2) because it is a big feature it is not a good choice as a "first
   contribution to the project", but new targets often are proposed
   and written by people who don't have any previous history of
   writing QEMU code
 (3) we already have targets for the common CPU ISAs, so
   anything new is likely to be obscure and not have many people
   who care about it either in our userbase or in our dev community.
   (riscv is the obvious recent exception here, as it is clearly relevant
   as a new architecture and has attracted multiple people to work
   on it and contribute both code and reviews)

1 and 2 mean that code review of a new TCG target is a lot
of work, and 3 means it's not clear how much return the project
gets for that investment :-(

There is not a large community of upstream developers who are
interested in maintaining a lot of obscure guest architectures:
we essentially rely on the goodwill and not-entirely-work-time
of just a few people when it comes to reviewing new TCG targets.
That means that patchsets often hang around on list for a long
time without getting attention.

Our past historical experience has often been that when people
contribute TCG targets, we do a lot of work on our end with
code review and helping to get the code into upstream QEMU, and
then these people more or less disappear, leaving us with the
burden of something we have to support and no help doing it.
If in general people submitting new TCG targets were all
*helping each other*, passing on what they learned to the
next person along, contributing code review, updating older
code as QEMU APIs improve/churn, etc, then I think I'd feel
differently about this. But to be honest mostly I find myself
thinking "oh dear, not another one".

We already have two new TCG ports with patches on list
which are kind of stalled due to not having enough existing
upstream QEMU devs who can/will code review them (and
another which hasn't had patches posted but might do soon).
The odds for your new port having a happier future don't seem
too great to me :-(

thanks
-- PMM

Re: [EXTERNAL] Re: Adding New, Unsupported ISA to Qemu

[Peter Maydell]

On Tue, 5 Nov 2019 at 21:23, Hanson, Seth <shanson@sandia.gov> wrote:
> I completely understand your concern. Rest assured, this project is entirely internal and requires no code contribution, unit testing, etc. from QEMU devs. We simply want to garner as much documentation as possible to ensure optimal conversion/compatibility. My team and I have already completed a majority of our instruction set
mapping into TCG. Lately however, we've encountered issues with
floating point operations.

Yeah, for internal forks you have none of the upstreaming
issues (you're merely more on-your-own for figuring out
bugs :-))

> I noticed in the TCG Readme that floating point operations are no longer officially supported but were previously (per the last paragraph in 4.1).

Git blame will tell you that that claim about floating point
has been in there since the readme was first added to
the project in 2008. It would be more accurate to say
simply that TCG does not natively implement fp operations.

TCG's approach to fp is to just (at the TCG opcode level)
treat fp registers the same way as integer ones -- they're
32 bit or 64 bit binary values. Mostly fp operations are
implemented by having the TCG code call out to a helper
function, the same way you'd implement any moderately
complex operation that's not easy to do with inline TCG ops.
From the helper function, you can call the various emulation
functions provided by our generic fpu emulation layer
('softfloat') whose headers are in include/fpu. The FPU
emulation provides IEEE-compliant implementations of
various basic operations; you have to tell it how your target
handles things that IEEE 754 doesn't nail down (eg whether
you detect tininess before or after rounding, what your NaN
format is, that kind of thing), through
a mix of calling the functions that initialize the 'float_status'
and also adding to the target-specific ifdeffery in
fpu/softfloat-specialize.inc.c. When your target needs things
that aren't IEEE-specified you just have to implement
emulation of those in your per-target code (arm does this
for the 'recpe' reciprocal-estimate instruction, for instance).

IEEE cumulative exception flags (inexact, denormal, etc)
are tracked in the float_status and need to be made visible
to the guest in whatever fp status register it uses to show
those. The default assumption is that IEEE exceptions
don't generate guest CPU exceptions, but you can implement
the latter if you need it -- see ppc for an example of that.

> Can you please provide documentation for implementing the latter?

As usual for QEMU internals there are no documentation.
You can look at the headers in include/fpu which have some
comments describing the APIs, and at the existing CPUs
which use them to implement their FPU support.

thanks
-- PMM

Re: [EXTERNAL] Re: Adding New, Unsupported ISA to Qemu

[Philippe Mathieu-Daudé]

On 11/5/19 10:39 PM, Peter Maydell wrote:
> On Tue, 5 Nov 2019 at 21:23, Hanson, Seth <shanson@sandia.gov> wrote:
>> I completely understand your concern. Rest assured, this project is entirely internal and requires no code contribution, unit testing, etc. from QEMU devs. We simply want to garner as much documentation as possible to ensure optimal conversion/compatibility. My team and I have already completed a majority of our instruction set
> mapping into TCG. Lately however, we've encountered issues with
> floating point operations.
> 
> Yeah, for internal forks you have none of the upstreaming
> issues (you're merely more on-your-own for figuring out
> bugs :-))
> 
>> I noticed in the TCG Readme that floating point operations are no longer officially supported but were previously (per the last paragraph in 4.1).
> 
> Git blame will tell you that that claim about floating point
> has been in there since the readme was first added to
> the project in 2008. It would be more accurate to say
> simply that TCG does not natively implement fp operations.
> 
> TCG's approach to fp is to just (at the TCG opcode level)
> treat fp registers the same way as integer ones -- they're
> 32 bit or 64 bit binary values. Mostly fp operations are
> implemented by having the TCG code call out to a helper
> function, the same way you'd implement any moderately
> complex operation that's not easy to do with inline TCG ops.
>  From the helper function, you can call the various emulation
> functions provided by our generic fpu emulation layer
> ('softfloat') whose headers are in include/fpu. The FPU
> emulation provides IEEE-compliant implementations of
> various basic operations; you have to tell it how your target
> handles things that IEEE 754 doesn't nail down (eg whether
> you detect tininess before or after rounding, what your NaN
> format is, that kind of thing), through
> a mix of calling the functions that initialize the 'float_status'
> and also adding to the target-specific ifdeffery in
> fpu/softfloat-specialize.inc.c. When your target needs things
> that aren't IEEE-specified you just have to implement
> emulation of those in your per-target code (arm does this
> for the 'recpe' reciprocal-estimate instruction, for instance).
> 
> IEEE cumulative exception flags (inexact, denormal, etc)
> are tracked in the float_status and need to be made visible
> to the guest in whatever fp status register it uses to show
> those. The default assumption is that IEEE exceptions
> don't generate guest CPU exceptions, but you can implement
> the latter if you need it -- see ppc for an example of that.
> 
>> Can you please provide documentation for implementing the latter?
> 
> As usual for QEMU internals there are no documentation.
> You can look at the headers in include/fpu which have some
> comments describing the APIs, and at the existing CPUs
> which use them to implement their FPU support.

You can also read the git history (of a particular file/directory), you 
will learn a lot about API changes and why the design is this way today.

Also, looking at other similar contributions in the mailing list 
archives might give you useful hints. In particular when patches were 
not accepted, what was the reasons.

Regards,

Phil.