This will be needed once dataplane will be able to set it outside
the big QEMU lock.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Tested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Following the recent refactoring of virtio notifiers [1], more specifically
the patch ed08a2a0 ("virtio: use virtio_bus_set_host_notifier to
start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2]
by default, core virtio code requires 'ioeventfd_started' to be set
to true/false when the host notifiers are configured.

When vhost is stopped and started, however, there is a stop followed by
another start. Since ioeventfd_started was never set to true, the 'stop'
operation triggered by virtio_bus_set_host_notifier() will not result
in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves
the memory regions with stale notifiers and results on the next start
triggering the following assertion:

  kvm_mem_ioeventfd_add: error adding ioeventfd: File exists
  Aborted

This patch reintroduces (hopefully in a cleaner way) the concept
that was present with ioeventfd_disabled before the refactoring.
When ioeventfd_grabbed>0, ioeventfd_started tracks whether ioeventfd
should be enabled or not, but ioeventfd is actually not started at
all until vhost releases the host notifiers.

[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.htmlReported-by: NFelipe Franciosi <felipe@nutanix.com>
Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Reported-by: NAlex Williamson <alex.williamson@redhat.com>
Fixes: ed08a2a0 ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd")
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Tested-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

We must check for new virtqueue buffers after re-enabling notifications.
This prevents the race condition where the guest added buffers just
after we stopped popping the virtqueue but before we re-enabled
notifications.

I think the virtio-crypto code was based on virtio-net but this crucial
detail was missed.  virtio-net does not have the race condition because
it processes the virtqueue one more time after re-enabling
notifications.

Cc: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NGonglei <arei.gonglei@huawei.com>

Proposes best practices on how to use PCI Express/PCI device
in PCI Express based machines and explain the reasoning behind them.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

These are not used anymore.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The legacy vring layout is not used anymore as we use the separate
mappings even for legacy devices.
This patch simply removes it.

This also fixes a bug with virtio 1 devices when the vring descriptor table
is mapped at a higher address than the used vring because the following
function may return an insanely great value:

hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
{
    return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
           virtio_queue_get_used_size(vdev, n);
}

and the mapping fails.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

With virtio 1, the vring layout is split in 3 separate regions of
contiguous memory for the descriptor table, the available ring and the
used ring, as opposed with legacy virtio which uses a single region.

In case of memory re-mapping, the code ensures it doesn't affect the
vring mapping. This is done in vhost_verify_ring_mappings() which assumes
the device is legacy.

This patch changes vhost_verify_ring_mappings() to check the mappings of
each part of the vring separately.

This works for legacy mappings as well.

Cc: qemu-stable@nongnu.org
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

and use it to replace the raw number
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

to make the code more clearer
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

Rename it to nvdimm_dsm_handle_reserved_root_method
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

fixed the English issue and code-style issue
Suggested-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

and use these codes to refine the code
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

Rename it to nvdimm_plug()
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

inline buf_size to refine the code a bit
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

Its behavior has been changed as the nvdimm device which is being
realized also will be handled in this function, so rename it to
reflect the fact
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

Improve the description and clearly document the length field
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

To make the code more clearer, we
1) check ram_slots first, and build ssdt & nfit only when it is available
2) use nvdimm_get_plugged_device_list() to check if there is nvdimm device
   plugged
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

as it is never called when nvdimm hotplug happens
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

as they use completely different way to handle hotplug event
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

as there is a global lock to protect vm-exit handlers and
QMP/monitor, this lock can be dropped
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

as nvdimm acpi is okay to build fit when the nvdimm device
has not been 'realized'
Suggested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>

