All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Xen 4.4 development update: Is PVH a blocker?
Date: Tue, 17 Dec 2013 14:13:30 +0000	[thread overview]
Message-ID: <52B05C0A.4040404@eu.citrix.com> (raw)
In-Reply-To: <20131217115805.GD32721@deinos.phlegethon.org>

On 12/17/2013 11:58 AM, Tim Deegan wrote:
> At 08:47 +0000 on 16 Dec (1387180027), Jan Beulich wrote:
>>>>> On 13.12.13 at 20:21, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>>>   http://wiki.xen.org/wiki/Xen_Roadmap/4.4
>>>
>>> Our timeline had us start the code freeze last Friday.  However, we
>>> have not released an RC0 because we have been waiting for PVH dom0
>>> support.  Adding bug fixes during RCs makes sense, but RC0 should
>>> contain all of the functionality we expect to be in the final release.
>>>
>>> PVH dom0 support is making progress, however it's not that clear when
>>> it will actually be ready to be checked in.  The current discussion is
>>> about refcounting the new p2m type, which is a tricky and delicate
>>> operation (though luckily one which should be limited to domains which
>>> use that type -- at the moment, exclusively PVH dom0s).
>>>
>>> If we continue to wait, it is likely that the release will slip.  The
>>> question
>>> then is, how long should we continue to wait before we cut our losses and
>>> say we'll wait for PVH dom0 until 4.5?
>>
>> Even if likely unpopular, given the condition the one critical patch
>> is in I'd favor not waiting any longer at all, deferring the feature
>> to 4.5 and cutting RC1 e.g. based on what got pushed over the
>> weekend.
>
> +1.  The remeining changes that I'm aware of touch non-pvh code and
> refcounting code, neither of which seems like a good idea at this
> point, even if they were complete.

Right -- I think we're going to have to go ahead without it then.

FWIW I was always expecting dom0 PVH not to make it; it was Jan who 
first suggested making it a blocker.  But I think that was before we 
realized how tricky the p2m stuff was going to be.

I haven't taken a close look at the patches, but browsing the 
conversation, it seems like waiting is the best option.  For refcounting 
in particular, we don't want to rush things.  Bugs are subtle and may 
not manifest for quite a while.  It would be better to check this in at 
the beginning of a release cycle and we had the full time to shake 
things out.

  -George

      reply	other threads:[~2013-12-17 14:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13 19:21 Xen 4.4 development update: Is PVH a blocker? George Dunlap
2013-12-13 19:39 ` Konrad Rzeszutek Wilk
2013-12-13 20:55   ` Sander Eikelenboom
2013-12-16 15:09     ` Konrad Rzeszutek Wilk
2013-12-16 17:24       ` Sander Eikelenboom
2013-12-16 17:46         ` Konrad Rzeszutek Wilk
2013-12-16 17:59           ` Sander Eikelenboom
2013-12-16 19:34             ` Konrad Rzeszutek Wilk
2013-12-16 19:46               ` Sander Eikelenboom
2013-12-17 14:35                 ` Konrad Rzeszutek Wilk
2013-12-17 15:03                   ` Sander Eikelenboom
2013-12-17 21:35                     ` Konrad Rzeszutek Wilk
2013-12-17 21:52                       ` Sander Eikelenboom
2013-12-17 15:04               ` Anthony Liguori
2013-12-17 15:18                 ` Konrad Rzeszutek Wilk
2013-12-16 10:51   ` Ian Campbell
2013-12-16 15:12     ` Konrad Rzeszutek Wilk
2013-12-16 15:24       ` Konrad Rzeszutek Wilk
2013-12-16 15:43       ` Ian Campbell
2013-12-13 19:43 ` Konrad Rzeszutek Wilk
2013-12-16 10:50   ` George Dunlap
2013-12-16 10:54   ` Ian Campbell
2013-12-16 15:10     ` Konrad Rzeszutek Wilk
2013-12-19 14:06   ` Ian Campbell
2013-12-19 14:15     ` Processed: " xen
2013-12-16  8:47 ` Jan Beulich
2013-12-16 23:45   ` Mukesh Rathor
2013-12-17  8:25     ` Jan Beulich
2013-12-17 11:58   ` Tim Deegan
2013-12-17 14:13     ` George Dunlap [this message]

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=52B05C0A.4040404@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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.