From: Richard Henderson <richard.henderson@linaro.org>
To: "Stefan Weil" <sw@weilnetz.de>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Helge Deller <deller@gmx.de>, Michael Tokarev <mjt@tls.msk.ru>,
QEMU Developers <qemu-devel@nongnu.org>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures
Date: Wed, 10 Apr 2019 20:21:00 -1000 [thread overview]
Message-ID: <a04b5f09-4c21-04bc-f224-e9d0b3fb1d79@linaro.org> (raw)
In-Reply-To: <526e88d8-1c5e-1598-6ad3-9b4152ece556@weilnetz.de>
On 4/9/19 8:17 PM, Stefan Weil wrote:
> On 09.04.19 22:39, Richard Henderson wrote:
>> On 4/9/19 9:46 AM, Stefan Weil wrote:
>>> * Calling conventions. The current implementation works on many hosts,
>>> but for example not on Sparc. A fix would require simple calling
>>> conventions for all helper functions (for example stack based argument
>>> passing, can this be enforced?), or it needs to know the signature of
>>> each helper function at runtime. I'm afraid that fixing this would
>>> require much work. A runtime test whether calls of helper functions work
>>> correctly could be implemented easily and could abort the program
>>> execution when calls fail to pass the right arguments. Would such a
>>> runtime test help a little bit?
>>
>> In the rewrite of tci that I proposed some years ago,
>> I used libffi for this.
>>
>> Those patches could probably be recovered...
>>
>> https://patchwork.ozlabs.org/patch/348528/
>> https://patchwork.ozlabs.org/patch/348527/
>
>
> The first patch is the important one because it adds the signature to
> each helper function. As soon as this information is passed to the
> interpreter, the rest is simple. It should not be necessary to add a new
> dependency on libffi, because there are no foreign calling conventions
> here: all helpers use the C calling convention of the host architecture.
Perhaps the "foreign" in libffi is confusing you. Its goal *is* the C calling
convention of the host architecture.
> The TCG implementation for Sparc (and other hosts with special calling
> conventions) must also have some minimum information on the signatures
> of the helper functions. It should be possible to use the same
> information for TCI. Maybe your approach ist a general form which could
> be used for any TCG implementation.
We currently capture only enough information to support the TCG native hosts.
If we were to attempt to support, e.g. m68k as a host, then we would have to
expand this. What I capture for libffi is exact, so it's certainly possible.
But the number of possible function signatures is large. I forget the simple
math that expresses this well, but doing this the long way suggests 4372 as the
number of combinations (up to 6 arguments of 3 types; 4 return types).
This number is large enough that you cannot just open code all of the possible
calls. You absolutely have to know something about the host compiler's calling
convention.
I see only 3 possibilities for this:
(1) Use per host ifdefs and/or assembly to DTRT within TCI.
This admits that TCI requires *some* porting and does
not automatically run everywhere.
(2) Use an external library that already has said assembly,
and has already been ported to every interesting processor,
since it is often done along with the compiler port.
(3) Write a proper TCG backend for each host.
If you see another possibility, please enlighten me.
r~
next prev parent reply other threads:[~2019-04-11 6:21 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 18:57 [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures Helge Deller
2019-04-04 19:24 ` Philippe Mathieu-Daudé
2019-04-05 7:14 ` Helge Deller
2019-04-05 7:14 ` Helge Deller
2019-04-05 1:34 ` Peter Maydell
2019-04-05 1:34 ` Peter Maydell
2019-04-05 7:56 ` Helge Deller
2019-04-05 7:56 ` Helge Deller
2019-04-05 8:26 ` Daniel P. Berrangé
2019-04-05 8:26 ` Daniel P. Berrangé
2019-04-05 9:02 ` Helge Deller
2019-04-05 9:02 ` Helge Deller
2019-04-05 9:10 ` Philippe Mathieu-Daudé
2019-04-05 9:10 ` Philippe Mathieu-Daudé
2019-04-05 9:13 ` Peter Maydell
2019-04-05 9:13 ` Peter Maydell
2019-04-05 9:15 ` Daniel P. Berrangé
2019-04-05 9:15 ` Daniel P. Berrangé
2019-04-05 8:47 ` Philippe Mathieu-Daudé
2019-04-05 8:47 ` Philippe Mathieu-Daudé
2019-04-05 9:02 ` Daniel P. Berrangé
2019-04-05 9:02 ` Daniel P. Berrangé
2019-04-05 9:16 ` Philippe Mathieu-Daudé
2019-04-05 9:16 ` Philippe Mathieu-Daudé
2019-04-09 19:46 ` Stefan Weil
2019-04-09 19:46 ` Stefan Weil
2019-04-09 20:39 ` Richard Henderson
2019-04-09 20:39 ` Richard Henderson
2019-04-10 6:17 ` Stefan Weil
2019-04-10 6:17 ` Stefan Weil
2019-04-11 6:21 ` Richard Henderson [this message]
2019-04-11 6:21 ` Richard Henderson
2019-04-10 6:07 ` Thomas Huth
2019-04-10 6:07 ` Thomas Huth
2019-04-10 6:24 ` Stefan Weil
2019-04-10 6:24 ` Stefan Weil
2019-04-10 8:22 ` Thomas Huth
2019-04-10 8:22 ` Thomas Huth
2019-04-10 19:22 ` Stefan Weil
2019-04-10 19:22 ` Stefan Weil
2019-04-10 7:48 ` Thomas Huth
2019-04-10 7:48 ` Thomas Huth
2019-04-06 8:59 ` Richard Henderson
2019-04-06 8:59 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a04b5f09-4c21-04bc-f224-e9d0b3fb1d79@linaro.org \
--to=richard.henderson@linaro.org \
--cc=aurelien@aurel32.net \
--cc=berrange@redhat.com \
--cc=deller@gmx.de \
--cc=mjt@tls.msk.ru \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).