On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to PCI memory space:
- A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
- A 64-bit window which maps onto a large region somewhere high in PCI
address space (traditionally this used an identity mapping from guest
physical address to PCI address, but that's not always the case)
The qemu implementation in spapr-pci-host-bridge, however, only supports a
single outbound MMIO window, however. At least some Linux versions expect
the two windows however, so we arranged this window to map onto the PCI
memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
windows, the "32-bit" window from 2G..4G and the "64-bit" window from
4G..~64G.
This approach means, however, that the 64G window is not naturally aligned.
In turn this limits the size of the largest BAR we can map (which does have
to be naturally aligned) to roughly half of the total window. With some
large nVidia GPGPU cards which have huge memory BARs, this is starting to
be a problem.
This patch adds true support for separate 32-bit and 64-bit outbound MMIO
windows to the spapr-pci-host-bridge implementation, each of which can
be independently configured. The 32-bit window always maps to 2G.. in PCI
space, but the PCI address of the 64-bit window can be configured (it
defaults to the same as the guest physical address).
So as not to break possible existing configurations, as long as a 64-bit
window is not specified, a large single window can be specified. This
will appear the same way to the guest as the old approach, although it's
now implemented by two contiguous memory regions rather than a single one.
For now, this only adds the possibility of 64-bit windows. The default
configuration still uses the legacy mode.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Currently the default PCI host bridge for the 'pseries' machine type is
constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in
guest memory space. This means that if > 1TiB of guest RAM is specified,
the RAM will collide with the PCI IO windows, causing serious problems.
Problems won't be obvious until guest RAM goes a bit beyond 1TiB, because
there's a little unused space at the bottom of the area reserved for PCI,
but essentially this means that > 1TiB of RAM has never worked with the
pseries machine type.
This patch fixes this by altering the placement of PHBs on large-RAM VMs.
Instead of always placing the first PHB at 1TiB, it is placed at the next
1 TiB boundary after the maximum RAM address.
Technically, this changes behaviour in a migration-breaking way for
existing machines with > 1TiB maximum memory, but since having > 1 TiB
memory was broken anyway, this seems like a reasonable trade-off.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Currently the functions in pci-spapr.c (like pci-pc.c on which it's based)
don't distinguish between 32-bit and 64-bit PCI MMIO. At the moment, the
qemu side implementation is a bit weird and has a single MMIO window
straddling 32-bit and 64-bit regions, but we're likely to change that in
future.
In any case, pci-pc.c - and therefore the testcases using PCI - only handle
32-bit MMIOs for now. For spapr despite whatever changes might happen with
the MMIO windows, the 32-bit window is likely to remain at 2..4 GiB in PCI
space.
So, explicitly limit pci-spapr.c to 32-bit MMIOs for now, we can add 64-bit
MMIO support back in when and if we need it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
In pci-spapr.c (as in pci-pc.c from which it was derived), the
pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1]
essentially define the region of PCI (not CPU) addresses in which MMIO
or PIO BARs respectively will be allocated.
The size value is relative to the start value. But in pci-spapr.c it is
set to the entire size of the window supported by the (emulated) hardware,
but the start values are *not* at the beginning of the emulated windows.
That means if you tried to map enough PCI BARs, we'd messily overrun the
IO windows, instead of failing in iomap as we should.
This patch corrects this by calculating the hole sizes from the location
of the window in PCI space and the hole start.
[1] Those are bad names, but that's a problem for another time.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
The libqos code for accessing PCI on the spapr machine type uses IOBASE()
and MMIOBASE() macros to determine the address in the CPU memory map of
the windows to PCI address space.
This is a detail of the implementation of PCI in the machine type, it's not
specified by the PAPR standard. Real guests would get the addresses of the
PCI windows from the device tree.
Finding the device tree in libqos would be awkward, but we can at least
localize this knowledge of the implementation to the init function, saving
it in the QPCIBusSPAPR structure for use by the accessors.
That leaves only one place to fix if we alter the location of the PCI
windows, as we're planning to do.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
The existing implementation remains same and ics-base is introduced. The
type name "ics" is retained, and all the related functions renamed as
ics_simple_*
This will allow different implementations for the source controllers
such as the MSI support of PHB3 on Power8 which uses in-memory state
tables for example.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[ clg: added ICS_BASE_GET_CLASS and related fixes, based on :
http://patchwork.ozlabs.org/patch/646010/ ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Instead of an array of fixed sized blocks, use a list, as we will need
to have sources with variable number of interrupts. SPAPR only uses
a single entry. Native will create more. If performance becomes an
issue we can add some hashed lookup but for now this will do fine.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[ move the initialization of list to xics_common_initfn,
restore xirr_owner after migration and move restoring to
icp_post_load]
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
[ clg: removed the icp_post_load() changes from nikunj patchset v3:
http://patchwork.ozlabs.org/patch/646008/ ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rather than machine instances having backward-compatible option
defaults that need to be repeatedly re-enabled for every new machine
type we introduce, we set the defaults appropriate for newer machine
types, then add code to explicitly disable instance options as needed
to maintain compatibility with older machine types.
Currently pseries-2.5 does not inherit from pseries-2.6 in this
fashion, which is okay at the moment since we do not have any
instance compatibility options for pseries-2.6+ currently.
We will make use of this in future patches though, so fix it here.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
[dwg: Extended to make 2.7 inherit from 2.8 as well]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Vector Extend Sign Instructions:
vextsb2w: Vector Extend Sign Byte To Word
vextsh2w: Vector Extend Sign Halfword To Word
vextsb2d: Vector Extend Sign Byte To Doubleword
vextsh2d: Vector Extend Sign Halfword To Doubleword
vextsw2d: Vector Extend Sign Word To Doubleword
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since the PXE tester runs rather slow on ppc64 with tcg, there
is a chance that we hit the 60 seconds timeout on machines that
have a heavy CPU load. So let's increase the timeout to ease
the situation.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The pxe-test is run for three different targets now (x86_64, i386
and ppc64), and the bios-tables-test is run for two targets (x86_64
and i386). But each of the tests is using an invariant name for the
disk image with the boot sector code - so if the tests are running in
parallel, there is a race condition that they destroy the disk image
of a parallel test program. Let's use mkstemp() to create unique
temporary files here instead - and since mkstemp() is returning an
integer file descriptor instead of a FILE pointer, we also switch
the fwrite() and fclose() to write() and close() instead.
Reported-by: Sascha Silbe <x-qemu@se-silbe.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The pxe-test is quite slow on ppc64 with tcg. We can speed it up
a little bit by decreasing the size of the file that has to be
loaded via TFTP.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The target endianness is not deduced anymore from
the architecture name but asked directly to the guest,
using a new qtest command: "endianness". As it can't
change (this is the value of TARGET_WORDS_BIGENDIAN),
we store it to not have to ask every time we want to
know if we have to byte-swap a value.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
CC: Greg Kurz <groug@kaod.org>
CC: David Gibson <david@gibson.dropbear.id.au>
CC: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Two minor cleanups:
- exit gracefully in case on unsupported target,
- put machine command line in a constant to avoid
to duplicate it.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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 949055a254.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Peter 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: Muted Bytes <mutedbytes@gmail.com>
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-10-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-9-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The vnc_init_state method calls reset_keys() to reset the
modifier key state. This was originally added in
commit 53762ddb27
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 753b405331
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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-8-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-7-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-6-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-5-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-4-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-3-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The last line in vnc_init_state() says
/* vs might be free()ed here */
This was added in
commit 198a0039c5
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 1fc624122f
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: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475163940-26094-2-git-send-email-berrange@redhat.com
Signed-off-by: Gerd 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: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit bac3bf287a)
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: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 4cbec30d76)
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: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 230bf719d3)
some xhci cleanups
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJX/i7DAAoJEEy22O7T6HE4QKoP/jJQgEBlHr+frgzZl5xIQg7D
URx984HGIKWy9TPchjV8a5Ugd4c6eVYYTJlOlqojTRrmwWUoecaJCq9ukra8CIWm
bd+tttRwUCLhFVlXXhSPrj8NTis6NuxmUJ1i3qLnY7n0bxH/bluIDP75GGzrONuV
EszVUVV9o21kN81KSdmej0pAsKoXAMmfJX7EY9rFMHkdFTY7TR46l0qLqu5VMeGR
qS5IOmYNoGwtrDEFEuzFAvt5CL5UccKhpYvCSPA0eDgCJlFQ4Idu2dqZBMhEnDdO
dUr1V1lgTmd4eJNNXSm4UF3MnXSwE29L7elvgfsX8A23qtzudwEc7qL/NGSZzjic
HLx0nmHVqDv77vmHprhNf5wvmUdzOgEjNC7C2dIRNUuaO0MLNCVQFn1bbiyhvQnQ
JlzYHjzrmcBfFQs63pXPm86dMnaarVlgCnO0WiMQ7ql/wpERA/WsZ6tPz5ePOPlS
HdFOIGd8lUl3zvVTM4ZTL9W/Yrsm+k4gR82dU0SCmUyR3qCnVVr4Pr2lFM+xWNxW
D24WdK3GfxVdQz3IE2ar3eqi5tHgjqMY/ItTJ/WQxomI4Ho4sC9FWZfHiBgGyrzY
2eDBhmtXXBvatwz44b9t96hKUZkDaSMHrK6i1xYoh/bHQCr+q1956yqflicdcTHZ
+p8PzcMClUF+AMamBQLG
=oqbo
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20161012-1' into staging
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: Peter 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: Hans de Goede <hdegoede@redhat.com>
Message-id: 1476096313-7730-1-git-send-email-kraxel@redhat.com
Signed-off-by: Gerd 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: Vijay Kumar B. <vijaykumar@zilogic.com>
Reviewed-by: Deepak S. <deepak@zilogic.com>
Message-id: 1475060958-7760-1-git-send-email-vijaykumar@zilogic.com
Signed-off-by: Gerd 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=1381630
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Eric 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: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-9-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: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-7-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: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1474965172-30321-5-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: Gerd 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: Li Qiang <liqiang6-s@360.cn>
Tested-by: P J P <ppandit@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1476096382-7981-1-git-send-email-kraxel@redhat.com
iQEcBAABAgAGBQJX/feXAAoJEJykq7OBq3PIatAIAKoT0dQpc6L0kPM9QYX0soBR
sQ75/EyPyHK+7ly6huS0Zp78RHd98CVePdH/hn+Ha3in87ScBV/NXxgKJ/aUP8Mm
04aMkXgn0tydBndtSTom2sBHOyAl5RUCRH8JBhGQ5p+dbzfeeSU9or4UZdEiChp2
DyvmF7gjjGl8jsDl1G9KsxqOYzwgpxSVZzvzzjjK7ZlJ0fW0gkYInDIzyna/YGJP
Ea7Dc0lLN4wM7rHUk1CgTD8KzSACsmmVy4OfTUo+ij6RugtrCcsiouHqWZ3nYzbN
FHux0hXl02wnUuaZmSChgHxLDVG8pcNcWVt4wuh7wHXo8aNih8UeQLQnkdDnx9o=
=bcLW
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging
# 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: Peter Maydell <peter.maydell@linaro.org>
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: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Message-id: 1475588159-30598-21-git-send-email-berrange@redhat.com
Signed-off-by: Stefan 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: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-20-git-send-email-berrange@redhat.com
Signed-off-by: Stefan 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: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-19-git-send-email-berrange@redhat.com
Signed-off-by: Stefan 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: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-18-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
