Re: [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues

From: Alexander Graf <agraf@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-stable <qemu-stable@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Patch Tracking" <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues
Date: Tue, 18 Feb 2014 13:51:00 +0100	[thread overview]
Message-ID: <53035734.7050007@suse.de> (raw)
In-Reply-To: <CAFEAcA_8yYcWPR=b0cUTaQMxT=fuCX4+ibgGOzcgbyVCjO_0iw@mail.gmail.com>

On 02/18/2014 01:37 PM, Peter Maydell wrote:
> On 18 February 2014 12:17, Alexander Graf <agraf@suse.de> wrote:
>> On 02/18/2014 12:22 PM, Peter Maydell wrote:
>>> My criteria for ARM in the past has typically been "there's
>>> a new release every three months, anything that got past
>>> the release testing process for release N is sufficiently
>>> non-critical it can just go into release N+1".
>> Unfortunately this doesn't work for distributions. Distros
>> need to maintain a stable branch for the lifetime of a release
>> to ensure that we're reasonably regression free.
>>
>> If you indicate that this doesn't apply to ARM it basically means you admit
>> that ARM systems are not yet ready for "stable" use by customers when they
>> want to use KVM. At least at the point when we agree that customers do want
>> to run on a stable base for virtualization on ARM we need a working -stable
>> system for critical fixes.
> I agree in general that ARM support needs to move from
> its traditional "this is just a dev tool" situation to
> a broader level of support/stability guarantees for KVM.
> (We're not yet guaranteeing cross-version migration,
> for another example there.)

Yup. I think it's reasonably to not declare ARM a "stable" target at the 
current point in time. But I think we agree that we want to change that 
- timeframe wise probably around the release after 2.0 at which point 
hopefully PCI and virtio 1.0 have settled.

> However again we run into the definition of "what's a
> critical fix?". I think if distros need a stable branch
> then they need to be prepared to do the work of sorting
> through what counts as a critical fix that needs to be
> ported to that branch. (For instance, which boards and
> targets do they care about?)

I think this is up for discussion. If I had to declare anything, I 
wouldn't consider anything but the virt machine as supported for example 
- similar to how x86 only really considers the pc machine type stable.

> For instance patch 3 only applies to the integrator
> board, and I don't consider the guest-to-host border
> to be a security boundary for most of our legacy board
> models: there's just too much unaudited device code for
> that to be trustable.

Yes, I fully agree. Traditionally what I've done is to reply to patches 
that I consider stable material and nag the maintainer about CCing it. 
After a while people got so afraid of my emails that they started doing 
the CC themselves :). But in case of the integrator board I personally 
wouldn't bother ;).

Alex