Re: [Xen-devel] [PATCH 2/6] x86/HVM: slightly adjust RTC reset

[Tim Deegan <tim@xxxxxxx>]

At 10:51 +0100 on 02 May (1367491874), Jan Beulich wrote:
> >>> On 02.05.13 at 11:27, Tim Deegan <tim@xxxxxxx> wrote:
> > At 14:52 +0100 on 29 Apr (1367247135), Jan Beulich wrote:
> >> We should clear the interrupt enable flags here, deassert the IRQ, and
> >> clear REG_C.
> > 
> > I'm not sure at all that we should be tinkering with the IE flags here.
> > AFAICT this code is called on S3 suspend -- Does a real S3 do that (and
> > not reset any of the other RTC registers?
> 
> A real S3 might or might not do this, but I have to admit that I
> didn't notice that this is being called from other than rtc_init().

OK.  rtc_init() resets all four control registers just below the call to
rtc_reset(), so we can probably just drop this.

> The change was meant to serve purely documentation purposes
> based on the name of the function (which isn't in line with being
> used in the S3 suspend path if real suspend wouldn't do an RTC
> reset).

OK, it seems like this isn't really a 'reset' so much as a way to
disable the timer.  There doesn't seem to be an equivalent call after
resume to re-enable it though. I don't understand the S3 framework well
enough to exlain that. :)

> I wonder, however, whether clearing pt_code here is
> appropriate then.

I think we need to clear pt.code since we disable the timer, and
otherwise we might never re-enable it.

> And resetting pt.source wouldn't seem to
> belong here either if we don't mean to really "reset" the RTC -
> it's just that it never gets changed to anything else, so its
> mis-placement is benign.

The pt.source change was moved from rtc_init() to rtc_reset() here:

commit 9194f26eba9e7ce3c27863dabddafe46fcfdba58
Author: Keir Fraser <keir.fraser@xxxxxxxxxx>
Date:   Wed Jul 2 17:25:05 2008 +0100

    x86 hvm: Fix RTC handling.
     1. Clean up initialisation/destruction.
     2. Better handle per-domain time-offset changes.
    Signed-off-by: Keir Fraser <keir.fraser@xxxxxxxxxx>

Cc'ing Keir.

Tim.

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