qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2014-02-18 12:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 14:37 [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 1/3] hw/misc/arm_sysctl: Fix bad boundary check on mb clock accesses Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 2/3] hw/net/stellaris_enet: Avoid unintended sign extension Peter Maydell
2014-02-17 14:37 ` [Qemu-devel] [PATCH 3/3] hw/timer/arm_timer: Avoid array overrun for bad addresses Peter Maydell
2014-02-17 18:59 ` [Qemu-devel] [PATCH 0/3] ARM: three easy patches for coverity-reported issues Paolo Bonzini
2014-02-18  1:02   ` Andreas Färber
2014-02-18  9:46     ` Peter Maydell
2014-02-18 10:13       ` Andreas Färber
2014-02-18 11:09         ` Peter Maydell
2014-02-18 11:16           ` Paolo Bonzini
2014-02-18 11:22             ` Peter Maydell
2014-02-18 11:23               ` Paolo Bonzini
2014-02-18 12:17               ` Alexander Graf
2014-02-18 12:37                 ` Peter Maydell
2014-02-18 12:51                   ` Alexander Graf [this message]
2014-02-18 12:53                     ` Andreas Färber
2014-02-18 12:56                       ` Alexander Graf
2014-02-18 12:44             ` Andreas Färber
2014-02-18 13:05               ` Peter Maydell
2014-02-18 13:53               ` Paolo Bonzini
2014-02-21  7:24                 ` [Qemu-devel] [Qemu-stable] " Michael Roth
2014-02-21 10:43                   ` Paolo Bonzini
2014-02-24 15:41 ` [Qemu-devel] " Peter Maydell

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=53035734.7050007@suse.de \
    --to=agraf@suse.de \
    --cc=afaerber@suse.de \
    --cc=patches@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.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 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).