All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Yoshi <takashi@yoshi.email>
To: Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: Anders Berg <anders.berg@lsi.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Quentin Perret <qperret@google.com>,
	Christoffer Dall <Christoffer.Dall@arm.com>,
	James Morse <james.morse@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Date: Sat, 22 Feb 2020 15:40:30 +0100	[thread overview]
Message-ID: <20200222154030.5625fa5f.takashi@yoshi.email> (raw)
In-Reply-To: <20200210141324.21090-1-maz@kernel.org>

Hi

I found this mailing list thread and would like to express my opinion
and dependence on KVM/arm32.

I hope that I'm not too late already.


On Monday, 10.02.2020, 14:13 +0000 Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
> 
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)

I might not be an important user, but I have been for multiple years
and still am a regular user of KVM/arm32 on different devices.

I use KVM on my Tegra K1 Chromebook for app development and have
multiple SBCs at home on which I run VMs on using KVM+libvirt.

Sure, neither of these devices has many resources available, but they
are working fine. I would love to keep them in service since I haven't
found arm64-based replacements that don't require hours upon hours of
tinkering to just get a basic OS installation running with a mainline
kernel.

As an example that they can still be of use in 2020 I'd like to point
out that one of the SBCs is running my DNS resolver, LDAP server,
RSS reader, IRC bouncer, and shared todo list just fine, each in their
separate VM.

> - It is more and more getting in the way of new arm64 developments
> 
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree.

*scream*

> One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is
> perfect.

This assumption is deeply flawed. Most users (including me) are not
subscribed to this mailing list and will never find this thread at all.
I myself stumbled upon this discussion just by chance while I was
browsing the web trying to find something completely unrelated.

I've been using KVM on x86, ppc and arm for many years, yet I never
felt the need to report a bug on the mailing list.
(This is to be interpreted as a compliment to the great work the devs
of KVM have done!)

Just going by the number of bugs reported on a developers mailing list
is not going to paint an accurate picture.

I am convinced that I'm not the only one relying on KVM/arm32 in the
mainline kernel and would ask you to please reconsider keeping arm32 in
the mainline kernel for a few more years until adequate arm64
replacements are available on the market and have gained proper support
in the mainline kernel.

I myself unfortunately do neither have the knowledge nor resources to
help with development in KVM or maintaining a non-mainline kernel.

> But if you depend on KVM/arm being available in mainline, please
> shout.
> 
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
> 
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
> 
> [...]

Thanks for your understanding.

Kind regards

- Yoshi

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Yoshi <takashi@yoshi.email>
To: Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: Anders Berg <anders.berg@lsi.com>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Date: Sat, 22 Feb 2020 15:40:30 +0100	[thread overview]
Message-ID: <20200222154030.5625fa5f.takashi@yoshi.email> (raw)
In-Reply-To: <20200210141324.21090-1-maz@kernel.org>

Hi

I found this mailing list thread and would like to express my opinion
and dependence on KVM/arm32.

I hope that I'm not too late already.


On Monday, 10.02.2020, 14:13 +0000 Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
> 
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)

I might not be an important user, but I have been for multiple years
and still am a regular user of KVM/arm32 on different devices.

I use KVM on my Tegra K1 Chromebook for app development and have
multiple SBCs at home on which I run VMs on using KVM+libvirt.

Sure, neither of these devices has many resources available, but they
are working fine. I would love to keep them in service since I haven't
found arm64-based replacements that don't require hours upon hours of
tinkering to just get a basic OS installation running with a mainline
kernel.

As an example that they can still be of use in 2020 I'd like to point
out that one of the SBCs is running my DNS resolver, LDAP server,
RSS reader, IRC bouncer, and shared todo list just fine, each in their
separate VM.

> - It is more and more getting in the way of new arm64 developments
> 
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree.

*scream*

> One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is
> perfect.

This assumption is deeply flawed. Most users (including me) are not
subscribed to this mailing list and will never find this thread at all.
I myself stumbled upon this discussion just by chance while I was
browsing the web trying to find something completely unrelated.

I've been using KVM on x86, ppc and arm for many years, yet I never
felt the need to report a bug on the mailing list.
(This is to be interpreted as a compliment to the great work the devs
of KVM have done!)

Just going by the number of bugs reported on a developers mailing list
is not going to paint an accurate picture.

