from:"r"

[PATCH 0/1] i386/tcg fix for IRET as used in dotnet runtime

2024-06-11 Thread Robert R. Henry

This patch fixes the i386/tcg implementation of the IRET instruction
so that IRET can return from user space to user space, as used by the
dotnet runtime to switch threads.

This fixes https://gitlab.com/qemu-project/qemu/-/issues/249

I debugged this issue 4+ years ago, and wrote this patch then.

At the time, I did not fully understand the nuances of the priority
levels in the TCG emulation of the x86, nor of the x86 itself.
I understand less now!

I do not recall exactly how I was led to the conclusion that an
unhandled page fault in kernel space was due to a bug in the code
executed in the tcg emulator for IRET. Eventually, my approach to
debugging was to modify the source for the dotnet runtime so that
immediately prior to the IRET I executed an x87 fpatan2 instruction,
knowing that no modern program used that instruction, and that there
was a single point in QEMU source code that emulated that, making it a
convenient place to put gdb breakpoints to enable further breakpoints in
the IRET emulation code.

With this change the page faults go away, and that the dotnet program
completes as expected. For the curious,
https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/arch/amd64/context2.S#L241
shows how the dotnet runtime uses iret.

I have booted BSD, solaris and macosX with this change, and await
results for booting Windows from the Windows kernel team.

I have not tested this with other modern JITers, such as Java,
v8, or HHVM.

Robert R. Henry (1):
i386/tcg: Allow IRET from user mode to user mode for dotnet runtime

target/i386/tcg/seg_helper.c | 78 ++--
1 file changed, 47 insertions(+), 31 deletions(-)

--
2.34.1

[PATCH 1/1] i386/tcg: Allow IRET from user mode to user mode for dotnet runtime

2024-06-11 Thread Robert R. Henry

This fixes a bug wherein i386/tcg assumed an interrupt return using
the IRET instruction was always returning from kernel mode to either
kernel mode or user mode. This assumption is violated when IRET is used
as a clever way to restore thread state, as for example in the dotnet
runtime. There, IRET returns from user mode to user mode.

This bug manifested itself as a page fault in the guest Linux kernel.

