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: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The ALARM_FLAG_DYNTICKS can be testing simply by checking if there is
a rearm function.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony 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: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony 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: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony 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: Adam Litke <agl@us.ibm.com>
Signed-off-by: Anthony 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: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Many usbdevice_init implementors assume params is non-NULL.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Anthony 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: Chris Webb <chris@arachsys.com>
Signed-off-by: Anthony 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: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Anthony 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: Paul Brook <paul@codesourcery.com>
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.
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.
This reverts commit 3ced9f7a36.
The next commit will convert all of qdev_device_add() to QError, and
it'll be clearer with this partial conversion reverted.
While fully converted handlers are not supposed to print anything when
running in a QMP monitor, they are free to print in a human monitor.
For instance, device_add (not yet converted) prints help, and will
continue to do so after conversion.
Moreover, utility functions converted to QError should remain usable
from unconverted handlers.
Two problems:
* handler_audit() complains when a converted handler prints. Limit
that to QMP monitors.
* With QMP, handlers need to pass the error object by way of
monitor_set_error(). However, we do that both for QMP and for the
human monitor. The human monitor prints the error object after the
handler returns. If the handler prints anything else, that output
"overtakes" the error message.
Limit use of monitor_set_error() to QMP monitors. Update
handler_audit() accordingly.
Users can't set them, so qdev_device_help() shouldn't list them. Fix
that. Also make qdev_prop_parse() hide them instead of printing a
meaningless "has no parser" error message.
Their value means nothing to users, so qdev_print_props() shouldn't
print it. Fix by removing their print method.
Their only use is dirty hacks. Document that.
Users can't create them, so qdev_device_help() shouldn't list them.
Fix that.
Also make qdev_device_add() pretend they don't exist. Before, it
rejected them with a "can't be added via command line" message, which
wasn't quite right for monitor command device_add.
New LOC_CMDLINE. Use it for tracking option with argument in
lookup_opt(). We now report errors like this
qemu: -device smbus-eeprom: Did not find I2C bus for smbus-eeprom
New LOC_FILE. Use it for tracking file name and line number in
qemu_config_parse(). We now report errors like
qemu:foo.conf:42: Did not find I2C bus for smbus-eeprom
In particular, gems like this message:
-device: no driver specified
become almost nice now:
qemu:foo.conf:44: -device: no driver specified
(A later commit will get rid of the bogus -device:)
New struct Location holds a location. So far, the only location is
LOC_NONE, so this doesn't do anything useful yet.
Passing the current location all over the place would be too
cumbersome. Hide it away in static cur_loc instead, and provide
accessors. Print it in error_report().
Store it in QError, and print it in qerror_print().
Store it in QemuOpt, for use by qemu_opts_foreach(). This makes
error_report() do the right thing when it runs within
qemu_opts_foreach().
We may still have to store it in other data structures holding user
input for better error messages. Left for another day.
Paolo Bonzini