Sectors are marked dirty in the bitmap on AIO submission. This is wrong
since data has not reached storage.
Set a given sector as dirty in the dirty bitmap on AIO completion, so that
reading a sector marked as dirty is guaranteed to return uptodate data.
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Otherwise upper 32 bits of bitmap entries are not correctly calculated.
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This introduces generation of a qemu.stp/qemu-system-XXX.stp
files which provides tapsets with friendly names for static
probes & their arguments. Instead of
probe process("qemu").mark("qemu_malloc") {
printf("Malloc %d %p\n", $arg1, $arg2);
}
It is now possible todo
probe qemu.system.i386.qemu_malloc {
printf("Malloc %d %p\n", size, ptr);
}
There is one tapset defined per target arch, for both
user and system emulators.
* Makefile.target: Generate stp files for each target
* tracetool: Support for generating systemtap tapsets
* configure: Check for whether systemtap is available
with the DTrace backend
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This introduces a new tracing backend that targets the SystemTAP
implementation of DTrace userspace tracing. The core functionality
should be applicable and standard across any DTrace implementation
on Solaris, OS-X, *BSD, but the Makefile rules will likely need
some small additional changes to cope with OS specific build
requirements.
This backend builds a little differently from the other tracing
backends. Specifically there is no 'trace.c' file, because the
'dtrace' command line tool generates a '.o' file directly from
the dtrace probe definition file. The probe definition is usually
named with a '.d' extension but QEMU uses '.d' files for its
external makefile dependancy tracking, so this uses '.dtrace' as
the extension for the probe definition file.
The 'tracetool' program gains the ability to generate a trace.h
file for DTrace, and also to generate the trace.d file containing
the dtrace probe definition.
Example usage of a dtrace probe in systemtap looks like:
probe process("qemu").mark("qemu_malloc") {
printf("Malloc %d %p\n", $arg1, $arg2);
}
* .gitignore: Ignore trace-dtrace.*
* Makefile: Extra rules for generating DTrace files
* Makefile.obj: Don't build trace.o for DTrace, use
trace-dtrace.o generated by 'dtrace' instead
* tracetool: Support for generating DTrace data files
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We can't let the compiler define the alignment for qemu_cfg data.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fix a makefile error that meant that qemu would not compile if
the source and object directories were the same.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Since commit 4bed983730 an .fd_read()
handler that deletes its IOHandler is exposed to .fd_write() being
called on the deleted IOHandler.
This patch fixes deletion so that .fd_read() and .fd_write() are never
called on an IOHandler that is marked for deletion.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Some devices seem to choke on receiving a USB_REQ_GET_CONFIGURATION ctrl msg
(witnessed with a digital picture frame usb id 1908:1320).
When usb_fs_type == USB_FS_SYS, the active configuration can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The next patch in this series introduces multiple ways to get the
configuration dependent upon usb_fs_type, it is cleaner to put this
into its own function.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This allows us to recreate the sysfspath used during scanning later
(which will be used in a later patch in this series).
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch adds missing braces around if/else statements that call
macros which are likely to result in errors if the macro is
changed. It also makes the code comply better with CODING_STYLE.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This introduces generation of a qemu.stp/qemu-system-XXX.stp
files which provides tapsets with friendly names for static
probes & their arguments. Instead of
probe process("qemu").mark("qemu_malloc") {
printf("Malloc %d %p\n", $arg1, $arg2);
}
It is now possible todo
probe qemu.system.i386.qemu_malloc {
printf("Malloc %d %p\n", size, ptr);
}
There is one tapset defined per target arch.
* Makefile: Generate a qemu.stp file for systemtap
* tracetool: Support for generating systemtap tapsets
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This introduces a new tracing backend that targets the SystemTAP
implementation of DTrace userspace tracing. The core functionality
should be applicable and standard across any DTrace implementation
on Solaris, OS-X, *BSD, but the Makefile rules will likely need
some small additional changes to cope with OS specific build
requirements.
This backend builds a little differently from the other tracing
backends. Specifically there is no 'trace.c' file, because the
'dtrace' command line tool generates a '.o' file directly from
the dtrace probe definition file. The probe definition is usually
named with a '.d' extension but QEMU uses '.d' files for its
external makefile dependancy tracking, so this uses '.dtrace' as
the extension for the probe definition file.
The 'tracetool' program gains the ability to generate a trace.h
file for DTrace, and also to generate the trace.d file containing
the dtrace probe definition.
Example usage of a dtrace probe in systemtap looks like:
probe process("qemu").mark("qemu_malloc") {
printf("Malloc %d %p\n", $arg1, $arg2);
}
* .gitignore: Ignore trace-dtrace.*
* Makefile: Extra rules for generating DTrace files
* Makefile.obj: Don't build trace.o for DTrace, use
trace-dtrace.o generated by 'dtrace' instead
* tracetool: Support for generating DTrace data files
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
A via -kernel supplied x86_64 ELF image is being started in 32bit mode.
Detect and exit if a 64bit image has been supplied.
Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
local_apics are allocated sequentially and never removed, so
we can stop any iterations that go to MAX_APICS as soon as we
hit the first NULL. Looking at a small guest running a virtio-net
workload with oprofile, this drops apic_get_delivery_bitmask()
from #3 in the profile to down in the noise.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch fixes hot unplug of cold plugged devices
(those present at system start), which got broken by
5beb8ad503 .
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Cam Macdonell <cam@cs.ualberta.ca>
Tested-by: Cam Macdonell <cam@cs.ualberta.ca>
Reported-by: Cam Macdonell <cam@cs.ualberta.ca>.
pcibus_dev_print() was erroneously retrieving the device bus
number from the secondary bus number offset of the device
instead of the bridge above the device. This ends of landing
in the 2nd byte of the 3rd BAR for devices, which thankfully
is usually zero.
Note: pcibus_get_dev_path() copied this code,
inheriting the same bug. pcibus_get_dev_path() is used for
ramblock naming, so changing it can effect migration. However,
I've only seen this byte be non-zero for an assigned device,
which can't migrate anyway, so hopefully we won't run into
any issues.
This patch does not touch pcibus_get_dev_path, as
bus number is guest assigned for nested buses,
so using it for migration is broken anyway.
Fix it properly later.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When adding the length to the pseudo header, we're not properly
accounting for overflow.
From: Mark Wu <dwu@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-net expects set_offload to succeed after
peer cleanup.
Since we don't have an open fd anymore, make it so.
Fixes warning about the failure of offload setting.
Reported-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Frontends calling tap_get_vhost_net get an invalid pointer after the
peer backend has been deleted. Jason Wang <jasowang@redhat.com> reports
this leading to a crash in ack_features when we remove the vhost-net
bakend of a virtio nic.
The fix is simply to clear the backend pointer.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Make stdvga provide the new vgabios binary (with pcibios support)
using the PCI option rom bar. Seabios will happily load it from
there. The new vga bios will also lookup the framebuffer address
in pci config space, so the magic bochs lfb @ 0xe0000000 is not
needed any more -> zap it.
Without the patch:
# dmesg | grep framebuffer
vesafb: framebuffer at 0xe0000000, mapped to 0xf7e80000, using 1875k, total 8192k
# lspci -vs2
00:02.0 VGA compatible controller: Technical Corp. Device 1111 (prog-if 00 [VGA controller])
Subsystem: Qumranet, Inc. Device 1100
Physical Slot: 2
Flags: fast devsel
Memory at f0000000 (32-bit, prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled]
With patch applied:
# dmesg | grep framebuffer
vesafb: framebuffer at 0xf0000000, mapped to 0xf7e80000, using 1875k, total 8192k
# lspci -vs2
00:02.0 VGA compatible controller: Technical Corp. Device 1111 (prog-if 00 [VGA controller])
Subsystem: Qumranet, Inc. Device 1100
Physical Slot: 2
Flags: fast devsel
Memory at f0000000 (32-bit, prefetchable) [size=8M]
Expansion ROM at f0800000 [disabled] [size=64K]
cheers,
Gerd
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add support for the spice audio interface. With this patch applied
audio can be forwarded over the network from/to the spice client. Both
recording and playback is supported.
The driver is first in the driver list, but the can_be_default flag is
set only in case spice is active. So if you have the spice protocol
enabled the spice audio driver is the default one, otherwise whatever
comes first after spice in the list. Overriding the default using
QEMU_AUDIO_DRV works in any case.
[ v2: audio codestyle: add spaces before open parenthesis ]
[ v2: add const to silence array ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: malc <av1474@comtv.ru>
Signed-off-by: malc <av1474@comtv.ru>
The HDA bus supports up to 15 codecs, with addresses 0 ... 14.
We get that wrong in two places:
* When handing out addresses we accept address 15 as valid.
* The bitmasks for two registers (WAKEEN and STATESTS) don't
have bit 14 set.
This patch fixes it.
[ v2: codestyle: add braces ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
The HDA bus supports up to 15 codecs, with addresses 0 ... 14.
We get that wrong in two places:
* When handing out addresses we accept address 15 as valid.
* The bitmasks for two registers (WAKEEN and STATESTS) don't
have bit 14 set.
This patch fixes it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
This patch adds MSI support to the intel hda audio driver. It is
enabled by default, use '-device intel-hda,msi=0' to disable it.
[ v2: codestyle: add braces ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
When the guest updates the WAKEEN register we
must re-calculate the IRQ status.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
HDA: Honor WAKEEN bits when deciding to raise an interrupt on codec
status change. This prevents an interrupt storm with the Haiku HDA
driver which does not handle codec status changes in the irq handler.
Signed-off-by: François Revol <revol@free.fr>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Add pci exit callback for the intel-hda device and cleanup properly.
Also add an exit callback to the HDA bus implementation and make sure
it is called on qdev_free().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Fix scsi-disk to use the usual completion paths that involve rerror/werror
handling instead of directly completing the requests in cases where
bdrv_aio_readv/writev returns NULL.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Fix virtio-blk to use the usual completion path that involves werror handling
instead of directly completing the request in cases where bdrv_aio_flush
returns NULL.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When building on a 64 bit host which uses 'long' for int64_t,
GCC emits a warning:
CC block/blkverify.o
/src/qemu/block/blkverify.c: In function `blkverify_verify_readv':
/src/qemu/block/blkverify.c:304: warning: long long int format, long
unsigned int arg (arg 3)
Rework a77cffe7e9 to avoid the warning.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The cache content may be destroyed after a failed read, better not use it any
more.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This pulls the request completion for error cases from the caller to
scsi_disk_emulate_command. This should not change semantics, but allows to
reuse scsi_handle_write_error() for flushes in the next patch.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
