All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>,
	"Tim (Xen.org)" <tim@xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 0/6] x86/HVM: RTC/VPT adjustments
Date: Thu, 2 May 2013 10:23:21 +0100	[thread overview]
Message-ID: <51823089.8060900@eu.citrix.com> (raw)
In-Reply-To: <51822AA102000078000D26E9@nat28.tlf.novell.com>

On 02/05/13 07:58, Jan Beulich wrote:
>>>> On 01.05.13 at 18:15, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 29/04/13 14:42, Jan Beulich wrote:
>>> 1: fix processing of RTC REG_B writes
>>> 2: slightly adjust RTC reset
>>> 3: adjust IRQ (de-)assertion
>>> 4: properly handle RTC periodic timer even when !RTC_PIE
>>> 5: fix legacy PIC check in pt_update_irq()
>>> 6: RTC code must be in line with WAET flags passed by hvmloader
>>>
>>> This fixes the Win2003 boot failure George reported. Roger, since
>>> the first patch is slightly different from what you tested earlier,
>>> could you re-test that patch alone and the full series against
>>> FreeBSD?
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> This series seems to fix the w2k3 issue -- but it looks like a series of
>> "fixes and updates".  I thought we had decided to revert all the RTC
>> changes?
> I always said I'd prefer a partial revert over a full one, if at all
> possible. Of course I'm not intending to enforce this in any way,
> but I'm also not intending to myself revert good fixes (and drop
> further ones, as presented in this series) without need. So my
> proposed solution is this series of patches (which is a partial
> revert in terms of functionality, but not any kind of revert in terms
> of source code) - others can certainly propose other solutions.
> This is even more so now that we know that the reason for the
> observed regression weren't the RTC changes themselves, but
> the expectation of non-spec-conforming emulation behavior by
> the guest.

OK -- well I'll leave it to you and Tim to judge; just let me remind you 
of our primary goals at this point (in order of importance):

1. A bug-free 4.3 release
2. An awesome 4.3 release
3. An on-time 4.3 release

And that for #1, in particular we're worried about bugs that that may 
not be detected until after the release.

If you think this series optimizes those goals from a risk / benefits 
perspective, then I'm OK with it.

  -George

  reply	other threads:[~2013-05-02  9:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-29 13:42 [PATCH 0/6] x86/HVM: RTC/VPT adjustments Jan Beulich
2013-04-29 13:51 ` [PATCH 1/6] x86/HVM: fix processing of RTC REG_B writes Jan Beulich
2013-05-02  8:07   ` Roger Pau Monné
2013-05-02  9:21   ` Tim Deegan
2013-05-02  9:40     ` Jan Beulich
2013-05-02  9:48       ` Tim Deegan
2013-04-29 13:52 ` [PATCH 2/6] x86/HVM: slightly adjust RTC reset Jan Beulich
2013-05-02  9:27   ` Tim Deegan
2013-05-02  9:51     ` Jan Beulich
2013-05-02 10:05       ` Tim Deegan
2013-04-29 13:53 ` [PATCH 3/6] x86/HVM: adjust IRQ (de-)assertion Jan Beulich
2013-05-02  9:34   ` Tim Deegan
2013-05-02  9:54     ` Jan Beulich
2013-04-29 13:53 ` [PATCH 4/6] x86/HVM: properly handle RTC periodic timer even when !RTC_PIE Jan Beulich
2013-05-02  9:41   ` Tim Deegan
2013-05-02 10:02     ` Jan Beulich
2013-04-29 13:54 ` [PATCH 5/6] x86/HVM: fix legacy PIC check in pt_update_irq() Jan Beulich
2013-05-02  9:46   ` Tim Deegan
2013-04-29 13:56 ` [PATCH 6/6] x86/HVM: RTC code must be in line with WAET flags passed by hvmloader Jan Beulich
2013-05-01 16:15 ` [PATCH 0/6] x86/HVM: RTC/VPT adjustments George Dunlap
2013-05-02  6:58   ` Jan Beulich
2013-05-02  9:23     ` George Dunlap [this message]
2013-05-02  9:53       ` Tim Deegan
2013-05-02 10:03       ` Jan Beulich
2013-05-02  8:15 ` Roger Pau Monné
2013-05-02  8:50   ` 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=51823089.8060900@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.