Re: Bug: Windows 2003 fails to install on xen-unstable tip

[George Dunlap <george.dunlap@eu.citrix.com>]

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@eu.citrix.com> 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