This bug appears to have been in QEMU since the beginning.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/249
Signed-off-by: Robert R. Henry 
---
 target/i386/tcg/seg_helper.c | 78 ++--
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/target/i386/tcg/seg_helper.c b/target/i386/tcg/seg_helper.c
index 715db1f232..815d26e61d 100644
--- a/target/i386/tcg/seg_helper.c
+++ b/target/i386/tcg/seg_helper.c
@@ -843,20 +843,35 @@ static void do_interrupt_protected(CPUX86State *env, int 
intno, int is_int,
 
 #ifdef TARGET_X86_64
 
-#define PUSHQ_RA(sp, val, ra)   \
-{   \
-sp -= 8;\
-cpu_stq_kernel_ra(env, sp, (val), ra);  \
-}
-
-#define POPQ_RA(sp, val, ra)\
-{   \
-val = cpu_ldq_kernel_ra(env, sp, ra);   \
-sp += 8;\
-}
+#define PUSHQ_RA(sp, val, ra, cpl, dpl) \
+  FUNC_PUSHQ_RA(env, , val, ra, cpl, dpl)
+
+static inline void FUNC_PUSHQ_RA(
+CPUX86State *env, target_ulong *sp,
+target_ulong val, target_ulong ra, int cpl, int dpl) {
+  *sp -= 8;
+  if (dpl == 0) {
+cpu_stq_kernel_ra(env, *sp, val, ra);
+  } else {
+cpu_stq_data_ra(env, *sp, val, ra);
+  } 
+}
 
-#define PUSHQ(sp, val) PUSHQ_RA(sp, val, 0)
-#define POPQ(sp, val) POPQ_RA(sp, val, 0)
+#define POPQ_RA(sp, val, ra, cpl, dpl) \
+  val = FUNC_POPQ_RA(env, , ra, cpl, dpl)
+
+static inline target_ulong FUNC_POPQ_RA(
+CPUX86State *env, target_ulong *sp,
+target_ulong ra, int cpl, int dpl) {
+  target_ulong val;
+  if (cpl == 0) {  /* TODO perhaps both arms reduce to cpu_ldq_data_ra? */
+val = cpu_ldq_kernel_ra(env, *sp, ra);
+  } else {
+val = cpu_ldq_data_ra(env, *sp, ra);
+  }
+  *sp += 8;
+  return val;
+}
 
 static inline target_ulong get_rsp_from_tss(CPUX86State *env, int level)
 {
@@ -901,6 +916,7 @@ static void do_interrupt64(CPUX86State *env, int intno, int 
is_int,
 uint32_t e1, e2, e3, ss, eflags;
 target_ulong old_eip, esp, offset;
 bool set_rf;
+const target_ulong retaddr = 0;
 
 has_error_code = 0;
 if (!is_int && !is_hw) {
@@ -989,13 +1005,13 @@ static void do_interrupt64(CPUX86State *env, int intno, 
int is_int,
 eflags |= RF_MASK;
 }
 
-PUSHQ(esp, env->segs[R_SS].selector);
-PUSHQ(esp, env->regs[R_ESP]);
-PUSHQ(esp, eflags);
-PUSHQ(esp, env->segs[R_CS].selector);
-PUSHQ(esp, old_eip);
+PUSHQ_RA(esp, env->segs[R_SS].selector, retaddr, cpl, dpl);
+PUSHQ_RA(esp, env->regs[R_ESP], retaddr, cpl, dpl);
+PUSHQ_RA(esp, eflags,   retaddr, cpl, dpl);
+PUSHQ_RA(esp, env->segs[R_CS].selector, retaddr, cpl, dpl);
+PUSHQ_RA(esp, old_eip,  retaddr, cpl, dpl);
 if (has_error_code) {
-PUSHQ(esp, error_code);
+PUSHQ_RA(esp, error_code, retaddr, cpl, dpl);
 }
 
 /* interrupt gate clear IF mask */
@@ -1621,8 +1637,8 @@ void helper_lcall_protected(CPUX86State *env, int new_cs, 
target_ulong new_eip,
 
 /* 64 bit case */
 rsp = env->regs[R_ESP];
-PUSHQ_RA(rsp, env->segs[R_CS].selector, GETPC());
-PUSHQ_RA(rsp, next_eip, GETPC());
+PUSHQ_RA(rsp, env->segs[R_CS].selector, GETPC(), cpl, dpl);
+PUSHQ_RA(rsp, next_eip, GETPC(), cpl, dpl);
 /* from this point, not restartable */
 env->regs[R_ESP] = rsp;
 cpu_x86_load_seg_cache(env, R_CS, (new_cs & 0xfffc) | cpl,
@@ -1792,8 +1808,8 @@ void helper_lcall_protected(CPUX86State *env, int new_cs, 
target_ulong new_eip,
 #ifdef TARGET_X86_64
 if (shift == 2) {
 /* XXX: verify if new stack address is canonical */
-PUSHQ_RA(sp, env->segs[R_SS].selector, GETPC());
-PUSHQ_RA(sp, env->regs[R_ESP], GETPC());
+PUSHQ_RA(sp, env->segs[R_SS].selector, GETPC(), cpl, dpl);
+PUSHQ_RA(sp, env->regs[R_ESP], GETPC(), cpl, dpl);
 /* parameters aren't supported for 64-bit call gates */
 } else
 #endif
@@ -1828,8 +1844,8 @@ void helper_lcall_protected(CPUX86State *env, int new_cs, 
target_ulong new_eip,
 
 #ifdef TARGET_X86_64
 if (shift == 2) {
-PUSHQ_RA(sp, env->segs[R_CS].selector, GETPC());
-PUSHQ_RA(sp, next_eip, GETPC());
+PUSHQ_RA(sp, env->segs[R_CS].sele

Help with QEMU DBUS display

2023-08-28 Thread Elijah R


Hi!

I'm currently attempting to use qemu's DBUS display from within a go 
application, using the godbus 
<https://pkg.go.dev/github.com/godbus/dbus/v5> library. However, I'm 
hitting some roadblocks, and this is probably because I'm a bit confused 
about how qemu's peer-to-peer dbus connection works, and it's not 
explained in the documentation.



I invoke QEMU with the following argument

-display dbus,p2p=yes

and then connect to QMP through a separate UNIX socket. From my 
understanding, I need to listen on the socket separately in the program, 
and then pass qemu the file descriptor over QMP and run add_client.


In the same program I listen to the socket, and start waiting for a 
connection. Then, on another thread, get a file descriptor for the 
socket by first dialing it. Here's my code for that


sock, err := net.Dial("unix", "/tmp/qemudbus.sock")
if err != nil {
return err
}
uc, ok := sock.(*net.UnixConn)
if !ok {
	return fmt.Errorf("Could not cast 
Conn to UnixConn")

}
file, err := uc.File()

I then pass this file descriptor to QEMU using QMP (I'm using 
DigitalOcean's qmp library)


res, err := mon.RunWithFile([]byte(`{"execute": "getfd", "arguments": {"fdname": 
"dbusmon"}}`), file)

And add the dbus client:

res, err = mon.Run([]byte(`{"execute": "add_client", "arguments": {"protocol": "@dbus-display", 
"fdname": "dbusmon"}}`))

This seems to work fine, as I'm then (apparently) able to make a DBUS 
connection with that socket without any error.


However, when I then try to do anything with that connection (In this 
case I'm attempting to introspect /org/qemu/Display1/VM), the call hangs 
and never returns.


node, err := introspect.Call(session.Object("org.qemu.Display1.VM", 
"/org/qemu/Display1/VM"))

I'm not sure what's going wrong here, but I suspect I'm obtaining the 
file descriptor wrong (am I supposed to dial the socket?) or I'm doing 
things in the wrong order.


Thanks in advance for any help.



Regards,

Elijah R


publickey - elijah@elijahr.dev - a0a86704.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

MacOS cocoa/OpenGL

2022-03-04 Thread R Kim

Hello Guys,

Looks like we haven't yet official support for OpenGL on MacOS? I need to apply
third-party patches to make it work. It would be great if these parts are
imported to qemu and be official. Nowaways, it's really needed Acceleration on
VMs for who uses Graphical interfaces browsing, eg, chrome.

I have found it:
https://mail.gnu.org/archive/html/qemu-devel/2021-02/msg04235.html

It uses Angle from Google and the developer seems to be creating you own
branch, with a lot of patches in https://github.com/akihikodaki/qemu/tree/macos

Another it this one, did small changes, but uses SDL instead of cocoa:
Based on initial work "Virgil 3D on macOS" by 小田喜陽彦 akihikodaki.
[https://mail.gnu.org/archive/html/qem...](https://www.youtube.com/redirect?event=video_description_token=QUFFLUhqa3FxTDVuaWhiSFZkWWRkbHZkeTRTckc0bTJIQXxBQ3Jtc0trY3kza3JQT1dPS09vWmhCZktYSTRuWUdJMzB5MGdmV01DYUN4UGpOVTFWS3RwLUNZVGw5MzE3Zzg3WXZLNlJqNVNFZkM5QUZwRUN3UnJfOU5kVWxQaUJLdGo4N0IxVXd3X3pIb1lQUThMcmpJVktfWQ=https%3A%2F%2Fmail.gnu.org%2Farchive%2Fhtml%2Fqemu-devel%2F2021-02%2Fmsg04235.html)
With improvements: - Get rid of ANGLE as EGL libraries. Virgil 3D solely uses
OpenGL Core backend through SDL2 which wraps to NSOpenGL. - No patch to "cocoa"
display of QEMU. Minimal modification to SDL2 display to support Virgil 3D on
macOS. QEMU cannot have both "cocoa" and "sdl2" display in the same build. -
Minimal change to libepoxy and virglrenderer, basically only have to make sure
they built without libdrm and libEGL. - Fix known issues with OpenGL Core -
Performance comparable to ANGLE OpenGL ES backend. WebGL Aquarium at 60 FPS.
Chromium web rendering is accelerated. The accelerated ArchLinux ARM is very
snappy & usable with Apple HVF virtualization. It matches or even exceeds the
performance of typical ARM Linux flavors running on RK3399 or RPi4 bare-metal.
It probably makes M1 MacBooks the world fastest (... most expensive) Linux ARM
laptops. Nested VM is possible, and there is a demo of qemu-3dfx Glide
passthrough from nested QEMU i386 instance running Blood 1.2 3Dfx DOS game.

1 2 3 4 5 6 7 8 >

1 - 100 of 769 matches

Mail list logo