Similar to the cmd_write_pio fix, update the nsector count and
ide sector before we invoke ide_transfer_start.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-3-git-send-email-jsnow@redhat.com

We need to adjust the sector being written to
prior to calling ide_transfer_start, otherwise
we'll write to the same sector again.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-2-git-send-email-jsnow@redhat.com

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Cc: qemu-stable <qemu-stable@nongnu.org>
Reported-by: NLidonglin <lidonglin@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Ohci does't support hotplugging/hotunplugging yet, but
existing resource cleanup leak logic likes ehci/uhci.

Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Cc: qemu-stable <qemu-stable@nongnu.org>
Reported-by: NLidonglin <lidonglin@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This reverts commit 13704e4c.

With the Intel microcode update that removed HLE and RTM, there will be
different kinds of Haswell and Broadwell CPUs out there: some that still
have the HLE and RTM features, and some that don't have the HLE and RTM
features. On both cases people may be willing to use the pc-*-2.3
machine-types.

So instead of making the CPU model results confusing by making it depend
on the machine-type, keep HLE and RTM on the existing Haswell and
Broadwell CPU models. The plan is to introduce "Haswell-noTSX" and
"Broadwell-noTSX" CPU models later, for people who have CPUs that don't
have TSX feature available.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Since commit
   dd0247e0 pc: acpi: mark all possible CPUs as enabled in SRAT
Linux kernel actually tries to use CPU to Node mapping from
QEMU provided SRAT table instead of discarding it, and that
in some cases breaks build_sched_domains() which expects
sane mapping where cores/threads belonging to the same socket
are on the same NUMA node.

With current default round-robin mapping of VCPUs to nodes
guest ends-up with cores/threads belonging to the same socket
being on different NUMA nodes.

For example with following CLI:

   qemu-system-x86_64 -m 4G \
         -cpu Opteron_G3,vendor=AuthenticAMD \
         -smp 5,sockets=1,cores=4,threads=1,maxcpus=8 \
         -numa node,nodeid=0 -numa node,nodeid=1

2.6.32 based kernels will hang on boot due to incorrectly built
sched_group-s list in update_sd_lb_stats()

Replacing default mapping with a manual, where VCPUs belonging to
the same socket are on the same NUMA node, fixes the issue for
guests which can't handle nonsense topology i.e. changing CLI to:
  -numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7

So instead of simply scattering VCPUs around nodes, provide
callback to map the same socket VCPUs to the same NUMA node,
which is what guests would expect from a sane hardware/BIOS.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Users of virtio-serial may want to know when a port becomes writable.  A
port can stop accepting writes if the guest port is open but not being
read from.  In this case, data gets queued up in the virtqueue, and
after the vq is full, writes to the port do not succeed.

When the guest reads off a vq element, and adds a new one for the host
to put data in, we can tell users the port is available for more writes,
via the new ->guest_writable() callback.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Coverity reports a truncation due to cast operation on operand
reltab->sh_size from 64 bits to 32 bits for calls of load_at.

Fix the types of the function arguments to match their use in
function load_at: the offset is used for lseek which takes an
off_t parameter, the size is used for g_malloc and read.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

The pc-dimm option presented on device list (by argument "-device \?")
is the unique option that don't have any information about it. This
patch adds a description for the pc-dimm device to help users to
identify it.
Signed-off-by: NPaulo Vital <paulo.vital@profitbricks.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

This is a continuation of the work started in commit 565f65d2:
"error: Use error_report_err() where appropriate"
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Cc: Michael Tokarev <mjt@tls.msk.ru>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Sparse report:

hw/display/vga.c:2000:5: warning: returning void-valued expression
hw/intc/arm_gic.c:707:9: warning: returning void-valued expression
hw/intc/etraxfs_pic.c:138:9: warning: returning void-valued expression
hw/nvram/fw_cfg.c:475:5: warning: returning void-valued expression
hw/timer/a9gtimer.c:124:5: warning: returning void-valued expression
hw/tpm/tpm_tis.c:794:5: warning: returning void-valued expression
hw/usb/hcd-musb.c:558:9: warning: returning void-valued expression
hw/usb/hcd-musb.c:776:13: warning: returning void-valued expression
hw/usb/hcd-musb.c:867:5: warning: returning void-valued expression
hw/usb/hcd-musb.c:932:5: warning: returning void-valued expression
include/qom/cpu.h:584:5: warning: returning void-valued expression
monitor.c:4686:13: warning: returning void-valued expression
monitor.c:4690:13: warning: returning void-valued expression

Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andreas Färber <afaerber@suse.de>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Sparse report:

arm/nseries.c:1406:5: warning: returning void-valued expression
arm/nseries.c:1411:5: warning: returning void-valued expression

Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Sparse report:

