TYPE_TCG_ACCEL to register "info jit"
and devices can add whatever debug monitor commands they need.
ATB,
Mark.
On 11/06/2024 07:58, Manos Pitsidianakis wrote:
On Tue, 11 Jun 2024 at 09:11, Mark Cave-Ayland
wrote:
On 11/06/2024 06:49, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
Officialise the QMP command, use the existing
hmp_info_human_readable_text() helper.
I'm not sure
were to change from "info via" to "debug via" I don't see there would be a
big problem with this.
ATB,
Mark.
On 06/06/2024 10:53, Mark Cave-Ayland wrote:
Instead of directly implementing the writeback using gen_op_st_v(), use the
existing gen_writeback() function.
Suggested-by: Paolo Bonzini
Signed-off-by: Mark Cave-Ayland
---
target/i386/tcg/emit.c.inc | 2 +-
1 file changed, 1 insertion(+), 1
ht also be:
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2319
ATB,
Mark.
-by: Mark Cave-Ayland
Mark Cave-Ayland (4):
target/i386: use local X86DecodedOp in gen_POP()
target/i386: use gen_writeback() within gen_POP()
target/i386: fix SP when taking a memory fault during POP
target/i386: fix size of EBP writeback in gen_enter()
target/i386/tcg/emit.c.inc | 8
is done using MO_16 which can leave junk in the top
16-bits of EBP after executing ENTER.
Change the writeback of EBP to use the same size indicated by mo_pushpop() to
ensure that the full value is written back.
Signed-off-by: Mark Cave-Ayland
Resolves: https://gitlab.com/qemu-project/qemu/-/issues
Instead of directly implementing the writeback using gen_op_st_v(), use the
existing gen_writeback() function.
Suggested-by: Paolo Bonzini
Signed-off-by: Mark Cave-Ayland
---
target/i386/tcg/emit.c.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/tcg
-off-by: Mark Cave-Ayland
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198
---
target/i386/tcg/emit.c.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index 2d5dc11548..f905a67380 100644
--- a/target/i386/tcg
This will make subsequent changes a little easier to read.
Signed-off-by: Mark Cave-Ayland
---
target/i386/tcg/emit.c.inc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index e990141454..a89f8e0ebb 100644
On 03/06/2024 12:40, Daniel P. Berrangé wrote:
On Thu, May 30, 2024 at 01:22:11PM +0100, Mark Cave-Ayland wrote:
On 30/05/2024 12:40, BALATON Zoltan wrote:
On Thu, 30 May 2024, Gerd Hoffmann wrote:
stdvga is the much better option.
Signed-off-by: Gerd Hoffmann
---
hw/display/cirrus_vga.c
On 28/05/2024 22:29, Mark Cave-Ayland wrote:
On 26/05/2024 20:42, Richard Henderson wrote:
Now tested with RISU, using a Solaris M8 host as reference.
This exposed a few bugs in the existing VIS1 support as well,
so fix those before anything else. It also exposed a few bugs
nges for it lately. If something works why drop it?
Seconded: whilst stdvga is preferred, there are a lot of older OSs that work well in
QEMU using the Cirrus emulation. I appreciate that the code could do with a bit of
work, but is there a more specific reason that it should be deprecated?
ATB,
Mark.
s/about/deprecated.rst to really mark it as
deprecated, since that's our official list (AFAIK).
Also, there are still some machines that use this device:
$ grep -r USB_OHCI_PCI *
hw/hppa/Kconfig: imply USB_OHCI_PCI
hw/mips/Kconfig: imply USB_OHCI_PCI
hw/ppc/Kconfig: imply USB_OHCI_PCI
hw
files changed, 1558 insertions(+), 331 deletions(-)
Thanks - I'll give this series a quick run over my test images over the next few days
just to make sure there are no regressions (unlikely as I don't have much in the way
of current VIS test cases) and report back.
ATB,
Mark.
, but obviously there are clear benefits to having SPARC support included :)
ATB,
Mark.
On 15/05/2024 16:30, Richard Henderson wrote:
On 4/29/24 23:02, Richard Henderson wrote:
On 4/29/24 13:52, Mark Cave-Ayland wrote:
No objections here about the remainder of the series, other than that I don't have
an easy/obvious way to test the new instructions...
I was thinking about
From: Richard Henderson
Not only do these instructions have f32 inputs, they also do not
perform rounding. Since these are relatively simple, implement
them properly inline.
Signed-off-by: Richard Henderson
Message-Id: <20240502165528.244004-6-richard.hender...@linaro.org>
Signed-off-by
hieu-Daudé
Message-Id: <20240502165528.244004-8-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-Ayland
---
target/sparc/vis_helper.c | 78 ---
1 file changed, 24 insertions(+), 54 deletions(-)
diff --git a/target/sparc/vis_helper.c b/target/sparc/vi
From: Richard Henderson
This instruction has f32 inputs, which changes the decode
of the register numbers.
Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20240502165528.244004-7-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-Ayland
---
target
4-4-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-Ayland
---
target/sparc/helper.h | 2 +-
target/sparc/translate.c | 21 -
target/sparc/vis_helper.c | 9 +
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/target/sparc/helper.h b/target
).
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2141
Signed-off-by: Thomas Huth
Reviewed-by: Mark Cave-Ayland
Reviewed-by: Richard Henderson
Message-Id: <20240419084812.504779-4-th...@redhat.com>
Signed-off-by: Mark Cave-Ayland
---
docs/system/target-sparc.rst | 12 +++-
virtio driver where this
is not the case.
Set the sun4u machine defaults for all virtio devices so that disable-legacy=on
and iommu_platform=on to ensure a default configuration will allow virtio
devices to function correctly on both Linux and NetBSD.
Signed-off-by: Mark Cave-Ayland
Message-Id
Message-Id: <20240502165528.244004-5-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-Ayland
---
target/sparc/helper.h | 3 +--
target/sparc/translate.c | 38 +++
target/sparc/vis_helper.c | 47 +++
3 files chang
From: Richard Henderson
Supply HWCAP_SPARC_V8PLUS, HWCAP_SPARC_MUL32, HWCAP_SPARC_DIV32,
HWCAP_SPARC_POPC, HWCAP_SPARC_FSMULD, HWCAP_SPARC_VIS, HWCAP_SPARC_VIS2.
Signed-off-by: Richard Henderson
Message-Id: <20240502165528.244004-2-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-
From: Richard Henderson
This is a 2-operand instruction, not 3-operand.
Worse, we took the source from the wrong operand.
Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20240502165528.244004-3-richard.hender...@linaro.org>
Signed-off-by: Mark Cave-
From: Thomas Huth
For consistency we should drop the names with a "+" in it in the
long run.
Reviewed-by: Mark Cave-Ayland
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Message-Id: <20240419084812.504779-5-th...@redhat.com>
Sig
PU names, and provide
backward compatibility for the old names via some simple checks in the
sparc_cpu_class_by_name() function.
Reviewed-by: Mark Cave-Ayland
Signed-off-by: Thomas Huth
Reviewed-by: Richard Henderson
Message-Id: <20240419084812.504779-2-th...@redhat.com>
Signed-off-by: Mark Cave-
Reviewed-by: Richard Henderson
Reviewed-by: Mark Cave-Ayland
Signed-off-by: Thomas Huth
Message-Id: <20240419084812.504779-3-th...@redhat.com>
Signed-off-by: Mark Cave-Ayland
---
target/sparc/cpu.c | 56 +++---
1 file changed, 28 insertions(+), 28 del
VIS instructions from Richard
- CPU name updates from Thomas
Mark Cave-Ayland (1):
hw/sparc64: set iommu_platform=on for virtio devices attached to the
sun4u machine
Richard Henderson (7):
linux-user/sparc: Add more
On 03/05/2024 19:18, Philippe Mathieu-Daudé wrote:
On 2/5/24 18:55, Richard Henderson wrote:
Split out from my vis4 patch set, with just the bug fixes.
I've fixed the issue in patch 6, as noticed by Mark, but
include the follow-up that cleans up all of the macros by
removing them.
r
On 02/05/2024 17:55, Richard Henderson wrote:
Split out from my vis4 patch set, with just the bug fixes.
I've fixed the issue in patch 6, as noticed by Mark, but
include the follow-up that cleans up all of the macros by
removing them.
r~
Richard Henderson (7):
linux-user/sparc: Add more
piling C object
libqemu-sparc64-softmmu.fa.p/target_sparc_translate.c.o
ninja: build stopped: subcommand failed.
make: *** [Makefile:167: run-ninja] Error 1
ATB,
Mark.
a longstanding softmmu bug that caused kernel panics
when the UserTxt ASI was accessed.
Appreciated,
-- Bazz
I've just updated the 9.0 changelog with an improved version of the above wording as
requested.
ATB,
Mark.
On 29/04/2024 22:02, Richard Henderson wrote:
On 4/29/24 13:52, Mark Cave-Ayland wrote:
No objections here about the remainder of the series, other than that I don't have
an easy/obvious way to test the new instructions...
I was thinking about adding support to RISU, but the gcc compile farm
docs/system/target-sparc.rst | 12 ---
qom/object.c | 8 -
target/sparc/cpu.c | 66 +---
4 files changed, 54 insertions(+), 41 deletions(-)
Thanks! I've applied this to my qemu-sparc branch, along with Peter's suggested tweak
to the grammar in patch 3.
ATB,
Mark.
/obvious way to test the new instructions...
ATB,
Mark.
On 25/04/2024 11:26, Manos Pitsidianakis wrote:
On Thu, 25 Apr 2024 at 13:24, Michael S. Tsirkin wrote:
On Thu, Apr 25, 2024 at 01:04:31PM +0300, Manos Pitsidianakis wrote:
On Thu, 25 Apr 2024 at 10:49, Mark Cave-Ayland
wrote:
On 25/04/2024 07:30, Manos Pitsidianakis wrote:
On Wed, 24
On 25/04/2024 11:04, Manos Pitsidianakis wrote:
On Thu, 25 Apr 2024 at 10:49, Mark Cave-Ayland
wrote:
On 25/04/2024 07:30, Manos Pitsidianakis wrote:
On Wed, 24 Apr 2024 at 13:31, Mark Cave-Ayland
wrote:
On 23/04/2024 12:05, Philippe Mathieu-Daudé wrote:
On 23/4/24 11:18, Manos
On 25/04/2024 07:30, Manos Pitsidianakis wrote:
On Wed, 24 Apr 2024 at 13:31, Mark Cave-Ayland
wrote:
On 23/04/2024 12:05, Philippe Mathieu-Daudé wrote:
On 23/4/24 11:18, Manos Pitsidianakis wrote:
On Tue, 23 Apr 2024 at 11:47, Manos Pitsidianakis
wrote:
On Tue, 23 Apr 2024 at 00:11
le
endian.
ATB,
Mark.
On 23/04/2024 10:18, Paolo Bonzini wrote:
On Mon, Apr 22, 2024 at 9:10 PM Volker Rümelin wrote:
Am 20.04.24 um 07:40 schrieb Mark Cave-Ayland:
Current documentation agrees that all 32 bits are written, so I don't
think you need this comment:
Ah that's good to know the docs are now correct
On 20/04/2024 00:14, Brad Smith wrote:
On 2024-04-18 4:27 p.m., Mark Cave-Ayland wrote:
On 07/03/2024 17:43, Thomas Huth wrote:
Add some words about how to enable or disable boolean features,
and remove the note about a Linux kernel being available on the
QEMU website (they have been removed
On 20/04/2024 02:21, Richard Henderson wrote:
On 4/19/24 12:51, Mark Cave-Ayland wrote:
The various Intel CPU manuals claim that SGDT and SIDT can write either 24-bits
or 32-bits depending upon the operand size, but this is incorrect. Not only do
the Intel CPU manuals give contradictory
matches the behaviour on real
hardware.
Signed-off-by: Mark Cave-Ayland
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198
--
MCA: Whilst I don't have a copy of OS/2 Warp handy, I've confirmed that this
patch fixes the issue in WFW 3.11 with Win32s. For more technical information I
highly
Solaris.
Reviewed-by: Mark Cave-Ayland
ATB,
Mark.
On 19/04/2024 05:59, Thomas Huth wrote:
On 18/04/2024 22.27, Mark Cave-Ayland wrote:
On 07/03/2024 17:43, Thomas Huth wrote:
Add some words about how to enable or disable boolean features,
and remove the note about a Linux kernel being available on the
QEMU website (they have been removed
virtio driver where this
is not the case.
Set the sun4u machine defaults for all virtio devices so that disable-legacy=on
and iommu_platform=on to ensure a default configuration will allow virtio
devices to function correctly on both Linux and NetBSD.
Signed-off-by: Mark Cave-Ayland
---
hw/sparc64
On 18/04/2024 21:08, Mark Cave-Ayland wrote:
On 15/04/2024 08:26, Thomas Huth wrote:
On 07/03/2024 18.43, Thomas Huth wrote:
The Sparc CPU naming and the corresponding help text is somewhat
confusing for the users. We should avoid spaces in the Names and
provide clear information
'''
See my previous comment about the CPU names, otherwise:
Reviewed-by: Mark Cave-Ayland
ATB,
Mark.
aris kernels
don't work probably due to interface issues between OpenBIOS and
Solaris.
Just curious as to what current issues exist with NetBSD and OpenBSD? At least both
my NetBSD and OpenBSD test images survive a casual boot test here with latest git.
ATB,
Mark.
heir names
target/sparc/cpu: Avoid spaces by default in the CPU names
target/sparc/cpu: Improve the CPU help text
docs/system/target-sparc: Improve the Sparc documentation
docs/about: Deprecate the old "UltraSparc" CPU names that contain a
"+"
Ping!
Mark, Aryom,
ocessors in the form "UltraSparc
IIIi plus" so I'd be inclined to use that form for the new type names e.g.
"UltraSparc-IIIi-plus".
Otherwise looks good to me, thanks for having a look at this!
Reviewed-by: Mark Cave-Ayland
ATB,
Mark.
sparc_defs[] = {
.features = CPU_DEFAULT_FEATURES,
},
{
-.name = "TI SuperSparc 60", /* STP1020APGA */
+.name = "TI-SuperSparc-60", /* STP1020APGA */
.iu_version = 0x4000, /* SuperSPARC 3.x */
.fpu_version = 0 << FSR_VER_SHIFT,
.mmu_version = 0x01000800, /* SuperSPARC 3.x, no MXCC */
@@ -484,7 +484,7 @@ static const sparc_def_t sparc_defs[] = {
.features = CPU_DEFAULT_FEATURES,
},
{
-.name = "TI SuperSparc 61",
+.name = "TI-SuperSparc-61",
.iu_version = 0x4400, /* SuperSPARC 3.x */
.fpu_version = 0 << FSR_VER_SHIFT,
.mmu_version = 0x0100, /* SuperSPARC 3.x, MXCC */
@@ -498,7 +498,7 @@ static const sparc_def_t sparc_defs[] = {
.features = CPU_DEFAULT_FEATURES,
},
{
-.name = "TI SuperSparc II",
+.name = "TI-SuperSparc-II",
.iu_version = 0x4000, /* SuperSPARC II 1.x */
.fpu_version = 0 << FSR_VER_SHIFT,
.mmu_version = 0x0800, /* SuperSPARC II 1.x, MXCC */
Thanks Thomas, this looks much better!
Reviewed-by: Mark Cave-Ayland
ATB,
Mark.
d();
+#endif
+
default:
/* ??? In theory we've handled all of the ASIs that are valid
for ldda, and this should raise DAE_invalid_asi. However,
Thanks for the excellent analysis, and also thanks to Richard for improving the
correctness of the patch:
Acked-by: Mark Cave-Ayland
ATB,
Mark.
There are still a few places that use fifo8_push() instead of esp_fifo_push() in
order to push a value into the FIFO. Update those places to use esp_fifo_push()
instead.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id
Now that all users of esp_fifo_pop_buf() operate on the main FIFO there is no
need to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-9-mark.cave-ayl...@ilande.co.uk>
Signed-off-by
This allows these functions to be used earlier in the file without needing a
separate forward declaration.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-14-mark.cave-ayl...@ilande.co.uk>
Signed-off-by
This ensures that the DRQ line is always set correctly when reading/writing
single bytes to/from the FIFO.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-16-mark.cave-ayl...@ilande.co.uk>
Signed-off-by
Now the esp_update_drq() is called for all reads/writes to the FIFO, there is
no need to manually raise and lower the DRQ signal.
Signed-off-by: Mark Cave-Ayland
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/611
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1831
Reviewed
The current logic assumes that at least 1 byte is present in the FIFO when
executing a non-DMA SELATNS command, but this may not be the case if the
guest executes an invalid ESP command sequence.
Reported-by: Chuhong Yuan
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Paolo Bonzini
Reviewed
The aim is to restrict the esp_fifo_*() functions so that they only operate on
the hardware FIFO. When reading from cmdfifo in do_message_phase() use the
underlying esp_fifo8_pop_buf() function directly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu
This ensures that esp_update_drq() is called via esp_fifo_push() whenever the
host uses PDMA to transfer data to a SCSI device.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-17-mark.cave-ayl...@ilande.co
The aim is to restrict the esp_fifo_*() functions so that they only operate on
the hardware FIFO. When reading from cmdfifo in do_command_phase() use the
underlying esp_fifo8_pop_buf() function directly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu
This new function sets the DRQ line correctly according to the current transfer
mode, direction and FIFO contents. Update esp_fifo_push_buf() and
esp_fifo_pop_buf()
to use it so that DRQ is always set correctly when reading/writing multiple
bytes
to/from the FIFO.
Signed-off-by: Mark Cave
Now that all users of esp_fifo_push() operate on the main FIFO there is no need
to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-6-mark.cave-ayl...@ilande.co.uk>
Signed-off-by
callers.
Suggested-by: Paolo Bonzini
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20240324191707.623175-12-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 30 ++-
Instead of pushing data into the FIFO directly with fifo8_push_all(), add a new
esp_fifo_push_buf() function and use it accordingly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-10-mark.cave-
Update esp_fifo_pop_buf() to be a simple wrapper onto the new
esp_fifo8_pop_buf()
function.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Paolo Bonzini
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20240324191707.623175-2-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Mark Cave-
the end of the FIFO
data buffer.
Add an extra check to fifo8_peek_buf() to ensure that if the cmdfifo has wrapped
internally then esp_cdb_ready() will exit rather than allow scsi_cdb_length() to
access data outside the cmdfifo data buffer.
Reported-by: Chuhong Yuan
Signed-off-by: Mark Cave-Ayland
by fuzzing (with thanks
to
Chuhong Yuan )
Mark Cave-Ayland (17):
esp.c: move esp_fifo_pop_buf() internals to new esp_fifo8_pop_buf()
function
esp.c: replace esp_fifo_pop_buf() with esp_fifo8_pop_buf() in
do_command_phase
Now that all users of esp_fifo_pop() operate on the main FIFO there is no need
to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-7-mark.cave-ayl...@ilande.co.uk>
Signed-off-by
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Paolo Bonzini
Message-Id: <20240324191707.623175-5-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/h
On 04/04/2024 11:28, Philippe Mathieu-Daudé wrote:
Hi Mark,
On 24/3/24 20:16, Mark Cave-Ayland wrote:
Mark Cave-Ayland (17):
esp.c: move esp_fifo_pop_buf() internals to new esp_fifo8_pop_buf()
function
esp.c: replace esp_fifo_pop_buf() with esp_fifo8_pop_buf
warn that way?
FWIW I'd be amazed if anyone were actually overriding the default and trying to do
this, but I guess that's what the warn_report() is for anyhow:
Reviewed-by: Mark Cave-Ayland
ATB,
Mark.
On 27/03/2024 07:09, Gerd Hoffmann wrote:
On Tue, Mar 26, 2024 at 01:30:48PM +, Mark Cave-Ayland wrote:
Heh I've actually been using isapc over the past couple of weeks to fire up
some old programs in a Windows 3 VM :)
I'm wondering why these use cases can't simply use the 'pc' machine
m->deprecation_reason = "old and unattended - use a newer version instead";
}
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
ATB,
Mark.
On 25/03/2024 10:49, Philippe Mathieu-Daudé wrote:
On 24/3/24 20:16, Mark Cave-Ayland wrote:
The current logic assumes that at least 1 byte is present in the FIFO when
executing a non-DMA SELATNS command, but this may not be the case if the
guest executes an invalid ESP command sequence
On 25/03/2024 10:26, Philippe Mathieu-Daudé wrote:
On 24/3/24 20:17, Mark Cave-Ayland wrote:
During normal use the cmdfifo will never wrap internally and cmdfifo_cdb_offset
will always indicate the start of the SCSI CDB. However it is possible that a
malicious guest could issue an invalid ESP
The current logic assumes that at least 1 byte is present in the FIFO when
executing a non-DMA SELATNS command, but this may not be the case if the
guest executes an invalid ESP command sequence.
Reported-by: Chuhong Yuan
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 3 ++-
1 file
The aim is to restrict the esp_fifo_*() functions so that they only operate on
the hardware FIFO. When reading from cmdfifo in do_command_phase() use the
underlying esp_fifo8_pop_buf() function directly.
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 2 +-
1 file changed, 1 insertion(+), 1
Now that all users of esp_fifo_pop_buf() operate on the main FIFO there is no
need to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
There are still a few places that use fifo8_push() instead of esp_fifo_push() in
order to push a value into the FIFO. Update those places to use esp_fifo_push()
instead.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 6 +++---
1 file changed, 3
Now that all users of esp_fifo_pop() operate on the main FIFO there is no need
to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/esp.c b/hw
callers.
Suggested-by: Paolo Bonzini
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index f3aa5364cf..f47abc36d6 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
This ensures that the DRQ line is always set correctly when reading/writing
single bytes to/from the FIFO.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/scsi/esp.c b
This ensures that esp_update_drq() is called via esp_fifo_push() whenever the
host uses PDMA to transfer data to a SCSI device.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
This new function sets the DRQ line correctly according to the current transfer
mode, direction and FIFO contents. Update esp_fifo_push_buf() and
esp_fifo_pop_buf()
to use it so that DRQ is always set correctly when reading/writing multiple
bytes
to/from the FIFO.
Signed-off-by: Mark Cave
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 9386704a58..5b169b3720 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -315,7 +315,8 @@ static void
Instead of pushing data into the FIFO directly with fifo8_push_all(), add a new
esp_fifo_push_buf() function and use it accordingly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff
Now the esp_update_drq() is called for all reads/writes to the FIFO, there is
no need to manually raise and lower the DRQ signal.
Signed-off-by: Mark Cave-Ayland
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/611
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1831
---
hw/scsi
The aim is to restrict the esp_fifo_*() functions so that they only operate on
the hardware FIFO. When reading from cmdfifo in do_message_phase() use the
underlying esp_fifo8_pop_buf() function directly.
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 2 +-
1 file changed, 1 insertion(+), 1
the end of the FIFO
data buffer.
Add an extra check to fifo8_peek_buf() to ensure that if the cmdfifo has wrapped
internally then esp_cdb_ready() will exit rather than allow scsi_cdb_length() to
access data outside the cmdfifo data buffer.
Reported-by: Chuhong Yuan
Signed-off-by: Mark Cave-Ayland
This allows these functions to be used earlier in the file without needing a
separate forward declaration.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff
all manual calls to esp_raise_drq() and esp_lower_drq()
since the DRQ signal is now updated correctly upon each FIFO read/write access.
Signed-off-by: Mark Cave-Ayland
v3:
- Rebase onto master
- Add patch 1 to move the internals of esp_fifo_pop_buf() to a new
esp_fifo8_pop_buf() function. T
Update esp_fifo_pop_buf() to be a simple wrapper onto the new
esp_fifo8_pop_buf()
function.
Signed-off-by: Mark Cave-Ayland
---
hw/scsi/esp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 590ff99744..1b7b118a0b 100644
--- a/hw
Now that all users of esp_fifo_push() operate on the main FIFO there is no need
to pass the FIFO explicitly.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Philippe Mathieu-Daudé
---
hw/scsi/esp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/esp.c b/hw
> On 20 Mar 2024, at 16:00, Peter Maydell wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On Wed, 20 Mar 2024 at 14:10, Mark Burton wrote:
>> I’d broaden this to all ’
> On 20 Mar 2024, at 14:55, Peter Maydell wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On Wed, 20 Mar 2024 at 12:31, Mark Burton wrote:
>>> On 20 Mar 2024, at
case you can only do that from the HMP command, not the QMP
> command, AIUI), so getting rid of that weird inconsistency makes
> sense to me: and that's what this patchset is doing.
>
> What NMI probably ought to be is board-specific: so it's like
> having some notional front panel swi
1 - 100 of 6387 matches
Mail list logo