There have been some comments on the ML about the usefulness of tci.

https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04551.html

  Peter Maydell> I'd prefer we just got rid of it.

https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04296.html

  Richard Henderson> Is it time to remove it? I'm pretty sure the only hosts
                     for which it will work have proper backends...

Richard quotes are way clearer than me trying to paraphrase what he told me:
- it doesn't use libffi, and as such the way it makes calls to helpers doesn't work for many hosts.
- we already cover almost everthing that debian does. if debian or gentoo doesn't support it, one can confidently say there's little interest.
- if someone *does* want to run qemu on something else, it isn't difficult to port tcg.

I figured out MAINTAINERS was unsync, so added patches 1-4, they are not really
tci-related.

Patches 5,6 are trivial fixes to let the codebase quite sane if there is future
need to revert/reimport tci.

Patches 7,8 are the removal, marked RFC... let's debate!

Regards,

Phil.

PS: How to have fun with TCI and MTTCG:

$ wget -q https://github.com/raspberrypi/firmware/raw/master/boot/kernel7.img
$ ./configure --enable-tcg-interpreter && make subdir-arm-softmmu

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
Segmentation fault (core dumped)

-

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
qemu-system-arm: Trying to execute code outside RAM or ROM at 0xef661ad0
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

Segmentation fault (core dumped)

-

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
qemu-system-arm: Trying to execute code outside RAM or ROM at 0xe28fe004
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

qemu-system-arm: qemu/accel/tcg/cpu-exec.c:599: cpu_loop_exec_tb: Assertion `use_icount' failed.
Aborted (core dumped)

-

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
qemu/tcg/tcg.c:480: temp_idx: Assertion `n >= 0 && n < s->nb_temps' failed.
Aborted (core dumped)

-
$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
write access to unsupported AArch32 system register cp:15 opc1:4 crn:12 crm:0 opc2:0 (non-secure)
Segmentation fault (core dumped)

-

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
qemu-system-arm: Trying to execute code outside RAM or ROM at 0xe59f5014
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

qemu: fatal: Trying to execute code outside RAM or ROM at 0xe59f5014
R00=00000031 R01=00000308 R02=00000000 R03=e59f5014
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000308 R15=e59f5014
PSR=a00001d3 N-C- A NS svc32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000

-

$ arm-softmmu/qemu-system-arm -machine raspi2 -cpu cortex-a7 -smp 4 -accel tcg,thread=multi -kernel kernel7.img
qemu-system-arm: Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors
read access to unsupported AArch32 64 bit system register cp:13 opc1: 13 crm:0 (non-secure)
qemu: fatal: Unhandled exception 0x0

R00=00000002 R01=00000308 R02=00000000 R03=08000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000308 R15=08000000
PSR=200001d3 --C- A NS svc32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000

:)

