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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.04.13 at 18:34, Tim Deegan <tim@xxxxxxx> wrote:
> At 17:02 +0100 on 25 Apr (1366909369), Jan Beulich wrote:
>> 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_.

So it turns out they have two handlers - the one that does read
REG_C is an early (apparently probing kind) one, while very soon
they install a second, permanent one. That second one reads
REG_C only conditionally, and the condition is the respective
flag in the WAET table (added by c/s 23965:6880bfc48504) to
hvmloader. The moment I clear that flag, all works as expected.

Now it is obvious that the combination of that flag and proper
RTC emulation can't work together, yet obviously we also can't
tell whether a particular guest looks at this flag at all. So the
question is how else to do the necessary clearing of REG_C,
which after all acts as the ACK to having handled the IRQ (and
enabling further ones). The only mechanism I can think of would
be a hook from the EOI handler, but that looks like a pretty
gross hack to me (and is of course all but safe if e.g. another OS
deliberately doesn't read the register from the interrupt hander
itself, but does so only from non-interrupt context).

Jan


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