Previously the code relied on the queue's "next" field getting
set to -1 sometime between an update to the bitmap, and the next
call to IRQ_get_next. Sometimes this happened after the update.
Sometimes it happened before the check. Sometimes it didn't happen
at all.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Other priorities are signed, so avoid comparisons between
signed and unsigned.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Critical interrupts on FSL MPIC are not supposed to pay
attention to priority, IACK, EOI, etc. On the currently modeled
version it's not supposed to pay attention to the mask bit either.
Also reorganize to make it easier to implement newer FSL MPIC models,
which encode interrupt level information differently and support
mcheck as well as crit, and to reduce problems for later patches
in this set.
Still missing is the ability to lower the CINT signal to the core,
as IACK/EOI is not used. This will come with general IRQ-source-driven
lowering in the next patch.
New state is added which is not serialized, but instead is recomputed
in openpic_load() by calling the appropriate write_IRQreg function.
This should have the side effect of causing the IRQ outputs to be
raised appropriately on load, which was missing.
The serialization format is altered by swapping ivpr and idr (we'd like
IDR to be restored before we run the IVPR logic), and moving interrupts
to the end (so that other state has been restored by the time we run the
IDR/IVPR logic. Serialization for this driver is not yet in a state
where backwards compatibility is reasonable (assuming it works at all),
and the current serialization format was not built for extensibility.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: fix for current code state]
Signed-off-by: Alexander Graf <agraf@suse.de>
The base openpic specification doesn't provide abbreviated register
names, so it's somewhat understandable that the QEMU code made up
its own, except that most of the names that QEMU used didn't correspond
to the terminology used by any implementation I could find.
In some cases, like PCTP, the phrase "processor current task priority"
could be found in the openpic spec when describing the concept, but
the register itself was labelled "current task priority register"
and every implementation seems to use either CTPR or the full phrase.
In other cases, individual implementations disagree on what to call
the register. The implementations I have documentation for are
Freescale, Raven (MCP750), and IBM. The Raven docs tend to not use
abbreviations at all. The IBM MPIC isn't implemented in QEMU. Thus,
where there's disagreement I chose to use the Freescale abbreviations.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: rebase on current state of the code]
Signed-off-by: Alexander Graf <agraf@suse.de>
Book E does not play games with certain bits of xSRR1 being MSR save
bits and others being error status. xSRR1 is the old MSR, period.
This was causing things like MSR[CE] to be lost, even in the saved
version, as soon as you take an exception.
rfci/rfdi/rfmci are fixed to pass the actual xSRR1 register contents,
rather than the register number.
Put FIXME comments on the hack that is "asrr0/1". The whole point of
separate exception levels is so that you can, for example, take a machine
check or debug interrupt without corrupting critical-level operations.
The right xSRR0/1 set needs to be chosen based on CPU type flags.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This will stop things from breaking once it's properly treated as a
level-triggered interrupt. Note that it's the MPIC's MSI cascade
interrupts that are level-triggered; the individual MSIs are
edge-triggered.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Fix various format errors when debug prints are enabled. Also
cause error checking to happen even when debug prints are not
enabled, and consistently use 0x for hex output.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: adjust for more recent code base, prettify DPRINTF macro]
Signed-off-by: Alexander Graf <agraf@suse.de>
Removed h2g() macro around the ka->_sa_handler due to the _sa_handler being a
guest memory address.
Changed the __put_user to put_user as it was attempting to put a value at the
stack address but the new address is a guest memory address, __put_user is
for host memory addresses.
Signed-off-by: Samuel Seay <LightningTH@GMail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[agraf: change subject line, reformat commit message]
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch install the timer reset handler. This will be called when
the guest is reset.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
[agraf: adjust for QOM'ification]
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch fixes the following coding style violations:
- structs have to be typedef and be CamelCase
- if()s are always surrounded by curly braces
Signed-off-by: Alexander Graf <agraf@suse.de>
epapr_hcalls.h is now referenced by kvm_para.h. so this is needed for
QEMU to get compiled on powerpc.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
If we access a register via the QEMU memory inspection commands (e.g.
"xp") rather than from guest code, we won't have a CPU context.
Gracefully fail to access the register in that case, rather than
crashing.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
"opp->nb_irqs-1" would have been a minor coding style error,
but putting in one space but not the other makes it look
confusingly like a numeric literal "-1".
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
It's in the address range that normally contains a magic redirection
to the CPU-specific region of the curretn CPU, but it isn't actually
a per-CPU register. On real hardware BRR1 shows up only at 0x40000,
not at 0x60000 or other non-magic per-CPU areas. Plus, this makes
it possible to read the register on the QEMU command line with "xp".
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Previously only the spurious vector was sized appropriately
to the openpic model.
Also, instances of "IPVP_VECTOR(opp->spve)" were replace with
just "opp->spve", as opp->spve is already just a vector and not
an IVPR.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
I could not find this register in any spec (FSL, IBM, or OpenPIC)
and the code doesn't do anything with it but initialize, save,
or restore it.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Deefine symbolic names for some register bits, and use some that
have already been defined.
Also convert some register values from hex to decimal when it improves
readability.
IPVP_PRIORITY_MASK is corrected from (0x1F << 16) to (0xF << 16), in
conjunction with making wider use of the symbolic name. I looked at
Freescale and IBM MPIC docs and at the base OpenPIC spec, and all three
had priority as 4 bits rather than 5. Plus, the magic nubmer that is
being replaced with symbolic values treated the field as 4 bits wide.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Add EHCI USB host controller to exynos4210.
Signed-off-by: Liming Wang <walimisdev@gmail.com>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Reviewed-by: Igor Mitsyanko <i.mitsyanko@samsung.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
It uses a different capsbase and opregbase than the Xilinx device.
Signed-off-by: Liming Wang <walimisdev@gmail.com>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Igor Mitsyanko <i.mitsyanko@samsung.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This allows specific derived models to use different values.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
SysBus EHCI was introduced in a hurry before 1.3 Soft Freeze.
To use QOM casts in place of DO_UPCAST() / FROM_SYSBUS(), we need an
identifying type. Introduce generic abstract base types for PCI and
SysBus EHCI to allow multiple types to access the shared fields.
While at it, move the state structs being amended with macros to the
header file so that they can be embedded.
The VMSTATE_PCI_DEVICE() macro does not play nice with the QOM
parent_obj naming convention, so defer that cleanup.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Due to the way devices are addressed with xhci (done by hardware, not
the guest os) there is no packet when invoking the set-address control
request. Create a dummy packet in that case to avoid null pointer
dereferences.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The xhci-hcd may submit bulk transfers > 65535 bytes even when not using
bulk-in pipeling, so usbredir can only be used in combination with an xhci
hcd if the client has the 32 bits bulk length capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
To ensure that interrupt receiving is properly stopped when the guest is
no longer interested in an interrupt endpoint.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Some usb devices (host or network redirection) can benefit from knowing when
the guest stops using an endpoint. Redirection may involve submitting packets
independently from the guest (in combination with a fifo buffer between the
redirection code and the guest), to ensure that buffers of the real usb device
are timely emptied. This is done for example for isoc traffic and for interrupt
input endpoints. But when the (re)submission of packets is done by the device
code, then how does it know when to stop this?
For isoc endpoints this is handled by detecting a set interface (change alt
setting) command, which works well for isoc endpoints. But for interrupt
endpoints currently the redirection code never stops receiving data from
the device, which is less then ideal.
However the controller emulation is aware when a guest looses interest, as
then the qh for the endpoint gets unlinked (ehci, ohci, uhci) or the endpoint
is explicitly stopped (xhci). This patch adds a new ep_stopped USBDevice
method and modifies the hcd code to call this on queue unlink / ep stop.
This makes it possible for the redirection code to properly stop receiving
interrupt input (*) data when the guest no longer has interest in it.
*) And in the future also buffered bulk input.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb_ep_find_packet_by_id mistakenly only checks the first packet and if that
is not a match, keeps trying the first packet! This patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This leads to cleaner code in usb-hid, and removes up to a 1000 calls / sec to
qemu_get_clock_ns(vm_clock) if idle-time is set to its default value of 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If somehow we've gotten behind a lot, simply skip ahead, like the ehci code
does.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Before this patch uhci would process an unlimited amount of frames when
behind on schedule, by setting the timer to a time already past, causing the
timer subsys to immediately recall the frame_timer function gain.
This would cause invalid cancellations of bulk queues when the catching up
processed more then 32 frames at a moment when the bulk qh was temporarily
unlinked (which the Linux uhci driver does).
This patch fixes this by processing maximum 16 frames in one go, and always
setting the timer one ms later, making the code behave more like the ehci
code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rather then using the magic 32 value in various places.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Re-arrange how we process frames / increase frnum / report pending interrupts,
to avoid a 1 ms delay in interrupt reporting to the guest. This increases
the packet throughput for cases where the guest submits a single packet,
then waits for its completion then re-submits from 500 pkts / sec to
1000 pkts / sec. This impacts for example the use of redirected / virtual
usb to serial convertors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_raise_irq(s, USBSTS_PCD), gets applied immediately so there is no need
to call commit_irq after it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
I tried lowering the time between raising an interrupt and rescanning the
async schedule to see if the guest has queued a new transfer before, but
that did not have any positive effect. I now believe the cause for this is
that lowering this time made it more likely to hit the 1 ms interrupt
threshold penalty for the next packet, as described in my
"ehci: Use uframe precision for interrupt threshold checking" commit.
Now that we do interrupt threshold handling with uframe precision, futher
lowering this time from .5 to .25 ms gives an extra 15% improvement in speed
(MB/s) reading from a simple USB-2.0 thumb-drive.
While at it also properly set the int_req_by_async flag for short packet
completions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Before this patch, the following could happen:
1) Transfer completes, raises interrupt
2) .5 ms later we check if the guest has queued up any new transfers
3) We find and execute a new transfer
4) .2 ms later the new transfer completes
5) We re-run our frame_timer to write back the completion, but less then
1 ms has passed since our last run, so frindex is not changed, so the
interrupt threshold code delays the interrupt
6) 1 ms from the re-run our frame-timer runs again and finally delivers
the interrupt
This leads to unnecessary large delays of interrupts, this code fixes this
by changing frindex to uframe precision and using that for interrupt threshold
control, making the interrupt fire at step 5 for guest which have low interrupt
threshold settings (like Linux).
Note that the guest still sees the frindex move in steps of 8 for migration
compatibility.
This boosts Linux read speed of a simple cheap USB thumb drive by 6 %.
Changes in v2:
-Make the guest see frindex move in steps of 8 by modifying ehci_opreg_read,
rather then using a shadow variable
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_fill_queue assumes that there is a one on one relationship between an ep
and a qh, this patch adds a check to ensure this.
Note I don't expect this to ever trigger, this is just something I noticed
the guest might do while working on other stuff. The only way this check can
trigger is if a guest mixes in and out qtd-s in a single qh for a non
control ep.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Remove the short-circuiting of fetchqtd in fetchqh, so that the
qtd gets properly verified before completing the transaction.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is not allowed, except for clearing active on cancellation, so don't
warn when the new token does not have its active bit set.
This unifies the cancellation path for modified qtd-s, and prepares
ehci_verify_qtd to be used ad an extra check inside
ehci_writeback_async_complete_packet().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Also drop the warning printf, which was there mainly because this was an
untested code path (as the previous bug fixes to it show), but that no
longer is the case now :)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A device reset does not affect the link state, only set_link does.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commit b9d03e352c added link
auto-negotiation emulation, it would always set link up by
callback function. Problem exists if original link status
was down, link status should not be changed in auto-negotiation.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
