search for: rtc_reg_c

Finally I got around to breaking up the similarly named monolithic patch that caused a regression shortly before the 4.2 release and got therefore reverted. This series consists of the broken up pieces that - according to my testing - don''t expose the reported lockup; the 7th will need debugging to understand what''s wrong there. 1: use RTC_* names instead of literal numbers 2:

Dear all: I have found a big bug on xen concerning time virtualization. Please let me show you the whole process: 1 Phenomenon when I run a JVM based program in IE browser in my Virtual Machine, I have found clearly that time at the right bottom corner in my VM gets more slower and slower. I studied the bug deeply, and found something below. 2 Xen vmx_vmexit_handler --> ......... -->

This patch series makes suspend support in qemu alot more useful. Right now the guest can put itself into s3, but qemu will wakeup the guest instantly. With this patch series applied the guest will stay suspended instead and there are a few events which can kick the guest out of suspend state: A monitor command, ps/2 input, serial input, rtc. Not much yet, but it''s a start with the

...port_read(RTCState *s, uint32_t addr) { int ret; @@ -268,6 +286,8 @@ static uint32_t rtc_ioport_read(RTCState break; case RTC_REG_A: ret = s->hw.cmos_data[s->hw.cmos_index]; + if (update_in_progress(s)) + ret |= RTC_UIP; break; case RTC_REG_C: ret = s->hw.cmos_data[s->hw.cmos_index]; diff -r 47cb862a07c2 -r edc35b026509 xen/arch/x86/time.c --- a/xen/arch/x86/time.c Mon Mar 05 14:39:07 2012 +0800 +++ b/xen/arch/x86/time.c Mon Mar 05 14:39:41 2012 +0800 @@ -1601,6 +1601,13 @@ unsigned long get_localtime(struct d...