Commit 31190ed7 added a migration blocker in vhost_dev_init() to
check if memfd would succeed. It is better if this blocker first
checks if vhost backend requires shared log. This will avoid a
situation where a blocker is added inappropriately (e.g. shared
log allocation fails when vhost backend doesn't support it).
Signed-off-by: NRafael David Tinoco <rafael.tinoco@canonical.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

virtio 1.0 spec says this is a legacy feature bit,
hide it from guests in modern mode.

Note: for cross-version migration compatibility,
we keep the bit set in host_features.
The result will be that a guest migrating cross-version
will see host features change under it.
As guests only seem to read it once, this should
not be an issue. Meanwhile, will work to fix guests to
ignore this bit in virtio1 mode, too.

Cc: qemu-stable@nongnu.org
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

Legacy features are those that transitional devices only
expose on the legacy interface.
Allow different ones per device class.

Cc: qemu-stable@nongnu.org # dependency for the next patch
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

We should not use cpu_to_le16() here, instead each of device/function
value is stored in a 8 byte field.
Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Currently the virtio-crypto device hasn't supported
hotpluggable and live migration well. Let's tag it
as not hotpluggable and migration actively and reopen
them once we support them well.
Suggested-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The function does not fully initialize the returned VirtQueueElement and should
be used only internally from the virtio module.
Signed-off-by: NLadi Prosek <lprosek@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The function undoes the effect of virtqueue_pop and doesn't do anything
destructive or irreversible so virtqueue_unpop is a more fitting name.
Signed-off-by: NLadi Prosek <lprosek@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Using uint8_t for source id will lose bus num and get the
wrong/invalid IOTLB entry. Fixing by using uint16_t instead and
enlarge level shift.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
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>

There are only very old and orphaned stable branches listed
in the MAINTAINERS file - so this section is pretty useless
nowadays. Let's remove it.
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

These files are currently unmaintained.

I'm proposing that Fam and I co-maintain them; under the model that
whomever between us isn't authoring a given series will be responsible
for reviewing it.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Acked-by: NFam Zheng <famz@redhat.com>
Acked-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

I recently added new files to the source tree that are not
covered by any maintainer yet -- and since every new source
file should have a maintainer nowadays, I volunteer to look
after these files now, too.
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

disas/m68k.c obviously belong to the m68k CPU section in
the MAINTAINERS file, but remove the hw/m68k/ directory
here since it only contains machine (not CPU) related
files, as requested by Laurent. Add the machine related
files to the right machine sections instead.
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

Both files seem to belong to the Sun4m machine.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

The files w/cpu/a*mpcore.c are already assigned to the ARM CPU
section, but the corresponding headers include/hw/cpu/a*mpcore.h
are still missing.

The file hw/*/imx* are already assigned to the i.MX31 machine, but
the corresponding header files include/hw/*/imx* are still missing.

The file hw/misc/arm_integrator_debug.c seems to belong to Integrator
CP, hw/cpu/realview_mpcore.c seems to belong to Real View, and
hw/misc/mst_fpga.c seems to belong to PXA2XX.

And the files hw/misc/zynq* and include/hw/misc/zynq* seem to belong
to the Xilinx Zynq machine.
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Acked-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>

On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.

To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.

We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Message-id: 20161109102752.13255-1-samuel.thibault@ens-lyon.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The printscreen/sysrq and pause/break keys currently don't work for guests
using -usbdevice keyboard when accessed through vnc with a gtk-vnc based
client.

The reason for this is a mismatch between gtk-vnc and qemu in how these keys
should be mapped to XT keycodes.

On the original IBM XT these keys behaved differently than other keys.

Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html:

The keys PrtSc/SysRq and Pause/Break are special. The former produces
scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37
together with Shift or Ctrl, but 54 together with (left or right) Alt.  (And
one gets the expected sequences upon release.  But see below.) The latter
produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier)
and nothing at all upon release.  However, together with (left or right)
Ctrl, one gets e0 46 e0 c6, and again nothing at release.  It does not
repeat.

Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to send
raw XT keycodes directly to qemu, but the specification doesn't explicitly
specify how to map such long/complicated keycode sequences.  From the spec
(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message)

The keycode is the XT keycode that produced the keysym. An XT keycode is an
XT make scancode sequence encoded to fit in a single U32 quantity.  Single
byte XT scancodes with a byte value less than 0x7f are encoded as is.
2-byte XT scancodes whose first byte is 0xe0 and second byte is less than
0x7f are encoded with the high bit of the first byte set

hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37
-> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54).
Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in
RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46
-> 0xc6 in RFB).

See keymaps.cvs in gtk-vnc for the mapping used:
https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150

Now, it isn't obvious to me which sequence is really "right", but as the
0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like
the pragmatic solution to me.  The USB HID keyboard boot protocol used by
hid.c doesn't have any other mapping applicable to these keys.

The other guest keyboard interfaces (ps/2, virtio, ..) are not affected,
because they handle these keys differently.
Signed-off-by: NPeter Korsgaard <peter@korsgaard.com>
Message-id: 20161028145132.1702-1-peter@korsgaard.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

GDK_KEY_Delete is only defined with gtk version 2.22 and newer,
on older versions this key was called GDK_Delete instead.
Since this is the case for all GDK_KEY_* defines, change the
already existing preprocessor check there to test for version 2.22,
so we know that we can remove this code block in case we require
that version as a minimum one day.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1478081328-25515-1-git-send-email-thuth@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>