Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).
Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Don't assume zeroed cpuid_model[] fields.
This didn't break anything yet but QOM properties should be able to set
the value to something else without setting an intermediate zero string.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
After adding GCC_FMT_ATTR to qtest_sendf, more format errors are reported
by the compiler. These are fixed here.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is a bitmap file (32x32x4) derived from the official QEMU mascot
(which was designed by Benoît Canet). I stripped the text from the SVG
to get a nearly square image and converted the result to BMP without
any manual optimization.
The bitmap is currently used by QEMU's SDL interface and replaces the
default X icon.
v2: Add qemu-icon.bmp to Makefile.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Here's an example session:
anthony@titi:~/git/qemu/QMP$ QMP_SERVER=/tmp/server.sock ./qom-fuse tmp
anthony@titi:~/git/qemu/QMP$ ls tmp
machine sysbus type
anthony@titi:~/git/qemu/QMP$ ls tmp/machine
i440fx peripheral peripheral-anon type unattached
anthony@titi:~/git/qemu/QMP$ ls tmp/machine/i440fx
ioapic parent_bus pci.0 type
anthony@titi:~/git/qemu/QMP$ ls tmp/machine/i440fx/pci.0
child[0] child[1] child[2] child[3] child[4] child[5] type
anthony@titi:~/git/qemu/QMP$ ls tmp/machine/i440fx/pci.0/child[4]
addr legacy-addr multifunction type
command_serr_enable legacy-command_serr_enable parent_bus
ide.0 legacy-multifunction rombar
ide.1 legacy-romfile romfile
anthony@titi:~/git/qemu/QMP$ cat tmp/machine/i440fx/pci.0/child[4]/type
piix3-ide
anthony@titi:~/git/qemu/QMP$ ls -al tmp/machine/i440fx/pci.0/child\[4\]/parent_bus
lrwxr-xr-x 2 anthony anthony 4096 1969-12-31 18:00 tmp/machine/i440fx/pci.0/child[4]/parent_bus -> ../../../machine/i440fx/pci.0
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We're not actually calling qdev_init for the pc-sysfw device. Since we create
the canonical path during realize, this was causing an assert to trigger when
attempting to read a link pointing to pc-sysfw.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
s->sock is assigned only afterwards, so we're really registering an
aio_fd_handler for file descriptor 0 here. Not exactly what we intended.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
uhci_reset() clears irq mask and irq status registers, but doesn't
update the irq line. Which may result in suspious IRQs after uhci
reset. Fix it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds a function which creates unique serial numbers for usb
devices and puts it into use. Windows guests tend to become unhappy if
they find two identical usb devices in the system. Effects range from
non-functional devices (with yellow exclamation mark in device manager)
to BSODs. Handing out unique serial numbers to devices fixes this.
With this patch applied almost all emulated devices get a generated,
unique serial number. There are two exceptions:
* usb-storage devices will prefer a user-specified serial number
and will only get a generated number in case the serial property
is unset.
* usb-hid devices keep the fixed serial number "42" as it is used
to signal "remote wakeup actually works".
See commit 7b074a22da
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
We clear our pending async urb list on device disconnect and we may still
receive "packet complete" packets from our peer after this, which will then
refer to packet ids no longer in our list.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Without this disconnected devices look like the last redirected device
in the monitor in "info usb".
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
An interface-count of 0 happens when a device is in unconfigured state when
it gets redirected. So we should not use 0 to detect not having received
interface info from our peer.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Shortly before 1.0, we added helper functions / wrappers for doing PCI DMA
from individual devices. This makes what's going on clearer and means that
when we add IOMMU support somewhere in the future, only the general PCI
code will have to change, not every device that uses PCI DMA.
However, usb-xhci is not using these wrappers, despite being a PCI only
device. This patch remedies the situation, using the pci dma functions
instead of direct calls to cpu_physical_memory_{read,write}(). Likewise
address parameters for DMA are changed to dma_addr_t instead of
target_phys_addr_t.
[ kraxel: removed #ifdefs ]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb-host optimizes away zero-length packets by not entering the
processing loop at all. Which isn't correct, we should submit a
zero-length urb to the host devicein that case. This patch makes
sure we run the processing loop at least once.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb-host assumes the first iovec element is always valid.
In case of a zero-length packet this isn't true though.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Little fix for usb packet handling on i/o cancelation. The
usb packet pointer (s->packet) is cleared at the wrong place:
The scsi request cancel handler does it. When a usb packet
is canceled the usb-storage emulation canceles the scsi request
if present. In most cases there is one, so usually s->packet
is cleared as needed even with the code sitting at the wrong
place.
If there is no scsi request in flight s->packet is not cleared
though. The usb-storage emulation will then try to complete an
usb packet which is not in flight any more and thereby trigger
an assert() in the usb core.
Fix this by clearing s->packet at the correct place, which is
the usb packet cancel header.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
frindex is a 14 bits counter, so bits 31-14 should always be 0, and
after the commit titled "usb-ehci: frindex always is a 14 bits counter"
we rely on frindex always being a multiple of 8. I've not seen this in
practice, but theoretically a guest can write a value >= 0x4000 or a value
which is not a multiple of 8 value to frindex, this patch ensures that
things will still work when that happens.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
To answer the question in the comment removed by this patch: I think
this was needed because several places in the ehci emulation did not
check the T bit of link entries correctly and thus might have followed
invalid references. See commit 2a5ff735dc
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Our hda codecs exist in two variants: With CONFIG_MIXEMU=y they expose
amplifiers for volume control to the guest, with CONFIG_MIXEMU=n they
don't.
This patch changes the codec ids, they are different now for these two
cases. This makes sure windows guests will notice the difference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
It's identical to the hda-duplex codec, except that it advertises the
input as microphone instead of line-in and the output as speaker instead
of line-out. Some guest apps (microsoft netmeeting being one) are picky
when it comes to selecting the recording source and don't accept
line-in, so give them what they expect.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
We currently host stable trees for 0.10, 0.14, 0.15 and 1.0.
Sort in descending order. It is expected that further non-stable
sections will be added above these so this order avoids scrolling
through an ever-growing list of stable trees.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Instead of a Web link, T: is supposed to indicate type of SCM and
pullable URL, so switch to the git:// URL.
Also harmonize the spacing between sections while at it.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
tcg/tci is a directory, so for recursive semantics add a trailing slash.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Stefan Weil <sw@weilnetz.de>
Only one pattern is allowed per F: line, split in two.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
When a guest driver resets the virtio status to not ready, or when qemu
is reset, reset all ports' guest_connected bit and let port users know
of this event if they have the guest_close() callback registered.
Reviewed-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
guest_connected should be false before guest driver initialization, and
true after, both for multiport aware and non multiport aware drivers.
Don't set it before the guest_features are available; instead use
set_status which is called by io to VIRTIO_PCI_STATUS with
VIRTIO_CONFIG_S_DRIVER_OK by even older non multiport drivers.
[Amit: Add comment, tweak summary, only set guest_connected and not
reset it as a side-effect.]
Signed-off-by: Alon Levy <alevy@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Use Hz as unit.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Using it now would incur converting the three x86_def_t vendor words
into a string for object_property_set_str(), then back to three words
in the "vendor" setter.
The built-in CPU definitions use numeric preprocessor defines to
initialize the three words in a charset-safe way, so do not change the
fields to char[12] just to use the setter.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Add the property early in the initfn so that it can be used in helpers
such as mce_init().
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
[AF: Add an error_free(), spotted by Michael Roth]
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
A family field value of 0xf and extended family field value of 0xff is
the maximum representable unsigned family number.
All other CPUID property values are bounds-checked, so add a check here
for symmetry before we adopt it in a property setter.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Avoids an x86_env_get_cpu() call there, to work with QOM properties.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Don't assume zeroed cpuid_model[] fields.
This didn't break anything yet but QOM properties should be able to set
the value to something else without setting an intermediate zero string.
Reviewed-by: Eduardo Habhost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[AF: Use memset() instead of for loop, suggested by Igor]
Signed-off-by: Andreas Färber <afaerber@suse.de>