All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
Date: Mon, 19 Sep 2016 13:41:38 +0200	[thread overview]
Message-ID: <20160919114138.GA15852@cbox> (raw)
In-Reply-To: <43020f1f-6367-6f11-2534-b26ced13b540@suse.de>

On Mon, Sep 19, 2016 at 12:51:46PM +0200, Alexander Graf wrote:
> 
> 
> On 16.09.16 15:30, Christoffer Dall wrote:

[...]

> > 
> > That being said, I'm not categorically against these patches, but I
> > share Marc's view that we've already seen that non-vgic support had been
> > broken for multiple versions without anyone complaining, and without
> > automated testing or substantial interest in the work, the patches
> > really are likely to bit-rot.
> 
> I know that it's very hard to grasp from an upstream maintainer
> perspective, 

pfff

> but keep in mind where the bulk of execution of kernel code
> lies. The average life cycle of a "stable" Linux distribution's kernel
> is a few years.
> 
> So far all regressions in the user space gic code have been found within
> less than 1y of the respective code release. I'd say that counts for
> quite a well used feature.
> 

The only report I can think of about this was Pavel using an upstream
kernel for in-house Samsung development on non-public hardware.

But, again, I didn't look at the patches in detail yet, I'm not
categorically against them, I will take a careful look at them like I do
with all patches on the kvmarm list.  There's a risk they'll break in
mainline unless we sort out our testing story, and it may just be
something we'll have to live with.

> > But I haven't even looked at the patches in detail, I was just replying
> > to the comment about testing.
> 
> Also keep in mind that without the architected timer support (and/or
> without qemu patches than enable user space timers) the user space gic
> support is pretty unusable to most people, so you obviously get less
> reports.
>

I don't disagree with this.  I don't know what this has to do with the
part of my mail you're replying to, but I completely agree that the
current userspace irqchip support has limited value.

-Christoffer

WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
Date: Mon, 19 Sep 2016 13:41:38 +0200	[thread overview]
Message-ID: <20160919114138.GA15852@cbox> (raw)
In-Reply-To: <43020f1f-6367-6f11-2534-b26ced13b540@suse.de>

On Mon, Sep 19, 2016 at 12:51:46PM +0200, Alexander Graf wrote:
> 
> 
> On 16.09.16 15:30, Christoffer Dall wrote:

[...]

> > 
> > That being said, I'm not categorically against these patches, but I
> > share Marc's view that we've already seen that non-vgic support had been
> > broken for multiple versions without anyone complaining, and without
> > automated testing or substantial interest in the work, the patches
> > really are likely to bit-rot.
> 
> I know that it's very hard to grasp from an upstream maintainer
> perspective, 

pfff

> but keep in mind where the bulk of execution of kernel code
> lies. The average life cycle of a "stable" Linux distribution's kernel
> is a few years.
> 
> So far all regressions in the user space gic code have been found within
> less than 1y of the respective code release. I'd say that counts for
> quite a well used feature.
> 

The only report I can think of about this was Pavel using an upstream
kernel for in-house Samsung development on non-public hardware.

But, again, I didn't look at the patches in detail yet, I'm not
categorically against them, I will take a careful look at them like I do
with all patches on the kvmarm list.  There's a risk they'll break in
mainline unless we sort out our testing story, and it may just be
something we'll have to live with.

> > But I haven't even looked at the patches in detail, I was just replying
> > to the comment about testing.
> 
> Also keep in mind that without the architected timer support (and/or
> without qemu patches than enable user space timers) the user space gic
> support is pretty unusable to most people, so you obviously get less
> reports.
>

I don't disagree with this.  I don't know what this has to do with the
part of my mail you're replying to, but I completely agree that the
current userspace irqchip support has limited value.

-Christoffer

  reply	other threads:[~2016-09-19 11:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16  6:26 [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic Alexander Graf
2016-09-16  6:26 ` Alexander Graf
2016-09-16  6:26 ` [PATCH v3 1/2] KVM: arm/arm64: Add vcpu ENABLE_CAP functionality Alexander Graf
2016-09-16  6:26   ` Alexander Graf
2016-09-16  6:26 ` [PATCH v3 2/2] KVM: arm/arm64: Route vtimer events to user space Alexander Graf
2016-09-16  6:26   ` Alexander Graf
2016-09-16  9:11   ` Peter Maydell
2016-09-16  9:11     ` Peter Maydell
2016-09-16  9:18     ` Alexander Graf
2016-09-16  9:18       ` Alexander Graf
2016-09-16 10:20 ` [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic Marc Zyngier
2016-09-16 10:20   ` Marc Zyngier
2016-09-16 12:18   ` Paolo Bonzini
2016-09-16 12:18     ` Paolo Bonzini
2016-09-16 12:30     ` Christoffer Dall
2016-09-16 12:30       ` Christoffer Dall
2016-09-16 12:31       ` Paolo Bonzini
2016-09-16 12:31         ` Paolo Bonzini
2016-09-16 13:30         ` Christoffer Dall
2016-09-16 13:30           ` Christoffer Dall
2016-09-16 13:46           ` Andrew Jones
2016-09-16 13:46             ` Andrew Jones
2016-09-16 15:45             ` Paolo Bonzini
2016-09-16 15:45               ` Paolo Bonzini
2016-09-16 19:36             ` Alexander Graf
2016-09-16 19:36               ` Alexander Graf
2016-09-19  7:52               ` Andrew Jones
2016-09-19  7:52                 ` Andrew Jones
2016-09-19 11:45                 ` Alexander Graf
2016-09-19 11:45                   ` Alexander Graf
2016-09-16 13:50           ` Gerd Hoffmann
2016-09-16 13:50             ` Gerd Hoffmann
2016-09-19 10:51           ` Alexander Graf
2016-09-19 10:51             ` Alexander Graf
2016-09-19 11:41             ` Christoffer Dall [this message]
2016-09-19 11:41               ` Christoffer Dall
2016-09-16 12:25   ` Alexander Graf
2016-09-16 12:25     ` Alexander Graf
2016-09-16 12:29     ` Christoffer Dall
2016-09-16 12:29       ` Christoffer Dall
2016-09-16 12:40       ` Paolo Bonzini
2016-09-16 12:40         ` Paolo Bonzini
2016-09-16 12:44         ` Alexander Graf
2016-09-16 12:44           ` Alexander Graf
2016-09-16 12:54           ` Paolo Bonzini
2016-09-16 12:54             ` Paolo Bonzini
2016-09-17 15:28           ` Ard Biesheuvel
2016-09-17 15:28             ` Ard Biesheuvel
2016-09-17 15:38             ` Peter Maydell
2016-09-17 15:38               ` Peter Maydell
2016-09-17 16:47               ` Ard Biesheuvel
2016-09-17 16:47                 ` Ard Biesheuvel
2016-09-16 12:43       ` Alexander Graf
2016-09-16 12:43         ` Alexander Graf

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=20160919114138.GA15852@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=pbonzini@redhat.com \
    /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.