On ppc405ep there is a register that allows for software to reset the
core, but not the whole system. Implement this reset using a reset
interrupt.

This gets rid of a bunch of #if 0'ed code.
Reported-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The kvmvapic code remaps a section of ROM as RAM to allow the guest to
maintain state there.  It is careful to align the section size to a page
boundary, to avoid creating subpages, but neglects to do the same for
the start address.  These leads to an assert later on when the memory
core tries to create a page which is half RAM and half ROM.

Fix by aligning the start address to a page boundary.

This can be triggered by running qemu-system-x86_64 -enable-kvm -vga none.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently, the "kvmclock" type is only registered when kvm_enabled().

This breaks when moving type registration to before command line
parsing (so that QOM types can be used for CPU and machine).

Since the QOM classes are lazy-initialized anyway and kvmclock_create()
has another kvm_enabled() check, simply drop the KVM check in
kvmclock_register_types().

kvm-i8259, kvm-apic and kvm-ioapic do not suffer from such a check.

Reviewed-by: please.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This fixes a broken endian assumption in an assertion in usb-msd.

Cc: Gerd Hoffman <kraxel@redhat.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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

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

Step #2 (separate for better bisectability): renumber so the silly '-1'
goes away.  Pick a range which doesn't overlap the old values.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Step #1 (separate for better bisectability): replace numbers with names.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Zap DPRINTF, add tracepoints instead.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Cancel any in-flight transaction when the guest stops the uhci schedule.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

It should also free all queues.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Also do async->td initialization in uhci_async_alloc now.
Prepares for adding tracepoints.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add a new function to check whenever the packet state is as expected,
log more informations in case it isn't.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch fixes two bugs in the OHCI device where the device writes
back data to system memory that should be exclusively under the
control of the guest side driver.

In OHCI specification Section 5.2.7, it mentioned "In all cases, Host
Controller Driver is responsible for the insertion and removal of all
Endpoint Descriptors in the various Host Controller Endpoint
Descriptor lists".  In the ohci_frame_boundary(), ohci_put_hcca()
writes the entire hcca back including the interrupt ED lists which
should be under driver control. This violates the specification and
can race with a host driver updating that list at the same time.

In the OHCI Spec Section 4.6, Transfer Descriptor Queue Processing, it
mentioned "Since the TD pointed to by TailP is not accessed by the HC,
the Host Controller Driver can initialize that TD and link at least
one other to it without creating a coherency or synchronization
problem".  While the function ohci_put_ed() writes the entire endpoint
descriptor back including the TailP which should under driver
control. This violate the specification and can race with a host
driver updating the TD list at the same time.

In each case the solution is to make sure we don't write data which is
under driver control.

Cc: Gerd Hoffman <kraxel@redhat.com>
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Remove the uhci and ohci init wrappers, which all wrapped a
pci_create_simple() one-liner.  Switch callsites to call
pci_create_simple directly.  Remove the header files where
the wrappers where declared.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Reorganize usb source files.  Create a new hw/usb/ directory and move
all usb source code to that place.  Also make filenames a bit more
descriptive.  Host adapters are prefixed with "hch-" now, usb device
emulations are prefixed with "dev-".  Fixup paths Makefile and include
paths to make it compile.  No code changes.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

These were stored as NULL due to wrong cut-and-paste from set_pointer.
Reported-by: NGerhard Wiesinger <lists@wiesinger.com>
Tested-by: NGerhard Wiesinger <lists@wiesinger.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAlon Levy <alevy@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Most MemoryRegionOps already had the const attribute.
This patch adds it to the remaining ones.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

* it's -> its (fixed for all files)
* dont -> don't (only fixed in a line which was touched by the previous fix)
* distrub -> disturb (fixed in the same line)
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

The 'struct' is not needed, and all other MemoryRegionOps don't use it.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Don't signal port status change if the usb device isn't in attached
state.  Happens with usb-host devices with the pass-through device
being plugged out at the host.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Use the new, direct control transfer submission method instead of
bypassing the usb core by calling usb_device_handle_control directly.
The later fails for async control transfers.

This patch gets xhci + usb-host combo going.

Add a more direct code path to submit control transfers.  Instead of
feeding three usb packets (setup, data, ack) to usb_handle_packet and
have the do_token_* functions in usb.c poke the control transfer
parameters out of it just submit a single packet carrying the actual
data with the control xfer parameters filled into USBPacket->parameters.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

With this patch applied USB drivers can enable pipelining per endpoint.
With pipelining enabled the usb core will continue submitting packets
even when there are still async transfers in flight instead of passing
them on one by one.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This can happen today in case the ->complete() callback queues up the
next packet.  Also we'll support pipelining soon, which allows to have
multiple packets per queue in flight (aka ASYNC) state.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We already have USB_RET_NAK, but that means that a device does not want
to send/receive right now. But with host / network redirection we can
actually have a transaction fail due to some io error, rather then ie
the device just not having any data atm.

This patch adds a new error code named USB_RET_IOERROR for this, and uses
it were appropriate.

Notes:
-Currently all usb-controllers handle this the same as NODEV, but that
 may change in the future, OHCI could indicate a CRC error instead for example.
-This patch does not touch hw/usb-musb.c, that is because the code in there
 handles STALL and NAK specially and has a if status < 0 generic catch all
 for all other errors
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

