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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-04-29 at 07:53 +0100, Jan Beulich wrote:
> >>> 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 */

These sound much more sane. I should have considered the obvious answer
that the names we'd given the bits were rubbish! Actually the "GOOD"
name seems totally backward to me, since it seems to imply that the RTC
has non-conforming *and* non-desirable behaviour (raising many IRQs), if
it were non-conforming and desirable maybe GOOD would be ok...

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

OK.

23965:6880bfc48504 says that Windows 8 requires this table, but does it
also require us to set this bit? If our RTC emulation does require an
ACK then it seems we should simply omit the bit (but not the table),
will that work with both Win2k3 and Win8?

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

Sounds reasonable to me...

Ian.


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