From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Bug: Windows 2003 fails to install on xen-unstable tip Date: Tue, 23 Apr 2013 15:21:14 +0100 Message-ID: <517698DA.3060301@eu.citrix.com> References: <516D7DA202000078000CDA60@nat28.tlf.novell.com> <516D61A8.1080102@eu.citrix.com> <516E791902000078000CDE09@nat28.tlf.novell.com> <516EE63E.4090008@eu.citrix.com> <5171332602000078000CEE8A@nat28.tlf.novell.com> <51712018.4010600@citrix.com> <5171591402000078000CF023@nat28.tlf.novell.com> <51714BE5.8080909@eu.citrix.com> <517535A702000078000CF75C@nat28.tlf.novell.com> <517557F3.9020605@eu.citrix.com> <51767DC402000078000CFE48@nat28.tlf.novell.com> <517664BE.401@eu.citrix.com> <51768DB702000078000CFEF9@nat28.tlf.novell.com> <517675EC.9010904@eu.citrix.com> <5176A20A02000078000CFFD3@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: <5176A20A02000078000CFFD3@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: "Tim (Xen.org)" , "xen-devel@lists.xen.org" , Eddie Dong , Suravee Suthikulpanit , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 23/04/13 14:00, Jan Beulich wrote: >>>> On 23.04.13 at 13:52, George Dunlap wrote: >> On 23/04/13 12:33, Jan Beulich wrote: >>>>>> On 23.04.13 at 12:38, George Dunlap 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