Philippe Mathieu-Daudé (8):
  MAINTAINERS: update tcg entries
  MAINTAINERS: update kvm entries
  MAINTAINERS: update xen entries
  MAINTAINERS: update tci entry
  tcg/tci: enable bswap16_i64
  tcg/tci: disable MTTCG if TCI is enabled
  tcg/tci: time to remove it :(
  travis: remove tcg/tci job

 .travis.yml              |    3 -
 MAINTAINERS              |   16 +-
 Makefile.target          |    2 -
 configure                |   31 +-
 disas.c                  |    5 +-
 disas/Makefile.objs      |    4 -
 disas/tci.c              |   61 ---
 include/disas/bfd.h      |    1 -
 include/exec/exec-all.h  |   16 +-
 tcg/tcg-common.c         |    4 -
 tcg/tcg.c                |    6 +-
 tcg/tci.c                | 1251 ----------------------------------------------
 tcg/tci/README           |  130 -----
 tcg/tci/tcg-target.h     |  195 --------
 tcg/tci/tcg-target.inc.c |  897 ---------------------------------
 15 files changed, 14 insertions(+), 2608 deletions(-)
 delete mode 100644 disas/tci.c
 delete mode 100644 tcg/tci.c
 delete mode 100644 tcg/tci/README
 delete mode 100644 tcg/tci/tcg-target.h
 delete mode 100644 tcg/tci/tcg-target.inc.c

-- 
2.13.1

 Hi Philippe,

On 29.06.2017 03:02, Philippe Mathieu-Daudé wrote:
> There have been some comments on the ML about the usefulness of tci.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04551.html
> 
>   Peter Maydell> I'd prefer we just got rid of it.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04296.html
> 
>   Richard Henderson> Is it time to remove it? I'm pretty sure the only hosts
>                      for which it will work have proper backends...
> 
> Richard quotes are way clearer than me trying to paraphrase what he told me:
> - it doesn't use libffi, and as such the way it makes calls to helpers doesn't work for many hosts.
> - we already cover almost everthing that debian does. if debian or gentoo doesn't support it, one can confidently say there's little interest.
> - if someone *does* want to run qemu on something else, it isn't difficult to port tcg.
> 
> I figured out MAINTAINERS was unsync, so added patches 1-4, they are not really
> tci-related.

Since they are not related to TCI at all, please submit these as
separate series.

> Patches 5,6 are trivial fixes to let the codebase quite sane if there is future
> need to revert/reimport tci.

I think this should go into 2.10...

> Patches 7,8 are the removal, marked RFC... let's debate!

... but NACK for a direct removal. Common sense is to make obsolete
features as deprecated first and then wait for 2 public releases before
the final removal, so that users still have a chance to speak up in case
they still need the feature and are willing to maintain it.

Please see the following URL for details (and please also add an entry
for TCI in the Miscellaneous section there):

  http://wiki.qemu.org/Features/LegacyRemoval

 Thomas

On 06/29/2017 05:46 AM, Thomas Huth wrote:>> I figured out MAINTAINERS 
was unsync, so added patches 1-4, they are not really
>> tci-related.
> 
> Since they are not related to TCI at all, please submit these as
> separate series.

Ok.

>> Patches 5,6 are trivial fixes to let the codebase quite sane if there is future
>> need to revert/reimport tci.
> 
> I think this should go into 2.10...

Ok I will resend separately.

>> Patches 7,8 are the removal, marked RFC... let's debate!
> 
> ... but NACK for a direct removal. Common sense is to make obsolete
> features as deprecated first and then wait for 2 public releases before
> the final removal, so that users still have a chance to speak up in case
> they still need the feature and are willing to maintain it.
> 
> Please see the following URL for details (and please also add an entry
> for TCI in the Miscellaneous section there):
> 
>    http://wiki.qemu.org/Features/LegacyRemoval

Ok I'll follow the procedure and see how to modify the ./configure (with 
Daniel comment), also update the wiki accordingly.

Regards,

Phil.

On 29/06/2017 10:46, Thomas Huth wrote:
>> Patches 7,8 are the removal, marked RFC... let's debate!
> ... but NACK for a direct removal. Common sense is to make obsolete
> features as deprecated first and then wait for 2 public releases before
> the final removal, so that users still have a chance to speak up in case
> they still need the feature and are willing to maintain it.

I think this is a slightly different case than what is in
http://wiki.qemu.org/Features/LegacyRemoval.

TCI is enabled only with a specific configure argument if your machine
is not supported by TCG.  This would break _build_ configurations, not
user configurations.  It's a remote possibility that users are building
their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
be more speedy in removing the code.

Paolo

On 29.06.2017 17:06, Paolo Bonzini wrote:
> 
> 
> On 29/06/2017 10:46, Thomas Huth wrote:
>>> Patches 7,8 are the removal, marked RFC... let's debate!
>> ... but NACK for a direct removal. Common sense is to make obsolete
>> features as deprecated first and then wait for 2 public releases before
>> the final removal, so that users still have a chance to speak up in case
>> they still need the feature and are willing to maintain it.
> 
> I think this is a slightly different case than what is in
> http://wiki.qemu.org/Features/LegacyRemoval.
> 
> TCI is enabled only with a specific configure argument if your machine
> is not supported by TCG.  This would break _build_ configurations, not
> user configurations.  It's a remote possibility that users are building
> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
> be more speedy in removing the code.

