[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 09:20 +0100 on 29 Apr (1367227227), Ian Campbell wrote:
> On Mon, 2013-04-29 at 07:53 +0100, Jan Beulich wrote:
> > 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...

"Good" is what the Microsoft WAET spec calls it.  The spec also
describes these bits as "Windows behaviour that the system requires"
rather than system behaviour that Windows relies on, but that doesn't
guarantee that Windows actually behaves that way.

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

Specifically emulated: that's what the 'E' in WAET stands for.  This
flag is to tell Windows that it needn't ack every RTC interrupt with an
IO read, so avoiding a bunch of VMEXITs (yay!).  But clearly you can't
have that behaviour and also Jan's change to skip all the interrupts
entirely if the guest's not using them.

My inclination is:

- for 4.3, revert.  Even if we keep the various emulation changes, we
  should go back to having the VPT code inject the interrupts, and
  drop the idea of suppressing the timer when the interrupt's unused. 

- For 4.4, make this bit optional and turn on the RTC suppression
  once the VPT interactions are fixed, and only when this bit is clear.
  The bit should be set off by default for new creation, but on by
  default on restore/migrate if unspecified by the sender, so that 
  VMs currently relying on it don't break.

Tim.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.