If an error occurs in a section load, set the file error flag
so that the transport can get notified to do a cleanup.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NMichael R. Hines <michael@hinespot.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

If we fail for some reason (e.g. a mismatched RAMBlock)
and it's set the qemu_file error flag, pass that error back to the
peer so it can clean up rather than waiting for some higher level
progress.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NMichael R. Hines <michael@hinespot.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Report the values when a comparison fails; together with
the previous patch that prints the device and field names
this should give a good idea of why loading the migration failed.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

When a field fails to load (typically due to a limit
check, or a call to a get/put) report the device and field
to give an indication of the cause.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

ui: vnc cleanups, input-linux kbd fix.

# gpg: Signature made Thu 13 Oct 2016 09:47:43 BST
# gpg:                using RSA key 0x4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/pull-ui-20161013-1:
  input-linux: initialize key state
  ui: rename vnc_init_state to vnc_start_protocol
  ui: move some initialization out of vnc_init_state
  ui: remove bogus call to reset_keys() in vnc_init_state
  ui: remove bogus call to graphic_hw_update() in vnc_listen_io
  ui: refactor method for setting up VncDisplay auth types
  ui: rename misleading 'VncDisplay' variables
  ui: remove 'ws_tls' field from VncState
  ui: remove 'enabled' and 'ws_enabled' fields from VncState
  ui: remove misleading comment from vnc_init_state
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

That commit mis-used mux char: the frontend are multiplexed, not the
backend. Fix the regression preventing "c-a c" to switch the focus. The
following patches will fix the crash (when leaving or removing frontend)
by tracking frontends with handler tags.

This reverts commit 949055a2.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

[stable] ppc-for-2.7 queue

# gpg: Signature made Thu 13 Oct 2016 06:03:37 BST
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.7-20161013:
  ppc: Check the availability of transactional memory
  hw/ppc/spapr: Fix the selection of the processor features
  hw/ppc/spapr: Move code related to "ibm,pa-features" to a separate function
  linux-headers: update
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Query input device keys, initialize state accordingly, so the correct
state is reflected in case any key is pressed at initialization time.
There is a high chance for this to actually happen for the 'enter' key
in case you start qemu with a terminal command (directly or virsh).

When finding any pressed keys the input grab is delayed until all keys
are lifted, to avoid confusing guest and host with appearently stuck
keys.
Reported-by: NMuted Bytes <mutedbytes@gmail.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1476277384-30365-1-git-send-email-kraxel@redhat.com

Rename the vnc_init_state method to reflect what its actual
purpose is, to discourage future devs from using it for more
general state initialization.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-10-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Most of the fields in VncState are initialized in the
vnc_connect() method, but some are done in vnc_init_state()
instead.

The purpose of having vnc_init_state() is to delay starting
of the VNC wire protocol until after the websockets handshake
has completed. As such the vnc_init_state() method only needs
to be used for initialization that is dependant on the wire
protocol running.

This also lets us get rid of the initialized boolean flag
from the VncState struct.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-9-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The vnc_init_state method calls reset_keys() to reset the
modifier key state. This was originally added in

  commit 53762ddb
  Author: malc <malc@c046a42c-6fe2-441c-8c8c-71466251a162>
  Date:   Mon Dec 1 20:57:52 2008 +0000

    Reset the key modifiers upon client connect

This was valid at this time because there was only the
single VncState object which was persistent across client
connections and so needed resetting.

The persistent data was later split off into VncDisplay
and VncState was allocated at time of client connection:

  commit 753b4053
  Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
  Date:   Mon Feb 16 14:59:30 2009 +0000

    Support multiple VNC clients (Brian Kress)

at which point the modifier state is always 0 due to
use of g_new0. As such the reset_keys() call has been
a no-op ever since.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-8-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Just before accepting a new client connection the vnc_listen_io
method calls graphic_hw_update(). This is bogus because there
is a call to this method already in vnc_state_init() and the
client doesn't need up2date graphics console before reaching
that.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-7-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

There is a lot of repeated code in the auth type setup method,
particularly around checking TLS credential types. Refactor
it to reduce duplication and instead of having one method
do both plain and websockets at once, call it separately
for each.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-6-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Normally code declares 'VncDisplay *vd' or 'VncState *vs'
but there are a bunch of places which misleadingly declare
'VncDisplay *vs'.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-5-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The 'ws_tls' field in VncState is only ever representing
the result of 'tlscreds != NULL' and is thus pointless.
Replace use of 'ws_tls' with a direct check against
'tlscreds'
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-4-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The 'ws_enabled' field is never used outside of the
vnc_display_open method, so can be a local variable.

