.readonly cannot be obtained from the MemoryRegion, since it is
inherited from aliases (so you can have a MemoryRegion mapped RW
at one address and RO at another). Record it in a MemoryRegionSection
for listeners.
Signed-off-by: Avi Kivity <avi@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
This allows reverse iteration, which in turns allows consistent ordering
among multiple listeners:
l1->add
l2->add
l2->del
l1->del
Signed-off-by: Avi Kivity <avi@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
memory_region_set_offset() complicates the API, and has been deprecated
since its introduction. Now that it is no longer used, remove it.
Signed-off-by: Avi Kivity <avi@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
memory_region_set_offset() will be going away soon, so don't use it.
Use an alias instead.
Signed-off-by: Avi Kivity <avi@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Like the related macro TCG_TARGET_LONG, HOST_LONG_BITS can be determined
by the C preprocessor. It is also not used in Makefiles.
So there is no need to calculate it in configure, and it can be defined
in qemu-common.h.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
The change in cpu.h is needed when HOST_LONG_BITS is defined in qemu-common.h.
Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
The change in cpu.h is needed when HOST_LONG_BITS is defined in qemu-common.h.
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Although qxl creates a shared displaysurface when the qxl surface is
upright and doesn't need to be flipped there is no guarantee that the
surface doesn't become unshared for some reason. Rename qxl_flip to
qxl_blit and fix it to handle both flip and non-flip cases.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
It's currently possible to setup spice channels using TLS when
no TLS port has been specified (ie TLS is disabled). This cannot
work, so better to error out in such a situation.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Error message reporting during spice startup wasn't consistent, it was done
with fprintf(stderr, "") but sometimes the message didn't have a trailing
\n. Using error_report make the intent of the message clearer and deal
with the final \n for us.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds an 64bit pci bar for vram. It is turned off by default.
It can be enabled by setting the size of the 64bit bar to be larger than
the 32bit bar. Both 32bit and 64bit bar refer to the same memory. Only
the first part of the memory is available via 32bit bar.
The intention is to allow large vram sizes for 64bit guests, by allowing
the vram bar being mapped above 4G, so we don't have to squeeze it into
the pci I/O window below 4G.
With vram_size_mb=16 and vram64_size_mb=256 it looks like this:
00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev 02) (prog-if 00 [VGA controller])
Subsystem: Red Hat, Inc Device 1100
Physical Slot: 2
Flags: fast devsel, IRQ 10
Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Memory at fd020000 (32-bit, non-prefetchable) [size=8K]
I/O ports at c5a0 [size=32]
Memory at ffe0000000 (64-bit, prefetchable) [size=256M]
Expansion ROM at fd000000 [disabled] [size=64K]
[ mapping above 4G needs patched seabios:
http://www.kraxel.org/cgit/seabios/commit/?h=pci64 ]
When creating an USB device the old way, there is no way to specify the
target bus. Thus the warning issued by usb_create makes no sense and
rather confuses our users.
Resolve this by passing a bus reference to the usbdevice_init handler
and letting those handlers forward it to usb_create.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The guest network stack might DHCPREQUEST an address that the slirp built
in dhcp server can't let it have - for example if the guest has an old
leases file from another network configuration. In this case the dhcp
server should and does reject the request and prepares to send a DHCPNAK
to the client.
However, in this case the daddr variable in bootp_reply() is set to
0.0.0.0. Shortly afterwards, it unconditionally attempts to pre-insert the
new client address into the ARP table. This causes an assertion failure in
arp_address_add() because of the 0.0.0.0 address.
According to RFC2131, DHCPNAK messages for clients on the same subnet
must be sent to the broadcast address (S3.2, subpoint 2).
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
In case we requeued a packet that was the head of a longer session
queue, we failed to restore this ordering. Also, we did not properly
deal with changes to Slirp::next_m.
Instead of a cumbersome roll back, this fix simply avoids any changes
until we know if the packet was actually sent. Both fixes crashes due
to inconsistent queues and simplifies the logic.
Thanks to Zhi Yong Wu who found the reason for these crashes.
CC: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
CC: Fabien Chouteau <chouteau@adacore.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Remove duplicate ifs_init macros, reimplement the logic as static inline
in mbuf.h.
CC: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
We should return USB_RET_NAK, rather then a 0 sized packet, when we've no data
for an interrupt IN endpoint.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The usbredir protocol uses a status of usb_redir_stall to indicate that
an iso data stream has stopped (ie because the urbs failed on resubmit),
but iso packets should never return a result of USB_RET_STALL, since iso
endpoints cannot stall. So instead simply always return USB_RET_NAK on
iso stream errors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
libusbredirparser-0.3.4 adds 2 new packets which allows us to notify
the usb-host:
-about the usb device filter we have (if any), so that it knows not the even
try to redirect certain devices
-when we reject a device based on filtering (in case it tries anyways)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Always call usbredir_device_disconnect() when usbredir_check_filter() fails
to clean up all the device state (ie received endpoint info).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The device version is in bcd format, which requires some special handling to
print.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Before this patch the ehci code was not checking for any other errors other
then USB_RET_NAK. This causes 2 problems:
1) Other errors are not reported to the guest.
2) When transactions with the ITD_XACT_IOC bit set completing with another
error would not result in USBSTS_INT getting set.
I hit this problem when unplugging devices while iso data was streaming from
the device to the guest. When this happens it takes a while for the guest to
process the unplugging and remove ISO transactions from the ehci schedule, in
the mean time these transactions would complete with a result of USB_RET_NODEV,
which was not handled. This lead to the Linux guest's usb subsystem "hanging",
that is it would no longer see new usb devices getting plugged in and running
for example lsusb would lead to a stuck (D state) lsusb process. This patch
fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Before commit ed5a83ddd8 each device
provided it's own response to USB_REQ_GET_STATUS, but after it that
response was based on bmAttributes, which was errounously set for
usb-ccid as 0xa0 and not 0xe0.
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Without it the produced library for make libcacard.la has an unresolved
symbol.
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Check for dev->config being NULL in two places:
USB_REQ_GET_CONFIGURATION and USB_REQ_GET_STATUS.
The behavior of USB_REQ_GET_STATUS is unspecified in the Default state,
that corresponds to dev->config being NULL (it defaults to NULL and is
reset whenever a SET_CONFIGURATION with value 0, or attachment). I
implemented it to correspond with the state before
ed5a83ddd8, the commit moving SET_STATUS
to usb-desc; if dev->config is not set we return whatever is in the
first configuration.
The behavior of USB_REQ_GET_CONFIGURATION is also undefined before any
SET_CONFIGURATION, but here we just return 0 (same as specified for the
Address state).
A win7 guest failed to initialize the device before this patch,
segfaulting when GET_STATUS was called with dev->config == NULL. With
this patch the passthrough device still doesn't work but the failure is
unrelated.
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds a sanity check to itd processing to make sure the
endpoint addressed by the guest is actually an iso endpoint. Also
verify that usb drivers don't return USB_RET_ASYNC which is illegal for
iso xfers.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When a usb device is busy processing a packet (and returns
USB_RET_ASYNC), continue walking the transfer descriptor list
and process them to fill the request queue.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Restruct the uhci_handle_td return code processing to make the
control flow more clear and the code more readable.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
UHCIAsync structs (in-flight requests) grouped in UHCIQueue now.
Each (active) usb endpoint gets its own UHCIQueue.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
