Don't overwrite pci header type.
Otherwise, multi function bit which pci_init_header_type() sets
appropriately is lost.
Anyway PCI_HEADER_TYPE_NORMAL is zero, so it is unnecessary to zero
which is already zero cleared.
how to test:
run qemu and issue info pci to see whether a device in question is
normal device, not pci-to-pci bridge.
This is handy because guest os isn't required.
tested changes:
The following files are covered by using following commands.
sparc64-softmmu
apb_pci.c, vga-pci.c, cmd646.c, ne2k_pci.c, sun4u.c
ppc-softmmu
grackle_pci.c, cmd646.c, ne2k_pci.c, vga-pci.c, macio.c
ppc-softmmu -M mac99
unin_pci.c(uni-north, uni-north-agp)
ppc64-softmmu
pci-ohci, ne2k_pci, vga-pci, unin_pci.c(u3-agp)
x86_64-softmmu
acpi_piix4.c, ide/piix.c, piix_pci.c
-vga vmware vmware_vga.c
-watchdog i6300esb wdt_i6300esb.c
-usb usb-uhci.c
-sound ac97 ac97.c
-nic model=rtl8139 rtl8139.c
-nic model=pcnet pcnet.c
-balloon virtio virtio-pci.c:
untested changes:
The following changes aren't tested.
prep_pci.c: ppc-softmmu -M prep should cover, but core dumped.
unin_pci.c(uni-north-pci): the caller is commented out.
openpic.c: the caller is commented out in ppc_prep.c
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
The commit 8e65b7c049 introduced
expire_time of UHCIState. But expire_time is not in vmstate, the
second uhci_frame_timer will not be fired immediately after loadvm.
Signed-off-by: TeLeMan <geleman@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
I have streaming audio devices working within qemu-kvm. This is a port
of the changes to qemu.
Streaming audio generates a series of isochronous requests that are
repetitive and time sensitive. The URBs need to be submitted in
consecutive USB frames and responses need to be handled in a timely manner.
Summary of the changes for isochronous requests:
1. The initial 'valid' value is increased to 32. It needs to be higher
than its current value of 10 since the host adds a 10 frame delay to the
scheduling of the first request; if valid is set to 10 the first
isochronous request times out and qemu cancels it. 32 was chosen as a
nice round number, and it is used in the path where a TD-async pairing
already exists.
2. The token field in the TD is *not* unique for isochronous requests,
so it is not a good choice for finding a matching async request. The
buffer (where to write the guest data) is unique, so use that value instead.
3. TD's for isochronous request need to be completed in the async
completion handler so that data is pushed to the guest as soon as it is
available. The uhci code currently attempts to process complete
isochronous TDs the next time the UHCI frame with the request is
processed. The results in lost data since the async requests will have
long since timed out based on the valid parameter. Increasing the valid
value is not acceptable as it introduces a 1+ second delay in the data
getting pushed to the guest.
4. The frame timer needs to be run on 1 msec intervals. Currently, the
expire time for the processing the next frame is computed after the
processing of each frame. This regularly causes the scheduling of frames
to shift in time. When this happens the periodic scheduling of the
requests is broken and the subsequent request is seen as a new request
by the host resulting in a 10 msec delay (first isochronous request is
scheduled for 10 frames from when the URB is submitted).
[ For what's worth a small change is needed to the guest driver to have
more outstanding URBs (at least 4 URBs with 5 packets per URB).]
Signed-off-by: David Ahern <daahern@cisco.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
No functional changes. I verified that the generated binary
does not change.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
Acked-by: Glauber Costa <glommer@gmail.com>
Device names with whitespace require quoting in the shell and in the
monitor. Some of the offenders are also overly long. Some have a
more convenient alias, some don't.
The place for verbose device names is DeviceInfo member desc. The
name should be short & sweet.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
pci.h declares some functions which aren't
defined in pci.h. Clean up moving things
to appropriate headers, and update all users.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch is preliminary for 64 bit BAR support.
Introduce dedicated type, pcibus_t, to represent pci bus address/size
instead of uint32_t.
Later this type will be changed to uint64_t.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
make constants for pci base address match pci_regs.h by
renaming PCI_ADDRESS_SPACE_xxx to PCI_BASE_ADDRESS_SPACE_xxx.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow us to find bugs easier.
Furthermore, the fact that we initialize things like the cpu quite early,
leads to the need to introduce synchronization stuff like qemu_system_cond.
This patch removes it entirely. All we need to do is call qemu_system_reset()
only when we're already sure the system is up and running
I tested it with qemu (with and without io-thread) and qemu-kvm, and it
seems to be doing okay - although qemu-kvm uses a slightly different patch.
[ v2: user mode still needs cpu_reset, so put it in ifdef. ]
[ v3: leave qemu_system_cond for now. ]
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Move usb code from vl.c to usb-bus.c and make it use the new data
structures added by qdev conversion. qemu usb core should be able
to handle multiple USB busses just fine now (untested though).
Kill some usb_*_init() legacy functions, use usb_create_simple()
instead.
Kill some FIXMEs added by the first qdev/usb patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* Add USBBus.
* Add USBDeviceInfo, move device callbacks here.
* Add usb-qdev helper functions.
* Switch drivers to qdev.
TODO:
* make the rest of qemu aware of usb busses and kill the FIXMEs
added by this patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
I used the following command to enable debugging:
perl -p -i -e 's/^\/\/#define DEBUG/#define DEBUG/g' * */* */*/*
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This reverts commit 8217606e6e (and
updates later added users of qemu_register_reset), we solved the
problem it originally addressed less invasively.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The device is not reset on system reset currently.
Without this patch RHEL4.8 hangs after reboot if -usbdevice table
is in use.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
This function is used to manage a PCI BAR, so make the more generic
pci_register_io_region() available to other uses.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch adds and uses #defines for PCI device classes and subclases,
using a new pci_config_set_class() function, similar to the recently
added pci_config_set_vendor_id() and pci_config_set_device_id().
Change since v1: fixed compilation of hw/sun4u.c
Signed-off-by: Stuart Brady <stuart.brady@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6491 c046a42c-6fe2-441c-8c8c-71466251a162
This patch defines PCI vendor and device IDs in pci.h (matching those
from Linux's pci_ids.h), and uses those definitions where appropriate.
Change from v1:
Introduces pci_config_set_vendor_id() / pci_config_set_device_id()
accessors as suggested by Anthony Liguori.
Signed-off-by: Stuart Brady <stuart.brady@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6442 c046a42c-6fe2-441c-8c8c-71466251a162
Transaction lifetime was originally set to 10 frames. That was an arbitrary
number I picked without much thinking :).
I'm changing that to 32 frames because things like interrupt transfers
and such are scheduled at that rate. It seems like 1/32 is accepted as
lowest supported rate. OHCI, for example, defines exactly 32 interrupt
heads.
While testing USB webcam under XP I noticed that interrupt transactions were
being canceled and then resubmitted on a regular basis, which works but is a
waste of CPU cycles. This change fixes that.
All other devices I have are not affected.
Signed-off-by: Max Krasnyansky <maxk@kernel.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5199 c046a42c-6fe2-441c-8c8c-71466251a162
While trying to make VX-3000 camera work on XP under KVM I realized that
we do not necessarily have to find original TD address. All we care about
is the token which identifies the transfer rather well (direction, endpoint,
size, etc).
This is especially important for the isochronous transfers because otherwise
they are being canceled left and right and we do not make much progress.
With this patch all devices that used bulk transfers that I've tried so
far continue to work just as well. And now my USB web cammera (isoc transfers)
is working well tool. It's not as smooth as native Windows but it's pretty
darn smooth.
The cool thing is that new USB code (both usb-uhci and usb-linux) is totaly
generic and does not need any special logic for ISOC.
Signed-off-by: Max Krasnyansky <maxk@kernel.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5072 c046a42c-6fe2-441c-8c8c-71466251a162
Fixes regression reported agains Linux 2.6.18.
Looks like XP and newer Linux kernels are less sensitive
to length returned for control transfers.
Signed-off-by: Max Krasnyansky <maxk@kernel.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5070 c046a42c-6fe2-441c-8c8c-71466251a162
For some reason we were not registering save/load-vm handler for piix3
flavor of UHCI and hence save/load was broken.
Async transactions need to be canceled when we save the VM because there
is no way we can save/restore all that state. Since we do not mess the
original TD/QH the driver will simply resubmit the transfers.
Tested with Windows XP-SP2 running under QEMU/KQEMU.
Signed-off-by: Max Krasnyansky <maxk@kernel.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5054 c046a42c-6fe2-441c-8c8c-71466251a162
This is esentially a re-write of the QEMU UHCI layer. My initial goal
was to support fully async operation with multiple outstanding async
transactions. Along the way I realized that I can greatly simplify
and cleanup the overall logic. There was a lot of duplicate and confusing
code in the UHCI data structure parsing and other places.
We were actually violating UHCI spec in handling async ISOC transaction
(host controller is not supposed to write into the frame pointer).
The reason I wanted to support fully async operation is because current
synchronous version is unusable with most devices exported from host
(via usb-linux.c). Transactions take a long time and the whole VM becomes
slow as hell.
Current async support is very rudimentory and for the most part
non-functional. Single transaction at a time is simply not enough. I have
a device for which XP driver submits both IN and OUT packets at the same
time. IN packet always times out unless OUT packet makes it to the device.
Hence we must be able to process both in order for that device to work.
The new code is backwards compatible and was first tested agains original
synchronous usb-linux.c and builtin usb devices like tablet which is also
synchronous. Rewrite of the usb-linux.c is coming up next.
Async support was tested against various XP versions (ie XP, SP2, SP3) and
a bunch of different USB devices: serial port controllers, mice, keyboard,
JTAG dongles (from Xilinx and Altera).
ISOC support was only lighly tested and needs more work. It's not any worse
than current code though.
UHCI parser changes are probably somewhat hard to review without the
understanding of the UHCI spec.
The async design should be fairly easy to follow. Basically we have a list
of async objects for each pending transfer. Async objects are tagged with
the original TD (transfer descriptor) address and token. We now support
unlimited number of outstanding isoc and one outstanding bulk/intr/ctrl
transfer per QH (queue head). UHCI spec does not have a clear protocol for
the cancelation of the trasfer requests. Driver can yank out TDs on any
frame boundary. In oder to handle that I added somewhat fancy TD validation
logic logic to avoid unnecessary cancelations.
Signed-off-by: Max Krasnyansky <maxk@kernel.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5050 c046a42c-6fe2-441c-8c8c-71466251a162
