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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.04.13 at 18:56, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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!"

One problem here of course is the naming in the firmware/
tree - it suggests a meaning of the flag that's not intended.
Taking what's in the hypervisor tree is much more meaningful
(and I'm intending to change the firmware/ bits, at once also
establishing the connection between it and the RTC emulation
code):

#define ACPI_WAET_RTC_NO_ACK        (1) /* RTC requires no int acknowledge */
#define ACPI_WAET_TIMER_ONE_READ    (1<<1)      /* PM timer requires only one 
read */

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

Yes. Specifically it requires new interrupts to get raised even
when the guest never reads REG_C (i.e. not only when
RTC_IRQF transitions from 0 to 1).

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

Ultimately I think we need to do this here too - default to the way
we used to run this before the emulation got made spec conforming,
but allow guests not paying attention to this questionable flag to
run with a properly emulated device (not needlessly raising
interrupts).

For 4.3 I think we won't want this, but only return to the previous
operating mode as far as necessary. I'm no longer intending to do
a revert though, but put the code in shape so that a new HVM
param to control this can be added without a lot of other code
changes.

Jan


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