Re: [Xen-devel] Bug: Windows 2003 fails to install on xen-unstable tip

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.04.13 at 16:21, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 23/04/13 14:00, Jan Beulich wrote:
>>>>> On 23.04.13 at 13:52, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>> On 23/04/13 12:33, Jan Beulich wrote:
>> Just went through that change again: The only thing that changes
>> is that while rtc_periodic_cb() (simply setting REG_C flags) got
>> called at the end of pt_intr_post(), rtc_periodic_interrupt() now
>> gets called from pt_update_irq(), and therefore takes care of
>> asserting the IRQ itself (which originally happened inside
>> pt_update_irq()) along with setting REG_C flags. Bottom line -
>> all the patch changes is when exactly REG_PF (and possibly
>> REG_IRQF) get set, and whether the IRQ actually gets asserted.
> 
> So that last bit seems to do these things:
> a. Changes when the handling happens in the Xen interrupt handler
> b. Causes assert/deassert to only happen if !(C.PF) && (B.PIE)
>    (Before it happened unconditionally)
> c. Causes C.IRQF=1 only if (same condition above)
>   (Before it happened unconditionally)
> d. Runs destroy_periodic_timer() if C.PF already
> 
> So just to figure out what it was that w2k3 wanted, I tried a bunch of 
> variations:
> 
> * All of above
>   BAD
> * a only; always assert/deassert + set C.IRQF
>   GOOD
> * always assert/deassert, but leave destroy_periodic_timer and IRQF 
> setting alone
>   FAIL
> * destroy if C.PF, assert/deassert, set IRQF if setting C.PF (don't 
> check B.PIE)
>   FAIL
> * destroy if C.PF, always assert/deassert + set C.IRQF
>   FAIL
> * never destroy, assert/deassert + set C.IRQF if setting C.PF
>   FAIL
> * never destroy, assert/deassert + set C.IRQF if !C.IRQF
>   FAIL
> 
> In short, it seems that w2k3 basically expects an unlimited number of 
> attempts to actually deliver the interrupt.

Not always doing the deassert/assert pair was actually part of Tim's
subsequent changes - before that it got called conditionally upon
B.PIE, but always set C.IRQF and always deasserted and asserted.
Since we know from the debug log that B.PIE is set, I fail to see how
the code prior to "x86/hvm: Centralize and simplify the RTC IRQ logic"
would have not worked, but the above case turned out GOOD.

So did his earlier 3 changes perhaps fix the issue, and the fourth re-
introduced it?

Jan


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