All error statuses except for NAK are handled in a switch case, move the
handling of NAK into the same switch case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The nakcnt code in ehci_execute_complete() marked transactions as finished
when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK
means that the device cannot receive / send data at that time and that
the transaction should be retried later, which is also what the usb-uhci
and usb-ohci code does.

Note that there already was some special code in place to handle this
for interrupt endpoints in the form of doing a return from
ehci_execute_complete() when reload == 0, but that for bulk transactions
this was not handled correctly (where as for example the usb-ccid device does
return USB_RET_NAK for bulk packets).

Besides that the code in ehci_execute_complete() decrement nakcnt by 1
on a packet result of USB_RET_NAK, but
-since the transaction got marked as finished,
 nakcnt would never be decremented again
-there is no code checking for nakcnt becoming 0
-there is no use in re-trying the transaction within the same usb frame /
 usb-ehci frame-timer call, since the status of emulated devices won't change
 as long as the usb-ehci frame-timer is running
So we should simply set the nakcnt to 0 when we get a USB_RET_NAK, thus
claiming that we've tried reload times (or as many times as possible if
reload is 0).

Besides the code in ehci_execute_complete() handling USB_RET_NAK there
was also code handling it in ehci_state_executing(), which calls
ehci_execute_complete(), and then does its own handling on top of the handling
in ehci_execute_complete(), this code would decrement nakcnt *again* (if not
already 0), or restore the reload value (which was never changed) on success.

Since the double decrement was wrong to begin with, and is no longer needed
now that we set nakcnt directly to 0 on USB_RET_NAK, and the restore of reload
is not needed either, this patch simply removes all nakcnt handling from
ehci_state_executing().
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch removes 2 bits of dead nakcnt code:

1) usb_ehci_execute calls ehci_qh_do_overlay which does:
nakcnt = reload;
and then has a block of code which is conditional on:
if (reload && !nakcnt) {
which ofcourse is never true now as nakcnt == reload.

2) ehci_state_fetchqh does:
nakcnt = reload;
but before nakcnt is ever used ehci_state_fetchqh is always followed
by a ehci_qh_do_overlay call which also does:
nakcnt = reload;
So doing this from ehci_state_fetchqh is redundant.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

cerr should only be decremented on errors which cause XactErr to be set, and
when that happens the failing transaction should be retried until cerr reaches
0 and only then should USBSTS_ERRINT be set (and inactive cleared and
USBSTS_INT set if requested).

Since we don't have any hardware level errors (and in case of redirection
the real hardware has already retried), re-trying makes no sense, so
immediately set cerr to 0 on errors which set XactErr.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get
sets then if the td has its IOC bit set USBINT should be set as well.

This means that for any status except for USB_RET_NAK we should set
USBINT if the IOC bit is set.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The purpose of the IAAD bit / the doorbell is to make the ehci controller
forget about cached qhs, this is mainly used when cancelling transactions,
the qh is unlinked from the async schedule and then the doorbell gets rung,
once the doorbell is acked by the controller the hcd knows that the qh is
no longer in use and that it can do something else with the memory, such
as re-use it for a new qh! But we keep our struct representing this qh around
for circa 250 ms. This allows for a (mightily large) race window where the
following could happen:
-hcd submits a qh at address 0xdeadbeef
-our ehci code sees the qh, sends a request to a usb-device, gets a result
 of USB_RET_ASYNC, sets the async_state of the qh to EHCI_ASYNC_INFLIGHT
-hcd unlinks the qh at address 0xdeadbeef
-hcd rings the doorbell, wait for us to ack it
-hcd re-uses the qh at address 0xdeadbeef
-our ehci code sees the qh, looks in the async_queue, sees there already is
 a qh at address 0xdeadbeef there with async_state of EHCI_ASYNC_INFLIGHT,
 does nothing
-the *original* (which the hcd thinks it has cancelled) transaction finishes
-our ehci code sees the qh on yet another pass through the async list,
 looks in the async_queue, sees there already is a qh at address 0xdeadbeef
 there with async_state of EHCI_ASYNC_COMPLETED, and finished the transaction
 with the results of the *original* transaction.

Not good (tm), this patch fixes this race by removing all qhs which have not
been seen during the last cycle through the async list immidiately when the
doorbell is rung.

Note this patch does not fix any actually observed problem, but upon
reading of the EHCI spec it became apparent to me that the above race could
happen and the usb-ehci behavior from before this patch is not good.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch USB 2 devices with interrupt endpoints were not working
properly. The problem is that to avoid loops we stop processing as soon
as we encounter a queue-head (qh) we've already seen since qhs can be linked
in a circular fashion, this is tracked by the seen flag in our qh struct.

The resetting of the seen flag is done from ehci_queues_rip_unused which
before this patch was only called when executing the statemachine for the
async schedule.

But packets for interrupt endpoints are part of the periodic schedule! So what
would happen is that when there were no ctrl or bulk packets for a USB 2
device with an interrupt endpoint, the async schedule would become non
active, then ehci_queues_rip_unused would no longer get called and when
processing the qhs for the interrupt endpoints from the periodic schedule
their seen bit would still be 1 and they would be skipped.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

qhs can be part of both the async and the periodic schedule, as is shown
in later patches in this series it is useful to keep track of the qhs on
a per schedule basis.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Before this patch the T-bit was not checked in 2 places, while it should be.

Once we properly check the T-bit everywhere we no longer need the weird
entry < 0x1000 and entry > 0x1000 checks, so this patch removes them.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>