You never know ... it's unlikely, but there might be people around who
run configure with "--enable-tcg-interpreter" on purpose. And why the
hurry for removing this? It's been around in the current shape since
years, so waiting for two more releases does not hurt, does it?

 Thomas

On 29/06/2017 17:46, Thomas Huth wrote:
>> TCI is enabled only with a specific configure argument if your machine
>> is not supported by TCG.  This would break _build_ configurations, not
>> user configurations.  It's a remote possibility that users are building
>> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
>> be more speedy in removing the code.
> You never know ... it's unlikely, but there might be people around who
> run configure with "--enable-tcg-interpreter" on purpose.

And they have never reported a bug? :)  But I agree it's not a big deal.
 Richard should decide.

Paolo

> And why the
> hurry for removing this? It's been around in the current shape since
> years, so waiting for two more releases does not hurt, does it?

On 29.06.2017 17:47, Paolo Bonzini wrote:
> 
> 
> On 29/06/2017 17:46, Thomas Huth wrote:
>>> TCI is enabled only with a specific configure argument if your machine
>>> is not supported by TCG.  This would break _build_ configurations, not
>>> user configurations.  It's a remote possibility that users are building
>>> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
>>> be more speedy in removing the code.
>> You never know ... it's unlikely, but there might be people around who
>> run configure with "--enable-tcg-interpreter" on purpose.
> 
> And they have never reported a bug? :)  But I agree it's not a big deal.
>  Richard should decide.
> 
> Paolo
> 
>> And why the
>> hurry for removing this? It's been around in the current shape since
>> years, so waiting for two more releases does not hurt, does it?

The various BSD folks also decided to rather maintain their patches
downstream instead of trying hard to get them included in the upstream
repository... now that we've got a deprecation warning in the configure
script, things fortunately start to change :-)

Likely nobody is maintaining downstream TCI patches ... but we don't
really now for sure - it could be the same situation as with BSD. So we
should give the users a chance to speak up first before we remove it.

 Thomas

On 06/29/2017 12:47 PM, Paolo Bonzini wrote:
> On 29/06/2017 17:46, Thomas Huth wrote:
>>> TCI is enabled only with a specific configure argument if your machine
>>> is not supported by TCG.  This would break _build_ configurations, not
>>> user configurations.  It's a remote possibility that users are building
>>> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
>>> be more speedy in removing the code.
>> You never know ... it's unlikely, but there might be people around who
>> run configure with "--enable-tcg-interpreter" on purpose.
> 
> And they have never reported a bug? :)  But I agree it's not a big deal.
>   Richard should decide.
> 
> Paolo
> 
>> And why the
>> hurry for removing this? It's been around in the current shape since
>> years, so waiting for two more releases does not hurt, does it?

It is unlikely someone is using it for ARM aarch64 (see patch 5).

MTTCG was not in 2.9 but is now enabled by default on alpha/arm* since 
February 2017 and on ppc64 since April 2017. Looking at the 6 different 
bugs I show in the cover, I'm pretty sure no active developer but me 
keep trying to use tci :p

Phil.

Am 29.06.2017 um 17:47 schrieb Paolo Bonzini:
> 
> 
> On 29/06/2017 17:46, Thomas Huth wrote:
>>> TCI is enabled only with a specific configure argument if your machine
>>> is not supported by TCG.  This would break _build_ configurations, not
>>> user configurations.  It's a remote possibility that users are building
>>> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
>>> be more speedy in removing the code.
>> You never know ... it's unlikely, but there might be people around who
>> run configure with "--enable-tcg-interpreter" on purpose.
> 
> And they have never reported a bug? :)  But I agree it's not a big deal.
>  Richard should decide.
> 
> Paolo

Was there a bug? I'm not aware of one.