The 'enabled' field is easily replaced by a check
for whether 'lsock' is non-NULL.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-3-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The last line in vnc_init_state() says

     /* vs might be free()ed here */

This was added in

  commit 198a0039
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   Tue Jun 16 14:19:48 2009 +0200

    vnc: rework VncState release workflow.

because the preceeding 'vnc_update_client()' could indeed
release the VncState instance.

The call to vnc_update_client() was removed not long after
though in

  commit 1fc62412
  Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Mon Aug 3 10:54:32 2009 +0100

    single vnc server surface

and so the comment has been wrong ever since
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-2-git-send-email-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

KVM-PR currently does not support transactional memory, and the
implementation in TCG is just a fake. We should not announce TM
support in the ibm,pa-features property when running on such a
system, so disable it by default and only enable it if the KVM
implementation supports it (i.e. recent versions of KVM-HV).
These changes are based on some earlier work from Anton Blanchard
(thanks!).
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit bac3bf28)

The current code uses pa_features_206 for POWERPC_MMU_2_06, and
for everything else, it uses pa_features_207. This is bad in some
cases because there is also a "degraded" MMU version of ISA 2.06,
called POWERPC_MMU_2_06a, which should of course use the flags for
2.06 instead. And there is also the possibility that the user runs
the pseries machine with a POWER5+ or even 970 processor. In that
case we certainly do not want to set the flags for 2.07, and rather
simply skip the setting of the pa-features property instead.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 4cbec30d)

The function spapr_populate_cpu_dt() has become quite big
already, and since we likely have to extend the pa-features
property for every new processor generation, it is nicer
if we put the related code into a separate function.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 230bf719)

Update headers against 4.8-rc2.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>

various usb bugfixes
some xhci cleanups

# gpg: Signature made Wed 12 Oct 2016 13:38:27 BST
# gpg:                using RSA key 0x4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/pull-usb-20161012-1:
  usb-redir: allocate buffers before waking up the host adapter
  usb: Fix incorrect default DMA offset.
  usb: fix serial generator
  xhci: make xhci_epid_to_usbep accept XHCIEPContext
  xhci: drop XHCITransfer->{slotid,epid}
  xhci: add & use xhci_kick_epctx()
  xhci: drop XHCITransfer->xhci
  xhci: use linked list for transfers
  xhci: drop unused comp_xfer field
  xhci: decouple EV_QUEUE from TD_QUEUE
  xhci: limit the number of link trbs we are willing to process
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Needed to make sure usb redirection is prepared to actually handle the
callback from the usb host adapter.  Without this interrupt endpoints
don't work on xhci.

Note: On ehci the usb_wakeup() call only schedules a BH for the actual
work, which hides this bug because the allocation happens before ehci
calls back even without this patch.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Message-id: 1476096313-7730-1-git-send-email-kraxel@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The default DMA offset is set to 3. When the property is not set by
the consumer, the default causes DMA access to be shifted by 3
bytes. In PXA, this results in incorrect DMA access, leading to error
notification in the USB controller driver. A better default would be
0, so that there is no offset, when the consumer does not specify one.
Signed-off-by: NVijay Kumar B. <vijaykumar@zilogic.com>
Reviewed-by: NDeepak S. <deepak@zilogic.com>
Message-id: 1475060958-7760-1-git-send-email-vijaykumar@zilogic.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

snprintf return value is *not* the number of chars written into the
buffer, but the number of chars needed.  So in case the buffer is too
small you can go alloc a bigger one and try again.  But that also means
you can't simply use the return value for the next snprintf call
without checking beforehand that things did actually fit.

Problem is that usb_desc_create_serial didn't perform that check, so a
loooong path string (can happen with deep pci-bridge nesting) results in
the third snprintf call smashing the stack.

Fix this by throwing out all the snpintf calls and use g_strdup_printf
instead.

https://bugzilla.redhat.com/show_bug.cgi?id=1381630Reported-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1475659998-22045-1-git-send-email-kraxel@redhat.com

All callsites have a XHCIEPContext pointer anyway, so we can just pass
it directly instead of fiddeling with slotid and epid.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-9-git-send-email-kraxel@redhat.com

We can use XHCITransfer->epctx->{slotid,epid} instead.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-8-git-send-email-kraxel@redhat.com

xhci_kick_epctx is a xhci_kick_ep variant which takes an XHCIEPContext
as input instead of slotid and epid.  So in case we have a XHCIEPContext
at hand at the callsite we can just pass it directly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-7-git-send-email-kraxel@redhat.com

