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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 29 April 2013 09:20
> To: Jan Beulich
> Cc: Suravee Suthikulpanit; Andrew Cooper; Paul Durrant; Roger Pau Monne;
> George Dunlap; Eddie Dong; xen-devel@xxxxxxxxxxxxx; Keir (Xen.org); Tim
> (Xen.org)
> Subject: Re: [Xen-devel] Bug: Windows 2003 fails to install on xen-unstable
> tip
> 
> 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...
> 

The names were taken from the spec. but replacing them with more descriptive 
names sounds like a reasonable plan.

  Paul

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