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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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:
> > > > > > On 23.04.13 at 12:38, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> > > > Do you not have boot images of Windows 2003 that you can test yourself?
> > > In fact I don't have any non-machine-bound Windows images at
> > > all. Let me go see whether my American colleagues could help out
> > > here...
> > So I manually broke the patch down into 5 component parts (attached).
> > The installer works just fine for the first 3 -- the ones actually
> > mentioned in the patch changeset.  It breaks when the handler is moved
> > into the generic IRQ timer code rather than having its own callback (I
> > think that's what's happening there, anyway).
> 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.
Let me see if I can get a patch to the tip of unstable (with all the 
other intermediate changes)...
 -George

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