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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-04-26 at 17:10 +0100, Jan Beulich wrote:
> >>> 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.

Oh my god. What on earth can the semantics of ACPI_WAET_RTC_GOOD be such
that every BIOS vendor doesn't immediately just set it: "Of course my
RTC is good!"

> Now it is obvious that the combination of that flag and proper
> RTC emulation can't work together,

So does the flag actually require *improper* behaviour from the RTC
(emulated or otherwise)?

/me boggles...

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

We have made these sorts of things guest-cfg conditional in the past,
but that's kind of sucky too.

Ian.


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