I am convinced that I'm not the only one relying on KVM/arm32 in the
mainline kernel and would ask you to please reconsider keeping arm32 in
the mainline kernel for a few more years until adequate arm64
replacements are available on the market and have gained proper support
in the mainline kernel.

I myself unfortunately do neither have the knowledge nor resources to
help with development in KVM or maintaining a non-mainline kernel.

> But if you depend on KVM/arm being available in mainline, please
> shout.
> 
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
> 
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
> 
> [...]

Thanks for your understanding.

Kind regards

- Yoshi
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Yoshi <takashi@yoshi.email>
To: Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: Anders Berg <anders.berg@lsi.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Quentin Perret <qperret@google.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Christoffer Dall <Christoffer.Dall@arm.com>,
	James Morse <james.morse@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Date: Sat, 22 Feb 2020 15:40:30 +0100	[thread overview]
Message-ID: <20200222154030.5625fa5f.takashi@yoshi.email> (raw)
In-Reply-To: <20200210141324.21090-1-maz@kernel.org>

Hi

I found this mailing list thread and would like to express my opinion
and dependence on KVM/arm32.

I hope that I'm not too late already.


On Monday, 10.02.2020, 14:13 +0000 Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
> 
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)

I might not be an important user, but I have been for multiple years
and still am a regular user of KVM/arm32 on different devices.

I use KVM on my Tegra K1 Chromebook for app development and have
multiple SBCs at home on which I run VMs on using KVM+libvirt.

Sure, neither of these devices has many resources available, but they
are working fine. I would love to keep them in service since I haven't
found arm64-based replacements that don't require hours upon hours of
tinkering to just get a basic OS installation running with a mainline
kernel.

As an example that they can still be of use in 2020 I'd like to point
out that one of the SBCs is running my DNS resolver, LDAP server,
RSS reader, IRC bouncer, and shared todo list just fine, each in their
separate VM.

> - It is more and more getting in the way of new arm64 developments
> 
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree.

*scream*

> One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is
> perfect.

This assumption is deeply flawed. Most users (including me) are not
subscribed to this mailing list and will never find this thread at all.
I myself stumbled upon this discussion just by chance while I was
browsing the web trying to find something completely unrelated.

I've been using KVM on x86, ppc and arm for many years, yet I never
felt the need to report a bug on the mailing list.
(This is to be interpreted as a compliment to the great work the devs
of KVM have done!)

Just going by the number of bugs reported on a developers mailing list
is not going to paint an accurate picture.

I am convinced that I'm not the only one relying on KVM/arm32 in the
mainline kernel and would ask you to please reconsider keeping arm32 in
the mainline kernel for a few more years until adequate arm64
replacements are available on the market and have gained proper support
in the mainline kernel.

I myself unfortunately do neither have the knowledge nor resources to
help with development in KVM or maintaining a non-mainline kernel.

> But if you depend on KVM/arm being available in mainline, please
> shout.
> 
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
> 
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
> 
> [...]

Thanks for your understanding.

Kind regards

