[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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...


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.