cppcheck report:
usb-linux.c:661: warning: Redundant assignment of "len" in switch

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Prototype without "inline" keyword breaks the build with some gcc
versions.  Noticed by Alexander Graf.

Fix this by removing the inline keywork everywhere.  Some functions
can't be inlined anyway as the are referenced using function pointers.
Beside that gcc does a pretty good job on auto-inlining these days.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This interrupt name is used by i386, CRIS, and MicroBlaze.
Copy the name into each target.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

SMI, VIRQ, INIT, SIPI, and MCE are all only used by the i386 port.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This interrupt name was only used by the ARM port.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

It is no longer used anywhere.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This bit is never set, therefore we should not read it either.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This bit is never set, therefore we should not read it either.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This mask contains all of the bits that should be ignored while single
stepping in the debugger.  The mask contains 2 bits that are not currently
cleared, but are also never set.  The bits are included in the mask for
consistency in handling of the CPU_INTERRUPT_TGT_EXT_N bits.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

These defines will be place-holders for cpu-specific functionality.
Generic code will, at the end of the patch series, no longer have to
concern itself about how SMI, NMI, etc should be handled.  Instead,
generic code will know only that the interrupt is internal or external.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Conflicts:
	exec.c

When we're trying to get a newly registered phys memory client updated
with the current page mappings, we end up passing the region offset
(a ram_addr_t) as the start address rather than the actual guest
physical memory address (target_phys_addr_t).  If your guest has less
than 3.5G of memory, these are coincidentally the same thing.  If
there's more, the region offset for the memory above 4G starts over
at 0, so the set_memory client will overwrite it's lower memory entries.

Instead, keep track of the guest phsyical address as we're walking the
tables and pass that to the set_memory client.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When we register a physical memory client, we try to walk the page
tables, calling the set_memory hook for every entry.  Effectively
playing catchup for the client for everything already registered.
With this type, we only walk the 2nd entry of the l1 table,
typically missing all of the registered memory.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Used by HD audio controllers like our intel-hda.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

msi_init may fail, so we need to check on uninit if the cap was
actually installed. This also avoids that the users need to check.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The general control register is a byte register.
Add support for byte reads.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

MDI control is a 32 bit register, but may be read or written using
8 or 16 bit access. Data is latched when the MSB is written.

Add support for byte/word read/write access.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pointer is a 32 bit register, but may be written using 8 or 16 bit writes.
Add support for byte/word writes.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

port is a 32 bit register, but may be written using 8 or 16 bit writes.
Add support for byte/word writes.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Like other Intel devices, e100 (eepro100) uses little endian byte order.

This patch was tested with these combinations:

i386 host, i386 + mipsel guests (le-le)
mipsel host, i386 guest (le-le)
i386 host, mips + ppc guests (le-be)
mips host, i386 guest (be-le)

mips and mipsel hosts were emulated machines.

v2:
Use prefix for new functions. Add the same prefix to stl_le_phys.
Fix alignment of mem (needed for word/dword reads/writes).
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

QEMU sends frames smaller than 60 bytes to ethernet nics.
Such frames are rejected by real NICs and their emulations.
To avoid this behaviour, other NIC emulations pad received
frames. This patch enables this workaround for eepro100, too.

All related code is marked with CONFIG_PAD_RECEIVED_FRAMES,
so we can drop this in case QEMU's networking code is
ever changed.
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

cppcheck reports that 'packet' is unused.

It was only used to calculate the size of the preceding data.
Removing it saves a lot of stack space (local variable rx).
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When DEBUG_EEPRO100 was enabled, unsupported writes were logged twice.
Now logging in eepro100_write1 and eepro100_write2 is similar to the
logging in eepro100_write4 (which already was correct).
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Initialize scsi_len with zero when starting a new request, so any
stuff leftover from the previous request is cleared out.  This may
happen in case the data returned by the scsi command doesn't fit
into the buffer provided by the guest.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Windows allows control transfers to pass up to 4k of data, so raise our
control buffer size to 4k. For control out transfers the usb core code copies
the control request data to a buffer before calling the device's handle_control
callback. Add a check for overflowing the buffer before copying the data.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Extend the iso buffering code to also buffer iso out packets, this
fixes for example using usb speakers with usb redirection.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently we reserve room for endpoint data for 16 endpoints, but given
that we only use endpoint data for endpoints 1-15, and always index the
array with the endpoint-number - 1, 15 is enough.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Refuse iso usb packets when then max packet size for the endpoint is 0,
this avoids an abort in usb_host_alloc_iso() caused by trying to qemu_malloc
a 0 bytes large buffer.

If an endpoint is not in the usb descriptor we've no idea what kind of
endpoint it is and thus how to handle it, refuse packages in this case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently we are submitting iso packets to the host one at a time, as we
receive them from the emulated host controller. This has 2 problems:
1) If we were fast enough to submit every packet in time for the next host host
controller usb frame, we would be generating 1000 hardware interrupts per
second on the host
2) We are not fast enough to submit every packet in time for the next host host
controller usb frame, causing us to not submit iso urbs in some usb frames
which causes devices with an endpoint with an interval of 1 ms (so every
frame) to loose data. This causes for example ubs-1.1 webcams to not work
properly (usb-2.0 is not supported at all atm).

This patch fixes both problems by changing the iso packet pass through handling
to buffer packets. This version only does so for iso input packets (webcams,
audio in) I'm working on a second patch extending this to iso output packets
(audio out).

This patch makes use of the linux batching of iso packets in one urb.
When an iso in packet gets received from the emulated host controller,
it immediately submits 3 urbs with 32 iso in packets each. This causes
the host to only get an hw interrupt every 32 packets dropping the
interrupt rate to 32 interrupts per second and gives it a queue of urbs
to work from once the first 32 iso in packets have been received to make sure
no packets are dropped.

Besides submitting a whole bunch or urbs as soon as the first urb is
received, effectively creating a buffer inside the kernel, this patch also
gets rid of the asynchroneous completion for iso in urbs. Instead they are
only marked as complete in the fd write callback (which usbfs uses to signal
complete urbs). These complete packets then get consumed by returning them
synchroneously to the emulated host controller when it submits an iso in
packet for the ep in question. When no complete packets are ready (which
happens when the stream is starting) a 0 length packet gets returned to
the emulated host controller.

With this patch I've several usb-1.1 webcams working well with usb pass
through, where as without this patch none of them work.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

At least one device I have lies when receiving a USB_REQ_GET_INTERFACE,
always returning 0 even if the alternate setting is different. This is
likely caused because in practice this control message is never used as
the operating system's usb stack knows which alternate setting it has
told the device to get into, and thus this ctrl message does not get
tested by device manufacturers.

When usb_fs_type == USB_FS_SYS, the active alt. setting can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>