* Against removing aarch32 kvm host support
@ 2020-04-28 12:38 Lukas Straub
2020-04-28 13:30 ` Marc Zyngier
0 siblings, 1 reply; 5+ messages in thread
From: Lukas Straub @ 2020-04-28 12:38 UTC (permalink / raw)
To: kvmarm; +Cc: kvm, kernel
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
Hello Everyone,
As a preorder of the Pyra handheld, (OMAP5 SoC with 2x cortex-a15 arm cores)
I'm against removing KVM host support for aarch32. I'm probably going to use
this device for more than 5 years and thus the latest lts-kernel is no option
for me.
Regards,
Lukas Straub
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Against removing aarch32 kvm host support
2020-04-28 12:38 Against removing aarch32 kvm host support Lukas Straub
@ 2020-04-28 13:30 ` Marc Zyngier
2020-04-28 14:26 ` Michael Mrozek
0 siblings, 1 reply; 5+ messages in thread
From: Marc Zyngier @ 2020-04-28 13:30 UTC (permalink / raw)
To: Lukas Straub; +Cc: kvmarm, kvm, kernel
Hi Lukas,
Thanks for your email.
On 2020-04-28 13:38, Lukas Straub wrote:
> Hello Everyone,
> As a preorder of the Pyra handheld, (OMAP5 SoC with 2x cortex-a15 arm
> cores)
> I'm against removing KVM host support for aarch32. I'm probably going
> to use
> this device for more than 5 years and thus the latest lts-kernel is no
> option
> for me.
So let me spell it out. You are against the removal of a feature that
you don't
use yet, that you may of may not use on a device that doesn't exist yet,
which
you may or may not still be using by the time 5.4/5.6 aren't supported
anymore.
You don't seem to have the strongest case, I'm afraid.
But nothing is lost! The code is still in the git tree, ou can always
revert
the removal patches and revive the port if you are so inclined. It will
just need
to be stand-alone, and not depend on the arm64 code, which is now
evolving its own
separate way.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Against removing aarch32 kvm host support
2020-04-28 13:30 ` Marc Zyngier
@ 2020-04-28 14:26 ` Michael Mrozek
2020-04-28 16:26 ` Tony Lindgren
2020-04-28 16:39 ` Marc Zyngier
0 siblings, 2 replies; 5+ messages in thread
From: Michael Mrozek @ 2020-04-28 14:26 UTC (permalink / raw)
To: Marc Zyngier, Lukas Straub; +Cc: kvmarm, kvm, kernel
Am Dienstag, den 28.04.2020, 14:30 +0100 schrieb Marc Zyngier:
Hi,
well, the PCBs are currently in production, the cases are already here (coating
is currently being delayed as the company has closed down due to Corona right
now), so the first 500 units would be ready to be shipped in around 2 - 3 months
at latest.
The non-existance problem would therefore be solved then.
So far, AFAIK, the Letux team has tried their best to get as close to possible
to mainline kernel and support as many classic devices (OMAP3 and OMAP4 devices
as well), so removing 32bit support from mainline would surely be a step back
for a lot of older devices as well.
I know we have to accept the decision, but so far, I've known Linux to support
as many older devices as possible as well - removing KVM Host 32bit support
would be a step back here.
Is there a specific reason for that?
Is it too complex to maintain alongside the aarch64 KVM Host?
> Hi Lukas,
>
> Thanks for your email.
>
> On 2020-04-28 13:38, Lukas Straub wrote:
> > Hello Everyone,
> > As a preorder of the Pyra handheld, (OMAP5 SoC with 2x cortex-a15 arm
> > cores)
> > I'm against removing KVM host support for aarch32. I'm probably going
> > to use
> > this device for more than 5 years and thus the latest lts-kernel is no
> > option
> > for me.
>
> So let me spell it out. You are against the removal of a feature that
> you don't
> use yet, that you may of may not use on a device that doesn't exist yet,
> which
> you may or may not still be using by the time 5.4/5.6 aren't supported
> anymore.
> You don't seem to have the strongest case, I'm afraid.
>
> But nothing is lost! The code is still in the git tree, ou can always
> revert
> the removal patches and revive the port if you are so inclined. It will
> just need
> to be stand-alone, and not depend on the arm64 code, which is now
> evolving its own
> separate way.
>
> Cheers,
>
> M.
--
Mit freundlichen Grüßen,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 990 5548
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek@openpandora.org
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Against removing aarch32 kvm host support
2020-04-28 14:26 ` Michael Mrozek
@ 2020-04-28 16:26 ` Tony Lindgren
2020-04-28 16:39 ` Marc Zyngier
1 sibling, 0 replies; 5+ messages in thread
From: Tony Lindgren @ 2020-04-28 16:26 UTC (permalink / raw)
To: Michael Mrozek; +Cc: Marc Zyngier, Lukas Straub, kvmarm, kvm, kernel
* Michael Mrozek <EvilDragon@openpandora.org> [200428 14:27]:
> Am Dienstag, den 28.04.2020, 14:30 +0100 schrieb Marc Zyngier:
> I know we have to accept the decision, but so far, I've known Linux to support
> as many older devices as possible as well - removing KVM Host 32bit support
> would be a step back here.
>
> Is there a specific reason for that?
> Is it too complex to maintain alongside the aarch64 KVM Host?
I don't know the details, but ideally things would be set up
in a way where folks interested in patching 32-bit arm kvm support
can do so without causing issues for 64-bit kvm development.
That being said, I don't know who might be interested in doing
all the work for that. It's unrealistic to expect Marc to do this
work if he's not using it.
Features that are used get more resources, and features that are
less used end up just bitrotting into a broken state in about
six weeks in the Linux kernel :)
Regards,
Tony
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Against removing aarch32 kvm host support
2020-04-28 14:26 ` Michael Mrozek
2020-04-28 16:26 ` Tony Lindgren
@ 2020-04-28 16:39 ` Marc Zyngier
1 sibling, 0 replies; 5+ messages in thread
From: Marc Zyngier @ 2020-04-28 16:39 UTC (permalink / raw)
To: Michael Mrozek; +Cc: Lukas Straub, kvmarm, kvm, kernel
Michael,
On 2020-04-28 15:26, Michael Mrozek wrote:
> Am Dienstag, den 28.04.2020, 14:30 +0100 schrieb Marc Zyngier:
>
> Hi,
>
> well, the PCBs are currently in production, the cases are already here
> (coating
> is currently being delayed as the company has closed down due to Corona
> right
> now), so the first 500 units would be ready to be shipped in around 2 -
> 3 months
> at latest.
>
> The non-existance problem would therefore be solved then.
And then? Are these 500 machines going to be instantly turned into
production KVM
hosts? Over 7 years, we have identified at most *four* users. Four users
over a
few billion 32bit ARM devices running Linux. What are the odds that you
will
actually use KVM in any significant way? None whatsoever.
> So far, AFAIK, the Letux team has tried their best to get as close to
> possible
> to mainline kernel and support as many classic devices (OMAP3 and OMAP4
> devices
> as well), so removing 32bit support from mainline would surely be a
> step back
> for a lot of older devices as well.
Read the above. No users. Which means that KVM/arm is untested and is
just
bit-rotting. It is also incomplete and nobody is interested in putting
the
required effort to help it moving forward. Hell, the whole ARM port is
now
on life support, and you worry about KVM?
> I know we have to accept the decision, but so far, I've known Linux to
> support
> as many older devices as possible as well - removing KVM Host 32bit
> support
> would be a step back here.
Linux is known to support as many *useful* devices and features as
possible.
KVM isn't one of them.
> Is there a specific reason for that?
Please read the threads on the subject.
> Is it too complex to maintain alongside the aarch64 KVM Host?
It certainly gets in the way of making significant changes to the arm64
port.
And as I said, feel free to revive the port anytime. The code is still
there,
the documentation available, and you're lucky enough to have one of the
few
machines capable of virtualization. If all of a sudden you end-up
finding
the killer use case for KVM/arm, I'll applaud its return. In the
meantime,
the arm64 will be able to move at a much faster pace. As it turns out,
it has actual users.
Thanks,
M.
>
>> Hi Lukas,
>>
>> Thanks for your email.
>>
>> On 2020-04-28 13:38, Lukas Straub wrote:
>> > Hello Everyone,
>> > As a preorder of the Pyra handheld, (OMAP5 SoC with 2x cortex-a15 arm
>> > cores)
>> > I'm against removing KVM host support for aarch32. I'm probably going
>> > to use
>> > this device for more than 5 years and thus the latest lts-kernel is no
>> > option
>> > for me.
>>
>> So let me spell it out. You are against the removal of a feature that
>> you don't
>> use yet, that you may of may not use on a device that doesn't exist
>> yet,
>> which
>> you may or may not still be using by the time 5.4/5.6 aren't supported
>> anymore.
>> You don't seem to have the strongest case, I'm afraid.
>>
>> But nothing is lost! The code is still in the git tree, ou can always
>> revert
>> the removal patches and revive the port if you are so inclined. It
>> will
>> just need
>> to be stand-alone, and not depend on the arm64 code, which is now
>> evolving its own
>> separate way.
>>
>> Cheers,
>>
>> M.
> --
> Mit freundlichen Grüßen,
>
> Michael Mrozek
>
> -----------------------
> OpenPandora GmbH
> Geschäftsführer: Michael Mrozek
>
> Schäffbräustr. 11
> 85049 Ingolstadt
> Deutschland
> Tel.: 0841 / 990 5548
> http://www.openpandora.de/
> HRB 4879, Amtsgericht Ingolstadt
> -----------------------
> eMail: mrozek@openpandora.org
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-28 16:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-28 12:38 Against removing aarch32 kvm host support Lukas Straub
2020-04-28 13:30 ` Marc Zyngier
2020-04-28 14:26 ` Michael Mrozek
2020-04-28 16:26 ` Tony Lindgren
2020-04-28 16:39 ` Marc Zyngier
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).