Use XHCITransfer->epctx->xhci instead.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-6-git-send-email-kraxel@redhat.com

xhci has a fixed number of 24 (TD_QUEUE) XHCITransfer structs per
endpoint, which turns out to be a problem for usb3 devices with 32 (or
more) bulk streams.  xhci re-checks the trb rings on every finished
transfer to make sure it'll pick up any pending work.  But that scheme
breaks in case the first transfer of a ring can't be started because we
ran out of XHCITransfer structs already.

So remove static XHCITransfer array from XHCIEPContext.  Use a linked
list instead, and allocate/free XHCITransfer as needed.  Add helper
functions to allocate & initialize and to cleanup & release
XHCITransfer structs.  That also simplifies trb management, we never
have to realloc XHCITransfer->trbs because we don't reuse XHCITransfer
structs any more.

New dynamic limit for in-flight xhci transfers per endpoint is
number-of-streams + 16.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-5-git-send-email-kraxel@redhat.com

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-4-git-send-email-kraxel@redhat.com

EV_QUEUE must not change because an array of that size is part of live
migration data.  Hard-code current value there, so we can touch TD_QUEUE
without breaking live migration.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-3-git-send-email-kraxel@redhat.com

Needed to avoid we run in circles forever in case the guest builds
an endless loop with link trbs.
Reported-by: NLi Qiang <liqiang6-s@360.cn>
Tested-by: NP J P <ppandit@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1476096382-7981-1-git-send-email-kraxel@redhat.com

# gpg: Signature made Wed 12 Oct 2016 09:43:03 BST
# gpg:                using RSA key 0x9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* remotes/stefanha/tags/tracing-pull-request:
  trace: Add missing execution mode of guest events
  trace: introduce a formal group name for trace events
  trace: pass trace-events to tracetool as a positional param
  trace: push reading of events up a level to tracetool main
  trace: rename _read_events to read_events
  trace: get rid of generated-events.h/generated-events.c
  trace: dynamically allocate event IDs at runtime
  trace: dynamically allocate trace_dstate in CPUState
  trace: provide mechanism for registering trace events
  trace: don't abort qemu if ftrace can't be initialized
  trace: emit name <-> ID mapping in simpletrace header
  trace: remove the TraceEventID and TraceEventVCPUID enums
  trace: give each trace event a named TraceEvent struct
  trace: break circular dependency in event-internal.h
  trace: remove duplicate control.h includes in generated-tracers.h
  trace: remove global 'uint16 dstate[]' array
  trace: remove some now unused functions
  trace: convert code to use event iterators
  trace: add trace event iterator APIs
  trace: move colo trace events to net/ sub-directory
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Add missing execution mode documentation for the 'guest_cpu_enter' and
'guest_cpu_reset' events.
Signed-off-by: NLluís Vilanova <vilanova@ac.upc.edu>
Message-id: 147566900921.7708.656450813307396468.stgit@fimbulvetr.bsc.es
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

The declarations in the generated-tracers.h file are
assuming there's only ever going to be one instance
of this header, as they are not namespaced. When we
have one header per event group, if a single source
file needs to include multiple sets of trace events,
the symbols will all clash.

This change thus introduces a '--group NAME' arg to the
'tracetool' program. This will cause all the symbols in
the generated header files to be given a unique namespace.

If no group is given, the group name 'common' is used,
which is suitable for the current usage where there is
only one global trace-events file used for code generation.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NLluís Vilanova <vilanova@ac.upc.edu>
Message-id: 1475588159-30598-21-git-send-email-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Instead of reading the contents of 'trace-events' from stdin,
accept the filename as a positional parameter. This also
allows for reading from multiple files, though this facility
is not used at this time.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-20-git-send-email-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Move the reading of events out of the 'tracetool.generate'
method and into tracetool.main, so that the latter is not
tied to generating from a single source of events.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-19-git-send-email-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

The _read_events method is used by callers outside of
its module, so should be a public method, not private.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-18-git-send-email-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Currently the generated-events.[ch] files contain the
event dstates, constants and TraceEvent structs, while the
generated-tracers.[ch] files contain the actual trace
probe logic. With the removal of usage of the event enums
from the API there is no longer any compelling reason for
the separation between these files. The generated-events.h
content is only ever needed from the generated-tracers.[ch]
files.

The enums/constants/structs from generated-events.[ch] are
thus moved into the generated-tracers.[ch], so that there
is one less file to be generated.
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-17-git-send-email-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>