- Yoshi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-02-22 14:40 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200210141344eucas1p25a6da0b0251931ef3659397a6f34c0c3@eucas1p2.samsung.com>
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
2020-02-10 14:13   ` Marc Zyngier
2020-02-10 14:13   ` Marc Zyngier
2020-02-10 14:13   ` [RFC PATCH 1/5] arm: Unplug KVM from the build system Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13   ` [RFC PATCH 2/5] arm: Remove KVM from config files Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13   ` [RFC PATCH 3/5] arm: Remove 32bit KVM host support Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13   ` [RFC PATCH 4/5] arm: Remove HYP/Stage-2 page-table support Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13   ` [RFC PATCH 5/5] arm: Remove GICv3 vgic compatibility macros Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 14:13     ` Marc Zyngier
2020-02-10 15:21   ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Olof Johansson
2020-02-10 15:21     ` Olof Johansson
2020-02-10 15:21     ` Olof Johansson
2020-02-10 15:54     ` Arnd Bergmann
2020-02-10 15:54       ` Arnd Bergmann
2020-02-10 15:54       ` Arnd Bergmann
2020-02-10 15:46   ` Will Deacon
2020-02-10 15:46     ` Will Deacon
2020-02-10 15:46     ` Will Deacon
2020-02-10 16:25   ` Russell King - ARM Linux admin
2020-02-10 16:25     ` Russell King - ARM Linux admin
2020-02-10 16:25     ` Russell King - ARM Linux admin
2020-02-10 16:26     ` Russell King - ARM Linux admin
2020-02-10 16:26       ` Russell King - ARM Linux admin
2020-02-10 16:26       ` Russell King - ARM Linux admin
2020-02-11 15:12   ` Vladimir Murzin
2020-02-11 15:12     ` Vladimir Murzin
2020-02-11 15:12     ` Vladimir Murzin
2020-02-11 15:23   ` Catalin Marinas
2020-02-11 15:23     ` Catalin Marinas
2020-02-11 15:23     ` Catalin Marinas
2020-02-17  0:14   ` Linus Walleij
2020-02-17  0:14     ` Linus Walleij
2020-02-17  0:14     ` Linus Walleij
2020-02-19 13:53   ` Stefan Agner
2020-02-19 13:53     ` Stefan Agner
2020-02-19 13:53     ` Stefan Agner
2020-02-20 11:01     ` Marc Zyngier
2020-02-20 11:01       ` Marc Zyngier
2020-02-20 11:01       ` Marc Zyngier
2020-02-19 14:56   ` Christoffer Dall
2020-02-19 14:56     ` Christoffer Dall
2020-02-19 14:56     ` Christoffer Dall
2020-02-19 15:09   ` Arnd Bergmann
2020-02-19 15:09     ` Arnd Bergmann
2020-02-19 15:09     ` Arnd Bergmann
2020-02-19 15:46     ` Jan Kiszka
2020-02-19 15:46       ` Jan Kiszka
2020-02-19 15:46       ` Jan Kiszka
2020-02-20 10:29       ` Marc Zyngier
2020-02-20 10:29         ` Marc Zyngier
2020-02-20 10:29         ` Marc Zyngier
2020-02-20 12:44   ` Marek Szyprowski
2020-02-20 12:44     ` Marek Szyprowski
2020-02-20 12:44     ` Marek Szyprowski
2020-02-20 13:15     ` Marc Zyngier
2020-02-20 13:15       ` Marc Zyngier
2020-02-20 13:15       ` Marc Zyngier
2020-02-20 13:17       ` Paolo Bonzini
2020-02-20 13:17         ` Paolo Bonzini
2020-02-20 13:17         ` Paolo Bonzini
2020-02-20 13:32       ` Robin Murphy
2020-02-20 13:32         ` Robin Murphy
2020-02-20 13:32         ` Robin Murphy
2020-02-20 14:01         ` Marc Zyngier
2020-02-20 14:01           ` Marc Zyngier
2020-02-20 14:01           ` Marc Zyngier
2020-02-20 14:38           ` Robin Murphy
2020-02-20 14:38             ` Robin Murphy
2020-02-20 14:38             ` Robin Murphy
2020-02-22 14:21   ` Takashi Yoshi
2020-02-22 14:21     ` Takashi Yoshi
2020-02-22 14:40   ` Takashi Yoshi [this message]
2020-02-22 14:40     ` Takashi Yoshi
2020-02-22 14:40     ` Takashi Yoshi
2020-02-22 21:31     ` Arnd Bergmann
2020-02-22 21:31       ` Arnd Bergmann
2020-02-22 21:31       ` Arnd Bergmann
2020-02-25 21:34       ` Takashi Yoshi
2020-02-25 21:34         ` Takashi Yoshi
2020-02-25 21:34         ` Takashi Yoshi
     [not found] <mailman.29637.1581344013.2486.linux-arm-kernel@lists.infradead.org>
2020-02-18 21:37 ` Daniel Golle
2020-02-19  8:31   ` Marc Zyngier
     [not found]     ` <CGME20200220130838eucas1p12bc652ecd882204a8ffda5ed28f48bd5@eucas1p1.samsung.com>
2020-02-20 13:08       ` Bartlomiej Zolnierkiewicz
2020-02-20 13:39         ` Marc Zyngier

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=20200222154030.5625fa5f.takashi@yoshi.email \
    --to=takashi@yoshi.email \
    --cc=Christoffer.Dall@arm.com \
    --cc=anders.berg@lsi.com \
    --cc=arnd@arndb.de \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vladimir.murzin@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.