[Qemu-devel] [PATCH, Bug 1612908] scripts: Add ability for qom-* python scripts to target tcp endpoints
From: Carl Allendorph
The current code for QEMUMonitorProtocol accepts both a unix socket
endpoint as a string and a tcp endpoint as a tuple. Most of the scripts
that use this class don't massage the command line argument to generate
a tuple. This patch refactors qmp-shell slightly to reuse the existing
parsing of the "host:port" string for all the qom-* scripts.
Signed-off-by: Carl Allendorph
---
scripts/qmp/qmp-shell | 22 ++
scripts/qmp/qmp.py| 23 ---
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index 0373b24..8a2a437 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -83,9 +83,6 @@ class QMPCompleter(list):
class QMPShellError(Exception):
pass
-class QMPShellBadPort(QMPShellError):
-pass
-
class FuzzyJSON(ast.NodeTransformer):
'''This extension of ast.NodeTransformer filters literal "true/false/null"
values in an AST and replaces them by proper "True/False/None" values that
@@ -103,28 +100,13 @@ class FuzzyJSON(ast.NodeTransformer):
# _execute_cmd()). Let's design a better one.
class QMPShell(qmp.QEMUMonitorProtocol):
def __init__(self, address, pretty=False):
-qmp.QEMUMonitorProtocol.__init__(self, self.__get_address(address))
+qmp.QEMUMonitorProtocol.__init__(self, address)
self._greeting = None
self._completer = None
self._pretty = pretty
self._transmode = False
self._actions = list()
-def __get_address(self, arg):
-"""
-Figure out if the argument is in the port:host form, if it's not it's
-probably a file path.
-"""
-addr = arg.split(':')
-if len(addr) == 2:
-try:
-port = int(addr[1])
-except ValueError:
-raise QMPShellBadPort
-return ( addr[0], port )
-# socket path
-return arg
-
def _fill_completion(self):
for cmd in self.cmd('query-commands')['return']:
self._completer.append(cmd['name'])
@@ -400,7 +382,7 @@ def main():
if qemu is None:
fail_cmdline()
-except QMPShellBadPort:
+except qmp.QMPShellBadPort:
die('bad port number in command-line')
try:
diff --git a/scripts/qmp/qmp.py b/scripts/qmp/qmp.py
index 62d3651..261ece8 100644
--- a/scripts/qmp/qmp.py
+++ b/scripts/qmp/qmp.py
@@ -25,21 +25,23 @@ class QMPCapabilitiesError(QMPError):
class QMPTimeoutError(QMPError):
pass
+class QMPShellBadPort(QMPError):
+pass
+
class QEMUMonitorProtocol:
def __init__(self, address, server=False, debug=False):
"""
Create a QEMUMonitorProtocol class.
@param address: QEMU address, can be either a unix socket path (string)
-or a tuple in the form ( address, port ) for a TCP
-connection
+or a TCP endpoint (string in the format "host:port")
@param server: server mode listens on the socket (bool)
@raise socket.error on socket connection errors
@note No connection is established, this is done by the connect() or
accept() methods
"""
self.__events = []
-self.__address = address
+self.__address = self.__get_address(address)
self._debug = debug
self.__sock = self.__get_sock()
if server:
@@ -47,6 +49,21 @@ class QEMUMonitorProtocol:
self.__sock.bind(self.__address)
self.__sock.listen(1)
+def __get_address(self, arg):
+"""
+Figure out if the argument is in the port:host form, if it's not it's
+probably a file path.
+"""
+addr = arg.split(':')
+if len(addr) == 2:
+try:
+port = int(addr[1])
+except ValueError:
+raise QMPShellBadPort
+return ( addr[0], port )
+# socket path
+return arg
+
def __get_sock(self):
if isinstance(self.__address, tuple):
family = socket.AF_INET
--
2.7.4
[Qemu-devel] [PATCH, Bug 1612908] scripts: Add TCP endpoints for qom-* scripts
From: Carl Allendorph I've created a patch for bug #1612908. The current docs for the scripts in the "scripts/qmp/" directory suggest that both unix sockets and tcp endpoints can be used. The TCP endpoints don't work for most of the scripts, with notable exception of 'qmp-shell'. This patch attempts to refactor the process of distinguishing between unix path endpoints and tcp endpoints to work for all of these scripts. Carl Allendorph (1): scripts: Add ability for qom-* python scripts to target tcp endpoints scripts/qmp/qmp-shell | 22 ++ scripts/qmp/qmp.py| 23 --- 2 files changed, 22 insertions(+), 23 deletions(-) -- 2.7.4
[Qemu-devel] adding search to dhcp
man qemu... hostname=name Specifies the client hostname reported by the builtin DHCP server. I would like to add a technically similar option: search It would be sent along the same path that the above hostname parameter takes. This would allow the guest OS to reference other boxes on my LAN by just hostname, not FQDN. I have many scripts that rely on this, and so they break when I try to run them in a qemu vm. man dhcp-options option domain-search domain-list; The domain-search option specifies a 'search list' of Domain Names to be used by the client to locate not-fully-qualified domain names. The difference between this option and historic use of the domain- name option for the same ends is that this option is encoded in RFC1035 compressed labels on the wire. For example: option domain-search "example.com", "sales.example.com", "eng.example.com"; I would expect the syntax to look like this: qemu -hda 1.qcow2 -net nick -net user,hostname=qemu,search=example.com,sales.example.com -- Carl K
Re: [Qemu-devel] adding search to dhcp
On Wed, May 11, 2011 at 6:01 AM, Markus Armbruster wrote: > Stefan Hajnoczi writes: > >> On Tue, May 10, 2011 at 6:40 PM, Carl Karsten wrote: >>> I would expect the syntax to look like this: >>> >>> qemu -hda 1.qcow2 -net nick -net >>> user,hostname=qemu,search=example.com,sales.example.com >> >> Comma escaping is needed but it seems like a reasonable feature to me. > > Comma escaping is ugly: > -net user,hostname=qemu,search=example.com,,sales.example.com > > Could we have multiple search options instead? Like this: > -net user,hostname=qemu,search=example.com,search=sales.example.com > How about: -net user,hostname=qemu,search="example.com,sales.example.com" Given I personally only need one search domain, any objection to me only writing the code to support 1? I would think the simple case search=example.com should be the same regardless of how someone implemented multiples. -- Carl K
[Qemu-devel] Re: livecd
Thanks for the links, Jure. Now for a bug report: I am trying to run Webconverger in the qemu VM. firefox3.iso and MorphixLiveKiosk_0.03.iso worked fine, but wc-2.4.img, wc-2.4.img, wc-1.8.iso all drop to the busybox prompt, but no definitive reason why. [EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio Could not open '/dev/kqemu' - QEMU acceleration layer not activated ACPI: Unable to locate RSDP PCI: PIIX3: Enabling Passive Release on :00:01.0 Loading, please wait... FATAL: Error inserting fan (/lib/modules/2.6.18-4-486/kernel/drivers/acpi/fan.ko): No such device FATAL: Error inserting thermal (/lib/modules/2.6.18-4-486/kernel/drivers/acpi/thermal.ko): No such device BusyBox v1.1.3 (Debian 1:1.1.3-4) Built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) I use "-serial stdio" and "boot: live console=ttyS0,115200" so that I have output I can cut/paste into the email. I get the same problem if I boot it without any options. those 2 FATAL errors are fairly common, and are probably not the reason it is dropping to the prompt. vmware-player runs wc-2.4.iso ok and I just put wc-2.4.img on a usbstick and a real machine booted just fine. So the qemu problem isn't stopping anything real. It just seems like something that should be looked into. It could be a problem with qemu. Carl K
Re: [Qemu-devel] Re: livecd
Carl Karsten wrote: Now for a bug report: [EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio whoops - [EMAIL PROTECTED]:~/qemu$ qemu | grep -i version QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard I think I am running: qemu-snapshot-2007-04-06_05.tar.bz2 wc-2.4.iso boots just fine on 0.8.2 I'll try again with the current one. I have 2 suggestions: 1. print the version/build number when running a VM 2. add a separator between qemu's output and the -serial stdio output. (is there a better place to make suggestions?) Carl K
Re: [Qemu-devel] Re: livecd
Carl Karsten wrote: Carl Karsten wrote: Now for a bug report: [EMAIL PROTECTED]:~/qemu$ qemu -cdrom wc-2.4.iso -boot c -m 196 -serial stdio I'll try again with the current one. just built/installed qemu-snapshot-2007-04-16_05 [EMAIL PROTECTED]:~/qemu$ ls -l $(which qemu) -rwxr-xr-x 1 root root 995012 2007-04-16 12:19 /usr/local/bin/qemu [EMAIL PROTECTED]:~/qemu$ qemu | grep version QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard still bombs. Kai Hendry wrote: > I've also had a friend test > webconverger successfully on qemu 0.9. What build of webconverger and qemu? Carl K
[PATCH] target/sparc: emulate floating point queue when raising fp traps
From 310902d2ccd88ccb8de971d0d7ede0dbc93939f4 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Sat, 10 Aug 2024 15:09:39 -0700
Subject: [PATCH] target/sparc: emulate floating point queue when raising
fp traps
Sparc 32-bit machines perform floating point operations in an
asynchronous co-processor. When a FP operation traps for any reason
the entire set of pending operations is dumped to memory as
the "floating point queue" and then processed by kernel trap
handling. SunOS and at least early Solaris 2 releases only
handle traps correctly if they can find the faulting operation
at the head of the floating point queue. Qemu did not previously
implement FP queue handling. This commit adds: additional fields
to the processor state to contain a single-element FP queue;
logic in trap handling to populate the FP queue when a FP
trap occurs; and implementation of the STDFQ instruction that
the kernel uses to extract a FP queue element from the processor
state to memory.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2340
Signed-off-by: Carl Hauser
---
IEEE trap changes have been tested with Solaris 2.5.6,
linux kernel 2.6.18 (debian 4), and NetBSD 10.
For IEEE traps the behaviors change as follows:
Solaris -- occurence of a FP trap no longer hangs the user program.
The trap is reported as occurring at the instruction after the
instruction that caused the fault. This probably is the case for SunOS
4.1.4 as well.
For linux -- occurence of a FP did not
previously hang the user program. However the trap was previously
reported as occurring AT the instruction that caused the fault and
now is reported at the next instruction.
For NetBSD -- previously, trap did not hang but was reported as
occurring on the FP instruction. The trap is now reported as
occurring at the instruction after the instruction that caused the fault.
For unimplemented FP operation traps:
For Solaris 2.5.6 -- occurence of a FP trap no longer hangs the user
program.
The instruction is emulated by kernel and control returns to the user
program.
I am unable to test the linux and NetBSD behavior because I've been
unable to get gcc to actually generate quad precision instructions on those
systems.
My main concern as a newbie patch submitter is that I may have broken
something for SPARC64. I couldn't figure out the correct changes
for insns.decode, but reordering the two lines allowed the patch
to work for 32-bit sparc, but it may have broken sparc64, which I
have no way to test.
target/sparc/cpu.h | 8
target/sparc/fop_helper.c | 17 -
target/sparc/helper.h | 4
target/sparc/insns.decode | 5 +++--
target/sparc/int32_helper.c | 15 +++
target/sparc/translate.c| 20 +---
6 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index dfd9512a21..ff48279a55 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -184,6 +184,8 @@ enum {
#define FSR_FTT_SEQ_ERROR (4ULL << 14)
#define FSR_FTT_INVAL_FPR (6ULL << 14)
+#define FSR_QNE(1ULL << 13)
+
#define FSR_FCC0_SHIFT10
#define FSR_FCC1_SHIFT32
#define FSR_FCC2_SHIFT34
@@ -436,6 +438,12 @@ struct CPUArchState {
/* FPU State Register, in parts */
uint32_t fsr;/* rm, tem, aexc */
uint32_t fsr_cexc_ftt; /* cexc, ftt */
+
+/* single-element FPU fault queue */
+uint32_t fsr_qne;/* qne */
+uint32_t fsr_qi; /* faulting fp instruction */
+target_ulong fsr_qa; /* address of faulting instruction */
+
uint32_t fcc[TARGET_FCCREGS];/* fcc* */
CPU_DoubleU fpr[TARGET_DPREGS]; /* floating point registers */
diff --git a/target/sparc/fop_helper.c b/target/sparc/fop_helper.c
index 0b30665b51..0f74ca7908 100644
--- a/target/sparc/fop_helper.c
+++ b/target/sparc/fop_helper.c
@@ -21,6 +21,7 @@
#include "cpu.h"
#include "exec/exec-all.h"
#include "exec/helper-proto.h"
+#include "exec/cpu_ldst.h"
#include "fpu/softfloat.h"
static inline float128 f128_in(Int128 i)
@@ -538,7 +539,7 @@ uint32_t helper_flcmpd(float64 src1, float64 src2)
target_ulong cpu_get_fsr(CPUSPARCState *env)
{
-target_ulong fsr = env->fsr | env->fsr_cexc_ftt;
+target_ulong fsr = env->fsr | env->fsr_cexc_ftt | env->fsr_qne;
fsr |= env->fcc[0] << FSR_FCC0_SHIFT;
#ifdef TARGET_SPARC64
@@ -563,6 +564,7 @@ static void set_fsr_nonsplit(CPUSPARCState *env,
target_ulong fsr)
int rnd_mode;
env->fsr = fsr & (FSR_RD_MASK | FSR_TEM_MASK | FSR_AEXC_MASK);
+env->fsr_qne = fsr & FSR_QNE;
switch (fsr & FSR_RD_MASK) {
case FSR_RD_NEAREST:
@@ -608,3 +610,16 @@ void helper_set_fsr_nofcc(CPUSPARCState *env,
uint32_t fsr)
env->fsr_cexc_ftt = fsr & (FSR_CEXC_MASK | FSR_FTT_MASK);
set_fsr_
[PATCH v2] target/sparc: emulate floating point queue when raising fp traps
From 9265233081fae546c0459792598a9f1688ddb020 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Sat, 10 Aug 2024 15:09:39 -0700
Subject: [PATCH v2] target/sparc: emulate floating point queue when
raising fp
traps
Sparc 32-bit machines perform floating point operations in an
asynchronous co-processor. When a FP operation traps for any reason
the entire set of pending operations is dumped to memory as
the "floating point queue" and then processed by kernel trap
handling. SunOS and at least early Solaris 2 releases only
handle traps correctly if they can find the faulting operation
at the head of the floating point queue. Qemu did not previously
implement FP queue handling. This commit adds: additional fields
to the processor state to contain a single-element FP queue;
logic in trap handling to populate the FP queue when a FP
trap occurs; and implementation of the STDFQ instruction that
the kernel uses to extract a FP queue element from the processor
state to memory.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2340
Signed-off-by: Carl Hauser
---
Addressed comments about unrelated blank line insertions, and
unneeded #ifdefs. Put lines in insns.c back to original order,
but now with comments and arg specifier for STDFQ.
As for testing unimplemented operations on linux and NetBSD,
my problem is that I can't get gcc to generate quad-precision
code on them at all. Both gcc's generate the same code for long double
that they generate for double. And neither accepts _Float_128 as
a valid type. While I have reasonable confidence that the
implementation of unimplemented operations will work in the
qemu, I don't know if these kernels actually have the necessary
code to emulate the instructions. Of course, if the compilers
have never generated the instructions it's unlikely that there
are any programs out there using them.
target/sparc/cpu.h | 8
target/sparc/fop_helper.c | 17 -
target/sparc/helper.h | 4
target/sparc/insns.decode | 4 ++--
target/sparc/int32_helper.c | 13 +
target/sparc/translate.c| 14 ++
6 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index dfd9512a21..ff48279a55 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -184,6 +184,8 @@ enum {
#define FSR_FTT_SEQ_ERROR (4ULL << 14)
#define FSR_FTT_INVAL_FPR (6ULL << 14)
+#define FSR_QNE(1ULL << 13)
+
#define FSR_FCC0_SHIFT10
#define FSR_FCC1_SHIFT32
#define FSR_FCC2_SHIFT34
@@ -436,6 +438,12 @@ struct CPUArchState {
/* FPU State Register, in parts */
uint32_t fsr;/* rm, tem, aexc */
uint32_t fsr_cexc_ftt; /* cexc, ftt */
+
+/* single-element FPU fault queue */
+uint32_t fsr_qne;/* qne */
+uint32_t fsr_qi; /* faulting fp instruction */
+target_ulong fsr_qa; /* address of faulting instruction */
+
uint32_t fcc[TARGET_FCCREGS];/* fcc* */
CPU_DoubleU fpr[TARGET_DPREGS]; /* floating point registers */
diff --git a/target/sparc/fop_helper.c b/target/sparc/fop_helper.c
index 0b30665b51..0f74ca7908 100644
--- a/target/sparc/fop_helper.c
+++ b/target/sparc/fop_helper.c
@@ -21,6 +21,7 @@
#include "cpu.h"
#include "exec/exec-all.h"
#include "exec/helper-proto.h"
+#include "exec/cpu_ldst.h"
#include "fpu/softfloat.h"
static inline float128 f128_in(Int128 i)
@@ -538,7 +539,7 @@ uint32_t helper_flcmpd(float64 src1, float64 src2)
target_ulong cpu_get_fsr(CPUSPARCState *env)
{
-target_ulong fsr = env->fsr | env->fsr_cexc_ftt;
+target_ulong fsr = env->fsr | env->fsr_cexc_ftt | env->fsr_qne;
fsr |= env->fcc[0] << FSR_FCC0_SHIFT;
#ifdef TARGET_SPARC64
@@ -563,6 +564,7 @@ static void set_fsr_nonsplit(CPUSPARCState *env,
target_ulong fsr)
int rnd_mode;
env->fsr = fsr & (FSR_RD_MASK | FSR_TEM_MASK | FSR_AEXC_MASK);
+env->fsr_qne = fsr & FSR_QNE;
switch (fsr & FSR_RD_MASK) {
case FSR_RD_NEAREST:
@@ -608,3 +610,16 @@ void helper_set_fsr_nofcc(CPUSPARCState *env,
uint32_t fsr)
env->fsr_cexc_ftt = fsr & (FSR_CEXC_MASK | FSR_FTT_MASK);
set_fsr_nonsplit(env, fsr);
}
+
+#ifndef TARGET_SPARC64
+void helper_store_fp_queue(CPUSPARCState *env, uint32_t addr)
+{
+if (!env->fsr_qne) {
+env->fsr_cexc_ftt = FSR_FTT_SEQ_ERROR;
+cpu_raise_exception_ra(env, TT_FP_EXCP, GETPC());
+}
+cpu_stl_be_data(env, addr, env->fsr_qa);
+cpu_stl_be_data(env, addr + 4, env->fsr_qi);
+env->fsr_qne = 0;
+}
+#endif
diff --git a/target/sparc/helper.h b/target/sparc/helper.h
index 134e519a37..15ae94d0f3 100644
--- a/target/sparc/helper.h
+++ b/target/sparc/helper.h
@@ -85,6 +85,10 @@ DEF_HELPER_FLAGS_2(fitoq, TCG_CALL_NO_WG, i128, env, s32)
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps
OK, I think the problem is the handling of dc->fsr_qne in
trans_STDFQ, lines 4583 and 4593 -- the code is evaluating
dc->fsr_qne at translation time and not at runtime.
On 8/16/24 14:19, Carl Hauser wrote:
Hi Richard,
I applied the 6 patches and then ran a divide-by-zero test on
the Solaris image. The result was a crash
(qemu) qemu:
fatal: Trap 0x08 (FPU Exception) while interrupts disabled,
Error state
pc: f0066d80 npc: f0066d84
%g0-7: 01086002 2000 fc067b80
0001 f638b180
%o0-7: f025ef5c f6376648
fc067b80 f004149c
%l0-7: 04401087 00010a10 00010a14 fc067b80 fc067f70 0080
0001 fc067b80
%i0-7: 0108 0008 0002 0f80 ef718cb0
e510 000109ec
%f00:
%f08: 4040
%f16:
%f24:
psr: 04001087 (icc: SPE: S--) wim: 0002
fsr: 0109 y:
I've
seen that PC address before -- I'm pretty sure it is the STDFQ
instruction in the kernel trap handler, and if I'm reading the
fsr correctly that is confirmed by the fact that it is
sequence-error type FPE which only occurs for STDFQ. Without a
bit of further poking around with the debugger I don't know
what's happening beyond that. I will keep looking but thought
I'd provide immediate results in case this rings a bell for
you.
If
it would be helpful, I could share a disk image with Solaris,
gnu tools, the test examples, etc. It's under 500MB compressed
and I think I have enough google drive space to accommodate
that at the moment.
--
Carl
On 8/16/24 00:23, Richard Henderson
wrote:
Hi Carl,
While digging through the manual to figure out if we were really
doing the right thing raising the fp exception, I found the fpu
exception state machine. I'm not sure it's worth emulating the
fp_exception_pending state, but it's certainly easy enough to
emulate the fp_executing/fp_exception states.
In addition, this simplifies the implementation of STDFQ,
restricts FQ to sparc32 system mode, and handles migration.
Would you please double-check this against your Solaris images?
r~
Carl Hauser (2):
target/sparc: Add FQ and FSR.QNE
target/sparc: Populate sparc32 FQ when raising fp exception
Richard Henderson (4):
target/sparc: Restrict STQF to sparcv9
target/sparc: Add FSR_QNE to tb_flags
target/sparc: Implement STDFQ
target/sparc: Add gen_trap_if_nofpu_fpexception
target/sparc/cpu.h | 30 -
target/sparc/fop_helper.c | 4 ++
target/sparc/int32_helper.c | 32 -
target/sparc/machine.c | 25 +++
target/sparc/translate.c| 126 ++--
target/sparc/insns.decode | 4 +-
6 files changed, 169 insertions(+), 52 deletions(-)
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps
Hi Richard,
I applied the 6 patches and then ran a divide-by-zero test on the
Solaris image. The result was a crash
(qemu) qemu:
fatal: Trap 0x08 (FPU Exception) while interrupts disabled,
Error state
pc: f0066d80 npc: f0066d84
%g0-7: 01086002 2000 fc067b80
0001 f638b180
%o0-7: f025ef5c f6376648
fc067b80 f004149c
%l0-7: 04401087 00010a10 00010a14 fc067b80 fc067f70 0080
0001 fc067b80
%i0-7: 0108 0008 0002 0f80 ef718cb0
e510 000109ec
%f00:
%f08: 4040
%f16:
%f24:
psr: 04001087 (icc: SPE: S--) wim: 0002
fsr: 0109 y:
I've
seen that PC address before -- I'm pretty sure it is the STDFQ
instruction in the kernel trap handler, and if I'm reading the
fsr correctly that is confirmed by the fact that it is
sequence-error type FPE which only occurs for STDFQ. Without a
bit of further poking around with the debugger I don't know
what's happening beyond that. I will keep looking but thought
I'd provide immediate results in case this rings a bell for you.
If
it would be helpful, I could share a disk image with Solaris,
gnu tools, the test examples, etc. It's under 500MB compressed
and I think I have enough google drive space to accommodate that
at the moment.
--
Carl
On 8/16/24 00:23, Richard Henderson
wrote:
Hi Carl,
While digging through the manual to figure out if we were really
doing the right thing raising the fp exception, I found the fpu
exception state machine. I'm not sure it's worth emulating the
fp_exception_pending state, but it's certainly easy enough to
emulate the fp_executing/fp_exception states.
In addition, this simplifies the implementation of STDFQ,
restricts FQ to sparc32 system mode, and handles migration.
Would you please double-check this against your Solaris images?
r~
Carl Hauser (2):
target/sparc: Add FQ and FSR.QNE
target/sparc: Populate sparc32 FQ when raising fp exception
Richard Henderson (4):
target/sparc: Restrict STQF to sparcv9
target/sparc: Add FSR_QNE to tb_flags
target/sparc: Implement STDFQ
target/sparc: Add gen_trap_if_nofpu_fpexception
target/sparc/cpu.h | 30 -
target/sparc/fop_helper.c | 4 ++
target/sparc/int32_helper.c | 32 -
target/sparc/machine.c | 25 +++
target/sparc/translate.c| 126 ++--
target/sparc/insns.decode | 4 +-
6 files changed, 169 insertions(+), 52 deletions(-)
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps
Yes, but ... isn't the state of dc->fsr_qne at translation time irrelevant? And changing it at translation time (line 4593) is dangerous (because it pertains to runtime, not translation time); i.e. why is 0 stored at both translation time (4593) and at runtime (4591)? I think that the if on line 4583 needs to be a run-time test. But I get very tangled up in these distinctions. For me, generating a call to a helper function instead of trying to generate all the correct logic made it easier to keep straight what was happening. On 8/16/24 15:05, Richard Henderson wrote: On 8/17/24 07:46, Carl Hauser wrote: OK, I think the problem is the handling of dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code is evaluating dc->fsr_qne at translation time and not at runtime. That's what patch 4 does, ensure that the runtime value is available at translation time. r~
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps
Further info:
netbsd panics in the kernel trap handler; unfortunately it does
not include the fsr in the panic message, but I expect it will be
the same as on Solaris.
linux raises SIGFPE in the application that caused the exception.
Not surprising since we've seen before that linux is blissfully
unaware of the floating point queue.
-- Carl
On 8/16/24 15:05, Richard Henderson
wrote:
On
8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of
dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code
is evaluating dc->fsr_qne at translation time and not at
runtime.
That's what patch 4 does, ensure that the runtime value is
available at translation time.
r~
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps
I changed target.c:4597 from return true; to return advance_pc(dc); and it worked. On 8/16/24 17:16, Richard Henderson wrote: On 8/17/24 09:48, Carl Hauser wrote: netbsd panics in the kernel trap handler; unfortunately it does not include the fsr in the panic message, but I expect it will be the same as on Solaris. Ok, I have reproduced this with netbsd 9.3. I'll have a look. r~
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps -- CORRECTION
I changed translate.c:4597 from return true; to return advance_pc(dc); and it worked. On 8/16/24 17:16, Richard Henderson wrote: On 8/17/24 09:48, Carl Hauser wrote: netbsd panics in the kernel trap handler; unfortunately it does not include the fsr in the panic message, but I expect it will be the same as on Solaris. Ok, I have reproduced this with netbsd 9.3. I'll have a look. r~
[PATCH] hw/char: suppress sunmouse events with no changes
From f155cbd57b37fa600c580ed30d593f47383ecd38 Mon Sep 17 00:00:00 2001
From: Carl Hauser
Date: Fri, 16 Aug 2024 09:20:36 -0700
Subject: [PATCH] hw/char: suppress sunmouse events with no changes
Sun optical mice circa 1993 were based on the Mouse Systems
Corp. optical mice. The technical manual for those mice
states that mice only send events when there is motion or the
button state changes. The Solaris 2.5.6 mouse driver seems
to be confused by updates that don't follow this specification.
This patch adds a field to the ESCCChannelState to contain
the button state sent in the last event and uses that in
sunmouse_event to avoid sending unnecessary updates.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2518
Signed-off-by: Carl Hauser
---
hw/char/escc.c | 10 ++
include/hw/char/escc.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/hw/char/escc.c b/hw/char/escc.c
index d450d70eda..7732141cf5 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -287,6 +287,7 @@ static void escc_reset_chn(ESCCChannelState *s)
s->rxint = s->txint = 0;
s->rxint_under_svc = s->txint_under_svc = 0;
s->e0_mode = s->led_mode = s->caps_lock_mode = s->num_lock_mode = 0;
+s->sunmouse_prev_state = 0;
clear_queue(s);
}
@@ -959,6 +960,15 @@ static void sunmouse_event(void *opaque,
int ch;
trace_escc_sunmouse_event(dx, dy, buttons_state);
+
+/* Don't send duplicate events without motion */
+if (dx == 0 &&
+dy == 0 &&
+(s->sunmouse_prev_state ^ buttons_state) == 0) {
+return;
+}
+s->sunmouse_prev_state = buttons_state;
+
ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
if (buttons_state & MOUSE_EVENT_LBUTTON) {
diff --git a/include/hw/char/escc.h b/include/hw/char/escc.h
index 5669a5b811..bc5ba4f564 100644
--- a/include/hw/char/escc.h
+++ b/include/hw/char/escc.h
@@ -46,6 +46,7 @@ typedef struct ESCCChannelState {
uint8_t rx, tx;
QemuInputHandlerState *hs;
char *sunkbd_layout;
+int sunmouse_prev_state;
} ESCCChannelState;
struct ESCCState {
--
2.34.1
Re: [PATCH] hw/char: suppress sunmouse events with no changes
Yes, just equality, no masking needed. Boneheaded.
I think I could figure out how to do the state migration if
that's the direction you want to go.
I don't think I could do the migration to
qemu_input_handler_register, especially as I would think that the
keyboard should be done at the same time.
I'll wait on a V2 patch with the equality fix for a decision
about migration/vs new style.
-- Carl
On 8/20/24 00:34, Richard Henderson
wrote:
On
8/20/24 09:18, Carl Hauser wrote:
@@ -959,6 +960,15 @@ static void
sunmouse_event(void *opaque,
int ch;
trace_escc_sunmouse_event(dx, dy, buttons_state);
+
+ /* Don't send duplicate events without motion */
+ if (dx == 0 &&
+ dy == 0 &&
+ (s->sunmouse_prev_state ^ buttons_state) == 0) {
Were you intending to mask vs MOUSE_EVENT_*BUTTON?
Otherwise this is just plain equality.
diff --git a/include/hw/char/escc.h
b/include/hw/char/escc.h
index 5669a5b811..bc5ba4f564 100644
--- a/include/hw/char/escc.h
+++ b/include/hw/char/escc.h
@@ -46,6 +46,7 @@ typedef struct ESCCChannelState {
uint8_t rx, tx;
QemuInputHandlerState *hs;
char *sunkbd_layout;
+ int sunmouse_prev_state;
This adds new state that must be migrated.
While the patch is relatively simple, I do wonder if this code
could be improved by converting away from the legacy mouse
interface to qemu_input_handler_register. Especially if that might
help avoid needing to add migration state that isn't "really" part
of the device.
Mark?
r~
Re: [PATCH for-9.2 v3 0/6] target/sparc: emulate floating point queue when raising fp traps -- CORRECTION
Do you want me to submit a patch set fixing this or will you? -- Carl On 8/18/24 19:42, Richard Henderson wrote: On 8/18/24 10:03, Carl Hauser wrote: I changed translate.c:4597 from return true; to return advance_pc(dc); and it worked. Whoops, yes indeed. Thanks for the catch. r~
Re: [PATCH v4 0/5] target/sparc: emulate floating point queue when raising fp traps
On 9/9/24 11:07, Richard Henderson wrote: Changes for v5: - Fix stdfq advance_pc. r~ Carl Hauser (2): target/sparc: Add FQ and FSR.QNE target/sparc: Populate sparc32 FQ when raising fp exception Richard Henderson (3): target/sparc: Add FSR_QNE to tb_flags target/sparc: Implement STDFQ target/sparc: Add gen_trap_if_nofpu_fpexception target/sparc/cpu.h | 30 - target/sparc/fop_helper.c | 4 ++ target/sparc/int32_helper.c | 40 ++- target/sparc/machine.c | 25 +++ target/sparc/translate.c| 128 ++-- target/sparc/insns.decode | 2 +- 6 files changed, 178 insertions(+), 51 deletions(-) I did very basic tests that IEEE exceptions are raised successfully and the quad precision instructions are emulated. Tested-by: Carl Hauser
[Qemu-devel] boot order=d bug?
In the real world I will have a machine with a sata hd and boot the installer from a usb stick. I want to test this with 2 disk image files. The usb stick will be built like so: https://github.com/CarlFK/video-stack-deploy/blob/usbstick/scripts/mk_usb_installer.sh but this will demo the problem I have run into with qemu: how do I boot from boot.img without using boot=menu? # make a blank disk to install to qemu-img create -f qcow2 disk.cow 8G # get an installer image wget http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/hd-media/boot.img.gz gunzip boot.img.gz qemu-system-x86_64 -m 256 -display curses \ -drive file=disk.cow,index=0 \ -drive file=boot.img,index=1 \ -boot menu=on # Hit esc and then #2 to boot the installer. Press ESC for boot menu. Select boot device: 1. ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes) 2. ata0-1: QEMU HARDDISK ATA-7 Hard-Disk (953 MiBytes) 3. Legacy option rom 4. Floppy [drive A] 5. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] 6. iPXE (PCI 00:03.0) juser@gator:~/temp/video-stack-deploy/scripts$ qemu-system-x86_64 -version QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-4+b1) Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers -- Carl K
Re: [Qemu-devel] boot order=d bug?
neat. missed that. except it doesn't work. juser@gator:~/temp$ qemu-system-x86_64 -drive file=boot.img,format=raw,bootindex=1 qemu-system-x86_64: -drive file=boot.img,format=raw,bootindex=1: Block format 'raw' does not support the option 'bootindex' juser@gator:~/temp$ qemu-system-x86_64 -drive file=boot.img,bootindex=1WARNING: Image format was not specified for 'boot.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. qemu-system-x86_64: -drive file=boot.img,bootindex=1: Block format 'raw' does not support the option 'bootindex' Is there a "yes you do --force" option ? On Sun, May 7, 2017 at 9:02 PM, Thomas Huth wrote: > On 07.05.2017 07:42, Carl Karsten wrote: > > In the real world I will have a machine with a sata hd and boot the > > installer from a usb stick. I want to test this with 2 disk image files. > > > > The usb stick will be built like so: > > https://github.com/CarlFK/video-stack-deploy/blob/ > usbstick/scripts/mk_usb_installer.sh > > > > but this will demo the problem I have run into with qemu: how do I boot > > from boot.img without using boot=menu? > > Have you already tried to use the bootindex property? See: > > http://git.qemu.org/?p=qemu.git;a=blob;f=docs/bootindex.txt > > Thomas > > -- Carl K
[Qemu-devel] format=raw,readonly errors
juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive file=disk.cow -drive file=boot.img WARNING: Image format was not specified for 'boot.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. This is OK, as I don't want anything writing to that thing anyway. So to get rid of the waring: juser@gator:~/temp$ qemu-system-x86_64 -drive file=boot.img,format=raw,readonly qemu-system-x86_64: Can't use a read-only drive qemu-system-x86_64: Initialization of device ide-hd failed: Device initialization failed. hmm... one more try: juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive file=disk.cow,readonly qemu-system-x86_64: Can't use a read-only drive qemu-system-x86_64: Initialization of device ide-hd failed: Device initialization failed. -- Carl K
Re: [Qemu-devel] format=raw,readonly errors
On Mon, May 8, 2017 at 3:51 AM, Markus Armbruster wrote: > Carl Karsten writes: > > > juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive > > file=disk.cow -drive file=boot.img > > WARNING: Image format was not specified for 'boot.img' and probing > guessed > > raw. > > Automatically detecting the format is dangerous for raw images, > > write operations on block 0 will be restricted. > > Specify the 'raw' format explicitly to remove the restrictions. > > > > This is OK, as I don't want anything writing to that thing anyway. So to > > get rid of the waring: > > > > juser@gator:~/temp$ qemu-system-x86_64 -drive > > file=boot.img,format=raw,readonly qemu-system-x86_64: Can't use a > read-only > > drive > > qemu-system-x86_64: Initialization of device ide-hd failed: Device > > initialization failed. > > -drive without if=... creates an IDE disk[*]. IDE disks can't do > read-only. Have you tried omitting ",readonly"? > omitting works, but my goal was for the drive to be read only. > > > hmm... one more try: > > > > juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive > > file=disk.cow,readonly > > qemu-system-x86_64: Can't use a read-only drive > > qemu-system-x86_64: Initialization of device ide-hd failed: Device > > initialization failed. > > > [*] It actually depends on the machine, but I figure that's of no > interest to you. > -- Carl K
Re: [Qemu-devel] boot order=d bug?
On Mon, May 8, 2017 at 2:57 AM, Thomas Huth wrote: > On 08.05.2017 06:22, Carl Karsten wrote: > > neat. missed that. > > > > except it doesn't work. > > > > juser@gator:~/temp$ qemu-system-x86_64 -drive > > file=boot.img,format=raw,bootindex=1 > > qemu-system-x86_64: -drive file=boot.img,format=raw,bootindex=1: Block > > format 'raw' does not support the option 'bootindex' > > bootindex is a property of the "-device" parameter, not of "-drive", so > you've got to specify both parameters here (with "if=none" for -drive). > See bootindex.txt for details. > got it. Thank you and IRC folks for this: qemu-system-x86_64 -m 256 \ -drive file=disk.cow,index=0 \ -drive file=/dev/sdb,index=1,format=raw,if=none,id=thumb \ -device ide-hd,drive=thumb,bootindex=1 > > Thomas > > > On Sun, May 7, 2017 at 9:02 PM, Thomas Huth wrote: > > > >> On 07.05.2017 07:42, Carl Karsten wrote: > >>> In the real world I will have a machine with a sata hd and boot the > >>> installer from a usb stick. I want to test this with 2 disk image > files. > >>> > >>> The usb stick will be built like so: > >>> https://github.com/CarlFK/video-stack-deploy/blob/ > >> usbstick/scripts/mk_usb_installer.sh > >>> > >>> but this will demo the problem I have run into with qemu: how do I > boot > >>> from boot.img without using boot=menu? > >> > >> Have you already tried to use the bootindex property? See: > >> > >> http://git.qemu.org/?p=qemu.git;a=blob;f=docs/bootindex.txt > >> > >> Thomas > >> > >> > > > > > > -- Carl K
Re: [Qemu-devel] format=raw,readonly errors
On Mon, May 8, 2017 at 10:32 AM, John Snow wrote: > > > On 05/08/2017 10:15 AM, Carl Karsten wrote: > > On Mon, May 8, 2017 at 3:51 AM, Markus Armbruster > wrote: > > > >> Carl Karsten writes: > >> > >>> juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses -drive > >>> file=disk.cow -drive file=boot.img > >>> WARNING: Image format was not specified for 'boot.img' and probing > >> guessed > >>> raw. > >>> Automatically detecting the format is dangerous for raw > images, > >>> write operations on block 0 will be restricted. > >>> Specify the 'raw' format explicitly to remove the > restrictions. > >>> > >>> This is OK, as I don't want anything writing to that thing anyway. So > to > >>> get rid of the waring: > >>> > >>> juser@gator:~/temp$ qemu-system-x86_64 -drive > >>> file=boot.img,format=raw,readonly qemu-system-x86_64: Can't use a > >> read-only > >>> drive > >>> qemu-system-x86_64: Initialization of device ide-hd failed: Device > >>> initialization failed. > >> > >> -drive without if=... creates an IDE disk[*]. IDE disks can't do > >> read-only. Have you tried omitting ",readonly"? > >> > > > > > > omitting works, but my goal was for the drive to be read only. > > > > > > I don't think there's a way to make physical IDE drives "read only." I > don't think there's any jumper settings or any of the like which can > accomplish this. > > Unlike floppy disks (which you could notch the corner of) or SD cards > (which have the write lock), I don't think ATA disks have a method for > being "read only," so this isn't a feature QEMU can support. > > What you CAN do, however, is to use -snapshot or otherwise use something > like a qcow2 overlay to trap all writes to a temporary file that you can > discard at a later point in time, effectively keeping your original > image "read only." > > I believe that SCSI disks support a read-only mode, though. > k - that all makes sense. kinda ;) "write operations on block 0 will be restricted." Is there a way to explicitly enable that? The installer on the usb stick keeps stepping on itself rendering it broken, both physical usb drive and a dd image. I can play with OS permissions too, but that restricted warning made me think that would be 'best'. but but, now that I have index/bootindex working I probably won't be trashing my installer any more, so non-issue. -- Carl K
Re: [Qemu-devel] format=raw,readonly errors
On Mon, May 8, 2017 at 11:29 AM, Eric Blake wrote: > On 05/08/2017 10:56 AM, Carl Karsten wrote: > > >>>>> juser@gator:~/temp$ qemu-system-x86_64 -m 256 -display curses > -drive > >>>>> file=disk.cow -drive file=boot.img > >>>>> WARNING: Image format was not specified for 'boot.img' and probing > >>>> guessed > >>>>> raw. > >>>>> Automatically detecting the format is dangerous for raw > >> images, > >>>>> write operations on block 0 will be restricted. > >>>>> Specify the 'raw' format explicitly to remove the > >> restrictions. > > > "write operations on block 0 will be restricted." > > > > Is there a way to explicitly enable that? > > Yes. Pass format=raw at the right place (in other words, instead of > getting the 'raw' format driver by default, explicitly mentioning that > you KNOW you want the 'raw' format driver is enough to shut up the > warning). > according to the warning: "Specify the 'raw' format explicitly to remove the restrictions." I want the restriction. format=raw, (write operations on block 0)=restricted > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > > -- Carl K
[Qemu-devel] [Bug 1612908] [NEW] qom-[list, tree, get, set] don't accept tcp endpoint arg
Public bug reported: Hi, I'm using origin/master [60ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. I have a patch to fix this issue that I can submit to the developer list. ** Affects: qemu Importance: Undecided Status: New ** Tags: python qom qom-list qom-tree scripts -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1612908 Title: qom-[list,tree,get,set] don't accept tcp endpoint arg Status in QEMU: New Bug description: Hi, I'm using origin/master [60ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. I have a patch to fix this issue that I can submit to the developer list. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1612908/+subscriptions
[Qemu-devel] ARM MCU Target Structure Question
Hello All, I'm working on a new microcontroller target (Atmel ATSAM4E) for the qemu-system-arm executable. I've successfully setup a machine and created some peripherals. I have some questions about how to structure the files for contributing this target to the qemu project. In the current "hw" directory, there seems to be a mashup of MCU/board machines, peripherals for these machines, and devices that would communicate with these peripherals like I2C or SPI slave devices. There are also general definitions for buses like I2C and SPI. There seem to be peripherals for certain machines spread over several different directories. For example, the omap*.c files are defined in the "arm" sub directory, and then several of the peripherals are defined in the ssi/i2c/gpio/etc directories. This seems inefficient from a development perspective because the omap i2c/ssi/gpio peripherals are unlikely to be reused by other MCUs or targets (except by derivatives in the OMAP family perhaps). My preferred way to contribute to the project would be to create a new set of directories in "hw/arm" that would have the following hierarchy: hw/arm/atmel/ - utils/ - atsam4/ - common/<-- Common Peripherals in family - atsam4e/ <-- Machine and Peripheral Definitions - atsam4n/ ... - atsam3/<-- Other families in the future? Similarly, I would create an "include" structure for headers: include/hw/arm/atmel/ - utils/ - atsam4/ - common/ - atsam4e/ - atsam4n/ ... - atsam3/ Is this reasonable and acceptable? I think refactoring the code in "hw" directory to organize machine targets using similar logic for SOCs and moving slave device targets into a separate subdirectory would be useful. I'm new to this project so perhaps I'm missing something. I hope this does not come across as stepping on anyones toes; that was not my intent. Thanks in advanced for any comments or advice.
Re: [Qemu-devel] ARM MCU Target Structure Question
On Mon, Aug 15, 2016 at 3:18 AM, Peter Maydell wrote: > This broadly matches the directory arrangement principles used > by the Linux kernel sources, which is where we've borrowed it from. > Ok - I'll pursue the current directory structure. Thanks, ~C
[Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
** Attachment added: "Used with other VNC servers.jpg" https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982277/+files/Used%20with%20other%20VNC%20servers.jpg ** Description changed: Description of problem - In my latest topic, I reported a bug relate to QEMU's websocket: https://bugs.launchpad.net/qemu/+bug/1718964 It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. So I did a test and found that there indeed existed some problems. The problem is: When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. Environment - All of the following versions have been tested: QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance (No need websocket option): qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 2. Launch websockify on a separate host and connect to QEMU's VNC port 3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify 4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) 5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) 6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move 7. Monitor network traffic on the proxy server Current result: - Monitor Downlink/Uplink network traffic on the proxy server (Refer to the attachments for more details). 1. Used with QEMU - D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) - D: 4.3 MB/s U: 334 KB/s (Client on WAN) 2. Used with other VNC servers - D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) - D: 369 KB/s U: 328 KB/s (Client on WAN) - It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) - will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. + It is found that when the client's network is poor, all the VNC servers + (tigervnc/x11vnc/tightvnc) will reduce the VNC data send to websocket + proxy (uplink and downlink symmetry), but QEMU never drop any frames and + still sends a lot of data to websockify, the client has no capacity to + accept so much data, more and more data are accumulated in the + websockify, then it crashes. Expected results: - When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725707 Title: QEMU sends excess VNC data to websockify even when network is poor Status in QEMU: New Bug description: Description of problem - In my latest topic, I reported a bug relate to QEMU's websocket: https://bugs.launchpad.net/qemu/+bug/1718964 It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. So I did a test and found that there indeed existed some problems. The problem is: When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. Environment - All of the following versions have been tested: QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance (No need websocket option): qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 2. Launch websockify on a separate host and connect to QEMU's VNC port 3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify
[Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
** Attachment added: "Used with QEMU.jpg" https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982276/+files/Used%20with%20QEMU.jpg -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725707 Title: QEMU sends excess VNC data to websockify even when network is poor Status in QEMU: New Bug description: Description of problem - In my latest topic, I reported a bug relate to QEMU's websocket: https://bugs.launchpad.net/qemu/+bug/1718964 It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. So I did a test and found that there indeed existed some problems. The problem is: When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. Environment - All of the following versions have been tested: QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance (No need websocket option): qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 2. Launch websockify on a separate host and connect to QEMU's VNC port 3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify 4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) 5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) 6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move 7. Monitor network traffic on the proxy server Current result: - Monitor Downlink/Uplink network traffic on the proxy server (Refer to the attachments for more details). 1. Used with QEMU - D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) - D: 4.3 MB/s U: 334 KB/s (Client on WAN) 2. Used with other VNC servers - D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) - D: 369 KB/s U: 328 KB/s (Client on WAN) It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. Expected results: - When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
[Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor
Public bug reported: Description of problem - In my latest topic, I reported a bug relate to QEMU's websocket: https://bugs.launchpad.net/qemu/+bug/1718964 It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. So I did a test and found that there indeed existed some problems. The problem is: When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. Environment - All of the following versions have been tested: QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance (No need websocket option): qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 2. Launch websockify on a separate host and connect to QEMU's VNC port 3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify 4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) 5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) 6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move 7. Monitor network traffic on the proxy server Current result: - Monitor Downlink/Uplink network traffic on the proxy server (Refer to the attachments for more details). 1. Used with QEMU - D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) - D: 4.3 MB/s U: 334 KB/s (Client on WAN) 2. Used with other VNC servers - D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) - D: 369 KB/s U: 328 KB/s (Client on WAN) It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. Expected results: - When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Topology" https://bugs.launchpad.net/bugs/1725707/+attachment/4982275/+files/Topology.jpg -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725707 Title: QEMU sends excess VNC data to websockify even when network is poor Status in QEMU: New Bug description: Description of problem - In my latest topic, I reported a bug relate to QEMU's websocket: https://bugs.launchpad.net/qemu/+bug/1718964 It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. So I did a test and found that there indeed existed some problems. The problem is: When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. Environment - All of the following versions have been tested: QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance (No need websocket option): qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 2. Launch websockify on a separate host and connect to QEMU's VNC port 3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify 4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) 5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) 6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move 7. Monitor network traffic on the proxy server Current result: - Monitor Downlink/Uplink network traffic on the proxy server (Refer to the attachments for more details). 1. Used with Q
[Qemu-devel] [Bug 1718964] [NEW] Memory leak when using websocket over a low speed network
Public bug reported: Description of problem - When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). Environment - All of the following versions have been tested: QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS Client OS: Windows 7 64bit / Windows 10 64bit Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance with websocket option: qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket 3. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) 4. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) 5. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move 6. Observe QEMU process on the host, more and more data are accumulated in the process, the consumption of memory continues to keep increasing Current result: - [Top - Initial status] PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2725 root 20 0 7229144 5.910g 23024 S 16.3 18.9 0:12.84 qemu-system-x86_64 [Top - After an hour's playing w/o limit (6-8MB/S)] PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2725 root 20 0 7370284 6.046g 23132 S 28.0 19.3 35:58.15 qemu-system-x86_64 [Top - Limit the bandwidth and continue to playing for another an hour (300KB/S)] PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2725 root 20 0 11.029g 8.853g 23132 S 20.0 28.2 72:14.17 qemu-system-x86_64 Also test several other combinations in the same environment: 1. Client(VNC Viewer) - Server(QEMU) 2. Client(VNC Viewer) - Server(tigervnc/x11vnc/tightvnc) 3. Client(noVNC) - Server(tigervnc/x11vnc/tightvnc) Likewise, the client's inbound bandwidth is limited to 300KB/S, although a lot of frame are lost, all of they still works (at least the mouse is movable). It's found that when connect to QEMU via websocket, it never drop any frames. QEMU still sends a lot of data to its websocket even when the network is congested, the process is continually consuming more memory, then it gets stack. Expected results: - When the network is poor (non-LAN), QEMU would reduce the VNC data send to its websocket correspondingly, and the memory usage remains stable. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1718964 Title: Memory leak when using websocket over a low speed network Status in QEMU: New Bug description: Description of problem - When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). Environment - All of the following versions have been tested: QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS Client OS: Windows 7 64bit / Windows 10 64bit Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 Steps to reproduce: - 100% reproducible. 1. Launch a QEMU instance with websocket option: qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket 3. Play a video (e.g. Watc
Re: [Qemu-devel] RFC: emulation of system flash
Hi, as the lead developer of the open source flashrom utility <http://www.flashrom.org/> I have to say that it would be nice to have Qemu emulate a flash chip. Right now flashrom is using its own flash chip emulator for testing, and being able to use flashrom in Qemu would be a nice addition. Auf 10.03.2011 05:51, Jordan Justen schrieb: > I have documented a simple flash-like device which I think could be > useful for qemu/kvm in some cases. (Particularly for allowing > persistent UEFI non-volatile variables.) > > http://wiki.qemu.org/Features/System_Flash > > Let me know if you have any suggestions or concerns. > Is there any reason why you chose to invent an interface for the flash chip which is more complicated than the interface used by common flash chips out there? Maybe some EFI requirement? Regards, Carl-Daniel
Re: [Qemu-devel] Re: RFC: emulation of system flash
Auf 10.03.2011 12:48, Gleb Natapov schrieb: > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: > >> On 2011-03-10 10:47, Gleb Natapov wrote: >> >>> Second. I asked how flash is programmed because interfaces like CFI >>> where you write into flash memory address range to issue commands cannot >>> be emulated efficiently in KVM. KVM supports either regular memory slots >>> or IO memory, but in your proposal the same memory behaves as IO on >>> write and regular memory on read. Better idea would be to present >>> non-volatile flash as ISA virtio device. Should be simple to implement. >>> >> Why not enhancing KVM memory slots to support direct read access while >> writes are trapped and forwarded to a user space device model? >> > Yes we can make memory slot that will be treated as memory on read and > IO on write, but first relying on that will prevent using flash interface > on older kernels and second it is not enough to implement the proposal. > When magic value is written into an address, the address become IO for > reading too, but KVM slot granularity is page, not byte, so KVM will > have to remove the slot to make it IO, but KVM can't execute code from > IO region (yet), so we will not be able to run firmware from flash and > simultaneously write into the flash. > If you have a Parallel/LPC/FWH flash chip in your mainboard, it is technically impossible to execute code from flash while you are writing to _any_ part of the flash chip because every single read from the flash chip during an active write will toggle one bit of the read data. So if your code already runs on real x86, you will never hit that problem. (SPI flash is an exception, but it uses out-of-band access anyway, usually via some southbridge interface, and that means the IO vs. execution conflict won't happen there either.) Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] Re: RFC: emulation of system flash
Auf 10.03.2011 13:06, Jan Kiszka schrieb: > BTW, the programming granularity is not bytes but chips with common CFI. > But that's still tricky if you want to run code from the same chip while > updating parts of it. The easiest workaround would be handling the > overlay regions as ROM all the time. Not accurate but realizable without > kernel changes. > I've yet to see CFI chips on x86. >> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: >> >>> Virtio >>> means that you have to patch the guest (which might be something else >>> than flexible Linux...). >>> >>> >> This intended to be used by firmware only and we control that. >> > I'm thinking beyond this use case, beyond firmware flashes, beyond x86. > If you're thinking beyond x86, most flash is probably using SPI nowadays because the reduced PCB footprint can save lots of money. And for SPI you only need OOB access for write and the memory region itself is readonly. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] Re: RFC: emulation of system flash
Auf 10.03.2011 19:43, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote: > >> On 03/10/2011 06:51 AM, Jordan Justen wrote: >> >>> http://wiki.qemu.org/Features/System_Flash >>> >>> >> - make the programming interface the same as an existing device >> > How strongly do you feel about this? > > For one thing, real devices are not as flexible as QEMU for flash > sizes. QEMU allows for any 64kb multiple bios size. Real world > devices generally only support powers of 2 sizes. > > Firmware hub devices are somewhat simplistic to emulate, but I think > they use 16MB of address space, while only providing <= 1MB of flash > storage. > Up to 4 MB on real hardware, and if you use Parallel flash devices, there is no limit at all (except cost). The software interface is identical for read/write/erase/probe. > SPI devices are available in many sizes, so it might be possible to > choose a 16MB device to emulate. But, it would be a lot more complex > to emulate as it would it involve emulating an SPI contoller + the > device. > I have written a SPI flash chip emulator (it emulates 3 different real-world SPI flash chips) and am willing to contribute it to Qemu if there is interest. The code is pretty small, and adding a SPI host controller emulator should be a few lines of code extra. Not a big problem. > I thought this might be a case where deviation from real hardware > emulation could better serve the VM's needs. > If we have to write the code anyway, and if it can work just fine with current KVM/Qemu, is there a reason not to use the same interface as real hardware? Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] RFC: emulation of system flash
Auf 10.03.2011 22:55, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 05:51, Jordan Justen schrieb: >> >>> I have documented a simple flash-like device which I think could be >>> useful for qemu/kvm in some cases. (Particularly for allowing >>> persistent UEFI non-volatile variables.) >>> >>> http://wiki.qemu.org/Features/System_Flash >>> >>> Let me know if you have any suggestions or concerns. >>> >>> >> Is there any reason why you chose to invent an interface for the flash >> chip which is more complicated than the interface used by common flash >> chips out there? >> Maybe some EFI requirement? >> > This is a simpler version than the flash devices I'm used to dealing > with for x86/x86-64 UEFI systems. Can you suggest an alternative real > interface that is simpler? > Pseudocode for the real interface most common on x86 before SPI came along: Write a page (256 bytes) or a few bytes: chip_writeb(0xAA, bios_base + 0x); chip_writeb(0x55, bios_base + 0x2AAA); chip_writeb(0xA0, bios_base + 0x); chip_writeb(databyte0, bios_base + addr); chip_writeb(databyte1, bios_base + addr + 1); chip_writeb(databyte2, bios_base + addr + 2); chip_writeb(databyte3, bios_base + addr + 3); ... up to 256 databytes. chip_readb(bios_base); The last chip_readb(bios_base) is repeated until the result does not change anymore. For me, that looks pretty simple and straightforward, especially compared to other more exotic flash chip interfaces. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] Re: RFC: emulation of system flash
Auf 10.03.2011 23:14, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 19:43, Jordan Justen schrieb: >> >>> I thought this might be a case where deviation from real hardware >>> emulation could better serve the VM's needs. >>> >> If we have to write the code anyway, and if it can work just fine with >> current KVM/Qemu, is there a reason not to use the same interface as >> real hardware? >> > If there was a real device emulated by qemu, I would gladly make use > of it in OVMF. > Nice. So should I dig up my flash emulator code and check which chips are supported? Porting the code to Qemu shouldn't be too hard. > I just thought this proposal would be much easier to implement, and > not be restricted to any particular size. (Since -bios currently > supports any size that is a multiple of 64kb.) A real device is going > to imply a certain size. > Right, the constant size argument is definitely a point we need to talk about. We could sidestep the issue by always using a 16 MByte flash device which gets filled from the top with the firmware image, but I'm not sure if that has other side effects. Another way to solve this would be to emulate multiple flash chips, one per power-of-two size between 128 kB and 16 MB. Some SPI flash chip families encode the size into their ID, so determining the size algorithmically is as simple as calculating 1 << idbyte3 and emulating this is equally simple. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] Re: RFC: emulation of system flash
Auf 10.03.2011 23:58, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger > wrote: > >> Right, the constant size argument is definitely a point we need to talk >> about. >> >> We could sidestep the issue by always using a 16 MByte flash device >> which gets filled from the top with the firmware image, but I'm not sure >> if that has other side effects. >> Another way to solve this would be to emulate multiple flash chips, one >> per power-of-two size between 128 kB and 16 MB. Some SPI flash chip >> families encode the size into their ID, so determining the size >> algorithmically is as simple as calculating >> 1 << idbyte3 >> and emulating this is equally simple. >> > Power of 2 from 128kb to 16MB sounds reasonable to me. > > How would the SPI host controller be discovered? PCI ID of the ISA bridge of the chipset. AFAIK most flashing programs out there use that criterion. There is one drawback, though: We should use an interface which works well for all emulated chipsets in Qemu, and that may a bit harder. Is there a way to get PCI IDs of all emulated chipsets in Qemu so I can take a look if there is a chance to to this correctly? > Would the firmware > be able to depend on having control of the device at OS runtime? This > would be needed for UEFI non-volatile variables to make sure they can > always be written. > UEFI _should not_ have control of the device at OS runtime on real hardware for security reasons, unless UEFI slipped a rootkit into the OS. Not sure about Windows, but I'm pretty sure Linux will not run any UEFI code (except maybe during early init). Think flash update. If some flash update software runs under your OS of choice, and UEFI is allowed to perform read/write accesses to flash at the same time, you will get random corruption. You could do it like some AMD chipsets, and provide some sort of semaphore for flash access coordination between a flash updater and the BIOS/EFI, but I don't think any Intel chipset can do that. Newer Intel chipsets allow locking out flash accesses not coming from the management engine, but UEFI does not run in the management engine, so that feature won't help us here. That said, if any OS out there indeed runs UEFI code regularly during OS runtime, and that UEFI code wants to access flash, it has to hope that nobody else is trying to access flash at the same time. An easy way out would be to use the ACPI NVS region while the machine is running an OS, but changes would not automatically be persistent without help from the OS or some ACPI handler on shutdown. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] RFC: emulation of system flash
Hi Jordan, thanks for your insights. Auf 10.03.2011 23:29, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 22:55, Jordan Justen schrieb: >> >>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >>> wrote: >>> >>>> Is there any reason why you chose to invent an interface for the flash >>>> chip which is more complicated than the interface used by common flash >>>> chips out there? >>>> Maybe some EFI requirement? >>>> >>> This is a simpler version than the flash devices I'm used to dealing >>> with for x86/x86-64 UEFI systems. Can you suggest an alternative real >>> interface that is simpler? >>> >> Pseudocode for the real interface most common on x86 before SPI came along: >> >> Write a page (256 bytes) or a few bytes: >> chip_writeb(0xAA, bios_base + 0x); >> chip_writeb(0x55, bios_base + 0x2AAA); >> chip_writeb(0xA0, bios_base + 0x); >> chip_writeb(databyte0, bios_base + addr); >> chip_writeb(databyte1, bios_base + addr + 1); >> chip_writeb(databyte2, bios_base + addr + 2); >> chip_writeb(databyte3, bios_base + addr + 3); >> ... up to 256 databytes. >> chip_readb(bios_base); >> The last chip_readb(bios_base) is repeated until the result does not >> change anymore. >> >> For me, that looks pretty simple and straightforward, especially >> compared to other more exotic flash chip interfaces. >> > I disagree that you think my proposal is more complicated than this example. > Upon rereading your proposal, I think the unfamiliarity of the proposed interface and the index/data design triggered my "complicated" reflex. > But, I would agree, that all other things being equal, emulating a > real device would be preferable. > > I would like to know what people's thoughts are regarding supporting > various devices sizes. I think that right now -bios should support > files sizes that are multiples of 64kb up to ~16MB. (Perhaps even > larger.) > On recent Intel chipsets you are limited to 16 MB mapped to the top of the 32bit address space. The same limitation exists for most other x86 chipsets as well. That said, some people may want bigger images, but for x86 this may cause conflicts with the HPET region. > A large -bios file can be interesting for embedding an OS image into > the rom/flash device... > I've seen people embed coreboot+Linux+X.org into a 4 MB image on x86, so I think 16 MB are plenty (flash bigger than that is either NAND or expensive or slow, and would require significant effort to emulate correctly (NAND) or simply not exist in consumer equipment for speed/money reasons). > Carl-Daniel, do you think we can address this while still supporting > real hardware emulation? > If we restrict ourselves to the 128kB-16MB range, I think I can find a flash chip family which has the criteria we want. 64 kByte flash chips still exist, but usually not as part of a family which reaches 16 MByte. We should decide first if we want SPI flash or Parallel flash, and then I can try to find a matching flash chip family. Regards, Carl-Daniel -- http://www.hailfinger.org/
[Qemu-devel] Re: RFC: emulation of system flash
Auf 11.03.2011 01:19, Jan Kiszka schrieb: > On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote: > >> Auf 10.03.2011 22:55, Jordan Justen schrieb: >> >>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >>> wrote: >>> >>> >>>> Auf 10.03.2011 05:51, Jordan Justen schrieb: >>>> >>>> >>>>> I have documented a simple flash-like device which I think could be >>>>> useful for qemu/kvm in some cases. (Particularly for allowing >>>>> persistent UEFI non-volatile variables.) >>>>> >>>>> http://wiki.qemu.org/Features/System_Flash >>>>> >>>>> Let me know if you have any suggestions or concerns. >>>>> >>>>> >>>>> >>>> Is there any reason why you chose to invent an interface for the flash >>>> chip which is more complicated than the interface used by common flash >>>> chips out there? >>>> Maybe some EFI requirement? >>>> >>>> >>> This is a simpler version than the flash devices I'm used to dealing >>> with for x86/x86-64 UEFI systems. Can you suggest an alternative real >>> interface that is simpler? >>> >>> >> Pseudocode for the real interface most common on x86 before SPI came along: >> >> Write a page (256 bytes) or a few bytes: >> chip_writeb(0xAA, bios_base + 0x); >> chip_writeb(0x55, bios_base + 0x2AAA); >> chip_writeb(0xA0, bios_base + 0x); >> chip_writeb(databyte0, bios_base + addr); >> chip_writeb(databyte1, bios_base + addr + 1); >> chip_writeb(databyte2, bios_base + addr + 2); >> chip_writeb(databyte3, bios_base + addr + 3); >> ... up to 256 databytes. >> chip_readb(bios_base); >> The last chip_readb(bios_base) is repeated until the result does not >> change anymore. >> > Hmm, I may oversee some subtle difference, but this looks pretty much > like CFI to me (see hw/pflash_cfi02.c). > I thought CFI also implements a way to retrieve device size/geometry with the Query (0x98) command, but that part is rarely implemented on x86 flash (I didn't see any yet). That said, the non-query commands are identical AFAICS. > At least it's an in-band interface, which is the better choice as we > currently only have a PIIX3 southbridge for x86, predating even FWHs. > Right, that pretty much kills the option of using SPI unless someone wants to emulate a flash translation controller (e.g. the ITE IT8716F Super I/O). Can be done, would work, but the IT8716F has some quirks (max 1 MB SPI flash chips) which make it a less desirable option for emulation. Regards, Carl-Daniel -- http://www.hailfinger.org/
[Qemu-devel] Re: [SeaBIOS] About cpu_set, CPU hotplug and related subjects
On 28.04.2010 12:45, Gleb Natapov wrote: > On Wed, Apr 28, 2010 at 12:41:51PM +0200, Jes Sorensen wrote: > >> The CPU declarations are particularly tricky as they get pretty big and >> complex and need to live in the DSDT, whereas a lot of other things we >> can shift off to separate SSDT tables and only put the minimum that >> needs to be generated dynamically in it's own table. >> >> > We can generate complex code statically and call it from dynamically > generated CPU declarations. > There is some ACPI code generator in coreboot. Not sure if it is usable for those purposes. coreboot uses it to generate AMD CPU frequency tables. Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: [Qemu-devel] Unclear committer situation
On 02.12.2009 20:12, Anthony Liguori wrote: > Artyom Tarasenko wrote: >> I thought attaching a second copy were the way to send the patch >> properly. >> > > Attaching as an application/octet-stream is not terribly helpful. It > basically means you've attached a binary blob. > >> Is the proper way described somewhere? >> > > The proper way is to use a mailer that isn't broken. Attaching > everything as "application/octet-stream" is broken. Some mailers do the right thing if the attachment name ends in .txt (maybe that helps with gmail). Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
Re: [Qemu-devel] Re: approaches to 3D virtualisation
On 12.12.2009 13:08, Juan Quintela wrote: > - vmware_vga. Lets say that the way that it embeds an vga is > _interesting_ to say the less. Also the vga can be compiled out, but > not bios/os on earth will boot without its support. > The coreboot developers can boot Linux on all VIA chipsets without VGA support (no VGA ROM, no VGA interface) and X works just fine. Note that this works on pretty much every 2.6.x Linux kernel and X with the Unichrome driver. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
Re: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
On 22.11.2009 18:39, Sebastian Herbszt wrote: > Gleb Natapov wrote: >> On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote: >>> Is the requirement for "Targeted Content Delivery" specified >>> somewhere with something more >>> clear than "SMBIOS data is useful in identifying the computer for >>> targeted delivery of >>> model-specific software and firmware content" (e.g. changing BIOS >>> version, release date, etc.)? >>> >>> >@@ -130,8 +131,8 @@ smbios_init_type_1(void *start) >>> >p->header.length = sizeof(struct smbios_type_1); >>> >p->header.handle = 0x100; >>> > >>> >-load_str_field_or_skip(1, manufacturer_str); >>> >-load_str_field_or_skip(1, product_name_str); >>> >+load_str_field_with_default(1, manufacturer_str, "QEMU"); >>> >+load_str_field_with_default(1, product_name_str, "QEMU"); >>> >>> Use "QEMU Virtual Platform" product name derivated from "VMware >>> Virtual Platform" ? >>> Use "QEMU Project" or "QEMU Community" throughout for manufacturer >>> name? >> I'll change this to use defines as per Kevin's request, so to keep >> number of defines to minimum >> lets make it "QEMU Project" everywhere. > > Will you introduce something like CONFIG_SYSVENDOR? Would be useful in > case some other project > (Bochs, Xen?) starts to use seabios. coreboot already uses SeaBIOS on various x86 hardware platforms. Regards, Carl-Daniel -- Developer quote of the month: "We are juggling too many chainsaws and flaming arrows and tigers."
Re: [PATCH] hw/char: suppress sunmouse events with no changes
More on whether the sunmouse_prev_state needs to be migrated. I think
that if it were NOT included in the migration state the following
would hold, assuming that it would be initialized to 0 in the "to"
environment:
1. If prev_state is 0 in the "from" environment the prev_state in the
"to" environment would be correct -- and this would be the case almost
all the time.
2. If it is non-0 in the "from" environment (so the guest OS believes
there is a mouse button pressed) and the first mouse event in the "to"
environment has motion, the event will be sent correctly and the
prev_state is then correct; likely almost all of the rest of the time.
3. If it is non-0 in the "from" environment (so the guest OS believes
there is a mouse button pressed) and the first mouse event in the "to"
environment has no motion and non-zero button state the event will be
sent and there are two cases:
3a. if the button state is NOT the same as the prev state in the
"from" environment the event will have been sent correctly.
*3b. if the button state IS the same as prev_state in the "from"
environment (so the guest OS believes there is a mouse button pressed)
the event will have been sent incorrectly and is a duplicate. The
prev_state in the "to" environment will now be correct and no further
duplicates will be sent.
*4. If it is non-0 in the "from" environment (so the guest OS believes
there is a mouse button pressed) and the first mouse event(s) in the
"to" environment has no motion and zero button state, the event will
not be sent. It is not apparent that the code that carries mouse
events from the host to the escc driver level would ever produce such
an event as the first one or ones, but if it did the state would
persist until there was mouse motion or a button press event. The
consequence would be that the guest would continue to understand that
a mouse button was pressed when it was not. The situation gets
corrected on any mouse movement or button press.
So the starred cases, 3b and 4, are the only incorrect behaviors. Both
are likely extremely rare and hard to make happen. Case 3b results in
one spurious duplicate event sent to the guest. I have only seen
Solaris misbehave in the face of a flood of duplicate events. My
testing with linux didn't uncover any misbehavior even when flooded
with duplicates. NetBSD 10 has other mouse misbehaviors that make it
hard to tell whether or not duplicates matter there. In case 4, the
guest would continue to believe a mouse button was depressed when it
wasn't but this would be cured by any button press or movement.
It appears that this is all quite similar to the way caps_lock_mode
and num_lock_mode are handled in escc -- they are both part of the
ESCCChannelState but not part of the migration state and I would
expect would exhibit similar need to see transitions in some cases
before getting the state fully correct after a migration.
On Wed, Aug 21, 2024 at 7:18 AM Mark Cave-Ayland
wrote:
>
> On 20/08/2024 08:34, Richard Henderson wrote:
>
> > On 8/20/24 09:18, Carl Hauser wrote:
> >> @@ -959,6 +960,15 @@ static void sunmouse_event(void *opaque,
> >> int ch;
> >>
> >> trace_escc_sunmouse_event(dx, dy, buttons_state);
> >> +
> >> +/* Don't send duplicate events without motion */
> >> +if (dx == 0 &&
> >> +dy == 0 &&
> >> +(s->sunmouse_prev_state ^ buttons_state) == 0) {
> >
> > Were you intending to mask vs MOUSE_EVENT_*BUTTON?
> > Otherwise this is just plain equality.
> >
> >> diff --git a/include/hw/char/escc.h b/include/hw/char/escc.h
> >> index 5669a5b811..bc5ba4f564 100644
> >> --- a/include/hw/char/escc.h
> >> +++ b/include/hw/char/escc.h
> >> @@ -46,6 +46,7 @@ typedef struct ESCCChannelState {
> >> uint8_t rx, tx;
> >> QemuInputHandlerState *hs;
> >> char *sunkbd_layout;
> >> +int sunmouse_prev_state;
> >
> > This adds new state that must be migrated.
> >
> > While the patch is relatively simple, I do wonder if this code could be
> > improved by
> > converting away from the legacy mouse interface to
> > qemu_input_handler_register.
> > Especially if that might help avoid needing to add migration state that
> > isn't
> > "really" part of the device.
> >
> > Mark?
>
> Ooof I didn't even realise that qemu_add_mouse_event_handler() was legacy -
> is that
> documented anywhere at all?
>
> At first glance (e.g.
> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/ps2.c?ref_type=heads#L789)
> it appears that movement and button events are handled separately which I
> think would
> solve the problem.
>
> I can try and put something together quickly for Carl to test and improve if
> that
> helps, although I'm quite tied up with client work and life in general right
> now(!).
>
>
> ATB,
>
> Mark.
>
>
Re: [PATCH] escc: convert Sun mouse to use QemuInputHandler
This still, but less frequently, shows the behavior of having the cursor
leap downwards occasionally. I may not be able to work on debugging it
until next week, but I'll try to see if I can figure it out sooner. The
hypothesis with the old code was that it was sending floods of mouse
messages and the Sun driver was dropping a byte at some point. So that's
the first thing I'll look into with this new code, but it could be
something different. This is definitely better than the old code -- just
not sending anything in response to mouse wheel movement helps a lot.
On Mon, Sep 2, 2024 at 2:38 PM Mark Cave-Ayland <
mark.cave-ayl...@ilande.co.uk> wrote:
> Update the Sun mouse implementation to use QemuInputHandler instead of the
> legacy qemu_add_mouse_event_handler() function.
>
> Note that this conversion adds extra sunmouse_* members to ESCCChannelState
> but they are not added to the migration stream (similar to the Sun keyboard
> members). If this were desired in future, the Sun devices should be split
> into separate devices and added to the migration stream there instead.
>
> Signed-off-by: Mark Cave-Ayland
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2518
> ---
> hw/char/escc.c | 79 ++
> include/hw/char/escc.h | 3 ++
> roms/seabios | 2 +-
> 3 files changed, 60 insertions(+), 24 deletions(-)
>
> diff --git a/hw/char/escc.c b/hw/char/escc.c
> index d450d70eda..6d4e3e3350 100644
> --- a/hw/char/escc.c
> +++ b/hw/char/escc.c
> @@ -287,6 +287,7 @@ static void escc_reset_chn(ESCCChannelState *s)
> s->rxint = s->txint = 0;
> s->rxint_under_svc = s->txint_under_svc = 0;
> s->e0_mode = s->led_mode = s->caps_lock_mode = s->num_lock_mode = 0;
> +s->sunmouse_dx = s->sunmouse_dy = s->sunmouse_buttons = 0;
> clear_queue(s);
> }
>
> @@ -952,53 +953,85 @@ static void handle_kbd_command(ESCCChannelState *s,
> int val)
> }
> }
>
> -static void sunmouse_event(void *opaque,
> - int dx, int dy, int dz, int buttons_state)
> +static void sunmouse_handle_event(DeviceState *dev, QemuConsole *src,
> + InputEvent *evt)
> {
> -ESCCChannelState *s = opaque;
> -int ch;
> +ESCCChannelState *s = (ESCCChannelState *)dev;
> +InputMoveEvent *move;
> +InputBtnEvent *btn;
> +static const int bmap[INPUT_BUTTON__MAX] = {
> +[INPUT_BUTTON_LEFT] = 0x4,
> +[INPUT_BUTTON_MIDDLE] = 0x2,
> +[INPUT_BUTTON_RIGHT] = 0x1,
> +[INPUT_BUTTON_SIDE] = 0x0,
> +[INPUT_BUTTON_EXTRA] = 0x0,
> +};
> +
> +switch (evt->type) {
> +case INPUT_EVENT_KIND_REL:
> +move = evt->u.rel.data;
> +if (move->axis == INPUT_AXIS_X) {
> +s->sunmouse_dx += move->value;
> +} else if (move->axis == INPUT_AXIS_Y) {
> +s->sunmouse_dy -= move->value;
> +}
> +break;
>
> -trace_escc_sunmouse_event(dx, dy, buttons_state);
> -ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
> +case INPUT_EVENT_KIND_BTN:
> +btn = evt->u.btn.data;
> +if (btn->down) {
> +s->sunmouse_buttons |= bmap[btn->button];
> +} else {
> +s->sunmouse_buttons &= ~bmap[btn->button];
> +}
> +break;
>
> -if (buttons_state & MOUSE_EVENT_LBUTTON) {
> -ch ^= 0x4;
> -}
> -if (buttons_state & MOUSE_EVENT_MBUTTON) {
> -ch ^= 0x2;
> -}
> -if (buttons_state & MOUSE_EVENT_RBUTTON) {
> -ch ^= 0x1;
> +default:
> +/* keep gcc happy */
> +break;
> }
> +}
>
> -put_queue(s, ch);
> +static void sunmouse_sync(DeviceState *dev)
> +{
> +ESCCChannelState *s = (ESCCChannelState *)dev;
> +int ch;
>
> -ch = dx;
> +trace_escc_sunmouse_event(s->sunmouse_dx, s->sunmouse_dy, 0);
> +ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
> +ch ^= s->sunmouse_buttons;
> +put_queue(s, ch);
>
> +ch = s->sunmouse_dx;
> if (ch > 127) {
> ch = 127;
> } else if (ch < -127) {
> ch = -127;
> }
> -
> put_queue(s, ch & 0xff);
> +s->sunmouse_dx = 0;
>
> -ch = -dy;
> -
> +ch = s->sunmouse_dy;
> if (ch > 127) {
> ch = 127;
> } else if (ch < -127) {
> ch = -127;
> }
> -
> put_queue(s, ch & 0xff);
> +s->sunmouse_dy = 0;
>
> /* MSC protocol specifies two extra motion bytes */
> -
> put_queue(s, 0);
> put_queue(s, 0);
> }
>
> +static const QemuInputHandler sunmouse_handler = {
> +.name = "QEMU Sun Mouse",
> +.mask = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_REL,
> +.event = sunmouse_handle_event,
> +.sync = sunmouse_sync,
> +};
> +
> static void escc_init1(Object *obj)
> {
> ESCCState *s = ESCC(obj);
> @@ -1036,8 +1069,8 @@ static void escc_realize(DeviceState *dev, Error
> **errp)
> }
>
> if (s->chn[0].type == escc_m
Re: [PATCH] escc: convert Sun mouse to use QemuInputHandler
Well, I was wrong -- it is sending a duplicate mouse packets when the mouse
wheel is rotated. The packets correctly represent the mouse buttons state.
I just now discovered that one of my Logitech mice sends continuous mouse
events when the wheel is rotated half a notch and held there. Another
Logitech mouse doesn't do that but does send multiple (6-10) events per
notch. A Microsoft mouse sends 2 events per notch.
I don't know where these should be suppressed. Mouse wheel rotation of a
host mouse shouldn't send anything to the emulated Sun mouse. I suspect
that the unwanted host events are propagating down to escc via calls to
sunmouse_sync. So is sunmouse_sync where they should be filtered out?
Probably, because the calling code is not specific to sunmouse and for
other mice those calls are needed.
-- Carl
On Mon, Sep 2, 2024 at 4:16 PM Carl Hauser wrote:
> This still, but less frequently, shows the behavior of having the cursor
> leap downwards occasionally. I may not be able to work on debugging it
> until next week, but I'll try to see if I can figure it out sooner. The
> hypothesis with the old code was that it was sending floods of mouse
> messages and the Sun driver was dropping a byte at some point. So that's
> the first thing I'll look into with this new code, but it could be
> something different. This is definitely better than the old code -- just
> not sending anything in response to mouse wheel movement helps a lot.
>
> On Mon, Sep 2, 2024 at 2:38 PM Mark Cave-Ayland <
> mark.cave-ayl...@ilande.co.uk> wrote:
>
>> Update the Sun mouse implementation to use QemuInputHandler instead of the
>> legacy qemu_add_mouse_event_handler() function.
>>
>> Note that this conversion adds extra sunmouse_* members to
>> ESCCChannelState
>> but they are not added to the migration stream (similar to the Sun
>> keyboard
>> members). If this were desired in future, the Sun devices should be split
>> into separate devices and added to the migration stream there instead.
>>
>> Signed-off-by: Mark Cave-Ayland
>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2518
>> ---
>> hw/char/escc.c | 79 ++
>> include/hw/char/escc.h | 3 ++
>> roms/seabios | 2 +-
>> 3 files changed, 60 insertions(+), 24 deletions(-)
>>
>> diff --git a/hw/char/escc.c b/hw/char/escc.c
>> index d450d70eda..6d4e3e3350 100644
>> --- a/hw/char/escc.c
>> +++ b/hw/char/escc.c
>> @@ -287,6 +287,7 @@ static void escc_reset_chn(ESCCChannelState *s)
>> s->rxint = s->txint = 0;
>> s->rxint_under_svc = s->txint_under_svc = 0;
>> s->e0_mode = s->led_mode = s->caps_lock_mode = s->num_lock_mode = 0;
>> +s->sunmouse_dx = s->sunmouse_dy = s->sunmouse_buttons = 0;
>> clear_queue(s);
>> }
>>
>> @@ -952,53 +953,85 @@ static void handle_kbd_command(ESCCChannelState *s,
>> int val)
>> }
>> }
>>
>> -static void sunmouse_event(void *opaque,
>> - int dx, int dy, int dz, int buttons_state)
>> +static void sunmouse_handle_event(DeviceState *dev, QemuConsole *src,
>> + InputEvent *evt)
>> {
>> -ESCCChannelState *s = opaque;
>> -int ch;
>> +ESCCChannelState *s = (ESCCChannelState *)dev;
>> +InputMoveEvent *move;
>> +InputBtnEvent *btn;
>> +static const int bmap[INPUT_BUTTON__MAX] = {
>> +[INPUT_BUTTON_LEFT] = 0x4,
>> +[INPUT_BUTTON_MIDDLE] = 0x2,
>> +[INPUT_BUTTON_RIGHT] = 0x1,
>> +[INPUT_BUTTON_SIDE] = 0x0,
>> +[INPUT_BUTTON_EXTRA] = 0x0,
>> +};
>> +
>> +switch (evt->type) {
>> +case INPUT_EVENT_KIND_REL:
>> +move = evt->u.rel.data;
>> +if (move->axis == INPUT_AXIS_X) {
>> +s->sunmouse_dx += move->value;
>> +} else if (move->axis == INPUT_AXIS_Y) {
>> +s->sunmouse_dy -= move->value;
>> +}
>> +break;
>>
>> -trace_escc_sunmouse_event(dx, dy, buttons_state);
>> -ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
>> +case INPUT_EVENT_KIND_BTN:
>> +btn = evt->u.btn.data;
>> +if (btn->down) {
>> +s->sunmouse_buttons |= bmap[btn->button];
>> +} else {
>> +s->sunmouse_buttons &= ~bmap[btn->button];
>> +}
>> +break;
>>
>> -if (buttons_state & MOUSE_EVENT_LBUTTON) {
>> -c
Re: [PATCH v2] escc: convert Sun mouse to use QemuInputHandler
This works well.
On Tue, Sep 3, 2024 at 1:38 PM Mark Cave-Ayland <
mark.cave-ayl...@ilande.co.uk> wrote:
> Update the Sun mouse implementation to use QemuInputHandler instead of the
> legacy qemu_add_mouse_event_handler() function.
>
> Note that this conversion adds extra sunmouse_* members to ESCCChannelState
> but they are not added to the migration stream (similar to the Sun keyboard
> members). If this were desired in future, the Sun devices should be split
> into separate devices and added to the migration stream there instead.
>
> Signed-off-by: Mark Cave-Ayland
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2518
> ---
> hw/char/escc.c | 88 +++---
> include/hw/char/escc.h | 3 ++
> 2 files changed, 69 insertions(+), 22 deletions(-)
>
>
> v2:
> - Only allow left, middle and right button events (use bit 7 which is
> always
> set in the first byte to indicate a valid event)
>
> - Remove zero entries from the bmap table as static entries should be
> zero anyway
>
> diff --git a/hw/char/escc.c b/hw/char/escc.c
> index d450d70eda..641d4ee206 100644
> --- a/hw/char/escc.c
> +++ b/hw/char/escc.c
> @@ -287,6 +287,7 @@ static void escc_reset_chn(ESCCChannelState *s)
> s->rxint = s->txint = 0;
> s->rxint_under_svc = s->txint_under_svc = 0;
> s->e0_mode = s->led_mode = s->caps_lock_mode = s->num_lock_mode = 0;
> +s->sunmouse_dx = s->sunmouse_dy = s->sunmouse_buttons = 0;
> clear_queue(s);
> }
>
> @@ -952,53 +953,96 @@ static void handle_kbd_command(ESCCChannelState *s,
> int val)
> }
> }
>
> -static void sunmouse_event(void *opaque,
> - int dx, int dy, int dz, int buttons_state)
> +static void sunmouse_handle_event(DeviceState *dev, QemuConsole *src,
> + InputEvent *evt)
> {
> -ESCCChannelState *s = opaque;
> -int ch;
> +ESCCChannelState *s = (ESCCChannelState *)dev;
> +InputMoveEvent *move;
> +InputBtnEvent *btn;
> +static const int bmap[INPUT_BUTTON__MAX] = {
> +[INPUT_BUTTON_LEFT] = 0x4,
> +[INPUT_BUTTON_MIDDLE] = 0x2,
> +[INPUT_BUTTON_RIGHT] = 0x1,
> +};
> +
> +switch (evt->type) {
> +case INPUT_EVENT_KIND_REL:
> +move = evt->u.rel.data;
> +if (move->axis == INPUT_AXIS_X) {
> +s->sunmouse_dx += move->value;
> +} else if (move->axis == INPUT_AXIS_Y) {
> +s->sunmouse_dy -= move->value;
> +}
> +break;
>
> -trace_escc_sunmouse_event(dx, dy, buttons_state);
> -ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
> +case INPUT_EVENT_KIND_BTN:
> +btn = evt->u.btn.data;
> +if (bmap[btn->button]) {
> +if (btn->down) {
> +s->sunmouse_buttons |= bmap[btn->button];
> +} else {
> +s->sunmouse_buttons &= ~bmap[btn->button];
> +}
> +/* Indicate we have a supported button event */
> +s->sunmouse_buttons |= 0x80;
> +}
> +break;
>
> -if (buttons_state & MOUSE_EVENT_LBUTTON) {
> -ch ^= 0x4;
> -}
> -if (buttons_state & MOUSE_EVENT_MBUTTON) {
> -ch ^= 0x2;
> +default:
> +/* keep gcc happy */
> +break;
> }
> -if (buttons_state & MOUSE_EVENT_RBUTTON) {
> -ch ^= 0x1;
> +}
> +
> +static void sunmouse_sync(DeviceState *dev)
> +{
> +ESCCChannelState *s = (ESCCChannelState *)dev;
> +int ch;
> +
> +if (s->sunmouse_dx == 0 && s->sunmouse_dy == 0 &&
> +(s->sunmouse_buttons & 0x80) == 0) {
> +/* Nothing to do after button event filter */
> +return;
> }
>
> +/* Clear our button event flag */
> +s->sunmouse_buttons &= ~0x80;
> +trace_escc_sunmouse_event(s->sunmouse_dx, s->sunmouse_dy,
> + s->sunmouse_buttons);
> +ch = 0x80 | 0x7; /* protocol start byte, no buttons pressed */
> +ch ^= s->sunmouse_buttons;
> put_queue(s, ch);
>
> -ch = dx;
> -
> +ch = s->sunmouse_dx;
> if (ch > 127) {
> ch = 127;
> } else if (ch < -127) {
> ch = -127;
> }
> -
> put_queue(s, ch & 0xff);
> +s->sunmouse_dx = 0;
>
> -ch = -dy;
> -
> +ch = s->sunmouse_dy;
> if (ch > 127) {
> ch = 127;
> } else if (ch < -127) {
> ch = -127;
> }
> -
> put_queue(s, ch & 0xff);
> +s->sunmouse_dy = 0;
>
> /* MSC protocol specifies two extra motion bytes */
> -
> put_queue(s, 0);
> put_queue(s, 0);
> }
>
> +static const QemuInputHandler sunmouse_handler = {
> +.name = "QEMU Sun Mouse",
> +.mask = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_REL,
> +.event = sunmouse_handle_event,
> +.sync = sunmouse_sync,
> +};
> +
> static void escc_init1(Object *obj)
> {
> ESCCState *s = ESCC(obj);
> @@ -1036,8 +1080,8 @@ static void escc_realize(DeviceState *dev, Error
> **errp
Re: [Qemu-devel] [Nbd] write_zeroes/trim on the whole disk
On 24.09.2016 19:33, Vladimir Sementsov-Ogievskiy wrote: > On 24.09.2016 20:13, Vladimir Sementsov-Ogievskiy wrote: >> I agree that requests larger than disk size are ugly.. But splitting >> request brings me again to idea of having separate command or flag >> for clearing the whole disk without that dance. Server may report >> availability of this/flag command only if target driver supports fast >> write_zeroes (qcow2 in our case). > Also, such flag may be used to satisfy all needs: > > flag BIG_REQUEST is set and length = 0->request on the whole > disk, offset must be 0 > flag BIG_REQUEST is set and length > 0->request on > (offset*block_size, length*block_size), length*block_size must be <= > disk_size What happens if length*block_size<=disk_size, but offset*block_size+length*block_size>disk_size? Wraparound? Regards, Carl-Daniel
