diff options
Diffstat (limited to 'gitlab/issues_text/target_i386/host_missing/accel_HVF')
7 files changed, 200 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067 new file mode 100644 index 000000000..fd91c3be1 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1067 @@ -0,0 +1,84 @@ +SSH QEMU ISSUE by using with MacOs +Description of problem: +ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes +Steps to reproduce: +1. Take the Qemu window and external ssh connection to backround, \ + wait until few minutes and the connection are frozen. \ + If we clicking to qemu window again, the ssh connection are available +Additional information: +The ssh connection settings by Macos: \ +Host * \ +AddKeysToAgent yes \ +IdentityFile ~/.ssh/id_rsa \ +IdentitiesOnly yes \ +ServerAliveInterval 3600 \ +TCPKeepAlive yes \ +ServerAliveCountMax 2 \ +\ +\ +SSH connection settings by Ubuntu Server: + +Include /etc/ssh/sshd_config.d/*.conf \ +\ +#Port 22 \ +#AddressFamily any \ +#ListenAddress 0.0.0.0 \ +#ListenAddress :: \ +#HostKey /etc/ssh/ssh_host_rsa_key \ +#HostKey /etc/ssh/ssh_host_ecdsa_key \ +#HostKey /etc/ssh/ssh_host_ed25519_key \ +#RekeyLimit default none \ +#SyslogFacility AUTH \ +#LogLevel INFO \ +#LoginGraceTime 2m \ +#PermitRootLogin prohibit-password \ +#StrictModes yes \ +#MaxAuthTries 6 \ +#MaxSessions 10 \ +#PubkeyAuthentication yes \ +#Expect .ssh/authorized_keys2 to be disregarded by default in future. \ +#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 \ +#AuthorizedPrincipalsFile none \ +#AuthorizedKeysCommand none \ +#AuthorizedKeysCommandUser nobody \ +#HostbasedAuthentication no \ +#IgnoreUserKnownHosts no \ +#IgnoreRhosts yes \ +#PasswordAuthentication yes \ +#PermitEmptyPasswords no \ +ChallengeResponseAuthentication no \ +#KerberosAuthentication no \ +#KerberosOrLocalPasswd yes \ +#KerberosTicketCleanup yes \ +#KerberosGetAFSToken no \ +#GSSAPIAuthentication no \ +#GSSAPICleanupCredentials yes \ +#GSSAPIStrictAcceptorCheck yes \ +#GSSAPIKeyExchange no \ +UsePAM yes \ +#AllowAgentForwarding yes \ +#AllowTcpForwarding yes \ +#GatewayPorts no \ +X11Forwarding yes \ +#X11DisplayOffset 10 \ +#X11UseLocalhost yes \ +#PermitTTY yes \ +PrintMotd no \ +#PrintLastLog yes \ +#TCPKeepAlive yes \ +#PermitUserEnvironment no \ +#Compression delayed \ +#ClientAliveInterval 0 \ +#ClientAliveCountMax 3 \ +#UseDNS no \ +#PidFile /var/run/sshd.pid \ +#MaxStartups 10:30:100 \ +#PermitTunnel no \ +#ChrootDirectory none \ +#VersionAddendum none \ +#Banner none \ +AcceptEnv LANG LC_* \ +PasswordAuthentication yes \ +ClientAliveInterval 600 \ +TCPKeepAlive yes \ +ClientAliveCountMax 10 \ diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/150 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/150 new file mode 100644 index 000000000..dbbe08265 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/150 @@ -0,0 +1 @@ +Illegal Instruction with HVF when encountering SSE instructions in the emulator diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/155 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/155 new file mode 100644 index 000000000..8471bf984 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/155 @@ -0,0 +1 @@ +MMX emulation is missing on HVF Acceleration diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603 new file mode 100644 index 000000000..be6410412 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/1603 @@ -0,0 +1,73 @@ +Regression in v8.0.0-rc1: `Abort trap: 6` during `hvf/x86_emu.c:exec_mov()` (`-cpu host` + UEFI) +Description of problem: +`qemu-system-x86_64 -accel hvf -cpu host -drive <UEFI>` crashes. +Steps to reproduce: +```console +$ qemu-system-x86_64 -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Abort trap: 6 +``` +Additional information: +This is a regression in v8.0.0-rc1. + +- v8.0.0-rc0: works +- v8.0.0-rc1: crashes +- ... +- v8.0.0-rc4: crashes + + +Backtrace: +```console +$ lldb /usr/local/bin/qemu-system-x86_64 +(lldb) target create "/usr/local/bin/qemu-system-x86_64" +Current executable set to '/usr/local/bin/qemu-system-x86_64' (x86_64). +(lldb) process handle SIGUSR2 -s false -p true +NAME PASS STOP NOTIFY +=========== ======= ======= ======= +SIGUSR2 true false not set +(lldb) run -accel hvf -cpu host -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-x86_64-code.fd +Process 17627 launched: '/usr/local/bin/qemu-system-x86_64' (x86_64) +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +Process 17627 stopped and restarted: thread 1 received signal: SIGUSR2 +2023-04-14 17:16:22.879194+0900 qemu-system-x86_64[17627:1529741] [Window] Warning: Window NSWindow 0x10391def0 ordered front from a non-active application and may order beneath the active application's windows. +vmx_read_mem: mmu_gva_to_gpa ffc00000 failed +Process 17627 stopped +* thread #4, stop reason = signal SIGABRT + frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 +libsystem_kernel.dylib`: +-> 0x7ff8121331f2 <+10>: jae 0x7ff8121331fc ; <+20> + 0x7ff8121331f4 <+12>: movq %rax, %rdi + 0x7ff8121331f7 <+15>: jmp 0x7ff81212ccdb ; cerror_nocancel + 0x7ff8121331fc <+20>: retq +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #4, stop reason = signal SIGABRT + * frame #0: 0x00007ff8121331f2 libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007ff81216aee6 libsystem_pthread.dylib`pthread_kill + 263 + frame #2: 0x00007ff812091b45 libsystem_c.dylib`abort + 123 + frame #3: 0x0000000100223608 qemu-system-x86_64`vmx_read_mem + 201 + frame #4: 0x000000010021fa5b qemu-system-x86_64`read_val_ext + 65 + frame #5: 0x000000010021fc02 qemu-system-x86_64`fetch_operands + 197 + frame #6: 0x0000000100220f8b qemu-system-x86_64`exec_mov + 31 + frame #7: 0x0000000100220f01 qemu-system-x86_64`exec_instruction + 48 + frame #8: 0x000000010021c81f qemu-system-x86_64`hvf_vcpu_exec + 4144 + frame #9: 0x000000010033fa53 qemu-system-x86_64`hvf_cpu_thread_fn + 270 + frame #10: 0x0000000100492e49 qemu-system-x86_64`qemu_thread_start + 130 + frame #11: 0x00007ff81216b1d3 libsystem_pthread.dylib`_pthread_start + 125 + frame #12: 0x00007ff812166bd3 libsystem_pthread.dylib`thread_start + 15 +(lldb) +``` diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938 new file mode 100644 index 000000000..0ffa4769d --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/2938 @@ -0,0 +1,11 @@ +10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2 +Description of problem: +Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine. + +Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up. + +For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3. +Steps to reproduce: +1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2` +Additional information: + diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/664 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/664 new file mode 100644 index 000000000..5f8de9c2f --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/664 @@ -0,0 +1,14 @@ +hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID +Description of problem: +When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors. +Steps to reproduce: +This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines: +``` +[Kernel]: CPU[0]: Physical address bit width: 36 +[Kernel]: CPU[0]: Virtual address bit width: 32 +``` +But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001. +Additional information: +The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values. + +NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information. diff --git a/gitlab/issues_text/target_i386/host_missing/accel_HVF/886 b/gitlab/issues_text/target_i386/host_missing/accel_HVF/886 new file mode 100644 index 000000000..a5fc28406 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_missing/accel_HVF/886 @@ -0,0 +1,16 @@ +OpenIndiana panics when using -accel hvf +Description of problem: +OpenIndiana panics on boot. + +``` +Loading unix... +Loading /platform/i86pc/amd64/boot_archive... +Loading /platform/i86pc/amd64/boot_archive.hash... +Booting... +OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit + +panic[cpu0]/thread=fffffffffbc49060: +``` +Steps to reproduce: +1. Run given command +2. Wait |