arm/omap1.c:1015:9: warning: returning void-valued expression
arm/omap1.c:1084:9: warning: returning void-valued expression
arm/omap1.c:1178:9: warning: returning void-valued expression
arm/omap1.c:1287:9: warning: returning void-valued expression
arm/omap1.c:1382:9: warning: returning void-valued expression
arm/omap1.c:1650:9: warning: returning void-valued expression
arm/omap1.c:1778:9: warning: returning void-valued expression
arm/omap1.c:1985:9: warning: returning void-valued expression
arm/omap1.c:210:9: warning: returning void-valued expression
arm/omap1.c:2213:9: warning: returning void-valued expression
arm/omap1.c:2352:9: warning: returning void-valued expression
arm/omap1.c:2447:9: warning: returning void-valued expression
arm/omap1.c:2640:9: warning: returning void-valued expression
arm/omap1.c:317:9: warning: returning void-valued expression
arm/omap1.c:3413:13: warning: returning void-valued expression
arm/omap1.c:3414:13: warning: returning void-valued expression
arm/omap1.c:3415:14: warning: returning void-valued expression
arm/omap1.c:3589:9: warning: returning void-valued expression
arm/omap1.c:443:9: warning: returning void-valued expression
arm/omap1.c:588:9: warning: returning void-valued expression
arm/omap1.c:860:9: warning: returning void-valued expression
arm/omap2.c:1362:9: warning: returning void-valued expression
arm/omap2.c:450:9: warning: returning void-valued expression
arm/omap2.c:695:9: warning: returning void-valued expression
arm/omap2.c:760:9: warning: returning void-valued expression
hw/char/omap_uart.c:115:9: warning: returning void-valued expression
hw/display/omap_dss.c:1019:9: warning: returning void-valued expression
hw/display/omap_dss.c:215:9: warning: returning void-valued expression
hw/display/omap_dss.c:380:9: warning: returning void-valued expression
hw/display/omap_dss.c:739:9: warning: returning void-valued expression
hw/display/omap_dss.c:931:9: warning: returning void-valued expression
hw/dma/omap_dma.c:139:5: warning: returning void-valued expression
hw/dma/omap_dma.c:1505:9: warning: returning void-valued expression
hw/dma/omap_dma.c:1860:9: warning: returning void-valued expression
hw/gpio/omap_gpio.c:116:9: warning: returning void-valued expression
hw/misc/omap_gpmc.c:627:9: warning: returning void-valued expression
hw/misc/omap_l4.c:85:9: warning: returning void-valued expression
hw/misc/omap_sdrc.c:95:9: warning: returning void-valued expression
hw/misc/omap_tap.c:98:9: warning: returning void-valued expression
hw/sd/omap_mmc.c:409:9: warning: returning void-valued expression
hw/ssi/omap_spi.c:229:9: warning: returning void-valued expression
hw/timer/omap_gptimer.c:447:9: warning: returning void-valued expression

Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Sparse report:

9pfs/virtio-9p.c:1953:9: warning: returning void-valued expression
9pfs/virtio-9p-handle.c:143:5: warning: returning void-valued expression
9pfs/virtio-9p-handle.c:160:5: warning: returning void-valued expression
9pfs/virtio-9p-local.c:384:5: warning: returning void-valued expression
9pfs/virtio-9p-local.c:415:5: warning: returning void-valued expression
9pfs/virtio-9p-proxy.c:672:5: warning: returning void-valued expression
9pfs/virtio-9p-proxy.c:689:5: warning: returning void-valued expression

Cc: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Code comment says "table 6-2" but in fact it's is not a table, it is
"Figure 6-2" on page 479.

Cc: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reported-by: NMichael Tokarev <mjt@tls.msk.ru>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Error Status Register, so this patch fix a wrong definition
for PCI_ERR_COR_STATUS register with w1cmask type.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Refer to "PCI Express Base Spec3.0", this comments can't
fit the description in spec, so we should fix them.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

when specify TLP Prefix log as using pcie_aer_inject_error,
the TLP prefix log is always discarded. because the check
is incorrect, the End-End TLP Prefix Supported bit
(PCI_EXP_DEVCAP2_EETLPP) should be in Device Capabilities 2 Register.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

from pcie spec 7.8.17, the End-End TLP Prefix Blocking bit local
is 15(e.g. 0x8000) in device control 2 register.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

