aboutsummaryrefslogtreecommitdiff
path: root/Makefile.hw
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2012-10-01 14:22:08 +0200
committerAnthony Liguori <aliguori@us.ibm.com>2012-10-05 08:02:30 -0500
commitb8994faf2a8d6fc791669bb432bdb3a7a1711013 (patch)
treec1876480b0f09dd97806039e26451a151720c8d0 /Makefile.hw
parente67edb943f0c812530aaae2491da56f9542f928b (diff)
downloadqemu-b8994faf2a8d6fc791669bb432bdb3a7a1711013.zip
qemu-b8994faf2a8d6fc791669bb432bdb3a7a1711013.tar.gz
qemu-b8994faf2a8d6fc791669bb432bdb3a7a1711013.tar.bz2
rtc: implement century byte
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 42fc73a (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: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'Makefile.hw')
0 files changed, 0 insertions, 0 deletions