Currently we test our visitors individually, and seperately for input
vs. output. This is useful for validating internal representations
against the native C types and vice-versa, and other visitor-specific
testing, but it doesn't cover the potential use-case of using visitor
pairs for serialization/deserialization very well, and makes it
hard to easily extend the coverage for different C types / boundary
conditions.
To cover that we add a set of unit tests that takes a number of native C
values, passes them into an output visitor, extracts the values with an
input visitor, then compares the result to the original.
Plugging in new visitors to the test harness only requires a user to
implement the SerializeOps interface and add it to a list.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This adds visitor interfaces for fixed-width integers types.
Implementing these in visitors is optional, otherwise we fall back to
visit_type_int() (int64_t) with some additional bounds checking to avoid
integer overflows for cases where the value fetched exceeds the bounds
of our target C type.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[LE: exclude negative values in uint*_t Visitor interfaces]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[AF: Merged fix by Laszlo]
Signed-off-by: Andreas Färber <afaerber@suse.de>
They could suggest that all TBs of the page containing the range would
be invalidated.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This changes implementations of all iov_*
functions, completing the previous step.
All iov_* functions now ensure that this offset
argument is within the iovec (using assertion),
but lets to specify `bytes' value larger than
actual length of the iovec - in this case they
stops at the actual end of iovec. It is also
suggested to use convinient `-1' value as `bytes'
to mean just this -- "up to the end".
There's one very minor semantic change here: new
requiriment is that `offset' points to inside of
iovec. This is checked just at the end of functions
(assert()), it does not actually need to be enforced,
but using any of these functions with offset pointing
past the end of iovec is wrong anyway.
Note: the new code in iov.c uses arithmetic with
void pointers. I thought this is not supported
everywhere and is a GCC extension (indeed, the C
standard does not define void arithmetic). However,
the original code already use void arith in
iov_from_buf() function:
(memcpy(..., buf + buf_off,...)
which apparently works well so far (it is this
way in qemu 1.0). So I left it this way and used
it in other places.
While at it, add a unit-test file test-iov.c,
to check various corner cases with iov_from_buf(),
iov_to_buf() and iov_memset().
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reorder arguments to be more natural, readable and
consistent with other iov_* functions, and change
argument names, from:
iov_from_buf(iov, iov_cnt, buf, iov_off, size)
to
iov_from_buf(iov, iov_cnt, offset, buf, bytes)
The result becomes natural English:
copy data to this `iov' vector with `iov_cnt'
elements starting at byte offset `offset'
from memory buffer `buf', processing `bytes'
bytes max.
(Try to read the original prototype this way).
Also change iov_clear() to more general iov_memset()
(it uses memset() internally anyway).
While at it, add comments to the header file
describing what the routines actually does.
The patch only renames argumens in the header, but
keeps old names in the implementation. The next
patch will touch actual code to match.
Now, it might look wrong to pay so much attention
to so small things. But we've so many badly designed
interfaces already so the whole thing becomes rather
confusing or error prone. One example of this is
previous commit and small discussion which emerged
from it, with an outcome that the utility functions
like these aren't well-understdandable, leading to
strange usage cases. That's why I paid quite some
attention to this set of functions and a few
others in subsequent patches.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Original code has one thing to process (cur_len), requests to
convert from iovec to buf another thing (len which is actually max_len),
and processes something else (copied). Whole thing is very difficult
to understand, even if it does a right thing. The iov_to_buf()
conversion in this case will always return cur_len, because it is
the length of the iovec it was asked to process, and the size we
asked to convert is the same or larger, and iov_to_buf() will stop
at reaching either iov or buf.
Make the code saner by doing the only sane thing: dropping `copied'
which is always the same as `cur_len' but just introduces questions.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Also this functions is better invoked by the core than by each and every
device. This allows to drop the config_write callbacks from ich and
intel-hda.
CC: Alexander Graf <agraf@suse.de>
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Terminate msi/msix_write_config early if support is not enabled. This
allows to remove checks at the caller site if MSI is optional.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There is no point in pushing this burden to the devices, they tend to
forget to call them (like intel-hda, ahci, xhci did). Instead, reset
functions are now called from pci_device_reset. They do nothing if
MSI/MSI-X is not in use.
CC: Alexander Graf <agraf@suse.de>
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Properly register reset functions via the device class.
CC: Alexander Graf <agraf@suse.de>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Call msi_reset on device reset as still required by the core.
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: qemu-stable@nongnu.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Call msi_reset on device reset as still required by the core.
CC: Alexander Graf <agraf@suse.de>
CC: qemu-stable@nongnu.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Some drivers (Linux' 8139too among them) rely on the NIC
injecting an interrupt in the event of a receive buffer overflow
and, accordingly, set the RxOverflow bit in the interrupt
mask. Unfortunately rtl8139's can_receive method ignores the
RxOverflow flag, which may lead to a situation where rtl8139
stops receiving packets (can_receive returns 0) when the receive
buffer becomes full.
If the driver eventually read from the receive buffer or reset
the card the emulator could recover from this situation. However
some implementations only do this upon receiving an interrupt
with either RxOK or RxOverflow set in the ISR; interrupt that
will never come because QEMU's flow control mechanisms would
prevent rtl8139 from receiving any packet.
Letting packets go through when the overflow interrupt is enabled
makes the QEMU emulator compliant to the spec and solves the
problem.
This patch should fix a relatively common (in our experience)
network stall observed when running enterprise distros with
rtl8139 as the NIC; in some cases the 8139too device driver gets
loaded and when under heavy load the network eventually stops
working.
Reported-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Acked-by: Igor Kovalenko <igor.v.kovalenko@gmail.com>
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The lazy initialisation of r_check was throwing an error on --enable-debug.
Removed the lazy initialisation of r_check and swx_addr.
Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Move the framecount check out of the loop and use the new
ehci_update_frindex function to skip frames if needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Adapt the frame timer sleeps according to the actual needs. With the
periodic schedule being active we'll have to wakeup 1000 times per
second and go check for work. In case only the async schedule is active
we can be more lazy though. When idle ehci will increate the sleep time
step by step, so qemu has to wake up less frequently. When we'll see
transactions on the bus or the guest fiddles with the schedule
enable/disable bits we'll return to a 1000 Hz wakeup rate and full
speed. With both schedules disabled we stop wakeups altogether.
This patch also drops the freq property (configures wakeup rate
manually) which is obsoleted by this patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When the enable bits for controller / async schedule / periodic schedule
change just make sure we kick the frame timer and let
ehci_advance_periodic_state and ehci_advance_async_state handle the
controller state changes.
This will make ehci set USBSTS_HALT when the controller shutdown is
actually done, once both schedules are in inactive state and the
USBSTS_PSS and USBSTS_ASS bits are clear.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Update the status register in the ehci_set_state function, to make sure
the guest-visible register is in sync with our internal schedule state.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add helper functions to query whenever the async / periodic schedule
is enabled or not. Put them into use too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Check for the reset bit first when processing USBCMD register writes.
Also break out of the switch, there is no need to check the other bits.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When a packet completes which happens to be part of the async schedule
kick the async bottom half for processing,
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Keep track whenever a EHCIQueue is part of the async or periodic
schedule. This way we don't have to pass around the async flag
everywhere but can look it up from the EHCIQueue struct when needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add packet queuing. Follow the qTD chain to see if there are more
packets we can submit. Improves performance on larger transfers,
especially with usb-host, as we don't have to wait for a packet to
finish before sending the next one to the host for processing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Keep a USBDevice pointer in EHCIQueue so we don't have to lookup the
device on each usb packet submission.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This way it is possible to use ehci_execute to submit others than the
first EHCIPacket of the EHCIQueue.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a separate EHCIPacket struct and move fields over from EHCIQueue.
Preparing for supporting multiple packets per queue being in flight at
the same time. No functional changes yet.
Fix some codestyle issues along the way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Properly register reset function via the device class.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Repace the running buffer pointer (scsi_buf) with a buffer offset
field (scsi_off). The later is alot easier to live-migrate.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Factor out packet completion to a separate function which
cares to get the MSDState->packet update right.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