if k->set_host_notifier failed, VirtIOSCSIVring *r will leak
Signed-off-by: NBo Su <subo7@huawei.com>
Message-Id: <1426671732-80213-1-git-send-email-subo7@huawei.com>
Reviewed-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Hotplugging a scsi-disk may trigger the assertion in qemu_sgl_concat.

    qemu-system-x86_64: qemu/hw/scsi/virtio-scsi.c:115: qemu_sgl_concat:
    Assertion `skip == 0' failed.

This is introduced by commit 55783a55 (virtio-scsi: work around bug in
old BIOSes) which didn't check out_num when accessing out_sg[0].iov_len
(the same to in sg). For virtio_scsi_push_event, looking into out_sg
doesn't make sense because 0 req_size is intended.

Cc: qemu-stable@nongnu.org
[Cc'ing qemu-stable because 55783a55 did it too]
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-Id: <1426233354-525-1-git-send-email-famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Boards that do not include an USB controller should not provide
USB devices. However, when running "qemu-system-s390x -device help"
for example, there's still a usb-hub, usb-kbd, usb-mouse and
usb-tablet in the list of "supported" devices. Let's fix that
by compiling and linking the USB files only if it is really
necessary.
Signed-off-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Instead of passing icc_bridge from the PC initialization code to
cpu_x86_create(), make the PC initialization code attach the CPU to
icc_bridge.

The only difference here is that icc_bridge attachment will now be done
after x86_cpu_parse_featurestr() is called. But this shouldn't make any
difference, as property setters shouldn't depend on icc_bridge.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This avoids cluttering GTester output with irrelevant warnings.

Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Move non-qdev-gpio[*] from /machine into /machine/unattached.
For the PC this moves 25 nodes from the stable namespace into the unstable.

Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Tested-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

qerror_report_err() is a transitional interface to help with
converting existing monitor commands to QMP.  It should not be used
elsewhere.

usb_msd_password_cb() is only called from within an HMP command
handler.  Replace by error_report_err().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When the image is encrypted, QMP device_add creates the device, defers
actually attaching it to when the key becomes available, then returns
an error.  This is wrong.  device_add must either create the device
and succeed, or do nothing and fail.

The bug is in usb_msd_realize_storage().  It posts an error with
qerror_report_err(), and returns success.  Device realization relies
on the return value, and completes.  The QMP monitor, however, relies
on the posted error, and sends it in an error reply.

Reproducer:

    $ qemu-system-x86_64 -nodefaults -display none -usb -qmp stdio -drive if=none,id=foo,file=geheim.qcow2
    {"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}}
    { "execute": "qmp_capabilities" }
    {"return": {}}
    { "execute": "device_add", "arguments": { "driver": "usb-storage", "id": "bar", "drive": "foo" } }
    {"error": {"class": "DeviceEncrypted", "desc": "'foo' (geheim.qcow2) is encrypted"}}

Even though we got an error back, the device got created just fine.
To demonstrate, let's unplug it again:

    {"execute":"device_del","arguments": { "id": "bar" } }
    {"timestamp": {"seconds": 1426003440, "microseconds": 237181}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/bar/bar.0/legacy[0]"}}
    {"timestamp": {"seconds": 1426003440, "microseconds": 238231}, "event": "DEVICE_DELETED", "data": {"device": "bar", "path": "/machine/peripheral/bar"}}
    {"return": {}}

Fix by making usb_msd_realize_storage() fail properly.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

monitor_read_bdrv_key_start() does several things:

1. If no key is needed, call completion_cb() and succeed

2. If we're in QMP context, call qerror_report_err() and fail

3. Start reading the key in the monitor.

This is two things too many.  Inline 1. and 2. into its callers
monitor_read_block_device_key() and usb_msd_realize_storage().

Since monitor_read_block_device_key() only ever runs in HMP context,
drop 2. there.

The next commit will clean up the result in usb_msd_realize_storage().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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

Commit 457215ec "ohci: Use QOM realize for OHCI" converted only
"sysbus-ohci".  Finish the job: convert "pci-ohci".
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The previous commit broke the additional messages explaining the error
messages.  Improve the error messages, so they don't need explaining
so much.  Helps QMP users as well, unlike additional explanations.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This loses the messages explaining the error printed with
error_printf_unless_qmp().  The next commit will make up for the loss.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Use DeviceClass::realize() and TypeInfo::instance_init() instead of
the deprecated SysBusDevice::init().
Signed-off-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

All four leaks are similar, so fix them in one patch.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

We don't validate the existence of handle_output which may let a buggy
guest to trigger a SIGSEV easily. E.g:

1) write 10 to queue_sel to a virtio net device with only 1 queue
2) setup an arbitrary pfn
3) then notify queue 10

Fixing this by validating the existence of handle_output before.

Cc: qemu-stable@nongnu.org
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDon Koch <dkoch@verizon.com>
Reviewed-by: NFam Zheng <famz@redhat.com>

Older PC machine types might by accident be backwards live migration compatible,
but with the new vmdesc self-describing blob in our live migration stream we
would break that compatibility.

Also users wouldn't expect massive behaviorial differences when updating to a
new version of QEMU while retaining their old machine type, especially not
potential breakage in tooling around live migration.

So disable vmdesc submission for old PC machine types.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

We now always send a JSON blob describing the migration file format as part
of the migration stream. However, some tools built around QEMU have proven
to stumble over this.

This patch gives the user the chance to disable said self-describing part of
the migration stream. To disable vmdesc submission, just add

  -machine suppress-vmdesc=on

to your QEMU command line.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NJuan Quintela <quintela@redhat.com>