Re: [Xen-devel] Xen RTC emulation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.11.13 at 13:01, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> In what we believe is now the final regression discovered when upgrading
> XenServer from Xen 4.1 to 4.3, there is an issue with RTC emulation.
> 
> Win2003 SP2 is a WAET unaware operating system, whose RTC access pattern
> triggers Xen's rtc_mode_no_ack logic.  The result is that the domain
> falls into a tight loop reading RTC RegC, whoes value is always 0xc0.

I specifically tested with w2k3, and know (from disassembling) that
it reads and evaluates the WAET table. While not impossible, it
seems unlikely that this would have been switched back in SP2.

> I have confirmed that switching Xen back to RTC strict mode fixes the
> regression, but I am presuming that this alone would be an unpopular fix
> upstream.
> 
> At the moment, HVMloader unconditionally advertises the RTC_NO_ACK bit
> in the WAET table, and Xen unconditionally decides that the domain has
> been informed that it should not ack RTC interrupts as per the
> specification.

No, it not "should not" but "doesn't need to".

> This logic is broken.  There is no guarantee that the domain has read
> the WAET table, but even if it has, there is no guarantee that it will
> act on the information it has been given.

And again, there is no requirement to omit the ACKs, Xen just
knows that it shouldn't rely on them being issued. At least that's
been the intention.

>  One option would be the
> toolstack to set this parameter up; it is in the best place to know
> whether a certain domain will correctly use the new available mode. 
> This would involve moving the rtc mode in Xen to a per-domain setting.

Yes, this was always the plan, and a first partial patch to do that
had been posted quite a while ago. The thing disliked (by Tim, with
me agreeing) was that the emulation mode got tied there to Viridian
mode. As noted in a reply to one of George's 4.4 status mails, I
simply didn't find time so far to convert the patch to one using a
distinct HVM param.

Jan


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