All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Tiejun Chen <tiejun.chen@intel.com>
Cc: Kevin <kevin.tian@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Yong Y Wang <yong.y.wang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Requesting for freeze exception for RMRR
Date: Fri, 17 Jul 2015 16:11:25 +0100	[thread overview]
Message-ID: <55A91B1D.1050406@citrix.com> (raw)
In-Reply-To: <20150717140157.GM12455@zion.uk.xensource.com>

On 17/07/15 15:01, Wei Liu wrote:
> On Fri, Jul 17, 2015 at 02:43:05PM +0100, Jan Beulich wrote:
>>>>> On 17.07.15 at 15:21, <wei.liu2@citrix.com> wrote:
>>> The major concern seems to be around the PCI allocation algorithm. Jan
>>> has different opinion from George. George provided a simple solution
>>> that will not make things worse than before, while Jan prefers to get
>>> everything right.
>>>
>>> To be fair, the PCI allocation code in a bad state is not really
>>> contributor's fault.
>>>
>>> Jan also pointed out on IRC he thinks the proper logic he asked for is
>>> not very hard to implement.
>>>
>>> Given we either take George's route, which already seems to have a
>>> patch, or Jan's route, which he thinks shouldn't be too hard to
>>> implement, I'm inclined to say give this series another week (24th
>>> deadline still applied). Note that we've been working on this for ages,
>>> any delay is going to burn up more energy than necessary.
>>>
>>> Jan and George, if you disagree with what I say above, please reply.
>> My main disagreement here continues to be that we're talking
>> about a bug fix, and hence I don't view this as needing a freeze
>> exception in the first place (at least not at this point in time). Yes,
>> the bug fix involves adding code that looks like a new feature, but
>> that happens with bug fixes.
>>
> Fine then. I'm not going to argue feature vs bug fix at this stage.  The
> final resolution is still the same. Tiejun can continue working on this
> next week.

Sorry for being slow in my maintainership role with this series.  (I
have been busy with the migration v2 side of things).

I can appreciate Wei's position that, despite this being a bugfix, it
does exhibit itself as a new feature, and we don't want to be merging a
new feature beyond the hard feature freeze point.

The PCI allocation code is in a state, but it was in a similarly bad
state before.  I agree with Jan's point of the risk that these new
changes cause a regression in booting guests, although we can mitigate
that somewhat by testing.

I feel at this point that we shouldn't block the RMRR bugfix on also
fixing the PCI allocation algorithm (which was a pre-existing issue).

Therefore, I recommend that v9 gets respun to v10 to address the current
comments, and accepted.  Afterwards, the PCI allocation algorithm gets
worked on as a bugfix activity, to pro actively cater for the risk of
regression.

~Andrew

  parent reply	other threads:[~2015-07-17 15:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13  6:31 Requesting for freeze exception for RMRR Chen, Tiejun
2015-07-13  8:11 ` Jan Beulich
2015-07-13 11:41 ` Wei Liu
2015-07-14  1:27   ` Chen, Tiejun
2015-07-14  9:29     ` Wei Liu
2015-07-17  1:16       ` Chen, Tiejun
2015-07-17  9:17         ` Wei Liu
2015-07-17  9:24           ` Chen, Tiejun
2015-07-17  9:30             ` Wei Liu
2015-07-17 13:21               ` Wei Liu
2015-07-17 13:43                 ` Jan Beulich
2015-07-17 14:01                   ` Wei Liu
2015-07-17 14:33                     ` Chen, Tiejun
2015-07-17 15:11                     ` Andrew Cooper [this message]
2015-07-17 15:26                       ` Chen, Tiejun
2015-07-17 15:32                         ` Wei Liu
2015-07-17 15:37                           ` Chen, Tiejun
2015-07-20  1:14                       ` Tian, Kevin
2015-07-13 13:38 ` Jan Beulich
2015-07-14  0:26   ` Chen, Tiejun
2015-07-14  9:18     ` Jan Beulich
2015-07-14  9:25       ` Ian Campbell
2015-07-14  9:36         ` Jan Beulich
2015-07-14  9:27       ` Chen, Tiejun
2015-07-14  9:38         ` Jan Beulich

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=55A91B1D.1050406@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=kevin.tian@intel.com \
    --cc=tiejun.chen@intel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yong.y.wang@intel.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.