Remove glib.h includes, as it is provided by osdep.h.

This commit was created with scripts/clean-includes.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Tested-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Tested-by: NEric Blake <eblake@redhat.com>

It is dangerous to include user headers before system headers since user
macros can affect system headers.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This avoids each test needing to add it to suppress windows popping up.

[Commit 7ceeedd0 ("blockdev-test: add
test case for drive_add duplicate IDs") and commit
43cd2098 ("qdev-monitor-test: add
device_add leak test cases") added qtest tests without specifying
-display none.

As a result, "make check" now tries to use graphics (GTK or SDL).  Since
graphics are not used by the test and inappropriate for headless "make
check" runs, add the missing -display none.

This fixes "make check" in the QEMU buildbot.
-- Stefan]
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

As of glib 2.35.4, glib changed its logic for ordering test cases:

https://bugzilla.gnome.org/show_bug.cgi?id=694487

This was causing failures in rtc-test. Group the reordered test
cases into their own suite, which maintains the original ordering.

CC: qemu-stable@nongnu.org
Signed-off-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Trying (unsuccessfully) to break the device model as mentioned in
https://bugs.launchpad.net/qemu/+bug/1090558.

At least if someone tries to fix that, it won't break what works...
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1357922817-17584-3-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Eliminate dependencies between one test and the others.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1357922817-17584-2-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Struct tm does not have tm_gmtoff field on illumos.
Fix the build by not zero-initializing these fields on Solaris.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <andreas.faerber@web.de>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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>

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>

When setting a date in 1980, Linux is actually disregarding the century
byte and setting the year to 2080.  This causes a year-2038 overflow
in mktimegm.  Fix this by doing the days-to-seconds computation in
64-bit math.
Reported-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Avoid this warning on OpenBSD:
  CC    tests/rtc-test.o
/src/qemu/tests/rtc-test.c: In function 'check_time':
/src/qemu/tests/rtc-test.c:171: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t'
/src/qemu/tests/rtc-test.c:173: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t'
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>