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 16:46:50 +0100 Message-ID: <5176ACEA.1040607@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> <517698DA.3060301@eu.citrix.com> <5176BD1602000078000D0106@nat28.tlf.novell.com> <5176A13F.9030603@eu.citrix.com> <5176BEC202000078000D012D@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: <5176BEC202000078000D012D@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 16:02, Jan Beulich wrote: >>>> On 23.04.13 at 16:57, George Dunlap wrote: >> On 23/04/13 15:55, Jan Beulich wrote: >>>>>> On 23.04.13 at 16:21, George Dunlap wrote: >>>> 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: >>>>> 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? >> If you've got a git hash I can try to revert it. > 527824f41f5fac9cba3d4441b2e73d3118d98837 Reverting that c/s has no effect. And if I then make the change that made it work before -- namely, unconditionally calling rtc_toggle_irq in rtc_periodic_interrupt() -- then the w2k3 installer just spins instead of hangs. At this point I think it's worth asking: is raising needless IRQs and running non-used pmtimers really causing that big of an issue? Given that I've just spent a whole day trying to debug this, wouldn't it be better just to revert all the rtc-related changesets from 620d5da? -George