From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 0/6] x86/HVM: RTC/VPT adjustments Date: Thu, 2 May 2013 10:23:21 +0100 Message-ID: <51823089.8060900@eu.citrix.com> References: <517E94E602000078000D1AE7@nat28.tlf.novell.com> <51813FBF.5010105@eu.citrix.com> <51822AA102000078000D26E9@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51822AA102000078000D26E9@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , "Tim (Xen.org)" , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 02/05/13 07:58, Jan Beulich wrote: >>>> On 01.05.13 at 18:15, George Dunlap 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 >> 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