Re: Error detecting linker while compiling qemu-system-ppc on macOS
Hello, macOS seems to use '/Library/Frameworks/Python.framework/Versions/3.11/bin/python3' hsp@MacOSVentura qemu-ppc % ./configure --target-list=ppc-softmmu Using './build' as the directory for build output python determined to be '/Library/Frameworks/Python.framework/Versions/3.11/bin/python3' python version: Python 3.11.0 I had both python 3.11 and 3.12 installed through brew. I now removed 3.11. When building with --python=/usr/local/Cellar/python@3.12/3.12.0/bin/python3.12 I get: hsp@MacOSVentura qemu-ppc % ./configure --target-list=ppc-softmmu --python=/usr/local/Cellar/python@3.12/3.12.0/bin/python3.12 Using './build' as the directory for build output python determined to be '/usr/local/Cellar/python@3.12/3.12.0/bin/python3.12' python version: Python 3.12.0 And configure succeeds. On Mon, 6 Nov 2023, Howard Spoelstra wrote: Hi all, I'm getting a error while compiling on macOS (Intel). It seems linker detection is passed an unknown argument "--version", whereas "-v" works OK? See log below. See also https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg10375.html and the tickets listed in there. It should work with meson 1.2.x according to Rene's ticket to Meson and you can install that from homebrew but it seems it's not picked up. Why is it using /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11 ? How many pythons do you8 have on macOS? What does which python tell you and does it work better when you add --python=/path/to/python/that/homebrew/meson/uses ? Regards, BALATON Zoltan
Error detecting linker while compiling qemu-system-ppc on macOS
Hi all, I'm getting a error while compiling on macOS (Intel). It seems linker detection is passed an unknown argument "--version", whereas "-v" works OK? See log below. Thanks for looking into this, Howard Build started at 2023-11-06T07:29:19.181487 Main binary: /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11 Build Options: -Db_pie=false -Ddocs=disabled -Dplugins=true '--native-file config-meson.cross' Python system: Darwin The Meson build system Version: 0.63.3 Source dir: /Users/hsp/src/qemu-ppc Build dir: /Users/hsp/src/qemu-ppc/build Build type: native build Project name: qemu Project version: 8.1.50 - Detecting compiler via: cc -m64 -mcx16 --version compiler returned compiler stdout: Apple clang version 15.0.0 (clang-1500.0.40.1) Target: x86_64-apple-darwin22.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin compiler stderr: Running command: cc -m64 -mcx16 -E -dM - - Detecting linker via: cc -m64 -mcx16 -Wl,--version linker returned linker stdout: linker stderr: ld: unknown options: --version clang: error: linker command failed with exit code 1 (use -v to see invocation) - Detecting Apple linker via: cc -m64 -mcx16 -Wl,-v linker stdout: linker stderr: @(#)PROGRAM:ld PROJECT:dyld-1015.7 BUILD 18:48:43 Aug 22 2023 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3) Library search paths: /usr/local/lib Framework search paths: ld: Undefined symbols: _main, referenced from: clang: error: linker command failed with exit code 1 (use -v to see invocation) ../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64 -mcx16 -Wl,--version` stdout: stderr: ld: unknown options: --version clang: error: linker command failed with exit code 1 (use -v to see invocation)
Re: [PATCH 0/4] target/ppc: Catch invalid real address accesses
On Tue, Jun 27, 2023 at 1:24 PM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 27/06/2023 11:28, Howard Spoelstra wrote: > > > On Tue, Jun 27, 2023 at 10:15 AM Mark Cave-Ayland < > mark.cave-ayl...@ilande.co.uk > > <mailto:mark.cave-ayl...@ilande.co.uk>> wrote: > > > > On 26/06/2023 14:35, Cédric Le Goater wrote: > > > > > On 6/23/23 14:37, Cédric Le Goater wrote: > > >> On 6/23/23 11:10, Peter Maydell wrote: > > >>> On Fri, 23 Jun 2023 at 09:21, Nicholas Piggin < > npig...@gmail.com > > <mailto:npig...@gmail.com>> wrote: > > >>>> > > >>>> ppc has always silently ignored access to real (physical) > addresses > > >>>> with nothing behind it, which can make debugging difficult at > times. > > >>>> > > >>>> It looks like the way to handle this is implement the > transaction > > >>>> failed call, which most target architectures do. Notably not > x86 > > >>>> though, I wonder why? > > >>> > > >>> Much of this is historical legacy. QEMU originally had no > > >>> concept of "the system outside the CPU returns some kind > > >>> of bus error and the CPU raises an exception for it". > > >>> This is turn is (I think) because the x86 PC doesn't do > > >>> that: you always get back some kind of response, I think > > >>> -1 on reads and writes ignored. We added the > do_transaction_failed > > >>> hook largely because we wanted it to give more accurate > > >>> emulation of this kind of thing on Arm, but as usual with new > > >>> facilities we left the other architectures to do it themselves > > >>> if they wanted -- by default the behaviour remained the same. > > >>> Some architectures have picked it up; some haven't. > > >>> > > >>> The main reason it's a bit of a pain to turn the correct > > >>> handling on is because often boards don't actually implement > > >>> all the devices they're supposed to. For a pile of legacy Arm > > >>> boards, especially where we didn't have good test images, > > >>> we use the machine flag ignore_memory_transaction_failures to > > >>> retain the legacy behaviour. (This isn't great because it's > > >>> pretty much going to mean we have that flag set on those > > >>> boards forever because nobody is going to care enough to > > >>> investigate and test.) > > >>> > > >>>> Other question is, sometimes I guess it's nice to avoid > crashing in > > >>>> order to try to quickly get past some unimplemented MMIO. > Maybe a > > >>>> command line option or something could turn it off? It should > > >>>> probably be a QEMU-wide option if so, so that shouldn't hold > this > > >>>> series up, I can propose a option for that if anybody is > worried > > >>>> about it. > > >>> > > >>> I would not recommend going any further than maybe setting the > > >>> ignore_memory_transaction_failures flag for boards you don't > > >>> care about. (But in an ideal world, don't set it and deal with > > >>> any bug reports by implementing stub versions of missing > devices. > > >>> Depends how confident you are in your test coverage.) > > >> > > >> It seems it broke the "mac99" and powernv10 machines, using the > > >> qemu-ppc-boot images which are mostly buildroot. See below for > logs. > > >> > > >> Adding Mark for further testing on Mac OS. > > > > > > > > > Mac OS 9.2 fails to boot with a popup saying : > > > Sorry, a system error occured. > > > "Sound Manager" > > >address error > > > To temporarily turn off extensions, restart and > > > hold down the shift key > > > > > > > > > Darwin and Mac OSX look OK. > > > > My guess would be that MacOS 9.2 is trying to access the sound chip > registers which > > isn't implemente
Re: [PATCH 0/4] target/ppc: Catch invalid real address accesses
On Tue, Jun 27, 2023 at 10:15 AM Mark Cave-Ayland <
mark.cave-ayl...@ilande.co.uk> wrote:
> On 26/06/2023 14:35, Cédric Le Goater wrote:
>
> > On 6/23/23 14:37, Cédric Le Goater wrote:
> >> On 6/23/23 11:10, Peter Maydell wrote:
> >>> On Fri, 23 Jun 2023 at 09:21, Nicholas Piggin
> wrote:
>
> ppc has always silently ignored access to real (physical) addresses
> with nothing behind it, which can make debugging difficult at times.
>
> It looks like the way to handle this is implement the transaction
> failed call, which most target architectures do. Notably not x86
> though, I wonder why?
> >>>
> >>> Much of this is historical legacy. QEMU originally had no
> >>> concept of "the system outside the CPU returns some kind
> >>> of bus error and the CPU raises an exception for it".
> >>> This is turn is (I think) because the x86 PC doesn't do
> >>> that: you always get back some kind of response, I think
> >>> -1 on reads and writes ignored. We added the do_transaction_failed
> >>> hook largely because we wanted it to give more accurate
> >>> emulation of this kind of thing on Arm, but as usual with new
> >>> facilities we left the other architectures to do it themselves
> >>> if they wanted -- by default the behaviour remained the same.
> >>> Some architectures have picked it up; some haven't.
> >>>
> >>> The main reason it's a bit of a pain to turn the correct
> >>> handling on is because often boards don't actually implement
> >>> all the devices they're supposed to. For a pile of legacy Arm
> >>> boards, especially where we didn't have good test images,
> >>> we use the machine flag ignore_memory_transaction_failures to
> >>> retain the legacy behaviour. (This isn't great because it's
> >>> pretty much going to mean we have that flag set on those
> >>> boards forever because nobody is going to care enough to
> >>> investigate and test.)
> >>>
> Other question is, sometimes I guess it's nice to avoid crashing in
> order to try to quickly get past some unimplemented MMIO. Maybe a
> command line option or something could turn it off? It should
> probably be a QEMU-wide option if so, so that shouldn't hold this
> series up, I can propose a option for that if anybody is worried
> about it.
> >>>
> >>> I would not recommend going any further than maybe setting the
> >>> ignore_memory_transaction_failures flag for boards you don't
> >>> care about. (But in an ideal world, don't set it and deal with
> >>> any bug reports by implementing stub versions of missing devices.
> >>> Depends how confident you are in your test coverage.)
> >>
> >> It seems it broke the "mac99" and powernv10 machines, using the
> >> qemu-ppc-boot images which are mostly buildroot. See below for logs.
> >>
> >> Adding Mark for further testing on Mac OS.
> >
> >
> > Mac OS 9.2 fails to boot with a popup saying :
> > Sorry, a system error occured.
> > "Sound Manager"
> >address error
> > To temporarily turn off extensions, restart and
> > hold down the shift key
> >
> >
> > Darwin and Mac OSX look OK.
>
> My guess would be that MacOS 9.2 is trying to access the sound chip
> registers which
> isn't implemented in QEMU for the moment (I have a separate screamer
> branch
> available, but it's not ready for primetime yet). In theory they shouldn't
> be
> accessed at all because the sound device isn't present in the OpenBIOS
> device tree,
> but this is all fairly old stuff.
>
> Does implementing the sound registers using a dummy device help at all?
>
>
My uneducated guess is that you stumbled on a longstanding, but
intermittently occurring, issue specific to Mac OS 9.2 related to sound
support over USB in Apple monitors.
I believe It is not fixed by the patch set from the 23 of june, I still get
system errors when running Mac OS 9.2 with the mac99 machine after applying
them.
Mac OS 9.2 has required mac99,via=pmu for a long time now to always boot
successfully. (while 9.0.4 requires mac99 to boot, due to an undiagnosed
OHCI USB problem with the specific drivers that ship with it.) ;-)
Best,
Howard
>
> diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
> index 265c0bbd8d..e55f938da7 100644
> --- a/hw/misc/macio/macio.c
> +++ b/hw/misc/macio/macio.c
> @@ -26,6 +26,7 @@
> #include "qemu/osdep.h"
> #include "qapi/error.h"
> #include "qemu/module.h"
> +#include "hw/misc/unimp.h"
> #include "hw/misc/macio/cuda.h"
> #include "hw/pci/pci.h"
> #include "hw/ppc/mac_dbdma.h"
> @@ -94,6 +95,7 @@ static bool macio_common_realize(PCIDevice *d, Error
> **errp)
> {
> MacIOState *s = MACIO(d);
> SysBusDevice *sbd;
> +DeviceState *dev;
>
> if (!qdev_realize(DEVICE(>dbdma), BUS(>macio_bus), errp)) {
> return false;
> @@ -102,6 +104,14 @@ static bool macio_common_realize(PCIDevice *d, Error
> **errp)
> memory_region_add_subregion(>bar, 0x08000,
>
Re: source fails to compile on msys2
Yep, fixed No idea how I got that wrong ;-) Best, Howard
Re: source fails to compile on msys2
Hello Peter,
My source was cloned today. I just cloned again and I still see the tokens
reversed:
git clone https://www.gitlab.com/qemu/qemu qemu-master-clean
/**
* qemu_build_not_reached()
*
* The compiler, during optimization, is expected to prove that a call
* to this function cannot be reached and remove it. If the compiler
* supports QEMU_ERROR, this will be reported at compile time; otherwise
* this will be reported at link time due to the missing symbol.
*/
extern G_NORETURN
void QEMU_ERROR("code path is reachable")
qemu_build_not_reached_always(void);
#if defined(__OPTIMIZE__) && !defined(__NO_INLINE__)
#define qemu_build_not_reached() qemu_build_not_reached_always()
#else
#define qemu_build_not_reached() g_assert_not_reached()
#endif
The source on gitlab shows the correct order:
/** * qemu_build_not_reached() * * The compiler, during optimization,
is expected to prove that a call * to this function cannot be reached
and remove it. If the compiler * supports QEMU_ERROR, this will be
reported at compile time; otherwise * this will be reported at link
time due to the missing symbol. */G_NORETURN externvoid
QEMU_ERROR("code path is reachable")
qemu_build_not_reached_always(void);#if defined(__OPTIMIZE__) &&
!defined(__NO_INLINE__)#define qemu_build_not_reached()
qemu_build_not_reached_always()#else#define qemu_build_not_reached()
g_assert_not_reached()#endif
source fails to compile on msys2
Hello, It seems the current source fails to compile with up to date msys2. Source is configured with: ./configure --target-list="ppc-softmmu" --enable-gtk --enable-sdl --enable-slirp FAILED: qga/vss-win32/qga-vss.dll.p/install.cpp.obj "c++" "-m64" "-mcx16" "-Iqga/vss-win32/qga-vss.dll.p" "-Iqga/vss-win32" "-I../qga/vss-win32" "-I." "-Iqapi" "-Itrace" "-Iui" "-Iui/shader" "-IC:/msys64/mingw64/include/glib-2.0" "-IC:/msys64/mingw64/lib/glib-2.0/include" "-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Wnon-virtual-dtor" "-Werror" "-std=gnu++11" "-O2" "-g" "-iquote" "." "-iquote" "C:/msys64/home/hsp/src/qemu-master-clean" "-iquote" "C:/msys64/home/hsp/src/qemu-master-clean/include" "-iquote" "C:/msys64/home/hsp/src/qemu-master-clean/tcg/i386" "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-U_FORTIFY_SOURCE" "-D_FORTIFY_SOURCE=2" "-fno-pie" "-no-pie" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-Wundef" "-Wwrite-strings" "-Wtype-limits" "-Wformat-security" "-Wformat-y2k" "-Winit-self" "-Wignored-qualifiers" "-Wempty-body" "-Wendif-labels" "-Wexpansion-to-defined" "-Wimplicit-fallthrough=2" "-Wmissing-format-attribute" "-Wno-missing-include-dirs" "-Wno-shift-negative-value" "-Wno-psabi" "-fstack-protector-strong" "-Wno-unknown-pragmas" "-Wno-delete-non-virtual-dtor" "-Wno-non-virtual-dtor" -MD -MQ qga/vss-win32/qga-vss.dll.p/install.cpp.obj -MF "qga/vss-win32/qga-vss.dll.p/install.cpp.obj.d" -o qga/vss-win32/qga-vss.dll.p/install.cpp.obj "-c" ../qga/vss-win32/install.cpp In file included from C:/msys64/mingw64/lib/glib-2.0/include/glibconfig.h:9, from C:/msys64/mingw64/include/glib-2.0/glib/gtypes.h:34, from C:/msys64/mingw64/include/glib-2.0/glib/galloca.h:34, from C:/msys64/mingw64/include/glib-2.0/glib.h:32, from C:/msys64/home/hsp/src/qemu-master-clean/include/glib-compat.h:32, from C:/msys64/home/hsp/src/qemu-master-clean/include/qemu/osdep.h:144, from ../qga/vss-win32/install.cpp:13: C:/msys64/mingw64/include/glib-2.0/glib/gmacros.h:1076:21: error: standard attributes in middle of decl-specifiers 1076 | # define G_NORETURN [[noreturn]] | ^ C:/msys64/home/hsp/src/qemu-master-clean/include/qemu/osdep.h:240:8: note: in expansion of macro 'G_NORETURN' 240 | extern G_NORETURN |^~ C:/msys64/mingw64/include/glib-2.0/glib/gmacros.h:1076:21: note: standard attributes must precede the decl-specifiers to apply to the declaration, or follow them to apply to the type 1076 | # define G_NORETURN [[noreturn]] | ^ C:/msys64/home/hsp/src/qemu-master-clean/include/qemu/osdep.h:240:8: note: in expansion of macro 'G_NORETURN' 240 | extern G_NORETURN |^~ C:/msys64/mingw64/include/glib-2.0/glib/gmacros.h:1076:21: error: attribute ignored [-Werror=attributes] 1076 | # define G_NORETURN [[noreturn]] | ^ C:/msys64/home/hsp/src/qemu-master-clean/include/qemu/osdep.h:240:8: note: in expansion of macro 'G_NORETURN' 240 | extern G_NORETURN |^~ C:/msys64/mingw64/include/glib-2.0/glib/gmacros.h:1076:21: note: an attribute that appertains to a type-specifier is ignored 1076 | # define G_NORETURN [[noreturn]] | ^ C:/msys64/home/hsp/src/qemu-master-clean/include/qemu/osdep.h:240:8: note: in expansion of macro 'G_NORETURN' 240 | extern G_NORETURN |^~ cc1plus.exe: all warnings being treated as errors Best, Howard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan wrote: > On Fri, 27 Jan 2023, BALATON Zoltan wrote: > > On Thu, 26 Jan 2023, Howard Spoelstra wrote: > >> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan > wrote: > >>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: > >>>> Mac OS X > >>>> #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to > adb > >>>> mouse. No recognition as HID device. > >>>> #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that > point > >>> kbd > >>>> pcap shows normal interrupt operation and recognition as HID device > >>>> #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that > point > >>> kbd > >>>> pcap shows normal interrupt operation and recognition as HID device > >>>> #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to > adb > >>>> mouse. pcap shows no recognition as HID device. > >>>> #10.0 in both cases apple system profiler shows 2 usb buses but no > >>> devices. > >>> > >>> These are all the logs I get booting a 10.0 install iso with > >>> mac99,via=pmu > >>> > >>>>> = > >>>>> OpenBIOS 1.1 [May 25 2022 20:04] > >>>>> Configuration device id QEMU version 1 machine id 1 > >>>>> CPUs: 1 > >>>>> Memory: 256M > >>>>> UUID: ---- > >>>>> CPU type PowerPC,G4 > >>> milliseconds isn't unique. > >>>>> switching to new context: > >>>>> call-method slw_update_keymap failed with error ffdf > >>>>> call-method slw_update_keymap failed with error ffdf > >>> usb_ohci_reset pci-ohci > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_set_ctl pci-ohci: new state 0x0 > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_port_detach port #0 > >>> usb_ohci_port_attach port #0 > >>> usb_ohci_port_detach port #1 > >>> usb_ohci_port_attach port #1 > >>> dbdma_unassigned_flush: use of unassigned channel 0 > >>> dbdma_unassigned_flush: use of unassigned channel 0 > >>> usb_ohci_mem_write_bad_offset 0x30 > >>> usb_ohci_set_ctl pci-ohci: new state 0x80 > >>> usb_ohci_start pci-ohci: USB Operational > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_set_ctl pci-ohci: new state 0xc0 > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_port_reset port #0 > >>> > >>> It's probably OK until it restarts but the seems to be stopped. Anybody > >>> wants to have a look? Maybe start with finding what the states mean. > >>> > >>> > >> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS > >> 9.0.4: > >> > >> usb_ohci_set_ctl pci-ohci: new state 0x80 > >> usb_ohci_start pci-ohci: USB Operational > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_port_reset port #0 > >> usb_ohci_port_reset port #0 > >> > >> So both usb mouse and kbd do not work. > >> > >> the pcap file for the mouse stalls here: > >> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response > > > > Maybe the driver gets something from the emulated HID device that it > cannot > > handle and stops during init? Can you reproduce the same with OS X 10.0 > and > > try to correlate the events you see in pcap and trace with the driver > source > > or find out how to enable and read the messages in the driver (unless > these > > are stripped from the binary in Mac OS X but maybe there's something in > the > > guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are > > implemented in hw/usb/dev-hid.c but this file does not have any debuging > or > > traces. You might try to add some printfs for testing. > > > >> However, when I use the usb probe tool
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan wrote: > On Thu, 26 Jan 2023, Howard Spoelstra wrote: > > Mac OS X > > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb > > mouse. No recognition as HID device. > > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point > kbd > > pcap shows normal interrupt operation and recognition as HID device > > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point > kbd > > pcap shows normal interrupt operation and recognition as HID device > > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb > > mouse. pcap shows no recognition as HID device. > > #10.0 in both cases apple system profiler shows 2 usb buses but no > devices. > > These are all the logs I get booting a 10.0 install iso with mac99,via=pmu > > >> = > >> OpenBIOS 1.1 [May 25 2022 20:04] > >> Configuration device id QEMU version 1 machine id 1 > >> CPUs: 1 > >> Memory: 256M > >> UUID: ---- > >> CPU type PowerPC,G4 > milliseconds isn't unique. > >> switching to new context: > >> call-method slw_update_keymap failed with error ffdf > >> call-method slw_update_keymap failed with error ffdf > usb_ohci_reset pci-ohci > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_set_ctl pci-ohci: new state 0x0 > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_port_detach port #0 > usb_ohci_port_attach port #0 > usb_ohci_port_detach port #1 > usb_ohci_port_attach port #1 > dbdma_unassigned_flush: use of unassigned channel 0 > dbdma_unassigned_flush: use of unassigned channel 0 > usb_ohci_mem_write_bad_offset 0x30 > usb_ohci_set_ctl pci-ohci: new state 0x80 > usb_ohci_start pci-ohci: USB Operational > usb_ohci_hub_power_up powered up all ports > usb_ohci_hub_power_up powered up all ports > usb_ohci_set_ctl pci-ohci: new state 0xc0 > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_hub_power_up powered up all ports > usb_ohci_hub_power_up powered up all ports > usb_ohci_port_reset port #0 > > It's probably OK until it restarts but the seems to be stopped. Anybody > wants to have a look? Maybe start with finding what the states mean. > > I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4: usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 So both usb mouse and kbd do not work. the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response However, when I use the usb probe tool from the USB DDK, to probe the buses I see the host emit a get descriptor 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host starts polling it and mouse and kbd start to work. Best, Howard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 4:33 PM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan > wrote: > >> I thought MacOS 8 needed old world ROM but looks like it can also load > it > >> from disk on new world machines. Then what version of the ROM it has? > >> It seems there was some change at ROM 5.2.1 then which solves the > problem > >> with usb and older versions may have done something differently and > >> expect it to work unlike it's emulated now. > >> > >> The rom on the 8.6 Cd is version > > The disk utility on the CD cannot initialise a hard disk (something we > had > > with some 9.0.4 versions too) > > This sentence seems to be unfinished, also the disk utility problem is > maybe unrelated so just ignore that for now and focus on usb first. > > >> So it seems versions before 10.2 have a problem (except 9,1 and 9.2 > which > >> may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I > assume > >> later 9.x versions have at least this or newer Toolbox ROM) I think it's > >> esasier to debug with OS X because it's easier to get logs and the > drivers > >> may also be open source so easier to check what's happening so let's > just > >> forget about MacOS9 for now and try to find out what changed between > 10.1 > >> and 10.2 in usb handling. > >> > >>> It seems via=pmu provides usb mouse first, usb kbd second. > >>> With Mac OS 9.0.4 the second device will not work. > >>> With 10.0 / 10.1 both usb mouse and kbd do not work. > >> > >> These are added here: > >> > >> > >> > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 > >> > >> you could change the order but it does not matter if both needs to work. > >> If it makes the first one work then maybe the older USB drivers only > >> handle one port per bus? But then the problem in OS X may be different. > >> > >>> Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by > >> default I > >>> only see one bus: USB 0 into which both mouse and kdb are plugged. > >>> On the real G4 the mouse and kbd are each plugged into another bus, so > I > >>> see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. > >>> > >>> With -M mac99,via=cuda one USB bus is always created. It has id > "usb-bus" > >>> We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this > is > >>> the Apple USB controller). > >>> > >>> Then add mouse and kbd to different buses with: > >>> -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) > >>> -device usb-kbd,bus=usb1.0 (attaches to second bus). > >>> > >>> This then mimics what I see on real hardware. Should qemu-system-ppc by > >>> default provide the same? > >> > >> Does this solve the problem you have? > > > > > > No. > > OK so then we should not do that by default either unless we find it's > needed for some reason. > > >> (You talk about via=cude above but I > >> think it should be via=pmu. Is that a typo?) > > > > > > No, even with via-cuda the first usb bus is created: > > dev: pci-ohci, id "" > >masterbus = "" > >num-ports = 3 (0x3) > >firstport = 0 (0x0) > >addr = 0d.0 > >romfile = "" > >romsize = 4294967295 (0x) > >rombar = 1 (0x1) > >multifunction = false > >x-pcie-lnksta-dllla = true > >x-pcie-extcap-init = true > >failover_pair_id = "" > >acpi-index = 0 (0x0) > >class USB controller, addr 00:0d.0, pci id 106b:003f (sub > 1af4:1100) > >bar 0: mem at 0x8008 [0x800800ff] > >bus: usb-bus.0 > > type usb-bus > > > > I now think in some cases the mouse falls back to adb when usb does not > > work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to > the > > desktop. > > Can we disable usb-bus creation for via=cuda? > > Yes, try: > > qemu-system-ppc -M mac99,usb=no > > (I had to look at the code to find that out). > > > If this helps mac_newworld.c > >> could add another usb bus or do somerthing different to match real > >> hardware but you have to convince Mark about that first... Also Mac > >> keyboard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan > wrote: > >> On Tue, 24 Jan 2023, Howard Spoelstra wrote: > >>> From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 > due > >> to > >>> the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would > be > >>> that these suffer the same usb issue) > >>> The real powermac3,1 AGP has no adb. > >> > >> And do these OSes run on real PowerMac3,1? If so then we likely have a > bug > >> in USB emulation so maybe that could be fixed? In any case my patch does > >> not change mac99 and this should continue to work. > >> > >>> via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly > only > >>> needed for Mac OS X 10.5 guest (for which the speed reported was hacked > >> to > >>> 900Mhz to fool the installer), but should support all Mac OS/OS X that > >> are > >>> now supported. > >> > >> Since via=pmu is what should be a real machine does it run OS X >=10.2 > >> already? > >> > > > > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 > > > > qemu-system-ppc status: > > 8.6 will not boot from CD or HD. > > 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 > > usb device problem > > 9.1 and 9.2 with via=pmu > > 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also > with > > an usb problem) > > 10.2 with via=pmu (but has serious graphics speed problem, also with > > via=cuda) > > 10.3 and 10.4 with via=pmu > > 10.5 only with via=pmu (but needs the 900Mhz speed hack). > > > > *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. > > I thought MacOS 8 needed old world ROM but looks like it can also load it > from disk on new world machines. Then what version of the ROM it has? > It seems there was some change at ROM 5.2.1 then which solves the problem > with usb and older versions may have done something differently and > expect it to work unlike it's emulated now. > > The rom on the 8.6 Cd is version The disk utility on the CD cannot initialise a hard disk (something we had with some 9.0.4 versions too) > So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which > may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume > later 9.x versions have at least this or newer Toolbox ROM) I think it's > esasier to debug with OS X because it's easier to get logs and the drivers > may also be open source so easier to check what's happening so let's just > forget about MacOS9 for now and try to find out what changed between 10.1 > and 10.2 in usb handling. > > > It seems via=pmu provides usb mouse first, usb kbd second. > > With Mac OS 9.0.4 the second device will not work. > > With 10.0 / 10.1 both usb mouse and kbd do not work. > > These are added here: > > > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 > > you could change the order but it does not matter if both needs to work. > If it makes the first one work then maybe the older USB drivers only > handle one port per bus? But then the problem in OS X may be different. > > > Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by > default I > > only see one bus: USB 0 into which both mouse and kdb are plugged. > > On the real G4 the mouse and kbd are each plugged into another bus, so I > > see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. > > > > With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" > > We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is > > the Apple USB controller). > > > > Then add mouse and kbd to different buses with: > > -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) > > -device usb-kbd,bus=usb1.0 (attaches to second bus). > > > > This then mimics what I see on real hardware. Should qemu-system-ppc by > > default provide the same? > > Does this solve the problem you have? No. > (You talk about via=cude above but I > think it should be via=pmu. Is that a typo?) No, even with via-cuda the first usb bus is created: dev: pci-ohci, id "" masterbus = "" num-ports = 3 (0x3) firstport = 0 (0x0) addr = 0d.0 romfile = "" romsize = 4294967295 (0x) rombar = 1 (0x1) multifunction = false x-pcie-lnksta-dllla = t
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due > to > > the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be > > that these suffer the same usb issue) > > The real powermac3,1 AGP has no adb. > > And do these OSes run on real PowerMac3,1? If so then we likely have a bug > in USB emulation so maybe that could be fixed? In any case my patch does > not change mac99 and this should continue to work. > > > via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only > > needed for Mac OS X 10.5 guest (for which the speed reported was hacked > to > > 900Mhz to fool the installer), but should support all Mac OS/OS X that > are > > now supported. > > Since via=pmu is what should be a real machine does it run OS X >=10.2 > already? > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 qemu-system-ppc status: 8.6 will not boot from CD or HD. 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 usb device problem 9.1 and 9.2 with via=pmu 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with an usb problem) 10.2 with via=pmu (but has serious graphics speed problem, also with via=cuda) 10.3 and 10.4 with via=pmu 10.5 only with via=pmu (but needs the 900Mhz speed hack). *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. It seems via=pmu provides usb mouse first, usb kbd second. With Mac OS 9.0.4 the second device will not work. With 10.0 / 10.1 both usb mouse and kbd do not work. Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I only see one bus: USB 0 into which both mouse and kdb are plugged. On the real G4 the mouse and kbd are each plugged into another bus, so I see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is the Apple USB controller). Then add mouse and kbd to different buses with: -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) -device usb-kbd,bus=usb1.0 (attaches to second bus). This then mimics what I see on real hardware. Should qemu-system-ppc by default provide the same? > > via=pmu-adb seems only needed to trick mac os server installations that > > would later run on the g3beige. > > > > To my knowledge 32 bit Linux guests all require via=pmu > > See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC > > That doc might need some updating. It seems to be from before pegasos2 was > added. Maybe we would be better off linking from this page to others that > are more actively maintained such as: > https://www.emaculation.com/doku.php/qemu > and > http://zero.eik.bme.hu/~balaton/qemu/amiga/ > > I "maintain" that page with only general information. I can link to the specific sites you mention. > or even better updating the main docs in > > https://www.qemu.org/docs/master/system/ppc/powermac.html > > That would have to be taken up by someone else. Best, Howard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Mon, Jan 23, 2023 at 11:06 PM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 22/01/2023 22:07, BALATON Zoltan wrote: > > > On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: > >> On 12/01/2023 23:51, BALATON Zoltan wrote: > >>> On Thu, 12 Jan 2023, Howard Spoelstra wrote: > >>>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan > wrote: > >>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>>>>>> Setting emulated machine type with a property called "via" is > >>>>>>> confusing users so deprecate the "via" option in favour of newly > added > >>>>>>> explicit machine types. The default via=cuda option is not a valid > >>>>>>> config (no real Mac has this combination of hardware) so no machine > >>>>>>> type could be defined for that therefore it is kept for backwards > >>>>>>> compatibility with older QEMU versions for now but other options > >>>>>>> resembling real machines are deprecated. > >>>>>>> > >>>>>>> Signed-off-by: BALATON Zoltan > >>>>>> > >>>>>> I believe that people do use -M mac99,via=cuda to run some rare > versions > >>>>> of > >>>>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so > we > >>>>> would > >>>>>> want to keep this option somewhere. > >>>>> > >>>>> The idea is that after previous patches we now have machine types > for all > >>>>> other via option values (that also match real Mac machines) other > than > >>>>> via=cude but that is the default for mac99 so after the reprecation > period > >>>>> when the via option is removed mac99 (which is the same as > mac99,via=cuda) > >>>>> can remain for this use case (and for backward compatibility) until > the > >>>>> other machines are fixed to not need this any more. So all via > options are > >>>>> still available but as different machine types. > >>>>> > >>>> My 2 cents about naming: > >>>> It seems less important how the machines are named when their name is > not > >>>> covering their definition. F.i. the powermac3,1 never had adb, could > not be > >>>> equipped with a G3 cpu, did not run at 900Mhz. The closest possible > >>>> qemu-options based definition of a powermac3,1 (via=pmu) will not run > Mac > >>>> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > >>>> already needed. > >>> > >>> What does that mean? Should we aim to emulate real Macs or are we > happy with the > >>> Franken-Mac we have now? The names also show what we intend to emulate > even though > >>> the emulation may not be complete or have bugs (this is also true for > other > >>> machines in QEMU where a lot of them are not fully emulated, only well > enough to > >>> boot guest OSes). > >>> > >>> Looks like everybody has forgotten the previous discussion and not > read the docs > >>> and deprecation patches where this is explained so I summarise the > proposed change > >>> here again: > >>> > >>> - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for > >>> the via option and when using it in qemu-system-ppc64 suggesting using > new > >>> machines instead so these could evetually be removed next year. > mac99,via=cuda is > >>> just mac99 so you can continue to use that, mac99 is not deprecated > and don't want > >>> to remove it. > >>> > >>> - qemu-system-ppc64 -M mac99 -> powermac7_3 > >>> > >>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > >>> > >>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > FWIW this information would be useful in the cover letter once we decide > the way > forward. Also as a reviewer, it is hard to keep track of all the changes > if the > series are constantly changing and with no changelog on the cover letter, > which is > why it takes me a while to review them. > > >>> The last one is one of the rare Macs that had adb and pmu, all others > with pmu > >>> usually have USB. The PowerMac1,2 (G4 PCI) h
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan wrote: > On Thu, 12 Jan 2023, Howard Spoelstra wrote: > > On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan > wrote: > > > >> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >>> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>> > >>>> Setting emulated machine type with a property called "via" is > >>>> confusing users so deprecate the "via" option in favour of newly added > >>>> explicit machine types. The default via=cuda option is not a valid > >>>> config (no real Mac has this combination of hardware) so no machine > >>>> type could be defined for that therefore it is kept for backwards > >>>> compatibility with older QEMU versions for now but other options > >>>> resembling real machines are deprecated. > >>>> > >>>> Signed-off-by: BALATON Zoltan > >>> > >>> I believe that people do use -M mac99,via=cuda to run some rare > versions > >> of > >>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we > >> would > >>> want to keep this option somewhere. > >> > >> The idea is that after previous patches we now have machine types for > all > >> other via option values (that also match real Mac machines) other than > >> via=cude but that is the default for mac99 so after the reprecation > period > >> when the via option is removed mac99 (which is the same as > mac99,via=cuda) > >> can remain for this use case (and for backward compatibility) until the > >> other machines are fixed to not need this any more. So all via options > are > >> still available but as different machine types. > >> > > My 2 cents about naming: > > It seems less important how the machines are named when their name is not > > covering their definition. F.i. the powermac3,1 never had adb, could not > be > > equipped with a G3 cpu, did not run at 900Mhz. The closest possible > > qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac > > OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > > already needed. > > What does that mean? Should we aim to emulate real Macs or are we happy > with the Franken-Mac we have now? > The names also show what we intend to > emulate even though the emulation may not be complete or have bugs (this > is also true for other machines in QEMU where a lot of them are not fully > emulated, only well enough to boot guest OSes). > > Looks like everybody has forgotten the previous discussion and not read > the docs and deprecation patches where this is explained so I summarise > the proposed change here again: > > No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I personally do not oppose a name change, the new names seem more descriptive. I tested your patches and they behave as they should. The functionality does not change. However, my simple point was what's in a name when the underlying machine does not reflect what the name implies. It is not my place to comment on a possible development agenda. I can only tell you what I'd like and point out issues. > - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for the via option and when using it in qemu-system-ppc64 suggesting > using new machines instead so these could evetually be removed next year. > mac99,via=cuda is just mac99 so you can continue to use that, mac99 is > not deprecated and don't want to remove it. > > - qemu-system-ppc64 -M mac99 -> powermac7_3 > > - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > > - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > The last one is one of the rare Macs that had adb and pmu, all others with > pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 > hardware but more similar to g3beige and no ADB ports according to > https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > > The PowerMac7,3 seems to be matching the PCI device listing in the comment > at the beginning of mac_newworld.c and also this article: > https://www.informit.com/articles/article.aspx?p=606582 > > What is the 2 USB devices problem? Is it the one we've debugged before and > found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? > That could be fixed if there was somebody interested enough to provide a > patch. > It is not about passing through USB devices and active packets per endpoint. The powermac3,1 has two
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote:
> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> > On 04/01/2023 21:59, BALATON Zoltan wrote:
> >
> >> Setting emulated machine type with a property called "via" is
> >> confusing users so deprecate the "via" option in favour of newly added
> >> explicit machine types. The default via=cuda option is not a valid
> >> config (no real Mac has this combination of hardware) so no machine
> >> type could be defined for that therefore it is kept for backwards
> >> compatibility with older QEMU versions for now but other options
> >> resembling real machines are deprecated.
> >>
> >> Signed-off-by: BALATON Zoltan
> >
> > I believe that people do use -M mac99,via=cuda to run some rare versions
> of
> > MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we
> would
> > want to keep this option somewhere.
>
> The idea is that after previous patches we now have machine types for all
> other via option values (that also match real Mac machines) other than
> via=cude but that is the default for mac99 so after the reprecation period
> when the via option is removed mac99 (which is the same as mac99,via=cuda)
> can remain for this use case (and for backward compatibility) until the
> other machines are fixed to not need this any more. So all via options are
> still available but as different machine types.
>
>
My 2 cents about naming:
It seems less important how the machines are named when their name is not
covering their definition. F.i. the powermac3,1 never had adb, could not be
equipped with a G3 cpu, did not run at 900Mhz. The closest possible
qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac
OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is
already needed.
>
> >> ---
> >> hw/ppc/mac_newworld.c | 9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> >> index f07c37328b..adf185bd3a 100644
> >> --- a/hw/ppc/mac_newworld.c
> >> +++ b/hw/ppc/mac_newworld.c
> >> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
> >> if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> >> warn_report("mac99 with G5 CPU is deprecated, "
> >> "use powermac7_3 instead");
> >> +} else {
> >> +if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> >> +warn_report("mac99,via=pmu is deprecated, "
> >> +"use powermac3_1 instead");
> >> +}
> >> +if (core99_machine->via_config ==
> CORE99_VIA_CONFIG_PMU_ADB) {
> >> +warn_report("mac99,via=pmu-adb is deprecated, "
> >> +"use powerbook3_2 instead");
> >> +}
> >> }
> >> }
> >> /* allocate RAM */
> >
> >
> > ATB,
> >
> > Mark.
> >
> >
>
>
Re: [PATCH v4 00/19] Misc ppc/mac machines clean up
On Tue, Oct 25, 2022 at 6:49 PM BALATON Zoltan wrote:
> Since only one week is left until freeze starts I've included some
> more patches in this version that I've intended to submit after the
> clean ups but we're running out of time now. The last 3 patches could
> be squashed together, I've just split these up because I expect
> resistence from Mark to any changes so maybe it's easier to digest
> piece by piece and can cherry pick parts easier this way but ideally
> these should be in one patch.
>
> I'd appreciate very much if this series would get in before the
> freeze, it is very discouraging to spend time with something that gets
> ignored and then postponed for the rest of the year just to start
> again the same in January. This might be a reason why not many people
> contribute to this part of QEMU besides that maybe only a few people
> are still interested so those who are interested should be served
> better to not scare them off even more.
>
> Regards,
> BALATON Zoltan
>
> v4: Add some more patches that I've found since v3 or was intended in
> separate series
> v3: Some more patch spliting and changes I've noticed and address more
> review comments
> v2: Split some patches and add a few more I've noticed now and address
> review comments
>
> BALATON Zoltan (19):
> mac_newworld: Drop some variables
> mac_oldworld: Drop some more variables
> mac_{old|new}world: Set tbfreq at declaration
> mac_{old|new}world: Avoid else branch by setting default value
> mac_{old|new}world: Simplify cmdline_base calculation
> mac_newworld: Clean up creation of Uninorth devices
> mac_{old|new}world: Reduce number of QOM casts
> hw/ppc/mac.h: Move newworld specific parts out from shared header
> hw/ppc/mac.h: Move macio specific parts out from shared header
> hw/ppc/mac.h: Move grackle-pcihost type declaration out to a header
> hw/ppc/mac.h: Move PROM and KERNEL defines to board code
> hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.h
> mac_nvram: Use NVRAM_SIZE constant
> mac_{old|new}world: Code style fix adding missing braces to if-s
> mac_newworld: Turn CORE99_VIA_CONFIG defines into an enum
> mac_newworld: Add machine types for different mac99 configs
> mac_newworld: Deprecate mac99 with G5 CPU
> mac_newworld: Deprecate mac99 "via" option
> mac_newworld: Document deprecation
>
> MAINTAINERS | 2 +
> docs/about/deprecated.rst | 7 +
> docs/system/ppc/powermac.rst | 12 +-
> hw/ide/macio.c| 1 -
> hw/intc/heathrow_pic.c| 1 -
> hw/intc/openpic.c | 1 -
> hw/misc/macio/cuda.c | 1 -
> hw/misc/macio/gpio.c | 1 -
> hw/misc/macio/macio.c | 8 +-
> hw/misc/macio/pmu.c | 1 -
> hw/nvram/mac_nvram.c | 2 +-
> hw/pci-host/grackle.c | 15 +-
> hw/pci-host/uninorth.c| 1 -
> hw/ppc/mac.h | 105 ---
> hw/ppc/mac_newworld.c | 341 ++
> hw/ppc/mac_oldworld.c | 120 ++--
> include/hw/misc/macio/macio.h | 23 ++-
> include/hw/nvram/mac_nvram.h | 51 +
> include/hw/pci-host/grackle.h | 44 +
> 19 files changed, 415 insertions(+), 322 deletions(-)
> delete mode 100644 hw/ppc/mac.h
> create mode 100644 include/hw/nvram/mac_nvram.h
> create mode 100644 include/hw/pci-host/grackle.h
>
> --
> 2.30.4
>
>
>
Hi all,
I applied these patches and they seem to work as expected. I like the way
this makes it clearer which machine is actually emulated, even though it is
still not easy to understand which default hardware the emulated machine
actually presents.
I also like the more consistent way a new rom file for a VGA device can be
added. The deprecation warnings are clear.
Qemu-system-ppc defaults to the g3beige machine, which does not reflect the
(in my opinion) main use case of running Mac OS/X with the powermac3_1
machine and will not boot the main versions of ppc Mac OS/X anyway.
So for qemu-system-ppc:
Tested-by: Howard Spoelstra
Best,
Howard
Re: [PATCH 0/2] target/m68k: fix two writes to %sr
On Tue, Sep 13, 2022 at 6:29 PM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 13/09/2022 15:28, Richard Henderson wrote: > > > The second was described by Mark in the lobby of KVM Forum. > > The first was found by inspection of other uses of gen_helper_set_sr. > > > > r~ > > > > Richard Henderson (2): > >target/m68k: Fix MACSR to CCR > >target/m68k: Perform writback before modifying SR > > > > target/m68k/translate.c | 14 +- > > 1 file changed, 9 insertions(+), 5 deletions(-) > > I've applied these on top of my MacOS virtual memory branch at > https://github.com/mcayland/qemu/commits/q800.upstream2-vm and I can > confirm that > MacOS 8.1 now boots here with virtual memory enabled :) > > Possibly it might be worth including a tidied-up version of the "WIP: > target/m68k: > always exit_tb when changing sr with andi/ori/eori" commit from that > branch which is > also related to switching between supervisor and user modes under MacOS. > Shall I tidy > it up and send it to the list? > > > ATB, > > Mark. > > I've compiled the branch mentioned above with a fully updated MSYS2 on windows. The executable hangs when running Mac OS 8 with Virtual Memory enabled. On a fast machine I see Error 7 as before, on a slower machine, the boot screen just hangs with no error shown. A Linux build does work, also on the slower machine. Best, Howard
Re: [PATCH 0/2] target/m68k: fix two writes to %sr
On Wed, Sep 14, 2022 at 6:48 PM Howard Spoelstra wrote: > > > On Tue, Sep 13, 2022 at 6:29 PM Mark Cave-Ayland < > mark.cave-ayl...@ilande.co.uk> wrote: > >> On 13/09/2022 15:28, Richard Henderson wrote: >> >> > The second was described by Mark in the lobby of KVM Forum. >> > The first was found by inspection of other uses of gen_helper_set_sr. >> > >> > r~ >> > >> > Richard Henderson (2): >> >target/m68k: Fix MACSR to CCR >> >target/m68k: Perform writback before modifying SR >> > >> > target/m68k/translate.c | 14 +- >> > 1 file changed, 9 insertions(+), 5 deletions(-) >> >> I've applied these on top of my MacOS virtual memory branch at >> https://github.com/mcayland/qemu/commits/q800.upstream2-vm and I can >> confirm that >> MacOS 8.1 now boots here with virtual memory enabled :) >> >> Possibly it might be worth including a tidied-up version of the "WIP: >> target/m68k: >> always exit_tb when changing sr with andi/ori/eori" commit from that >> branch which is >> also related to switching between supervisor and user modes under MacOS. >> Shall I tidy >> it up and send it to the list? >> >> >> ATB, >> >> Mark. >> >> > I've compiled the branch mentioned above with a fully updated MSYS2 on > windows. The executable hangs when running Mac OS 8 with Virtual Memory > enabled. On a fast machine I see Error 7 as before, on a slower machine, > the boot screen just hangs with no error shown. A Linux build does work, > also on the slower machine. > > Best, > Howard > ps: a debug enabled non-stripped build will run with Virtual Memory enabled on Windows.
Re: Corrupted display changing screen colour depth in qemu-system-ppc/MacOS
On Fri, Jun 17, 2022 at 2:38 PM Marc-André Lureau <
marcandre.lur...@redhat.com> wrote:
> Hi
>
> On Fri, Jun 17, 2022 at 1:56 PM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > Can you try ditch the QEMU_ALLOCATED_FLAG check added by the commit?
> > >
> > > Commit cb8962c146 drops the QEMU_ALLOCATED_FLAG check: if I add it
> back in
> > > with the following diff on top then everything works again:
> >
> > Ah, the other way around.
> >
> > > diff --git a/ui/console.c b/ui/console.c
> > > index 365a2c14b8..decae4287f 100644
> > > --- a/ui/console.c
> > > +++ b/ui/console.c
> > > @@ -2400,11 +2400,12 @@ static void vc_chr_open(Chardev *chr,
> > >
> > > void qemu_console_resize(QemuConsole *s, int width, int height)
> > > {
> > > -DisplaySurface *surface;
> > > +DisplaySurface *surface = qemu_console_surface(s);
> > >
> > > assert(s->console_type == GRAPHIC_CONSOLE);
> > >
> > > -if (qemu_console_get_width(s, -1) == width &&
> > > +if (surface && (surface->flags & QEMU_ALLOCATED_FLAG) &&
> > > +qemu_console_get_width(s, -1) == width &&
> > > qemu_console_get_height(s, -1) == height) {
> > > return;
> > > }
> > >
> > > > Which depth changes triggers this? Going from direct color to a
> > > > paletted mode?
> > >
> > > A quick test suggests anything that isn't 32-bit colour is affected.
> >
> > Hmm, I think the commit should simply be reverted.
> >
> > Short-cutting the qemu_console_resize() call is only valid in case the
> > current surface was created by qemu_console_resize() too. When it is
> > something else -- typically a surface backed by vga vram -- it's not.
> > Looking at the QEMU_ALLOCATED_FLAG checks exactly that ...
>
> Oh ok, it might be worth adding a comment to clarify that. By
> reverting, we are going back to the situation where
> qemu_console_resize() will create a needless surface when rendering
> with GL. As I tried to explain in the commit message, it will need
> more changes to prevent that. I can take a look later.
>
>
Hi Marc-André,
I wondered whether you've had a chance to look at this?
Best,
Howard
Re: Issue with qemu-system-ppc running OSX guests
On Thu, Mar 3, 2022 at 12:55 AM Fabiano Rosas wrote: > Howard Spoelstra writes: > > > On Wed, Mar 2, 2022 at 9:11 PM BALATON Zoltan > wrote: > > > >> On Wed, 2 Mar 2022, Howard Spoelstra wrote: > >> > Hi all, > >> > > >> > I noticed qemu-system-ppc running OSX guests does not get to the > desktop > >> or > >> > does not display the menu bars. > >> > >> Cc-ing the relevant people and the PPC list might help, I've added them. > >> Also telling which OSX guest version can reproduce the problem could > help > >> debugging. Is it any OSX version? > >> > >> Regards, > >> BALATON Zoltan > >> > > > > Oops, Qemu running on Fedora 35 host, > > Reproducer: > > > > ./qemu-system-ppc \ > > -M mac99 \ > > -m 512 \ > > -L pc-bios \ > > -display sdl -serial stdio \ > > -boot c \ > > -drive file=10.1.img,format=raw,media=disk > > > > The issue affects all supported Mac OSX guests: 10.0 to 10.5 > > Hi Howard, > > Thanks for bisecting this. It seems we inadvertently marked some of the > Vector Multiply instructions to be ISA v2.07 only. > > I can boot Mac OSX 10.4 until the desktop with this fix: > > diff --git a/target/ppc/translate/vmx-impl.c.inc > b/target/ppc/translate/vmx-impl.c.inc > index f91bee839d..c5d02d13fe 100644 > --- a/target/ppc/translate/vmx-impl.c.inc > +++ b/target/ppc/translate/vmx-impl.c.inc > @@ -3141,14 +3141,14 @@ static bool trans_VMULLD(DisasContext *ctx, arg_VX > *a) > return true; > } > > -TRANS_FLAGS2(ALTIVEC_207, VMULESB, do_vx_helper, gen_helper_VMULESB) > -TRANS_FLAGS2(ALTIVEC_207, VMULOSB, do_vx_helper, gen_helper_VMULOSB) > -TRANS_FLAGS2(ALTIVEC_207, VMULEUB, do_vx_helper, gen_helper_VMULEUB) > -TRANS_FLAGS2(ALTIVEC_207, VMULOUB, do_vx_helper, gen_helper_VMULOUB) > -TRANS_FLAGS2(ALTIVEC_207, VMULESH, do_vx_helper, gen_helper_VMULESH) > -TRANS_FLAGS2(ALTIVEC_207, VMULOSH, do_vx_helper, gen_helper_VMULOSH) > -TRANS_FLAGS2(ALTIVEC_207, VMULEUH, do_vx_helper, gen_helper_VMULEUH) > -TRANS_FLAGS2(ALTIVEC_207, VMULOUH, do_vx_helper, gen_helper_VMULOUH) > +TRANS_FLAGS(ALTIVEC, VMULESB, do_vx_helper, gen_helper_VMULESB) > +TRANS_FLAGS(ALTIVEC, VMULOSB, do_vx_helper, gen_helper_VMULOSB) > +TRANS_FLAGS(ALTIVEC, VMULEUB, do_vx_helper, gen_helper_VMULEUB) > +TRANS_FLAGS(ALTIVEC, VMULOUB, do_vx_helper, gen_helper_VMULOUB) > +TRANS_FLAGS(ALTIVEC, VMULESH, do_vx_helper, gen_helper_VMULESH) > +TRANS_FLAGS(ALTIVEC, VMULOSH, do_vx_helper, gen_helper_VMULOSH) > +TRANS_FLAGS(ALTIVEC, VMULEUH, do_vx_helper, gen_helper_VMULEUH) > +TRANS_FLAGS(ALTIVEC, VMULOUH, do_vx_helper, gen_helper_VMULOUH) > TRANS_FLAGS2(ALTIVEC_207, VMULESW, do_vx_helper, gen_helper_VMULESW) > TRANS_FLAGS2(ALTIVEC_207, VMULOSW, do_vx_helper, gen_helper_VMULOSW) > TRANS_FLAGS2(ALTIVEC_207, VMULEUW, do_vx_helper, gen_helper_VMULEUW) > --- > > I'll let Lucas comment on it and we can send a proper patch in the > morning. > Hi, Thanks, this patch does indeed fix the issue. Best, Howard
Re: Issue with qemu-system-ppc running OSX guests
On Wed, Mar 2, 2022 at 9:11 PM BALATON Zoltan wrote: > On Wed, 2 Mar 2022, Howard Spoelstra wrote: > > Hi all, > > > > I noticed qemu-system-ppc running OSX guests does not get to the desktop > or > > does not display the menu bars. > > Cc-ing the relevant people and the PPC list might help, I've added them. > Also telling which OSX guest version can reproduce the problem could help > debugging. Is it any OSX version? > > Regards, > BALATON Zoltan > Oops, Qemu running on Fedora 35 host, Reproducer: ./qemu-system-ppc \ -M mac99 \ -m 512 \ -L pc-bios \ -display sdl -serial stdio \ -boot c \ -drive file=10.1.img,format=raw,media=disk The issue affects all supported Mac OSX guests: 10.0 to 10.5 Best, Howard > > Bisecting lead to this commit: > > > > 80eca687c8513a7e1611e0441abdd68b0c02a1d6 is the first bad commit > > commit 80eca687c8513a7e1611e0441abdd68b0c02a1d6 > > Author: Lucas Mateus Castro (alqotel) > > Date: Wed Mar 2 06:51:36 2022 +0100 > > > >target/ppc: moved vector even and odd multiplication to decodetree > > > >Moved the instructions vmulesb, vmulosb, vmuleub, vmuloub, > >vmulesh, vmulosh, vmuleuh, vmulouh, vmulesw, vmulosw, > >muleuw and vmulouw from legacy to decodetree. Implemented > >the instructions vmulesd, vmulosd, vmuleud, vmuloud. > > > >Reviewed-by: Richard Henderson > >Signed-off-by: Lucas Mateus Castro (alqotel) < > > lucas.ara...@eldorado.org.br> > >Signed-off-by: Matheus Ferst > >Message-Id: <20220225210936.1749575-3-matheus.fe...@eldorado.org.br> > >Signed-off-by: Cédric Le Goater > > > > target/ppc/helper.h | 24 ++-- > > target/ppc/insn32.decode| 22 +++ > > target/ppc/int_helper.c | 20 +- > > target/ppc/translate/vmx-impl.c.inc | 77 > > - > > target/ppc/translate/vmx-ops.c.inc | 15 ++-- > > tcg/ppc/tcg-target.c.inc| 6 +++ > > 6 files changed, 112 insertions(+), 52 deletions(-) > > > > Best, > > Howard > >
Issue with qemu-system-ppc running OSX guests
Hi all, I noticed qemu-system-ppc running OSX guests does not get to the desktop or does not display the menu bars. Bisecting lead to this commit: 80eca687c8513a7e1611e0441abdd68b0c02a1d6 is the first bad commit commit 80eca687c8513a7e1611e0441abdd68b0c02a1d6 Author: Lucas Mateus Castro (alqotel) Date: Wed Mar 2 06:51:36 2022 +0100 target/ppc: moved vector even and odd multiplication to decodetree Moved the instructions vmulesb, vmulosb, vmuleub, vmuloub, vmulesh, vmulosh, vmuleuh, vmulouh, vmulesw, vmulosw, muleuw and vmulouw from legacy to decodetree. Implemented the instructions vmulesd, vmulosd, vmuleud, vmuloud. Reviewed-by: Richard Henderson Signed-off-by: Lucas Mateus Castro (alqotel) < lucas.ara...@eldorado.org.br> Signed-off-by: Matheus Ferst Message-Id: <20220225210936.1749575-3-matheus.fe...@eldorado.org.br> Signed-off-by: Cédric Le Goater target/ppc/helper.h | 24 ++-- target/ppc/insn32.decode| 22 +++ target/ppc/int_helper.c | 20 +- target/ppc/translate/vmx-impl.c.inc | 77 - target/ppc/translate/vmx-ops.c.inc | 15 ++-- tcg/ppc/tcg-target.c.inc| 6 +++ 6 files changed, 112 insertions(+), 52 deletions(-) Best, Howard
Re: Mouse pointer warping with gtk display
On Thu, Jan 27, 2022 at 8:48 PM Marc-André Lureau < marcandre.lur...@gmail.com> wrote: > Hi > > On Thu, Jan 27, 2022 at 10:29 PM BALATON Zoltan > wrote: > >> Hello, >> >> We've found a problem with mouse pointer jumping around then constantly >> warping making it unusable which only seems to happen with the gtk >> display. Similar problem was reported with MacOS guests but now we could >> also reproduce with MorphOS on pegasos2 and thus confirm it's not a guest >> issue or hardware emulation problem but seems to be related to QEMU's gtk >> display. This can be reproduced as following (boot.img is the file from >> the root dir of the iso which is available from >> https://www.morphos-team.net/morphos-3.15.iso ): >> >> qemu-system-ppc -M pegasos2 -cdrom morphos-3.15.iso -display sdl \ >> -L ../pc-bios -kernel boot.img -device ati-vga,romfile="" >> >> This does not have this problem and mouse works but running with -display >> gtk has the mouse pointer issue making it unusable. It can be seemingly >> avoided with using -device ati-vga,romfile="",guest_hwcursor=true so I >> think problem is somewhere in mouse handling in ui/gtk.c with host side >> mouse pointer. The gd_motion_event() in that file has a big comment about >> warping mouse back to the middle near the end of the function which seems >> to ne what's happening and causing this as this does not appear in sdl.c >> that does not show the same issue but I don't understand what that code >> is >> trying to do. >> > > In general, a guest handles mouse input with relative motion events > (standard ps2). > > A more VM-friendly guest can additionally handle mouse input with absolute > coordinates (vmmouse, usb tablet etc) > > While giving absolute coordinates to a guest is quite a simple task from a > client (and offers some advantages) it is more tricky to deal with relative > mouse events... > > At the toolkit level, iirc, you generally don't have low-level events & > relative motion (gtk doesn't let you grab the mouse exclusively to receive > all events). You can workaround this with some window managers (ex wayland > relative-pointer unstable extension). > > The "old" strategy with gtk2/3 is to grab the mouse, which is then > constrained within the display widget iirc, and convert absolute events to > relative events by doing simple current_position - last_position. Since > your client mouse may reach the widget borders (and/or the client monitor > limits, can't remember which applies, I think it varies), you also need to > recenter the client mouse somewhere, and that's usually in the middle of > the display widget. > > This is clunky at best, and gtk devs decided to no longer support that > kind of API with gtk4. The recommended approach is to use lower-level > events, like the one you get from the wayland extensions. This is a pain > for portability, but that's all we have for now. > > spice-gtk implements the wayland stuff. Have you tried running -display > spice-app? It may have a more polished behavior than the one in qemu. > > > > > > >> >> It's a known problem that host mouse pointer can get out of sync with the >> guest which I think is because mouse acceleration on the host is not >> correctly taken into account when reporting mouse moves to the guest and >> this may try to correct that issue but it seems to cause more harm than >> good in some cases. Any idea what might be the problem and how to solve >> this? I wonder why nobody else is seeing this with other guests. (I'm not >> direcly interested in fixing it as I'm using sdl display but this makes >> it >> hard to use some guests for users whose distros make gtk backend the >> default which may actually be most people so it might be a good idea to >> improve this for them so I thought at least reporting the problem is >> useful.) >> > > I suspect SDL offers an API for relative mouse events, which works better > than what we do in the gtk backend. > > I hope in the future we can drop the gtk code from qemu, in favor of > dbus-display and rdw. Maintaining that kind of code is hard, and having the > same gtk widget base code for various remote desktop apps & protocols > should help maintenance and offer a consistent behavior, whether you use > QEMU/DBus, VNC, Spice, or RDP and whatever the future brings. > > (I wrote the above mostly from memory, I agree it's convoluted and a bit > buggy, I doubt anyone likes it ;) > > -- > Marc-André Lureau > Hi Zoltan, While I can reproduce the issue you report when running morphos with gtk, I cannot currently reproduce with the Mac OS/OSX guests I tested on Linux host. Both mac99 (adb mouse and kbd) and mac99,via=pmu (usb mouse and kbd) keep the mouse inside the guest window with both sdl and gtk. Best, Howard
Re: [RFC PATCH 0/4] Misc OHCI patches
Hi all, One more observation: When running Mac OS guests with -mac99,via=pmu, the guest is presented with a usb-mouse and usb-kbd, while -mac99 provides cuda mouse/kbd. If I run with via=pmu, the mouse/kbd will not work when passing through the usb headset. Only when I keep interrupting by pressing a volume button on the headset, the mouse moves. So it seems Qemu does not iterate getting interrupts over multiple devices. Best, Howard >
Re: [RFC PATCH 0/4] Misc OHCI patches
On Sun, Oct 3, 2021 at 12:00 PM BALATON Zoltan wrote: > On Sun, 3 Oct 2021, Howard Spoelstra wrote: > > On Sat, Oct 2, 2021 at 5:42 PM BALATON Zoltan > wrote: > >> I'm also not sure where's the problem (maybe we have multiple problems). > >> It also does not work with an emulated usb-audio device but that also > >> doesn't work with EHCI so it may have a problem by itself (UHCI also > seems > >> to be broken on its own so it does not even work as much as OHCI and > >> EHCI). You've also said it worked with pass through with a different > >> device so maybe this only happens with some devices or some sequence of > >> things these devices are doing. Only allowing one async packet in OHCI > >> instead of allowing one per endpoint is just a guess that could cause > >> delays in processing other packets but eventually it should go through > >> unless one async packet never completes and blocks all later ones or the > >> delays introduced by this limitaion causes things to go in a way that > >> guests don't expect and thus fail. > >> > > After some sifting through the logs, I my interpretation of our issue is > > this: > > Too many pending is referring to endpoint 0 when something is not > > completed. Qemu permantly checks endpoint 4 for hid activity, skips when > no > > interrupt occurs. You can see both intermittently in the 1st log below. > > Too many pending refers to qemu not being able to fully read/get the > device > > descriptors from boot. The too many pending is "solved", with a click on > a > > hid button. That leads to async complete, after which the only activity > is > > to check for interrupts from the hid devices. > > That sounds like an async packet waiting on ep 4 blocks communication on > ep 0 because we don't allow one active packet per ep in hcd-ohci as the > comment says so this may be fixed by implementing that. But I'm not sure > because this log did not include packet status. Maybe also enable > usb_packet_state traces to confirm this. I may try to fix this, I have an > idea how do it: I can pass the USBPacket back from the completion callback > via OHCIState to ohci_service_td() but have to find a way to replace the > various cancel calls that use the usb_packet from OHCIState now to stop > relying on that and do it by ep or whatever they have. This needs some > more thinking and understand the code and OHCI better. > > I assume no more than one callback can be running at once so I can't get > completion for two packets at the same time, therefore one pointer to pass > back a packet is enough. I'll put an assert there and see what happens but > if somebody knows please advise. > > > However, as the descriptors from endpoint 0 are not fully read from boot, > > endpoint 1 (the actual audio stream) is not available. > > Unplugging/plugging the usb device in combination with some hid > interrupts > > (me pushing the volume button) can sometimes reload the configuration > > correctly, so endpoint 1 becomes available and sound can be played > through > > it. > > Could be if guest driver starts polling ep 4 while still trying to talk to > ep 0 which then fails due to packet waiting in async on ep 4. The emulated > usb-audio may be different, that does not have HID endpoint only ep 0 for > control and two audio ones and it seems to be detected but playing sound > does not work. Does -device usb-audio instead of passed through device > makes sound with your guest OSes or that has a separate problem? > Usb-audio works in MacOS 9.2 guest, but only for some seconds. After that the desktop becomes unresponsive. Icons disappear, mouse still moves but cannot activate anything. With via=pmu, log shows usb mouse/kbd still communicating. I've seen something very similar happen when I attempt to stop and start usb support in Mac OS 9.2 with the headset passed through. System sounds in Fedora 12 guest can be played. New logging with package status shows: usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_packet_status status=0 usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_packet_status status=-6 usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_async_complete usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_packet_status status=0 usb_ohci_ed_pkt_flags fa=107 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_packet_status status=0 usb_ohci_ed_pkt_flags fa=107 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_td_packet_status status=-6 --> note this is line 1282 in my log The following the
Re: [RFC PATCH 0/4] Misc OHCI patches
On Sat, Oct 2, 2021 at 5:42 PM BALATON Zoltan wrote: > On Sat, 2 Oct 2021, Howard Spoelstra wrote: > > Both have issues communicating with endpoint 4 (the hid controls volume > > up/down and mute). > > Endpoint 1 should receive the isochronous audio stream, but never does. > > > > After some experimentation with unplugging/plugging the headset and > probing > > the usb stack (using the usb prober from the mac usb ddk for Mac OS 9.2) > at > > some point endpoint 4 communication works for both guests tested. Only > once > > was I able to get sound out and in working in Mac OS 9.2. For OSX I could > > only once get audio in working. > > The async packets are on endpoint 0. I'm not sure the HID endpoint 4 is > normally involved at all unless you push some buttons but it should work > without that so maybe look at the 0 and the audio endpoints instead of > HID that should have no traffic unless you press buttons. > > > Pcap and text logs for both MacOS 9.2 and OSX 10.4 tests included... > > These are way too big to be possible to find anything in them. Maybe you > should do something simpler like boot the guest without the device > attached and discard all logs up to that point. Then start collecting logs > and attach device and play a short sound. Stop collecting log and try to > make sense of where that fails. That's still a lot of traces but should > only contain the relevant info of detecing the device and playing a sound > not a lot of others that makes it difficult to find what's relevant. > > I'm also not sure where's the problem (maybe we have multiple problems). > It also does not work with an emulated usb-audio device but that also > doesn't work with EHCI so it may have a problem by itself (UHCI also seems > to be broken on its own so it does not even work as much as OHCI and > EHCI). You've also said it worked with pass through with a different > device so maybe this only happens with some devices or some sequence of > things these devices are doing. Only allowing one async packet in OHCI > instead of allowing one per endpoint is just a guess that could cause > delays in processing other packets but eventually it should go through > unless one async packet never completes and blocks all later ones or the > delays introduced by this limitaion causes things to go in a way that > guests don't expect and thus fail. > > Regards, > BALATON Zoltan > After some sifting through the logs, I my interpretation of our issue is this: Too many pending is referring to endpoint 0 when something is not completed. Qemu permantly checks endpoint 4 for hid activity, skips when no interrupt occurs. You can see both intermittently in the 1st log below. Too many pending refers to qemu not being able to fully read/get the device descriptors from boot. The too many pending is "solved", with a click on a hid button. That leads to async complete, after which the only activity is to check for interrupts from the hid devices. However, as the descriptors from endpoint 0 are not fully read from boot, endpoint 1 (the actual audio stream) is not available. Unplugging/plugging the usb device in combination with some hid interrupts (me pushing the volume button) can sometimes reload the configuration correctly, so endpoint 1 becomes available and sound can be played through it. usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_async_complete usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_async_complete usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_async_complete usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 usb_ohci_ed_pkt_flags fa=95 en=4 d=2 s=0 k=0 f=0 mps=37 usb_ohci_td_too_many_pending usb_ohci_ed_pkt_flags fa=95 en=0 d=0 s=0 k=0 f=0 mps=64 us
Re: [qemu-web v2 PATCH] Update the information about the required version of macOS
On Mon, Sep 13, 2021 at 8:21 AM Thomas Huth wrote: > The versions that we specify for macOS are way too old already. Let's > rephrase this without specific version numbers, pointing the users > to the latest version instead. > > Signed-off-by: Thomas Huth > --- > v2: Rephrased to be more in sync with docs/about/build-platforms.rst > > _download/macos.md | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/_download/macos.md b/_download/macos.md > index 06aa811..c55438a 100644 > --- a/_download/macos.md > +++ b/_download/macos.md > @@ -6,5 +6,7 @@ QEMU can be installed from MacPorts: > > sudo port install qemu > > -QEMU requires Mac OS X 10.5 or later, but it is recommended > -to use Mac OS X 10.7 or later. > +QEMU requires the the most recent macOS version that is currently > available. > +Support for the previous version will be dropped two years after the > current > +version has been released or when Apple drops support for it, whatever > comes > +first. > -- > 2.27.0 > Hi, Nice to see this clarified. I guess a small typo crept in: "QEMU requires the the most recent macOS version that is currently available." Also, is this statement correct when the 2 year previous version(s) are also supported? Might I also suggest "version(s)" instead of "version"? Best, Howard
Re: Implementing isochronous transfers in hw/hcd-ohci.c
On Fri, Sep 10, 2021 at 9:23 PM Programmingkid wrote: > > > > On Sep 10, 2021, at 7:51 AM, BALATON Zoltan wrote: > > > > On Fri, 10 Sep 2021, Howard Spoelstra wrote: > >> On Fri, Sep 10, 2021 at 7:07 AM Gerd Hoffmann > wrote: > >> > >>> On Thu, Sep 09, 2021 at 05:06:17PM -0400, Programmingkid wrote: > >>>> Hi Gerd, > >>>> > >>>> Howard and I were talking about USB audio problems with Mac OS guests. > >>> We think the issue might be with frames being sent to the USB audio > card > >>> too soon. My guess is only one frame is suppose to be transmitted > every 1 > >>> millisecond. I was also reading the todo notes in the file > hw/hcd-ohci.c. > >>> This is what it says: > >>>> > >>>> * TODO: > >>>> * o Isochronous transfers > >>>> * o Allocate bandwidth in frames properly > >>>> * o Disable timers when nothing needs to be done, or remove timer > usage > >>>> *all together. > >>>> * o BIOS work to boot from USB storage > >>>> */ > >>>> > >>>> Do you think implementing isochronous transfers would fix the audio > >>> problems Mac OS guest are experiencing? > >>> > >>> Most likely yes, audio devices typically use iso endpints. > >>> > >>> take care, > >>> Gerd > >>> > >> > >> Hi, > >> > >> Below I pasted the first lines mentioning isochronous traffic from a > pcap > >> file when running fedora12 with the usb-audio device and the first lines > >> from a pcap file running Mac OS 9.2 with the usb-audio device > >> > >> Fedora: > >> 91 56.715001 host 0.5.1 USB 256 URB_ISOCHRONOUS out > >> 92 56.715018 0.5.1 host USB 64 URB_ISOCHRONOUS out > >> > >> MacOS: > >> 143 56.031989 host 0.16.1 USB 256 URB_ISOCHRONOUS out > >> 144 56.032026 0.16.1 host USB 64 URB_ISOCHRONOUS out > >> > >> The usb-audio device works for the fedora guest, so would this not > indicate > >> that the iso endpoints are already working? > >> > >> The usb-audio device also work (for a limited amount of time) when > running > >> MacOS. Looking at USB logging in the Mac OS guest, to me it seems the > MacOS > >> side runs into timing issues when packages drift too far apart. It then > >> finally gives up trying to keep the stream open. > > > > I was also trying to find why the usb-audio device does not work with > MorphOS but I could not figure it out. Now I have two machines (mac99 and > pegasos2) that can boot MorphOS but usb-audio does not work with either so > maybe it's not because of the USB controller. I've found there is a debug > property that enables some logging: -device usb-audio,debug=1 but that did > not reveal much more. It looks like MorphOS tries to query the device but > replies come very slow (not sure if that's normal or a problem) then just > gives up after a while. Maybe you can try comparing what Fedora and other > OSes query as it may be we're missing some info in USB descriptors that > other drivers than Linux's rely on but that's just a guess I haven't tested > with Linux guest on pegasos2 or mac99 yet. > > > > Regards, > > BALATON Zoltan > > Thank for the info everyone. When I try to use the USB-Audio device in Mac > OS 10.4.11, the operating system doesn't use it. It does show up in the > System Profiler application. In Mac OS 9.2 the sound from it is perfect > sounding, but the operating system crashes after less than a minute. In Mac > OS 10.2.3 the operating system does set it as its output device but it does > not work. > > To find out what is wrong we would probably have to build the USB audio > drivers in Mac OS X and enable debug output to see what is wrong. They are > open source and I have done this in the past. As for Mac OS 9, I'm not sure > how to debug its driver. See the screen shot attached for the warnings about timing in MacOS 9.2 before the stream collapses.This was after some system sounds were played successfully. [image: usb-audiolog.png] Best, Howard
Re: [qemu-web PATCH] Fix link to Windows page in Wiki
On Sat, Sep 11, 2021 at 8:29 AM Helge Konetzka wrote:
> Am 10.09.21 um 17:44 schrieb Paolo Bonzini:
> > On 25/08/21 18:43, Helge Konetzka wrote:
> >> Furthermore I would like to propose to change the instructions for
> >> Native builds with MSYS2 on Wiki Windows page.
> >>
> >> Please remove the section which copies system binaries to match the
> >> expected file names!
> >>
> >> Instead define variables for configure (gcc-ar and gcc-ranlib are
> >> existing copies of x86_64-w64-mingw32-gcc-ar and
> >> x86_64-w64-mingw32-gcc-ranlib) and add strip to enable make install:
> >>
> >> AR=gcc-ar NM=nm OBJCOPY=objcopy RANLIB=gcc-ranlib WINDRES=windres
> >> STRIP=strip \
> >> ./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl
> >
> > Do you even need anything but "./configure"? (possibly AR=gcc-ar NM=nm
> > at the beginning)?
>
> Sorry for being indistinct!
>
> My intention was to put "AR=gcc-ar NM=nm OBJCOPY=objcopy
> RANLIB=gcc-ranlib WINDRES=windres STRIP=strip" in front of "./configure"
> (see the '\' after STRIP=strip) instead of copying binaries:
>
> diff -Naur qemu.org.orig/Hosts/W32 qemu.org/Hosts/W32
> --- qemu.org.orig/Hosts/W32 2021-09-11 08:27:01.198715675 +0200
> +++ qemu.org/Hosts/W32 2021-09-11 08:28:15.853605118 +0200
> @@ -232,14 +232,6 @@
> Close the MSYS2 console.
> Start mingw64.exe.
>
> -cd /mingw64/bin
> -cp x86_64-w64-mingw32-gcc-ar.exe x86_64-w64-mingw32-ar.exe
> -cp x86_64-w64-mingw32-gcc-ranlib.exe x86_64-w64-mingw32-ranlib.exe
> -cp windres.exe x86_64-w64-mingw32-windres.exe
> -cp nm.exe x86_64-w64-mingw32-nm.exe
> -cp objcopy.exe x86_64-w64-mingw32-objcopy.exe
> -cd ~
> -
> Download the QEMU source code:
>
> git clone https://www.github.com/qemu/qemu
> @@ -247,6 +239,7 @@
> Finally build QEMU with:
>
> cd qemu
> +AR=gcc-ar NM=nm OBJCOPY=objcopy RANLIB=gcc-ranlib WINDRES=windres
> STRIP=strip \
> ./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl
> make
>
>
Hi,
I wrote those instructions as I obviously could not find a better way to
get Qemu to cross-compile using MSYS2 in Windows.
When you look at configure, you see that only adding the cross-prefix will
not find the MSYS equivalents of some tools:
ar="${AR-${cross_prefix}ar}"
looks for x86_64-w64-mingw32-ar.exe and not (as it is named in MSYS2)
x86_64-w64-mingw32-gcc-ar.exe
Perhaps it would be better to fix configure for the MSYS2 case so the
flags or the renaming are not required?
Best,
Howard
Re: Implementing isochronous transfers in hw/hcd-ohci.c
On Fri, Sep 10, 2021 at 7:07 AM Gerd Hoffmann wrote: > On Thu, Sep 09, 2021 at 05:06:17PM -0400, Programmingkid wrote: > > Hi Gerd, > > > > Howard and I were talking about USB audio problems with Mac OS guests. > We think the issue might be with frames being sent to the USB audio card > too soon. My guess is only one frame is suppose to be transmitted every 1 > millisecond. I was also reading the todo notes in the file hw/hcd-ohci.c. > This is what it says: > > > > * TODO: > > * o Isochronous transfers > > * o Allocate bandwidth in frames properly > > * o Disable timers when nothing needs to be done, or remove timer usage > > *all together. > > * o BIOS work to boot from USB storage > > */ > > > > Do you think implementing isochronous transfers would fix the audio > problems Mac OS guest are experiencing? > > Most likely yes, audio devices typically use iso endpints. > > take care, > Gerd > Hi, Below I pasted the first lines mentioning isochronous traffic from a pcap file when running fedora12 with the usb-audio device and the first lines from a pcap file running Mac OS 9.2 with the usb-audio device Fedora: 91 56.715001 host 0.5.1 USB 256 URB_ISOCHRONOUS out 92 56.715018 0.5.1 host USB 64 URB_ISOCHRONOUS out MacOS: 143 56.031989 host 0.16.1 USB 256 URB_ISOCHRONOUS out 144 56.032026 0.16.1 host USB 64 URB_ISOCHRONOUS out The usb-audio device works for the fedora guest, so would this not indicate that the iso endpoints are already working? The usb-audio device also work (for a limited amount of time) when running MacOS. Looking at USB logging in the Mac OS guest, to me it seems the MacOS side runs into timing issues when packages drift too far apart. It then finally gives up trying to keep the stream open. Best, Howard
Re: Bug in qemu-system-ppc running fedora 12 ppc guest
On Thu, Jul 29, 2021 at 12:07 PM BALATON Zoltan wrote: > Hello, > > On Thu, 29 Jul 2021, Howard Spoelstra wrote: > > Hi, > > > > Qemu-system-ppc built from current master can no longer run Fedora 12 ppc > > as guest. (This the only ppc distro I tested.) Host is Fedora 34. Please > > see screen shot attached. > > Booting from both an installation DVD and from an installed system fail. > > > > To reproduce: > > compile qemu-system-ppc from current master and run: > > > > ./qemu-system-ppc \ > > -M mac99,via=pmu \ > > -m 1024 \ > > -L pc-bios \ > > -boot d \ > > -cdrom Fedora-12-ppc-DVD.iso \ > > -g 1024x768x8 > > > > I tracked the issue down to this commit: > > > > 8f0a4b6a9b40e18116a2bb6bbcc00feb8119c792 is the first bad commit > > commit 8f0a4b6a9b40e18116a2bb6bbcc00feb8119c792 > > There's a fix for a similar problem I've seen with AROS and pegasos2 > firmware 1.2 that's in today's pull request: > > https://lists.nongnu.org/archive/html/qemu-ppc/2021-07/msg00281.html > > That should likely fixes this. Can you try with that (either once it's > merged or from David's for-6.1 branch). > > Regards, > BALATON Zoltan > Thanks, this issue is indeed fixed by https://github.com/qemu/qemu/commit/2d1154bd95a8bfea30cc59de8e080e5a016a9bee Best, Howard
Bug in qemu-system-ppc running fedora 12 ppc guest
Hi, Qemu-system-ppc built from current master can no longer run Fedora 12 ppc as guest. (This the only ppc distro I tested.) Host is Fedora 34. Please see screen shot attached. Booting from both an installation DVD and from an installed system fail. To reproduce: compile qemu-system-ppc from current master and run: ./qemu-system-ppc \ -M mac99,via=pmu \ -m 1024 \ -L pc-bios \ -boot d \ -cdrom Fedora-12-ppc-DVD.iso \ -g 1024x768x8 I tracked the issue down to this commit: 8f0a4b6a9b40e18116a2bb6bbcc00feb8119c792 is the first bad commit commit 8f0a4b6a9b40e18116a2bb6bbcc00feb8119c792 Author: Matheus Ferst Date: Tue Jun 1 16:35:28 2021 -0300 target/ppc: Move cmp/cmpi/cmpl/cmpli to decodetree Additionally, REQUIRE_64BIT when L=1 to match what is specified in The Programming Environments Manual: "For 32-bit implementations, the L field must be cleared, otherwise the instruction form is invalid." Some CPUs are known to deviate from this specification by ignoring the L bit [1]. The stricter behavior, however, can help users that test software with qemu, making it more likely to detect bugs that would otherwise be silent. If deemed necessary, a future patch can adapt this behavior based on the specific CPU model. [1] The 601 manual is the only one I've found that explicitly states that the L bit is ignored, but we also observe this behavior in a 7447A v1.2. Signed-off-by: Matheus Ferst Message-Id: <20210601193528.2533031-15-matheus.fe...@eldorado.org.br> Reviewed-by: Richard Henderson [dwg: Corrected whitespace error] Signed-off-by: David Gibson target/ppc/insn32.decode | 14 target/ppc/translate.c | 52 -- target/ppc/translate/fixedpoint-impl.c.inc | 31 ++ 3 files changed, 45 insertions(+), 52 deletions(-) Best, Howard [image: Qemu-system-ppc-Fedora-Crashing.png]
Re: [Bug 1926497] Re: dp83932 stops working after a short while
On Wed, Apr 28, 2021 at 11:31 PM Jeff <1926...@bugs.launchpad.net> wrote: > > It looks like using > https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/debian-10.0.0 > -m68k-NETINST-1.iso instead fixes the issue. Perhaps the instruction on > https://wiki.qemu.org/Documentation/Platforms/m68k should be updated. > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1926497 > > Title: > dp83932 stops working after a short while > > Status in QEMU: > New > > Bug description: > Following the instructions here > https://wiki.qemu.org/Documentation/Platforms/m68k I was able to > successfully install debian. However, running apt-get update stalls > after the first 1-2MB. > > root@debian:~# apt-get update > Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] > Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease > Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 > kB] > 18% [2 Packages 2,155 kB/8,735 kB 25%] > > After running apt-get update. I don't seem to be able to send any > packets anymore. ping host lookups fail and a subsequent apt-get > update makes no progress. > > I'm launching qemu with: > > qemu-system-m68k -boot c \ >-M q800 -serial none -serial mon:stdio -m 1000M \ >-net nic,model=dp83932 -net user \ >-append "root=/dev/sda2 rw console=ttyS0 console=tty" \ >-kernel vmlinux-4.16.0-1-m68k \ >-initrd initrd.img-4.16.0-1-m68k \ >-drive file=m68k-deb10.qcow2,format=qcow2 \ >-nographic > > I see this with qemu v6.0.0-rc5 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1926497/+subscriptions I've updated the page to include: Please note that the instructions below use kernel versions that might have been superseded by newer ones on the most recent installation cd images! Also, during installation on hard disk image the update process might install a newer kernel. Always make sure to extract the latest kernel and initrd.gz from your hard disk image after installation or update and replace the kernel names in the examples below with what is currently installed.
Re: Mac OS real USB device support issue
On Fri, Apr 9, 2021 at 9:37 PM Programmingkid wrote: > > > > > On Apr 7, 2021, at 1:28 AM, Howard Spoelstra wrote: > > > > On Wed, Apr 7, 2021 at 7:26 AM Howard Spoelstra wrote: > >> > >> On Wed, Apr 7, 2021 at 3:53 AM Programmingkid > >> wrote: > >>> > >>> > >>> > >>>> On Apr 6, 2021, at 7:18 PM, BALATON Zoltan wrote: > >>>> > >>>> On Tue, 6 Apr 2021, Programmingkid wrote: > >>>>>> On Apr 6, 2021, at 12:53 PM, BALATON Zoltan wrote: > >>>>>> On Tue, 6 Apr 2021, Programmingkid wrote: > >>>>>>>> On Apr 6, 2021, at 10:01 AM, Howard Spoelstra > >>>>>>>> wrote: > >>>>>>>> On Tue, Apr 6, 2021 at 3:44 PM Programmingkid > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Gerd, > >>>>>>>>> > >>>>>>>>> I was wondering if you had access to a Mac OS 10 or Mac OS 11 > >>>>>>>>> machine to test USB support. I am on Mac OS 11.1 and cannot make > >>>>>>>>> USB devices work with any of my guests. So far these are the guests > >>>>>>>>> I have tested with: > >>>>>>>>> > >>>>>>>>> - Windows 7 > >>>>>>>>> - Mac OS 9.2 > >>>>>>>>> - Windows 2000 > >>>>>>>>> > >>>>>>>>> I have tried using USB flash drives, USB sound cards, and an USB > >>>>>>>>> headset. They all show up under 'info usb', but cannot be used in > >>>>>>>>> the guest. My setup does use a USB-C hub so I'm not sure if this is > >>>>>>>>> a bug with QEMU or an issue with the hub. Would you have any > >>>>>>>>> information on this issue? > >>>>>>>> > >>>>>>>> Hi John, > >>>>>>>> > >>>>>>>> As far as the Mac OS 9.2 guest is concerned on a mac OS host, it does > >>>>>>>> not support USB 2.0. I was successful only in passing through a USB > >>>>>>>> flash drive that was forced into USB 1.1 mode by connecting it to a > >>>>>>>> real USB 1.1 hub and unloading the kext it used. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Howard > >>>>>>> > >>>>>>> Hi Howard, I was actually thinking about CC'ing you for this email. > >>>>>>> Glad you found it. Unloading kext files does not sound pleasant. > >>>>>>> Maybe there is some better way of doing it. > >>>>>> > >>>>>> In any case, until you make sure nothing tries to drive the device on > >>>>>> the host, passing it to a guest likely will fail because then two > >>>>>> drivers from two OSes would try to access it simultaneously which > >>>>>> likely creates a mess as the device and drivers don't expect this. So > >>>>>> you can't just pass a device through that the host has recognised and > >>>>>> is driving without somehow getting the host to leave it alone first > >>>>>> before you can pass it through. Unloading the driver is one way to do > >>>>>> that (although it probably breaks all other similar devices too). > >>>>>> Maybe there's another way to unbind a device from the host such as > >>>>>> ejecting it first but then I'm not sure if the low level USB needed > >>>>>> for accessing the device still works after that or it's completely > >>>>>> forgotten. There's probably a doc somewhere that describes how it > >>>>>> works and how can you plug a device without also getting higher level > >>>>>> drivers to load or if there's no official ways for that then you'll > >>>>>> need to do some configuration on the host t > >>>> o avoid it grabbing devices that you want to pass through. On Linux you > >>>> can add an udev rule to ignore the device (maybe also adding > >>>> TAG+="uaccess" to allow console users to use it without needing root > >>>> access) but not s
Re: Mac OS real USB device support issue
On Thu, Apr 8, 2021 at 1:05 PM Gerd Hoffmann wrote: > > Hi, > > > > Those might be a good place to start. IOKit provides the drivers and > > > also the io registry which is probably where you can get if a driver > > > is bound to a device and which one is it. How to dissociate the > > > driver from the device though I don't know. > > > https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/DeviceRemoval/DeviceRemoval.html > > > According to this article a driver has a stop() and detach() method > > that is called by the IOKit to remove a device. I'm thinking QEMU can > > be the one that calls these methods for a certain device. > > libusb should do that. Interfaces exist already (see > libusb_detach_kernel_driver & friends) because we have the very same > problem on linux. > > take care, > Gerd > As far as I understand the patches here https://github.com/libusb/libusb/issues/906 they are internal to libusb, so we would need to build a libusb for use with e.g., brew to build a macOS executable. Or wait for them to be finalised to get included in libusb and then included in brew and then Best, Howard
Re: Mac OS real USB device support issue
On Wed, Apr 7, 2021 at 7:26 AM Howard Spoelstra wrote: > > On Wed, Apr 7, 2021 at 3:53 AM Programmingkid > wrote: > > > > > > > > > On Apr 6, 2021, at 7:18 PM, BALATON Zoltan wrote: > > > > > > On Tue, 6 Apr 2021, Programmingkid wrote: > > >>> On Apr 6, 2021, at 12:53 PM, BALATON Zoltan wrote: > > >>> On Tue, 6 Apr 2021, Programmingkid wrote: > > >>>>> On Apr 6, 2021, at 10:01 AM, Howard Spoelstra > > >>>>> wrote: > > >>>>> On Tue, Apr 6, 2021 at 3:44 PM Programmingkid > > >>>>> wrote: > > >>>>>> > > >>>>>> Hi Gerd, > > >>>>>> > > >>>>>> I was wondering if you had access to a Mac OS 10 or Mac OS 11 > > >>>>>> machine to test USB support. I am on Mac OS 11.1 and cannot make USB > > >>>>>> devices work with any of my guests. So far these are the guests I > > >>>>>> have tested with: > > >>>>>> > > >>>>>> - Windows 7 > > >>>>>> - Mac OS 9.2 > > >>>>>> - Windows 2000 > > >>>>>> > > >>>>>> I have tried using USB flash drives, USB sound cards, and an USB > > >>>>>> headset. They all show up under 'info usb', but cannot be used in > > >>>>>> the guest. My setup does use a USB-C hub so I'm not sure if this is > > >>>>>> a bug with QEMU or an issue with the hub. Would you have any > > >>>>>> information on this issue? > > >>>>> > > >>>>> Hi John, > > >>>>> > > >>>>> As far as the Mac OS 9.2 guest is concerned on a mac OS host, it does > > >>>>> not support USB 2.0. I was successful only in passing through a USB > > >>>>> flash drive that was forced into USB 1.1 mode by connecting it to a > > >>>>> real USB 1.1 hub and unloading the kext it used. > > >>>>> > > >>>>> Best, > > >>>>> Howard > > >>>> > > >>>> Hi Howard, I was actually thinking about CC'ing you for this email. > > >>>> Glad you found it. Unloading kext files does not sound pleasant. Maybe > > >>>> there is some better way of doing it. > > >>> > > >>> In any case, until you make sure nothing tries to drive the device on > > >>> the host, passing it to a guest likely will fail because then two > > >>> drivers from two OSes would try to access it simultaneously which > > >>> likely creates a mess as the device and drivers don't expect this. So > > >>> you can't just pass a device through that the host has recognised and > > >>> is driving without somehow getting the host to leave it alone first > > >>> before you can pass it through. Unloading the driver is one way to do > > >>> that (although it probably breaks all other similar devices too). Maybe > > >>> there's another way to unbind a device from the host such as ejecting > > >>> it first but then I'm not sure if the low level USB needed for > > >>> accessing the device still works after that or it's completely > > >>> forgotten. There's probably a doc somewhere that describes how it works > > >>> and how can you plug a device without also getting higher level drivers > > >>> to load or if there's no official ways for that then you'll need to do > > >>> some configuration on the host t > > > o avoid it grabbing devices that you want to pass through. On Linux you > > > can add an udev rule to ignore the device (maybe also adding > > > TAG+="uaccess" to allow console users to use it without needing root > > > access) but not sure how USB works on macOS. > > >>> > > >>> Regards, > > >>> BALATON Zoltan > > >> > > >> Being able to dissociate a real USB device from its Mac OS driver would > > >> be very useful in this situation. IOKit might be one place to look for > > >> such a feature. The Mach kernel documentation is another place that > > >> might have what we want. > > > > > > Those might be a good place to start. IOKit provides the drivers and also > > > the io registry which is probably where you can get if
Re: Mac OS real USB device support issue
On Wed, Apr 7, 2021 at 3:53 AM Programmingkid wrote: > > > > > On Apr 6, 2021, at 7:18 PM, BALATON Zoltan wrote: > > > > On Tue, 6 Apr 2021, Programmingkid wrote: > >>> On Apr 6, 2021, at 12:53 PM, BALATON Zoltan wrote: > >>> On Tue, 6 Apr 2021, Programmingkid wrote: > >>>>> On Apr 6, 2021, at 10:01 AM, Howard Spoelstra > >>>>> wrote: > >>>>> On Tue, Apr 6, 2021 at 3:44 PM Programmingkid > >>>>> wrote: > >>>>>> > >>>>>> Hi Gerd, > >>>>>> > >>>>>> I was wondering if you had access to a Mac OS 10 or Mac OS 11 machine > >>>>>> to test USB support. I am on Mac OS 11.1 and cannot make USB devices > >>>>>> work with any of my guests. So far these are the guests I have tested > >>>>>> with: > >>>>>> > >>>>>> - Windows 7 > >>>>>> - Mac OS 9.2 > >>>>>> - Windows 2000 > >>>>>> > >>>>>> I have tried using USB flash drives, USB sound cards, and an USB > >>>>>> headset. They all show up under 'info usb', but cannot be used in the > >>>>>> guest. My setup does use a USB-C hub so I'm not sure if this is a bug > >>>>>> with QEMU or an issue with the hub. Would you have any information on > >>>>>> this issue? > >>>>> > >>>>> Hi John, > >>>>> > >>>>> As far as the Mac OS 9.2 guest is concerned on a mac OS host, it does > >>>>> not support USB 2.0. I was successful only in passing through a USB > >>>>> flash drive that was forced into USB 1.1 mode by connecting it to a > >>>>> real USB 1.1 hub and unloading the kext it used. > >>>>> > >>>>> Best, > >>>>> Howard > >>>> > >>>> Hi Howard, I was actually thinking about CC'ing you for this email. Glad > >>>> you found it. Unloading kext files does not sound pleasant. Maybe there > >>>> is some better way of doing it. > >>> > >>> In any case, until you make sure nothing tries to drive the device on the > >>> host, passing it to a guest likely will fail because then two drivers > >>> from two OSes would try to access it simultaneously which likely creates > >>> a mess as the device and drivers don't expect this. So you can't just > >>> pass a device through that the host has recognised and is driving without > >>> somehow getting the host to leave it alone first before you can pass it > >>> through. Unloading the driver is one way to do that (although it probably > >>> breaks all other similar devices too). Maybe there's another way to > >>> unbind a device from the host such as ejecting it first but then I'm not > >>> sure if the low level USB needed for accessing the device still works > >>> after that or it's completely forgotten. There's probably a doc somewhere > >>> that describes how it works and how can you plug a device without also > >>> getting higher level drivers to load or if there's no official ways for > >>> that then you'll need to do some configuration on the host t > > o avoid it grabbing devices that you want to pass through. On Linux you can > > add an udev rule to ignore the device (maybe also adding TAG+="uaccess" to > > allow console users to use it without needing root access) but not sure how > > USB works on macOS. > >>> > >>> Regards, > >>> BALATON Zoltan > >> > >> Being able to dissociate a real USB device from its Mac OS driver would be > >> very useful in this situation. IOKit might be one place to look for such a > >> feature. The Mach kernel documentation is another place that might have > >> what we want. > > > > Those might be a good place to start. IOKit provides the drivers and also > > the io registry which is probably where you can get if a driver is bound to > > a device and which one is it. How to dissociate the driver from the device > > though I don't know. > > https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/DeviceRemoval/DeviceRemoval.html > According to this article a driver has a stop() and detach() method that is > called by the IOKit to remove a device. I'm thinking QEMU can be the one that > calls
Re: Mac OS real USB device support issue
On Tue, Apr 6, 2021 at 3:44 PM Programmingkid wrote: > > Hi Gerd, > > I was wondering if you had access to a Mac OS 10 or Mac OS 11 machine to test > USB support. I am on Mac OS 11.1 and cannot make USB devices work with any of > my guests. So far these are the guests I have tested with: > > - Windows 7 > - Mac OS 9.2 > - Windows 2000 > > I have tried using USB flash drives, USB sound cards, and an USB headset. > They all show up under 'info usb', but cannot be used in the guest. My setup > does use a USB-C hub so I'm not sure if this is a bug with QEMU or an issue > with the hub. Would you have any information on this issue? Hi John, As far as the Mac OS 9.2 guest is concerned on a mac OS host, it does not support USB 2.0. I was successful only in passing through a USB flash drive that was forced into USB 1.1 mode by connecting it to a real USB 1.1 hub and unloading the kext it used. Best, Howard
Re: [Bug 1850570] Re: Cannot use usb-host on Mac OS
On Sun, Apr 4, 2021 at 8:30 PM John Arbuckle <1850...@bugs.launchpad.net> wrote: > > I am also having problems with using real USB devices. I tried a C-Media > USB sound card, a CISCO USB headset, and a PNY flash drive. All of them > seem to be detected by the Windows 7 guest, but can't be started for > some reason. I have tried running as root. I didn't see any libusb > errors. My Windows 2000 guest also has issues with starting the USB > sound card. > > My command-line: > sudo qemu-system-x86_64 -hda "Windows 7 HD.qcow2" -boot "c" -m 5000 -device > ich9-usb-ehci1 -device usb-host,vendorid=0x0930,productid=0x6545 > > Even when I unmount the flash drive first Mac OS 11.1 will actually > mount the flash drive when I try using it in QEMU. > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1850570 > > Title: > Cannot use usb-host on Mac OS > > Status in QEMU: > New > > Bug description: > Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives > these errors and the drive does not show up. Also, when Qemu is > starting the drive ejects and remounts twice. Qemu built with > ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl > --disable-cocoa --enable-sdl-image. > > qemu-system-i386 image.qcow -usb -device usb-kbd -device > usb-host,vendorid=0x0781,productid=0x5571 > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions > Hi John, I experience similar issues when passing through USB devices in qemu-system-ppc. macOS load a kext for the device and will not unload it when libusb tries to connect to the device. I wrote this on the emaculation site: For USB storage devices you might need to: Run a terminal and execute: sudo kextunload /System/Library/Extensions/IOUSBMassStorageDriver.kext Other devices might be using other kexts (drivers), so you would need to find out which kext is loaded for the device. Some devices might be using a kext that is also in use for other host devices. If you unload such a kext, the host will loose access to those devices. I have not yet found a way to reliably find which kexts are loaded and to unload them. Best, Howard
Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest
On Fri, Mar 26, 2021 at 8:54 PM BALATON Zoltan wrote: > > On Fri, 26 Mar 2021, Howard Spoelstra wrote: > > On Fri, Mar 26, 2021 at 10:00 AM Bin Meng wrote: > >> > >> On Fri, Mar 26, 2021 at 4:49 PM Jason Wang wrote: > >>> > >>> > >>> 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > >>>> On Fri, 26 Mar 2021, Howard Spoelstra wrote: > >>>>> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng wrote: > >>>>>> > >>>>>> Hi Howard, > >>>>>> > >>>>>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > >>>>>> wrote: > >>>>>>> > >>>>>>> (adding the relevant people to the cc list) > >>>>>>> > >>>>>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes > >>>>>>>> when > >>>>>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > >>>>>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > >>>>>>>> with the default ethernet connection. It gets activated when I start > >>>>>>>> qemu. > >>>>>>>> > >>>>>>>> To reproduce, compile qemu-system-ppc from current source and run: > >>>>>>>> > >>>>>>>> qemu-system-ppc.exe ^ > >>>>>>>> -L pc-bios ^ > >>>>>>>> -M mac99 ^ > >>>>>>>> -m 128 ^ > >>>>>>>> -sdl -serial stdio ^ > >>>>>>>> -boot c ^ > >>>>>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > >>>>>>>> -device sungem,netdev=network01 -netdev > >>>>>>>> tap,ifname=TapQemu,id=network01 > >>>>>>>> > >>>>>>>> I bisected to the commit below. Thanks for looking into this. > >>>>>> > >>>>>> Thanks for reporting. > >>>>>> > >>>>>> Can you please provide some further information: > >>>>>> > >>>>>> 1. Does "-net user" work on Windows? > >>>>>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > >>>>>> > >>>>>> Regards, > >>>>>> Bin > >>>>> > >>>>> Hello Bin, > >>>>> > >>>>> Thanks for getting back to me. I forgot to mention that reverting the > >>>>> above patch restores functionality. And that other applications using > >>>>> the same tap device work correctly. > >>>>> In answer to your questions: > >>>>> > >>>>> 1. Yes, slirp works on Windows 10 with this setup. > >>>>> 2. Yes, in Linux both tap and slirp work. > >>>>> > >>>>> My Windows build is done with a fully up to date msys2 installation. > >>>>> > >>>>> I tried to debug in Windows: > >>>>> (gdb) run > >>>>> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > >>>>> -M mac99 -m 128 -sdl -serial stdio -boot c -drive > >>>>> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > >>>>> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > >>>>> [New Thread 13304.0x1f00] > >>>>> [New Thread 13304.0x2f84] > >>>>> [New Thread 13304.0x3524] > >>>>> [New Thread 13304.0x2b8c] > >>>>> [New Thread 13304.0x368c] > >>>>> [New Thread 13304.0x3668] > >>>>> [New Thread 13304.0xf4c] > >>>>> [New Thread 13304.0x49c] > >>>>> [New Thread 13304.0x1d4c] > >>>>> [New Thread 13304.0x7fc] > >>>>> [Thread 13304.0x7fc exited with code 0] > >>>>> [New Thread 13304.0x357c] > >>>>> [New Thread 13304.0x7c0] > >>>>> [New Thread 13304.0x3564] > >>>>> [New Thread 13304.0x26f4] >
Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest
On Fri, Mar 26, 2021 at 10:00 AM Bin Meng wrote: > > On Fri, Mar 26, 2021 at 4:49 PM Jason Wang wrote: > > > > > > 在 2021/3/26 下午4:21, BALATON Zoltan 写道: > > > On Fri, 26 Mar 2021, Howard Spoelstra wrote: > > >> On Fri, Mar 26, 2021 at 2:50 AM Bin Meng wrote: > > >>> > > >>> Hi Howard, > > >>> > > >>> On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > > >>> wrote: > > >>>> > > >>>> (adding the relevant people to the cc list) > > >>>> > > >>>> On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra > > >>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> When running qemu-system-ppc with Mac OS guest, the guest crashes > > >>>>> when > > >>>>> using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > >>>>> with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > >>>>> with the default ethernet connection. It gets activated when I start > > >>>>> qemu. > > >>>>> > > >>>>> To reproduce, compile qemu-system-ppc from current source and run: > > >>>>> > > >>>>> qemu-system-ppc.exe ^ > > >>>>> -L pc-bios ^ > > >>>>> -M mac99 ^ > > >>>>> -m 128 ^ > > >>>>> -sdl -serial stdio ^ > > >>>>> -boot c ^ > > >>>>> -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > >>>>> -device sungem,netdev=network01 -netdev > > >>>>> tap,ifname=TapQemu,id=network01 > > >>>>> > > >>>>> I bisected to the commit below. Thanks for looking into this. > > >>> > > >>> Thanks for reporting. > > >>> > > >>> Can you please provide some further information: > > >>> > > >>> 1. Does "-net user" work on Windows? > > >>> 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > > >>> > > >>> Regards, > > >>> Bin > > >> > > >> Hello Bin, > > >> > > >> Thanks for getting back to me. I forgot to mention that reverting the > > >> above patch restores functionality. And that other applications using > > >> the same tap device work correctly. > > >> In answer to your questions: > > >> > > >> 1. Yes, slirp works on Windows 10 with this setup. > > >> 2. Yes, in Linux both tap and slirp work. > > >> > > >> My Windows build is done with a fully up to date msys2 installation. > > >> > > >> I tried to debug in Windows: > > >> (gdb) run > > >> Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > > >> -M mac99 -m 128 -sdl -serial stdio -boot c -drive > > >> "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > > >> "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > > >> [New Thread 13304.0x1f00] > > >> [New Thread 13304.0x2f84] > > >> [New Thread 13304.0x3524] > > >> [New Thread 13304.0x2b8c] > > >> [New Thread 13304.0x368c] > > >> [New Thread 13304.0x3668] > > >> [New Thread 13304.0xf4c] > > >> [New Thread 13304.0x49c] > > >> [New Thread 13304.0x1d4c] > > >> [New Thread 13304.0x7fc] > > >> [Thread 13304.0x7fc exited with code 0] > > >> [New Thread 13304.0x357c] > > >> [New Thread 13304.0x7c0] > > >> [New Thread 13304.0x3564] > > >> [New Thread 13304.0x26f4] > > >> [New Thread 13304.0x2f68] > > >> > > >> Program received signal SIGSEGV, Segmentation fault. > > >> 0x7ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > >> (gdb) bt > > >> #0 0x7ffb9edea991 in ?? () from > > >> c:\qemu-master-msys2\libglib-2.0-0.dll > > >> #1 0x00080480bf50 in ?? () > > >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > >> (gdb) > > >> > > >> Even before I could attach to the process. > > > > > > If you run QEMU under gdb you don't have to attach to it but to get a > &g
Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest
Hi Bin, (I forgot to reply to all) > > In answer to your questions: > > > > 1. Yes, slirp works on Windows 10 with this setup. > > 2. Yes, in Linux both tap and slirp work. > > Thanks! Just to be clear, the above testing was performed with commit > 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7, right? > Yes, the test is based on current master, so including that commit. As said, reverting it restores tap functionality in Windows. > > > > My Windows build is done with a fully up to date msys2 installation. > > > > I tried to debug in Windows: > > (gdb) run > > Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios > > -M mac99 -m 128 -sdl -serial stdio -boot c -drive > > "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device > > "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S > > [New Thread 13304.0x1f00] > > [New Thread 13304.0x2f84] > > [New Thread 13304.0x3524] > > [New Thread 13304.0x2b8c] > > [New Thread 13304.0x368c] > > [New Thread 13304.0x3668] > > [New Thread 13304.0xf4c] > > [New Thread 13304.0x49c] > > [New Thread 13304.0x1d4c] > > [New Thread 13304.0x7fc] > > [Thread 13304.0x7fc exited with code 0] > > [New Thread 13304.0x357c] > > [New Thread 13304.0x7c0] > > [New Thread 13304.0x3564] > > [New Thread 13304.0x26f4] > > [New Thread 13304.0x2f68] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x7ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > (gdb) bt > > #0 0x7ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll > > #1 0x00080480bf50 in ?? () > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > (gdb) > > > > Even before I could attach to the process. > > Is QEMU crashed, or the MacOS guest crashed? Well, that is an interesting question. qemu-system-ppc -M mac99 uses openbios and it crashes while still in the openbios window just when it tries to boot the hd. Besides Mac OS 9.2, I now also tried booting a Mac OS X 10.3 image and it crashes just the same. Tracing the default sungem network device shows: C:\qemu-master-msys2>qemu-system-ppc.exe -L pc-bios -M mac99 -m 128 -sdl -serial stdio -boot c -drive file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media= disk -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 -trace "sung*" sungem_reset Full reset (PCI:1) sungem_rx_reset RX reset sungem_tx_reset TX reset sungem_reset Full reset (PCI:1) sungem_rx_reset RX reset sungem_tx_reset TX reset sungem_rx_mac_disabled Check RX MAC disabled sungem_rx_mac_disabled Check RX MAC disabled sungem_rx_mac_disabled Check RX MAC disabled sungem_mmio_mac_read MMIO mac read from 0x80 val=0x3456 sungem_mmio_mac_read MMIO mac read from 0x84 val=0x12 sungem_mmio_mac_read MMIO mac read from 0x88 val=0x5254 >> = >> OpenBIOS 1.1 [Mar 16 2021 08:16] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: ---- >> CPU type PowerPC,G4 milliseconds isn't unique. Best, Howard
Re: Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest
On Fri, Mar 26, 2021 at 2:50 AM Bin Meng wrote: > > Hi Howard, > > On Fri, Mar 26, 2021 at 1:35 AM Peter Maydell > wrote: > > > > (adding the relevant people to the cc list) > > > > On Thu, 25 Mar 2021 at 17:26, Howard Spoelstra wrote: > > > > > > Hi, > > > > > > When running qemu-system-ppc with Mac OS guest, the guest crashes when > > > using a tap network connection. Openvpn 2.4.9-I601-win10 is installed > > > with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged > > > with the default ethernet connection. It gets activated when I start > > > qemu. > > > > > > To reproduce, compile qemu-system-ppc from current source and run: > > > > > > qemu-system-ppc.exe ^ > > > -L pc-bios ^ > > > -M mac99 ^ > > > -m 128 ^ > > > -sdl -serial stdio ^ > > > -boot c ^ > > > -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ > > > -device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01 > > > > > > I bisected to the commit below. Thanks for looking into this. > > Thanks for reporting. > > Can you please provide some further information: > > 1. Does "-net user" work on Windows? > 2. If running QEMU under Linux, does "-net tap" or "-net user" work? > > Regards, > Bin Hello Bin, Thanks for getting back to me. I forgot to mention that reverting the above patch restores functionality. And that other applications using the same tap device work correctly. In answer to your questions: 1. Yes, slirp works on Windows 10 with this setup. 2. Yes, in Linux both tap and slirp work. My Windows build is done with a fully up to date msys2 installation. I tried to debug in Windows: (gdb) run Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L pc-bios -M mac99 -m 128 -sdl -serial stdio -boot c -drive "file=C:\Mac-disks\9.2-usb-pci-ddk.img,format=raw,media=disk" -device "sungem,netdev=network01" -netdev "tap,ifname=TapQemu,id=network01" -S [New Thread 13304.0x1f00] [New Thread 13304.0x2f84] [New Thread 13304.0x3524] [New Thread 13304.0x2b8c] [New Thread 13304.0x368c] [New Thread 13304.0x3668] [New Thread 13304.0xf4c] [New Thread 13304.0x49c] [New Thread 13304.0x1d4c] [New Thread 13304.0x7fc] [Thread 13304.0x7fc exited with code 0] [New Thread 13304.0x357c] [New Thread 13304.0x7c0] [New Thread 13304.0x3564] [New Thread 13304.0x26f4] [New Thread 13304.0x2f68] Program received signal SIGSEGV, Segmentation fault. 0x7ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll (gdb) bt #0 0x7ffb9edea991 in ?? () from c:\qemu-master-msys2\libglib-2.0-0.dll #1 0x00080480bf50 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) Even before I could attach to the process. Best, Howard
Bug with Windows tap network when running qemu-system-ppc with Mac OS 9 guest
Hi,
When running qemu-system-ppc with Mac OS guest, the guest crashes when
using a tap network connection. Openvpn 2.4.9-I601-win10 is installed
with TAP-Windows 9.24.2. A tap connection called TapQemu is bridged
with the default ethernet connection. It gets activated when I start
qemu.
To reproduce, compile qemu-system-ppc from current source and run:
qemu-system-ppc.exe ^
-L pc-bios ^
-M mac99 ^
-m 128 ^
-sdl -serial stdio ^
-boot c ^
-drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^
-device sungem,netdev=network01 -netdev tap,ifname=TapQemu,id=network01
I bisected to the commit below. Thanks for looking into this.
Best,
Howard
969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 is the first bad commit
commit 969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7
Author: Bin Meng
Date: Wed Mar 17 14:26:29 2021 +0800
net: Pad short frames to minimum size before sending from SLiRP/TAP
The minimum Ethernet frame length is 60 bytes. For short frames with
smaller length like ARP packets (only 42 bytes), on a real world NIC
it can choose either padding its length to the minimum required 60
bytes, or sending it out directly to the wire. Such behavior can be
hardcoded or controled by a register bit. Similarly on the receive
path, NICs can choose either dropping such short frames directly or
handing them over to software to handle.
On the other hand, for the network backends like SLiRP/TAP, they
don't expose a way to control the short frame behavior. As of today
they just send/receive data from/to the other end connected to them,
which means any sized packet is acceptable. So they can send and
receive short frames without any problem. It is observed that ARP
packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send
these ARP packets to the other end which might be a NIC model that
does not allow short frames to pass through.
To provide better compatibility, for packets sent from QEMU network
backends like SLiRP/TAP, we change to pad short frames before sending
it out to the other end, if the other end does not forbid it via the
nc->do_not_pad flag. This ensures a backend as an Ethernet sender
does not violate the spec. But with this change, the behavior of
dropping short frames from SLiRP/TAP interfaces in the NIC model
cannot be emulated because it always receives a packet that is spec
complaint. The capability of sending short frames from NIC models is
still supported and short frames can still pass through SLiRP/TAP.
This commit should be able to fix the issue as reported with some
NIC models before, that ARP requests get dropped, preventing the
guest from becoming visible on the network. It was workarounded in
these NIC models on the receive path, that when a short frame is
received, it is padded up to 60 bytes.
The following 2 commits seem to be the one to workaround this issue
in e1000 and vmxenet3 before, and should probably be reverted.
commit 78aeb23eded2 ("e1000: Pad short frames to minimum size (60 bytes)")
commit 40a87c6c9b11 ("vmxnet3: Pad short frames to minimum size
(60 bytes)")
Signed-off-by: Bin Meng
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Jason Wang
net/slirp.c | 10 ++
net/tap-win32.c | 10 ++
net/tap.c | 10 ++
3 files changed, 30 insertions(+)
usb-audio and Mac OS 9.x guests on qemu-system-ppc
Hi Gerd, I'm having issues with -device usb-audio and Mac OS 9.x guests on qemu-system-ppc. Command line used: ./qemu-system-ppc -M mac99 -L pc-bios \ -m 512 -boot c \ -device usb-audio \ -drive file=MacOS9.0.img,format=raw,media=disk \ -trace "usb*" Some logging below from Mac OS 9.0 and Fedora 12 guests. A screen shot of some usb logging inside the Mac OS 9 guest is also attached. For Mac OS 9.0 guest -trace "usb*" shows: usb_ohci_mem_write_bad_offset 0x30 (which also happens with -device usb-mouse and -device usb-kbd.) usb_ohci_td_packet_status status=0 usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 Log halts here, unless usb is probed from inside the guest with usb probe tool. After this probing, logging continues, but the guest desktop then becomes unresponsive after some time. (When I also use -device usb-mouse and -device usb-kbd, I can see in the logging that these device are actually still working even though mouse clicks are no longer consumed by the OS) When logging with Fedora12 guest, I see this a this stage: usb_ohci_td_packet_status status=0 usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 Before the Mac OS desktop becomes unresponsive I see (what seems to me) a load of retries in iso transfers. frame_number 0xfa3f starting_frame 0xfa3e frame_count 0x0007 relative 1 frame_number 0xfa40 starting_frame 0xfa3e frame_count 0x0007 relative 2 frame_number 0xfa41 starting_frame 0xfa3e frame_count 0x0007 relative 3 frame_number 0xfa42 starting_frame 0xfa3e frame_count 0x0007 relative 4 etcup to relative 7 or so, continuing for thousands of lines. A log from Fedora 12 guest shows that these frames mostly are relative 0: frame_number 0x5358 starting_frame 0x5358 frame_count 0x relative 0 In the log on the Mac OS 9.0 side (screen shot attached) I see isoch transfers that seem faulty as it mentions that frames are called from too far ahead. It also mentions that that a "wr gap" is becoming too to big. Finally the sytem becomes unresponsive. Perhaps you have some idea what might be causing these issues and the hangup? And what causes the bad_offset? I searched around in the qemu archives and found an email (from 2015) adressing usb-audio and Mac OS guests, in which it was suggested that a buffer increase could help. Best, Howard
Re: problema compilation
On Sat, Feb 20, 2021 at 9:42 AM Stefan Weil wrote: > > Am 20.02.21 um 00:07 schrieb Philippe Mathieu-Daudé: > > > Cc'ing Stefan / Yonggang / Paolo. > > > > On 2/20/21 12:03 AM, Peter Maydell wrote: > >> On Fri, 19 Feb 2021 at 22:54, nerus wrote: > >>> Good evening, I turn to you because I have a problem that does not appear > >>> in the official documentation, nor in the different blogs or irc channels. > >>> > >>> I need to do a cross compilation but it is impossible from version 5.2, > >>> when I use msys2 an error occurs indicating that symbolic links cannot be > >>> created even though the windows user has permissions to create symbolic > >>> links, I configured this through gpedit.msc. > >>> > >>> when I use cygwin with the mingw64-w64 tool chain an error occurs whereby > >>> meson says that it cannot find any compiler even though the compiler path > >>> is specified in the configuration script, mingw cannot be used from linux > >>> either due to There are many missing components that cannot be compiled > >>> by hand because the proper versions are no longer available, how could > >>> you solve these problems without using already compiled binaries? Thank > >>> you > > > The only tested build settings for producing 5.2 and newer Windows > binaries use Mingw-w64 cross tools on Linux. Up to now I did not try > building 5.2 on Windows. > > Depending on the Linux distribution there are more or less missing > components. > > As far as I know Fedora provides a rather complete list of cross > packages which not only covers the cross tools but also the required > other components (libraries). > > Debian based distributions only provide the cross tools (compiler, > linker, nsis). It should be possible to compile all required libraries > by hand, but of course that is a lot of work. I recently did that for > the braille library, and it took me about a day to get 32 and 64 bit > binaries. Therefore I use Debian with the Mingw-w64 library cross > packages from Cygwin. My GitHub repository includes a GitHub action > which runs the cross builds: > https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh. > That should also work on Windows with the Windows Subsystem for Linux (WSL). > > Recently (with bullseye and later) Debian changed the exception handling > for the 64 bit C++ cross compiler. Therefore Debian bullseye and similar > distributions can no longer be used with the Cygwin libraries. I still > have no solution for that. > > Stefan > > > >> Cross compilation works in general -- our CI testing setup > >> includes various cross-compile configurations, including > >> building Windows executables from a Linux host > >> (eg https://gitlab.com/qemu-project/qemu/-/jobs/1042844159). > >> > >> You'll need to be more specific about exactly what you're > >> trying to do and failing (eg quoting exact commands, > >> setups, error messages). Hi, I still use: https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 And it works without allowing symbolic links. I used to need to set that right to allowed, but it seems that is no longer the case and so I retracted it. Note that I do get a single warning about symlinks: ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc': No such file or directory. But that does not prevent a successful build. If you set the symbolic link right, you should also uncomment #MSYS=winsymlinks:nativestrict in both msys2.ini and mingw64.ini Best, Howard
Re: [PATCH v4] net/macos: implement vmnet-based netdev
On Thu, Feb 18, 2021 at 2:49 PM wrote: > > From: Phillip Tennen > > This patch implements a new netdev device, reachable via -netdev > vmnet-macos, that’s backed by macOS’s vmnet framework. > > The vmnet framework provides native bridging support, and its usage in > this patch is intended as a replacement for attempts to use a tap device > via the tuntaposx kernel extension. Notably, the tap/tuntaposx approach > never would have worked in the first place, as QEMU interacts with the > tap device via poll(), and macOS does not support polling device files. > > vmnet requires either a special entitlement, granted via a provisioning > profile, or root access. Otherwise attempts to create the virtual > interface will fail with a “generic error” status code. QEMU may not > currently be signed with an entitlement granted in a provisioning > profile, as this would necessitate pre-signed binary build distribution, > rather than source-code distribution. As such, using this netdev > currently requires that qemu be run with root access. I’ve opened a > feedback report with Apple to allow the use of the relevant entitlement > with this use case: > https://openradar.appspot.com/radar?id=5007417364447232 > > vmnet offers three operating modes, all of which are supported by this > patch via the “mode=host|shared|bridge” option: > > * "Host" mode: Allows the vmnet interface to communicate with other > * vmnet > interfaces that are in host mode and also with the native host. > * "Shared" mode: Allows traffic originating from the vmnet interface to > reach the Internet through a NAT. The vmnet interface can also > communicate with the native host. > * "Bridged" mode: Bridges the vmnet interface with a physical network > interface. > > Each of these modes also provide some extra configuration that’s > supported by this patch: > > * "Bridged" mode: The user may specify the physical interface to bridge > with. Defaults to en0. > * "Host" mode / "Shared" mode: The user may specify the DHCP range and > subnet. Allocated by vmnet if not provided. > > vmnet also offers some extra configuration options that are not > supported by this patch: > > * Enable isolation from other VMs using vmnet > * Port forwarding rules > * Enabling TCP segmentation offload > * Only applicable in "shared" mode: specifying the NAT IPv6 prefix > * Only available in "host" mode: specifying the IP address for the VM > within an isolated network > > Note that this patch requires macOS 10.15 as a minimum, as this is when > bridging support was implemented in vmnet.framework. > > Signed-off-by: Phillip Tennen Hi Phillip, Thanks for the updated patch. I have a small problem applying it with either git am or patch. I have to manually fix configure. This has been the case from v1 up to now: hsp@hsps-Catalina-VB qemu-master % patch -p1 < ../patches/qemu/v4-net-macos-implement-vmnet-based-netdev.patch patching file configure Hunk #1 FAILED at 778. 1 out of 1 hunk FAILED -- saving rejects to file configure.rej patching file net/clients.h patching file net/meson.build patching file net/net.c patching file net/vmnet-macos.c patching file qapi/net.json patching file qemu-options.hx Hunk #1 succeeded at 2507 (offset 24 lines). Best, Howard
Re: USB pass through into Mac OS 9.x with qemu-system-ppc
On Tue, Feb 16, 2021 at 4:42 PM Howard Spoelstra wrote: > > On Tue, Feb 16, 2021 at 3:48 PM Gerd Hoffmann wrote: > > > > Hi, > > > > > Please find another pcap file attached. This one stems from an attempt > > > to pass through a midi device when running qemu-system-ppc with Mac OS > > > 9.2 in macOS host. > > > > Ah, yes, I remember now. Problem is that the usb stick is plugged into > > a high-speed port (usb2) on the host but passed as full-speed device > > (usb1) to the guest. That works in some cases, but is not guaranteed > > to work. usb_host_speed_compat() tries to catch some of the > > incompatible cases. The usb-storage incompatibility slips through > > because the incompatibility is specific to the mass storage protocol. > > Specifically the wMaxPacketSize is 64 for usb1 and 512 for usb2. > > > > Seems fedora deals better with the situation ... > > > > take care, > > Gerd > > > > Hi Gerd, > > Thanks for looking into this. It looks to me that the usb storage > device nicely reports endpoints 1 and 2 when asked, but that the host > only ever communicates with endpoint 1. > Is that the issue you refer to, or might that be libusb related? > > Can this also explain that other (non-mass-storage) devices cannot be > passed through successfully ? > > Best, > Howard Hi Gerd, Thanks for the explanation. I've been successful in passing through an USB 2.0 stick into Mac OS 9.x when connected to a real USB 1.1 hub in a old Apple keyboard. This at least gives some perspective to connect other devices as well. So we can consider this quest finished ;-) Best, Howard
Re: USB pass through into Mac OS 9.x with qemu-system-ppc
On Tue, Feb 16, 2021 at 3:48 PM Gerd Hoffmann wrote: > > Hi, > > > Please find another pcap file attached. This one stems from an attempt > > to pass through a midi device when running qemu-system-ppc with Mac OS > > 9.2 in macOS host. > > Ah, yes, I remember now. Problem is that the usb stick is plugged into > a high-speed port (usb2) on the host but passed as full-speed device > (usb1) to the guest. That works in some cases, but is not guaranteed > to work. usb_host_speed_compat() tries to catch some of the > incompatible cases. The usb-storage incompatibility slips through > because the incompatibility is specific to the mass storage protocol. > Specifically the wMaxPacketSize is 64 for usb1 and 512 for usb2. > > Seems fedora deals better with the situation ... > > take care, > Gerd > Hi Gerd, Thanks for looking into this. It looks to me that the usb storage device nicely reports endpoints 1 and 2 when asked, but that the host only ever communicates with endpoint 1. Is that the issue you refer to, or might that be libusb related? Can this also explain that other (non-mass-storage) devices cannot be passed through successfully ? Best, Howard
Re: USB pass through into Mac OS 9.x with qemu-system-ppc
On Tue, Feb 9, 2021 at 6:17 PM Howard Spoelstra wrote: > > > > On Tue, Feb 9, 2021 at 4:12 PM Gerd Hoffmann wrote: >> >> Hi, >> >> > A noticeable issue when comparing the pcap files seems to be at Fedora pcap >> > frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems >> > the Mac OS side is missing 5 bytes and hence the packet is malformed. >> > (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte >> > in the response.) >> >> That is normal. Note that the configuration descriptor is requested >> twice: Once with a buffer large enough to see the wTotalLength field. >> and then again with a buffer large enough for the whole descriptor. >> >> > Also visible in the Mac OS pcap file at frame 53 is that it seems a setup >> > package is contained in an URB that is not suited for it. >> >> Looks more like a bug in the qemu pcap code, probably have to set some >> flag to indicate the setup section doesn't contain valid data instead >> of just leaving it all blank. >> >> Frame 55 is probably the problematic one. Look at the timestamps. The >> device seems to not answer, then after a while macos seems to try reset >> the device. >> >> Also the fedora trace has the bulk transfer data so wireshark can decode >> usb-storage commands and the scsi command wrapped inside. That is not >> the case in the macos trace. Not sure whenever that is another bug in >> the pcap code. It could also indicate the bug in the ohci emulation >> which in turn causes macos fail ... >> >> > Qemu-system-ppc is started like this for the Mac OS guest: >> > ./qemu-system-ppc \ >> > -M mac99,via=pmu \ >> > -m 512 \ >> > -boot c \ >> > -serial stdio \ >> > -L pc-bios \ >> > -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \ >> > -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap >> >> Does an emulated usb stick work with macos? >> > Hi Gerd, > > Thanks for getting back to me. > Yes, usb-storage works just fine with > > -drive if=none,id=stick,file=/home/hsp/Mac-disks/9.0.img,format=raw \ > -device usb-storage,drive=stick > > Best, > Howard Hi Gerd, Please find another pcap file attached. This one stems from an attempt to pass through a midi device when running qemu-system-ppc with Mac OS 9.2 in macOS host. In case you'd like to run a MacOS 9.2 guest yourself, I've prepared a zipped disk image to do just that: https://surfdrive.surf.nl/files/index.php/s/jalNAWL3Fkehts4/download Best, Howard usblog.pcap Description: Binary data
Re: [PATCH v2] net/macos: implement vmnet-based network device
On Fri, Feb 5, 2021 at 5:54 PM wrote: > > From: Phillip Tennen > > This patch implements a new netdev device, reachable via -netdev > vmnet-macos, that’s backed by macOS’s vmnet framework. > > The vmnet framework provides native bridging support, and its usage in > this patch is intended as a replacement for attempts to use a tap device > via the tuntaposx kernel extension. Notably, the tap/tuntaposx approach > never would have worked in the first place, as QEMU interacts with the > tap device via poll(), and macOS does not support polling device files. > > vmnet requires either a special entitlement, granted via a provisioning > profile, or root access. Otherwise attempts to create the virtual > interface will fail with a “generic error” status code. QEMU may not > currently be signed with an entitlement granted in a provisioning > profile, as this would necessitate pre-signed binary build distribution, > rather than source-code distribution. As such, using this netdev > currently requires that qemu be run with root access. I’ve opened a > feedback report with Apple to allow the use of the relevant entitlement > with this use case: > https://openradar.appspot.com/radar?id=5007417364447232 > > vmnet offers three operating modes, all of which are supported by this > patch via the “mode=host|shared|bridge” option: > > * "Host" mode: Allows the vmnet interface to communicate with other > * vmnet > interfaces that are in host mode and also with the native host. > * "Shared" mode: Allows traffic originating from the vmnet interface to > reach the Internet through a NAT. The vmnet interface can also > communicate with the native host. > * "Bridged" mode: Bridges the vmnet interface with a physical network > interface. > > Each of these modes also provide some extra configuration that’s > supported by this patch: > > * "Bridged" mode: The user may specify the physical interface to bridge > with. Defaults to en0. > * "Host" mode / "Shared" mode: The user may specify the DHCP range and > subnet. Allocated by vmnet if not provided. > > vmnet also offers some extra configuration options that are not > supported by this patch: > > * Enable isolation from other VMs using vmnet > * Port forwarding rules > * Enabling TCP segmentation offload > * Only applicable in "shared" mode: specifying the NAT IPv6 prefix > * Only available in "host" mode: specifying the IP address for the VM > within an isolated network > > Note that this patch requires macOS 10.15 as a minimum, as this is when > bridging support was implemented in vmnet.framework. > > Signed-off-by: Phillip Tennen > Hi Phillip, Thank you very much for this patch. As you wrote it should apply from 10.15 upwards. I have no problem building on Big Sur, but Catalina stumbles. See below. Latest Xcode installed, other requirements installed through brew. Thanks for looking into this, Best, Howard [1181/2135] Compiling C object libcommon.fa.p/net_vmnet-macos.c.o FAILED: libcommon.fa.p/net_vmnet-macos.c.o cc -Ilibcommon.fa.p -I. -I.. -I../capstone/include/capstone -I../dtc/libfdt -I../slirp -I../slirp/src -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/Cellar/libffi/3.3_2/include -I/usr/local/Cellar/glib/2.66.6/include -I/usr/local/Cellar/glib/2.66.6/include/glib-2.0 -I/usr/local/Cellar/glib/2.66.6/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.44/include -I/usr/local/Cellar/glib/2.66.6/include/gio-unix-2.0 -I/usr/local/Cellar/libusb/1.0.24/include/libusb-1.0 -I/usr/local/Cellar/pixman/0.40.0/include/pixman-1 -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -std=gnu99 -O2 -g -iquote . -iquote /Users/hsp/src/qemu-master -iquote /Users/hsp/src/qemu-master/include -iquote /Users/hsp/src/qemu-master/disas/libvixl -iquote /Users/hsp/src/qemu-master/tcg/i386 -iquote /Users/hsp/src/qemu-master/accel/tcg -m64 -mcx16 -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.fa.p/net_vmnet-macos.c.o -MF libcommon.fa.p/net_vmnet-macos.c.o.d -o libcommon.fa.p/net_vmnet-macos.c.o -c ../net/vmnet-macos.c ../net/vmnet-macos.c:54:10: error: use of undeclared identifier 'VMNET_SHARING_SERVICE_BUSY' case VMNET_SHARING_SERVICE_BUSY: ^
Re: USB pass through into Mac OS 9.x with qemu-system-ppc
On Tue, Feb 9, 2021 at 4:12 PM Gerd Hoffmann wrote: > Hi, > > > A noticeable issue when comparing the pcap files seems to be at Fedora > pcap > > frame 8 and Mac OS 9.2 pcap frame 28 (configuration descriptor). It seems > > the Mac OS side is missing 5 bytes and hence the packet is malformed. > > (A run with Mac OS 9.0 as guest showed that this guest only missed 1 byte > > in the response.) > > That is normal. Note that the configuration descriptor is requested > twice: Once with a buffer large enough to see the wTotalLength field. > and then again with a buffer large enough for the whole descriptor. > > > Also visible in the Mac OS pcap file at frame 53 is that it seems a setup > > package is contained in an URB that is not suited for it. > > Looks more like a bug in the qemu pcap code, probably have to set some > flag to indicate the setup section doesn't contain valid data instead > of just leaving it all blank. > > Frame 55 is probably the problematic one. Look at the timestamps. The > device seems to not answer, then after a while macos seems to try reset > the device. > > Also the fedora trace has the bulk transfer data so wireshark can decode > usb-storage commands and the scsi command wrapped inside. That is not > the case in the macos trace. Not sure whenever that is another bug in > the pcap code. It could also indicate the bug in the ohci emulation > which in turn causes macos fail ... > > > Qemu-system-ppc is started like this for the Mac OS guest: > > ./qemu-system-ppc \ > > -M mac99,via=pmu \ > > -m 512 \ > > -boot c \ > > -serial stdio \ > > -L pc-bios \ > > -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \ > > -device usb-host,vendorid=0x058f,productid=0x6387,pcap=macos92.pcap > > Does an emulated usb stick work with macos? > > Hi Gerd, Thanks for getting back to me. Yes, usb-storage works just fine with -drive if=none,id=stick,file=/home/hsp/Mac-disks/9.0.img,format=raw \ -device usb-storage,drive=stick Best, Howard
Bug: qemu-system-ppc -M mac99 boots into compat-monitor, not openbios.
Hi all, It seems a qemu-system-ppc from current master no longer boots into openbios, but into to the compat monitor. Command line to reproduce: /home/hsp/src/qemu-master/build/qemu-system-ppc \ -L pc-bios \ -M mac99,via=pmu -m 1024 -boot c \ -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk Bisecting leads to this commit: commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 Author: Paolo Bonzini Date: Tue Oct 27 08:44:23 2020 -0400 vl: remove separate preconfig main_loop Move post-preconfig initialization to the x-exit-preconfig. If preconfig is not requested, just exit preconfig mode immediately with the QMP command. As a result, the preconfig loop will run with accel_setup_post and os_setup_post restrictions (xen_restrict, chroot, etc.) already done. Reviewed-by: Igor Mammedov Signed-off-by: Paolo Bonzini include/sysemu/runstate.h | 1 - monitor/qmp-cmds.c| 9 - softmmu/vl.c | 95 --- 3 files changed, 41 insertions(+), 64 deletions(-) Thanks for looking into this, Best, Howard
Re: aio_poll() assertion fail on Windows
On Fri, Oct 16, 2020 at 1:32 PM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > Whilst testing a Windows build of git master of qemu-system-ppc in > MSYS2/MingW64 I > noticed the following assertion message in the console after booting into > OpenBIOS > and then closing the GTK GUI window without booting a client OS: > > $ ./qemu-system-ppc > ** > ERROR:../util/aio-win32.c:337:aio_poll: assertion failed: > (in_aio_context_home_thread(ctx)) > Bail out! ERROR:../util/aio-win32.c:337:aio_poll: assertion failed: > (in_aio_context_home_thread(ctx)) > > Has anyone else seen this at all? > > > ATB, > > Mark. > > Same here with SDL and GTK. C:\qemu-master-msys2>qemu-system-ppc.exe -L pc-bios -sdl -boot c -m 512 -M mac99,via=pmu ** ERROR:../util/aio-win32.c:337:aio_poll: assertion failed: (in_aio_context_home_thread(ctx)) Bail out! ERROR:../util/aio-win32.c:337:aio_poll: assertion failed: (in_aio_context_home_thread(ctx)) Best, Howard
Re: [PATCH v2 2/3] grackle: use qdev gpios for PCI IRQs
On Fri, Oct 16, 2020 at 2:30 AM David Gibson
wrote:
> On Tue, Oct 13, 2020 at 12:49:21PM +0100, Mark Cave-Ayland wrote:
> > Currently an object link property is used to pass a reference to the
> Heathrow
> > PIC into the PCI host bridge so that grackle_init_irqs() can connect the
> PCI
> > IRQs to the PIC itself.
> >
> > This can be simplified by defining the PCI IRQs as qdev gpios and then
> wiring
> > up the PCI IRQs to the PIC in the Old World machine init function.
> >
> > Signed-off-by: Mark Cave-Ayland
>
> Applied to ppc-for-5.2.
>
> > ---
> > hw/pci-host/grackle.c | 19 ++-
> > hw/ppc/mac_oldworld.c | 7 +--
> > 2 files changed, 7 insertions(+), 19 deletions(-)
> >
> > diff --git a/hw/pci-host/grackle.c b/hw/pci-host/grackle.c
> > index 57c29b20af..b05facf463 100644
> > --- a/hw/pci-host/grackle.c
> > +++ b/hw/pci-host/grackle.c
> > @@ -28,7 +28,6 @@
> > #include "hw/ppc/mac.h"
> > #include "hw/qdev-properties.h"
> > #include "hw/pci/pci.h"
> > -#include "hw/intc/heathrow_pic.h"
> > #include "hw/irq.h"
> > #include "qapi/error.h"
> > #include "qemu/module.h"
> > @@ -41,7 +40,6 @@ struct GrackleState {
> > PCIHostState parent_obj;
> >
> > uint32_t ofw_addr;
> > -HeathrowState *pic;
> > qemu_irq irqs[4];
> > MemoryRegion pci_mmio;
> > MemoryRegion pci_hole;
> > @@ -62,15 +60,6 @@ static void pci_grackle_set_irq(void *opaque, int
> irq_num, int level)
> > qemu_set_irq(s->irqs[irq_num], level);
> > }
> >
> > -static void grackle_init_irqs(GrackleState *s)
> > -{
> > -int i;
> > -
> > -for (i = 0; i < ARRAY_SIZE(s->irqs); i++) {
> > -s->irqs[i] = qdev_get_gpio_in(DEVICE(s->pic), 0x15 + i);
> > -}
> > -}
> > -
> > static void grackle_realize(DeviceState *dev, Error **errp)
> > {
> > GrackleState *s = GRACKLE_PCI_HOST_BRIDGE(dev);
> > @@ -85,7 +74,6 @@ static void grackle_realize(DeviceState *dev, Error
> **errp)
> > 0, 4, TYPE_PCI_BUS);
> >
> > pci_create_simple(phb->bus, 0, "grackle");
> > -grackle_init_irqs(s);
> > }
> >
> > static void grackle_init(Object *obj)
> > @@ -106,15 +94,12 @@ static void grackle_init(Object *obj)
> > memory_region_init_io(>data_mem, obj, _host_data_le_ops,
> >DEVICE(obj), "pci-data-idx", 0x1000);
> >
> > -object_property_add_link(obj, "pic", TYPE_HEATHROW,
> > - (Object **) >pic,
> > - qdev_prop_allow_set_link_before_realize,
> > - 0);
> > -
> > sysbus_init_mmio(sbd, >conf_mem);
> > sysbus_init_mmio(sbd, >data_mem);
> > sysbus_init_mmio(sbd, >pci_hole);
> > sysbus_init_mmio(sbd, >pci_io);
> > +
> > +qdev_init_gpio_out(DEVICE(obj), s->irqs, ARRAY_SIZE(s->irqs));
> > }
> >
> > static void grackle_pci_realize(PCIDevice *d, Error **errp)
> > diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> > index d6a76d06dc..05e46ee6fe 100644
> > --- a/hw/ppc/mac_oldworld.c
> > +++ b/hw/ppc/mac_oldworld.c
> > @@ -253,10 +253,9 @@ static void ppc_heathrow_init(MachineState *machine)
> > /* Grackle PCI host bridge */
> > dev = qdev_new(TYPE_GRACKLE_PCI_HOST_BRIDGE);
> > qdev_prop_set_uint32(dev, "ofw-addr", 0x8000);
> > -object_property_set_link(OBJECT(dev), "pic", OBJECT(pic_dev),
> > - _abort);
> > s = SYS_BUS_DEVICE(dev);
> > sysbus_realize_and_unref(s, _fatal);
> > +
> > sysbus_mmio_map(s, 0, GRACKLE_BASE);
> > sysbus_mmio_map(s, 1, GRACKLE_BASE + 0x20);
> > /* PCI hole */
> > @@ -266,6 +265,10 @@ static void ppc_heathrow_init(MachineState *machine)
> > memory_region_add_subregion(get_system_memory(), 0xfe00,
> > sysbus_mmio_get_region(s, 3));
> >
> > +for (i = 0; i < 4; i++) {
> > +qdev_connect_gpio_out(dev, i, qdev_get_gpio_in(pic_dev, 0x15 +
> i));
> > +}
> > +
> > pci_bus = PCI_HOST_BRIDGE(dev)->bus;
> >
> > pci_vga_init(pci_bus);
>
>
> Hi,
I see compilation of the current ppc-for-5.2 branch fail with:
../hw/pci-host/grackle.c: In function ‘grackle_realize’:
../hw/pci-host/grackle.c:68:11: error: ‘GrackleState’ has no member named
‘pic’
68 | if (!s->pic) {
| ^~
make: *** [Makefile.ninja:1741: libcommon.fa.p/hw_pci-host_grackle.c.o]
Error 1
Best,
Howard
Re: [PATCH 0/7] build: replace ninjatool with ninja
On Thu, Oct 15, 2020 at 7:39 PM Volker Rümelin wrote: > > > > > Thanks Paolo, > > > > Then only the issue regarding the pcbios/optionrom stuff remains ;-) > > > > make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. > Stop. > > make: *** [Makefile:171: pc-bios/optionrom/all] Error 2 > > make: *** Waiting for unfinished jobs > > > > Best, > > Howard > > > > Hi Howard, > > one solution for this issue is to uncomment the following line in > msys2_shell.cmd. > > rem To activate windows native symlinks uncomment next line > set MSYS=winsymlinks:nativestrict > > Then tell Windows 10 it's okay to create symlinks without elevated rights. > Here is a link with a description how to do this. > https://www.joshkel.com/2018/01/18/symlinks-in-windows/ > > I think since commit bf708f3c4a "optionrom: simplify Makefile" > pc-bios/optionrom/Makefile in your build directory has to be a symbolic > link. Without 'set MSYS=winsymlinks:nativestrict' msys2 ln -s copies the > Makefile instead of creating a symbolic link. > > Thanks Volker! I changed the Windows policy and setting in msys2_shell.cmd. However, I had to edit ming64.ini to uncomment the MSYS=winsymlinks:nativestrict there as well to get things going. While it is great to have this fix, I can't say I'm really happy with the need to change the Windows policy and to have to fix msys2. The patches Mark referred to and to which I also pointed earlier did fix this problem without changing Windows/Msys2/Mingw64 settings. Best regards, Howard
Re: [PATCH 0/7] build: replace ninjatool with ninja
On Thu, Oct 15, 2020 at 8:34 AM Paolo Bonzini wrote: > On 15/10/20 08:15, Howard Spoelstra wrote: > > ERROR: meson setup failed > > > > When I set --ninja=ninja explicitly, this error does not occur: > > Found ninja.EXE-1.10.1 at C:\msys64\mingw64\bin/ninja.EXE > > That is fixed by Meson 0.55.2, I'll add a submodule update. Thanks for > the reminder! > > Paolo > > Thanks Paolo, Then only the issue regarding the pcbios/optionrom stuff remains ;-) make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. Stop. make: *** [Makefile:171: pc-bios/optionrom/all] Error 2 make: *** Waiting for unfinished jobs Best, Howard
Re: [PATCH 0/7] build: replace ninjatool with ninja
On Wed, Oct 14, 2020 at 3:57 PM Paolo Bonzini wrote:
> This pull request is the last build system change for 5.2 from
> me, and it is simple: similar to how we are invoking
> ROM or tests/tcg "make" from the main Makefile, we now invoke ninja
> to build QEMU. Unlike those cases, however, build.ninja targets are
> forwarded transparently.
>
> The advantages cover various areas:
>
> - maintainability: we drop scripts/ninjatool.py, which is
> a large and hairy piece of code, and generally remove one
> thing that can go wrong and one thing that is unique to QEMU;
>
> - platform support: we remove the requirement for GNU make
> 3.82, which was annoying on Mac. We also avoid bugs on Windows
> due to meson emitting Windows rather than POSIX escapes (as
> expected by Ninja) and ninjatool ignoring the difference;
>
> - speed: invoking "configure" does not have to generate
> 44k lines of rules, while invoking "Make" does not anymore have
> to parse 44k lines of rules.
>
> - ease of use: Ninja tracks command lines, hence the problem
> of static library changing the objects they hold goes away
>
> Paolo
>
>
Hi,
I still have some issues when compiling on Windows with msys2/mingw64 after
this patch set. Command line:
mkdir build && cd build && ../configure --cross-prefix=x86_64-w64-mingw32-
--target-list=ppc-softmmu --enable-gtk --enable-sdl
Traceback (most recent call last):
File "C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/mesonmain.py",
line 131, in run
return options.run_func(options)
File "C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/msetup.py",
line 245, in run
app.generate()
File "C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/msetup.py",
line 159, in generate
self._generate(env)
File "C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/msetup.py",
line 215, in _generate
intr.backend.generate()
File
"C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/backend/ninjabackend.py",
line 483, in generate
ninja = environment.detect_ninja_command_and_version(log=True)
File
"C:/msys64/home/hsp/src/qemu-master/meson/mesonbuild/environment.py", line
177, in detect_ninja_command_and_version
name = os.path.basename(n)
File "C:/msys64/mingw64/lib/python3.8/ntpath.py", line 231, in basename
return split(p)[1]
File "C:/msys64/mingw64/lib/python3.8/ntpath.py", line 200, in split
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType
ERROR: meson setup failed
When I set --ninja=ninja explicitly, this error does not occur:
Found ninja.EXE-1.10.1 at C:\msys64\mingw64\bin/ninja.EXE
However, compiling then runs into a problem:
$ make -j8
/mingw64/bin/python3 -B /home/hsp/src/qemu-master/meson/meson.py introspect
--targets --tests --benchmarks | /mingw64/bin/python3 -B
scripts/mtest2make.py > Makefile.mtest
{ echo 'ninja-targets = \'; ninja -t targets all | sed 's/:.*//; $!s/$/
\\/'; } > Makefile.ninja
ninja -j8 all | cat
make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. Stop.
make: *** [Makefile:171: pc-bios/optionrom/all] Error 2
make: *** Waiting for unfinished jobs
The problem with optionrom was already present earlier and could be fixed
by applying:
https://patchwork.ozlabs.org/project/qemu-devel/list/?series=202798
That patch set does by now not apply cleanly anymore.
Best,
Howard
Re: [PULL v7 000/151] Meson-based build system
> How are you executing ldd? I cross built a mingw executable from Fedora
> and it was definitely using system DLLs.
>
> This is what I see in Fedora 32 before moving executable and dlls to
Windows:
[hsp@localhost build]$ uname -a
Linux localhost.localdomain 5.7.14-200.fc32.x86_64 #1 SMP Fri Aug 7
23:16:37 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[hsp@localhost build]$ ../configure --cross-prefix=x86_64-w64-mingw32-
--enable-gtk --enable-sdl --target-list=ppc-softmmu --disable-pie
cross containers podman
The Meson build system
Version: 0.55.0
Source dir: /home/hsp/src/qemu-master
Build dir: /home/hsp/src/qemu-master/build
Build type: cross build
Project name: qemu
Project version: 5.1.50
C compiler for the build machine: cc (gcc 10.2.1 "cc (GCC) 10.2.1 20200723
(Red Hat 10.2.1-1)")
C linker for the build machine: cc ld.bfd 2.34-4
C compiler for the host machine: x86_64-w64-mingw32-gcc (gcc 9.2.1
"x86_64-w64-mingw32-gcc (GCC) 9.2.1 20190827 (Fedora MinGW 9.2.1-6.fc32)")
C linker for the host machine: x86_64-w64-mingw32-gcc ld.bfd 2.32
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86
Host machine cpu: x86_64
Target machine cpu family: x86
Target machine cpu: x86_64
../meson.build:9: WARNING: Module unstable-keyval has no backwards or
forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
C++ compiler for the host machine: x86_64-w64-mingw32-g++ (gcc 9.2.1
"x86_64-w64-mingw32-g++ (GCC) 9.2.1 20190827 (Fedora MinGW 9.2.1-6.fc32)")
C++ linker for the host machine: x86_64-w64-mingw32-g++ ld.bfd 2.32
Configuring ninjatool using configuration
Library m found: YES
Library util found: NO
Library ws2_32 found: YES
Library winmm found: YES
Windows resource compiler: GNU windres version 2.32-%{release}
Library aio found: NO
Library rt found: NO
Found pkg-config: /usr/bin/x86_64-w64-mingw32-pkg-config (0.28)
Run-time dependency sdl2 found: YES 2.0.12
Found CMake: NO
Run-time dependency sdl-image found: NO (tried pkgconfig and cmake)
Run-time dependency libpng found: YES 1.6.37
Has header "jpeglib.h" : YES
Library jpeg found: YES
Has header "sasl/sasl.h" : NO
Configuring config-host.h using configuration
Program scripts/minikconf.py found: YES
Configuring ppc-softmmu-config-target.h using configuration
Configuring ppc-softmmu-config-devices.mak with command
Reading depfile:
/home/hsp/src/qemu-master/build/meson-private/ppc-softmmu-config-devices.mak.d
Configuring ppc-softmmu-config-devices.h using configuration
Program scripts/grepy.sh found: YES
Configuring config-all-devices.mak with command
Program scripts/hxtool found: YES
Program scripts/shaderinclude.pl found: YES
Program scripts/qapi-gen.py found: YES
Program scripts/qemu-version.sh found: YES
Run-time dependency threads found: YES
Program keycodemapdb/tools/keymap-gen found: YES
Program scripts/decodetree.py found: YES
Program ../scripts/modules/module_block.py found: YES
Program x86_64-w64-mingw32-nm found: YES
Program scripts/undefsym.sh found: YES
Program scripts/feature_to_c.sh found: YES
Program wixl found: NO
Program bzip2 found: YES
Configuring 50-edk2-i386-secure.json using configuration
Configuring 50-edk2-x86_64-secure.json using configuration
Configuring 60-edk2-aarch64.json using configuration
Configuring 60-edk2-arm.json using configuration
Configuring 60-edk2-i386.json using configuration
Configuring 60-edk2-x86_64.json using configuration
Program diff found: YES
Build targets in project: 215
qemu 5.1.50
Install prefix: c:/Program Files/QEMU
BIOS directory: c:/Program Files/QEMU
firmware path: ${prefix}/share/qemu-firmware
binary directory: c:/Program Files/QEMU
library directory: c:/Program Files/QEMU/lib
module directory: c:/Program Files/QEMU/lib
libexec directory: c:/Program Files/QEMU/libexec
include directory: c:/Program Files/QEMU/include
config directory: c:/Program Files/QEMU
local state directory: queried at runtime
Build directory: /home/hsp/src/qemu-master/build
Source path: /home/hsp/src/qemu-master
GIT binary: git
GIT submodules: ui/keycodemapdb tests/fp/berkeley-testfloat-3
tests/fp/berkeley-softfloat-3 meson dtc capstone slirp
C compiler: x86_64-w64-mingw32-gcc
Host C compiler: cc
C++ compiler: x86_64-w64-mingw32-g++
ARFLAGS: rv
CFLAGS: -O2 -g -fno-pie -mthreads -std=gnu99 -Wall
QEMU_CFLAGS:
-I/usr/x86_64-w64-mingw32/sys-root/mingw/include/pixman-1
-I/home/hsp/src/qemu-master/dtc/libfdt -Werror -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include
-mms-bitfields -I/usr/x86_64-w64-mingw32/sys-root/mingw/include
-I/usr/x86_64-w64-mingw32/sys-root/mingw/include/glib-2.0
-I/usr/x86_64-w64-mingw32/sys-root/mingw/lib/glib-2.0/include
Re: [PULL v7 000/151] Meson-based build system
On Fri, Aug 21, 2020 at 8:15 AM Howard Spoelstra wrote: > > > On Wed, Aug 19, 2020 at 11:32 PM Paolo Bonzini > wrote: > >> The following changes since commit >> d0ed6a69d399ae193959225cdeaa9382746c91cc: >> >> Update version for v5.1.0 release (2020-08-11 17:07:03 +0100) >> >> are available in the Git repository at: >> >> https://gitlab.com/bonzini/qemu.git tags/for-upstream >> >> for you to fetch changes up to 2eddb3c65821dce76433d5da6f3e6419349d1b77: >> >> >> Hi, > > I attempted to cross compile Qemu for Windows from the meson branch today > using a Fedora 32 VM and using MSYS2 . > > In both cases I compiled using: > ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu > --enable-gtk --enable-sdl > > For the builds to run on Windows I normally copy the pc-bios folder and > the required dlls (from \msys64\mingw64\bin for the MSYS2 build and from > /usr/x86_64-w64-mingw32/sys-root/mingw/bin for the Fedora based build). > This has always worked in the past. > > As noticed earlier in discussion with Paolo, with MSYS2 there appears to > be a difference in how grep works on Linux and Windows. Using grep 3.1 as > provided by MSYS2, the file config-all-devices.mak file stays empty. > > On Fedora the compilation process completed successfully. However, the > binary crashes. This is the backtrace I could get: > > (gdb) attach 11528 > Attaching to process 11528 > [New Thread 11528.0x218] > [New Thread 11528.0x3380] > [New Thread 11528.0xf80] > Reading symbols from C:\qemu-debugging\gdb.exe...(no debugging symbols > found)... > done. > 0x7ffb9ef0f8b1 in ntdll!DbgBreakPoint () >from C:\WINDOWS\SYSTEM32\ntdll.dll > (gdb) thread apply all bt full > > Thread 3 (Thread 11528.0xf80): > #0 0x7ffb9ef0f8b1 in ntdll!DbgBreakPoint () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #1 0x7ffb9ef3c90e in ntdll!DbgUiRemoteBreakin () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #2 0x7ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk () >from C:\WINDOWS\System32\kernel32.dll > No symbol table info available. > #3 0x7ffb9eebcec1 in ntdll!RtlUserThreadStart () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #4 0x in ?? () > No symbol table info available. > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > Thread 2 (Thread 11528.0x3380): > #0 0x7ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #1 0x7ffb9c658910 in WaitForMultipleObjectsEx () >from C:\WINDOWS\System32\KernelBase.dll > ---Type to continue, or q to quit--- > No symbol table info available. > #2 0x7ffb9c65880e in WaitForMultipleObjects () >from C:\WINDOWS\System32\KernelBase.dll > No symbol table info available. > #3 0x004291a5 in ?? () > No symbol table info available. > #4 0x7ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk () >from C:\WINDOWS\System32\kernel32.dll > No symbol table info available. > #5 0x7ffb9eebcec1 in ntdll!RtlUserThreadStart () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #6 0x in ?? () > No symbol table info available. > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > Thread 1 (Thread 11528.0x218): > #0 0x7ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects () >from C:\WINDOWS\SYSTEM32\ntdll.dll > No symbol table info available. > #1 0x7ffb9c658910 in WaitForMultipleObjectsEx () >from C:\WINDOWS\System32\KernelBase.dll > No symbol table info available. > #2 0x7ffb9c65880e in WaitForMultipleObjects () > ---Type to continue, or q to quit--- >from C:\WINDOWS\System32\KernelBase.dll > No symbol table info available. > #3 0x00483e9c in ?? () > No symbol table info available. > #4 0x00551049 in ?? () > No symbol table info available. > #5 0x00550498 in ?? () > No symbol table info available. > #6 0x005504fd in ?? () > No symbol table info available. > #7 0x00551b63 in ?? () > No symbol table info available. > #8 0x005489d7 in ?? () > No symbol table info available. > #9 0x00549421 in ?? () > No symbol table info available. > #10 0x00545e0b in ?? () > No symbol table info available. > #11 0x0054a922 in ?? () > No symbol table info available. > #12 0x00545e0b in ?? () > No symbol table info available. > #13 0x0054a94d in ?? () > No symbol table info available. > --
Re: [PULL v7 000/151] Meson-based build system
On Wed, Aug 19, 2020 at 11:32 PM Paolo Bonzini wrote: > The following changes since commit > d0ed6a69d399ae193959225cdeaa9382746c91cc: > > Update version for v5.1.0 release (2020-08-11 17:07:03 +0100) > > are available in the Git repository at: > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > for you to fetch changes up to 2eddb3c65821dce76433d5da6f3e6419349d1b77: > > > Hi, I attempted to cross compile Qemu for Windows from the meson branch today using a Fedora 32 VM and using MSYS2 . In both cases I compiled using: ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu --enable-gtk --enable-sdl For the builds to run on Windows I normally copy the pc-bios folder and the required dlls (from \msys64\mingw64\bin for the MSYS2 build and from /usr/x86_64-w64-mingw32/sys-root/mingw/bin for the Fedora based build). This has always worked in the past. As noticed earlier in discussion with Paolo, with MSYS2 there appears to be a difference in how grep works on Linux and Windows. Using grep 3.1 as provided by MSYS2, the file config-all-devices.mak file stays empty. On Fedora the compilation process completed successfully. However, the binary crashes. This is the backtrace I could get: (gdb) attach 11528 Attaching to process 11528 [New Thread 11528.0x218] [New Thread 11528.0x3380] [New Thread 11528.0xf80] Reading symbols from C:\qemu-debugging\gdb.exe...(no debugging symbols found)... done. 0x7ffb9ef0f8b1 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll (gdb) thread apply all bt full Thread 3 (Thread 11528.0xf80): #0 0x7ffb9ef0f8b1 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #1 0x7ffb9ef3c90e in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #2 0x7ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll No symbol table info available. #3 0x7ffb9eebcec1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #4 0x in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 11528.0x3380): #0 0x7ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #1 0x7ffb9c658910 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll ---Type to continue, or q to quit--- No symbol table info available. #2 0x7ffb9c65880e in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll No symbol table info available. #3 0x004291a5 in ?? () No symbol table info available. #4 0x7ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll No symbol table info available. #5 0x7ffb9eebcec1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #6 0x in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 1 (Thread 11528.0x218): #0 0x7ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #1 0x7ffb9c658910 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll No symbol table info available. #2 0x7ffb9c65880e in WaitForMultipleObjects () ---Type to continue, or q to quit--- from C:\WINDOWS\System32\KernelBase.dll No symbol table info available. #3 0x00483e9c in ?? () No symbol table info available. #4 0x00551049 in ?? () No symbol table info available. #5 0x00550498 in ?? () No symbol table info available. #6 0x005504fd in ?? () No symbol table info available. #7 0x00551b63 in ?? () No symbol table info available. #8 0x005489d7 in ?? () No symbol table info available. #9 0x00549421 in ?? () No symbol table info available. #10 0x00545e0b in ?? () No symbol table info available. #11 0x0054a922 in ?? () No symbol table info available. #12 0x00545e0b in ?? () No symbol table info available. #13 0x0054a94d in ?? () No symbol table info available. ---Type to continue, or q to quit--- #14 0x004017e5 in ?? () No symbol table info available. #15 0x00401472 in ?? () No symbol table info available. #16 0x0040117c in ?? () No symbol table info available. #17 0x7ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll No symbol table info available. #18 0x7ffb9eebcec1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll No symbol table info available. #19 0x in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) Best, Howard
Re: [PATCH v2 000/150] Meson integration for 5.2
On Fri, Aug 14, 2020 at 11:15 AM Paolo Bonzini wrote: > > Hi Paolo, I don't know how much of this is already meant to work, but I run into several issues when compiling the latest code from the meson-poc-next branch. 1. MSYS2-based Windows build: The guide to compile e.g., qemu-system-ppc on Windows with Msys2 works OK to compile Qemu: https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 However, when I compile the meson-poc-next branch I run into the following error: hsp@HSP-W10-X64-I7 MINGW64 ~/src/qemu-meson-gitlab/build $ ../configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu --enable-gtk --enable-sdl ... Program python3 found: NO ../meson.build:32:0: ERROR: /mingw64/bin/python3 not found A full log can be found at C:/msys64/home/hsp/src/qemu-meson-gitlab/build/meson-logs/meson-log.txt ERROR: meson setup failed 2. When cross compiling from Fedora 32 for Windows with ../configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --target-list=ppc-softmmu I get the error below even though the v2 commit message says there is a fix for the absolute path error included: The Meson build system Version: 0.55.0 Source dir: /home/hsp/src/qemu-meson-gitlab Build dir: /home/hsp/src/qemu-meson-gitlab/build Build type: cross build ../meson.build:1:0: ERROR: prefix value 'c:/Program Files/QEMU' must be an absolute path A full log can be found at /home/hsp/src/qemu-meson-gitlab/build/meson-logs/meson-log.txt ERROR: meson setup failed 3. As mentioned earlier here concerning a build on fedora 32 host: https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg02307.html Both SDL and GTK Guis do not seem to work, only the vnc server is started. 4. The v2 patch set seems to not apply cleanly to current qemu-master, I get this error: patching file docs/devel/build-system.rst (renamed from docs/devel/build-system.txt) Hunk #2 succeeded at 179 with fuzz 2 (offset 152 lines). Hunk #3 succeeded at 187 (offset 152 lines). Hunk #4 FAILED at 53. Hunk #5 FAILED at 90. Hunk #6 FAILED at 115. Hunk #7 FAILED at 183. Hunk #8 FAILED at 201. Hunk #9 FAILED at 211. Hunk #10 FAILED at 222. Hunk #11 FAILED at 247. Hunk #12 FAILED at 308. Hunk #13 FAILED at 356. Hunk #14 FAILED at 398. Hunk #15 FAILED at 451. 12 out of 15 hunks FAILED -- saving rejects to file docs/devel/build-system.rst.rej 5: And one question: Should the compiled binary etc be placed in the build directory, or should they go into (in my case) the ppc-softmmu folder as with a default build? Best, Howard
Re: [PATCH 000/147] Meson integration for 5.2
On Wed, Aug 12, 2020 at 3:24 PM Philippe Mathieu-Daudé wrote: > Hi Howard, > > On 8/12/20 8:32 AM, Howard Spoelstra wrote: > > Hi, > > > > I just compiled qemu-system-ppc using the the meson-poc-next branch with: > > git clone -b meson-poc-next http://www.github.com/bonzini/qemu > > qemu-mesonbuild-next > > I notice you refer to github while Paolo mentioned gitlab in the > cover: > > "This is available from https://gitlab.com/bonzini/qemu.git branch" > > I am not sure he maintains both sync, can you retest using the gitlab > branch? > > Hi Philippe, I have the same issue when building from the gitlab repo just minutes ago: qemu-system-ppc-meson-gitlab: Display 'sdl' is not available. qemu-system-ppc-meson-gitlab: Display 'gtk' is not available. Best, Howard
Re: [PATCH 000/147] Meson integration for 5.2
Hi, I just compiled qemu-system-ppc using the the meson-poc-next branch with: git clone -b meson-poc-next http://www.github.com/bonzini/qemu qemu-mesonbuild-next cd qemu-mesonbuild-next mkdir build cd build ../configure --target-list="ppc-softmmu" --enable-sdl --enable-gtk --disable-werror qemu-system-ppc is invoked as follows: ./qemu-system-ppc -L pc-bios \ -M mac99,via=pmu -m 512 -sdl \ -serial stdio \ -drive file=/home/hsp/Mac-disks/9.2.img,format=raw,media=disk \ -boot c Both SDL and GTK GUis are not found, while the configuration overview lists: SDL support: YES GTK support: YES Terminal says: qemu-system-ppc: Display 'sdl' is not available, or qemu-system-ppc: Display 'gtk' is not available. So qemu starts with the vnc server only. Best, Howard
Re: [PATCH v7 0/8] Mac Old World ROM experiment
If you can sort out the issue with masking in patches 1 and 2 then I'd be > happy to > take patches 1-5. Obviously there is still some discussion around the i2c > part, so I > can wait a few more days to see what the outcome is there: the patches > generally seem > okay, the one change I would like to see is to add a comment around the > SPD parts > mentioning that these are only used by the real G3 ROM and not OpenBIOS. > > My only concern is whether an incomplete i2c implementation could cause > OSs that > currently boot to hang, so it is important that you can test a variety of > OS images > from MacOS to Linux and BSD to ensure that it doesn't cause any regression. > > Hi, I tested this patch set both on top of current master and on top of Mark' screamer branch. On top of master with mac99 machine MacOS: HD boot: all 9.x and all 10.X boot to desktop CD boot: all 9.x and all 10.X boot to installer Linux: HD boot: Fedora 12, Debian 4, Debian Squeeze CD boot: Debian 10, Lubuntu-16.04 Live boots to desktop Freebsd tested (Live CD only) CD boot only: 12.1 boots to black screen (terminal shows: call-method set-depth failed with error ffdf) 11.4 boots to root login. On top of master with g3beige machine MacOS: HD boot: 10.0,10.1 boot to desktop Linux: HD boot: Fedora 12 boots to graphical login screen then hangs On top of screamer branch with mac99 machine MacOS: HD boot: 9.0 and 9.1 often hang with audio extension error. 9.2 and all 10.X boot to desktop. Nothing new here. CD boot: all 9.x and all 10.X boot to installer Linux: HD boot: Debian 4 boots to failing X server CD boot: Lubuntu-16.04 boot to desktop On top of screamer branch with g3beige machine: MacOS: HD boot: 10.0, 10.1 boot to desktop. CD boot: 10.0 to 10.4 boot to installer Linux: HD boot: Fedora 12 boots to graphical login screen then hangs All in all, I see no regressions. The boing is beautiful when g3beige/screamer with increased buffer size boots the G3 rom ;-) Best, Howard
Re: [PATCH] usb: fix usb-host build on windows.
On Wed, Jun 24, 2020 at 3:45 PM Gerd Hoffmann wrote:
> Seems the new API is not available on windows.
> Update #ifdefs accordingly.
>
> Fixes: 9f815e83e983 ("usb: add hostdevice property to usb-host")
> Reported-by: Howard Spoelstra
> Signed-off-by: Gerd Hoffmann
> ---
> hw/usb/host-libusb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> index ad7ed8fb0c67..c474551d8456 100644
> --- a/hw/usb/host-libusb.c
> +++ b/hw/usb/host-libusb.c
> @@ -907,7 +907,7 @@ static int usb_host_open(USBHostDevice *s,
> libusb_device *dev, int hostfd)
> goto fail;
> }
> } else {
> -#if LIBUSB_API_VERSION >= 0x01000107
> +#if LIBUSB_API_VERSION >= 0x01000107 && !defined(CONFIG_WIN32)
> trace_usb_host_open_hostfd(hostfd);
>
> rc = libusb_wrap_sys_device(ctx, hostfd, >dh);
> @@ -1107,7 +1107,7 @@ static void usb_host_realize(USBDevice *udev, Error
> **errp)
> QTAILQ_INIT(>isorings);
> s->hostfd = -1;
>
> -#if LIBUSB_API_VERSION >= 0x01000107
> +#if LIBUSB_API_VERSION >= 0x01000107 && !defined(CONFIG_WIN32)
> if (s->hostdevice) {
> int fd;
> s->needs_autoscan = false;
> --
> 2.18.4
>
> Thanks for the quick fix, so:
Tested-by: Howard Spoelstra
lib-usb related linking error with msys2 build
Hi all, I get the following error compiling qemu-system-ppc from current master with msys2 (fully updated) ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu --enable-gtk --enable-sdl C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../hw/usb/host-libusb.o: in function `usb_host_open': C:\msys64\home\hsp\src\qemu-master/hw/usb/host-libusb.c:913: undefined reference to `libusb_wrap_sys_device' collect2.exe: error: ld returned 1 exit status make[1]: *** [Makefile:208: qemu-system-ppcw.exe] Error 1 make: *** [Makefile:527: ppc-softmmu/all] Error 2 I tracked it down to commit: $ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) According to msys2, the following libusb is provided: Group(s):Repo(s)mingw32, mingw64 Version: 1.0.23-1Upstream URL: https://libusb.info/Arch Linux:1.0.23 GIT Version:1.0.23-1 License(s)LGPLBinary Packages:mingw-w64-i686-libusbmingw-w64-x86_64-libusb Thanks for looking into this. Best, Howard
Re: Patches for ui/gtk and ui/sdl
On Sun, May 10, 2020 at 8:42 PM Volker Rümelin wrote: > It's rather difficult to test qemu patches in guests on Windows with > important keys missing. These patches mainly fix the guest keyboard on > Windows. > > With best regards, > Volker > Hi Volker, Excellent patch! I tested this on Windows with qemu-system-ppc running Mac OS 9.2 with both SDL and GTK GUIs. Finally no more popping up of that windows menu. Key combos are sent correctly into the guest. Also right alt does no longer send left ctrl+alt into the guest. A mere cosmetic difference between using a real mac keyboard and a pc keyboard is that alt and windows key seem to have traded places. However, the mac keyboard does have the alt where the windows key is on the pc keyboard. The keys are, however, functionally correct. The GTK GUI itself was and is unusable for Mac OS 9 guests in WIndows. That OS has no tablet driver available. Thanks, Howard
Re: [PATCH v1 07/11] configure: disable PIE for Windows builds
On Thu, Apr 9, 2020 at 11:18 PM Alex Bennée wrote: > It seems on some compilers the test can pass but still give you > broken binaries. > > [AJB untested - please could windows users test] > > Fixes: d2cd29e30736 > Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 > Cc: Bug 1871798 <1871...@bugs.launchpad.net> > Cc: James Le Cuirot > Signed-off-by: Alex Bennée > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index a207cce82bc..e9c5f630c14 100755 > --- a/configure > +++ b/configure > @@ -807,6 +807,7 @@ MINGW32*) > audio_drv_list="" >fi >supported_os="yes" > + pie="no" > ;; > GNU/kFreeBSD) >bsd="yes" > -- > 2.20.1 > Solves my issue! So, Tested-by: Howard Spoelstra
Re: [Bug 1870911] [NEW] QEMU Crashes on Launch, Windows
On Sun, Apr 5, 2020 at 3:38 PM Russell Morris wrote: > Public bug reported: > > Hi, > > I an having no issues up to (and including) v5.0.0-rc0, but when I move > to rc1 ... it won't even execute in Windows. If I just try to, for > example, run > > qemu-system-x86_64.exe --version > > No output, it just exits. This seems to be new with this version. > > Thanks! > > ** 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/1870911 > > Title: > QEMU Crashes on Launch, Windows > > Status in QEMU: > New > > Bug description: > Hi, > > I an having no issues up to (and including) v5.0.0-rc0, but when I > move to rc1 ... it won't even execute in Windows. If I just try to, > for example, run > > qemu-system-x86_64.exe --version > > No output, it just exits. This seems to be new with this version. > > Thanks! > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1870911/+subscriptions > > Happens to me too with qemu-system-ppc. Earlier thread is here: https://lists.nongnu.org/archive/html/qemu-ppc/2020-04/msg00027.html For now compiling with --disable-pie will produce a running executable. Best, Howard
Re: qemu-system-ppc 5.0 rc1 crashing on Windows
On Thu, Apr 2, 2020 at 4:58 PM Alex Bennée wrote: > > Howard Spoelstra writes: > > > On Thu, Apr 2, 2020 at 3:20 PM Alex Bennée > wrote: > > > >> > >> Howard Spoelstra writes: > >> > >> > On Thu, Apr 2, 2020 at 12:47 PM Philippe Mathieu-Daudé < > >> phi...@redhat.com> > >> > wrote: > >> > > >> >> Cc'ing the persons referenced in the commit you referred, > >> >> who happened to be chatting about this issue few hours ago on IRC. > >> >> > >> >> > >> > Thanks, adding --disable-pie to configure solves this issue, but I > guess > >> > the default detection should work ;-) > >> > >> Could you try the following patch: > >> > >> Subject: [PATCH for-5.0] configure: Add -Werror to PIE probe > >> Date: Wed, 1 Apr 2020 14:47:56 -0700 > >> Message-Id: <20200401214756.6559-1-richard.hender...@linaro.org> > >> > >> which fixed the win mxe cross compile failures. > >> > >> > > Hi, > > > > Thanks for your reply. However, I already did that. Please see the end of > > my original message repeated below. > > I never experienced compilation errors, just a crash when running. > > > >>> > Please note that I tried again after applying patch > >>> > https://patchwork.ozlabs.org/patch/1265368/ However, this has not > >>> solved > >>> > my issue. > > Ahh sorry missed that. Is there anyway you get can a back trace? > > -- > Alex Bennée > Hi, I might need a bit of help here. I compiled qemu with: ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu --enable-gtk --enable-sdl --enable-debug Then run gdb for Windows: C:\qemu-debugging>gdb --args c:\qemu-master-msys2\qemu-system-ppc.exe -L c:\qemu-master-msys2\pc-bios -boot c -m 256 -M mac99,via=pmu -hda c:\Mac-disks\9.2.img GNU gdb (GDB) 7.7.50.20140303-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". This binary was built by Equation Solution <http://www.Equation.com>... Reading symbols from c:\qemu-master-msys2\qemu-system-ppc.exe...done. (gdb) run Starting program: c:\qemu-master-msys2\qemu-system-ppc.exe -L c:\qemu-master-msys2\pc-bios -boot c -m 256 -M "mac99,via=pmu" -hda c:\Mac-disks\9.2.img [New Thread 3076.0x1384] [New Thread 3076.0x9a0] [New Thread 3076.0x3074] [New Thread 3076.0x3014] [Thread 3076.0x9a0 exited with code 0] [Thread 3076.0x3014 exited with code 0] [Thread 3076.0x3074 exited with code 0] [Inferior 1 (process 3076) exited with code 03561] (gdb) thread apply all bt full I get no output. (gdb) bt No stack. Best, Howard
Re: qemu-system-ppc 5.0 rc1 crashing on Windows
On Thu, Apr 2, 2020 at 3:20 PM Alex Bennée wrote: > > Howard Spoelstra writes: > > > On Thu, Apr 2, 2020 at 12:47 PM Philippe Mathieu-Daudé < > phi...@redhat.com> > > wrote: > > > >> Cc'ing the persons referenced in the commit you referred, > >> who happened to be chatting about this issue few hours ago on IRC. > >> > >> > > Thanks, adding --disable-pie to configure solves this issue, but I guess > > the default detection should work ;-) > > Could you try the following patch: > > Subject: [PATCH for-5.0] configure: Add -Werror to PIE probe > Date: Wed, 1 Apr 2020 14:47:56 -0700 > Message-Id: <20200401214756.6559-1-richard.hender...@linaro.org> > > which fixed the win mxe cross compile failures. > > Hi, Thanks for your reply. However, I already did that. Please see the end of my original message repeated below. I never experienced compilation errors, just a crash when running. >> > Please note that I tried again after applying patch >> > https://patchwork.ozlabs.org/patch/1265368/ However, this has not >> solved >> > my issue. >> > Best, Howard > > > > Best, > > Howard > > > > > > > >> On 4/2/20 11:28 AM, Howard Spoelstra wrote: > >> > Hi, > >> > > >> > I just compiled qemu-system-ppc for Windows, using native msys2 on > >> > Windows 10 64 bit and the 64 bit mingw cross compiler on Fedora 31. > Both > >> > create executables that crash: > >> > > >> > qemu-system-ppc.exe -L pc-bios -boot c -m 512 -M mac99,via=pmu -h > >> > da C:\Mac-disks\9.2.img > >> > Exception code=0xc005 flags=0x0 at 0x7FFB2A602078. Access > >> > violation - attempting to write data at address 0x034C76EC > >> > > >> > I bisected this down to: > >> > > >> > d2cd29e30736afd4a1e8cac3cf4da360bbc65978 is the first bad commit > >> > commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978 > >> > Author: Richard Henderson >> > <mailto:richard.hender...@linaro.org>> > >> > Date: Tue Dec 17 13:47:37 2019 -1000 > >> > > >> > configure: Do not force pie=no for non-x86 > >> > > >> > PIE is supported on many other hosts besides x86. > >> > > >> > The default for non-x86 is now the same as x86: pie is used > >> > if supported, and may be forced via --enable/--disable-pie. > >> > > >> > The original commit (40d6444e91c) said: > >> > > >> >"Non-x86 are not changed, as they require TCG changes" > >> > > >> > but I think that's wrong -- there's nothing about PIE that > >> > affects TCG one way or another. > >> > > >> > Tested on aarch64 (bionic) and ppc64le (centos 7) hosts. > >> > > >> > Tested-by: Alex Bennée >> > <mailto:alex.ben...@linaro.org>> > >> > Reviewed-by: Alex Bennée >> > <mailto:alex.ben...@linaro.org>> > >> > Reviewed-by: Philippe Mathieu-Daudé >> > <mailto:phi...@redhat.com>> > >> > Signed-off-by: Richard Henderson >> > <mailto:richard.hender...@linaro.org>> > >> > > >> > Please note that I tried again after applying patch > >> > https://patchwork.ozlabs.org/patch/1265368/ However, this has not > >> solved > >> > my issue. > >> > > >> > Best, > >> > Howard > >> > > >> > > >> > >> > > > -- > Alex Bennée >
Re: qemu-system-ppc 5.0 rc1 crashing on Windows
On Thu, Apr 2, 2020 at 12:47 PM Philippe Mathieu-Daudé wrote: > Cc'ing the persons referenced in the commit you referred, > who happened to be chatting about this issue few hours ago on IRC. > > Thanks, adding --disable-pie to configure solves this issue, but I guess the default detection should work ;-) Best, Howard > On 4/2/20 11:28 AM, Howard Spoelstra wrote: > > Hi, > > > > I just compiled qemu-system-ppc for Windows, using native msys2 on > > Windows 10 64 bit and the 64 bit mingw cross compiler on Fedora 31. Both > > create executables that crash: > > > > qemu-system-ppc.exe -L pc-bios -boot c -m 512 -M mac99,via=pmu -h > > da C:\Mac-disks\9.2.img > > Exception code=0xc005 flags=0x0 at 0x7FFB2A602078. Access > > violation - attempting to write data at address 0x034C76EC > > > > I bisected this down to: > > > > d2cd29e30736afd4a1e8cac3cf4da360bbc65978 is the first bad commit > > commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978 > > Author: Richard Henderson > <mailto:richard.hender...@linaro.org>> > > Date: Tue Dec 17 13:47:37 2019 -1000 > > > > configure: Do not force pie=no for non-x86 > > > > PIE is supported on many other hosts besides x86. > > > > The default for non-x86 is now the same as x86: pie is used > > if supported, and may be forced via --enable/--disable-pie. > > > > The original commit (40d6444e91c) said: > > > >"Non-x86 are not changed, as they require TCG changes" > > > > but I think that's wrong -- there's nothing about PIE that > > affects TCG one way or another. > > > > Tested on aarch64 (bionic) and ppc64le (centos 7) hosts. > > > > Tested-by: Alex Bennée > <mailto:alex.ben...@linaro.org>> > > Reviewed-by: Alex Bennée > <mailto:alex.ben...@linaro.org>> > > Reviewed-by: Philippe Mathieu-Daudé > <mailto:phi...@redhat.com>> > > Signed-off-by: Richard Henderson > <mailto:richard.hender...@linaro.org>> > > > > Please note that I tried again after applying patch > > https://patchwork.ozlabs.org/patch/1265368/ However, this has not > solved > > my issue. > > > > Best, > > Howard > > > > > >
qemu-system-ppc 5.0 rc1 crashing on Windows
Hi, I just compiled qemu-system-ppc for Windows, using native msys2 on Windows 10 64 bit and the 64 bit mingw cross compiler on Fedora 31. Both create executables that crash: qemu-system-ppc.exe -L pc-bios -boot c -m 512 -M mac99,via=pmu -h da C:\Mac-disks\9.2.img Exception code=0xc005 flags=0x0 at 0x7FFB2A602078. Access violation - attempting to write data at address 0x034C76EC I bisected this down to: d2cd29e30736afd4a1e8cac3cf4da360bbc65978 is the first bad commit commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978 Author: Richard Henderson Date: Tue Dec 17 13:47:37 2019 -1000 configure: Do not force pie=no for non-x86 PIE is supported on many other hosts besides x86. The default for non-x86 is now the same as x86: pie is used if supported, and may be forced via --enable/--disable-pie. The original commit (40d6444e91c) said: "Non-x86 are not changed, as they require TCG changes" but I think that's wrong -- there's nothing about PIE that affects TCG one way or another. Tested on aarch64 (bionic) and ppc64le (centos 7) hosts. Tested-by: Alex Bennée Reviewed-by: Alex Bennée Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Richard Henderson Please note that I tried again after applying patch https://patchwork.ozlabs.org/patch/1265368/ However, this has not solved my issue. Best, Howard
Re: [PATCH 0/5] mostly changes related to audio float samples
On Mon, Mar 2, 2020 at 8:08 PM Volker Rümelin wrote: > Patch "audio: change naming scheme of FLOAT_CONV macros" and > patch "audio: consistency changes" should have been a review > for ed2a4a7941 "audio: proper support for float samples in > mixeng", but I was too slow. > > Patch "audio: change mixing engine float range to [-1.f, 1.f]" > definitely needs to be tested by macOS users. I verified > PulseAudio, SDL2 and ALSA (actually libasound) work, but I > don't want to introduce a regression for CoreAudio. I spent > some time on https://developer.apple.com but I couldn't find > the answer if CoreAudio uses the [-1.f, 1.f] range too. The > results from my favorite search engine suggest the answer is > yes. > > @Howard: > I need your help once again. Can you please test if you can > hear (or see) clipping with my patches? Don't forget to set all > volume controls in the guest and on the host to 100% or 0dB to > get a reliable result. Compared to qemu without these patches I > expect the playback volume is a bit louder, but there's still > no clipping. > > Volker Rümelin (5): > qapi/audio: add documentation for AudioFormat > audio: change naming scheme of FLOAT_CONV macros > audio: consistency changes > audio: change mixing engine float range to [-1.f, 1.f] > audio: fix saturation nonlinearity in clip_* functions > > audio/mixeng.c | 26 +- > audio/mixeng_template.h | 22 ++ > qapi/audio.json | 14 ++ > 3 files changed, 37 insertions(+), 25 deletions(-) > > -- > 2.16.4 > > Hi, I applied these to Mark's screamer branch to create a new OSX build. Testing was done by playing system sounds, and an MP3/Internet radio with QuickTime/iTunes. With or without 6dB, the max volume is way out of my comfort zone. I hear no real difference in quality compared to a build from the current screamer branch. If any, it might sound a bit better. That means there still is some minimal crackling (clipping?) in the high volume parts of the audio I played with OSX guests, not Mac OS 9.x guests. So as there is no regression, tested by: howard spoelstra
Re: Issue with vl.c: move -m parsing after memory backends has been processed. Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047
On Wed, Feb 26, 2020 at 12:38 PM BALATON Zoltan wrote: > Hello, > > On Wed, 26 Feb 2020, Howard Spoelstra wrote: > > Hi all, > > > > Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 on the ppc-for-50 branch > > makes qemu-system-ppc running Mac OS 9 extremely slow. I bisected to the > > result below. > > > > Command line used: > > ./qemu-system-ppc -L pc-bios -M mac99,via=pmu -m 512 -boot c \ > > -hda 9.2.img \ > > -serial stdio -sdl > > > > Best, > > Howard > > > > a1b18df9a4848fc8a906e40c275063bfe9ca2047 is the first bad commit > > commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 > > Author: Igor Mammedov > > Isn't this the same as what's discussed in > > https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg07229.html > > Regards, > BALATON Zoltan > > Yes, this refers to the same issue. I responded there too with reference to the bisection result I got. As it is being dealt with, there is no further need to follow up on this particular report.. Best, Howard
Re: Sudden slowdown of ARM emulation in master
On Wed, Feb 26, 2020 at 10:19 AM Igor Mammedov wrote:
> On Wed, 26 Feb 2020 00:07:55 +0100
> Niek Linnenbank wrote:
>
> > Hello Igor and Paolo,
>
> does following hack solves issue?
>
> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> index a08ab11f65..ab2448c5aa 100644
> --- a/accel/tcg/translate-all.c
> +++ b/accel/tcg/translate-all.c
> @@ -944,7 +944,7 @@ static inline size_t size_code_gen_buffer(size_t
> tb_size)
> /* ??? If we relax the requirement that CONFIG_USER_ONLY use the
> static buffer, we could size this on RESERVED_VA, on the text
> segment size of the executable, or continue to use the
> default. */
> -tb_size = (unsigned long)(ram_size / 4);
> +tb_size = MAX_CODE_GEN_BUFFER_SIZE;
> #endif
> }
> if (tb_size < MIN_CODE_GEN_BUFFER_SIZE) {
>
>
Nice, for me, that brings qemu-system-ppc back up to speed. (applied to
ppc-for-5.0)
Best,
Howard
Re: Sudden slowdown of ARM emulation in master
On Wed, Feb 26, 2020 at 9:42 AM Peter Maydell
wrote:
> On Tue, 25 Feb 2020 at 23:08, Niek Linnenbank
> wrote:
>
> > Just now I was working on some small fixes for the cubieboard machine
> and rebasing my Allwinner H3 branches.
> > While doing some testing, I noticed that suddenly the machines were much
> slower than before.
> > I only see this happening when I rebase to this commit:
> >ca6155c0f2bd39b4b4162533be401c98bd960820 ("Merge tag 'patchew/
> 20200219160953.13771-1-imamm...@redhat.com' of
> https://github.com/patchew-project/qemu into HEAD")
>
> Yeah, I noticed a slowdown yesterday as well, but haven't tracked it down
> as yet. The first thing would be to do a git bisect to try to narrow
> down what commit caused it.
>
> thanks
> -- PMM
>
Perhaps related? I noticed a slow down on qemu-system-ppc and tracked it
down here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg07262.html
Best,
Howard
Issue with vl.c: move -m parsing after memory backends has been processed. Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047
Hi all, Commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 on the ppc-for-50 branch makes qemu-system-ppc running Mac OS 9 extremely slow. I bisected to the result below. Command line used: ./qemu-system-ppc -L pc-bios -M mac99,via=pmu -m 512 -boot c \ -hda 9.2.img \ -serial stdio -sdl Best, Howard a1b18df9a4848fc8a906e40c275063bfe9ca2047 is the first bad commit commit a1b18df9a4848fc8a906e40c275063bfe9ca2047 Author: Igor Mammedov Date: Wed Feb 19 11:08:40 2020 -0500 vl.c: move -m parsing after memory backends has been processed It will be possible for main RAM to come from memory-backend and we should check that size specified in -m matches the size of the backend and [MachineState::]ram_size also matches backend's size. However -m parsing (set_memory_options()) happens before backends are intialized (object_create_delayed()) which complicates it. Consolidate set_memory_options() and assigning parsed results to current_machine after backends are initialized, so it would be possible access the initialized backend instance to compare sizes. This patch only consolidates scattered places touching ram_size within vl.c. And follow up patch will integrate backend handling to set_memory_options(). Signed-off-by: Igor Mammedov Message-Id: <20200219160953.13771-7-imamm...@redhat.com> vl.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-)
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
On Fri, Feb 21, 2020 at 1:09 PM Howard Spoelstra wrote: > > > The current screamer-enabled builds for OSX and Windows are on > www.emaculation.com ;-) > As you see from testing, there are reasons why the patches from Mark's > screamer branch are not in master yet, and these have not all been > addressed. There still needs to be testing on Linux and certainly on > Windows builds, and from what I mentioned above that might not be plain > sailing. > I guess I'll wait with providing new builds when the patches for both > openbios and qemu are reviewed and in some repo from which I can build > easily. > > Best, > Howard > Hi, There is indeed an issue when building your code for Windows. Whereas the current screamer from Mark just plays sound, a build with your patches will not. I need to Ctrl-Alt-G to exit grab, click on the command (cmd.exe) window in which the Qemu textual output is showing and then grab the mouse again to get sound. A simple grab exit/grab cycle is not enough, a click somewhere outside the Qemu window will also not do. Only a click to activate the command window and then grab again. Happens with both GTK and SDL GUIs. Command line is: qemu-system-ppc-master-screamer-john-v4.exe -L pc-bios -boot c -m 256 -M mac99,via=pmu ^ -drive file=C:\mac-disks\9.2.img ^ -sdl -serial stdio ^ -bios openbios-qemu-screamer-john-v2.elf Took me ages to find this regularity ;-) Best, Howard
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
On Fri, Feb 21, 2020 at 12:30 PM Programmingkid wrote: > > > On Feb 21, 2020, at 4:13 AM, Howard Spoelstra > wrote: > > > > Hi, > > > > It might be worth mentioning that any testing of your screamer > implementation with MacOS/OSX guests on the mac99 machine needs a > custom-built openbios. > > > > Where possible I'll compare your screamer with the current screamer > implementation built from: > > git clone -b screamer https://github.com/mcayland/qemu > > > > All tests on OSX Sierra host with system sounds and MP3 playback through > latest QuickTime and iTunes available for the guest. Host is Intel i7-4770K > at 3.50Ghz. 32Gb memory. Audio device is an USB headset. > > Overall very subjective impression is that sound problems seem to arise > quicker with strong changes in volume in the stream. Silence is produced > perfectly... > > I should note that I also tested earlier with a windows build and that I > had to re-install Mac OS on three occasions to get sound going with your > screamer. Whether that was caused by a faulty installation or your screamer > is unclear to me. > > > > There we go: > > > > Mac OS 9.0.4: mac99,via=cuda > > Apple audio extension often fails to load. (Not restricted to your > screamer. This is a longstanding issue.) See at bottom for OSX crash report. > > Your screamer: shows only CD in Sound CP Input panel. Play sound through > output device is selected. > > Current screamer: shows CD + External Mic. Play sound through output > device is selected. > > > > Mac OS 9.1: mac99,via=cuda > > Your screamer: No Input selection in the Sound CP. > > Current screamer: Has External Mic (but no CD) in Sound CP. Play sound > through output device is not selected. > > > > Mac OS 9.2: mac99,via=pmu > > Your screamer: mp3 through iTunes and QuickTime OK. System sounds OK. > > Current screamer: Has considerably more problems playing two streams > simultaneously. (mp3 through both QuickTime and iTunes.) > > > > Mac OS X 10.0: mac99,via=cuda > > Your screamer: setting the sound balance from middle position to the > left seems to control volume. > > Current screamer: Serious number of drop-outs when playing MP3 through > QuickTime. Not when using iTunes. Has issues when moving the sound balance. > > > > Mac OS X 10.1: mac99,via=cuda > > Off-topic: Interestingly, when booting with via=pmu, the same error > occurs as reported above. > > Your screamer: QuickTime: drop-outs. iTunes OK, even with playing system > sounds through the stream. Balance has same problem as above. > > Current screamer: Serious drop-outs through both QuickTime and iTunes > when playing MP3. Balance sync gets completely lost after moving slider. > More lag in response to clicking system sounds. > > > > Mac OSX 10.2: no test due to longstanding video issue with opening > folders. > > > > Mac OSX 10.3: mac99,via=pmu > > Your screamer: drop-outs with QuickTime and iTunes. But not the clicks > heard as mentioned below. Opening the Sound preferences when playing MP3 is > OK. System sounds playing through the stream produce crackling sound. > systems sounds stop playing after several clicks on different ones. I hear > parts of earlier clicked sound when new one clicked. > > Current screamer: intermittent clicks (0.5 seconds) when playing MP3 > with QuickTime and iTunes. But QuickTime much better compared to 10.1. > Currently playing mp3 gets completely distorted (doubled?) when opening > Sound preferences. > > > > Mac OSX 10.4: mac99,via=pmu > > Off-topic: From 10.4 onward, Internet radio works in iTunes. Channel > update is very slow in 10.4... > > Your screamer: drop-outs with QuickTime. Sounds comparable to current > screamer. Opening Sound preferences is OK, but can make stream spiral out > of control with an echo. Seems to happen quicker when playing sound with > strong stereo effects. But always quickly recovers, unlike current > screamer. iTunes also produces drop-outs. Also with internet stream, but is > almost listenable. > > Current screamer: drop-outs with QuickTime. Sounds like stream is not > always in correct order. Sound crackles. iTunes almost OK. I can hear one > or two clicks after stopping audio. Opening Sound preferences makes stream > spiral out of control with an echo. > > > > Mac OSX 10.5: mac99,via=pmu > > Your screamer: Drop-outs with QuickTime. A bit less-so with iTunes. > Opening Sound preferences provides same experience as with 10.4. Internet > stream almost listenable. > > Current screamer: QuickTime produces drop-outs. Sound control panel > spirals out of control. Small audio
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
Hi, It might be worth mentioning that any testing of your screamer implementation with MacOS/OSX guests on the mac99 machine needs a custom-built openbios. Where possible I'll compare your screamer with the current screamer implementation built from: git clone -b screamer https://github.com/mcayland/qemu All tests on OSX Sierra host with system sounds and MP3 playback through latest QuickTime and iTunes available for the guest. Host is Intel i7-4770K at 3.50Ghz. 32Gb memory. Audio device is an USB headset. Overall very subjective impression is that sound problems seem to arise quicker with strong changes in volume in the stream. Silence is produced perfectly... I should note that I also tested earlier with a windows build and that I had to re-install Mac OS on three occasions to get sound going with your screamer. Whether that was caused by a faulty installation or your screamer is unclear to me. There we go: Mac OS 9.0.4: mac99,via=cuda Apple audio extension often fails to load. (Not restricted to your screamer. This is a longstanding issue.) See at bottom for OSX crash report. Your screamer: shows only CD in Sound CP Input panel. Play sound through output device is selected. Current screamer: shows CD + External Mic. Play sound through output device is selected. Mac OS 9.1: mac99,via=cuda Your screamer: No Input selection in the Sound CP. Current screamer: Has External Mic (but no CD) in Sound CP. Play sound through output device is not selected. Mac OS 9.2: mac99,via=pmu Your screamer: mp3 through iTunes and QuickTime OK. System sounds OK. Current screamer: Has considerably more problems playing two streams simultaneously. (mp3 through both QuickTime and iTunes.) Mac OS X 10.0: mac99,via=cuda Your screamer: setting the sound balance from middle position to the left seems to control volume. Current screamer: Serious number of drop-outs when playing MP3 through QuickTime. Not when using iTunes. Has issues when moving the sound balance. Mac OS X 10.1: mac99,via=cuda Off-topic: Interestingly, when booting with via=pmu, the same error occurs as reported above. Your screamer: QuickTime: drop-outs. iTunes OK, even with playing system sounds through the stream. Balance has same problem as above. Current screamer: Serious drop-outs through both QuickTime and iTunes when playing MP3. Balance sync gets completely lost after moving slider. More lag in response to clicking system sounds. Mac OSX 10.2: no test due to longstanding video issue with opening folders. Mac OSX 10.3: mac99,via=pmu Your screamer: drop-outs with QuickTime and iTunes. But not the clicks heard as mentioned below. Opening the Sound preferences when playing MP3 is OK. System sounds playing through the stream produce crackling sound. systems sounds stop playing after several clicks on different ones. I hear parts of earlier clicked sound when new one clicked. Current screamer: intermittent clicks (0.5 seconds) when playing MP3 with QuickTime and iTunes. But QuickTime much better compared to 10.1. Currently playing mp3 gets completely distorted (doubled?) when opening Sound preferences. Mac OSX 10.4: mac99,via=pmu Off-topic: From 10.4 onward, Internet radio works in iTunes. Channel update is very slow in 10.4... Your screamer: drop-outs with QuickTime. Sounds comparable to current screamer. Opening Sound preferences is OK, but can make stream spiral out of control with an echo. Seems to happen quicker when playing sound with strong stereo effects. But always quickly recovers, unlike current screamer. iTunes also produces drop-outs. Also with internet stream, but is almost listenable. Current screamer: drop-outs with QuickTime. Sounds like stream is not always in correct order. Sound crackles. iTunes almost OK. I can hear one or two clicks after stopping audio. Opening Sound preferences makes stream spiral out of control with an echo. Mac OSX 10.5: mac99,via=pmu Your screamer: Drop-outs with QuickTime. A bit less-so with iTunes. Opening Sound preferences provides same experience as with 10.4. Internet stream almost listenable. Current screamer: QuickTime produces drop-outs. Sound control panel spirals out of control. Small audio parts still played when stopping QuickTime. iTunes almost OK with MP3 playback, only small drop-outs. Same with Internet radio. For good measure I also tested 10.5 with your screamer and the recent hardfloat patches which improve fpu performance from 9% to 11% of a real G4 1Ghz ;-) I did not experience a considerable improvement in sound quality. Best, Howard OSX host Crash report when audio extension fails: Crashed Thread:2 Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0008 Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Segmentation fault: 11 Termination Reason:Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] VM Regions Near 0x8: --> __TEXT 0001087b-000108f7f000 [
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
On Wed, Feb 19, 2020 at 8:28 PM BALATON Zoltan wrote: > On Wed, 19 Feb 2020, Howard Spoelstra wrote: > > I tested with the current ppc-for-5.0 branch and with v1 of the hardfloat > > patches applied on top of that. There is a noticeable speed improvement > in > > Linux and OSX hosts. Windows 10 host doesn't seem to be impressed at > all. I > > saw no obvious glitches so far. The fpu performance on OSX hosts seems > very > > slow. This was not always the case in the past, when it was on par with > > Linux performance. > > Interesting, thanks for the measurements. > > > Below are my results. > > > > Best, > > Howard > > > > Host Linux (Fedora 31): > > Mac OS tests: 9.2 with MacBench 5.0 > > Baseline(100%): G3 300Mhz > > 5.0 branch + hardfloat patches: cpu 193%, fpu 86% > > 5.0 branch: cpu 188%, fpu 57% > > Here there's a difference in cpu value before and after patch which I > can't explain (only changed FPU stuff so it should not change others) but > also not seen in other measurements so this could be some external > influence such as something else using CPU while running test? Unless this > happens consistently I'd put it down to measurement error. > Yes, I would put that cpu value down to some fluctuation in the test > > > Mac OSX tests: 10.5 with Skidmarks 4.0 test > > Baseline(100%): G4 1.0Ghz. > > 5.0 branch + hardfloat patches: Int:131 FP:11 Vec:15 > > 5.0 branch: Int:131 FP:9 Vec:11 > > > > Host OSX Sierra: > > Mac OS tests: 9.2 with MacBench 5.0 > > Baseline(100%): G3 300Mhz > > 5.0 branch + hardfloat patches: cpu 199%, fpu 66% > > 5.0 branch: cpu 199%, fpu 40% > > Mac OSX tests: 10.5 with Skidmarks 4.0 test > > Baseline(100%): G4 1.0Ghz. > > 5.0 branch + hardfloat patches: Int:129 PF:11 Vec:14 > > These values seem to match Linux measurement above so don't seem slower > although MacOS9 seems to be slower (66 vs. 86) so either this depends on > the ops used or something else. > Yes, the baseline speed for the fpu in Mac OS 9.2 is relatively low. > > > 5.0 branch: Int:129 FP:8 Vec:9 > > > > Host Windows 10: > > Mac OS tests: 9.2 with MacBench 5.0 > > Baseline(100%): G3 300Mhz > > 5.0 branch + hardfloat patches: cpu 180%, fpu 54% > new run 5.0 branch + hardfloat patches: cpu 184%, fpu 54% > 5.0 branch: cpu 199%, fpu 40% > new run 5.0 branch: cpu 184%, fpu 56% It seems I misreported (copy/past without changing the values) the earlier Windows-based results with Mac OS 9.2 guest. As said above (and this now seems to confirm) Windows is not impressed at all and perhaps a bit slower even. Windows builds are particularly sensitive to any other activity on the system. Moving the qemu window drops performance considerably. Perhaps due to SDL not running in its own thread? > > Here there's again difference in cpu value but the other way so maybe if > the cause is external CPU usage then this again may be an outlying > measurement? You could retake these two to verify if you get same numbers > again. The fpu value does seem to improve just not as much as the others > and it's also lower to start with. I wonder why. > > > Mac OSX tests: 10.5 with Skidmarks 4.0 test > > Baseline(100%): G4 1.0Ghz. > > 5.0 branch + hardfloat patches: Int:130 FP:9 Vec:10 > > 5.0 branch: Int:130 FP:10 Vec:11 > > > > All tests done on the same host with v1 of the hardfloat patches > > Intel i7-4770K at 3.50Ghz. 32Gb memory > > All guests set to 1024x768 and "thousands" of colors. > > Does it mean this host machine were rebooted into these OSes or these were > run in a VM. In case using VM, were all three running in VM or one was on > host (I'd guess OSX host with Linux and Windows VMs). > > > Linux and OSX (with brew) use default compilers. > > Windows build cross-compiled from Fedora with x86_64-win64-mingw32 > > I assume Linux and OSX were 64 bit builds, is Windows 32 bit or 64 bit > exe? > No virtualisation. I run all on the same bare metal, so booted into these three separately from separate SSDs. You might guess OSX Sierra is running on less "official" hardware and you would be right. All qemu builds were 64 bit. Best, Howard
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Hi, I tested with the current ppc-for-5.0 branch and with v1 of the hardfloat patches applied on top of that. There is a noticeable speed improvement in Linux and OSX hosts. Windows 10 host doesn't seem to be impressed at all. I saw no obvious glitches so far. The fpu performance on OSX hosts seems very slow. This was not always the case in the past, when it was on par with Linux performance. Below are my results. Best, Howard Host Linux (Fedora 31): Mac OS tests: 9.2 with MacBench 5.0 Baseline(100%): G3 300Mhz 5.0 branch + hardfloat patches: cpu 193%, fpu 86% 5.0 branch: cpu 188%, fpu 57% Mac OSX tests: 10.5 with Skidmarks 4.0 test Baseline(100%): G4 1.0Ghz. 5.0 branch + hardfloat patches: Int:131 FP:11 Vec:15 5.0 branch: Int:131 FP:9 Vec:11 Host OSX Sierra: Mac OS tests: 9.2 with MacBench 5.0 Baseline(100%): G3 300Mhz 5.0 branch + hardfloat patches: cpu 199%, fpu 66% 5.0 branch: cpu 199%, fpu 40% Mac OSX tests: 10.5 with Skidmarks 4.0 test Baseline(100%): G4 1.0Ghz. 5.0 branch + hardfloat patches: Int:129 PF:11 Vec:14 5.0 branch: Int:129 FP:8 Vec:9 Host Windows 10: Mac OS tests: 9.2 with MacBench 5.0 Baseline(100%): G3 300Mhz 5.0 branch + hardfloat patches: cpu 180%, fpu 54% 5.0 branch: cpu 199%, fpu 40% Mac OSX tests: 10.5 with Skidmarks 4.0 test Baseline(100%): G4 1.0Ghz. 5.0 branch + hardfloat patches: Int:130 FP:9 Vec:10 5.0 branch: Int:130 FP:10 Vec:11 All tests done on the same host with v1 of the hardfloat patches Intel i7-4770K at 3.50Ghz. 32Gb memory All guests set to 1024x768 and "thousands" of colors. Linux and OSX (with brew) use default compilers. Windows build cross-compiled from Fedora with x86_64-win64-mingw32 Skidmarks test is a combination of tests: ParseVid (INT) MPEG (INT) PixBlend (INT) Ellipticrypt (INT) Rijndael (INT) Quicksort (INT) MDCT (FP) IntToFloat (FP) Q3 (FP) FFT (FP) VolInt (FP) Quant (VMX) Galaxy (VMX) IDCT (VMX) BigMult (VMX)
Re: [PATCH v3] Implement the Screamer sound chip for the mac99 machine type
Hi Howard, could you test out this patch for me on Fedora 31? It is to be
> applied over the v3 patch.
>
> Thank you.
>
> ---
> hw/audio/screamer.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/hw/audio/screamer.c b/hw/audio/screamer.c
> index ad4aba12eb..7de17fe8a6 100644
> --- a/hw/audio/screamer.c
> +++ b/hw/audio/screamer.c
> @@ -14,7 +14,7 @@
> #include "migration/vmstate.h"
> #include "include/hw/audio/screamer.h"
>
> -#define DEBUG_SCREAMER 0
> +#define DEBUG_SCREAMER 1
> #define DPRINTF(fmt, ...) \
> do { if (DEBUG_SCREAMER) { printf(fmt , ## __VA_ARGS__); } } while (0)
>
> @@ -836,11 +836,12 @@ static uint64_t screamer_mmio_read(void *opaque,
> hwaddr addr, unsigned size)
> return_value = get_frame_count_reg(state);
> break;
> default:
> -DPRINTF("Unknown register read - addr:%llu\tsize:%d\n", addr,
> size);
> +DPRINTF("Unknown register read - addr:%" HWADDR_PRIx
> "\tsize:%d\n",
> +addr, size);
> return_value = 12021981; /* Value used for debugging purposes */
> }
> -DPRINTF("screamer_mmio_read() called addr: %llu size: %d", addr >> 4,
> -size);
> +DPRINTF("screamer_mmio_read() called addr: %" HWADDR_PRIx " size:
> %d",
> +addr >> 4, size);
> DPRINTF(" returning 0x%x\n", return_value);
> return return_value;
> }
> @@ -875,7 +876,8 @@ static void screamer_mmio_write(void *opaque, hwaddr
> addr, uint64_t raw_value,
> set_frame_count_reg(state, value);
> break;
> default:
> -DPRINTF("Unknown register write - addr:%llu\tvalue:%d\n", addr,
> value);
> +DPRINTF("Unknown register write - addr:%" HWADDR_PRIx
> "\tvalue:%d\n",
> +addr, value);
> }
> }
>
>
>
Tested, compiles cleanly. Debug output seems OK.
Best,
Howard
Re: [PATCH v3] Implement the Screamer sound chip for the mac99 machine type
On Sun, Feb 16, 2020 at 5:32 PM John Arbuckle
wrote:
> Signed-off-by: John Arbuckle
> ---
> v3 changes:
> - Updated the location of patched code in hw/ppc/kconfig.
> - Removed setting the props variable in screamer.c.
> - Removed the screamer_properties variable in screamer.c.
>
> v2 changes:
> - Fixed a bug that prevented the sampling rate from being changed.
>
> hw/audio/Kconfig | 3 +
> hw/audio/Makefile.objs| 2 +
> hw/audio/screamer.c | 983
> ++
> hw/misc/macio/macio.c | 35 +-
> hw/ppc/Kconfig| 1 +
> hw/ppc/mac.h | 5 +
> include/hw/audio/screamer.h | 42 ++
> include/hw/misc/macio/macio.h | 2 +
> 8 files changed, 1072 insertions(+), 1 deletion(-)
> create mode 100644 hw/audio/screamer.c
> create mode 100644 include/hw/audio/screamer.h
>
> diff --git a/hw/audio/Kconfig b/hw/audio/Kconfig
> index e9c6fed826..196da6c3fe 100644
> --- a/hw/audio/Kconfig
> +++ b/hw/audio/Kconfig
> @@ -50,3 +50,6 @@ config CS4231
>
> config MARVELL_88W8618
> bool
> +
> +config SCREAMER
> +bool
> diff --git a/hw/audio/Makefile.objs b/hw/audio/Makefile.objs
> index 63db383709..55906886bc 100644
> --- a/hw/audio/Makefile.objs
> +++ b/hw/audio/Makefile.objs
> @@ -15,4 +15,6 @@ common-obj-$(CONFIG_CS4231) += cs4231.o
> common-obj-$(CONFIG_MARVELL_88W8618) += marvell_88w8618.o
> common-obj-$(CONFIG_MILKYMIST) += milkymist-ac97.o
>
> +common-obj-$(CONFIG_SCREAMER) += screamer.o
> +
> common-obj-y += soundhw.o
> diff --git a/hw/audio/screamer.c b/hw/audio/screamer.c
> new file mode 100644
> index 00..ad4aba12eb
> --- /dev/null
> +++ b/hw/audio/screamer.c
> @@ -0,0 +1,983 @@
> +/*
> + * File: Screamer.c
> + * Description: Implement the Screamer sound chip used in Apple
> Macintoshes.
> + * It works by filling a buffer, then playing the buffer.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "audio/audio.h"
> +#include "hw/hw.h"
> +#include "hw/irq.h"
> +#include
> +#include "hw/ppc/mac.h"
> +#include "hw/qdev-properties.h"
> +#include "migration/vmstate.h"
> +#include "include/hw/audio/screamer.h"
> +
> +#define DEBUG_SCREAMER 0
> +#define DPRINTF(fmt, ...) \
> +do { if (DEBUG_SCREAMER) { printf(fmt , ## __VA_ARGS__); } } while (0)
> +
> +#define SOUND_CONTROL_REG 0
> +#define CODEC_CONTROL_REG 1
> +#define CODEC_STATUS_REG 2
> +#define CLIP_COUNT_REG 3
> +#define BYTE_SWAP_REG 4
> +#define FRAME_COUNT_REG5
> +
> +#define AWACS_BUSY 0x0100
> +
> +/* Used with AWACS register 1 */
> +#define RECALIBRATE 0x004
> +#define LOOPTHRU0x040
> +#define SPEAKER_MUTE0x080
> +#define HEADPHONE_MUTE 0x200
> +#define OUTPUT_ZERO 0x400
> +#define OUTPUT_ONE 0x800
> +#define PARALLEL_OUTPUT 0xc00
> +
> +/* Function prototypes */
> +static uint32_t set_busy_bit(uint32_t value, int bit);
> +static uint32_t set_part_ready_bit(uint32_t value, int bit_value);
> +static uint32_t set_revision(uint32_t input_value);
> +static uint32_t set_manufacturer(uint32_t input_value);
> +static int get_sampling_rate(ScreamerState *s);
> +static uint32_t get_frame_count_reg(ScreamerState *s);
> +static void add_to_speaker_buffer(DBDMA_io *io);
> +static void dma_request(DBDMA_io *io);
> +
> +
> +/ Getters */
> +
> +/* Returns the codec control register's encoded AWACS address */
> +static uint8_t get_codec_control_address(uint32_t value)
> +{
> +uint8_t return_value;
> +return_value = (value >> 12) & 0x0fff;
> +return return_value;
> +}
> +
> +
> +static uint32_t get_sound_control_reg(ScreamerState *s)
> +{
> +DPRINTF("%s() called - returned 0x%x\n", __func__, s->sound_control);
> +return s->sound_control;
> +}
> +
> +/* The AWACS registers are accessed thru this register */
> +static uint32_t get_codec_control_reg(ScreamerState *s)
> +{
> +int awacs_register = get_codec_control_address(s->codec_control);
> +uint32_t return_value = s->awacs[awacs_register];
> +return_value = set_busy_bit(return_value, 0); /* Tell CPU we are
> ready */
> +DPRINTF("%s() called - returned 0x%x\tAWACS register: %d\n", __func__,
> +return_value, awacs_register);
> +return return_value;
> +}
> +
> +/*
> + * Determines if the readback bit is set.
> + * It is used by the Codec Control register.
> + */
> +static bool readback_enabled(ScreamerState *s)
> +{
> +/* Note: bit zero is the readback enabled bit */
> +if (s->awacs[7] & 1) {
> +return true;
> +} else {
> +return false;
> +}
> +}
> +
> +static uint32_t get_codec_status_reg(ScreamerState *s)
> +{
> +uint32_t return_value;
> +
> +/* if in readback mode - return AWACS register value */
> +if (readback_enabled(s)) {
> +int awacs_register = (s->awacs[7] & 0xe) >> 1;
> +s->awacs[7] = s->awacs[7] & 0xfffe; /* turn off readback mode
> */
> +
Re: [PATCH] audio/dsound: fix invalid parameters error
Cher Philippe,
On Mon, Feb 3, 2020 at 10:18 AM Philippe Mathieu-Daudé
wrote:
> Hi Howard,
>
> On 2/3/20 8:56 AM, Howard Spoelstra wrote:
> > On Mon, Feb 3, 2020 at 12:02 AM Kővágó, Zoltán > <mailto:dirty.ice...@gmail.com>> wrote:
> >
> > Windows (unlike wine) bails out when IDirectSoundBuffer8::Lock is
> called
> > with zero length. Also, hw->pos_emul handling was incorrect when
> > calling this function for the first time.
> >
> > Signed-off-by: Kővágó, Zoltán > <mailto:dirty.ice...@gmail.com>>
> > Reported-by: KJ Liew mailto:lie...@yahoo.com>>
> > ---
> >
> > I've tested this patch on wine and a borrowed Windows 8.1 laptop, I
> > could only test audio playback, not recording. I've cross-compiled
> qemu
> > using the docker image, for 64-bit.
> >
> > ---
> > audio/dsound_template.h | 1 +
> > audio/audio.c | 6 ++
> > audio/dsoundaudio.c | 27 +++
> > 3 files changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/audio/dsound_template.h b/audio/dsound_template.h
> > index 7a15f91ce5..9c5ce625ab 100644
> > --- a/audio/dsound_template.h
> > +++ b/audio/dsound_template.h
> > @@ -244,6 +244,7 @@ static int dsound_init_out(HWVoiceOut *hw,
> > struct audsettings *as,
> > goto fail0;
> > }
> >
> > +ds->first_time = true;
> > obt_as.endianness = 0;
> > audio_pcm_init_info (>info, _as);
> >
> > diff --git a/audio/audio.c b/audio/audio.c
> > index f63f39769a..cb1efc6dc5 100644
> > --- a/audio/audio.c
> > +++ b/audio/audio.c
> > @@ -1076,10 +1076,8 @@ static size_t audio_pcm_hw_run_out(HWVoiceOut
> > *hw, size_t live)
> > while (live) {
> > size_t size, decr, proc;
> > void *buf = hw->pcm_ops->get_buffer_out(hw, );
> > -if (!buf) {
> > -/* retrying will likely won't help, drop everything. */
> > -hw->mix_buf->pos = (hw->mix_buf->pos + live) %
> > hw->mix_buf->size;
> > -return clipped + live;
> > +if (!buf || size == 0) {
> > +break;
> > }
> >
> > decr = MIN(size / hw->info.bytes_per_frame, live);
> > diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
> > index c265c0094b..bd57082a8d 100644
> > --- a/audio/dsoundaudio.c
> > +++ b/audio/dsoundaudio.c
> > @@ -53,12 +53,14 @@ typedef struct {
> > typedef struct {
> > HWVoiceOut hw;
> > LPDIRECTSOUNDBUFFER dsound_buffer;
> > +bool first_time;
> > dsound *s;
> > } DSoundVoiceOut;
> >
> > typedef struct {
> > HWVoiceIn hw;
> > LPDIRECTSOUNDCAPTUREBUFFER dsound_capture_buffer;
> > +bool first_time;
> > dsound *s;
> > } DSoundVoiceIn;
> >
> > @@ -414,21 +416,32 @@ static void *dsound_get_buffer_out(HWVoiceOut
> > *hw, size_t *size)
> > DSoundVoiceOut *ds = (DSoundVoiceOut *) hw;
> > LPDIRECTSOUNDBUFFER dsb = ds->dsound_buffer;
> > HRESULT hr;
> > -DWORD ppos, act_size;
> > +DWORD ppos, wpos, act_size;
> > size_t req_size;
> > int err;
> > void *ret;
> >
> > -hr = IDirectSoundBuffer_GetCurrentPosition(dsb, , NULL);
> > +hr = IDirectSoundBuffer_GetCurrentPosition(
> > +dsb, , ds->first_time ? : NULL);
> > if (FAILED(hr)) {
> > dsound_logerr(hr, "Could not get playback buffer
> position\n");
> > *size = 0;
> > return NULL;
> > }
> >
> > +if (ds->first_time) {
> > +hw->pos_emul = wpos;
> > +ds->first_time = false;
> > +}
> > +
> > req_size = audio_ring_dist(ppos, hw->pos_emul, hw->size_emul);
> > req_size = MIN(req_size, hw->size_emul - hw->pos_emul);
> >
> > +if (req_size == 0) {
> > +*size = 0;
> > +return NULL;
> > +}
> > +
> > err = dsound_lock_out(dsb, >info, hw->pos_emul, req_size,
> > , NULL,
> >
Re: [PATCH] audio/dsound: fix invalid parameters error
On Mon, Feb 3, 2020 at 12:02 AM Kővágó, Zoltán
wrote:
> Windows (unlike wine) bails out when IDirectSoundBuffer8::Lock is called
> with zero length. Also, hw->pos_emul handling was incorrect when
> calling this function for the first time.
>
> Signed-off-by: Kővágó, Zoltán
> Reported-by: KJ Liew
> ---
>
> I've tested this patch on wine and a borrowed Windows 8.1 laptop, I
> could only test audio playback, not recording. I've cross-compiled qemu
> using the docker image, for 64-bit.
>
> ---
> audio/dsound_template.h | 1 +
> audio/audio.c | 6 ++
> audio/dsoundaudio.c | 27 +++
> 3 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/audio/dsound_template.h b/audio/dsound_template.h
> index 7a15f91ce5..9c5ce625ab 100644
> --- a/audio/dsound_template.h
> +++ b/audio/dsound_template.h
> @@ -244,6 +244,7 @@ static int dsound_init_out(HWVoiceOut *hw, struct
> audsettings *as,
> goto fail0;
> }
>
> +ds->first_time = true;
> obt_as.endianness = 0;
> audio_pcm_init_info (>info, _as);
>
> diff --git a/audio/audio.c b/audio/audio.c
> index f63f39769a..cb1efc6dc5 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -1076,10 +1076,8 @@ static size_t audio_pcm_hw_run_out(HWVoiceOut *hw,
> size_t live)
> while (live) {
> size_t size, decr, proc;
> void *buf = hw->pcm_ops->get_buffer_out(hw, );
> -if (!buf) {
> -/* retrying will likely won't help, drop everything. */
> -hw->mix_buf->pos = (hw->mix_buf->pos + live) %
> hw->mix_buf->size;
> -return clipped + live;
> +if (!buf || size == 0) {
> +break;
> }
>
> decr = MIN(size / hw->info.bytes_per_frame, live);
> diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
> index c265c0094b..bd57082a8d 100644
> --- a/audio/dsoundaudio.c
> +++ b/audio/dsoundaudio.c
> @@ -53,12 +53,14 @@ typedef struct {
> typedef struct {
> HWVoiceOut hw;
> LPDIRECTSOUNDBUFFER dsound_buffer;
> +bool first_time;
> dsound *s;
> } DSoundVoiceOut;
>
> typedef struct {
> HWVoiceIn hw;
> LPDIRECTSOUNDCAPTUREBUFFER dsound_capture_buffer;
> +bool first_time;
> dsound *s;
> } DSoundVoiceIn;
>
> @@ -414,21 +416,32 @@ static void *dsound_get_buffer_out(HWVoiceOut *hw,
> size_t *size)
> DSoundVoiceOut *ds = (DSoundVoiceOut *) hw;
> LPDIRECTSOUNDBUFFER dsb = ds->dsound_buffer;
> HRESULT hr;
> -DWORD ppos, act_size;
> +DWORD ppos, wpos, act_size;
> size_t req_size;
> int err;
> void *ret;
>
> -hr = IDirectSoundBuffer_GetCurrentPosition(dsb, , NULL);
> +hr = IDirectSoundBuffer_GetCurrentPosition(
> +dsb, , ds->first_time ? : NULL);
> if (FAILED(hr)) {
> dsound_logerr(hr, "Could not get playback buffer position\n");
> *size = 0;
> return NULL;
> }
>
> +if (ds->first_time) {
> +hw->pos_emul = wpos;
> +ds->first_time = false;
> +}
> +
> req_size = audio_ring_dist(ppos, hw->pos_emul, hw->size_emul);
> req_size = MIN(req_size, hw->size_emul - hw->pos_emul);
>
> +if (req_size == 0) {
> +*size = 0;
> +return NULL;
> +}
> +
> err = dsound_lock_out(dsb, >info, hw->pos_emul, req_size, ,
> NULL,
>_size, NULL, false, ds->s);
> if (err) {
> @@ -508,18 +521,24 @@ static void *dsound_get_buffer_in(HWVoiceIn *hw,
> size_t *size)
> DSoundVoiceIn *ds = (DSoundVoiceIn *) hw;
> LPDIRECTSOUNDCAPTUREBUFFER dscb = ds->dsound_capture_buffer;
> HRESULT hr;
> -DWORD cpos, act_size;
> +DWORD cpos, rpos, act_size;
> size_t req_size;
> int err;
> void *ret;
>
> -hr = IDirectSoundCaptureBuffer_GetCurrentPosition(dscb, , NULL);
> +hr = IDirectSoundCaptureBuffer_GetCurrentPosition(
> +dscb, , ds->first_time ? : NULL);
> if (FAILED(hr)) {
> dsound_logerr(hr, "Could not get capture buffer position\n");
> *size = 0;
> return NULL;
> }
>
> +if (ds->first_time) {
> +hw->pos_emul = rpos;
> +ds->first_time = false;
> +}
> +
> req_size = audio_ring_dist(cpos, hw->pos_emul, hw->size_emul);
> req_size = MIN(req_size, hw->size_emul - hw->pos_emul);
>
> --
> 2.25.0
>
Hi,
I tested this patch running qemu-system-ppc with MacOS 9.2 and OSX 10.5.
Qemu was cross-compiled on Fedora 31 from
https://github.com/mcayland/qemu/tree/screamer. Host was Windows 10.
The dsound locking errors are gone, so for this test case all seems OK.
Best,
Howard
Re: [RFC PATCH] audio: proper support for float samples in mixeng
On Sun, Feb 2, 2020 at 8:38 PM Kővágó, Zoltán
wrote:
> This adds proper support for float samples in mixeng by adding a new
> audio format for it.
>
> Limitations: only native endianness is supported.
>
> Signed-off-by: Kővágó, Zoltán
> ---
>
> This patch is meant to be applied on top of "[PATCH] coreaudio: fix
> coreaudio
> playback" by Volker Rümelin, available at:
> https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg00114.html
>
> For more information, please refer to that thread.
>
> ---
> qapi/audio.json| 2 +-
> audio/audio_int.h | 3 +-
> audio/audio_template.h | 41
> audio/mixeng.h | 8 ++--
> audio/alsaaudio.c | 17
> audio/audio.c | 56 ++-
> audio/coreaudio.c | 7 +---
> audio/mixeng.c | 88 ++
> audio/paaudio.c| 9 +
> audio/sdlaudio.c | 28 ++
> 10 files changed, 180 insertions(+), 79 deletions(-)
>
> diff --git a/qapi/audio.json b/qapi/audio.json
> index 83312b2339..d8c507cced 100644
> --- a/qapi/audio.json
> +++ b/qapi/audio.json
> @@ -276,7 +276,7 @@
> # Since: 4.0
> ##
> { 'enum': 'AudioFormat',
> - 'data': [ 'u8', 's8', 'u16', 's16', 'u32', 's32' ] }
> + 'data': [ 'u8', 's8', 'u16', 's16', 'u32', 's32', 'f32' ] }
>
> ##
> # @AudiodevDriver:
> diff --git a/audio/audio_int.h b/audio/audio_int.h
> index 5ba2078346..cd92e48163 100644
> --- a/audio/audio_int.h
> +++ b/audio/audio_int.h
> @@ -40,7 +40,8 @@ struct audio_callback {
>
> struct audio_pcm_info {
> int bits;
> -int sign;
> +bool is_signed;
> +bool is_float;
> int freq;
> int nchannels;
> int bytes_per_frame;
> diff --git a/audio/audio_template.h b/audio/audio_template.h
> index 0336d2670c..7013d3041f 100644
> --- a/audio/audio_template.h
> +++ b/audio/audio_template.h
> @@ -153,15 +153,23 @@ static int glue (audio_pcm_sw_init_, TYPE) (
> sw->ratio = ((int64_t) sw->info.freq << 32) / sw->hw->info.freq;
> #endif
>
> +if (sw->info.is_float) {
> #ifdef DAC
> -sw->conv = mixeng_conv
> +sw->conv = mixeng_conv_float[sw->info.nchannels == 2];
> #else
> -sw->clip = mixeng_clip
> +sw->clip = mixeng_clip_float[sw->info.nchannels == 2];
> #endif
> -[sw->info.nchannels == 2]
> -[sw->info.sign]
> -[sw->info.swap_endianness]
> -[audio_bits_to_index (sw->info.bits)];
> +} else {
> +#ifdef DAC
> +sw->conv = mixeng_conv
> +#else
> +sw->clip = mixeng_clip
> +#endif
> +[sw->info.nchannels == 2]
> +[sw->info.is_signed]
> +[sw->info.swap_endianness]
> +[audio_bits_to_index(sw->info.bits)];
> +}
>
> sw->name = g_strdup (name);
> err = glue (audio_pcm_sw_alloc_resources_, TYPE) (sw);
> @@ -276,22 +284,23 @@ static HW *glue(audio_pcm_hw_add_new_,
> TYPE)(AudioState *s,
> goto err1;
> }
>
> -if (s->dev->driver == AUDIODEV_DRIVER_COREAUDIO) {
> +if (hw->info.is_float) {
> #ifdef DAC
> -hw->clip = clip_natural_float_from_stereo;
> +hw->clip = mixeng_clip_float[hw->info.nchannels == 2];
> #else
> -hw->conv = conv_natural_float_to_stereo;
> +hw->conv = mixeng_conv_float[hw->info.nchannels == 2];
> #endif
> -} else
> +} else {
> #ifdef DAC
> -hw->clip = mixeng_clip
> +hw->clip = mixeng_clip
> #else
> -hw->conv = mixeng_conv
> +hw->conv = mixeng_conv
> #endif
> -[hw->info.nchannels == 2]
> -[hw->info.sign]
> -[hw->info.swap_endianness]
> -[audio_bits_to_index (hw->info.bits)];
> +[hw->info.nchannels == 2]
> +[hw->info.is_signed]
> +[hw->info.swap_endianness]
> +[audio_bits_to_index(hw->info.bits)];
> +}
>
> glue(audio_pcm_hw_alloc_resources_, TYPE)(hw);
>
> diff --git a/audio/mixeng.h b/audio/mixeng.h
> index 7ef61763e8..2dcd6df245 100644
> --- a/audio/mixeng.h
> +++ b/audio/mixeng.h
> @@ -38,13 +38,13 @@ typedef struct st_sample st_sample;
> typedef void (t_sample) (struct st_sample *dst, const void *src, int
> samples);
> typedef void (f_sample) (void *dst, const struct st_sample *src, int
> samples);
>
> +/* indices: [stereo][signed][swap endiannes][8, 16 or 32-bits] */
> extern t_sample *mixeng_conv[2][2][2][3];
> extern f_sample *mixeng_clip[2][2][2][3];
>
> -void conv_natural_float_to_stereo(struct st_sample *dst, const void *src,
> - int samples);
> -void clip_natural_float_from_stereo(void *dst, const struct st_sample
> *src,
> -int samples);
> +/* indices: [stereo] */
> +extern t_sample *mixeng_conv_float[2];
> +extern f_sample *mixeng_clip_float[2];
>
> void *st_rate_start (int inrate, int outrate);
> void st_rate_flow(void *opaque, st_sample *ibuf, st_sample *obuf,
> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> index
Re: [PATCH 0/1] coreaudio: fix coreaudio playback
On Sun, Feb 2, 2020 at 3:03 PM Volker Rümelin wrote: > Hi, > > here is a new patch for the CoreAudio playback problem. This patch > is Zoltán's patch from > https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02142.html > and a improved version of my patch squashed together. > > I actually tested the changes in audio/audio_template.h, > audio/mixeng.c and audio/mixeng.h with all useful permutations of > FLOAT_MIXENG and RECIPROCAL defined/undefined. > > @Howard and John > Can you please test this patch? Compared to the patches you tested > this patch is quite different. > > @John > 'git am exported_mail.eml' knows how to handle > Content-Transfer-Encoding: in a mail file. It's not necessary to > apply this patch by hand. > > Volker Rümelin (1): > coreaudio: fix coreaudio playback > > audio/audio_template.h | 7 +++ > audio/coreaudio.c | 32 +--- > audio/mixeng.c | 48 > > audio/mixeng.h | 5 + > 4 files changed, 69 insertions(+), 23 deletions(-) > > -- > 2.16.4 > > Hi, This patch restores coreaudio for me. I applied the patch on top of https://github.com/mcayland/qemu/tree/screamer to test audio support in qemu-system-ppc running Mac OS 9.2 and OSX 10.5. Host is OSX Sierra. Thanks, Howard
Re: [RFC] coreaudio: fix coreaudio_test.diff
On Fri, Jan 31, 2020 at 9:35 AM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 31/01/2020 08:03, Gerd Hoffmann wrote: > > >> Thank you for testing the two patches. I will wait a few days to see if > Zoltán wants to write a cleaned up patch. Otherwise I'll try to write a > patch that's acceptable for submission. > > > > I'm busy collecting pending audio fixes for the next pull req, > > planned to send out early next week. Would be cool if I can > > include a coreaudio fix ;) > > > > The RFC patch looks sane to me but it clearly needs a better > > commit message. > > > > Current patch queue state: > > https://git.kraxel.org/cgit/qemu/log/?h=queue/audio > > > > If I missed something please resend. > > That would be great! One thing to note is that Volker's RFC patch applies > on top of > Zoltan's original diff from > https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02142.html > rather than > being standalone. > > If you take a look at my branch at > https://github.com/mcayland/qemu/commits/for-cat7 > then it's just a case of squashing the top 2 commits and coming up with a > suitable > commit message. > > > ATB, > > Mark. > Yes, lovely! I just applied the dsound patch from KJ Liew on top of the for-cat7 branch. https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03805.html While it will not apply directly (not finding the file to patch in the source tree), it nevertheless gets rid of the dsound errors too. Best, Howard
Re: [PATCH 0/4] target/ppc: Use probe_access
As this patch set solved the performance issue and even led to the highest scores I ever saw on the benchmark tool I used, let me add a: Tested-by: Howard Spoelstra On Thu, Jan 30, 2020 at 12:50 AM Richard Henderson < richard.hender...@linaro.org> wrote: > The first two address the performance regression noticed > by Howard Spoelstra. The last two are just something I > noticed at the same time. > > > r~ > > > Richard Henderson (4): > target/ppc: Use probe_access for LSW, STSW > target/ppc: Use probe_access for LMW, STMW > target/ppc: Remove redundant mask in DCBZ > target/ppc: Use probe_write for DCBZ > > target/ppc/mem_helper.c | 197 +--- > 1 file changed, 162 insertions(+), 35 deletions(-) > > -- > 2.20.1 > >
Re: [RFC] coreaudio: fix coreaudio_test.diff
On Wed, Jan 29, 2020 at 8:13 AM Volker Rümelin wrote: > This is an untested patch that tries to fix the problems in the > patch found at > https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02142.html. > > Signed-off-by: Volker Rümelin > --- > audio/audio_template.h | 16 > audio/coreaudio.c | 5 + > 2 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/audio/audio_template.h b/audio/audio_template.h > index a7b46b8363..e6724c5d68 100644 > --- a/audio/audio_template.h > +++ b/audio/audio_template.h > @@ -153,13 +153,6 @@ static int glue (audio_pcm_sw_init_, TYPE) ( > sw->ratio = ((int64_t) sw->info.freq << 32) / sw->hw->info.freq; > #endif > > -#ifdef FLOAT_MIXENG > -#ifdef DAC > -sw->conv = mixeng_conv_float; > -#else > -sw->clip = mixeng_clip_float; > -#endif > -#else > #ifdef DAC > sw->conv = mixeng_conv > #else > @@ -169,7 +162,6 @@ static int glue (audio_pcm_sw_init_, TYPE) ( > [sw->info.sign] > [sw->info.swap_endianness] > [audio_bits_to_index (sw->info.bits)]; > -#endif > > sw->name = g_strdup (name); > err = glue (audio_pcm_sw_alloc_resources_, TYPE) (sw); > @@ -284,6 +276,13 @@ static HW *glue(audio_pcm_hw_add_new_, > TYPE)(AudioState *s, > goto err1; > } > > +#ifdef FLOAT_MIXENG > +#ifdef DAC > +hw->clip = mixeng_clip_float; > +#else > +hw->conv = mixeng_conv_float; > +#endif > +#else > #ifdef DAC > hw->clip = mixeng_clip > #else > @@ -293,6 +292,7 @@ static HW *glue(audio_pcm_hw_add_new_, > TYPE)(AudioState *s, > [hw->info.sign] > [hw->info.swap_endianness] > [audio_bits_to_index (hw->info.bits)]; > +#endif > > glue(audio_pcm_hw_alloc_resources_, TYPE)(hw); > > diff --git a/audio/coreaudio.c b/audio/coreaudio.c > index 4e7e509ad0..ff0d23fd7d 100644 > --- a/audio/coreaudio.c > +++ b/audio/coreaudio.c > @@ -482,6 +482,7 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct > audsettings *as, > Audiodev *dev = drv_opaque; > AudiodevCoreaudioPerDirectionOptions *cpdo = dev->u.coreaudio.out; > int frames; > +struct audsettings fake_as; > > /* create mutex */ > err = pthread_mutex_init(>mutex, NULL); > @@ -490,6 +491,10 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct > audsettings *as, > return -1; > } > > +memcpy(_as, as, sizeof(struct audsettings)); > +as = _as; > +/* size of float is 32bits */ > +as->fmt = AUDIO_FORMAT_S32; > audio_pcm_init_info (>info, as); > > status = coreaudio_get_voice(>outputDeviceID); > -- > 2.16.4 > > Hi all, Thanks to the generous help from Mark, I can now report that it is good to hear coreaudio has been restored into a working state with this patch! I tested qemu-system-ppc running MacOS and OSX. Best, Howard
Re: [PATCH 0/4] target/ppc: Use probe_access
On Thu, Jan 30, 2020 at 12:50 AM Richard Henderson < richard.hender...@linaro.org> wrote: > The first two address the performance regression noticed > by Howard Spoelstra. The last two are just something I > noticed at the same time. > > > r~ > > > Richard Henderson (4): > target/ppc: Use probe_access for LSW, STSW > target/ppc: Use probe_access for LMW, STMW > target/ppc: Remove redundant mask in DCBZ > target/ppc: Use probe_write for DCBZ > > target/ppc/mem_helper.c | 197 +--- > 1 file changed, 162 insertions(+), 35 deletions(-) > > -- > 2.20.1 > > Hi, I can confirm these patches fix the performance issue I reported. Thanks, Howard
Re: Performance hit in qemu-system-ppc
On Tue, Jan 28, 2020 at 7:30 PM Richard Henderson < richard.hender...@linaro.org> wrote: > On 1/25/20 3:30 PM, Howard Spoelstra wrote: > > I noticed a considerable (~20%) slowdown in the cpu performance of > qemu-system-ppc. > > ENOINFO. > > For what test case? This should not have been on any hot path. > > Hi, I tested Mac OS 9.2 and 10.3/4 with qemu-system-ppc built from 4.2 and current master like this: Command line: ./qemu-system-ppc -L pc-bios -boot c -M mac99,via=pmu -m 512 \ -serial stdio -sdl \ -hda 9.2.img (10.3.img|10.4.img) Mac OS 9.2 MacBench 5.0 reports processor speed: 4.2: ~190% Master: ~160% Mac OSX 10.3.9 Skidmarks 4.0.1 test: specific drop in performance of MPEG(INT) test: 4.2: 118% Master: 100% Mac OS 10.4.11 Skidmarks 4.0.1 test: specific drop in performance of MPEG(INT) test: 4.2: 117% Master: 99% Best, Howard
Re: [PATCH v2] Implement the Screamer sound chip for the mac99 machine type
On Tue, Jan 28, 2020 at 9:30 AM Volker Rümelin wrote:
> > Hi,
> >
> > Unfortunately it's not that simple to simply revert the patch since the
> old backend api no longer exists. Also I don't have a Mac so it's almost
> impossible for me to test the results. I looked at the specified commit
> and I think I found a problem, could you please apply the attached patch on
> the current git master and check whether it solves the problem? If yes
> I'll turn it into a proper patch.
> >
> > Regards,
> > Zoltan
> >
>
> Hi Zoltán,
>
> I also don't have a Mac so I tested your patch with a slightly modified
> sdlaudio version. I found two bugs in your patch. With the bugs fixed I
> have working SDL2 audio playback with float type samples. Now I wonder if
> the fixed patch also fixes coreaudio playback. Depending on how busy you
> are I can just write a review for your patch and let you handle the rest,
> or may I send a modified version of your patch to the mailing list for
> testing?
>
> With best regards
> Volker
>
Hi Volker,
I can test for coreaudio. Can you let us know exactly what you fixed in the
patch?
While cross compiling for windows, I saw these errors (besides some casting
issues):
line 56: buffer2 (should be *buffer2?)
line 455: ret (should be ret2?)
audio/dsoundaudio.c:56:20: error: variable or field 'buffer2' declared void
56 | void *buffer1, buffer2;
|^~~
audio/dsoundaudio.c: In function 'dsound_get_buffer_out':
audio/dsoundaudio.c:428:18: error: returning 'int' from a function with
return type 'void *' makes pointer from integer without a cast
[-Werror=int-conversion]
428 | return ds->buffer2;
|~~^
audio/dsoundaudio.c:451:17: error: assignment to 'int' from 'void *' makes
integer from pointer without a cast [-Werror=int-conversion]
451 | ds->buffer2 = ret2;
| ^
audio/dsoundaudio.c:455:12: error: 'ret' undeclared (first use in this
function); did you mean 'ret2'?
455 | return ret;
|^~~
|ret2
audio/dsoundaudio.c:455:12: note: each undeclared identifier is reported
only once for each function it appears in
audio/dsoundaudio.c: In function 'dsound_put_buffer_out':
audio/dsoundaudio.c:471:49: error: passing argument 3 of
'dsound_unlock_out' makes pointer from integer without a cast
[-Werror=int-conversion]
471 | err = dsound_unlock_out(dsb, ds->buffer1, ds->buffer2,
ds->size1, ds->size2);
| ~~^
| |
| int
In file included from audio/dsoundaudio.c:267:
audio/dsound_template.h:49:12: note: expected 'LPVOID' {aka 'void *'} but
argument is of type 'int'
49 | LPVOID p2,
| ~~~^~
audio/dsoundaudio.c: In function 'dsound_get_buffer_out':
audio/dsoundaudio.c:456:1: error: control reaches end of non-void function
[-Werror=return-type]
456 | }
| ^
cc1: all warnings being treated as errors
Best,
Howard
Performance hit in qemu-system-ppc
Hi, I noticed a considerable (~20%) slowdown in the cpu performance of qemu-system-ppc. Bisecting led me to this commit: d03f140804b345a85973976506492027f703d82d is the first bad commit commit d03f140804b345a85973976506492027f703d82d Author: Richard Henderson Date: Mon Dec 9 13:49:58 2019 -0800 cputlb: Move body of cpu_ldst_template.h out of line With the tracing hooks, the inline functions are no longer so simple. Once out-of-line, the current tlb_entry lookup is redundant with the one in the main load/store_helper. This also begins the introduction of a new target facing interface, with suffix *_mmuidx_ra. This is not yet official because the interface is not done for user-only. Use abi_ptr instead of target_ulong in preparation for user-only; the two types are identical for softmmu. What remains in cpu_ldst_template.h are the expansions for _code, _data, and MMU_MODE_SUFFIX. Tested-by: Philippe Mathieu-Daudé Signed-off-by: Richard Henderson accel/tcg/cputlb.c | 116 include/exec/cpu_ldst.h | 25 +++- include/exec/cpu_ldst_template.h | 125 --- 3 files changed, 166 insertions(+), 100 deletions(-) Thanks for looking into this issue, Howard
Re: [Bug 1850570] Re: Cannot use usb-host on Mac OS
On Fri, Nov 1, 2019 at 11:35 AM Programmingkid wrote: > > > On Oct 31, 2019, at 7:35 PM, qemu-devel-requ...@nongnu.org wrote: > > > > Message: 10 > > Date: Thu, 31 Oct 2019 18:39:11 - > > From: John Canada <1850...@bugs.launchpad.net> > > To: qemu-devel@nongnu.org > > Subject: [Bug 1850570] Re: Cannot use usb-host on Mac OS > > Message-ID: > > <157254715118.3076.2379100780378521691.mal...@gac.canonical.com> > > Content-Type: text/plain; charset="utf-8" > > > > Yes, I tried running as root. I also tried it on a different computer > > that is running Mac OS 10.13, and it gave the same errors. > > > > -- > > You received this bug notification because you are a member of qemu- > > devel-ml, which is subscribed to QEMU. > > https://bugs.launchpad.net/bugs/1850570 > > > > Title: > > Cannot use usb-host on Mac OS > > > > Status in QEMU: > > New > > > > Bug description: > > Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives > > these errors and the drive does not show up. Also, when Qemu is > > starting the drive ejects and remounts twice. Qemu built with > > ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl > > --disable-cocoa --enable-sdl-image. > > > > qemu-system-i386 image.qcow -usb -device usb-kbd -device > usb-host,vendorid=0x0781,productid=0x5571 > > libusb: error [darwin_claim_interface] USBInterfaceOpen: another > process has device opened for exclusive access > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] USBInterfaceOpen: another > process has device opened for exclusive access > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > libusb: error [darwin_claim_interface] interface not found > > > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions > > > Try this. Unplug the USB device. Plug it back in, and as fast as you can > start QEMU. > > My theory is another program might be using the device. This could be > Spotlight trying to index the drive. > > Another possibility is libusb is not compatible with Mac OS 10.13 yet. > > Do you have another computer that runs Mac OS 10.12 or under that you can > test on? > > I guess the longstanding issue with libusb and OSX is that some kext has already claimed the device. A solution would be to unload the kext currently claiming the device before starting Qemu. If possible. Also see here: https://apple.stackexchange.com/questions/363491/how-to-disable-usb-mass-storage-in-mojave-to-free-up-device-for-libusb and the links from that page: https://github.com/libusb/libusb/wiki/FAQ#How_can_I_run_libusb_applications_under_Mac_OS_X_if_there_is_already_a_kernel_extension_installed_for_the_device https://stackoverflow.com/questions/33545656/codeless-kext-for-usb-storage-device Best, Howard
Re: USB-audio sound issues with qemu-system-ppc in Linux and Windows.
Hi, I'd like to add to the previous report that similar issues are present in OSX (Sierra) builds of qemu-system-ppc. In Mac OS 9.2 and OS X 10.3 guests, sound through the usb-audio device is unrecognisable. After forcibly shutting down Mac OS 9.2 after it becomes unresponsive, qemu crashes. The OS X crash reporter says this: Thread 2 Crashed: 0 qemu-system-ppc 0x00010999c4bd timer_del + 13 (qemu-timer.c:429) 1 qemu-system-ppc 0x0001096d543f audio_reset_timer + 319 (audio.c:811) 2 qemu-system-ppc 0x0001096ca2a6 vm_state_notify + 262 (vl.c:1433) 3 qemu-system-ppc 0x00010953642f do_vm_stop + 47 (cpus.c:1104) 4 qemu-system-ppc 0x0001096ceed7 qemu_main + 17239 (vl.c:4477) 5 qemu-system-ppc 0x00010988a526 call_qemu_main + 38 (cocoa.m:1769) 6 qemu-system-ppc 0x0001099a11ee qemu_thread_start + 126 (qemu-thread-posix.c:519) 7 libsystem_pthread.dylib 0x7fffb864a93b _pthread_body + 180 8 libsystem_pthread.dylib 0x7fffb864a887 _pthread_start + 286 9 libsystem_pthread.dylib 0x7fffb864a08d thread_start + 13 Best, Howard
USB-audio sound issues with qemu-system-ppc in Linux and Windows.
Hi, I'm experiencing several issues related to sound using usb-audio when running qemu-system-ppc in Linux and Windows. Guests tried are Mac OS 9.2 and Mac OS X 10.0, 10.1, 10.2 and 10.3. (10.4 and 10.5 never have the usb-audio device available for audio playback, even though the device is recognised in the OS X system profiler.) It is hit and miss whether the audio device is actually available upon boot in 9.2 and the other versions of OS X. Qemu version tried is current master (Oct 25th), Windows version is cross-compiled from Fedora 30. I do not think there is any regression going on here, these are just issues that have been present for a long time. General issue: when audio is played, it almost always sounds crackling. For reasons of size, I uploaded 3 logs obtained in Linux running Mac OS X 10.3 with -trace "usb*" to: https://surfdrive.surf.nl/files/index.php/s/YfVVxEE3cHXkFPf/download 1. Log_no_audio_available.txt 2. Log_audio_available_2_sounds_played.txt 3. Log_audio_available_multi_sounds_played_untill_hangup.txt General issue in Linux (fedora 30)(which seems related to bug https://bugs.launchpad.net/qemu/+bug/1623998): [hsp@fedora30 qemu-master]$ ./startqemu.sh pulseaudio: set_sink_input_volume() failed pulseaudio: Reason: Invalid argument pulseaudio: set_sink_input_mute() failed pulseaudio: Reason: Invalid argument General issue in Windows 10: I always get to a point where this is logged: dsound: Could not lock playback buffer dsound: Reason: An invalid parameter was passed to the returning function dsound: Failed to lock buffer Linux specific. Qemu invocation for Mac OS 9.2: ./qemu-system-ppc -L pc-bios -boot c -M mac99 -m 512 \ -drive file=~/Mac-disks/9.2.img,format=raw,media=disk \ -serial stdio -sdl -device usb-audio -trace "*aud*" This immediately starts logging: 7380@1571817102.833929:audio_timer_start interval 10 ms 7380@1571817125.207880:audio_timer_delayed interval 16 ms 7380@1571817129.046816:audio_timer_delayed interval 16 ms Any movement of a window on the Linux desktop results in additional audio_timer_delayed logging. The audio_timer_delayed never stops. In Mac OS 9.2, the desktop icons disappear after some seconds of running, so the system cannot be stopped normally. Running the GTK GUI, only this is logged (no additional logging when moving windows). 14130@1571988483.402017:audio_timer_start interval 10 ms But the icons on the desktop also disappear. When running Mac OS X 10.X and clicking some system sounds, I see: 12134@1571818709.446031:audio_timer_start interval 10 ms 12134@1571818710.195023:audio_timer_stop 12134@1571818714.951030:audio_timer_start interval 10 ms 12134@1571818715.432959:audio_timer_stop 12134@1571818717.171045:audio_timer_start interval 10 ms 12134@1571818717.714323:audio_timer_stop 12134@1571818718.072381:audio_timer_start interval 10 ms 12134@1571818719.114544:audio_timer_stop After randomly clicking some system sounds more, the timer starts delaying and no longer stops: 12134@1571818893.564793:audio_timer_stop 12134@1571818895.698040:audio_timer_start interval 10 ms 12134@1571818899.961673:audio_timer_delayed interval 15 ms 12134@1571818900.472716:audio_timer_delayed interval 15 ms 12134@1571818902.759007:audio_timer_delayed interval 15 ms 12134@1571818905.803400:audio_timer_delayed interval 15 ms But the systems stays responsive, so can be shut down. Windows specific. Invocation: qemu-system-ppc.exe -L pc-bios -boot c -M mac99 -m 512 ^ -drive file=C:\Mac-disks\9.2.img,format=raw,media=disk ^ -serial stdio -sdl -device usb-audio -trace "*aud*" This immediately starts logging the audio_timer_start interval and never stops. Icons disappear from the desktop after some seconds. When running Mac OS X 10.X, playing just two system sounds results in: 2380@1571822566.040790:audio_timer_start interval 10 ms 2380@1571822566.108279:audio_timer_delayed interval 22 ms 2380@1571822566.128820:audio_timer_delayed interval 20 ms 2380@1571822566.150509:audio_timer_delayed interval 22 ms 2380@1571822566.172112:audio_timer_delayed interval 21 ms .. 2380@1571822566.561345:audio_timer_delayed interval 21 ms 2380@1571822566.583846:audio_timer_delayed interval 22 ms 2380@1571822566.600482:audio_timer_delayed interval 15 ms 2380@1571822566.610111:audio_timer_stop 2380@1571822572.226433:audio_timer_start interval 10 ms 2380@1571822572.250866:audio_timer_delayed interval 24 ms 2380@1571822572.269819:audio_timer_delayed interval 18 ms .. 2380@1571822572.452403:audio_timer_delayed interval 20 ms 2380@1571822572.474190:audio_timer_delayed interval 21 ms 2380@1571822572.509474:audio_timer_delayed interval 35 ms dsound: Could not lock playback buffer dsound: Reason: An invalid parameter was passed to the returning function dsound: Failed to lock buffer 2380@1571822572.560505:audio_timer_delayed interval 51 ms 2380@1571822572.581102:audio_timer_delayed interval 19 ms 2380@1571822572.600912:audio_timer_delayed interval 19 ms There is no saying when
