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

Tweaking the rounding in qemu_next_deadline ensures that there's
no change whatsoever.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.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>

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

A simple patch to place together all handling of -icount.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

By adding the possibility to turn on/off a clock, yet another
incestuous relationship between timers and CPUs can be disentangled.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.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>

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

Make the timer subsystem register its own callback instead.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Instead of testing specially next_cpu in host_alarm_handler, just do
that in qemu_notify_event.  The idea is, if we are not running (or
not yet running) target CPU code, prepare things so that the execution
loop is exited asap; just make that clear.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qemu_notify_event in the non-iothread case is only stopping the current
CPU.  However, if the CPU is idle and the main loop is in the select
call then a call to qemu_event_increment is needed too (as done in
host_alarm_handler).  Since in general one doesn't know whether the CPU
is executing or not, it is a safe bet to always do qemu_event_increment.

Another way to see it: after this patch qemu_event_increment is the
"common part" of qemu_notify_event for both the CONFIG_IOTHREAD and
!CONFIG_IOTHREAD cases, which makes sense.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The timer_alarm_pending variable is related to the alarm timer but not
placed in the struct.  Also, in qemu_mod_timer the wrong flag was being
tested: the timer is rearmed in the alarm timer "bottom half", so the
right flag to test there is the "pending" flag.

Finally, I hoisted the NULL checks from alarm_has_dynticks to
host_alarm_handler.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The ALARM_FLAG_DYNTICKS can be testing simply by checking if there is
a rearm function.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The TIME_ONESHOT and TIME_PERIODIC flags are mutually exclusive.
The code after the patch matches the flags used in win32_start_timer.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The code is initializing an unsigned int to UINT_MAX using "-1", so that
the following always-true comparison seems to be always-false at a
first look.  Since alarm timer initializations are never nested, it is
simpler to unconditionally store the result of timeGetDevCaps into
data->period.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When working with the VM state (for loadvm/savevm and migration), it is not
valid to load and store pointers since the validity of those pointers cannot be
assured in the new qemu address space.  Therefore, virtio_balloon_save() and
virtio_balloon_load() must not handle the stats-related fields in struct
VirtIOBalloon.

If a memory stats request is in-flight at the time of a migration or savevm,
the request will not complete and should be resubmitted once migration or
loadvm completes.  Note that this extremely small race window can only be
triggered using QMP so it is not possible to hang the user monitor.
Signed-off-by: NAdam Litke <agl@us.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Add a logical block size attribute as various guest side tools only
increase the filesystem sector size based on it, not the advisory
physical block size.

For scsi we already have support for a different logical block size
in place for CDROMs that we can built upon.  Only my recent block
device characteristics VPD page needs some fixups.  Note that we
leave the logial block size for CDROMs hardcoded as the 2k value
is expected for it in general.

For virtio-blk we already have a feature flag claiming to support
a variable logical block size that was added for the s390 kuli
hypervisor.  Interestingly it does not actually change the units
in which the protocol works, which is still fixed at 512 bytes,
but only communicates a different minimum I/O granularity.  So
all we need to do in virtio is to add a trap for unaligned I/O
and round down the device size to the next multiple of the logical
block size.

IDE does not support any other logical block size than 512 bytes.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Many usbdevice_init implementors assume params is non-NULL.
Signed-off-by: NJan Kiszka <jan.kiszka@web.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

During boot, the screen gets resized to height 1 and a mouse click at this
point will cause a division by zero when calculating the absolute pointer
position from the pixel (x, y). Return a click in the middle of the screen
instead in this case.
Signed-off-by: NChris Webb <chris@arachsys.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The SDL_SetVideoMode() error condition is easily triggered by a user by
simply configure a guest with a host unsupported display resolution
and attempting to enable fullscreen.  Since the error is fatal, adding
a bit of debugging help can't harm.

Sample output with this change:

 (qemu) Could not open SDL display (1280x1024x32): No video mode large enough for 1280x1024

The width x height might seem redundant as SDL also provides it in
SDL_GetError(), but I believe there are situations where it is
useful.  I.e. if there is some other SDL error.  Anyway, redundant
information in fatal error messages has never harmed a single gerbil.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NShahar Havivi <shaharh@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NShahar Havivi <shaharh@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

QEMU uses a fixed page size for the CPU TLB.  If the guest uses large
pages then we effectively split these into multiple smaller pages, and
populate the corresponding TLB entries on demand.

When the guest invalidates the TLB by virtual address we must invalidate
all entries covered by the large page.  However the address used to
invalidate the entry may not be present in the QEMU TLB, so we do not
know which regions to clear.

Implementing a full vaiable size TLB is hard and slow, so just keep a
simple address/mask pair to record which addresses may have been mapped by
large pages.  If the guest invalidates this region then flush the
whole TLB.
Signed-off-by: NPaul Brook <paul@codesourcery.com>

While there, improve the params help text.

In the human monitor, it declares a single optional argument to be
parsed according to the QemuOptsList given by its name.

In QMP, it declares an optional argument for each member of the
QemuOptsList.

Restriction: only lists with empty desc are supported for now.  Good
enough for the job at hand.  We'll lift the restriction when we need
that.

Next commit wants to use it.

We sometimes permit omitting the first option name, for example
-device foo is short for -device driver=foo.  The name to use
("driver" in the example) is passed as argument to qemu_opts_parse().
For each QemuOptsList, we use at most one such name.

Move the name into QemuOptsList, and pass whether to permit the
abbreviation.  This ensures continued consistency, and simplifies the
commit after next in this series.

The functions are somewhat restricted.  Good enough for the job at
hand.  We'll extend them when we need more.

Conversion to QObject is still missing.

This reverts commit 3ced9f7a.

The next commit will convert all of qdev_device_add() to QError, and
it'll be clearer with this partial conversion reverted.