[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.