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:57:03 +0100 Message-ID: <5176A13F.9030603@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5176BD1602000078000D0106@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 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. -George