Re: [Xen-devel] [PATCH 0/6] x86/HVM: RTC/VPT adjustments

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.05.13 at 11:23, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 02/05/13 07:58, Jan Beulich wrote:
>>>>> On 01.05.13 at 18:15, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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@xxxxxxxx>
>>> 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.

I continue to think so, but Tim quite obviously has a different
opinion.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel