Re: Ping: [PATCH 0/2] cocoa.m: keyboard quality of life reborn
> On Sep 24, 2021, at 5:26 AM, Peter Maydell wrote: > > On Fri, 24 Sept 2021 at 00:08, Programmingkid > wrote: >> >> Hi Peter, are you reviewing cocoa patches? Should someone else see these >> patches? > > Gerd sent out a message a while back suggesting that people interested > in the cocoa UI (we have had several people recently submit patches) > ought to start reviewing each others' patches. I would certainly > prefer it if those people who are actively using and working on > the cocoa UI could take on more of this review work. > > -- PMM Problem is there isn't anyone else who does actually review cocoa patches. Even if there were others, there is no guarantee their suggestions would be something you agree with. Since you are the cocoa maintainer the only opinion that ultimately matters is yours .
Ping: [PATCH 0/2] cocoa.m: keyboard quality of life reborn
Hi Peter, are you reviewing cocoa patches? Should someone else see these patches? Thank you. Ping: https://patchwork.kernel.org/project/qemu-devel/patch/90e28997-9afa-4d8c-8323-bd087e629...@gmail.com/ https://patchwork.kernel.org/project/qemu-devel/patch/20210730170945.4468-3-programmingk...@gmail.com/ From 22a7f31c91d0803b0021e9802dde76daaec0738d Mon Sep 17 00:00:00 2001 From: John Arbuckle Date: Fri, 30 Jul 2021 13:01:26 -0400 Subject: [PATCH 0/2] cocoa.m: keyboard quality of life reborn These patches can really help improve keyboard usage with a guest. Based on patches by Gustavo Noronha Silva . John Arbuckle (2): Add full keyboard grab support Add ability to swap command/meta and options keys ui/cocoa.m | 178 ++--- 1 file changed, 170 insertions(+), 8 deletions(-) -- 2.24.3 (Apple Git-128)
Re: Implementing isochronous transfers in hw/hcd-ohci.c
> On Sep 11, 2021, at 5:46 AM, Howard Spoelstra wrote: > > > > 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. > > Best, > Howard So the question to answer is what is the wr gap?
Re: Implementing isochronous transfers in hw/hcd-ohci.c
> 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.
Implementing isochronous transfers in hw/hcd-ohci.c
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?
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Sep 1, 2021, at 5:08 AM, BALATON Zoltan wrote: > > On Tue, 31 Aug 2021, Programmingkid wrote: >> I just realized, I sent a patch to the developer list that fixes the missing >> qemu_vga.ndrv problem, but I do not know which maintainer to send it to. Who >> maintains the configure script? A search of the maintainers page was not >> clear as to who this is. > > That's what the get_maintainer script is for, try > scripts/get_maintainer.pl -f configure > Interestingly there's no maintainer listed for configure, in that case > probably pick the contributor with highest percentage and since it's a very > simple patch you can also cc qemu-trivial list. See: > https://wiki.qemu.org/Contribute/SubmitAPatch > where all this should be explained. > > Regards, > BALATON Zoltan Thank you for the advice. I have sent the patch to the trivial list and its maintainers.
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 31, 2021, at 5:08 PM, BALATON Zoltan wrote: > > On Tue, 31 Aug 2021, Programmingkid wrote: >>> On Aug 30, 2021, at 5:47 PM, BALATON Zoltan wrote: > >>> On Mon, 30 Aug 2021, Peter Maydell wrote: >>>> On Mon, 30 Aug 2021 at 21:29, Programmingkid >>>> wrote: >>>>> I found out that there are two pc-bios folders. One in the root directory >>>>> and one in the build directory. QEMU is looking in the pc-bios folder >>>>> located inside the build folder. The qemu_vga.ndrv file is only located >>>>> in the root directory pc-bios folder. I think a good solution to this >>>>> issue is to first remove one of the pc-bios folders. I'm not sure if it >>>>> is just me who has two pc-bios folders or if everyone does. >>>> >>>> Having two pc-bios folders is expected. The one in the source tree is >>>> the one which has the files we actually carry around in git. The one >>>> in the build tree is created by 'configure' and populated with symbolic >>>> links back to the files in the source tree. We need this one because >>>> the QEMU executable doesn't (and shouldn't) know where the source tree is: >>>> when it is looking for files it will look in places relative to the >>>> location of the executable itself (ie relative to the build tree) >>>> as well as places set by configure (used when you install QEMU and >>>> its various supporting files). >>>> >>>> The reason qemu_vga.ndrv is not in the pc-bios folder in the build >>>> tree is because when that file was added we forgot to add handling >>>> for it in configure. I'm not sure why nobody else has fallen over >>>> this in the intervening 3 years: running QEMU from the build tree >>>> will never find the file, and it will not be installed via >>>> 'make install' either. >>> >>> This file is a driver for MacOS and not many people run that old OS. Those >>> who do probably use Howard's binaries and follow his guides that tell you >>> to use -L pc-bios on command line. I always wondered why that's needed when >>> it should find it by default but this explains it and probably also your >>> question why nobody complained. >>> >>> Regards, >>> BALATON Zoltan >> >> This does sound like a good explanation. I am pretty sure I was able to use >> my Mac OS 9 VM without the -L option in the past and still have many video >> resolutions available. > > Depends how far back in the past was that. If before the meson conversion > that introduced the build dir maybe you run it from the source dir (if used > in-tree build) and it found the file. I'm not sure if it still works if you > run from source dir such as build/qemu-system-ppc that is without changing > current dir to build dir. If it works that way then maybe you ran it like > that before. (Or maybe had an installed version and it picked up the file > from there.) > > Regards, > BALATON Zoltan That was around version 2.10 so a while back. I just realized, I sent a patch to the developer list that fixes the missing qemu_vga.ndrv problem, but I do not know which maintainer to send it to. Who maintains the configure script? A search of the maintainers page was not clear as to who this is.
Re: [PATCH] Add qemu_vga.ndrv to build/pc-bios folder
> On Aug 31, 2021, at 4:33 PM, Mark Cave-Ayland > wrote: > > On 31/08/2021 17:50, John Arbuckle wrote: > >> Currently the file qemu_vga.ndrv is not copied into the /build/pc-bios >> folder. This makes all video resolution choices disappear from a PowerPC Mac >> OS guest. This patch has the qemu_vga.ndrv file copied into the >> build/pc-bios folder giving users back their video resolution choices. >> Signed-off-by: John Arbuckle >> --- >> configure | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> diff --git a/configure b/configure >> index 9a79a004d7..281577e46f 100755 >> --- a/configure >> +++ b/configure >> @@ -5056,7 +5056,9 @@ for bios_file in \ >> $source_path/pc-bios/openbios-* \ >> $source_path/pc-bios/u-boot.* \ >> $source_path/pc-bios/edk2-*.fd.bz2 \ >> -$source_path/pc-bios/palcode-* >> +$source_path/pc-bios/palcode-* \ >> +$source_path/pc-bios/qemu_vga.ndrv >> + >> do >> LINKS="$LINKS pc-bios/$(basename $bios_file)" >> done > > I think the patch looks correct, however the commit message and subject > aren't quite right. How about something like: > > [PATCH] configure: add missing pc-bios/qemu_vga.ndrv symlink in build tree > > Ensure that a link to pc-bios/qemu_vga.ndrv is added to the build tree, > otherwise the optional MacOS client driver will not be loaded by OpenBIOS > when launching QEMU directly from the build directory. > > > ATB, > > Mark. Ok. I will create a new patch with these changes.
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 31, 2021, at 11:57 AM, Peter Maydell wrote: > > On Tue, 31 Aug 2021 at 16:50, Programmingkid > wrote: >> Then I ran './configure --target-list=ppc-softmmu && make -j 9'. >> The pc-bios folder in the build directory was still populated with >> all the files (except for qemu_vga.ndrv). Anyone knows what exactly >> populates the pc-bios folder in the build folder? > > As I said above, it is the configure script, which needs a fix > to add qemu_vga.ndrv to the list of symlinks it creates. > > -- PMM Thank you for the information. I created a new patch that should solve this problem.
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 30, 2021, at 5:47 PM, BALATON Zoltan wrote: > > On Mon, 30 Aug 2021, Peter Maydell wrote: >> On Mon, 30 Aug 2021 at 21:29, Programmingkid >> wrote: >>> I found out that there are two pc-bios folders. One in the root directory >>> and one in the build directory. QEMU is looking in the pc-bios folder >>> located inside the build folder. The qemu_vga.ndrv file is only located >>> in the root directory pc-bios folder. I think a good solution to this >>> issue is to first remove one of the pc-bios folders. I'm not sure if it >>> is just me who has two pc-bios folders or if everyone does. >> >> Having two pc-bios folders is expected. The one in the source tree is >> the one which has the files we actually carry around in git. The one >> in the build tree is created by 'configure' and populated with symbolic >> links back to the files in the source tree. We need this one because >> the QEMU executable doesn't (and shouldn't) know where the source tree is: >> when it is looking for files it will look in places relative to the >> location of the executable itself (ie relative to the build tree) >> as well as places set by configure (used when you install QEMU and >> its various supporting files). >> >> The reason qemu_vga.ndrv is not in the pc-bios folder in the build >> tree is because when that file was added we forgot to add handling >> for it in configure. I'm not sure why nobody else has fallen over >> this in the intervening 3 years: running QEMU from the build tree >> will never find the file, and it will not be installed via >> 'make install' either. > > This file is a driver for MacOS and not many people run that old OS. Those > who do probably use Howard's binaries and follow his guides that tell you to > use -L pc-bios on command line. I always wondered why that's needed when it > should find it by default but this explains it and probably also your > question why nobody complained. > > Regards, > BALATON Zoltan This does sound like a good explanation. I am pretty sure I was able to use my Mac OS 9 VM without the -L option in the past and still have many video resolutions available.
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 30, 2021, at 4:59 PM, Peter Maydell wrote: > > On Mon, 30 Aug 2021 at 21:29, Programmingkid > wrote: >> I found out that there are two pc-bios folders. One in the root directory >> and one in the build directory. QEMU is looking in the pc-bios folder >> located inside the build folder. The qemu_vga.ndrv file is only located >> in the root directory pc-bios folder. I think a good solution to this >> issue is to first remove one of the pc-bios folders. I'm not sure if it >> is just me who has two pc-bios folders or if everyone does. > > Having two pc-bios folders is expected. The one in the source tree is > the one which has the files we actually carry around in git. The one > in the build tree is created by 'configure' and populated with symbolic > links back to the files in the source tree. We need this one because > the QEMU executable doesn't (and shouldn't) know where the source tree is: > when it is looking for files it will look in places relative to the > location of the executable itself (ie relative to the build tree) > as well as places set by configure (used when you install QEMU and > its various supporting files). > > The reason qemu_vga.ndrv is not in the pc-bios folder in the build > tree is because when that file was added we forgot to add handling > for it in configure. I'm not sure why nobody else has fallen over > this in the intervening 3 years: running QEMU from the build tree > will never find the file, and it will not be installed via > 'make install' either. > > (The pc-bios symlink stuff is a bit of a mess, as the comment about > it in configure notes. Perhaps meson now offers a cleaner way to > handle this? In particular pc-bios/meson.build already has to carry > around a complete list of all the bios blobs, so it could probably > create the symlink farm itself.) > > thanks > -- PMM I did try working on the pc-bios/meson.build file. I deleted all the entries in the 'blobs' list. Then I ran './configure --target-list=ppc-softmmu && make -j 9'. The pc-bios folder in the build directory was still populated with all the files (except for qemu_vga.ndrv). Anyone knows what exactly populates the pc-bios folder in the build folder?
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 29, 2021, at 8:17 AM, Peter Maydell wrote: > > On Sun, 29 Aug 2021 at 11:18, Mark Cave-Ayland > wrote: >> What I don't understand is that the binary is installed by default in QEMU's >> sharedir >> so everything works out of the box with "make install". Do you have some >> kind of >> custom installer which is doing something different? > > John has had problems before with the QEMU binary not being able to find > files at runtime (the previous example was the QEMU logo file). I suspect > we have a common underlying bug there. John -- do you run QEMU from > the build directory, or by installing it first and running the installed > binary, or in some other way ? > > thanks > -- PMM I found out that there are two pc-bios folders. One in the root directory and one in the build directory. QEMU is looking in the pc-bios folder located inside the build folder. The qemu_vga.ndrv file is only located in the root directory pc-bios folder. I think a good solution to this issue is to first remove one of the pc-bios folders. I'm not sure if it is just me who has two pc-bios folders or if everyone does. Anyone else see this?
Re: [PATCH] Report any problems with loading the VGA driver for PPC Macintosh targets
> On Aug 29, 2021, at 8:17 AM, Peter Maydell wrote: > > On Sun, 29 Aug 2021 at 11:18, Mark Cave-Ayland > wrote: >> What I don't understand is that the binary is installed by default in QEMU's >> sharedir >> so everything works out of the box with "make install". Do you have some >> kind of >> custom installer which is doing something different? > > John has had problems before with the QEMU binary not being able to find > files at runtime (the previous example was the QEMU logo file). I suspect > we have a common underlying bug there. John -- do you run QEMU from > the build directory, or by installing it first and running the installed > binary, or in some other way ? > > thanks > -- PMM I run QEMU from the build directory.
Ping: [PATCH 2/2] ui/cocoa.m: Add ability to swap command/meta and options keys
Ping:
From: John Arbuckle
Date: Fri, 30 Jul 2021 10:18:56 -0400
Subject: [PATCH 2/2] ui/cocoa.m: Add ability to swap command/meta and options
keys
For users who are use to using a Macintosh keyboard having to use a PC keyboard
can be a pain because the Command/meta and Option/Alt keys are switched. To
make life easier this option is added to allow the user to switch how the guest
reacts to each of these keys being pushed. It can make a Macintosh keyboard user
feel almost at home with a PC keyboard. The same could be said for PC keyboard
users who have to use a Macinosh keyboard.
Based on patch by Gustavo Noronha Silva .
Signed-off-by: John Arbuckle
---
ui/cocoa.m | 66 +++---
1 file changed, 58 insertions(+), 8 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index fdef9e9901..98596d5f38 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -116,6 +116,7 @@ static void cocoa_switch(DisplayChangeListener *dcl,
static CFMachPortRef eventsTap = NULL;
static CFRunLoopSourceRef eventsTapSource = NULL;
+static bool swap_command_option_keys = false;
static void with_iothread_lock(CodeBlock block)
{
@@ -810,12 +811,22 @@ - (bool) handleEventLocked:(NSEvent *)event
qkbd_state_key_event(kbd, Q_KEY_CODE_CTRL_R, false);
}
if (!(modifiers & NSEventModifierFlagOption)) {
-qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
-qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
+if (swap_command_option_keys) {
+qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
+qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
+} else {
+qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
+qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
+}
}
if (!(modifiers & NSEventModifierFlagCommand)) {
-qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
-qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
+if (swap_command_option_keys) {
+qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
+qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
+} else {
+qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
+qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
+}
}
switch ([event type]) {
@@ -847,13 +858,22 @@ - (bool) handleEventLocked:(NSEvent *)event
case kVK_Option:
if (!!(modifiers & NSEventModifierFlagOption)) {
-[self toggleKey:Q_KEY_CODE_ALT];
+if (swap_command_option_keys) {
+[self toggleKey:Q_KEY_CODE_META_L];
+} else {
+[self toggleKey:Q_KEY_CODE_ALT];
+}
+
}
break;
case kVK_RightOption:
if (!!(modifiers & NSEventModifierFlagOption)) {
-[self toggleKey:Q_KEY_CODE_ALT_R];
+if (swap_command_option_keys) {
+[self toggleKey:Q_KEY_CODE_META_R];
+} else {
+[self toggleKey:Q_KEY_CODE_ALT_R];
+}
}
break;
@@ -861,14 +881,22 @@ - (bool) handleEventLocked:(NSEvent *)event
case kVK_Command:
if (isMouseGrabbed &&
!!(modifiers & NSEventModifierFlagCommand)) {
-[self toggleKey:Q_KEY_CODE_META_L];
+if (swap_command_option_keys) {
+[self toggleKey:Q_KEY_CODE_ALT];
+} else {
+[self toggleKey:Q_KEY_CODE_META_L];
+}
}
break;
case kVK_RightCommand:
if (isMouseGrabbed &&
!!(modifiers & NSEventModifierFlagCommand)) {
-[self toggleKey:Q_KEY_CODE_META_R];
+if (swap_command_option_keys) {
+[self toggleKey:Q_KEY_CODE_ALT_R];
+} else {
+[self toggleKey:Q_KEY_CODE_META_R];
+}
}
break;
}
@@ -1188,6 +1216,7 @@ - (IBAction) do_about_menu_item: (id) sender;
- (void)make_about_window;
- (void)adjustSpeed:(id)sender;
- (IBAction)doFullGrab:(id)sender;
+- (IBAction)doSwapCommandOptionKeys:(id)sender;
@end
@implementation QemuCocoaAppController
@@ -1669,6 +1698,22 @@ - (IBAction)doFullGrab:(id) sender
}
}
+// The action method to the "Options->Swap Command and Option Keys" menu item
+- (IBAction)doSwapCommandOptionKeys:(id)sender
+{
+// If the menu item is not checked
+if ([sender state] ==
Ping: [PATCH 1/2] ui/cocoa.m: Add full keyboard grab support
ping
From: John Arbuckle
Date: Thu, 29 Jul 2021 14:41:57 -0400
Subject: [PATCH 1/2] ui/cocoa.m: Add full keyboard grab support
There are keyboard shortcuts that are vital for use in a guest that runs Mac OS.
These shortcuts are reserved for Mac OS use only which makes having the guest
see them impossible on a Mac OS host - until now. This patch will enable the
user to decide if the guest should see all keyboard shortcuts using a menu item.
This patch adds a new menu called Options and a new menu item called
"Full Keyboard Grab". Simply selecting this menu item will turn the feature on
or off at any time. Mac OS requires the user to enable access to assistive
devices to use this feature. How to do this varies with each Mac OS version.
Based on patch by Gustavo Noronha Silva .
Signed-off-by: John Arbuckle
---
ui/cocoa.m | 112 +
1 file changed, 112 insertions(+)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 9f72844b07..fdef9e9901 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -114,6 +114,9 @@ static void cocoa_switch(DisplayChangeListener *dcl,
typedef void (^CodeBlock)(void);
typedef bool (^BoolCodeBlock)(void);
+static CFMachPortRef eventsTap = NULL;
+static CFRunLoopSourceRef eventsTapSource = NULL;
+
static void with_iothread_lock(CodeBlock block)
{
bool locked = qemu_mutex_iothread_locked();
@@ -332,10 +335,27 @@ - (float) cdx;
- (float) cdy;
- (QEMUScreen) gscreen;
- (void) raiseAllKeys;
+- (void) setFullGrab;
@end
QemuCocoaView *cocoaView;
+// Part of the full keyboard grab system
+static CGEventRef handleTapEvent(CGEventTapProxy proxy, CGEventType type,
+CGEventRef cgEvent, void *userInfo)
+{
+QemuCocoaView *cocoaView = (QemuCocoaView*) userInfo;
+NSEvent* event = [NSEvent eventWithCGEvent:cgEvent];
+if ([cocoaView isMouseGrabbed] && [cocoaView handleEvent:event]) {
+COCOA_DEBUG("Global events tap: qemu handled the event, capturing!\n");
+return NULL;
+}
+COCOA_DEBUG("Global events tap: qemu did not handle the event, letting it"
+" through...\n");
+
+return cgEvent;
+}
+
@implementation QemuCocoaView
- (id)initWithFrame:(NSRect)frameRect
{
@@ -361,6 +381,12 @@ - (void) dealloc
}
qkbd_state_free(kbd);
+if (eventsTap) {
+CFRelease(eventsTap);
+}
+if (eventsTapSource) {
+CFRelease(eventsTapSource);
+}
[super dealloc];
}
@@ -1086,6 +1112,50 @@ - (void) raiseAllKeys
qkbd_state_lift_all_keys(kbd);
});
}
+
+// Inserts the event tap.
+// This enables us to receive keyboard events that Mac OS would
+// otherwise not let us see - like Command-Option-Esc.
+- (void) setFullGrab
+{
+COCOA_DEBUG("QemuCocoaView: setFullGrab\n");
+NSString *advice = @"Try enabling access to assistive devices";
+CGEventMask mask = CGEventMaskBit(kCGEventKeyDown) |
+CGEventMaskBit(kCGEventKeyUp) | CGEventMaskBit(kCGEventFlagsChanged);
+eventsTap = CGEventTapCreate(kCGHIDEventTap, kCGHeadInsertEventTap,
+ kCGEventTapOptionDefault, mask,
handleTapEvent,
+ self);
+if (!eventsTap) {
+@throw [NSException
+ exceptionWithName:@"Tap failure"
+reason:[NSString stringWithFormat:@"%@\n%@", @"Could not "
+"create event tap.", advice]
+userInfo:nil];
+} else {
+COCOA_DEBUG("Global events tap created! Will capture system key"
+" combos.\n");
+}
+
+eventsTapSource =
+CFMachPortCreateRunLoopSource(kCFAllocatorDefault, eventsTap, 0);
+if (!eventsTapSource ) {
+@throw [NSException
+ exceptionWithName:@"Tap failure"
+ reason:@"Could not obtain current CFRunLoop source."
+userInfo:nil];
+}
+CFRunLoopRef runLoop = CFRunLoopGetCurrent();
+if (!runLoop) {
+ @throw [NSException
+ exceptionWithName:@"Tap failure"
+ reason:@"Could not obtain current CFRunLoop."
+userInfo:nil];
+}
+
+CFRunLoopAddSource(runLoop, eventsTapSource, kCFRunLoopDefaultMode);
+CFRelease(eventsTapSource);
+}
+
@end
@@ -1117,6 +1187,7 @@ - (void)openDocumentation:(NSString *)filename;
- (IBAction) do_about_menu_item: (id) sender;
- (void)make_about_window;
- (void)adjustSpeed:(id)sender;
+- (IBAction)doFullGrab:(id)sender;
@end
@implementation QemuCocoaAppController
@@ -1569,6 +1640,35 @@ - (void)adjustSpeed:(id)sender
COCOA_DEBUG("cpu throttling at %d%c\n", cpu_throttle_get_percentage(),
'%');
}
+// The action method to the 'Options->Full Keyboard Grab' menu item
+- (IBAction)doFullGrab:(id) sender
+{
+@try
+{
+// Set the state of the menu item
+// if already checked
+if ([sender state] == NSControlStateValueOn) {
+// remove runloop source
+
Re: edid support for a Mac OS 10.8 guest
> On Aug 25, 2021, at 1:24 AM, Chen Zhang wrote: > >> On Tue, Aug 24, 2021 at 05:46:43PM -0400, Programmingkid wrote: >>> Hi, I recently tried using the edid feature in QEMU for my Mac OS 10.8 >>> guest >>> like this: -device VGA,edid=on,xres=1280,yres=800. When the guest operating >>> system loaded there were no additional options available in the Display >>> settings. Would you know what is wrong? >> >> Probably macos just doesn't read the edid block ... >> >> take care, >> Gerd > Hi, > Probably it was due to the low default vbe size. > Adding a `vgamem_mb=64` to the option list would suffice. > > Best regards Thanks for the help. The option unfortunately did not work.
edid support for a Mac OS 10.8 guest
Hi, I recently tried using the edid feature in QEMU for my Mac OS 10.8 guest like this: -device VGA,edid=on,xres=1280,yres=800. When the guest operating system loaded there were no additional options available in the Display settings. Would you know what is wrong? Thank you.
Re: Picture missing in About dialog on cocoa ui
> On Jul 8, 2021, at 2:38 PM, Programmingkid wrote: > > > >> On Jul 8, 2021, at 1:50 PM, Peter Maydell wrote: >> >> On Thu, 8 Jul 2021 at 17:28, Programmingkid >> wrote: >>> The problem with e31746ecf8dd2f25f687c94ac14016a3ba5debfc is it requires a >>> picture file to be found in a certain path. My original code used QEMU's >>> icon to obtain a picture. The reason why the picture in the About dialog >>> stopped appearing was because of the move to the meson build system. >>> A new patch has just been committed that fixes the missing icon issue. >>> Using 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' fixes the >>> missing picture issue in the About dialog. Hi Peter, I was wondering if you had made a decision on whether you plan on reverting the patch that breaks the About dialog for the Cocoa UI. Thank you.
Re: [PATCH v5 0/2] cocoa: keyboard quality of life
> From: Gustavo Noronha Silva > > v5 addresses the casting issue pointed out by Akihiko Odaki. > Sorry it took me so long to update the patches, but here > they are! Hopefully we can get them in now ;D > > Btw I also changed my email address slightly (.dev.br > instead of .eti.br). > > - > > This series adds two new options to the cocoa display: > > - full-grab causes it to use a global tap to steal system combos > away from Mac OS X, so they can be handled by the VM > > - swap-option-command does what it says on the tin; while that is > something you can do at the Mac OS X level or even supported by > some keyboards, it is much more convenient to have qemu put > Meta/Super and Alt where they belong if you are running a > non-Mac VM > > Both are off by default. For full-grab in particular, it is off also > because unfortunately it needs accessibility permissions for input > grabbing, so it requires more deliberate action by the user anyway. > > Gustavo Noronha Silva (2): > ui/cocoa: capture all keys and combos when mouse is grabbed > ui/cocoa: add option to swap Option and Command > > qapi/ui.json| 22 + > qemu-options.hx | 4 ++ > ui/cocoa.m | 129 > 3 files changed, 146 insertions(+), 9 deletions(-) > > -- > 2.30.1 (Apple Git-130) I could not make the full-grab feature work. I tried this: ./build/qemu-system-ppc -display cocoa,full_grab=on This is the error message I saw: qemu-system-ppc: -display cocoa,full_grab=on: Parameter 'full_grab' is unexpected The command and option key swapping feature does work. This should be a very useful feature to those with a PC keyboard. I totally suggest that a new menu called Options be made with these features added. This is how it could look like: Options - Full Keyboard Grab - Swap Command and Option Keys Right now the user has to restart QEMU if he or she wants to swap the command and options keys to initiate a full keyboard grab. This is not fun. With a menu the user could change these options while QEMU remains running. This code can be used to add the Options menu: ui/cocoa.m | 137 + 1 file changed, 128 insertions(+), 9 deletions(-) diff --git a/ui/cocoa.m b/ui/cocoa.m index 9f72844b07..de85305c7a 100644 --- a/ui/cocoa.m +++ b/ui/cocoa.m @@ -1655,6 +1755,14 @@ static void create_initial_menus(void) [menuItem setSubmenu:menu]; [[NSApp mainMenu] addItem:menuItem]; +// Options menu +menu = [[NSMenu alloc] initWithTitle:@"Options"]; +[menu addItem: [[[NSMenuItem alloc] initWithTitle:@"Full Keyboard Grab" action:@selector(setFullGrab:) keyEquivalent:@""] autorelease]]; +[menu addItem: [[[NSMenuItem alloc] initWithTitle:@"Swap Command and Option Keys" action:@selector(setSwapOptionCommand:) keyEquivalent:@""] autorelease]]; +menuItem = [[[NSMenuItem alloc] initWithTitle:@"Options" action:nil keyEquivalent:@""] autorelease]; +[menuItem setSubmenu:menu]; +[[NSApp mainMenu] addItem:menuItem]; + // Window menu menu = [[NSMenu alloc] initWithTitle:@"Window"]; [menu addItem: [[[NSMenuItem alloc] initWithTitle:@"Minimize" action:@selector(performMiniaturize:) keyEquivalent:@"m"] autorelease]]; // Miniaturize To be able to check and uncheck menu items you could see the method (void)adjustSpeed:(id)sender. Please let me know if there is anything else I could do to help. Thank you.
Re: [PATCH] block/vvfat: fix: drop backing
> On Jul 15, 2021, at 8:48 AM, Vladimir Sementsov-Ogievskiy
> wrote:
>
> Most probably this fake backing child doesn't work anyway (see notes
> about it in a8a4d15c1c34d).
>
> Still, since 25f78d9e2de528473d52 drivers are required to set
> .supports_backing if they want to call bdrv_set_backing_hd, so now
> vvfat just doesn't work because of this check.
>
> Let's finally drop this fake backing file.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
> Honestly, I don't know, which scenarios may break after this patch.
> So, that's just my idea that it's more correct to drop this thing than
> set .supports_backing in vvfat driver.
>
> block/vvfat.c | 43 ---
> 1 file changed, 4 insertions(+), 39 deletions(-)
>
> diff --git a/block/vvfat.c b/block/vvfat.c
> index ae9d387da7..34bf1e3a86 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -3098,26 +3098,6 @@ static int coroutine_fn
> vvfat_co_block_status(BlockDriverState *bs,
> return BDRV_BLOCK_DATA;
> }
>
> -static int coroutine_fn
> -write_target_commit(BlockDriverState *bs, uint64_t offset, uint64_t bytes,
> -QEMUIOVector *qiov, int flags)
> -{
> -int ret;
> -
> -BDRVVVFATState* s = *((BDRVVVFATState**) bs->opaque);
> -qemu_co_mutex_lock(>lock);
> -ret = try_commit(s);
> -qemu_co_mutex_unlock(>lock);
> -
> -return ret;
> -}
> -
> -static BlockDriver vvfat_write_target = {
> -.format_name= "vvfat_write_target",
> -.instance_size = sizeof(void*),
> -.bdrv_co_pwritev= write_target_commit,
> -};
> -
> static void vvfat_qcow_options(BdrvChildRole role, bool parent_is_format,
>int *child_flags, QDict *child_options,
>int parent_flags, QDict *parent_options)
> @@ -3133,7 +3113,6 @@ static int enable_write_target(BlockDriverState *bs,
> Error **errp)
> {
> BDRVVVFATState *s = bs->opaque;
> BlockDriver *bdrv_qcow = NULL;
> -BlockDriverState *backing;
> QemuOpts *opts = NULL;
> int ret;
> int size = sector2cluster(s, s->sector_count);
> @@ -3184,13 +3163,6 @@ static int enable_write_target(BlockDriverState *bs,
> Error **errp)
> unlink(s->qcow_filename);
> #endif
>
> -backing = bdrv_new_open_driver(_write_target, NULL,
> BDRV_O_ALLOW_RDWR,
> - _abort);
> -*(void**) backing->opaque = s;
> -
> -bdrv_set_backing_hd(s->bs, backing, _abort);
> -bdrv_unref(backing);
> -
> return 0;
>
> err:
> @@ -3205,17 +3177,10 @@ static void vvfat_child_perm(BlockDriverState *bs,
> BdrvChild *c,
> uint64_t perm, uint64_t shared,
> uint64_t *nperm, uint64_t *nshared)
> {
> -if (role & BDRV_CHILD_DATA) {
> -/* This is a private node, nobody should try to attach to it */
> -*nperm = BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE;
> -*nshared = BLK_PERM_WRITE_UNCHANGED;
> -} else {
> -assert(role & BDRV_CHILD_COW);
> -/* The backing file is there so 'commit' can use it. vvfat doesn't
> - * access it in any way. */
> -*nperm = 0;
> -*nshared = BLK_PERM_ALL;
> -}
> +assert(role & BDRV_CHILD_DATA);
> +/* This is a private node, nobody should try to attach to it */
> +*nperm = BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE;
> +*nshared = BLK_PERM_WRITE_UNCHANGED;
> }
>
> static void vvfat_close(BlockDriverState *bs)
> --
> 2.29.2
>
Tested-by: John Arbuckle
Re: Host folder sharing via USB issue
> On Jul 14, 2021, at 6:35 AM, Vladimir Sementsov-Ogievskiy > wrote: > > 14.07.2021 00:04, Programmingkid wrote: >> Hi I have noticed that host folder sharing via USB has recently stopped >> working. After doing some git bisecting I found this as the patch that seems >> to be the issue: >> 25f78d9e2de528473d52acfcf7acdfb64e3453d4 is the first bad commit >> commit 25f78d9e2de528473d52acfcf7acdfb64e3453d4 >> Author: Vladimir Sementsov-Ogievskiy >> Date: Thu Jun 10 15:05:34 2021 +0300 >> block: move supports_backing check to bdrv_set_file_or_backing_noperm() >> Move supports_backing check of bdrv_reopen_parse_backing to called >> (through bdrv_set_backing_noperm()) bdrv_set_file_or_backing_noperm() >> function. The check applies to general case, so it's appropriate for >> bdrv_set_file_or_backing_noperm(). >> We have to declare backing support for two test drivers, otherwise >> new >> check fails. >> Signed-off-by: Vladimir Sementsov-Ogievskiy >> >> Message-Id: <20210610120537.196183-7-vsement...@virtuozzo.com> >> Signed-off-by: Kevin Wolf >> block.c | 29 +++-- >> tests/unit/test-bdrv-drain.c | 1 + >> tests/unit/test-bdrv-graph-mod.c | 1 + >> 3 files changed, 17 insertions(+), 14 deletions(-) >> To reproduce this issue run this command: >> qemu-system-i386 -usb -device usb-storage,drive=fat16 -drive >> file=fat:rw:fat-type=16:"",id=fat16,format=raw,if=none >> Results: >> Unexpected error in bdrv_set_file_or_backing_noperm() at ../block.c:3159: >> qemu-system-i386: -drive file=fat:rw:fat-type=16:> path>,id=fat16,format=raw,if=none: Driver 'vvfat' of node '#block057' does >> not support backing files >> Abort trap: 6 >> Expected results: >> QEMU start running normally. >> Please let me know if you need more information. >> Thank you. > > Hi! > > Look at bt: > > #0 0x7fd34f6939d5 in raise () at /lib64/libc.so.6 > #1 0x7fd34f67c8a4 in abort () at /lib64/libc.so.6 > #2 0x55e446d967aa in error_handle_fatal (errp=0x55e447652680 > , err=0x55e448d17a20) at ../util/error.c:40 > #3 0x55e446d968da in error_setv >(errp=0x55e447652680 , src=0x55e446f8755b "../block.c", > line=3158, func=0x55e446f89c20 <__func__.64> > "bdrv_set_file_or_backing_noperm", err_class=ERROR_CLASS_GENERIC_ERROR, > fmt=0x55e446f88458 "Driver '%s' of node '%s' does not support backing files", > ap=0x7ffc31aba090, suffix=0x0) at ../util/error.c:73 > #4 0x55e446d96ab8 in error_setg_internal >(errp=0x55e447652680 , src=0x55e446f8755b "../block.c", > line=3158, func=0x55e446f89c20 <__func__.64> > "bdrv_set_file_or_backing_noperm", fmt=0x55e446f88458 "Driver '%s' of node > '%s' does not support backing files") at ../util/error.c:97 > #5 0x55e446c411cf in bdrv_set_file_or_backing_noperm > (parent_bs=0x55e448ceebe0, child_bs=0x55e448d21e40, is_backing=true, > tran=0x55e448d16c20, errp=0x55e447652680 ) at ../block.c:3158 > #6 0x55e446c41377 in bdrv_set_backing_noperm (bs=0x55e448ceebe0, > backing_hd=0x55e448d21e40, tran=0x55e448d16c20, errp=0x55e447652680 > ) at ../block.c:3218 > #7 0x55e446c413ae in bdrv_set_backing_hd (bs=0x55e448ceebe0, > backing_hd=0x55e448d21e40, errp=0x55e447652680 ) at > ../block.c:3227 > #8 0x55e446c1bd37 in enable_write_target (bs=0x55e448ceebe0, > errp=0x7ffc31aba360) at ../block/vvfat.c:3191 > #9 0x55e446c16fe8 in vvfat_open (bs=0x55e448ceebe0, > options=0x55e448cf4330, flags=155650, errp=0x7ffc31aba360) at > ../block/vvfat.c:1236 > #10 0x55e446c3df37 in bdrv_open_driver (bs=0x55e448ceebe0, > drv=0x55e4475e9760 , node_name=0x0, options=0x55e448cf4330, > open_flags=155650, errp=0x7ffc31aba470) at ../block.c:1550 > #11 0x55e446c3e8ee in bdrv_open_common (bs=0x55e448ceebe0, file=0x0, > options=0x55e448cf4330, errp=0x7ffc31aba470) at ../block.c:1827 > #12 0x55e446c427b6 in bdrv_open_inherit >(filename=0x55e448ce4300 "fat:rw:fat-type=16:/tmp", reference=0x0, > options=0x55e448cf4330, flags=40962, parent=0x55e448ce75a0, > child_class=0x55e4475099c0 , child_role=19, errp=0x7ffc31aba670) >at ../block.c:3747 > #13 0x55e446c419f5 in bdrv_open_child_bs >(filename=0x55e448ce4300 "fat:rw:fat-type=16:/tmp", > options=0x55e448cec9f0, bdref_key=0x55e446f884d0 "file", > parent=0x55e448ce75a0, child_class=0x55e4475099c0 , > child_role=19, allow_none=true, errp=0x7ffc31aba670) at ../block.c:3387 > #14 0x55e446c42
Host folder sharing via USB issue
Hi I have noticed that host folder sharing via USB has recently stopped working. After doing some git bisecting I found this as the patch that seems to be the issue: 25f78d9e2de528473d52acfcf7acdfb64e3453d4 is the first bad commit commit 25f78d9e2de528473d52acfcf7acdfb64e3453d4 Author: Vladimir Sementsov-Ogievskiy Date: Thu Jun 10 15:05:34 2021 +0300 block: move supports_backing check to bdrv_set_file_or_backing_noperm() Move supports_backing check of bdrv_reopen_parse_backing to called (through bdrv_set_backing_noperm()) bdrv_set_file_or_backing_noperm() function. The check applies to general case, so it's appropriate for bdrv_set_file_or_backing_noperm(). We have to declare backing support for two test drivers, otherwise new check fails. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-Id: <20210610120537.196183-7-vsement...@virtuozzo.com> Signed-off-by: Kevin Wolf block.c | 29 +++-- tests/unit/test-bdrv-drain.c | 1 + tests/unit/test-bdrv-graph-mod.c | 1 + 3 files changed, 17 insertions(+), 14 deletions(-) To reproduce this issue run this command: qemu-system-i386 -usb -device usb-storage,drive=fat16 -drive file=fat:rw:fat-type=16:"",id=fat16,format=raw,if=none Results: Unexpected error in bdrv_set_file_or_backing_noperm() at ../block.c:3159: qemu-system-i386: -drive file=fat:rw:fat-type=16:,id=fat16,format=raw,if=none: Driver 'vvfat' of node '#block057' does not support backing files Abort trap: 6 Expected results: QEMU start running normally. Please let me know if you need more information. Thank you.
Re: usb-host device not working
> On Jul 13, 2021, at 10:54 AM, Daniel P. Berrangé wrote: > > On Tue, Jul 13, 2021 at 10:49:12AM -0400, Programmingkid wrote: >> I have been having problems with using host USB devices lately. I use to be >> able to use host USB devices but can't currently. After doing some git >> bisecting I found it was this patch that causes this issue: >> >> commit 627302afb2f85cdd4b59595361876487aef19b7a (refs/bisect/bad) >> Author: Gerd Hoffmann >> Date: Thu Jun 24 12:38:35 2021 +0200 >> >>usb: build usb-host as module >> >>Drop one more shared library dependency (libusb) from core qemu. >> >>Signed-off-by: Gerd Hoffmann >>Reviewed-by: Jose R. Ziviani >>Message-Id: <20210624103836.2382472-34-kra...@redhat.com> >>Signed-off-by: Paolo Bonzini >> >> I build QEMU like this: >> >> ./configure --target-list=i386-softmmu --enable-libusb && make -j 9 >> >> This command use to work but fails now with the above commit: >> >> qemu-system-i386 -usb -device usb-host,vendorid=0x093a,productid=0x2510 >> >> I think this is a bug with the commit. Any suggestions? > > It'll be helpful to explain what kind of failure you observe, including > any exact error messages seen ? > > > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > Sure, here is what I see: qemu-system-i386: -device usb-host,vendorid=0x093a,productid=0x2510: 'usb-host' is not a valid device model name
Re: usb-host device not working
> On Jul 13, 2021, at 10:49 AM, Programmingkid > wrote: > > I have been having problems with using host USB devices lately. I use to be > able to use host USB devices but can't currently. After doing some git > bisecting I found it was this patch that causes this issue: > > commit 627302afb2f85cdd4b59595361876487aef19b7a (refs/bisect/bad) > Author: Gerd Hoffmann > Date: Thu Jun 24 12:38:35 2021 +0200 > >usb: build usb-host as module > >Drop one more shared library dependency (libusb) from core qemu. > >Signed-off-by: Gerd Hoffmann >Reviewed-by: Jose R. Ziviani >Message-Id: <20210624103836.2382472-34-kra...@redhat.com> >Signed-off-by: Paolo Bonzini > > I build QEMU like this: > > ./configure --target-list=i386-softmmu --enable-libusb && make -j 9 > > This command use to work but fails now with the above commit: > > qemu-system-i386 -usb -device usb-host,vendorid=0x093a,productid=0x2510 > > I think this is a bug with the commit. Any suggestions? > > Thank you. Forgot to mention this issue is observed on Mac OS 11.1.
usb-host device not working
I have been having problems with using host USB devices lately. I use to be able to use host USB devices but can't currently. After doing some git bisecting I found it was this patch that causes this issue: commit 627302afb2f85cdd4b59595361876487aef19b7a (refs/bisect/bad) Author: Gerd Hoffmann Date: Thu Jun 24 12:38:35 2021 +0200 usb: build usb-host as module Drop one more shared library dependency (libusb) from core qemu. Signed-off-by: Gerd Hoffmann Reviewed-by: Jose R. Ziviani Message-Id: <20210624103836.2382472-34-kra...@redhat.com> Signed-off-by: Paolo Bonzini I build QEMU like this: ./configure --target-list=i386-softmmu --enable-libusb && make -j 9 This command use to work but fails now with the above commit: qemu-system-i386 -usb -device usb-host,vendorid=0x093a,productid=0x2510 I think this is a bug with the commit. Any suggestions? Thank you.
Re: [PATCH 3/4] ui/icons: Use bundle mechanism
> On Jul 8, 2021, at 8:31 PM, Akihiko Odaki wrote:
>
> Hi,
>
> Reverting commit e31746ecf8dd2f25f687c94ac14016a3ba5debfc solves the
> problem only for cocoa and introduces another problem. (For others:
> see
> https://lore.kernel.org/qemu-devel/797ada26-0366-447f-85f0-5e27dc534...@gmail.com/
> for the context.)
What is the other problem that reverting the commit causes?
> The fix for cocoa basically comes for free if you
> fix the problem for other displays, and that's what this patch does.
That may be true but it also introduces the problem of having to keep track of
a picture file. With the original code there is no external picture file needed.
>
> On Fri, Jul 9, 2021 at 3:52 AM Programmingkid
> wrote:
>>
>>
>>> On Jul 8, 2021, at 1:25 PM, Akihiko Odaki wrote:
>>>
>>> Signed-off-by: Akihiko Odaki
>>> ---
>>> configure | 10 ++
>>> meson.build | 3 +--
>>> ui/cocoa.m | 20 +++-
>>> ui/gtk.c| 8 +---
>>> ui/sdl2.c | 18 +++---
>>> 5 files changed, 38 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index cff5a8ac280..a9f746849ec 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5058,6 +5058,16 @@ for f in $UNLINK ; do
>>>fi
>>> done
>>>
>>> +for icon_extension in bmp png ; do
>>> + for icon_file in $source_path/ui/icons/qemu_*.$icon_extension ; do
>>> +icon_basename=${icon_file%.$icon_extension}
>>> +icon_name=${icon_basename#$source_path/ui/icons/qemu_}
>>> +icon_dir=qemu-bundle/share/icons/hicolor/$icon_name/apps
>>> +symlink $icon_file $icon_dir/qemu.$icon_extension
>>> + done
>>> +done
>>> +
>>> +symlink $source_path/ui/icons/qemu.svg
>>> qemu-bundle/share/icons/hicolor/scalable/apps/qemu.svg
>>> symlink ../../pc-bios qemu-bundle/share/qemu
>>>
>>> (for i in $cross_cc_vars; do
>>> diff --git a/meson.build b/meson.build
>>> index 44adc660e23..6d90fe92bf1 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -1200,8 +1200,7 @@ config_host_data.set_quoted('CONFIG_QEMU_CONFDIR',
>>> get_option('prefix') / qemu_c
>>> config_host_data.set_quoted('CONFIG_QEMU_BUNDLE_DATADIR', qemu_datadir)
>>> config_host_data.set_quoted('CONFIG_QEMU_DESKTOPDIR', get_option('prefix')
>>> / qemu_desktopdir)
>>> config_host_data.set_quoted('CONFIG_QEMU_FIRMWAREPATH',
>>> get_option('qemu_firmwarepath'))
>>> -config_host_data.set_quoted('CONFIG_QEMU_HELPERDIR', get_option('prefix')
>>> / get_option('libexecdir'))
>>> -config_host_data.set_quoted('CONFIG_QEMU_ICONDIR', get_option('prefix') /
>>> qemu_icondir)
>>> +config_host_data.set_quoted('CONFIG_QEMU_BUNDLE_ICONDIR', qemu_icondir)
>>> config_host_data.set_quoted('CONFIG_QEMU_LOCALEDIR', get_option('prefix') /
>>> get_option('localedir'))
>>> config_host_data.set_quoted('CONFIG_QEMU_LOCALSTATEDIR',
>>> get_option('prefix') / get_option('localstatedir'))
>>> config_host_data.set_quoted('CONFIG_QEMU_MODDIR', get_option('prefix') /
>>> qemu_moddir)
>>> diff --git a/ui/cocoa.m b/ui/cocoa.m
>>> index 9f72844b079..d459dfaf595 100644
>>> --- a/ui/cocoa.m
>>> +++ b/ui/cocoa.m
>>> @@ -1477,15 +1477,17 @@ - (void)make_about_window
>>>NSRect picture_rect = NSMakeRect(x, y, picture_width, picture_height);
>>>
>>>/* Make the picture of QEMU */
>>> -NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
>>> - picture_rect];
>>> -char *qemu_image_path_c = get_relocated_path(CONFIG_QEMU_ICONDIR
>>> "/hicolor/512x512/apps/qemu.png");
>>> -NSString *qemu_image_path = [NSString
>>> stringWithUTF8String:qemu_image_path_c];
>>> -g_free(qemu_image_path_c);
>>> -NSImage *qemu_image = [[NSImage alloc]
>>> initWithContentsOfFile:qemu_image_path];
>>> -[picture_view setImage: qemu_image];
>>> -[picture_view setImageScaling: NSImageScaleProportionallyUpOrDown];
>>> -[superView addSubview: picture_view];
>>> +char *qemu_image_path_c = find_bundle(CONFIG_QEMU_BUNDLE_ICONDIR
>>> "/hicolor/512x512/apps/qemu.png");
>>> +if (qemu_image_path_c) {
>>> +NSString *qemu_image_path = [NSString
>>> stringWithUTF8String:qemu_image_path_c];
>>> +g_free(qemu_im
Re: Picture missing in About dialog on cocoa ui
> On Jul 8, 2021, at 8:15 PM, Akihiko Odaki wrote: > > I tried [NSApp applicationIconImage] but had no luck. I suspect it is > because Rez is for Carbon development and deprecated while NSApp is > from AppKit. Loading from the filesystem is inevitable. Totally disagree. I'm on a new MacBook Air and the rez command is available. I will agree that Apple likes removing features but the rez command is not one of them. I did not try [NSApp applicationIconImage], but I did try using [[NSWorkspace sharedWorkspace] iconForFile: program_path] and it worked. > By the way, I knew Rez is from Carbon but didn't know it is > deprecated, which I have figured out just now by reading man. Reading > the icon file and assigning it to [NSApp applicationIconImage] is a > possible solution, but it requires modifications for all graphical > backends (cocoa, gtk, and sdl) and of course an external icon file. Do > you think removing the dependency on Rez is worth it? I do not think we should remove any code that depends on rez. I honestly think the easiest and best thing to do is to go back to using my original patch for displaying a picture in the About dialog. > See "[PATCH 1/4] cutils: Introduce bundle mechanism" for a general fix > of the problem when loading a "bundled" file. > > Regards, > Akihiko Odaki > > > On Fri, Jul 9, 2021 at 2:51 AM Peter Maydell wrote: >> >> On Thu, 8 Jul 2021 at 17:28, Programmingkid >> wrote: >>> The problem with e31746ecf8dd2f25f687c94ac14016a3ba5debfc is it requires a >>> picture file to be found in a certain path. My original code used QEMU's >>> icon to obtain a picture. The reason why the picture in the About dialog >>> stopped appearing was because of the move to the meson build system. >>> A new patch has just been committed that fixes the missing icon issue. >>> Using 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' fixes the >>> missing picture issue in the About dialog. >> >> If the icon is the same (same resolution, etc) then just using it >> does seem better than loading it off the filesystem. But we should >> also sort out why get_relocated_path() isn't working, because if QEMU. >> can't load files that way then other things will also be broken I think. >> >> -- PMM
Re: [PATCH 3/4] ui/icons: Use bundle mechanism
> On Jul 8, 2021, at 1:25 PM, Akihiko Odaki wrote:
>
> Signed-off-by: Akihiko Odaki
> ---
> configure | 10 ++
> meson.build | 3 +--
> ui/cocoa.m | 20 +++-
> ui/gtk.c| 8 +---
> ui/sdl2.c | 18 +++---
> 5 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/configure b/configure
> index cff5a8ac280..a9f746849ec 100755
> --- a/configure
> +++ b/configure
> @@ -5058,6 +5058,16 @@ for f in $UNLINK ; do
> fi
> done
>
> +for icon_extension in bmp png ; do
> + for icon_file in $source_path/ui/icons/qemu_*.$icon_extension ; do
> +icon_basename=${icon_file%.$icon_extension}
> +icon_name=${icon_basename#$source_path/ui/icons/qemu_}
> +icon_dir=qemu-bundle/share/icons/hicolor/$icon_name/apps
> +symlink $icon_file $icon_dir/qemu.$icon_extension
> + done
> +done
> +
> +symlink $source_path/ui/icons/qemu.svg
> qemu-bundle/share/icons/hicolor/scalable/apps/qemu.svg
> symlink ../../pc-bios qemu-bundle/share/qemu
>
> (for i in $cross_cc_vars; do
> diff --git a/meson.build b/meson.build
> index 44adc660e23..6d90fe92bf1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1200,8 +1200,7 @@ config_host_data.set_quoted('CONFIG_QEMU_CONFDIR',
> get_option('prefix') / qemu_c
> config_host_data.set_quoted('CONFIG_QEMU_BUNDLE_DATADIR', qemu_datadir)
> config_host_data.set_quoted('CONFIG_QEMU_DESKTOPDIR', get_option('prefix') /
> qemu_desktopdir)
> config_host_data.set_quoted('CONFIG_QEMU_FIRMWAREPATH',
> get_option('qemu_firmwarepath'))
> -config_host_data.set_quoted('CONFIG_QEMU_HELPERDIR', get_option('prefix') /
> get_option('libexecdir'))
> -config_host_data.set_quoted('CONFIG_QEMU_ICONDIR', get_option('prefix') /
> qemu_icondir)
> +config_host_data.set_quoted('CONFIG_QEMU_BUNDLE_ICONDIR', qemu_icondir)
> config_host_data.set_quoted('CONFIG_QEMU_LOCALEDIR', get_option('prefix') /
> get_option('localedir'))
> config_host_data.set_quoted('CONFIG_QEMU_LOCALSTATEDIR', get_option('prefix')
> / get_option('localstatedir'))
> config_host_data.set_quoted('CONFIG_QEMU_MODDIR', get_option('prefix') /
> qemu_moddir)
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 9f72844b079..d459dfaf595 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -1477,15 +1477,17 @@ - (void)make_about_window
> NSRect picture_rect = NSMakeRect(x, y, picture_width, picture_height);
>
> /* Make the picture of QEMU */
> -NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
> - picture_rect];
> -char *qemu_image_path_c = get_relocated_path(CONFIG_QEMU_ICONDIR
> "/hicolor/512x512/apps/qemu.png");
> -NSString *qemu_image_path = [NSString
> stringWithUTF8String:qemu_image_path_c];
> -g_free(qemu_image_path_c);
> -NSImage *qemu_image = [[NSImage alloc]
> initWithContentsOfFile:qemu_image_path];
> -[picture_view setImage: qemu_image];
> -[picture_view setImageScaling: NSImageScaleProportionallyUpOrDown];
> -[superView addSubview: picture_view];
> +char *qemu_image_path_c = find_bundle(CONFIG_QEMU_BUNDLE_ICONDIR
> "/hicolor/512x512/apps/qemu.png");
> +if (qemu_image_path_c) {
> +NSString *qemu_image_path = [NSString
> stringWithUTF8String:qemu_image_path_c];
> +g_free(qemu_image_path_c);
> +NSImageView *picture_view = [[NSImageView alloc] initWithFrame:
> + picture_rect];
> +NSImage *qemu_image = [[NSImage alloc]
> initWithContentsOfFile:qemu_image_path];
> +[picture_view setImage: qemu_image];
> +[picture_view setImageScaling: NSImageScaleProportionallyUpOrDown];
> +[superView addSubview: picture_view];
> +}
>
> /* Make the name label */
> NSBundle *bundle = [NSBundle mainBundle];
> diff --git a/ui/gtk.c b/ui/gtk.c
> index 98046f577b9..e250f9e18a0 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -2198,9 +2198,11 @@ static void gtk_display_init(DisplayState *ds,
> DisplayOptions *opts)
> s->opts = opts;
>
> theme = gtk_icon_theme_get_default();
> -dir = get_relocated_path(CONFIG_QEMU_ICONDIR);
> -gtk_icon_theme_prepend_search_path(theme, dir);
> -g_free(dir);
> +dir = find_bundle(CONFIG_QEMU_BUNDLE_ICONDIR);
> +if (dir) {
> +gtk_icon_theme_prepend_search_path(theme, dir);
> +g_free(dir);
> +}
> g_set_prgname("qemu");
>
> s->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> diff --git a/ui/sdl2.c b/ui/sdl2.c
> index a203cb0239e..7b7ed9f9065 100644
> --- a/ui/sdl2.c
> +++ b/ui/sdl2.c
> @@ -877,15 +877,19 @@ static void sdl2_display_init(DisplayState *ds,
> DisplayOptions *o)
> }
>
> #ifdef CONFIG_SDL_IMAGE
> -dir = get_relocated_path(CONFIG_QEMU_ICONDIR
> "/hicolor/128x128/apps/qemu.png");
> -icon = IMG_Load(dir);
> +dir = find_bundle(CONFIG_QEMU_BUNDLE_ICONDIR
> "/hicolor/128x128/apps/qemu.png");
> +if (dir) {
> +icon = IMG_Load(dir);
> +}
> #else
>
Re: Picture missing in About dialog on cocoa ui
> On Jul 8, 2021, at 1:50 PM, Peter Maydell wrote: > > On Thu, 8 Jul 2021 at 17:28, Programmingkid wrote: >> The problem with e31746ecf8dd2f25f687c94ac14016a3ba5debfc is it requires a >> picture file to be found in a certain path. My original code used QEMU's >> icon to obtain a picture. The reason why the picture in the About dialog >> stopped appearing was because of the move to the meson build system. >> A new patch has just been committed that fixes the missing icon issue. >> Using 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' fixes the >> missing picture issue in the About dialog. > > If the icon is the same (same resolution, etc) then just using it > does seem better than loading it off the filesystem. The picture did look nice in the About dialog.
Re: Picture missing in About dialog on cocoa ui
> On Jul 8, 2021, at 1:37 AM, Akihiko Odaki wrote: > > Hi, > > My installation correctly shows the picture. Please make sure you > install it and run the installed binary (not the binary located in the > build directory). The new code should work reliably once you install > it while the old code may or may not work depending on how you execute > the binary. > > Regards, > Akihiko Odaki The problem with e31746ecf8dd2f25f687c94ac14016a3ba5debfc is it requires a picture file to be found in a certain path. My original code used QEMU's icon to obtain a picture. The reason why the picture in the About dialog stopped appearing was because of the move to the meson build system. A new patch has just been committed that fixes the missing icon issue. Using 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' fixes the missing picture issue in the About dialog. Thank you. > > On Thu, Jul 8, 2021 at 2:00 AM Programmingkid > wrote: >> >> Hello, now that the code to add the icon to QEMU has been restored for Mac >> OS, I think it is time to revert patch >> e31746ecf8dd2f25f687c94ac14016a3ba5debfc. This patch was made to fix the >> missing icon in the About dialog but it doesn't seem to work any more. I do >> not see a picture in the About dialog on Mac OS 11.1. The easiest fix for >> this issue is to revert the mentioned patch. When I ran >> 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' the picture in the >> About dialog appeared again.
Re: Picture missing in About dialog on cocoa ui
> On Jul 8, 2021, at 4:58 AM, Peter Maydell wrote: > > On Thu, 8 Jul 2021 at 06:38, Akihiko Odaki wrote: >> >> Hi, >> >> My installation correctly shows the picture. Please make sure you >> install it and run the installed binary (not the binary located in the >> build directory). The new code should work reliably once you install >> it while the old code may or may not work depending on how you execute >> the binary. > > The correct behaviour would be for it to find the icon both > as an installed binary and when run from the build directory. > (This is true for various kinds of loaded file including guest > bios images.) > > thanks > -- PMM Agreed. My original code did this. I do think reverting e31746ecf8dd2f25f687c94ac14016a3ba5debfc is the best way to fix this issue. Thank you.
Picture missing in About dialog on cocoa ui
Hello, now that the code to add the icon to QEMU has been restored for Mac OS, I think it is time to revert patch e31746ecf8dd2f25f687c94ac14016a3ba5debfc. This patch was made to fix the missing icon in the About dialog but it doesn't seem to work any more. I do not see a picture in the About dialog on Mac OS 11.1. The easiest fix for this issue is to revert the mentioned patch. When I ran 'git revert e31746ecf8dd2f25f687c94ac14016a3ba5debfc' the picture in the About dialog appeared again.
Re: [PATCH v2] Set icon for QEMU binary on Mac OS
> On Jul 5, 2021, at 4:07 PM, Paolo Bonzini wrote:
>
> Well, you're not using $ICON at all but I can clean that up myself. Thanks
> for testing.
>
> Paolo
>
Please send me the cleaned up patch for testing once you complete it. Thank you.
> Il lun 5 lug 2021, 21:53 John Arbuckle ha scritto:
> Signed-off-by: John Arbuckle
> ---
> v1 changes:
> Rewrote the patch as the maintainer had wanted.
>
> meson.build| 15 ++-
> scripts/entitlement.sh | 10 +-
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index db6789af9c..499ab49981 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -2360,8 +2360,7 @@ foreach target : target_dirs
>endif
>foreach exe: execs
> exe_name = exe['name']
> -exe_sign = 'CONFIG_HVF' in config_target
> -if exe_sign
> +if targetos == 'darwin'
>exe_name += '-unsigned'
> endif
>
> @@ -2375,7 +2374,13 @@ foreach target : target_dirs
> link_args: link_args,
> gui_app: exe['gui'])
>
> -if exe_sign
> +if 'CONFIG_HVF' in config_target
> + entitlements = meson.current_source_dir() /
> 'accel/hvf/entitlements.plist'
> +else
> + entitlements = '/dev/null'
> +endif
> +if targetos == 'darwin'
> + icon = '...'
>emulators += {exe['name'] : custom_target(exe['name'],
> depends: emulator,
> output: exe['name'],
> @@ -2383,14 +2388,14 @@ foreach target : target_dirs
> meson.current_source_dir() / 'scripts/entitlement.sh',
> meson.current_build_dir() / exe_name,
> meson.current_build_dir() / exe['name'],
> - meson.current_source_dir() /
> 'accel/hvf/entitlements.plist'
> + entitlements, icon
> ])
>}
>
>meson.add_install_script('scripts/entitlement.sh', '--install',
> get_option('bindir') / exe_name,
> get_option('bindir') / exe['name'],
> - meson.current_source_dir() /
> 'accel/hvf/entitlements.plist')
> + entitlements, icon)
> else
>emulators += {exe['name']: emulator}
> endif
> diff --git a/scripts/entitlement.sh b/scripts/entitlement.sh
> index f7aaaf2766..46e378426b 100755
> --- a/scripts/entitlement.sh
> +++ b/scripts/entitlement.sh
> @@ -11,6 +11,7 @@ fi
> SRC="$1"
> DST="$2"
> ENTITLEMENT="$3"
> +ICON="$4"
>
> if $in_place; then
>trap 'rm "$DST.tmp"' exit
> @@ -20,6 +21,13 @@ else
>cd "$MESON_INSTALL_DESTDIR_PREFIX"
> fi
>
> -codesign --entitlements "$ENTITLEMENT" --force -s - "$SRC"
> +if test "$ENTITLEMENT" != '/dev/null'; then
> + codesign --entitlements "$ENTITLEMENT" --force -s - "$SRC"
> +fi
> +
> +# Add the QEMU icon to the binary on Mac OS
> +Rez -append '../pc-bios/qemu.rsrc' -o "$SRC"
> +SetFile -a C "$SRC"
> +
> mv -f "$SRC" "$DST"
> trap '' exit
> --
> 2.24.3 (Apple Git-128)
>
[PATCH] Set icon for QEMU binary on Mac OS
Hi Paolo, I was told you were the one who I should send this patch to. Please
let me know if you feel otherwise.
Before switching the build system over to Meson, an icon was
added to the QEMU binary on Mac OS. This patch adds back that
feature.
Signed-off-by: John Arbuckle
---
meson.build | 20
1 file changed, 20 insertions(+)
diff --git a/meson.build b/meson.build
index f00b7754fd..7f534f4e75 100644
--- a/meson.build
+++ b/meson.build
@@ -2183,6 +2183,26 @@ foreach target : target_dirs
link_args: link_args,
gui_app: exe['gui'])
+# set QEMU's icon on Mac OS
+if targetos == 'darwin'
+newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
+ depends : emulator,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 1',
+ command : ['Rez', '-append',
+ meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+
+custom_target('Icon for ' + exe_name + ' - part 2',
+ depends : newiconpart1,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 2',
+ command : ['SetFile', '-a', 'C',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+endif
+
if exe_sign
emulators += {exe['name'] : custom_target(exe['name'],
install: true,
--
2.24.3 (Apple Git-128)
Help with patch
Hi, I made a patch that adds an icon to QEMU on Mac OS. Who should I send this
patch to?
From 45650a7f52deb8c2c436d71a3fcf5326287c2e05 Mon Sep 17 00:00:00 2001
From: John Arbuckle
Date: Tue, 2 Feb 2021 08:35:43 -0500
Subject: [PATCH] Set icon for QEMU binary on Mac OS
Before switching the build system over to Meson, an icon was
added to the QEMU binary on Mac OS. This patch adds back that
feature.
Signed-off-by: John Arbuckle
---
meson.build | 20
1 file changed, 20 insertions(+)
diff --git a/meson.build b/meson.build
index f00b7754fd..7f534f4e75 100644
--- a/meson.build
+++ b/meson.build
@@ -2183,6 +2183,26 @@ foreach target : target_dirs
link_args: link_args,
gui_app: exe['gui'])
+# set QEMU's icon on Mac OS
+if targetos == 'darwin'
+newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
+ depends : emulator,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 1',
+ command : ['Rez', '-append',
+ meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+
+custom_target('Icon for ' + exe_name + ' - part 2',
+ depends : newiconpart1,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 2',
+ command : ['SetFile', '-a', 'C',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+endif
+
if exe_sign
emulators += {exe['name'] : custom_target(exe['name'],
install: true,
--
2.24.3 (Apple Git-128)
Re: tb_flush() calls causing long Windows XP boot times
> On Jun 15, 2021, at 9:58 PM, Richard Henderson > wrote: > > On 6/15/21 6:58 AM, Programmingkid wrote: >>> Ahh I misread - so those are the addresses of the routines and not where >>> it's sticking the breakpoint? >>> >>> I notice from a bit of googling that there is a boot debugger. I wonder >>> if /nodebug in boot.ini stops this behaviour? >>> >>> >>> https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files >>> >>> -- >>> Alex Bennée >> Hi Alex, >> I tried your suggestion of using /nodebug. It did not stop the tb_flush() >> function from being called. > > We are not expecting zero calls to tb_flush (it is used for other things, > including buffer full), but we are hoping that it reduces the frequency of > the calls. Agreed. > I'm guessing you didn't immediately see the slowdown vanish, and so there was > no change to the frequency of the calls. Correct. > FWIW, if you switch to the qemu console, you can see how many flushes have > occurred with "info jit". Thank you very much for this information. I'm currently learning about the x86's debug registers D0 to D7. There are a lot of rules associated with them. So my guess is one or more rules may not be implemented in QEMU. I will try to test them out in FreeDOS and compare notes with a real x86 CPU. A possible workaround might be to implement a command line option that allows the user to specify how often the tb_flush() call is made. When I eliminated the call I could not find any problems with my VM's. I understand if this is not possible.
Re: tb_flush() calls causing long Windows XP boot times
> On Jun 14, 2021, at 10:37 AM, Alex Bennée wrote: > > Mark Cave-Ayland writes: > >> On 11/06/2021 19:22, Alex Bennée wrote: >> >> (added Gitlab on CC) >> >>> Paolo Bonzini writes: >>> >>>> On 11/06/21 17:01, Programmingkid wrote: >>>>> Hello Alex, >>>>> The good news is the source code to Windows XP is available >>>>> online:https://github.com/cryptoAlgorithm/nt5src >>>> >>>> It's leaked, so I doubt anybody who's paid to work on Linux or QEMU >>>> would touch that with a ten-foot pole. >>> Indeed. >>> Anyway what the OP could do is run QEMU with gdb and -d nochain and >>> stick a breakpoint (sic) in breakpoint_invalidate. Then each time it >>> hits you can examine the backtrace to cpu_loop_exec_tb and collect the >>> data from tb->pc. Then you will have a bunch of addresses in Windows >>> that keep triggering the behaviour. You can then re-run with -dfilter >>> and -d in_asm,cpu to get some sort of idea of what Windows is up to. >> >> I have been able to recreate this locally using my WinXP and it looks >> like during boot WinXP goes into a tight loop where it writes and >> clears a set of breakpoints via writes to DB7 which is what causes the >> very slow boot time. >> >> Once boot proceeds further into the login screen, the same code seems >> to called periodically once every second or so which has less of a >> performance impact. >> >> >> This gives a repeated set of outputs like this: >> >> # bpi @ 0x90 >> ### dp7 add bp inst @ 0x8053cab8, index 1 >> # bpi @ 0xa4 >> ### dp7 add bp inst @ 0x8053cab8, index 2 >> # bpi @ 0xff >> ### dp7 add bp inst @ 0x8053cab8, index 3 >> # bpi @ 0xf > > That's weird - maybe this is a misunderstanding of the x86 debug > registers but it looks like it's setting each one to all the same value. > >> ### dp7 remove bp inst @ 0x8053f58a, index 0 >> # bpi @ 0x90 >> ### dp7 remove bp inst @ 0x8053f58a, index 1 >> # bpi @ 0xa4 >> ### dp7 remove bp inst @ 0x8053f58a, index 2 >> # bpi @ 0xff >> ### dp7 remove bp inst @ 0x8053f58a, index 3 >> ... >> ... >> ### dp7 add bp inst @ 0x8053c960, index 0 >> # bpi @ 0x90 >> ### dp7 add bp inst @ 0x8053c960, index 1 >> # bpi @ 0xa4 >> ### dp7 add bp inst @ 0x8053c960, index 2 >> # bpi @ 0xff >> ### dp7 add bp inst @ 0x8053c960, index 3 >> # bpi @ 0xf >> ### dp7 remove bp inst @ 0x8053c730, index 0 >> # bpi @ 0x90 >> ### dp7 remove bp inst @ 0x8053c730, index 1 >> # bpi @ 0xa4 >> ### dp7 remove bp inst @ 0x8053c730, index 2 >> # bpi @ 0xff >> ### dp7 remove bp inst @ 0x8053c730, index 3 >> ... >> ... > > I wonder if this is Windows check pointing itself by observing when it > gets to a particular place in the boot sequence. I guess we don't have > any symbols for the addresses it's setting? > >> >> From a vanilla XP install the 2 main sections of code which alter the >> breakpoint registers are at 0x8053cab8 (enable) and 0x8053f58a >> (disable): > > Ahh I misread - so those are the addresses of the routines and not where > it's sticking the breakpoint? > > I notice from a bit of googling that there is a boot debugger. I wonder > if /nodebug in boot.ini stops this behaviour? > > > https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files > > -- > Alex Bennée Hi Alex, I tried your suggestion of using /nodebug. It did not stop the tb_flush() function from being called.
Re: tb_flush() calls causing long Windows XP boot times
> On Jun 11, 2021, at 7:24 AM, Alex Bennée wrote: > > > Mark Cave-Ayland writes: > >> On 10/06/2021 14:14, Peter Maydell wrote: >> >>> On Thu, 10 Jun 2021 at 14:02, Programmingkid >>> wrote: >>>> >>>> Hi Richard, >>>> >>>> There is a function called breakpoint_invalidate() in cpu.c that >>>> calls a function called tb_flush(). I have determined that this >>>> call is being made over 200,000 times when Windows XP boots. >>>> Disabling this function makes Windows XP boot way faster than >>>> before. The time went down from around 3 minutes to 20 seconds when >>>> I applied the patch below. >>>> >>>> After I applied the patch I ran several tests in my VM's to see if >>>> anything broke. I could not find any problems. Here is the list my VM's I >>>> tested: >>>> >>>> Mac OS 10.8 in qemu-system-x86_64 >>>> Windows 7 in qemu-system-x86_64 >>>> Windows XP in qemu-system-i386 >>>> Mac OS 10.4 in qemu-system-ppc >>>> >>>> I would be happy if the patch below was accepted but I would like to know >>>> your thoughts. >>> >>>> cpu.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/cpu.c b/cpu.c >>>> index bfbe5a66f9..297c2e4281 100644 >>>> --- a/cpu.c >>>> +++ b/cpu.c >>>> @@ -253,7 +253,7 @@ static void breakpoint_invalidate(CPUState *cpu, >>>> target_ulong pc) >>>> * Flush the whole TB cache to force re-translation of such TBs. >>>> * This is heavyweight, but we're debugging anyway. >>>> */ >>>> -tb_flush(cpu); >>>> +/* tb_flush(cpu); */ >>>> } >>>> #endif >>> The patch is clearly wrong -- this function is called when a CPU >>> breakpoint >>> is added or removed, and we *must* drop generated code which either >>> (a) includes code to take the breakpoint exception and now should not >>> or (b) doesn't include code to take the breakpoint exception and now should. >>> Otherwise we will incorrectly take/not take a breakpoint exception when >>> that stale code is executed. >>> As the comment notes, the assumption is that we won't be adding and >>> removing breakpoints except when we're debugging and therefore >>> performance is not critical. Windows XP is clearly doing something >>> we weren't expecting, so we should ideally have a look at whether >>> we can be a bit more efficient about not throwing the whole TB >>> cache away. >> >> FWIW this was reported a while back on Launchpad as >> https://bugs.launchpad.net/qemu/+bug/1883593 where the performance >> regression was traced back to: >> >> commit b55f54bc965607c45b5010a107a792ba333ba654 >> Author: Max Filippov >> Date: Wed Nov 27 14:06:01 2019 -0800 >> >>exec: flush CPU TB cache in breakpoint_invalidate >> >>When a breakpoint is inserted at location for which there's currently no >>virtual to physical translation no action is taken on CPU TB cache. If a >>TB for that virtual address already exists but is not visible ATM the >>breakpoint won't be hit next time an instruction at that address will be >>executed. >> >>Flush entire CPU TB cache in breakpoint_invalidate to force >>re-translation of all TBs for the breakpoint address. >> >>This change fixes the following scenario: >>- linux user application is running >>- a breakpoint is inserted from QEMU gdbstub for a user address that is >> not currently present in the target CPU TLB >>- an instruction at that address is executed, but the external debugger >> doesn't get control. >> >>Reviewed-by: Richard Henderson >>Signed-off-by: Max Filippov >>Message-Id: <20191127220602.10827-2-jcmvb...@gmail.com> >>Signed-off-by: Richard Henderson > > This was a reversion of a reversion (see 406bc339b0 and a9353fe89). So > we've bounced between solutions several times. Fundamentally if it gets > tricky to ensure your translated state matches the actual machine state > the easiest option is to throw everything away and start again. > >> Perhaps Windows XP is constantly executing some kind of breakpoint >> instruction or updating some CPU debug registers during boot? > > It would be useful to identify what exactly is triggering the changes > here. If it's old fashioned breakpoint instructions being inserted into > memory we will need to ensure our invalidating of old translations is > rock solid. If we are updating our internal breakpoint/watchpoint > tracking as a result of the guest messing with debug registers maybe we > can do something a bit more finessed? > >> >> >> ATB, >> >> Mark. > > > -- > Alex Bennée Hello Alex, The good news is the source code to Windows XP is available online: https://github.com/cryptoAlgorithm/nt5src
Re: tb_flush() calls causing long Windows XP boot times
> On Jun 10, 2021, at 9:14 AM, Peter Maydell wrote: > > On Thu, 10 Jun 2021 at 14:02, Programmingkid > wrote: >> >> Hi Richard, >> >> There is a function called breakpoint_invalidate() in cpu.c that calls a >> function called tb_flush(). I have determined that this call is being made >> over 200,000 times when Windows XP boots. Disabling this function makes >> Windows XP boot way faster than before. The time went down from around 3 >> minutes to 20 seconds when I applied the patch below. >> >> After I applied the patch I ran several tests in my VM's to see if anything >> broke. I could not find any problems. Here is the list my VM's I tested: >> >> Mac OS 10.8 in qemu-system-x86_64 >> Windows 7 in qemu-system-x86_64 >> Windows XP in qemu-system-i386 >> Mac OS 10.4 in qemu-system-ppc >> >> I would be happy if the patch below was accepted but I would like to know >> your thoughts. > >> cpu.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/cpu.c b/cpu.c >> index bfbe5a66f9..297c2e4281 100644 >> --- a/cpu.c >> +++ b/cpu.c >> @@ -253,7 +253,7 @@ static void breakpoint_invalidate(CPUState *cpu, >> target_ulong pc) >> * Flush the whole TB cache to force re-translation of such TBs. >> * This is heavyweight, but we're debugging anyway. >> */ >> -tb_flush(cpu); >> +/* tb_flush(cpu); */ >> } >> #endif > > The patch is clearly wrong -- this function is called when a CPU breakpoint > is added or removed, and we *must* drop generated code which either > (a) includes code to take the breakpoint exception and now should not > or (b) doesn't include code to take the breakpoint exception and now should. > Otherwise we will incorrectly take/not take a breakpoint exception when > that stale code is executed. > > As the comment notes, the assumption is that we won't be adding and > removing breakpoints except when we're debugging and therefore > performance is not critical. Windows XP is clearly doing something > we weren't expecting, so we should ideally have a look at whether > we can be a bit more efficient about not throwing the whole TB > cache away. > > thanks > -- PMM Thank you for the information. I think there may be additional conditions that may need to be considered before calling tb_flush().
tb_flush() calls causing long Windows XP boot times
Hi Richard, There is a function called breakpoint_invalidate() in cpu.c that calls a function called tb_flush(). I have determined that this call is being made over 200,000 times when Windows XP boots. Disabling this function makes Windows XP boot way faster than before. The time went down from around 3 minutes to 20 seconds when I applied the patch below. After I applied the patch I ran several tests in my VM's to see if anything broke. I could not find any problems. Here is the list my VM's I tested: Mac OS 10.8 in qemu-system-x86_64 Windows 7 in qemu-system-x86_64 Windows XP in qemu-system-i386 Mac OS 10.4 in qemu-system-ppc I would be happy if the patch below was accepted but I would like to know your thoughts. Thank you. --- cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpu.c b/cpu.c index bfbe5a66f9..297c2e4281 100644 --- a/cpu.c +++ b/cpu.c @@ -253,7 +253,7 @@ static void breakpoint_invalidate(CPUState *cpu, target_ulong pc) * Flush the whole TB cache to force re-translation of such TBs. * This is heavyweight, but we're debugging anyway. */ -tb_flush(cpu); +/* tb_flush(cpu); */ } #endif -- 2.24.3 (Apple Git-128)
Windows 7 crashing due to patch: target/i386: extract mmu_translate
Hi Paolo, Windows 7 is crashing a lot in QEMU due to this error: PAGE_FAULT_IN_NONPAGED_AREA. After bisecting I traced the issue to this patch: 661ff4879eee77953836ba9843c74b202844a492 Author: Paolo Bonzini Date: Thu Mar 18 10:16:35 2021 -0400 target/i386: extract mmu_translate Extract the page table lookup out of handle_mmu_fault, which only has to invoke mmu_translate and either fill the TLB or deliver the page fault. Signed-off-by: Paolo Bonzini target/i386/tcg/sysemu/excp_helper.c | 151 --- 1 file changed, 86 insertions(+), 65 deletions(-) Here is the bug report link: https://gitlab.com/qemu-project/qemu/-/issues/394 Thank you.
ping: [PATCH] Set icon for QEMU binary on Mac OS
Ping,
please implement this patch. The default icon on Mac OS 11 is not very good
looking.
https://lore.kernel.org/qemu-devel/20210202134410.9274-1-programmingk...@gmail.com/
Before switching the build system over to Meson, an icon was
added to the QEMU binary on Mac OS. This patch adds back that
feature.
Signed-off-by: John Arbuckle
---
meson.build
| 20
1 file changed, 20 insertions(+)
diff
--git a/meson.build b/meson.build
index f00b7754fd..7f534f4e75 100644
--- a/meson.build
+++ b/meson.build
@@ -2183,6 +2183,26 @@ foreach target : target_dirs
link_args: link_args,
gui_app: exe['gui'])
+# set QEMU's icon on Mac OS
+if targetos == 'darwin'
+newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
+ depends : emulator,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 1',
+ command : ['Rez', '-append',
+ meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+
+custom_target('Icon for ' + exe_name + ' - part 2',
+ depends : newiconpart1,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 2',
+ command : ['SetFile', '-a', 'C',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+endif
+
if exe_sign
emulators += {exe['name'] : custom_target(exe['name'],
install: true,
--
2.24.3 (Apple Git-128)
Re: Windows 7 fails to boot with patch 7eff2e7c
If you have any patches you would like me to test out please send them to me. Thank you. > On May 27, 2021, at 11:13 AM, Programmingkid > wrote: > > I have noticed that Windows 7 has stopped being able to boot recently. After > doing some bisecting I found out it was this patch that is causing this issue: > > 7eff2e7c652304157f503f2d406193bb9de10d58 is the first bad commit > commit 7eff2e7c652304157f503f2d406193bb9de10d58 > Author: Richard Henderson > Date: Fri May 14 10:13:31 2021 -0500 > >target/i386: Cleanup read_crN, write_crN, lmsw > >Pull the svm intercept check into the translator. >Pull the entire implementation of lmsw into the translator. >Push the check for CR8LEG into the regno validation switch. >Unify the gen_io_start check between read/write. >
Windows 7 fails to boot with patch 7eff2e7c
I have noticed that Windows 7 has stopped being able to boot recently. After doing some bisecting I found out it was this patch that is causing this issue: 7eff2e7c652304157f503f2d406193bb9de10d58 is the first bad commit commit 7eff2e7c652304157f503f2d406193bb9de10d58 Author: Richard Henderson Date: Fri May 14 10:13:31 2021 -0500 target/i386: Cleanup read_crN, write_crN, lmsw Pull the svm intercept check into the translator. Pull the entire implementation of lmsw into the translator. Push the check for CR8LEG into the regno validation switch. Unify the gen_io_start check between read/write.
Re: [PATCH 0/2] vvfat: fix two crashes.
> On May 25, 2021, at 12:18 PM, Kevin Wolf wrote:
>
> Am 24.05.2021 um 18:06 hat Programmingkid geschrieben:
>>>>> qemu-system-ppc -usb -device usb-storage,drive=fat16 -drive
>>>>> file=fat:rw:fat-type=16:">>>> folder>",id=fat16,format=raw,if=none
>>>>>
>> On a related topic would you know if it is possible to use fat32
>> instead of fat16 for host folder sharing? I did try replacing the text
>> fat16 with fat32 but it didn't appear to work.
>
> I think the correct syntax is fat:32:rw:. But one of the first
> things it does is:
>
>warn_report("FAT32 has not been tested. You are welcome to do so!");
>
> So probably nobody would be surprised if it broke.
>
> Kevin
>
Thank you very much for this information.
Re: [PATCH 0/2] vvfat: fix two crashes.
> On May 25, 2021, at 2:05 AM, Vladimir Sementsov-Ogievskiy > wrote: > > 24.05.2021 20:33, Programmingkid wrote: >>> On May 24, 2021, at 12:56 PM, Vladimir Sementsov-Ogievskiy >>> wrote: >>> >>> 24.05.2021 19:06, Programmingkid wrote: >>>>> On May 24, 2021, at 11:55 AM, Vladimir Sementsov-Ogievskiy >>>>> wrote: >>>>> >>>>> 24.05.2021 18:41, Programmingkid wrote: >>>>>>> On May 24, 2021, at 6:12 AM, Vladimir Sementsov-Ogievskiy >>>>>>> wrote: >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> As reported by Programmingkid, command >>>>>>> >>>>>>> qemu-system-ppc -usb -device usb-storage,drive=fat16 -drive >>>>>>> file=fat:rw:fat-type=16:">>>>>> folder>",id=fat16,format=raw,if=none >>>>>>> >>>>>>> crashes. >>>>>>> >>>>>>> I tested it with qemu-system-x86_64 and it reproduces for me. I even >>>>>>> kept "" as is :). >>>>>>> >>>>>>> So, here are two fixes. >>>>>>> >>>>>>> Vladimir Sementsov-Ogievskiy (2): >>>>>>> block/vvfat: child_vvfat_qcow: add .get_parent_aio_context, fix crash >>>>>>> block/vvfat: fix vvfat_child_perm crash >>>>>>> >>>>>>> include/block/block.h | 1 + >>>>>>> block.c | 4 ++-- >>>>>>> block/vvfat.c | 8 +++- >>>>>>> 3 files changed, 6 insertions(+), 7 deletions(-) >>>>>>> >>>>>>> -- >>>>>>> 2.29.2 >>>>>> I applied both of your patches to the most recent git commit today and >>>>>> they worked. I was able to share files from the host on the guest. >>>>>> Thank you. >>>>>> Reviewed-by: John Arbuckle >>>>> >>>>> Thanks for testing! Didn't you mean "Tested-by: "? Or if you both >>>>> reviewed and tested, having both marks makes sense. >>>> Yes, you are right. It should be: Tested-by: John Arbuckle >>>> >>>>> >>>>> Hmm, also, I think "Reported-by" in first patch should be fixed to your >>>>> real name too for consistency. >>>> That should be fine but it isn't important. >>>> On a related topic would you know if it is possible to use fat32 instead >>>> of fat16 for host folder sharing? I did try replacing the text fat16 with >>>> fat32 but it didn't appear to work. >>> >>> No, I don't know.. >>> >>> Moreover, my quick look at the code of vvfat, this fixed bug (which is >>> obviously not covered by tests), and also status of block/vvfat in >>> MAINTAINERS file "Odd Fixes", all this leads to advice "don't use it if >>> possible". May be Kevin can add something about it, he is maintainer.. >>> >>> Could you use for example NFS or Samba, or sshfs to share folders? Or you >>> need exactly to make a host folder available in guest vm as usb drive? >> I do actually need it for some of my VM's. It makes sharing of folder >> between the host and guest so easy. > > Probably virtio-fs is modern way for such thing: > > https://virtio-fs.gitlab.io/ Thank you for this.
Re: [PATCH 0/2] vvfat: fix two crashes.
> On May 24, 2021, at 12:56 PM, Vladimir Sementsov-Ogievskiy > wrote: > > 24.05.2021 19:06, Programmingkid wrote: >>> On May 24, 2021, at 11:55 AM, Vladimir Sementsov-Ogievskiy >>> wrote: >>> >>> 24.05.2021 18:41, Programmingkid wrote: >>>>> On May 24, 2021, at 6:12 AM, Vladimir Sementsov-Ogievskiy >>>>> wrote: >>>>> >>>>> Hi! >>>>> >>>>> As reported by Programmingkid, command >>>>> >>>>> qemu-system-ppc -usb -device usb-storage,drive=fat16 -drive >>>>> file=fat:rw:fat-type=16:">>>> folder>",id=fat16,format=raw,if=none >>>>> >>>>> crashes. >>>>> >>>>> I tested it with qemu-system-x86_64 and it reproduces for me. I even >>>>> kept "" as is :). >>>>> >>>>> So, here are two fixes. >>>>> >>>>> Vladimir Sementsov-Ogievskiy (2): >>>>> block/vvfat: child_vvfat_qcow: add .get_parent_aio_context, fix crash >>>>> block/vvfat: fix vvfat_child_perm crash >>>>> >>>>> include/block/block.h | 1 + >>>>> block.c | 4 ++-- >>>>> block/vvfat.c | 8 +++- >>>>> 3 files changed, 6 insertions(+), 7 deletions(-) >>>>> >>>>> -- >>>>> 2.29.2 >>>> I applied both of your patches to the most recent git commit today and >>>> they worked. I was able to share files from the host on the guest. >>>> Thank you. >>>> Reviewed-by: John Arbuckle >>> >>> Thanks for testing! Didn't you mean "Tested-by: "? Or if you both reviewed >>> and tested, having both marks makes sense. >> Yes, you are right. It should be: Tested-by: John Arbuckle >> >>> >>> Hmm, also, I think "Reported-by" in first patch should be fixed to your >>> real name too for consistency. >> That should be fine but it isn't important. >> On a related topic would you know if it is possible to use fat32 instead of >> fat16 for host folder sharing? I did try replacing the text fat16 with fat32 >> but it didn't appear to work. > > No, I don't know.. > > Moreover, my quick look at the code of vvfat, this fixed bug (which is > obviously not covered by tests), and also status of block/vvfat in > MAINTAINERS file "Odd Fixes", all this leads to advice "don't use it if > possible". May be Kevin can add something about it, he is maintainer.. > > Could you use for example NFS or Samba, or sshfs to share folders? Or you > need exactly to make a host folder available in guest vm as usb drive? I do actually need it for some of my VM's. It makes sharing of folder between the host and guest so easy.
Re: [PATCH 0/2] vvfat: fix two crashes.
> On May 24, 2021, at 11:55 AM, Vladimir Sementsov-Ogievskiy > wrote: > > 24.05.2021 18:41, Programmingkid wrote: >>> On May 24, 2021, at 6:12 AM, Vladimir Sementsov-Ogievskiy >>> wrote: >>> >>> Hi! >>> >>> As reported by Programmingkid, command >>> >>> qemu-system-ppc -usb -device usb-storage,drive=fat16 -drive >>> file=fat:rw:fat-type=16:">> folder>",id=fat16,format=raw,if=none >>> >>> crashes. >>> >>> I tested it with qemu-system-x86_64 and it reproduces for me. I even >>> kept "" as is :). >>> >>> So, here are two fixes. >>> >>> Vladimir Sementsov-Ogievskiy (2): >>> block/vvfat: child_vvfat_qcow: add .get_parent_aio_context, fix crash >>> block/vvfat: fix vvfat_child_perm crash >>> >>> include/block/block.h | 1 + >>> block.c | 4 ++-- >>> block/vvfat.c | 8 +++- >>> 3 files changed, 6 insertions(+), 7 deletions(-) >>> >>> -- >>> 2.29.2 >> I applied both of your patches to the most recent git commit today and they >> worked. I was able to share files from the host on the guest. >> Thank you. >> Reviewed-by: John Arbuckle > > Thanks for testing! Didn't you mean "Tested-by: "? Or if you both reviewed > and tested, having both marks makes sense. Yes, you are right. It should be: Tested-by: John Arbuckle > > Hmm, also, I think "Reported-by" in first patch should be fixed to your real > name too for consistency. That should be fine but it isn't important. On a related topic would you know if it is possible to use fat32 instead of fat16 for host folder sharing? I did try replacing the text fat16 with fat32 but it didn't appear to work.
Re: [PATCH 0/2] vvfat: fix two crashes.
> On May 24, 2021, at 6:12 AM, Vladimir Sementsov-Ogievskiy > wrote: > > Hi! > > As reported by Programmingkid, command > > qemu-system-ppc -usb -device usb-storage,drive=fat16 -drive > file=fat:rw:fat-type=16:"",id=fat16,format=raw,if=none > > crashes. > > I tested it with qemu-system-x86_64 and it reproduces for me. I even > kept "" as is :). > > So, here are two fixes. > > Vladimir Sementsov-Ogievskiy (2): > block/vvfat: child_vvfat_qcow: add .get_parent_aio_context, fix crash > block/vvfat: fix vvfat_child_perm crash > > include/block/block.h | 1 + > block.c | 4 ++-- > block/vvfat.c | 8 +++- > 3 files changed, 6 insertions(+), 7 deletions(-) > > -- > 2.29.2 I applied both of your patches to the most recent git commit today and they worked. I was able to share files from the host on the guest. Thank you. Reviewed-by: John Arbuckle
Re: Mac OS real USB device support issue
I just wanted to give you guys an update on this issue. The libusb people have fixed the issue with USB device driver detaching on Mac OS. Here is where the code for the fix is located: https://github.com/libusb/libusb/pull/911/commits. I was able to build the library and connect it to QEMU on Mac OS 11.1. As I write this email I am listening to mp3 files on my Mac OS 10.4 VM that is using a real USB sound card. It isn't perfect sounding but definitely a leap forward from where we were a month ago. To download each commit in patch form, just append ".patch" to the patch's URL. Apply the patches one by one using "patch -p1 < patch.txt". Then open the Xcode project file and build the libusb target. To locate the file I had to use this command in the terminal: cd ~/Library/Developer/Xcode/DerivedData Then find out the path of the old libusb being used in QEMU: otool -L | grep "libusb" Then to have QEMU use the new library file, use this command: install_name_tool -change Please let me know if you need any help with building your own version of libusb.
Ping: [PATCH] Set icon for QEMU binary on Mac OS
This patch was submitted in February and I haven't heard anything about it
since. Could this be included in the up coming release please?
https://lore.kernel.org/qemu-devel/20210202134410.9274-1-programmingk...@gmail.com/
Before switching the build system over to Meson, an icon was
added to the QEMU binary on Mac OS. This patch adds back that
feature.
Signed-off-by: John Arbuckle
---
meson.build
| 20
1 file changed, 20 insertions(+)
diff
--git a/meson.build b/meson.build
index f00b7754fd..7f534f4e75 100644
--- a/meson.build
+++ b/meson.build
@@ -2183,6 +2183,26 @@ foreach target : target_dirs
link_args: link_args,
gui_app: exe['gui'])
+# set QEMU's icon on Mac OS
+if targetos == 'darwin'
+newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
+ depends : emulator,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 1',
+ command : ['Rez', '-append',
+ meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+
+custom_target('Icon for ' + exe_name + ' - part 2',
+ depends : newiconpart1,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 2',
+ command : ['SetFile', '-a', 'C',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+endif
+
if exe_sign
emulators += {exe['name'] : custom_target(exe['name'],
install: true,
--
2.24.3 (Apple Git-128)
Re: Mac OS real USB device support issue
> On Apr 9, 2021, at 4:08 AM, Gerd Hoffmann wrote: > > Hi, > >> The questions that come to mind are: >> - Does libusb_detach_kernel_driver() work on Mac OS? >> - Is libusb_detach_kernel_driver() called on Mac OS in QEMU? >> >> The only mention of this function in QEMU comes from host-libusb.c. >> >> After some tests I found out the function >> host-libusb.c:usb_host_detach_kernel() is being called on Mac OS 11.1. >> It never reaches the libusb_detach_kernel_driver() function. It stops >> at the continue statement. > > Yep. Most likely libusb_kernel_driver_active() returns 0 because the > kernel driver management functions are not implemented for macos. > > take care, > Gerd > I was wondering about the usb_host_detach_kernel() code. It iterates thru interface 0 to 15. Why does it stop at 15? Isn't possible to have up to 255 interfaces?
Re: Mac OS real USB device support issue
> 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 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 documenta
Re: Mac OS real USB device support issue
> On Apr 8, 2021, at 12:40 PM, Howard Spoelstra wrote: > > 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 We could also consider our own git submodule incase the libusb people fail to fix their issue.
Re: Mac OS real USB device support issue
> On Apr 8, 2021, at 7:05 AM, 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
>
The questions that come to mind are:
- Does libusb_detach_kernel_driver() work on Mac OS?
- Is libusb_detach_kernel_driver() called on Mac OS in QEMU?
The only mention of this function in QEMU comes from host-libusb.c.
After some tests I found out the function
host-libusb.c:usb_host_detach_kernel() is being called on Mac OS 11.1. It never
reaches the libusb_detach_kernel_driver() function. It stops at the continue
statement. Here is the full function:
static void usb_host_detach_kernel(USBHostDevice *s)
{
printf("usb_host_detach_kernel() called\n");
struct libusb_config_descriptor *conf;
int rc, i;
rc = libusb_get_active_config_descriptor(s->dev, );
if (rc != 0) {
printf("rc != 0 => %d\n", rc);
return;
}
for (i = 0; i < USB_MAX_INTERFACES; i++) {
rc = libusb_kernel_driver_active(s->dh, i);
usb_host_libusb_error("libusb_kernel_driver_active", rc);
if (rc != 1) {
if (rc == 0) {
s->ifs[i].detached = true;
}
printf("rc != 1 => %d\n", rc);
continue;
}
trace_usb_host_detach_kernel(s->bus_num, s->addr, i);
rc = libusb_detach_kernel_driver(s->dh, i);
printf("libusb_detach_kernel_driver() called\n");
usb_host_libusb_error("libusb_detach_kernel_driver", rc);
s->ifs[i].detached = true;
}
libusb_free_config_descriptor(conf);
}
Next to the continue statement in the loop is where my printf function says
that rc is equal to 0. So it looks like libusb_kernel_driver_active() may have
an issue since it sets the rc variable. Later on I will try to figure out what
is happening here.
Ping: [PATCH] Set icon for QEMU binary on Mac OS
I haven't heard anything about this patch for a while.
From 45650a7f52deb8c2c436d71a3fcf5326287c2e05 Mon Sep 17 00:00:00 2001
From: John Arbuckle
Date: Tue, 2 Feb 2021 08:35:43 -0500
Subject: [PATCH] Set icon for QEMU binary on Mac OS
Before switching the build system over to Meson, an icon was
added to the QEMU binary on Mac OS. This patch adds back that
feature.
Signed-off-by: John Arbuckle
---
meson.build | 20
1 file changed, 20 insertions(+)
diff --git a/meson.build b/meson.build
index f00b7754fd..7f534f4e75 100644
--- a/meson.build
+++ b/meson.build
@@ -2183,6 +2183,26 @@ foreach target : target_dirs
link_args: link_args,
gui_app: exe['gui'])
+# set QEMU's icon on Mac OS
+if targetos == 'darwin'
+newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
+ depends : emulator,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 1',
+ command : ['Rez', '-append',
+ meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+
+custom_target('Icon for ' + exe_name + ' - part 2',
+ depends : newiconpart1,
+ input : emulator,
+ output : 'new icon for ' + exe_name + ' - 2',
+ command : ['SetFile', '-a', 'C',
+ meson.current_build_dir() / exe['name']],
+ build_by_default : true)
+endif
+
if exe_sign
emulators += {exe['name'] : custom_target(exe['name'],
install: true,
--
2.24.3 (Apple Git-128)
Re: Mac OS real USB device support issue
> 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 these methods for a certain device. > >> I have one theory. What if we introduce a middleman. A pseudo-USB device >> that the guest operating system could apply its configuration data to and >> will also talk directly with to the real USB device. >> So this: >> >> USB device <-> Host <-> QEMU USB middleman <-> Guest > > Isn't this middleman the QEMU usb-host device that we already have? It could be. I ne
Re: Mac OS real USB device support issue
> 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 to 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. I have one theory. What if we introduce a middleman. A pseudo-USB device that the guest operating system could apply its configuration data to and will also talk directly with to the real USB device. So this: USB device <-> Host <-> QEMU USB middleman <-> Guest This could make USB 2.0 and 3.0 flash drives compatible with an older operating system like Mac OS 9. The USB middleman could fully accept Mac OS 9's configuration and make it think it is talking to a USB 1.1 device. Parameters like data packet payload size would no longer be a problem. Host driver unloading would no longer be needed (in theory).
Re: Mac OS real USB device support issue
> On Apr 6, 2021, at 10:20 AM, BALATON Zoltan wrote: > > On Tue, 6 Apr 2021, 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. > > I think USB passthorugh works in VirtualBox on macOS so maybe you could check > how that works there and what might need to be done for it. Although I'm not > sure if it's in the open source part or in the non-free extensions so may not > be that easy to find out what's needed if the sources for it are not > available. > > Regards. > BALATON Zoltan Excellent idea.
Re: Mac OS real USB device support issue
> 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. Thanks. Currently there doesn't appear to be a single page with info on how to use USB devices in QEMU with a Mac OS host. Hopefully when I have collected enough information I can make one.
Mac OS real USB device support issue
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?
Copyright string's date needs to be updated to 2021
Hi Peter, The copyright string's date is still saying 2020. Could this be updated to 2021? Thank you.
Re: Qemu-devel Digest, Vol 216, Issue 57
> On Mar 3, 2021, at 4:59 AM, qemu-devel-requ...@nongnu.org wrote: > > Message: 1 > Date: Wed, 3 Mar 2021 10:22:50 +0100 > From: Gerd Hoffmann > To: Akihiko Odaki > Cc: qemu-devel@nongnu.org > Subject: Re: [PATCH 1/2] coreaudio: Drop support for macOS older than > 10.6 > Message-ID: <20210303092250.x7j6kcyrv3qjg...@sirius.home.kraxel.org> > Content-Type: text/plain; charset=us-ascii > > On Mon, Mar 01, 2021 at 08:45:53PM +0900, Akihiko Odaki wrote: >> Mac OS X 10.6 was released in 2009. > > Also minimum version required my qemu is 10.13 (I think), > so any code for older macos versions is dead anyway. > > take care, > Gerd This stinks. Older versions of Mac OS X were perfectly fine for running QEMU on. All my intel Macs run Mac OS X versions before 10.13. I'm thinking we should at least support Mac OS 10.10 and higher.
Re: [PATCH v9 04/11] slirp: feature detection for smbd
I've noticed that my guests like Windows XP and Mac OS 10.4 cannot access the internet using the recent versions of QEMU on Mac OS 11. I'm on an M1 Mac. Does your patchset enable guests to be able to access the internet?
Re: Editing QEMU POWER Platform wiki page
> On Feb 22, 2021, at 6:01 AM, Greg Kurz wrote: > > On Thu, 18 Feb 2021 10:16:25 -0300 > Leonardo Augusto Guimarães Garcia wrote: > >> Hi there, >> >> I would like to edit the wiki page at [0] as it contains some outdated >> information. Could anyone that has access to the wiki please help me >> create a user so that I can edit it? >> >> 0. https://wiki.qemu.org/Documentation/Platforms/POWER >> > > Hi Leo, > > User creation isn't publicly available to avoid spam : only an existing > user can create a new account. This being said, wiki isn't the preferred > way to expose documentation since there's no review and things ultimately > bitrot. Page [0] you want to update is a perfect example of the mess : > not only it contains irrelevant data but also stuff that is definitely > wrong (e.g. 'compat' cpu property was deprecated in QEMU 5.0 and will > be removed in QEMU 6.0). > > Ideally we'd want everything to be in the main QEMU doc and don't > even need a wiki. > > On the PowerPC front, the most up-to-date docs are in the QEMU tree: > > docs/system/ppc/embedded.rst > docs/system/ppc/powermac.rst > docs/system/ppc/powernv.rst > docs/system/ppc/prep.rst > docs/system/ppc/pseries.rst > docs/system/target-ppc.rst > > So I don't know exactly what changes you had in mind, but maybe first > consider to update the main documentation. > > On my side, I think I want do ditch all the current content and just put > links to https://qemu.readthedocs.io/en/latest/ instead. I can take care > of that, in which case you wouldn't need an account. > > Cheers, > > -- > Greg > > PS: > > Cedric reported that we also have a page for non-pseries > platforms: > > https://wiki.qemu.org/Documentation/Platforms/PowerPC > > I'm Cc'ing some regular contributors for those platforms so > they can evaluate the bitrotting status of this wiki. > >> Cheers, >> >> Leo Admittedly the wiki page for POWER is very unfriendly looking. I think it should be completely rewritten. This format should work better: - Description - IBM POWER system emulator - Build Directions - configure --target-list=ppc64-softmmu && make - Suggested Command-line - qemu-system-ppc64 -cpu POWER9 -machine pseries -m 2G -serial mon:stdio \ -cdrom -hda -boot d - Links - Linux iso files - AIX iso ? - https://worthdoingbadly.com/aixqemu/ - https://www.youtube.com/watch?v=OlajaCWvcdw - AIX 7.2 in QEMU - Pictures - Linux running in the POWER VM - AIX running in the POWER VM - Any games running in one of the above VM's - Productivity software like OpenOffice in the VM - Contacts - < maintainers' contact info > If you want I could update the wiki page for you. I just would need help with verifying the above information.
Guest network access not working on M1 Macs
Is guest networking working for users of M1 Macs? None of my VMs are able to connect to the internet. I'm using an M1 Mac with Mac OS 11.1. My QEMU is currently at commit f4ceebdec531243dd72e38f85f085287e6e63258.
Re: Virgil 3D renderer on macOS
> On Feb 12, 2021, at 4:25 AM, qemu-devel-requ...@nongnu.org wrote:
>
> Message: 2
> Date: Fri, 12 Feb 2021 12:52:21 +0900
> From: 小田喜陽彦
> To: qemu-devel@nongnu.org, virglrenderer-de...@lists.freedesktop.org
> Subject: Virgil 3D renderer on macOS
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I would like to introduce my Virgil 3D renderer port to macOS.
>
> Some patches which are made in the process are useful even without
> Virgil 3D renderer, and already submitted to upstreams:
> - [PATCH] ui/cocoa: Support unique keys of JIS keyboards
> - [PATCH] ui/cocoa: Remove the uses of full screen APIs
> - [PATCH] ui/cocoa: Do not copy members of pixman image
> - [PATCH] ui/cocoa: Interpret left button down as is when command is pressed
> - Support ANGLE on macOS by akihikodaki · Pull Request #239 · anholt/libepoxy
> https://github.com/anholt/libepoxy/pull/239
>
> I will send other patches when I confirm they do not cause harm on
> Linux hosts, or changes they depend on get merged.
>
> The complete source code is available on GitHub:
> https://github.com/akihikodaki/libepoxy/tree/macos
> https://github.com/akihikodaki/qemu/tree/macos
> https://github.com/akihikodaki/virglrenderer/tree/macos
>
> The "cocoa" display of QEMU will provide OpenGL support to the guest
> on macOS hosts. "NSOpenGLContext" (which wraps "CGL") will be the
> backend for core profile. ANGLE (which also wraps CGL and provides
> compatibility improvements) will be the backend for ES profile. It is
> possible to build without ANGLE, but such a build will lose ES profile
> compatibility.
>
> Videos captured on M1 MacBook Air are available on YouTube:
> https://youtu.be/ezvQPREjN1s (The WebGL Aquarium on the host, for comparison)
> https://youtu.be/iOG9Dbn8VoE (QEMU with OpenGL Core)
> https://youtu.be/k0bVlVQU2JQ (QEMU with OpenGL ES)
>
> glmark2 gives 577 scores for gl=es and 151 scores for gl=off. The FPS
> of the WebGL aquarium with identical configurations was consistent
> with the display on the host (60 FPS), 15 FPS with gl=es, 8 FPS with
> gl=off.
>
> I have not ran a formal conformance tests, but gl=core (which uses
> NSOpenGLContext) had a few problems:
> - glmark2 fails with the following output:
>> vrend_compile_shader: context error reported 6 "glmark2" Illegal shader 0
>> shader failed to compile
>> ERROR: 0:2: '' : extension 'GL_ARB_fragment_coord_conventions' is not
>> supported
>
> - Mozilla Firefox opening "about:support" fails with the following
> output on the host (This one should be easy to fix but I rather not
> because I also have gl=es.):
>> No provider of glTexStorage2DMultisample found. Requires one of:
>>Desktop OpenGL 4.3
>>
>>GL_ARB_texture_storage_multisample
>>OpenGL ES 3.1
>
> In contrast, gl=es, backed with ANGLE, runs properly as far as I have seen.
>
> My motivation is to make Linux desktop usable on M1. Patches to add
> Hypervisor framework support on Aarch64 are already submitted ("hvf:
> Implement Apple Silicon Support") and they are indeed useful for
> various workloads and I also used them to port Virgil, but I also
> needed graphics acceleration for my purpose. Another attempt to get
> Linux work on M1 is Asahi Linux, which aims to run Linux bare-metal.
> Of course, this needs porting graphic stacks to M1 and is likely to
> take time. I am satisfied with my port for the purpose although there
> may be rooms for performance or compatibility improvements.
>
> There is nothing preventing that if anyone would like to use Virgil on
> Intel Macs. Also, some patches may benefit other OpenGL ES
> configurations and displays.
>
> Thanks,
I am also an M1 Mac owner. I don't know very much about graphics cards but I
would be happy to help if you need a tester.
I was doing a lot of thinking about implementing a 3D video card in QEMU. One
option was to port PCem's Voodoo2 card to QEMU. Another option was to implement
the ATI Rage 128 card. Drivers wouldn't probably be a problem since they
already exist for Mac OS and Windows. One issue users might encounter is game
support. Both these cards are older and probably are missing features that
newer games need. Then there's the problem of proprietary firmware files these
cards probably use. So I was wondering what your opinion on this issue. Should
we focus on emulating a real video card or focus on making Virgil 3D compatible
with more operating systems?
Re: USB pass through into Mac OS 9.x with qemu-system-ppc
> On Feb 8, 2021, at 8:29 AM, qemu-devel-requ...@nongnu.org wrote: > > Message: 15 > Date: Mon, 8 Feb 2021 14:29:06 +0100 > From: Howard Spoelstra > To: qemu-devel qemu-devel , Gerd Hoffmann > > Subject: USB pass through into Mac OS 9.x with qemu-system-ppc > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I'd like to report an issue when passing through an USB device into Mac OS > 9.2. > Passing through the same device into Fedora 12 ppc guest works fine. Host > is Fedora 33. Both guests use the OHCI controller. AFAICT Mac OS 9 only has > support for OHCI. > > Pcap files for two runs are attached, as is a screenshot of Mac OS 9.2 USB > messages from inside the guest. > > 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.) > > 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. > > 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 > > Or like this for the Fedora 12 guest: > ./qemu-system-ppc \ > -L pc-bios \ > -boot c \ > -prom-env "boot-device=hd:,\yaboot" -prom-env > "boot-args=conf=hd:,\yaboot.conf" \ > -M mac99,via=pmu \ > -m 1024 \ > -drive file=/home/hsp/Linux-disks/fedora12.qcow2 \ > -g 1024x768x32 \ > -device usb-host,vendorid=0x058f,productid=0x6387,pcap=fedora12.pcap > > Thanks for looking into this, > > Best, > Howard Spoelstra Hi Howard. I suggest you make a bug report so we may track this issue. This is where you would file the bug: https://bugs.launchpad.net/qemu/ I didn't know about the pcap option. It looks very useful. Thank you.
Re: Help with Windows XP in qemu-system-i386
> On Feb 5, 2021, at 4:08 PM, Programmingkid wrote: > > > >> On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin wrote: >> >> On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote: >>> Hi, I'm noticing that my Windows XP Service Pack 3 VM is causing >>> qemu-system-i386 to experience 100% host cpu usage even when the guest is >>> at idle. I was wondering if you are seeing this issue as well on any >>> version of Windows guest? Windows 2000 doesn't seem to have this problem so >>> I'm wondering if this is a bug with QEMU or a problem with my VM. Any help >>> would be appreciated. >>> >>> Thank you. >> >> Just tried an xp guest, stays below 10% for me. Suggest discussing this >> on the mailing list. > > Thank you for the reply. Which service pack is your Windows XP VM using? > Hi Michael. I noticed what was the cause of Windows XP using so much CPU time when idle. When I used the '-smp 4' option Windows made a change then restarted. After restarting the screen was black. Does this happen to you? Please make a backup of any image file you have before experimenting. Windows 7 doesn't have this problem. I am qemu-system-i386 at commit 1214d55d1c41fbab3a9973a05085b8760647e411. Removing the '-smp 2' option does make Windows XP start up again, but the high host CPU usage at idle remains... I reported this bug here: https://bugs.launchpad.net/qemu/+bug/1914294
Re: Help with Windows XP in qemu-system-i386
> On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin wrote: > > On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote: >> Hi, I'm noticing that my Windows XP Service Pack 3 VM is causing >> qemu-system-i386 to experience 100% host cpu usage even when the guest is at >> idle. I was wondering if you are seeing this issue as well on any version of >> Windows guest? Windows 2000 doesn't seem to have this problem so I'm >> wondering if this is a bug with QEMU or a problem with my VM. Any help would >> be appreciated. >> >> Thank you. > > Just tried an xp guest, stays below 10% for me. Suggest discussing this > on the mailing list. Thank you for the reply. Which service pack is your Windows XP VM using?
Re: [PATCH] Set icon for QEMU binary on Mac OS
> On Feb 4, 2021, at 3:54 AM, Paolo Bonzini wrote:
>
> On 02/02/21 14:44, John Arbuckle wrote:
>> Before switching the build system over to Meson, an icon was
>> added to the QEMU binary on Mac OS. This patch adds back that
>> feature.
>> Signed-off-by: John Arbuckle
>> ---
>> meson.build | 20
>> 1 file changed, 20 insertions(+)
>> diff --git a/meson.build b/meson.build
>> index f00b7754fd..7f534f4e75 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -2183,6 +2183,26 @@ foreach target : target_dirs
>> link_args: link_args,
>> gui_app: exe['gui'])
>> +# set QEMU's icon on Mac OS
>> +if targetos == 'darwin'
>> +newiconpart1 = custom_target('Icon for ' + exe_name + ' - part 1',
>> + depends : emulator,
>> + input : emulator,
>> + output : 'new icon for ' + exe_name + ' - 1',
>> + command : ['Rez', '-append',
>> + meson.source_root() + '/pc-bios/qemu.rsrc', '-o',
>> + meson.current_build_dir() / exe['name']],
>> + build_by_default : true)
>> +
>> +custom_target('Icon for ' + exe_name + ' - part 2',
>> + depends : newiconpart1,
>> + input : emulator,
>> + output : 'new icon for ' + exe_name + ' - 2',
>> + command : ['SetFile', '-a', 'C',
>> + meson.current_build_dir() / exe['name']],
>> + build_by_default : true)
>> +endif
>> +
>> if exe_sign
>>emulators += {exe['name'] : custom_target(exe['name'],
>> install: true,
>
> Maybe you can do it on install, using add_install_script instead?
>
> Paolo
The script would only be two lines long:
Rez -append ./pc-bios/qemu.rsrc -o $(QEMU_BINARY)
SetFile -a C $(QEMU_BINARY)
Is a separate script file still preferred?
Re: Makefile has local changes that will be overwritten
> On Feb 1, 2021, at 11:04 AM, Stefan Weil wrote: > > Am 01.02.21 um 16:36 schrieb Programmingkid: > >> Thank you for the suggestion. I tried it but didn't seem to help. I should >> report this is what I see when I try to build QEMU: >> Disabling PIE due to missing toolchain support >> error: Your local changes to the following files would be overwritten by >> checkout: >> Makefile >> Please commit your changes or stash them before you switch branches. >> Aborting >> Unable to checkout '85e5d839847af54efab170f2b1331b2a6421e647' in submodule >> path 'dtc' >> /Users/john/Documents/Development/Projects/Qemu/qemu-git/scripts/git-submodule.sh: >> failed to update modules >> >> Unable to automatically checkout GIT submodules ' ui/keycodemapdb >> tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 meson dtc >> capstone slirp'. > > So dtc/Makefile is causing the problem. > > What does "git -C dtc diff" show? diff --git a/Makefile b/Makefile old mode 100644 new mode 100755 > "git -C dtc reset --hard" might fix the problem for you. This does make configure work now :) Thank you.
Re: Makefile has local changes that will be overwritten
> On Feb 1, 2021, at 10:46 AM, Daniel P. Berrangé wrote: > > On Mon, Feb 01, 2021 at 09:23:24AM -0500, Programmingkid wrote: >> When trying to build QEMU I see this error: >> >> error: Your local changes to the following files would be overwritten by >> checkout: >> Makefile >> Please commit your changes or stash them before you switch branches. >> Aborting > > This suggests you've made changes to "Makefile" in your local > checkout that aren't committed. What does 'git diff Makefile" > say ? It didn't say anything. >> What I do to see this error: >> ./configure --target-list=i386-softmmu >> >> I did some bisecting and found out this is the patch that causes the problem: >> >> commit 7d7dbf9dc15be6e1465c756c2c5ae7f1ab104fc8 >> Author: Dan Streetman >> Date: Tue Jan 19 12:20:46 2021 -0500 >> >>configure: replace --enable/disable-git-update with --with-git-submodules >> >>Replace the --enable-git-update and --disable-git-update configure params >>with the param --with-git-submodules=(update|validate|ignore) to >>allow 3 options for building from a git repo. > > That commit includes changes to "Makefile", so if you have made local > changes to Makefile yourself, this will cause the message you see from > git. Either stash your changes, or rebase to resolve them. I didn't make any changes to the Makefile. I even deleted it and tried configure again. Saw the same error about MakeFile again.
Re: Makefile has local changes that will be overwritten
> On Feb 1, 2021, at 9:58 AM, Stefan Weil wrote: > > Am 01.02.21 um 15:23 schrieb Programmingkid: > >> When trying to build QEMU I see this error: >> >> error: Your local changes to the following files would be overwritten by >> checkout: >> Makefile >> Please commit your changes or stash them before you switch branches. >> Aborting >> >> What I do to see this error: >> ./configure --target-list=i386-softmmu > > > I suggest to start with a clean installation (or clean your existing > installation manually, especially remove the generated Makefile) and run > configure from a subdirectory: > > mkdir -p build && cd build && ../configure --target-list=i386-softmmu > > Running ./configure is no longer supported. > > Regards, > > Stefan Thank you for the suggestion. I tried it but didn't seem to help. I should report this is what I see when I try to build QEMU: Disabling PIE due to missing toolchain support error: Your local changes to the following files would be overwritten by checkout: Makefile Please commit your changes or stash them before you switch branches. Aborting Unable to checkout '85e5d839847af54efab170f2b1331b2a6421e647' in submodule path 'dtc' /Users/john/Documents/Development/Projects/Qemu/qemu-git/scripts/git-submodule.sh: failed to update modules Unable to automatically checkout GIT submodules ' ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 meson dtc capstone slirp'. If you require use of an alternative GIT binary (for example to enable use of a transparent proxy), then please specify it by running configure by with the '--with-git' argument. e.g. $ ./configure --with-git='tsocks git' Alternatively you may disable automatic GIT submodule checkout with: $ ./configure --with-git-submodules=validate and then manually update submodules prior to running make, with: $ scripts/git-submodule.sh update ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 meson dtc capstone slirp
Re: Makefile has local changes that will be overwritten
> On Feb 1, 2021, at 9:52 AM, Peter Maydell wrote: > > On Mon, 1 Feb 2021 at 14:49, Dan Streetman wrote: >> >> On Mon, Feb 1, 2021 at 9:23 AM Programmingkid >> wrote: >>> >>> When trying to build QEMU I see this error: >>> >>> error: Your local changes to the following files would be overwritten by >>> checkout: >>>Makefile >>> Please commit your changes or stash them before you switch branches. >>> Aborting >>> >>> What I do to see this error: >>> ./configure --target-list=i386-softmmu >> >> Sorry, I don't see that error, what commit are you building from? > > ...and what does git think the local changes to Makefile are ? This is the output of 'git status': On branch master Your branch is up to date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: dtc (new commits, modified content) Untracked files: (use "git add ..." to include in what will be committed) pixman/ no changes added to commit (use "git add" and/or "git commit -a") This is the output of 'git diff master': diff --git a/dtc b/dtc index 85e5d83984..88f18909db 16 --- a/dtc +++ b/dtc @@ -1 +1 @@ -Subproject commit 85e5d839847af54efab170f2b1331b2a6421e647 +Subproject commit 88f18909db731a627456f26d779445f84e449536-dirty I have tried 'git clean -d -f', 'git reset --hard' and 'git pull'. I am now at 74208cd252c5da9d867270a178799abd802b9338 and still seeing the error with MakeFile.
Re: Makefile has local changes that will be overwritten
> On Feb 1, 2021, at 9:48 AM, Dan Streetman wrote: > > On Mon, Feb 1, 2021 at 9:23 AM Programmingkid > wrote: >> >> When trying to build QEMU I see this error: >> >> error: Your local changes to the following files would be overwritten by >> checkout: >>Makefile >> Please commit your changes or stash them before you switch branches. >> Aborting >> >> What I do to see this error: >> ./configure --target-list=i386-softmmu > > Sorry, I don't see that error, what commit are you building from? 7d7dbf9dc15be6e1465c756c2c5ae7f1ab104fc8
Makefile has local changes that will be overwritten
When trying to build QEMU I see this error: error: Your local changes to the following files would be overwritten by checkout: Makefile Please commit your changes or stash them before you switch branches. Aborting What I do to see this error: ./configure --target-list=i386-softmmu I did some bisecting and found out this is the patch that causes the problem: commit 7d7dbf9dc15be6e1465c756c2c5ae7f1ab104fc8 Author: Dan Streetman Date: Tue Jan 19 12:20:46 2021 -0500 configure: replace --enable/disable-git-update with --with-git-submodules Replace the --enable-git-update and --disable-git-update configure params with the param --with-git-submodules=(update|validate|ignore) to allow 3 options for building from a git repo. My Info: Mac OS 11.1 Arm64 CPU
[Bug 1913505] Re: Windows XP slow on Apple M1
> On Jan 29, 2021, at 1:20 AM, qemu-devel-requ...@nongnu.org wrote: > > Message: 14 > Date: Fri, 29 Jan 2021 06:06:41 - > From: Thomas Huth <1913...@bugs.launchpad.net> > To: qemu-devel@nongnu.org > Subject: [Bug 1913505] Re: Windows XP slow on Apple M1 > Message-ID: > > <161190040137.32137.17544748693681218726.mal...@chaenomeles.canonical.com> > > Content-Type: text/plain; charset="utf-8" > > Did you compile QEMU on your own? If so, which parameters did you use > for the "configure" script? > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1913505 > > Title: > Windows XP slow on Apple M1 > > Status in QEMU: > New > > Bug description: > Qemu installed by using brew install qemu -s on M1 > > QEMU emulator version 5.2.0 > XP image from: https://archive.org/details/WinXPProSP3x86 > > Commands run: > $ qemu-img create -f qcow2 xpsp3.img 10G > $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom > WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso > -boot d > > It's taken 3 days now with qemu running at around 94% CPU and > installation hasn't finished. The mouse pointer moves and occasionally > changes between the pointer and hourglass so it doesn't seem to have > frozen. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions Hi, I followed your directions on reproducing this issue. My times were very different from yours. I used my own patch to make qemu-system-i386 on my M1 Mac running Mac OS 11.1. It is on the list if you want to try it. For Windows XP, I used my own copy. It was build 2600 and Service Pack 3. Installing Windows XP took about 23 minutes. After the installation was completed Windows tried to start up but probably crashed so I had to reboot the VM. After that it started up without problems. Here are some benchmarks I did: For my ARM-based QEMU I saw these start up times to the login screen: 1:20, 1:19, 1:16, 1:18 For a QEMU binary I made a few years ago that is x86_64-based, I saw these times: 1:09, 1:09 The ARM-based QEMU is at version 5.2.50 (git commit 9cd69f1a270235b652766f00b94114f48a2d603f). The x86_64-based QEMU is at version 2.10.1. I would have bet that the ARM-based QEMU would run circles around the x86_64 version, but the opposite happened. These are my theories about what could be wrong: - A patch somewhere made QEMU slow -- feature bloat -- bugs -- emulated hardware issues - The ARM TCG isn't as good as the x86_64 version - Non-optimal command-line options Please let me know if you have any ideas or suggestions. Thank you.
Re: [RFC] QEMU as Xcode project on macOS
> On Sep 9, 2020, at 8:56 AM, Christian Schoenebeck > wrote: > > I've recently been thinking about how feasible a stripped down Xcode project > for QEMU would be, i.e. you just get the QEMU sources, click on > qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing. > > I've done this before for gtk(mm), which you might know, depends on approx. > 24 > individual libraries (glib, jpeg, png, pixman, atk, gdk, cairo, pixman, > graphene, sigcpp, ... gtk, gtkmm) that you would usually all need to download > and > > ./configure && make & make install > > each individually on macOS. Or right, you could alternatively "just install" > them from Homebrew, MacPorts, Fink. But no matter which solution you choose, > it easily ends up in a mess (conflicts, misbehaviours) on macOS to install > libs and apps globally. And I think that's the problem why there are > currently > relatively little contribution for QEMU coming from devs on macOS. Because > you > don't want to install things globally on a macOS system, it's simply not > working well there as it does with Linux distros. > > And the other thing is: I've tested the waters with Apple and filed a QEMU > related macOS bug with them. The response was like expected; they basically > said 'if there's no Xcode project, then we don't investigate it'. > > The question is, and I don't have the big picture of QEMU yet to judge that, > how much is auto generated for QEMU i.e. with custom scripts that would > probably destroy this plan? There are these trace calls that are auto > generated, is there more like the TCG part for instance? > > What I could imagine: a hand crafted Xcode project as a starting point, and > if > that works out, switching to auto generating that Xcode project from the > Meson > inftrastructure to avoid multiplication of maintenance effort. > > Best regards, > Christian Schoenebeck > I think the solution to this problem is to switch over the CMake (https://en.wikipedia.org/wiki/CMake). It is a build system that lets you specify how you want to build software. There are many targets available including 'make' and an Xcode project file.
Re: About hardfloat in ppc
> On Apr 30, 2020, at 12:34 PM, Dino Papararo wrote:
>
> Maybe the fastest way to implement hardfloats for ppc could be run them by
> default and until some fpu instruction request for FPSCR register.
> At this time probably we want to check for some exception.. so QEMU could
> come back to last fpu instruction executed and re-execute it in softfloat
> taking care this time of FPSCR flags, then continue in hardfloats unitl
> another instruction looking for FPSCR register and so on..
>
> Dino
That sounds like a good idea.
> -Messaggio originale-
> Da: BALATON Zoltan
> Inviato: giovedì 30 aprile 2020 17:36
> A: 罗勇刚(Yonggang Luo)
> Cc: Richard Henderson ; Dino Papararo
> ; qemu-devel@nongnu.org; Programmingkid
> ; qemu-...@nongnu.org; Howard Spoelstra
> ; Alex Bennée
> Oggetto: Re: R: R: About hardfloat in ppc
>
> On Thu, 30 Apr 2020, 罗勇刚(Yonggang Luo) wrote:
>> I propose a new way to computing the float flags, We preserve a float
>> computing cash typedef struct FpRecord { uint8_t op;
>> float32 A;
>> float32 B;
>> } FpRecord;
>> FpRecord fp_cache[1024];
>> int fp_cache_length;
>> uint32_t fp_exceptions;
>>
>> 1. For each new fp operation we push it to the fp_cache, 2. Once we
>> read the fp_exceptions , then we re-compute the fp_exceptions by
>> re-running the fp FpRecord sequence.
>> and clear fp_cache_length.
>> 3. If we clear the fp_exceptions , then we set fp_cache_length to 0
>> and clear fp_exceptions.
>> 4. If the fp_cache are full, then we re-compute the fp_exceptions by
>> re-running the fp FpRecord sequence.
>>
>> Would this be a general method to use hard-float?
>> The consued time should be 2*hard_float.
>> Considerating read fp_exceptions are rare, then the amortized time
>> complexity would be 1 * hard_float.
>
> It's hard to guess what the hit rate of such cache would be and if it's low
> then managing the cache is probably more expensive than running with
> softfloat. So to evaluate any proposed patch we also need some benchmarks
> which we can experiment with to tell if the results are good or not otherwise
> we're just guessing. Are there some existing tests and benchmarks that we can
> use? Alex mentioned fp-bench I think and to evaluate the correctness of the
> FP implementation I've seen this other
> conversation:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg05107.html
> https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg05126.html
>
> Is that something we can use for PPC as well to check the correctness?
>
> So I think before implementing any potential solution that came up in this
> brainstorming the first step would be to get and compile (or write if not
> available) some tests and benchmarks:
>
> 1. testing host behaviour for inexact and compare that for different archs 2.
> some FP tests that can be used to compare results with QEMU and real CPU to
> check correctness of emulation (if these check for inexact differences then
> could be used instead of 1.) 3. some benchmarks to evaluate QEMU performance
> (these could be same as FP tests or some real world FP heavy applications).
>
> Then we can see if the proposed solution is faster and still correct.
>
> Regards,
> BALATON Zoltan
Sound support for Mac OS guests
Hi Mark, I was just wondering what it is going to take to have Mac OS sound support in qemu-system-ppc? I have made four versions of my Screamer sound chip patch and you ignored each one. Did you plan on committing your version of Screamer?
Re: [PATCH v2 6/8] target/ppc: allow ppc_cpu_do_system_reset to take an alternate vector
> On Mar 17, 2020, at 6:46 PM, David Gibson wrote: > > On Tue, Mar 17, 2020 at 11:06:15AM -0400, Programmingkid wrote: >> >>> On Mar 17, 2020, at 7:01 AM, qemu-ppc-requ...@nongnu.org wrote: >>> >>> Message: 3 >>> Date: Tue, 17 Mar 2020 11:47:32 +0100 >>> From: Cédric Le Goater >>> To: David Gibson , Nicholas Piggin >>> >>> Cc: qemu-...@nongnu.org, Aravinda Prasad , >>> Ganesh Goudar , Greg Kurz , >>> qemu-devel@nongnu.org >>> Subject: Re: [PATCH v2 6/8] target/ppc: allow ppc_cpu_do_system_reset >>> to take an alternate vector >>> Message-ID: <097148e5-78be-a294-236d-160fb5c29...@kaod.org> >>> Content-Type: text/plain; charset=windows-1252 >>> >>> On 3/17/20 12:34 AM, David Gibson wrote: >>>> On Tue, Mar 17, 2020 at 09:28:24AM +1000, Nicholas Piggin wrote: >>>>> Cédric Le Goater's on March 17, 2020 4:15 am: >>>>>> On 3/16/20 3:26 PM, Nicholas Piggin wrote: >>>>>>> Provide for an alternate delivery location, -1 defaults to the >>>>>>> architected address. >>>>>> >>>>>> I don't know what is the best approach, to override the vector addr >>>>>> computed by powerpc_excp() or use a machine class handler with >>>>>> cpu->vhyp. >>>>> >>>>> Yeah it's getting a bit ad hoc and inconsistent with machine check >>>>> etc, I just figured get something minimal in there now. The whole >>>>> exception delivery needs a spring clean though. >>>> >> >> Currently Mac OS 9 will not restart. When someone goes to restart it >> the screen will turn black and stay that way. Could this patch solve >> this problem? > > No. It's unlikely to be related, and at this stage is used > exclusively to implement the FWNMI stuff for the pseries machine. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_ > _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Ok. Thank you.
Re: [PATCH v2 6/8] target/ppc: allow ppc_cpu_do_system_reset to take an alternate vector
> On Mar 17, 2020, at 7:01 AM, qemu-ppc-requ...@nongnu.org wrote: > > Message: 3 > Date: Tue, 17 Mar 2020 11:47:32 +0100 > From: Cédric Le Goater > To: David Gibson , Nicholas Piggin > > Cc: qemu-...@nongnu.org, Aravinda Prasad , > Ganesh Goudar , Greg Kurz , > qemu-devel@nongnu.org > Subject: Re: [PATCH v2 6/8] target/ppc: allow ppc_cpu_do_system_reset > to take an alternate vector > Message-ID: <097148e5-78be-a294-236d-160fb5c29...@kaod.org> > Content-Type: text/plain; charset=windows-1252 > > On 3/17/20 12:34 AM, David Gibson wrote: >> On Tue, Mar 17, 2020 at 09:28:24AM +1000, Nicholas Piggin wrote: >>> Cédric Le Goater's on March 17, 2020 4:15 am: On 3/16/20 3:26 PM, Nicholas Piggin wrote: > Provide for an alternate delivery location, -1 defaults to the > architected address. I don't know what is the best approach, to override the vector addr computed by powerpc_excp() or use a machine class handler with cpu->vhyp. >>> >>> Yeah it's getting a bit ad hoc and inconsistent with machine check >>> etc, I just figured get something minimal in there now. The whole >>> exception delivery needs a spring clean though. >> Currently Mac OS 9 will not restart. When someone goes to restart it the screen will turn black and stay that way. Could this patch solve this problem?
Re: [PATCH] qemu-common.h: Update copyright string to include 2020
> On Mar 14, 2020, at 5:33 PM, Philippe Mathieu-Daudé wrote:
>
> Extend the copyright range to include the current year.
>
> Reported-by: John Arbuckle
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/qemu-common.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/qemu-common.h b/include/qemu-common.h
> index 082da59e85..d0142f29ac 100644
> --- a/include/qemu-common.h
> +++ b/include/qemu-common.h
> @@ -13,7 +13,7 @@
> #define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)
>
> /* Copyright string for -version arguments, About dialogs, etc */
> -#define QEMU_COPYRIGHT "Copyright (c) 2003-2019 " \
> +#define QEMU_COPYRIGHT "Copyright (c) 2003-2020 " \
> "Fabrice Bellard and the QEMU Project developers"
>
> /* Bug reporting information for --help arguments, About dialogs, etc */
> --
> 2.21.1
>
Thank you for making this patch. I tried my best to apply it but I kept seeing
'malformed patch at line' errors. It was probably an issue with my email client.
About dialog copyright date needs updating
Hi Peter, in the About dialog for QEMU the copyright date shows as 2019. Can it be updated to 2020 please? Thank you.
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
> On Feb 26, 2020, at 1:09 PM, Alex Bennée wrote: > > > G 3 writes: > >> Accuracy is an important part of the IEEE 754 floating point standard. The >> whole purpose of this standard is to ensure floating point calculations are >> consistent across multiple CPUs. I believe referring to this patch as >> inaccurate is itself inaccurate. That gives the impression that this patch >> produces calculations that are not inline with established standards. This >> is not true. The only part of this patch that will produce incorrect values >> are the flags. > > As I stated further up the thread I'd be happy to take a patch that > turns this on without the messing about with the FPU flags which AFAICT > breaks the architectural compliance of those instructions. The ability > to detect inexact results is part of the IEEE spec even if it is > considerably looser about when the flag should be reset. > >> There *may* be a program or two out there that depend on >> these flags, but for the majority of programs that only care about basic >> floating point arithmetic this patch will produce correct values. Currently >> the emulated PowerPC's FPU already produces wrong values for the >> flags. > > Those are bugs that should be fixed. The state of the flags after a > calculation should be considered part of the "values" generated by the > FPU. > >> This patch does set the Inexact flag (which I don't like), but since I have >> never encountered any source code that cares for this flag, I can let it >> go. I think giving the user the ability to decide which option to use is >> the best thing to do. > > Giving the user the option to break things is a poor flag, most of QEMUs > configurable knobs are about trading of size/speed without affecting > correctness. > > If the PPC maintainers are happy that hardfloat's speed trade-offs are > worth it for usual workloads (whatever they may be) then I have no > objection to making defaulting hardfloat to on - perhaps* even with an > option to force softfloat if it faster for some workloads. > >> >> On Wed, Feb 26, 2020 at 10:51 AM Aleksandar Markovic < >> aleksandar.m.m...@gmail.com> wrote: >> >>> >>> >>> On Wed, Feb 26, 2020 at 3:29 PM Alex Bennée >>> wrote: Dino Papararo writes: > Please let's go with hardfloat pps support, it's really a good feature >>> to implement. > Even if in a first step it could lead to inaccuracy results, later it > could solved with other patches. That's the wrong way around. We have regression tests for a reason. >>> >>> I tend to agree with Alex here, and additionally want to expand more on >>> this topic. >>> >>> In my view: (that I think is at least very close to the community >>> consensus) >>> >>> This is *not* a ppc-specific issue. There exist a principle across all >>> targets >>> that QEMU FPU calculation must be accurate - exactly as specified in any >>> applicable particular ISA document. Any discrepancy is an outright bug. >>> >>> We even recently had several patches for FPU in ppc target that handled >>> some fairly obscure cases of inaccuracies, I believe they were authored >>> by Paul Clarke, so there are people in ppc community that care about >>> FPU accuracy (as I guess is the case for any target). >>> >>> There shouldn't be a target that decides by itself and within itself >>> "ok, we don't need accuracy, let's trade it for speed". This violates >>> the architecture of QEMU. Please allow that for any given software >>> project, there is an architecture that should be respected. >>> >>> This doesn't mean that anybody's experimentation is discouraged. No-one >>> can stop anybody from forking from QEMU upstream tree and do whatever >>> is wanted. >>> >>> But, this doesn't mean such experimentation will be upstreamed. QEMU >>> upstream should be collecting place for the best ideas and implementations, >>> not for arbitrary experimentations. >>> >>> Best regards, >>> Aleksandar >>> >>> I'll happily accept patches to turn on hardfloat for PPC if: a) they don't cause regressions in our fairly extensive floating point tests b) the PPC maintainers are happy with the new performance profile The way forward would be to: 1. patch to drop #if defined(TARGET_PPC) || defined(__FAST_MATH__) 2. audit target/ppc/fpu_helper.c w.r.t chip manual and fix any unneeded splatting of flags (if any) 3. measure the before/after performance effect and decide if on balance it's worth keeping > I think it's important for qemu to as global as possible and don't > target only recent hardware. Are you referring to guests or hosts? For guests we will always favour accuracy of speed of emulation. For hosts we need to have IEEE compliant FPU HW to even stand a chance of using hardfloat. -- Alex Bennée >>> > > > -- > Alex Bennée Ok, I was just looking at Intel's x87 chip
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
> On Feb 26, 2020, at 12:27 PM, Aleksandar Markovic > wrote: > > On Wed, Feb 26, 2020 at 6:04 PM G 3 wrote: >> >> Accuracy is an important part of the IEEE 754 floating point standard. The >> whole purpose of this standard is to ensure floating point calculations are >> consistent across multiple CPUs. I believe referring to this patch as >> inaccurate is itself inaccurate. That gives the impression that this patch >> produces calculations that are not inline with established standards. This >> is not true. The only part of this patch that will produce incorrect values >> are the flags. There *may* be a program or two out there that depend on >> these flags, but for the majority of programs that only care about basic >> floating point arithmetic this patch will produce correct values. Currently >> the emulated PowerPC's FPU already produces wrong values for the flags. This >> patch does set the Inexact flag (which I don't like), but since I have never >> encountered any source code that cares for this flag, I can let it go. I >> think giving the user the ability to decide which option to use is the best >> thing to do. >> > > From the experiments described above, the patch in question changes the > behavior > of applications (for example, sound is different with and without the > patch), which is > in contradiction with your claim that you "never encountered any > source code that > cares for this flag" and that "the only part of this patch that will > produce incorrect > values are the flags". > > In other words, and playing further with them: > > The claim that "referring to this patch as inaccurate is itself > inaccurate" is itself inaccurate. > > Best regards, > Aleksandar It is inaccurate to state that just because the USB audio device seems to play better with the hardfloat feature enabled that this changes the fact that I have yet to see any source code that actually reviews the flags. I have reviewed both the USB audio device and Apple's AppleUSBAudio class code and have not seen any mention of the exception flags.
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
> On Feb 25, 2020, at 7:09 AM, BALATON Zoltan wrote: > > On Mon, 24 Feb 2020, Programmingkid wrote: >> Intel Core i5-2500S CPU @ 2.70GHz. > [...] >> Ok, I did test on the G4, here are my results: >> >> Git commit: c1e667d2598b9b3ce62b8e89ed22dd38dfe9f57f >> Mac OS 10.4.3 VM >> -cpu G4 >> -USB audio device >> >> Hardfloat=false >> Audio sounds bad when playing midi file. >> Extraction rate: 1.5x >> Converting rate: 0.7x >> Total time: 7:24 >> >> Hardfloat=true >> Midi audio sounded perfect for about 30 seconds, then it went silent! >> Extraction rate: 1.4x (slower with hard float) >> Converting rate: 0.7x (same as without hardfloat) >> Total time: 7:16 (faster time with hardfloat) > > How is that extraction rate is slower but total time is less than without > hardfloat? There must be other factors here than just FP ops. Maybe a better > test is to not play the audio just save it to a file so other issues with USB > is not influencing the test. I does seem odd to me also. >> When I played sound this second time I hard the same broken audio I usually >> hear with the USB audio device with hardfloat set to false. When playing the >> same midi file with hardfloat set to true, the audio played perfectly! It >> only played for 30 seconds before it went silent. > > So probably there are at least two problems: FPU emulation is not fast enough > to decode audio to fill buffer then there's also something with usb-audio > that jams it after a while? I don't think all of this is FPU related. I think a timeout takes place and that is why audio stops playing. It is probably an USB OHCI issue. The other USB controller seems to work better. > >> I can give you the full testing suite if you like. I run it on Mac OS 10.4 >> but it should compile with gcc on Linux. I will send it to you in a separate >> email because it is big. > > Thanks, I'll have a look and see if I can make sense of it but not sure when > will I find time. Please let me know if you have any questions with it. > >> I have another idea on how to improve QEMU's performance. What if you >> enabled more CPUs for the PowerPC target? Mac OS 9, Mac OS X, and Linux >> support multiple CPUs. It might actually be easier to do this than to > > Have you tried if it works? I think MTTCG is enabled for PPC64 but not sure > about 32 bit PPC. The mac99 machine seems to init multiple CPUs but not sure > if they'll use MTTCG. But you could test it to see if it makes any difference. I had completely forgot about MTTCG. I think Howard once did some performance testing with it and came back with favorable results. Maybe this is another avenue we should look at. > >> improve the FPU. I imagine the performance increase with multiple emulated >> CPUs would be much more noticeable. > > The Amiga like OSes I'm interested in don't use multiple cores so I'm mainly > interested in improving single core performance. Also I'm not sure if (part > of) your problem is slow FPU preventing fast enough audio decoding then > having multiple CPUs with slow FPU would help as this may use a single thread > anyway. Good point. MTTCG might be the option that really helps with speed improvements.
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
> On Feb 19, 2020, at 10:35 AM, BALATON Zoltan wrote: > > Hello, > > On Tue, 18 Feb 2020, Programmingkid wrote: >>> On Feb 18, 2020, at 12:10 PM, BALATON Zoltan wrote: >>> While other targets take advantage of using host FPU to do floating >>> point computations, this was disabled for PPC target because always >>> clearing exception flags before every FP op made it slightly slower >>> than emulating everyting with softfloat. To emulate some FPSCR bits, >>> clearing of fp_status may be necessary (unless these could be handled >>> e.g. using FP exceptions on host but there's no API for that in QEMU >>> yet) but preserving at least the inexact flag makes hardfloat usable >>> and faster than softfloat. Since most clients don't actually care >>> about this flag, we can gain some speed trading some emulation >>> accuracy. >>> >>> This patch implements a simple way to keep the inexact flag set for >>> hardfloat while still allowing to revert to softfloat for workloads >>> that need more accurate albeit slower emulation. (Set hardfloat >>> property of CPU, i.e. -cpu name,hardfloat=false for that.) There may >>> still be room for further improvement but this seems to increase >>> floating point performance. Unfortunately the softfloat case is slower >>> than before this patch so this patch only makes sense if the default >>> is also set to enable hardfloat. >>> >>> Because of the above this patch at the moment is mainly for testing >>> different workloads to evaluate how viable would this be in practice. >>> Thus, RFC and not ready for merge yet. >>> >>> Signed-off-by: BALATON Zoltan >>> --- >>> v2: use different approach to avoid needing if () in >>> helper_reset_fpstatus() but this does not seem to change overhead >>> much, also make it a single patch as adding the hardfloat option is >>> only a few lines; with this we can use same value at other places where >>> float_status is reset and maybe enable hardfloat for a few more places >>> for a little more performance but not too much. With this I got: >> >> >> >> Thank you for working on this. It is about time we have a better FPU. > > Thank you for testing it. I think it would be great if we could come up with > some viable approach to improve this before the next freeze. > >> I applied your patch over David Gibson's ppc-for-5.0 branch. It applied >> cleanly and compiled easily. > > I've heard some preliminary results from others that there's also a > difference between v1 and v2 of the patch in performance where v1 may be > faster for same cases so if you (or someone else) want and have time you > could experiment with different versions and combinations as well to find the > one that's best on all CPUs. Basically we have these parts: > > 1. Change target/ppc/fpu_helper.c::helper_reset_fpstatus() to force > float_flag_inexact on in case hadfloat is enabled, I've tried two approaches > for this: > > a. In v1 added an if () in the function > b. In v2 used a variable from env set earlier (I've hoped this may be faster > but maybe it's not, testing and explanation is welcome) > > 2. Also change places where env->fp_status is copied to a local tstat and > then reset (I think this is done to accumulate flags from multiple FP ops > that would individually reset env->fp_status or some other reason, maybe this > could be avoided if we reset fp_status less often but that would need more > understanding of the FP emulation that I don't have so I did not try to clean > that up yet). > > If v2 is really slower than v1 then I'm not sure is it because also changing > places with tstat or because of the different approach in > helper_reset_fpstatus() so you could try combinations of these as well. > >> Tests were done on a Mac OS 10.4.3 VM. The CPU was set to G3. > > What was the host CPU and OS this was tested on? Please always share CPU info > and host OS when sharing bechmark results so they are somewhat comparable. It > also depends on CPU features for vector instrucions at least so without CPU > info the results could not be understood. Intel Core i5-2500S CPU @ 2.70GHz. > I think G3 does not have AltiVec/VMX so maybe testing with G4 would be better > to also test those ops unless there's a reason to only test G3. I've tested > with G4 both FPU only and FPU+VMX code on Linux host with i7-9700K CPU @ > 3.60GHz as was noted in the original cover letter but may be I'va also > forgotten some details so I list it here again. Ok, I did test on the G4, here a
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
> On Feb 23, 2020, at 12:00 PM, qemu-ppc-requ...@nongnu.org wrote: > > Message: 2 > Date: Sun, 23 Feb 2020 12:43:37 +0300 > From: Andrew Randrianasulu > To: hsp.c...@gmail.com, qemu-devel@nongnu.org, "qemu-...@nongnu.org" > > Subject: Re: [PATCH v4] Implement the Screamer sound chip for the > mac99 machine type > Message-ID: <202002231243.37654.randrianas...@gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Just thought I must share my uneducated guess on issue reported at > > https://www.emaculation.com/forum/viewtopic.php?f=34=9820 >> Please note that running with 1024Mb of memory will make sound stop working >> in Mac OS 9.x. So run with less memory. >> As will running without virtual memory. > > My guess this has something to do with device memory regions, may be because > Linux always uses Virtual memory > (MMU, address translation), as well as Mac OS X 10.x - this little issue was > unnoticed until recently ? Interesting theory. We may have to consult the 'Inside Macintosh' series under Memory management to find out how Mac OS 9 works with non-virtual memory.
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
> On Feb 23, 2020, at 9:17 AM, Howard Spoelstra wrote: > > > > 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 Thank you very much for catching this problem. Could you send me your Windows binary of QEMU that uses my patch. I would like to see if I can reproduce the problem on my computer.
Re: [PATCH v4] Implement the Screamer sound chip for the mac99 machine type
> 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 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:
Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
> On Feb 18, 2020, at 12:10 PM, BALATON Zoltan wrote: > > While other targets take advantage of using host FPU to do floating > point computations, this was disabled for PPC target because always > clearing exception flags before every FP op made it slightly slower > than emulating everyting with softfloat. To emulate some FPSCR bits, > clearing of fp_status may be necessary (unless these could be handled > e.g. using FP exceptions on host but there's no API for that in QEMU > yet) but preserving at least the inexact flag makes hardfloat usable > and faster than softfloat. Since most clients don't actually care > about this flag, we can gain some speed trading some emulation > accuracy. > > This patch implements a simple way to keep the inexact flag set for > hardfloat while still allowing to revert to softfloat for workloads > that need more accurate albeit slower emulation. (Set hardfloat > property of CPU, i.e. -cpu name,hardfloat=false for that.) There may > still be room for further improvement but this seems to increase > floating point performance. Unfortunately the softfloat case is slower > than before this patch so this patch only makes sense if the default > is also set to enable hardfloat. > > Because of the above this patch at the moment is mainly for testing > different workloads to evaluate how viable would this be in practice. > Thus, RFC and not ready for merge yet. > > Signed-off-by: BALATON Zoltan > --- > v2: use different approach to avoid needing if () in > helper_reset_fpstatus() but this does not seem to change overhead > much, also make it a single patch as adding the hardfloat option is > only a few lines; with this we can use same value at other places where > float_status is reset and maybe enable hardfloat for a few more places > for a little more performance but not too much. With this I got: Thank you for working on this. It is about time we have a better FPU. I applied your patch over David Gibson's ppc-for-5.0 branch. It applied cleanly and compiled easily. Tests were done on a Mac OS 10.4.3 VM. The CPU was set to G3. I did several tests and here are my results: With hard float: - The USB audio device does not produce any sound. - Converting a MIDI file to AAC in iTunes happens at 0.4x (faster than soft float :) ). For my FPSCR test program, 21 tests failed. The high number is because the inexact exception is being set for situations it should not be set for. With soft float: - Some sound can be heard from the USB audio device. It isn't good sounding. I had to force quit Quicktime player because it stopped working. - Converting a MIDI file to AAC in iTunes happens at 0.3x (slower than hard float). - 13 tests failed with my FPSCR test program. This patch is a good start. I'm not worried about the Floating Point Status and Control Register flags being wrong since hardly any software bothers to check them. I think more optimizations can happen by simplifying the FPU. As it is now it makes a lot of calls per operation.
Re: [PATCH v3] Implement the Screamer sound chip for the mac99 machine type
> On Feb 16, 2020, at 2:57 PM, Howard Spoelstra wrote:
>
>
>
>
> 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;
> +
Re: [PATCH v3] Implement the Screamer sound chip for the mac99 machine type
> On Feb 16, 2020, at 4:59 PM, BALATON Zoltan wrote:
>
> On Sun, 16 Feb 2020, Howard Spoelstra wrote:
>> On Sun, Feb 16, 2020 at 5:32 PM John Arbuckle
>> wrote:
>>> 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.
>>> + */
>
> Do you need a copyright and license header here? Especially if this is not
> all your original work but based on previous code (don't know if it is just
> saying in case as I know Mark also had some similar patches before but not
> sure how are those related if at all). If this contains code from somewhere
> else then license and author of that code may need to be included too.
That is a good question. According to this page https://wiki.qemu.org/License,
files that don't have licensing information default under the GNU GPL v2. I'm
fine with that.
>
>>> +/* Called when the CPU writes to the memory addresses assigned to
>>> Screamer */
>>> +static void screamer_mmio_write(void *opaque, hwaddr addr, uint64_t
>>> raw_value,
>>> +unsigned size)
>>> +{
>>> +DPRINTF("screamer_mmio_write() called - size: %d\n", size);
>>> +ScreamerState *state = opaque;
>>> +uint32_t value = raw_value & 0x;
>>> +addr = addr >> 4;
>>> +
>>> +switch (addr) {
>>> +case SOUND_CONTROL_REG:
>>> +set_sound_control_reg(state, value);
>>> +break;
>>> +case CODEC_CONTROL_REG:
>>> +set_codec_control_reg(state, value);
>>> +break;
>>> +case CODEC_STATUS_REG:
>>> +set_codec_status_reg(state, value);
>>> +break;
>>> +case CLIP_COUNT_REG:
>>> +set_clip_count_reg(state, value);
>>> +break;
>>> +case BYTE_SWAP_REG:
>>> +set_byte_swap_reg(state, value);
>>> +break;
>>> +case FRAME_COUNT_REG:
>>> +set_frame_count_reg(state, value);
>>> +break;
>>> +default:
>>> +DPRINTF("Unknown register write - addr:%llu\tvalue:%d\n", addr,
>>> value);
>>> +}
>>> +}
>>>
>>> Hi,
>>
>> This patch will not compile without errors. Host is Fedora 31.
>> The compiler suggests changing lines 839, 842 and 878 in screamer.c so the
>> DPRINTF arguments use %lu instead of %llu.
>> With that fixed, compiling completes succesfully.
>
> Replacing with %lu may fix 32bit build but would break 64bit one. Use
> HWADDR_PRIx format string instead to print hwaddr but others will probably
> tell to remove DPRINTFs alltogether when they are not needed any more and
> replace the remaining few useful ones with traces if debugging is still
> needed. I don't mind DPRINTFs that much at least until things are stable
> enough but once the code is stable most DPRINTFs may not be needed any more.
>
> I can't really review the actual patch because I don't know audio in QEMU.
>
> Regards,
> BALATON Zoltan
Your HWADDR_PRIx suggestion was great. I am making a small patch to test out
your suggestion.
Thank you.
Re: [RFC] coreaudio: fix coreaudio_test.diff
> On Jan 29, 2020, at 2: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 > I could not apply this patch using 'patch -p1 < '. I kept seeing the error malformed patch. When I applied the patch by hand QEMU was able to play sound normally again. Thank you :) I used qemu-system-i386 at git commit adcd6e93b9519f7fe421d543e3aa646895b32e1a to test this patch. Both the AC97 and SB16 sound cards with Windows XP and Windows NT 4.0 respectively. Only the ES1370 sound card used with Windows 2000 failed to play anything. This is probably a problem with it and not your patch. Reviewed-by: John Arbuckle
Re: [PATCH v2] Implement the Screamer sound chip for the mac99 machine type
> On Jan 10, 2020, at 7:32 PM, Zoltán Kővágó wrote: > > On 2020-01-05 02:58, Programmingkid wrote: >> I found the patch that breaks Screamer sound support for qemu-system-ppc. It >> is this: >> commit 2ceb8240fa4e4e30fb853565eb2bed3032d74f62 >> Author: Kővágó, Zoltán >> Date: Thu Sep 19 23:24:11 2019 +0200 >> coreaudio: port to the new audio backend api >> Signed-off-by: Kővágó, Zoltán >> Message-id: >> 586a1e66de5cbc6c5234f9ae556d24befb6afada.1568927990.git.dirty.ice...@gmail.com >> Signed-off-by: Gerd Hoffmann >> Reversing this patch should make the Screamer patch work with the current >> git version of QEMU. > > 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 > > Sorry it did not fix the problem. I only hear pops occasionally. Most of the time only silence can be heard. Thank you for the patch.
Re: [PATCH v2] Implement the Screamer sound chip for the mac99 machine type
> On Jan 4, 2020, at 8:58 PM, Programmingkid wrote: > > I found the patch that breaks Screamer sound support for qemu-system-ppc. It > is this: > > commit 2ceb8240fa4e4e30fb853565eb2bed3032d74f62 > Author: Kővágó, Zoltán > Date: Thu Sep 19 23:24:11 2019 +0200 > >coreaudio: port to the new audio backend api > >Signed-off-by: Kővágó, Zoltán >Message-id: > 586a1e66de5cbc6c5234f9ae556d24befb6afada.1568927990.git.dirty.ice...@gmail.com >Signed-off-by: Gerd Hoffmann > > > Reversing this patch should make the Screamer patch work with the current git > version of QEMU. @Peter Maydell Does QEMU play audio correctly on your version of Mac OS X? I am using Mac OS 10.12 and the audio sound demonically loud and scary. I am currently at this git revision: f0dcfddecee8b860e015bb07d67cfcbdfbfd51d Merge: 40f09ee833 725fe5d10d Author: Peter Maydell Date: Fri Jan 3 17:18:08 2020 + Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging I have ran several tests with qemu-system-i386 using Windows guest with the ac97 and sb16 sound cards. It sounds just as bad for me on qemu-system-ppc. Thank you.
Re: [PATCH v2] Implement the Screamer sound chip for the mac99 machine type
I found the patch that breaks Screamer sound support for qemu-system-ppc. It is this: commit 2ceb8240fa4e4e30fb853565eb2bed3032d74f62 Author: Kővágó, Zoltán Date: Thu Sep 19 23:24:11 2019 +0200 coreaudio: port to the new audio backend api Signed-off-by: Kővágó, Zoltán Message-id: 586a1e66de5cbc6c5234f9ae556d24befb6afada.1568927990.git.dirty.ice...@gmail.com Signed-off-by: Gerd Hoffmann Reversing this patch should make the Screamer patch work with the current git version of QEMU.
Re: [Bug 1850570] Re: Cannot use usb-host on Mac OS
> 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?
