1. 19 12月, 2012 3 次提交
  2. 12 12月, 2012 1 次提交
  3. 11 12月, 2012 3 次提交
  4. 09 12月, 2012 2 次提交
  5. 07 12月, 2012 1 次提交
  6. 06 12月, 2012 2 次提交
  7. 28 11月, 2012 1 次提交
    • A
      rtc: Only call rtc_set_cmos when Register B SET flag is disabled. · 02c6ccc6
      Alex Horn 提交于
      This bug occurs when the SET flag of Register B is enabled. When an RTC
      data register (i.e. any of the ten time/calender CMOS bytes) is set, the
      data is (as expected) correctly stored in the cmos_data array. However,
      since the SET flag is enabled, the function rtc_set_time is not invoked.
      As a result, the field base_rtc in RTCState remains uninitialized. This
      causes a problem on subsequent writes which can end up overwriting data.
      To see this, consider writing data to Register A after having written
      data to any of the RTC data registers; the following figure illustrates
      the call stack for the Register A write operation:
      
       +- cmos_io_port_write
       +-- check_update_timer
       +---- get_next_alarm
       +------ rtc_update_time
      
      In rtc_update_time, get_guest_rtc calculates the wrong time and
      overwrites the previously written RTC data register values.
      Signed-off-by: NAlex Horn <alex.horn@cs.ox.ac.uk>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      02c6ccc6
  8. 27 11月, 2012 1 次提交
  9. 26 11月, 2012 2 次提交
  10. 19 11月, 2012 1 次提交
  11. 15 11月, 2012 8 次提交
  12. 10 11月, 2012 1 次提交
  13. 01 11月, 2012 1 次提交
  14. 31 10月, 2012 1 次提交
  15. 30 10月, 2012 2 次提交
  16. 27 10月, 2012 1 次提交
  17. 24 10月, 2012 7 次提交
  18. 20 10月, 2012 1 次提交
  19. 05 10月, 2012 1 次提交
    • P
      rtc: implement century byte · b8994faf
      Paolo Bonzini 提交于
      Implement the century byte in the RTC emulation, and test that it works.
      This leads to some annoying compatibility code because we need to treat
      a value of 2000 for the base_year property as "use the century byte
      properly" (which would be a value of 0).
      
      The century byte will now be always-zero, rather than always-20,
      for the MIPS Magnum machine whose base_year is 1980.  Commit 42fc73a1
      (Support epoch of 1980 in RTC emulation for MIPS Magnum, 2009-01-24)
      correctly said:
      
          With an epoch of 1980 and a year of 2009, one could argue that [the
          century byte] should hold either 0, 1, 19 or 20.  NT 3.50 on MIPS
          does not read the century byte.
      
      so I picked the simplest and most sensible implementation which is to
      return 0 for 1980-2079, 1 for 2080-2179 and so on.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      b8994faf