The inquiry command, for the case of VPD=1, was returning short
responses; the number of returned bytes was just the number of bytes
in the request, without padding to the specified allocation length
with zero bytes. This is usually harmless, but it is a violation
of the SCSI specification.
To fix this, always pad with zero bytes to r->cmd.xfer in
scsi_disk_emulate_command, and return at most r->buflen bytes
(the size of the buffer for command data) rather than at most
buflen bytes (the number of bytes that was filled in).
Before this patch, "strace sg_inq -p0x83 /dev/sda" would report a
non-zero resid value. After this patch, it reports resid=0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It works nicely with the QMP commands, but it adds useless complication
with HMP. In particular, see the following:
(qemu) nbd_server_add -w scsi0-hd0
(qemu) nbd_server_start -a localhost:10809
NBD server already exporting device scsi0-hd0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This failed on the new assertion of qemu_set_fd_handler2:
qemu-system-x86_64: /home/pbonzini/work/upstream/qemu/iohandler.c:60: qemu_set_fd_handler2: Assertion `fd >= 0' failed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The URI syntax is consistent with the Gluster syntax. Export names
are specified in the path, preceded by one or more (otherwise unused)
slashes.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The call to gen_logic_imm for OPC_LUI passes -1 for rs. This
causes the MIPS_DEBUG statement to seg fault due to the deference
of regnames[rs]. This patch fixes that.
Signed-off-by: Eric Johnson <ericj@mips.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
(aurel32: replaced static string formating by a static string)
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Acked-by: Richard Henderson <rth@twiddle.net>
Acked-by: Aurelien Jarno <aurelien@aurel32.net>
Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
This is setting the stage for a cleanup of FPREM and FPREM1 helpers while being
sure that they behave same as bare metal.
The test constructs operands using combinations of corner cases for the
floating-point bitfields and prints operands, result and FPU status word for
FPREM and FPREM1. The outputs can then be compared between bare metal and QEMU.
The 'run-test-i386-fprem' make target does just that.
Signed-off-by: Catalin Patulea <catalinp@google.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Cirrus is triggering this, e.g. during Win2k boot: Changes only on
disabled regions require no topology update when transaction depth drops
to 0 again.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
A compiler warning is caused by the unused local function reinit_timers
on non-POSIX hosts. Include that function only for POSIX hosts.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Keep saving display surface parameters at init and using these cached
values instead of getting them when needed. Not sure why this is
needed (maybe due to the interaction with the vga device) but not
doing this broke the Xorg vmware driver at least.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Since 0b57e287, cpu_memory_rw_debug already triggers a TB invalidation.
As it doesn't (and cannot) set is_cpu_write_access=1 but "consumes" the
currently executed TB, the tb_invalidate_phys_page_range call from
patch_instruction didn't work anymore.
Fix this by open-coding the required bits to restore the CPU state from
the current TB position before patching and resume execution on the
patched instruction afterward.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
The xhci device does correct endian switches on the results of some DMAs
but not all. In particular, there are many DMAs of what are essentially
arrays of 32-bit integers which never get byteswapped. This causes them
to be interpreted incorrectly on big-endian hosts, since (as per the xhci
spec) these arrays are always little-endian in guest memory.
This patch adds some helper functions to fix these bugs. This may not be
all the endian bugs in the xhci code, but it's certainly some of them and
the Linux guest xhci driver certainly gets further with these fixes.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Instead make ehci_execute and ehci_fill_queue return the again value.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Since with the ehci and xhci controllers a single packet can be larger
then maxpacketsize, it is possible for the result of a single packet
to be both having transferred some data as well as the transfer to have
an error.
An example would be an input transfer from a bulk endpoint successfully
receiving 1 or more maxpacketsize packets from the device, followed
by a packet signalling halt.
While already touching all the devices and controllers handle_packet /
handle_data / handle_control code, also change the return type of
these functions to void, solely storing the status in the packet. To
make the code paths for regular versus async packet handling more
uniform.
This patch unfortunately is somewhat invasive, since makeing the qemu
usb core deal with this requires changes everywhere. This patch only
prepares the usb core for this, all the hcd / device changes are done
in such a way that there are no functional changes.
This patch has been tested with uhci and ehci hcds, together with usb-audio,
usb-hid and usb-storage devices, as well as with usb-redir redirection
with a wide variety of real devices.
Note that there is usually no need to directly set packet->actual_length
form devices handle_data callback, as that is done by usb_packet_copy()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The swaph instruction was not decoding correctly. s/1e1/1e2 on the
9 LSBs on the instruction decode.
Reported-by: David Holsgrove <david.holsgrove@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Tools were broken because they initialized the block layer while
qemu_aio_context was still NULL.
Reported-by: malc <av1474@comtv.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
mmu access looks something like:
<check tlb>
if miss goto slow_path
<fast path>
done:
...
; end of the TB
slow_path:
<pre process>
mr r3, r27 ; move areg0 to r3
; (r3 holds the first argument for all the PPC32 ABIs)
<call mmu_helper>
b $+8
.long done
<post process>
b done
On ppc32 <call mmu_helper> is:
(SysV and Darwin)
mmu_helper is most likely not within direct branching distance from
the call site, necessitating
a. moving 32 bit offset of mmu_helper into a GPR ; 8 bytes
b. moving GPR to CTR/LR ; 4 bytes
c. (finally) branching to CTR/LR ; 4 bytes
r3 setting - 4 bytes
call - 16 bytes
dummy jump over retaddr - 4 bytes
embedded retaddr - 4 bytes
Total overhead - 28 bytes
(PowerOpen (AIX))
a. moving 32 bit offset of mmu_helper's TOC into a GPR1 ; 8 bytes
b. loading 32 bit function pointer into GPR2 ; 4 bytes
c. moving GPR2 to CTR/LR ; 4 bytes
d. loading 32 bit small area pointer into R2 ; 4 bytes
e. (finally) branching to CTR/LR ; 4 bytes
r3 setting - 4 bytes
call - 24 bytes
dummy jump over retaddr - 4 bytes
embedded retaddr - 4 bytes
Total overhead - 36 bytes
Following is done to trim the code size of slow path sections:
In tcg_target_qemu_prologue trampolines are emitted that look like this:
trampoline:
mfspr r3, LR
addi r3, 4
mtspr LR, r3 ; fixup LR to point over embedded retaddr
mr r3, r27
<jump mmu_helper> ; tail call of sorts
And slow path becomes:
slow_path:
<pre process>
<call trampoline>
.long done
<post process>
b done
call - 4 bytes (trampoline is within code gen buffer
and most likely accessible via
direct branch)
embedded retaddr - 4 bytes
Total overhead - 8 bytes
In the end the icache pressure is decreased by 20/28 bytes at the cost
of an extra jump to trampoline and adjusting LR (to skip over embedded
retaddr) once inside.
Signed-off-by: malc <av1474@comtv.ru>
Register displaychangelistener last, after spice is fully initialized,
otherwise we may hit NULL pointer dereferences when qemu starts calling
our callbacks.
Commit e250d949fe triggers this bug.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When entering vga mode the display size likely changes,
notify all displaychangelisteners about this.
Probably went unnoticed for a while as one if the first
things the guest does after leaving qxl native mode and
entering qxl vga mode is to set the vga video mode. But
there is still a small window where qemu can operate on
stale data, leading to crashes now and then.
https://bugzilla.redhat.com/show_bug.cgi?id=865767
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Due to usage of pixman for rendering on all spice surfaces we have
pixman's requirement that the stride be word aligned. A guest not
honoring that can crash spice and qemu with it due to failure to create
a surface (in spice-server). Avoid this early on in primary surface
creation and offscreen surface creation.
Recently windows guests got odd width support which triggers a non word
aligned primary surface in 16bit color depth. Off screen surfaces have
always been word aligned, but doesn't hurt to check them here too.
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fix build on a 32 bit host:
CC mips-softmmu/target-mips/dsp_helper.o
/src/qemu/target-mips/dsp_helper.c: In function 'helper_dextr_rs_w':
/src/qemu/target-mips/dsp_helper.c:3556: error: integer constant is too large for 'long' type
/src/qemu/target-mips/dsp_helper.c: In function 'helper_extr_s_h':
/src/qemu/target-mips/dsp_helper.c:3656: error: integer constant is too large for 'long' type
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Postpone stopping the dirty log to the point where the command fifo is
configured to allow drivers which don't use the fifo to work too.
(Without this the picture rendered into the vram never got to the
screen and the DIRECT_VRAM option meant to support this case was
removed a year ago.)
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
According to the documentation drivers using this device should read
FB_SIZE before enabling the device to know what memory to map. This
would not work if we return 0 before enabled. The docs also mention
reading SVGA_REG_DEPTH but not writing it. (Only SVGA_REG_BITS_PER_PIXEL
can be written but we don't really support that either.)
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