The TODO assertions were added on purpose when I wrote the code:

Initially all TCG codes had it, and I removed them as soon as a
statement was executed and I had verified the result.

So the recently failing assertions are simply code which was
not triggered before, maybe because earlier versions of QEMU
did not use those cases or maybe because a new guest scenario
now needs them while my tests did not.

TCI was never meant to be used for production, so I think
my approach was acceptable.

Stefan

On 29 June 2017 at 17:45, Stefan Weil <sw@weilnetz.de> wrote:
> TCI was never meant to be used for production, so I think
> my approach was acceptable.

I think perhaps this is at the root of some of the difference
in perspective here -- I tend to the view that given that
QEMU is a production codebase, we should not really have
code in it which is neither (a) production-quality nor
(b) intended to be incrementally improved until it reaches
that level of usability; so anything that's in the middle
ground should either be improved, or removed.
I don't know whether I'm in a minority in that general view.

You can make a similar argument regarding the obscure host OS/CPU
either we support the platform well enough that you can
actually use it and we're testing to ensure it remains the
case, or we don't support it, and we should remove the code.
(Ditto, various ancient board models...)

thanks
-- PMM

On Thu, Jun 29, 2017 at 05:46:26PM +0200, Thomas Huth wrote:
> On 29.06.2017 17:06, Paolo Bonzini wrote:
> > 
> > 
> > On 29/06/2017 10:46, Thomas Huth wrote:
> >>> Patches 7,8 are the removal, marked RFC... let's debate!
> >> ... but NACK for a direct removal. Common sense is to make obsolete
> >> features as deprecated first and then wait for 2 public releases before
> >> the final removal, so that users still have a chance to speak up in case
> >> they still need the feature and are willing to maintain it.
> > 
> > I think this is a slightly different case than what is in
> > http://wiki.qemu.org/Features/LegacyRemoval.
> > 
> > TCI is enabled only with a specific configure argument if your machine
> > is not supported by TCG.  This would break _build_ configurations, not
> > user configurations.  It's a remote possibility that users are building
> > their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
> > be more speedy in removing the code.
> 
> You never know ... it's unlikely, but there might be people around who
> run configure with "--enable-tcg-interpreter" on purpose. And why the
> hurry for removing this? It's been around in the current shape since
> years, so waiting for two more releases does not hurt, does it?

The flipside is that even if we delete it, if someone does suddenly
care, the code is still there in git & easy to undelete again. Given
that we believe there are zero users, it is known broken in many
ways, and TCG provides a working alternative, I don't see a strong
reason to not just kill it right away. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 29 June 2017 at 17:07, Daniel P. Berrange <berrange@redhat.com> wrote:
> The flipside is that even if we delete it, if someone does suddenly
> care, the code is still there in git & easy to undelete again. Given
> that we believe there are zero users, it is known broken in many
> ways, and TCG provides a working alternative, I don't see a strong
> reason to not just kill it right away.

"zero users" is quite a strong and hard to prove statement.
I don't really see a reason not to do at least one release
of deprecate-and-warn before we drop it.

(People do occasionally do weird stuff with TCI, eg http://qira.me/
involves a QEMU fork with a very hacked about TCI.)

thanks
-- PMM

