> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] > Sent: Tuesday, January 10, 2012 5:25 PM > >> Also, I'm not sure if the update in progress flag still works. > >> Clients are supposed to wait for UIP=0 before reading the RTC, and an > >> update is supposed to be at least 220 microseconds away when UIP=0. > > > > Hardware need a period time to update clock and it would not provide > > the right value during the update. So it uses UIP to notify the > > software doesn't believe the value if the UIP is set. For emulation, > > you can read RTC at any time and it always gives you the right value. > > So there is no need to emulate UIP. > > This is incorrect, for two reasons. First, the UIP is in the spec, and we have to > implement it. Second, reading the clock is not atomic, and waiting for UIP=0 > gives you 220 microseconds during which you know that the read will appear > atomic. For a simulator, we need to follow the spec strictly and simulate hardware as precisely as possible. But QEMU is a generic machine emulator and virtualizer. It's not a hardware simulator. If there is an easy way we can provide the same function, why we chose the complicated one? Also, is there an actual case that break with my patch? > >> Also, it would be nice if you could based these patches on the > >> 4-patch series I sent recently that fixes some bugs with interrupts > >> and 12-hour emulation. > > > > When it will be check in? > > I don't know. :) > > >> There is another aspect of RTC emulation that is missing in the > >> current code; after setting the clock, the next second tick will > >> occur in exactly 500 ms. I have patches to fix this, but it looks > >> like it could be incorporated in your series, too. > > > > I do not quite understand it. What does "setting the clock" mean? And > > what is the next second tick? > > It means that the (not externally visible) millisecond value is set to > 500 when you modify the current time of the RTC. The next update of the clock > will happen exactly 500 ms after you reset bit 7 of register B. Same question, any reason need to complicate the current logic? Or any actual usage model need to add this? best regards yang -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
