Re: [Xen-devel] [PATCH RFC v2 0/2] Fix RTC noack issues

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.12.13 at 12:09, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> This series allows the toolstack to choose (by way of XenStore platform 
> flags)
> whether the domain is expecting to make use of RTC mode noack performance
> optimisations.
> 
> It also switches the implict default back to rtc_mode_strict, which is the
> safe default for Xen to have.
> 
> This fixes a longstanding regression in Win2k3SP2 only where its access
> pattern causes it to fall into an infinite loop reading RTC RegC.

It's not really clear to me how to read this: Since you still keep both
modes and don't change their behavior, I don't see how you
address the infinite loop in case such a domain got started with
the mode set to no-ack. After all, both modes should - provided
they're consistent with what the WAET says - work with any guest
(and hence there's no "good" or "bad" default mode).

> Questions for thought:
> 
>  * Does it make sense to allow customisation of ACPI_WAET_TIMER_ONE_READ ?
>    There is no sitation where an admin should turn it off.

As said before - without currently seeing a use for making this
configurable, we should leave it alone.

>  * I believe this is safe wrt migrations, but am not certain enough to say for
>    sure.  This is a critical point, as the bad default (and regression) has
>    been in Xen since late in the Xen-4.3 development cycle.

So a guest started on 4.3 and evaluating WAET won't read REG_C
during interrupts. I can't see how this is not going to be a problem
when on 4.4 the default would be the opposite. I think you'd need
to default guests getting migrated to either the fixed no-ack mode
that 4.3 used, or have the tools inspect its WAET and have them
set the mode according to the bit there.

It was only the inverse change that was safe (from 4.2 to 4.3): A
guest reading REG_C even if it isn't required to would still work
correctly.

Jan


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