On 29.06.2017 18:07, Daniel P. Berrange wrote:
> On Thu, Jun 29, 2017 at 05:46:26PM +0200, Thomas Huth wrote:
>> On 29.06.2017 17:06, Paolo Bonzini wrote:
>>>
>>>
>>> On 29/06/2017 10:46, Thomas Huth wrote:
>>>>> Patches 7,8 are the removal, marked RFC... let's debate!
>>>> ... but NACK for a direct removal. Common sense is to make obsolete
>>>> features as deprecated first and then wait for 2 public releases before
>>>> the final removal, so that users still have a chance to speak up in case
>>>> they still need the feature and are willing to maintain it.
>>>
>>> I think this is a slightly different case than what is in
>>> http://wiki.qemu.org/Features/LegacyRemoval.
>>>
>>> TCI is enabled only with a specific configure argument if your machine
>>> is not supported by TCG.  This would break _build_ configurations, not
>>> user configurations.  It's a remote possibility that users are building
>>> their own QEMU, with TCI enabled, to work around a TCG bug.  So we can
>>> be more speedy in removing the code.
>>
>> You never know ... it's unlikely, but there might be people around who
>> run configure with "--enable-tcg-interpreter" on purpose. And why the
>> hurry for removing this? It's been around in the current shape since
>> years, so waiting for two more releases does not hurt, does it?
> 
> The flipside is that even if we delete it, if someone does suddenly
> care, the code is still there in git & easy to undelete again. Given
> that we believe there are zero users, it is known broken in many
> ways, and TCG provides a working alternative, I don't see a strong
> reason to not just kill it right away. 

At least I was using TCI a couple of times during the last years (when I
was suspecting a bug in the normal TCG backend, so I could compare).
There might be other people, too, so I would not dare to say that there
are zero users!
Though I used it a couple of times in the past, I personally would not
object the removal of TCI nowadays since the normal TCG backends have
become pretty mature ... but other users of TCI might have a different
opinion here, so let's mark it as deprecated now and remove it next year
(unless somebody speaks up and explains why it should not be removed).

 Thomas

Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [RFC PATCH 0/8] removal of tci (tcg interpreter)
Message-id: 20170629010300.2848-1-f4bug@amsat.org
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
fatal: Cannot update paths and switch to branch 'test' at the same time.
Did you intend to checkout 'origin/patchew/20170629010300.2848-1-f4bug@amsat.org' which can not be resolved as commit?
Traceback (most recent call last):
  File "/home/fam/bin/patchew", line 440, in test_one
    git_clone_repo(clone, r["repo"], r["head"], logf)
  File "/home/fam/bin/patchew", line 53, in git_clone_repo
    cwd=clone)
  File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', 'checkout', 'origin/patchew/20170629010300.2848-1-f4bug@amsat.org', '-b', 'test']' returned non-zero exit status 128



---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

On Thu, 07/06 16:49, no-reply@patchew.org wrote:
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> fatal: Cannot update paths and switch to branch 'test' at the same time.
> Did you intend to checkout 'origin/patchew/20170629010300.2848-1-f4bug@amsat.org' which can not be resolved as commit?
> Traceback (most recent call last):
>   File "/home/fam/bin/patchew", line 440, in test_one
>     git_clone_repo(clone, r["repo"], r["head"], logf)
>   File "/home/fam/bin/patchew", line 53, in git_clone_repo
>     cwd=clone)
>   File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call
>     raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['git', 'checkout', 'origin/patchew/20170629010300.2848-1-f4bug@amsat.org', '-b', 'test']' returned non-zero exit status 128
> 

Ignore this please, patchew is recovering from a bad state.

Am 29.06.2017 um 03:02 schrieb Philippe Mathieu-Daudé:
> There have been some comments on the ML about the usefulness of tci.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04551.html
> 
>   Peter Maydell> I'd prefer we just got rid of it.
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04296.html
> 
>   Richard Henderson> Is it time to remove it? I'm pretty sure the only hosts
>                      for which it will work have proper backends...
> 
> Richard quotes are way clearer than me trying to paraphrase what he told me:
> - it doesn't use libffi, and as such the way it makes calls to helpers doesn't work for many hosts.
> - we already cover almost everthing that debian does. if debian or gentoo doesn't support it, one can confidently say there's little interest.
> - if someone *does* want to run qemu on something else, it isn't difficult to port tcg.
> 
> I figured out MAINTAINERS was unsync, so added patches 1-4, they are not really
> tci-related.
> 
> Patches 5,6 are trivial fixes to let the codebase quite sane if there is future
> need to revert/reimport tci.
> 
> Patches 7,8 are the removal, marked RFC... let's debate!
> 
> Regards,
> 
> Phil.


Hi,

