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
On 10.04.19 10:22, Thomas Huth wrote:
> Additionally, I think it should be possible to compile with the
> x86_64-linux-user target and then to run "make check-tcg" ... however,
> that currently crashes with:
>
> TODO qemu/tcg/tci.c:859: tcg_qemu_tb_exec()
> qemu/tcg/tci.c:859: tcg fatal error
> qe
On 10/04/2019 08.07, Thomas Huth wrote:
> On 09/04/2019 21.46, Stefan Weil wrote:
>> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
Do the various crashes that you i
On 09/04/2019 21.46, Stefan Weil wrote:
[...]
> The known problems with the current implementation are
[...]
> * Calling conventions. The current implementation works on many hosts,
> but for example not on Sparc
Is there also a problem with the sparc *target* (i.e. not only sparc
hosts)? TCI does
On 10.04.19 08:07, Thomas Huth wrote:
> That's great, good to know that you're still interested in TCI! ... but
> I think one of the main problems is still that we completely lack test
> coverage for TCI - the code always is in danger to bit-rot if it is not
> tested by default.
Ideally it would
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
On 09/04/2019 21.46, Stefan Weil wrote:
> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
>>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>>> Do the various crashes that you illustrate in that cover letter
>>> still exist
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 t
On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>> Do the various crashes that you illustrate in that cover letter
>> still exist today ? If so, 2 years of continued brokennes
On 4/5/19 2:56 PM, Helge Deller wrote:
> Looking just at some of the debian "ports" (non-release) architectures:
> alpha, hppa, ia64, m68k, powerpc, sh4, sparc64
FWIW:
sparc64 does have a tcg backend.
(Indeed, tcg/sparc does *not* support 32-bit cpus!)
powerpc does have a tcg backend, and it has
On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Helge,
>>
>> On 4/5/19 9:56 AM, Helge Deller wrote:
>>> On 05.04.19 03:34, Peter Maydell wrote:
On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> If a non-release
On Fri, Apr 05, 2019 at 11:02:52AM +0200, Helge Deller wrote:
> On 05.04.19 10:26, Daniel P. Berrangé wrote:
> > On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
> >> Hi Peter,
> >>
> >> On 05.04.19 03:34, Peter Maydell wrote:
> >>> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> >
On Fri, 5 Apr 2019 at 16:02, Helge Deller wrote:
> Sadly such special treatment by projects makes life for me
> as an architecture maintainer much harder :-(
It's kind of inevitable for programs that aren't straightforwardly
architecture agnostic. gcc doesn't work for architectures which
don't ha
Cc'ing qemu-block.
On 4/5/19 11:02 AM, Helge Deller wrote:
[...]
> As another example, even if I only want to build "qemu-img", I still need
> to manually give the --enable-tcg-interpreter configure option.
You found a bug :)
On 05.04.19 10:26, Daniel P. Berrangé wrote:
> On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
>> Hi Peter,
>>
>> On 05.04.19 03:34, Peter Maydell wrote:
>>> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
If a non-release architecture is found, and it's known that there is no
On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Helge,
>
> On 4/5/19 9:56 AM, Helge Deller wrote:
> > On 05.04.19 03:34, Peter Maydell wrote:
> >> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> >>> If a non-release architecture is found, and it's known that there
Hi Helge,
On 4/5/19 9:56 AM, Helge Deller wrote:
> On 05.04.19 03:34, Peter Maydell wrote:
>> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
>>> If a non-release architecture is found, and it's known that there is no
>>> native TCG support for that CPU, automatically fall back to the TCI
>>> im
On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
> Hi Peter,
>
> On 05.04.19 03:34, Peter Maydell wrote:
> > On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> >> If a non-release architecture is found, and it's known that there is no
> >> native TCG support for that CPU, automatical
Hi Peter,
On 05.04.19 03:34, Peter Maydell wrote:
> On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
>> If a non-release architecture is found, and it's known that there is no
>> native TCG support for that CPU, automatically fall back to the TCI
>> implementation instead of requesting the user t
Hi Philippe,
On 04.04.19 21:24, Philippe Mathieu-Daudé wrote:
> Hi Helge,
>
> On 4/4/19 8:57 PM, Helge Deller wrote:
>> If a non-release architecture is found, and it's known that there is no
>> native TCG support for that CPU, automatically fall back to the TCI
>> implementation instead of reques
On Fri, 5 Apr 2019 at 01:59, Helge Deller wrote:
> If a non-release architecture is found, and it's known that there is no
> native TCG support for that CPU, automatically fall back to the TCI
> implementation instead of requesting the user to run configure again
> with the --enable-tcg-interprete
Hi Helge,
On 4/4/19 8:57 PM, Helge Deller wrote:
> If a non-release architecture is found, and it's known that there is no
> native TCG support for that CPU, automatically fall back to the TCI
> implementation instead of requesting the user to run configure again
> with the --enable-tcg-interprete
If a non-release architecture is found, and it's known that there is no
native TCG support for that CPU, automatically fall back to the TCI
implementation instead of requesting the user to run configure again
with the --enable-tcg-interpreter option.
This change simplifies building qemu in automat
23 matches
Mail list logo
