Re: [Xen-devel] [PATCH, v2] x86/HVM: assorted RTC emulation adjustments

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.08.12 at 15:44, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
wrote:
> On Wed, 22 Aug 2012, Jan Beulich wrote:
>> - don't call rtc_timer_update() on REG_A writes when the value didn't
>>   change (doing the call always was reported to cause wall clock time
>>   lagging with the JVM running on Windows)
>> - don't call rtc_timer_update() on REG_B writes at all
>> - only call alarm_timer_update() on REG_B writes when relevant bits
>>   change
>> - only call check_update_timer() on REG_B writes when SET changes
>> - instead properly handle AF and PF when the guest is not also setting
>>   AIE/PIE respectively (for UF this was already the case, only a
>>   comment was slightly inaccurate)
>> - raise the RTC IRQ not only when UIE gets set while UF was already
>>   set, but generalize this to cover AIE and PIE as well
>> - properly mask off bit 7 when retrieving the hour values in
>>   alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
>>   converting from 12- to 24-hour value
>> - also handle the two other possible clock bases
>> - use RTC_* names in a couple of places where literal numbers were used
>>   so far
>> 
>> Note that this only improves the situation described in the thread at
>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00664.html,
>> there are still problems with the emulation when invoked at a high rate
>> as described there.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Although this patch solves a real problem and should probably go in at
> some point, I am a bit worried about drifting too much from the original
> RTC emulator (that was taken from QEMU),

Then does that emulator have similar problems?

> because it would be nice to be able to backport features like this one:
> 
> http://marc.info/?l=qemu-devel&m=134392375010304 

I agree this would be nice to have (albeit I'm not sure how much
the original problem is actually present in the Xen code, particularly
with the patch here applied, as I think it may implicitly clean up some
of the unneccesary active timers).

Jan


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