as Peter already has written, there are different perspectives on QEMU.

My conclusion is that depending on those perspectives people come to
different results whether certain code parts are useful or not.

When I started using (and contributing) to QEMU in 2006, I wanted to
analyse code running on an embedded MIPS system. With real hardware
that was impossible, but with QEMU I could watch and debug that code
(as soon as the MIPS emulation was sufficiently good, so that was
my initial motivation).

Later I was responsible for automated software tests. Those tests
included software written for embedded PCs. The only missing components
for an emulation with QEMU were the network cards, so I wrote the
eepro100 (part of official QEMU) and dp8381x (only in my fork)
network hardware emulations.

Later I wanted to build and run QEMU on platforms which were not
implemented. So that was the motivation to write TCI. I also used
TCI to analyse TCG commands with Valgrind. It is for example very
easy to count the frequency of the different TCG opcodes executed
in an emulation run. TCI could also be used to monitor register
usage with minimal code changes. And I still think that it is
the easiest way to build QEMU on a completely new platform
(that should work out of the box) and to make emulation work
there (that might require some efforts).

In my current role I'm interested in the emulation of old computer
systems. Therefore my fork still includes some hardware emulations
which were removed in the official QEMU, and especially emulation
of all generations of the Intel PC platform is important for me.

I am aware that neither of those applications is in the primary
focus of most QEMU developers who want to have a stable, well
performing platform for server virtualisation. My server
qemu.weilnetz.de also uses that technology, so I want that, too.

Nevertheless QEMU is the only software which I know which not
only addresses the needs for server / PC virtualisation, but
also is useful for researchers and scientists, archivists,
learners and teachers or experimenters.

Up to now, I had the impression that QEMU is sufficiently modular
so that the different perspectives and expectations could be
supported without harming each other too much. The only drawback
was additional code (which would not be needed when focussing on
a single perspective) causing additional compilation time
and more (formal, mostly automated) file changes for code clean
ups and API‌ changes.

Cheers
Stefan

On 29 June 2017 at 19:09, Stefan Weil <sw@weilnetz.de> wrote:
> Nevertheless QEMU is the only software which I know which not
> only addresses the needs for server / PC virtualisation, but
> also is useful for researchers and scientists, archivists,
> learners and teachers or experimenters.
>
> Up to now, I had the impression that QEMU is sufficiently modular
> so that the different perspectives and expectations could be
> supported without harming each other too much. The only drawback
> was additional code (which would not be needed when focussing on
> a single perspective) causing additional compilation time
> and more (formal, mostly automated) file changes for code clean
> ups and API‌ changes.

Yes, the whole of TCG demonstrates that we're not purely
trying to be a virtual-machine-usecase-only codebase,
so certainly there is scope for having multiple parts
and uses in QEMU.

I think the part of TCI that makes it stand out as awkward
here is that it is an option that you have to pick at
configure time, and enabling it disables the standard
TCG backend. If it was a runtime option to use the
interpreter rather than the codegen (in the same way that
you can runtime select between KVM and TCG), I think that
would help a lot:
 * reduces the number of build configs we need to test
 * means it's accessible to the bulk of users who use their
   distro's build of QEMU rather than rolling their own
 * less of a beartrap for users who enable the config
   option and then wonder why QEMU is running so slowly
 * opens the possibility of using the interpreter as part
   of mainstream TCG (eg in the cases of "execute one
   insn and throw it away, which might be faster
   interpreted in theory)

TCI is also awkward because it means we don't really know
what the set of platforms we run on is. (For instance I'd
like to fix our configure script which currently uses 'uname'
as a fallback for identifying target CPU and OS, which
is totally wrong for cross-compile. It would be easier to
be sure such a refactor was correct if we knew which
hosts we could possibly run on...)

That to me all adds up to a position where while I don't
care enough to take active steps to remove TCI from QEMU,
I wouldn't be unhappy to see it go if other people strongly
support removal, and if nobody's interested in trying to
fix its problems.

thanks
-- PMM