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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/25/2013 05:34 PM, Tim Deegan wrote:
> At 17:02 +0100 on 25 Apr (1366909369), Jan Beulich wrote:
> > > > > On 23.04.13 at 12:38, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> > > On 23/04/13 11:25, Jan Beulich wrote:
> > > > Just to double check - could you comment out entirely the first
> > > > (normal code, i.e. not the one marked //todo?) "else if" in
> > > > rtc_periodic_interrupt() (including its body of course)? I would
> > > > expect this to not make a difference, and if so I don't see how
> > > > Windows expects to be woken up again (I would guess that
> > > > they internally have some gating logic preventing the normal IRQ8
> > > > handling to happen, yet of course we don't know what would
> > > > reset that state).
> > > In fact, when I comment out that region, then it hangs in the guest BIOS
> > > before even attempting to boot the CD.
> > That's due to a different issue, that I meanwhile found a fix for
> > (caused by the general vpt code expecting interrupts to be
> > delivered, yet the BIOS doesn't enable the interrupt, and hence
> > the RTC periodic timer doesn't get advanced to the next tick,
> > and it having an earlier expiration time than the PIT one prevents
> > pt_update_irq() to pick that one up for processing).
> How inconvenient - I had been solving the same problem today.  Yes, if
> rtc_periodic_interrupt() doesn't actually inject an interrupt, the vpt
> code needs to know so it can increment the timer.
>
> > With that fixed and the mentioned code block removed, things
> > work as I had expected. But the logging that I added in the
> > course of all this shows that it really juts happens to work,
> > I can't really explain why (other than the myriads of superfluous
> > interrupts attempted to be injected into the guest keeping the
> > VM alive). In particular, almost none of the injected IRQs
> > actually reach their handler (there are only very few REG_C
> > reads), but the handler also doesn't do anything really
> > interesting (i.e. we don't actually need the handler to execute,
> > we just need to keep a flow of interrupts going into the VM).
> Really?  Does injecting spurious interrupts work too?  Presumably the
> handler does _something_.
>
> > Yet I did verify that the correct values get actually written
> > through vmx_inject_extint()/__vmx_inject_exception().
> >
> > So at this point I'm of the opinion that the RTC changes really
> > just exposed a completely different issue, and I'm of the opinion
> > that this is what needs fixing, not papering over it by reverting
> > the RTC stuff.
> On the contrary, I think this shows that the RTC/vpt/guest interactions
> are so badly understood as to merit backing the whole lot out for 4.3.
> This has been dragging on for weeks now, and AFAICS it's going to need a
> serious overhaul, plus someone manually testing all the OSes that are
> likely to be affected (i.e. the crufty old ones).
Yes, I think "first, do no harm" should be what we aim for here...

 -George

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