Re: [Qemu-devel] Obsolete QEMU host environments

[Aurelien Jarno]

On 2017-03-15 07:09, Richard Henderson wrote:
> On 03/15/2017 03:07 AM, Peter Maydell wrote:
> > On 14 March 2017 at 17:54, Thomas Huth  wrote:
> > > Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
> > > ... so it's maybe not as dead as you think? Or should we rather get rid
> > > of that soon, too?
> > 
> > I don't actually mind whether we keep tcg/ia64 or drop it.
> > But if we keep it then we must have a machine we can test
> > it on -- that means one I have access to (and which we
> > can otherwise use for central testing), not just one the
> > maintainer might happen to have.
> > 
> > Also, that MAINTAINERS entry was added in 2011, so it's
> > probably about as out of date as the code :-)
> 
> Red Hat's last ia64 machine died a few years ago, so I haven't
> been able to test it for quite some time.
> 
> I don't know if Aurelien can still test on ia64 or not.

I have the same issue, the last QEMU test I have been able to do on an
ia64 machine dates from last summer, so something like 9 months ago. I
don't think anybody has a lot of interest in ia64 anymore, so I guess
it's time to just remove the ia64 host backend.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] Obsolete QEMU host environments

[Thomas Huth]

On 15.03.2017 10:40, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 07:09:55AM +1000, Richard Henderson wrote:
>> On 03/15/2017 03:07 AM, Peter Maydell wrote:
>>> On 14 March 2017 at 17:54, Thomas Huth  wrote:
 Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
 ... so it's maybe not as dead as you think? Or should we rather get rid
 of that soon, too?
>>>
>>> I don't actually mind whether we keep tcg/ia64 or drop it.
>>> But if we keep it then we must have a machine we can test
>>> it on -- that means one I have access to (and which we
>>> can otherwise use for central testing), not just one the
>>> maintainer might happen to have.
>>>
>>> Also, that MAINTAINERS entry was added in 2011, so it's
>>> probably about as out of date as the code :-)
>>
>> Red Hat's last ia64 machine died a few years ago, so I haven't
>> been able to test it for quite some time.
> 
> AFAIK, HP are the only major vendor who still sell new ia64 machines and
> that's high end stuff costing many $. Even they are pushing people to
> x86_64 unless they need ia64 for legacy reasons. Otherwise ebay and other
> secondhand marketplaces are the only way to get hold of ia64.

Unless Aurelien speaks up and says that it is still maintained, I'd say
we add a big fat "ia is deprecated and going to be removed" warning to
the configure script once we left the freeze state. If nobody then
speaks up within the next two or three releases of QEMU, we remove the
ia64 support from QEMU.

 Thomas

Re: [Qemu-devel] Obsolete QEMU host environments

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 07:09:55AM +1000, Richard Henderson wrote:
> On 03/15/2017 03:07 AM, Peter Maydell wrote:
> > On 14 March 2017 at 17:54, Thomas Huth  wrote:
> > > Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
> > > ... so it's maybe not as dead as you think? Or should we rather get rid
> > > of that soon, too?
> > 
> > I don't actually mind whether we keep tcg/ia64 or drop it.
> > But if we keep it then we must have a machine we can test
> > it on -- that means one I have access to (and which we
> > can otherwise use for central testing), not just one the
> > maintainer might happen to have.
> > 
> > Also, that MAINTAINERS entry was added in 2011, so it's
> > probably about as out of date as the code :-)
> 
> Red Hat's last ia64 machine died a few years ago, so I haven't
> been able to test it for quite some time.

AFAIK, HP are the only major vendor who still sell new ia64 machines and
that's high end stuff costing many $. Even they are pushing people to
x86_64 unless they need ia64 for legacy reasons. Otherwise ebay and other
secondhand marketplaces are the only way to get hold of ia64.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Obsolete QEMU host environments

[Richard Henderson]

On 03/15/2017 03:07 AM, Peter Maydell wrote:

On 14 March 2017 at 17:54, Thomas Huth  wrote:

Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
... so it's maybe not as dead as you think? Or should we rather get rid
of that soon, too?


I don't actually mind whether we keep tcg/ia64 or drop it.
But if we keep it then we must have a machine we can test
it on -- that means one I have access to (and which we
can otherwise use for central testing), not just one the
maintainer might happen to have.

Also, that MAINTAINERS entry was added in 2011, so it's
probably about as out of date as the code :-)


Red Hat's last ia64 machine died a few years ago, so I haven't
been able to test it for quite some time.

I don't know if Aurelien can still test on ia64 or not.


r~

Re: [Qemu-devel] Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14)

[Peter Maydell]

On 14 March 2017 at 17:54, Thomas Huth  wrote:
> Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
> ... so it's maybe not as dead as you think? Or should we rather get rid
> of that soon, too?

I don't actually mind whether we keep tcg/ia64 or drop it.
But if we keep it then we must have a machine we can test
it on -- that means one I have access to (and which we
can otherwise use for central testing), not just one the
maintainer might happen to have.

Also, that MAINTAINERS entry was added in 2011, so it's
probably about as out of date as the code :-)

thanks
-- PMM

[Qemu-devel] Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14)

[Thomas Huth]

On 14.03.2017 17:20, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 04:01:14PM +, Dr. David Alan Gilbert wrote:
>> * Juan Quintela (quint...@redhat.com) wrote:
>>> Peter Maydell  wrote:
 On 14 March 2017 at 09:13, Stefan Hajnoczi  wrote:
> On Mon, Mar 13, 2017 at 11:02:01AM +0100, Peter Maydell wrote:
> The minimum requirements for the new language:
> 1. Does it support the host operating systems that QEMU runs on?
> 2. Does it support the host architectures that QEMU runs on?

 Speaking of this, I was thinking that we should introduce
 a rule that for any host OS/arch we support we must have
 a build machine so we can at least do a compile test.
 For instance if you believe configure we support Solaris
 and AIX, but I bet they're bit-rotting. The ia64 backend
 has to be a strong candidate for being dumped too.
 Demanding "system we can test on or we drop support"
 would let us more clearly see what we're actually running
 on and avoid unnecessarily ruling things out because they
 don't support Itanium or AIX...
>>>
>>> YES, YES and YES.
>>>
>>> I demand an osX build machine NOW  Remote access is ok.
>>>
>>> Now more seriously, I can (relatively easy) compile test my pull
>>> requests with:
>>> - linux x86 (latest fedora, but I can get an older one if needed)
>>> - linux x86_64 (latest fedor,, but the same)
>>> - mingw64 32bit (latest fedora, but here I have the problem that Peter
>>>   uses a different crosscompiler than me)
>>> - mingw64 32bit (the same)
>>>
>>> But for the rest, I need to wait that somebody told me that it breaks
>>> the build.  Normally it is things like size_t is 32bit instead of 64bit
>>> or some stupid things like that, that are trivial to fix if I can
>>> compile there before doing the pull submission.
>>
>> I also do a FreeBSD VM, and grab an aarch64 and/or PPC bigendian host
>> to test on.
>>
>> (I could grab an ia64 host, but I don't think I could find anything
>> to install on it that would be new enough for the rest of our build
>> requirements).
> 
> Indeed, ia64 is a fully dead as a host architecture at this point, only
> interesting as a historical curiosity. Paolo already killed ia64 KVM
> host support in Linux git back in 2014.

Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained
... so it's maybe not as dead as you think? Or should we rather get rid
of that soon, too?

 Thomas