Minor tweak to wiki Linux build instructions.
On https://wiki.qemu.org/Hosts/Linux the list of recommended packages currently is a mix of RedHat and Debian names. I suggest the following instead: Recommended additional packages Package names are for Debian(RedHat).* git-email, used for sending patches* libsdl2-dev(libsdl2-devel), needed for the SDL based graphical user interface* libgtk-3-dev(gtk3-devel), for a simple UI instead of VNC* libvte-dev(vte-devel), for access to QEMU monitor and serial/console devices via the GTK interface* libcapstone-dev(libcapsone-devel), for disassembling CPU instructions
Re: [RFC PATCH] mailmap/gitdm: more fixes for bad tags and authors
>Alex Bennée writes: > I was running some historical tags for the last 10 years and got the > following warnings: > > git log --use-mailmap --numstat --since "June 2010" | ~/src/gitdm.git/gitdm > -n -l 5 > alar...@ddci.com is an author name, probably not what you want > ... > The following fixes try and alleviate that although I still get a > warning for Aaron which I think is from 9743cd5736. Alex, I'm not sure what I can do to help, but my email address hasn't changed, still works, and I lack any sort of accent (just ask me :-).
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Mark Cave-Ayland" wrote on 04/06/2018 09:14:14 AM: > From: "Mark Cave-Ayland" > To: alar...@ddci.com, "Peter Maydell" > Cc: "Stefan Weil" , "QEMU Developers" > Date: 04/06/2018 09:14 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 06/04/18 14:28, alar...@ddci.com wrote: > > > I was not successful with the wiki instructions for "Native builds > > with MSYS2": > > > >./qemu-2.12.0-rc2/configure --python=/usr/bin/python2 \ > >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >--prefix=/usr/local/qemu \ > >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' > >make > >... > >C:\msys2-x86_64_20161025\msys64\mingw64\bin\ar.exe: creating > > libfdt/libfdt.a > >make[1]: *** No rule to make target ...build/capstone/capstone.lib'. > > Stop. > >make: *** [Makefile:503: subdir-capstone] Error 2 > > Ah I believe those instructions were mine from when I had temporary > access to a Windows VM for testing last year. > > Since the instructions pre-dated the inclusion of capstone as a > dependency, is it as simple as adding: > > git submodule update --init capstone > > before running configure and make? I didn't do the "git" parts. I extracted from the source tarball. Is the tarball source supposed to work, or is it necessary to always use git?
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 12:21:37 PM: > On 6 April 2018 at 18:06, wrote: > > > > FWIW, the compile had some anomalous behavior: > > > > .../qemu-2.12.0-rc2/scripts/feature_to_c.sh: line 71: /usr/bin/sed: > > Invalid argument > > > > line 71 is: > > arrayname=xml_feature_$(echo $input | sed 's,.*/,,; s/[-.]/_/g') > > > > Not sure what the problem is, but I always use "-e" before scripts. > > That's a bit odd. (POSIX allows both "-e script" and just "script".) > What version of sed is this, and what version of /bin/sh ? I don't know what the issue is. When I execute that command from my normal bash shell, it works just fine. This is current Cygwin, so: qemu$ sed --version sed (GNU sed) 4.4 Packaged by Cygwin (4.4-1) ... qemu$ /bin/sh --version GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) ... Perhaps I misread the sed manual, but I thought when you used a character other than "/", you had to preface the character with a backslash, e.g., sed 's\,.*,,;' But, the above is all just speculation. I don't know what the real problem is. FWIW, I rebuilt twice more and the error didn't show up again, but I did get some other spurious errors, one from GCC "invalid argument" and another: /bin/sh: /usr/bin/x86_64-w64-mingw32-gcc: Device or resource busy make: *** [/cygdrive/c/scm/Deos/products/qemu/branches/2.12/output/qemu-2.12.0-rc2/rules.mak:66: stubs/notify-event.o] Error 126 So perhaps it is just normal Cygwin "fork" errors, or my use of "make -j8". I think you can ignore this. Sorry for the spam.
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 09:51:55
AM:
> I've now done this, and can reproduce the problem. So the
> issue is generic to 32-bit hosts.
Supporting evidence: I compiled Cygwin/MINGW with x86_64 and the
resulting binaries work properly
FWIW, the compile had some anomalous behavior:
.../qemu-2.12.0-rc2/scripts/feature_to_c.sh: line 71: /usr/bin/sed:
Invalid argument
line 71 is:
arrayname=xml_feature_$(echo $input | sed 's,.*/,,; s/[-.]/_/g')
Not sure what the problem is, but I always use "-e" before scripts.
Later the make failed with the following error:
> gdbstub-xml.c:695:28: error: ‘xml_feature_’ undeclared here (not in a
function)
> { "i386-64bit-core.xml", xml_feature_ },
^~~~
> gdbstub-xml.c:61:19: warning: ‘xml_feature_i386_64bit_core_xml’ defined
but not used [-Wunused-const-variable=]
> static const char xml_feature_i386_64bit_core_xml[] = {
>^~~
> make[1]: ***
[/cygdrive/c/scm/Deos/products/qemu/branches/2.12/output/qemu-2.12.0-rc2/rules.mak:66:
gdbstub-xml.o] Error 1
> make: *** [Makefile:478: subdir-x86_64-softmmu] Error 2
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/06/2018 04:41:01 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" , "Stefan Weil" > Date: 04/06/2018 04:41 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 5 April 2018 at 22:23, wrote: > > "Peter Maydell" wrote on 04/05/2018 12:28:01 > > PM: > > > >> From: "Peter Maydell" > >> To: alar...@ddci.com > >> Cc: "QEMU Developers" > >> Date: 04/05/2018 12:28 PM > >> Subject: Re: [Qemu-devel] -icount changes physical address assignments > > in QEMU 2.10/2.11 > >> > >> On 5 April 2018 at 17:44, wrote: > >> > "Peter Maydell" wrote on 04/05/2018 > > 09:05:53 > >> > AM: > >> >> I've just tried your attached test image ... > >> > > >> > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > >> > Cygwin (a version from about a month ago) using mingw compilers > >> > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the > >> > resulting QEMU binary is run using -icount 2 against my test binary, > >> > but not when run without -icount. Here are the commands used: > >> > > >> > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ > >> >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >> >--prefix=/usr/local/qemu \ > >> >--enable-sdl --with-sdlabi=2.0 \ > >> >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > >> >--cross-prefix=i686-w64-mingw32- > >> > /usr/bin/make -Otarget -j 8 > >> > > >> > Any suggestions of things to try? > >> > >> Can you reproduce the problem on a Linux host? It would > >> be interesting to identify if this is a Windows-host > >> specific issue somehow. > > > > Linux "works". I installed ubuntu 17.10 in a VM on my windows box, > > recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure > > line the same as above except omitting --cross-prefix and --with-sdlabi. > > Both with "-icount 2" and without show expected results. > > > > I installed a fresh Cygwin with just the packages suggested at > > https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus > > some obviously missing ones like python, make, etc.) and the problem > > persists. The updated configure line is: > > > > ../qemu-2.12.0-rc2/configure \ > > '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > > --prefix=/usr/local/qemu \ > > '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > > --cross-prefix=i686-w64-mingw32- > > Hmm, if it's Windows-only that's unfortunate, since I'm not really > in a position to debug things that only happon on Windows hosts. > > Stefan, does this sort of bug sound familiar at all? > > Looking at your --cross-prefix you seem to be building 32-bit > binaries; was your Ubuntu VM 32 bit or 64 bit? I'm wondering > if this might turn out to be a 32-bit host issue rather than > necessarily a Windows one. 1. Ubuntu 17.10 is 64-bit, compilation was native, run on the compilation host. I.e., I did not cross compile to windows. 2. Cygwin was a 64-bit install, 64-bit windows 7 host. I followed the instructions on the wiki. I was curious about the "ming32" part myself, but cygwin package search doesn't indicate an obvious (to me) replacement. I was not successful with the wiki instructions for "Native builds with MSYS2": ./qemu-2.12.0-rc2/configure --python=/usr/bin/python2 \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' make ... C:\msys2-x86_64_20161025\msys64\mingw64\bin\ar.exe: creating libfdt/libfdt.a make[1]: *** No rule to make target ...build/capstone/capstone.lib'. Stop. make: *** [Makefile:503: subdir-capstone] Error 2
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/05/2018 12:28:01 PM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 12:28 PM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 5 April 2018 at 17:44, wrote: > > "Peter Maydell" wrote on 04/05/2018 09:05:53 > > AM: > >> I've just tried your attached test image ... > > > > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > > Cygwin (a version from about a month ago) using mingw compilers > > (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the > > resulting QEMU binary is run using -icount 2 against my test binary, > > but not when run without -icount. Here are the commands used: > > > > ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ > >'--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ > >--prefix=/usr/local/qemu \ > >--enable-sdl --with-sdlabi=2.0 \ > >'--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ > >--cross-prefix=i686-w64-mingw32- > > /usr/bin/make -Otarget -j 8 > > > > Any suggestions of things to try? > > Can you reproduce the problem on a Linux host? It would > be interesting to identify if this is a Windows-host > specific issue somehow. Linux "works". I installed ubuntu 17.10 in a VM on my windows box, recompiled QEMU 2.12.0-rc2 (same sources as above), using a configure line the same as above except omitting --cross-prefix and --with-sdlabi. Both with "-icount 2" and without show expected results. I installed a fresh Cygwin with just the packages suggested at https://wiki.qemu.org/Hosts/W32#Native_builds_with_Mingw-w64 (plus some obviously missing ones like python, make, etc.) and the problem persists. The updated configure line is: ../qemu-2.12.0-rc2/configure \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ --cross-prefix=i686-w64-mingw32-
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 04/05/2018 09:05:53 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 09:06 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 22 March 2018 at 05:31, wrote: > > Your patch (applied to 2.11 source release) changed the behavior > > somewhat, but did not fix the problem. Attached is a binary that when > > run should show a CGA fontset and color bars. > > > > This command should "work": > > > > qemu-system-aarch64 -M virt,virtualization=on -cpu cortex-a53 -vga std > > -device secondary-vga -device virtio-net,netdev=vlan0,addr=2 -kernel > > icount-bug.bin -netdev user,id=vlan0 > > > > If you add "-icount 2" the display will appear, but be mangled. > > > > I didn't spend too much time trimming the source code, so if you need > > to step by step debug walking through the guest code, I'll have to > > prune it down some more. > > > > For the record, the QEMU source I have is modified slightly to add ARM WFE > > support, something I will submit once this is all straightened out, > > but this bug appeared before I made that patch. > > Hi; sorry for the delay in testing this. I've just tried your > attached test image with current head of git QEMU (commit > 0e87fdc966d05f4e5ad86, which is the 2.12.0-rc2 release candidate), > and it gives me a correct display both with and without -icount 2. > So I think we've fixed this bug, probably with the combination > of commits 0790f86861079b19 and 87f963be66a3245, or possibly > a75a52d62418da. > > thanks > -- PMM Thank you for your help. > I've just tried your attached test image ... Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using Cygwin (a version from about a month ago) using mingw compilers (mingw64-i686-gcc-g++ 6.4.0), and I still see the issue when the resulting QEMU binary is run using -icount 2 against my test binary, but not when run without -icount. Here are the commands used: ../qemu-2.12.0-rc2/configure --python=/usr/bin/python \ '--with-pkgversion=DDCI QEMU 2.12.0-rc2' \ --prefix=/usr/local/qemu \ --enable-sdl --with-sdlabi=2.0 \ '--target-list=aarch64-softmmu ppc64-softmmu x86_64-softmmu' \ --cross-prefix=i686-w64-mingw32- /usr/bin/make -Otarget -j 8 Any suggestions of things to try? If you think this is a build environment issue, I can try MSYS and report my results.
Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
"Peter Maydell" wrote on 03/15/2018 11:55:19 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 03/15/2018 11:55 AM > Subject: Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11 > > On 23 February 2018 at 00:39, wrote: > > When porting our RTOS from QEMU 2.8 to 2.10/2.11, I ran into a problem > > where 16-bit writes to the "bochs dispi interface" were being reported > > differently depending on whether or not "-icount" was given to QEMU. > > > > For example, info mtree: > > ... > > 11000500-11000515 (prio 0, i/o): bochs dispi interface > > > > A 16-bit write to 0x11000500 was delivered to pci_vga_bochs_write() as > > having > > address 0, when -icount was not specified, but as address 2 when > > -icount was specified. Correspondingly writes to 0x11000502 were 2 > > and 0 respectively. Essentially the words were swapped depending on > > the presence of -icount. > > > > I suspect a similar problem for the AARCH64 GIC (generic interrupt > > controller), but other than observing the GIC changing from working to > > non-working depending on the absence/presence of -icount I haven't > > confirmed the underlying cause. > > > > 2.10 and 2.11 were built from source on Cygwin using mingw, 2.8 from a > > "native" MinGW. The results are consistent for 2.10 and 2.11. 2.8 > > does not have the -icount dependency. The "broken" command line was: > > > > qemu-system-aarch64 -m 1077 -name "arm" -M virt,virtualization=on > > -cpu cortex-a53 -icount align=off,shift=0,sleep=on > > -vga std -device secondary-vga > > -device > > virtio-net,netdev=vlan0,addr=2,disable-modern=false,mac=52:54:00:12:67:56 > > -kernel ...deosBoot.bin -initrd "deosBoot.qemu" -netdev > > tap,id=vlan0,ifname="DDCI-tap0" > > > > The "working" command line omitted -icount and its argument. > > > > FWIW, the error from the GIC with -icount was: > > > > qemu: fatal: IO on conditional branch instruction > > > > Any pointers? > > Can you try with this patch applied? > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06595.html > (that will go into git master within the next week or so but isn't > yet applied; it does fix at least some -icount related problems). > > If that doesn't help, can you provide a demonstration test > binary that I can use to reproduce the bug? > > thanks > -- PMM Peter, thanks for the patch, and sorry for the long delay getting back to you. I was on extended travel. Your patch (applied to 2.11 source release) changed the behavior somewhat, but did not fix the problem. Attached is a binary that when run should show a CGA fontset and color bars. This command should "work": qemu-system-aarch64 -M virt,virtualization=on -cpu cortex-a53 -vga std -device secondary-vga -device virtio-net,netdev=vlan0,addr=2 -kernel icount-bug.bin -netdev user,id=vlan0 If you add "-icount 2" the display will appear, but be mangled. I didn't spend too much time trimming the source code, so if you need to step by step debug walking through the guest code, I'll have to prune it down some more. For the record, the QEMU source I have is modified slightly to add ARM WFE support, something I will submit once this is all straightened out, but this bug appeared before I made that patch. If you need me to update sources to head, or to 2.12 and re-apply your patch I can do that. md5sum: f4626a1b8edb0d64cba14fe3b43e3357 *icount-bug.bin icount-bug.bin Description: Binary data
[Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11
When porting our RTOS from QEMU 2.8 to 2.10/2.11, I ran into a problem where 16-bit writes to the "bochs dispi interface" were being reported differently depending on whether or not "-icount" was given to QEMU. For example, info mtree: ... 11000500-11000515 (prio 0, i/o): bochs dispi interface A 16-bit write to 0x11000500 was delivered to pci_vga_bochs_write() as having address 0, when -icount was not specified, but as address 2 when -icount was specified. Correspondingly writes to 0x11000502 were 2 and 0 respectively. Essentially the words were swapped depending on the presence of -icount. I suspect a similar problem for the AARCH64 GIC (generic interrupt controller), but other than observing the GIC changing from working to non-working depending on the absence/presence of -icount I haven't confirmed the underlying cause. 2.10 and 2.11 were built from source on Cygwin using mingw, 2.8 from a "native" MinGW. The results are consistent for 2.10 and 2.11. 2.8 does not have the -icount dependency. The "broken" command line was: qemu-system-aarch64 -m 1077 -name "arm" -M virt,virtualization=on -cpu cortex-a53 -icount align=off,shift=0,sleep=on -vga std -device secondary-vga -device virtio-net,netdev=vlan0,addr=2,disable-modern=false,mac=52:54:00:12:67:56 -kernel ...deosBoot.bin -initrd "deosBoot.qemu" -netdev tap,id=vlan0,ifname="DDCI-tap0" The "working" command line omitted -icount and its argument. FWIW, the error from the GIC with -icount was: qemu: fatal: IO on conditional branch instruction Any pointers?
Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts
David Gibson wrote on 06/18/2017 04:04:48 AM: > On Fri, Jun 16, 2017 at 11:31:02AM -0500, alar...@ddci.com wrote: > > I haven't received any feedback on this patch, ... Did it get lost? > > No, I've just been busy and then sick. I'll get to it eventually.. As always, thanks for your efforts. You have been so responsive in the past I figured something was up. I hope you're feeling better. If karma is any consolation, I was just going through my QEMU "todo" list and found that I neglected to submit a follow up patch to an email conversation from last July. Ouch. I'll get that in the mail ASAP. http://lists.nongnu.org/archive/html/qemu-ppc/2016-07/msg00916.html
Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts
G 3 wrote on 06/18/2017 03:38:29 PM: > > From: Aaron Larson > > Date: 06/05/2017 12:22 PM > > Subject: [PATCH v3] target-ppc: Enable open-pic timers to count > > and generate interrupts > > > > Previously QEMU open-pic implemented the 4 open-pic timers > > including all timer registers, but the timers did not "count" > > or generate any interrupts. The patch makes the timers both > > count and generate interrupts. The timer clock frequency is > > fixed at 25MHZ. > > > > G3> Does QEMU behave differently after this patch is implemented? > > > > If the open-pic timers are programmed, then QEMU behaves > > differently, otherwise there should be no difference. > > I guess I should have asked what differences did you see in QEMU's > behavior? In the past, the open-pic timers were, effectively, unimplemented. They allowed a write to the timer registers, e.g., to enable a counter, but the counter never "counted", instead just returning whatever was most recently programmed. Now the timers are, well, timers. Given the previous implementation, it was highly unlikely any software running on QEMU actually used the timers, so in general I would expect there would be no difference at all.
Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts
G 3 wrote on 06/18/2017 09:45:25 AM: > >>> From: Aaron Larson > >>> To: ag...@suse.de, alar...@ddci.com, da...@gibson.dropbear.id.au, > >> qemu-devel@nongnu.org, qemu-...@nongnu.org > >>> Date: 06/05/2017 12:22 PM > >>> Subject: [PATCH v3] target-ppc: Enable open-pic timers to count and > >> generate interrupts > >>> > >>> Previously QEMU open-pic implemented the 4 open-pic timers including > >>> all timer registers, but the timers did not "count" or generate any > >>> interrupts. The patch makes the timers both count and generate > >>> interrupts. The timer clock frequency is fixed at 25MHZ. G3> Does QEMU behave differently after this patch is implemented? If the open-pic timers are programmed, then QEMU behaves differently, otherwise there should be no difference.
Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts
Aaron Larson wrote on 06/05/2017 12:22:53 PM: > From: Aaron Larson > To: ag...@suse.de, alar...@ddci.com, da...@gibson.dropbear.id.au, qemu-devel@nongnu.org, qemu-...@nongnu.org > Date: 06/05/2017 12:22 PM > Subject: [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts > > Previously QEMU open-pic implemented the 4 open-pic timers including > all timer registers, but the timers did not "count" or generate any > interrupts. The patch makes the timers both count and generate > interrupts. The timer clock frequency is fixed at 25MHZ. > > -- > > Responding to V2 patch comments. > - Simplify clock frequency logic and commentary. > - Remove camelCase variables. > - Timer objects now created at init rather than lazily. > > Signed-off-by: Aaron Larson I haven't received any feedback on this patch, and I don't see a response on the mailing list archive. Did it get lost?
Re: [Qemu-devel] [PATCH] target-ppc: Fix openpic timer read register offset
David Gibson wrote on 06/04/2017 07:55:34 PM: > From: David Gibson > To: Aaron Larson > Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org > Date: 06/04/2017 07:55 PM > Subject: Re: [PATCH] target-ppc: Fix openpic timer read register offset > > On Fri, Jun 02, 2017 at 04:32:59AM -0700, Aaron Larson wrote: > > > > openpic_tmr_read() is incorrectly computing register offset of the > > TCCR, TBCR, TVPR, and TDR registers when accessing the open pic timer > > registers. ... > > Applied to ppc-for-2.10. It looks saner than the existing code, but I > don't know openpic well enough to really review it; so I'm trusting > you on that. Thanks David, I'll have an updated timer patch out later today for the timer that actually times. I'm reasonably sure the resulting code is correct because we have the same binary working on real hardware and on QEMU.
Re: [Qemu-devel] [PATCH v2] target-ppc: Enable open-pic timers to count and generate interrupts
David Gibson wrote on 05/13/2017 02:59:16
AM:
> From: David Gibson
> On Fri, May 12, 2017 at 09:34:33AM -0500, alar...@ddci.com wrote:
> > David Gibson wrote on 05/12/2017
01:52:04
Sorry for the long delay getting back to you. I was out of town for a
while.
> > > > +}
> > > > +uint64_t ns = ticks_to_ns(val & ~TCCR_TOG);
> > > > +/* A count of zero causes a timer to be set to expire
> > immediately. This
> > > > + effectively stops the simulation so we don't honor that
> > configuration.
> > > > + On real hardware, this would generate an interrupt on
every
> > clock cycle
> > > > + if the interrupt was unmasked. */
> > >
> > > Could you also jam up if the count is non-zero but a too-small value
> > > to make forward progress? ...
> >
> > The case I'm concerned about is where a transient value is programmed
> > to the timer and the interrupt is masked. In that case QEMU will fire
> > the timer on (potentially) every other clock,
>
> Erm.. TCG doesn't really have "clocks" as such, so I'm not entirely
> sure what you mean here.
Hopefully its just terminology. QEMU has QEMU_CLOCK_VIRTUAL which
drives a timer. My understanding is that the top level loop in QEMU
is effectively:
while 1
if timer expired then run the handler
else execute some simulated code
If a QEMU timer handler reprograms the timer to expire at "now+0ns",
then no code is ever executed because the VIRTUAL CLOCK timer is
always pending. This is not exactly the same as what would happen on
real hardware because on hardware the interrupt would be asserted, but
if it was masked it would have no effect. In the simulation such a
situation effectively results in a "hang".
> > > > static void openpic_tmr_write(void *opaque, hwaddr addr, uint64_t
> > > > ...
> > > > -if (addr == 0x10f0) {
> > > > +if (addr == 0) {
> > >
> > > I don't really understand how this change fits in with the rest - it
> > > appears to be changing existing unrelated behaviour.
> >
> > I debated on changing this. I needed to make changes to both the
> > timer read and write code, and the existing code was inconsistent on
> > the treatment of the offset. The open-pic has a standard memory map
> > and the timer block starts at 0x10f0 from the BAR. Of course the
> > region in QEMU for the timer is setup such that the timer is at offset
> > zero in the QEMU timer memory region. The write code added the offset
> > to match the hardware, the read code did not, and consequently the
> > code I added for timer read and write needed to be gratuitously
> > different because of that. I chose to update the write to match the
> > read. I can undo the change, if you'd like, but it does make the
> > resulting code harder to understand (IMHO).
>
> So, making the read/write functions use consistent addressing sounds
> like a good idea. But I think it would be clearer to do this as a
> preliminary patch, rather than folded in with adding the timers
> implementation.
Will do. Patch to follow shortly. I assume that once the preliminary
patch is approved, I should submit a follow up patch with the addition
of the timer. BTW, I forgot to mention that the previous timer read
code was not only inconsistent, but was in error. Bad enough in error
that I doubt anyone could have been using the code.
Re: [Qemu-devel] [PATCH v2] target-ppc: Enable open-pic timers to count and generate interrupts
David Gibson wrote on 05/12/2017 01:52:04
AM:
> From: David Gibson
> To: Aaron Larson
> Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org
> Date: 05/12/2017 01:52 AM
> Subject: Re: [PATCH v2] target-ppc: Enable open-pic timers to count and
generate interrupts
>
> On Tue, May 02, 2017 at 07:57:22PM -0700, Aaron Larson wrote:
> >
> > Previous QEMU open-pic implemented the 4 open-pic timers including all
> > timer registers, but the timers did not "count" or generate any
> > interrupts. The patch makes the timers both count and generate
> > interrupts. The timer clock frequency is fixed at 100MHZ.
> >
> > Signed-off-by: Aaron Larson
>
> Looks sound in concept AFAICT not knowing the openpic hardware.
Thanks again for your review. I will provide an updated patch to
address all of the comments, but I need a bit more guidance on some.
> > ---
> > hw/intc/openpic.c | 135
++
> > 1 file changed, 117 insertions(+), 18 deletions(-)
> >
> > +/* If enabled is true, arranges for an interrupt to be raised val
clocks into
> > + the future, if enabled is false cancels the timer. */
> > +static void openpic_tmr_set_tmr(OpenPICTimer *tmr, uint32_t val, bool
enabled)
> > +{
> > +/* If timer doesn't exist, create it. */
> > +if (tmr->qemu_timer == NULL) {
> > +tmr->qemu_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
&qemu_timer_cb, tmr);
> > +DPRINTF("Created timer for n_IRQ %d\n", tmr->n_IRQ);
>
> Is there a reason to lazily create the timer, rather than always
> creating it at init time and just activating it when the timer is set?
I'm not familiar with the QEMU timer code so guidance is appreciated,
but a quick check indicates there wouldn't be much overhead to do as
you suggest. I will change to that approach.
> > +}
> > +uint64_t ns = ticks_to_ns(val & ~TCCR_TOG);
> > +/* A count of zero causes a timer to be set to expire
immediately. This
> > + effectively stops the simulation so we don't honor that
configuration.
> > + On real hardware, this would generate an interrupt on every
clock cycle
> > + if the interrupt was unmasked. */
>
> Could you also jam up if the count is non-zero but a too-small value
> to make forward progress? ...
The case I'm concerned about is where a transient value is programmed
to the timer and the interrupt is masked. In that case QEMU will fire
the timer on (potentially) every other clock, which will slow the
emulation down until a more sane value is programmed. I could add
code to inhibit the timer while the associated interrupt is masked,
but that is messy, and this seems like an unlikely corner case.
Let me know how you'd like this handled.
> > static void openpic_tmr_write(void *opaque, hwaddr addr, uint64_t
val,
> > -unsigned len)
> > + unsigned len)
> > {
> > OpenPICState *opp = opaque;
> > int idx;
> >
> > -addr += 0x10f0;
> > -
> > DPRINTF("%s: addr %#" HWADDR_PRIx " <= %08" PRIx64 "\n",
> > -__func__, addr, val);
> > +__func__, (addr + 0x10f0), val);
> > if (addr & 0xF) {
> > return;
> > }
> >
> > -if (addr == 0x10f0) {
> > +if (addr == 0) {
>
> I don't really understand how this change fits in with the rest - it
> appears to be changing existing unrelated behaviour.
I debated on changing this. I needed to make changes to both the
timer read and write code, and the existing code was inconsistent on
the treatment of the offset. The open-pic has a standard memory map
and the timer block starts at 0x10f0 from the BAR. Of course the
region in QEMU for the timer is setup such that the timer is at offset
zero in the QEMU timer memory region. The write code added the offset
to match the hardware, the read code did not, and consequently the
code I added for timer read and write needed to be gratuitously
different because of that. I chose to update the write to match the
read. I can undo the change, if you'd like, but it does make the
resulting code harder to understand (IMHO).
Re: [Qemu-devel] Subject: [PATCH] target-ppc: Add global timer group A to open-pic.
David Gibson wrote on 04/25/2017 11:34:41 PM: Thanks for the review David. I'll send an updated patch soon with all your comments addressed and all other s/0/NULL or false/ as appropriate and a better commit message. Just to clarify my concern; the patch causes the QEMU openpic timer to be hard coded at 100MHZ. This is common, but the openpic spec has numerous ways the clock could be driven and the actual frequency depends on target board configuration. Given that no other users are apparently using the QEMU openpic timer, it is probably ok, but I did want to point out the deficiency.
Re: [Qemu-devel] Subject: [PATCH] target-ppc: Add global timer group A to open-pic.
David Gibson wrote on 04/23/2017 06:17:22 PM: > From: David Gibson > To: Aaron Larson > Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org > Date: 04/23/2017 06:54 PM > Subject: Re: Subject: [PATCH] target-ppc: Add global timer group A to open-pic. > > On Fri, Apr 21, 2017 at 02:58:23PM -0700, Aaron Larson wrote: > > Add global timer group A to open-pic. This patch is still somewhat > > dubious because I'm not sure how to determine what QEMU wants for the > > timer frequency. Suggestions solicited. > > This commit message really needs some more context. What's a "global > time group A" a and why do we want it? The open-pic spec includes two sets/groups of timers, groups A and B, 4 timers in each group. Previously in QEMU the timer group A registers were implemented but they did not "count" or generate any interrupts. The patch makes the timers to do both (count and generate interrupts). About a year ago I mentioned that we had implemented this and offered to submit a patch, which seemed to be acceptable. Sadly, when I reviewed the implementation it had several egregious errors that I didn't know how to fix until recently. Quite frankly I didn't expect the patch to be accepted in its current form for the reason mentioned in the above commit log and was hoping for some guidance. If this is no longer a desirable patch, I can certainly continue to maintain it locally for our use.\ Aaron.
Re: [Qemu-devel] Subject: [PATCH] target-ppc: Add global timer group A to open-pic.
no-re...@patchew.org wrote on 04/21/2017 04:52:20 PM: > This series failed build test on s390x host. Please find the details below. Sorry about that. I was working my way through checkpatch.pl output and lost an intermediate change.
Re: [Qemu-devel] target-ppc: SPR_BOOKE_ESR not set on FP exceptions
David Gibson wrote on 07/29/2016 12:40:15 AM: > From: David Gibson > To: alar...@ddci.com > Cc: qemu-devel@nongnu.org, qemu-...@nongnu.org, ag...@suse.de > Date: 07/29/2016 12:38 AM > Subject: Re: target-ppc: SPR_BOOKE_ESR not set on FP exceptions > > On Thu, Jul 28, 2016 at 06:32:27PM -0500, alar...@ddci.com wrote: ... > > I did a quick check of the bits set in the POWERPC_EXCP_PROGRAM case. > > The classic PPC sets SRR1 bits 11--15 depending on the exception. In > > Book E these correspond to bits 43--47, > > Um.. what? I'm not understanding where this bit shift is coming > from. Sorry, I was looking at an old "classic" 32-bit manual for the SRR1 exception definition and a 64-bit manual for the BookE. They are the same bits. MSB0 bit numbering bytes again :-)
[Qemu-devel] target-ppc: SPR_BOOKE_ESR not set on FP exceptions
The target-ppc/excp_helper.c:powerpc_excp() case POWERPC_EXCP_FP fails
to set "env->spr[SPR_BOOKE_ESR] = ESR_FP;". I can submit a patch for
that, or anyone can add it, but I notice that in the other cases where
SPR_BOOKE_ESR is set, the "msr" is ALSO set. Since the "msr" is used
to initialize SRR1, there is a possibility of inadvertently enabling
BookE MSR bits indirectly. Given that this code is not performance
sensitive, I think it would be safer to set EITHER msr or the ESR, but
not BOTH. For example:
if (excp_model == POWERPC_EXCP_BOOKE)
env->spr[SPR_BOOKE_ESR] = ESR_FP;
else
msr |= 0x0010;
I did a quick check of the bits set in the POWERPC_EXCP_PROGRAM case.
The classic PPC sets SRR1 bits 11--15 depending on the exception. In
Book E these correspond to bits 43--47, of which (according to my
EREF) only 45 and 46 are currently defined. BookE MSR bits 45 (Wait
state enable) and 46 (Critical Enable) correspond to classic SRR1 bits
13 (exception is TRAP) and 14 ("SRR0 is not faulting instruction").
If I understand the current code, given this aliasing then when a TRAP
exception occurs on a book E processor it will effectively enable wait
state, and an FP exception (which sets bit 14/46) will set "Critical
Enable". I'm not sure that either of these features is currently
implemented so this may not have a downstream effect, but never the
less it seems incorrect.
I can submit a patch for the ESR_FP, and/or a change to have the
"either or but not both" settings of MSR and ESR. Please let me know
which you'd prefer.
Re: [Qemu-devel] [PATCH v2] target-ppc: Eliminate redundant and incorrect function booke206_page_size_to_tlb
David Gibson wrote on 06/28/2016 08:42:01 PM: > On Tue, Jun 28, 2016 at 06:50:05AM -0700, Aaron Larson wrote: > > > > Eliminate redundant and incorrect booke206_page_size_to_tlb function > > from ppce500_spin.c in preference to previously existing but newly > > exported definition from e500.c > > ... > > Signed-off-by: Aaron Larson > > Applied to pppc-for-2.7, thanks. I had previously created a bug for this at: https://bugs.launchpad.net/qemu/+bug/1587535 Do you want me to do anything with that bug?
Re: [Qemu-devel] [PATCH] target-ppc: Eliminate redundant and incorrect function booke206_page_size_to_tlb
David Gibson wrote on 06/27/2016 12:32:13 AM: > From: David Gibson > To: alar...@ddci.com > Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org > Date: 06/27/2016 12:30 AM > Subject: Re: [PATCH] target-ppc: Eliminate redundant and incorrect function booke206_page_size_to_tlb > > On Sun, Jun 26, 2016 at 09:38:03PM -0500, alar...@ddci.com wrote: > > David Gibson wrote on 06/26/2016 08:36:52 > > PM: > > > > > From: David Gibson > > > To: Aaron Larson > > > Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org > > > Date: 06/26/2016 08:58 PM > > > Subject: Re: [PATCH] target-ppc: Eliminate redundant and incorrect > > function booke206_page_size_to_tlb > > > > > > On Fri, Jun 24, 2016 at 12:11:00PM -0700, Aaron Larson wrote: > > > > > > > > Eliminate redundant and incorrect booke206_page_size_to_tlb function > > > > from ppce500_spin.c in preference to previously existing but newly > > > > exported definition from e500.c > > > > > > > > Signed-off-by: Aaron Larson > > > > > > Uh.. sorry.. can you provide a reference explaining why the removed > > > version is wrong? Doesn't this depend on which MMU Architecture > > > Version we're emulating? > > > > Sure, the code is internally inconsistent (shift assumed didn't match > > shift defined). I will provide an update commit message, similar to the > > original posting I made a few days ago with the "direction" > > corrected. > > Right, I can see that the two old versions were different, which was > clearly wrong. What I'm looking for is an explanation of why the one > you've picked is the right one, not the other one. How's this? Eliminate redundant and incorrect booke206_page_size_to_tlb function from ppce500_spin.c in preference to previously existing but newly exported definition from e500.c The booke206_page_size_to_tlb function in e500.c was updated in commit 2bd9543cd303d9f6cbd37b7466bb03543035156b to reflect a change in the definition of MAS1_TSIZE_SHIFT from 8 (corresponding to a min TLB page size of 4kb) to a value of 7 (TLB page size 2k). The booke206_page_size_to_tlb() function defined in ppce500_spin.c was never updated to reflect the change in MAS1_TSIZE_SHIFT. In http://lists.nongnu.org/archive/html/qemu-ppc/2016-06/msg00533.html, Scott Wood suggested this "root cause" explanation: SW> The patch that changed MAS1_TSIZE_SHIFT from 8 to 7 was around the SW> same time as the patch that added this code, which is probably why SW> adjusting it got missed. Commit 2bd9543cd3 did update the SW> equivalent code in ppce500_mpc8544ds.c, which now resides in SW> hw/ppc/e500.c and has been changed to not assume a power-of-2 SW> size. The ppce500_spin version should be eliminated.
Re: [Qemu-devel] [PATCH] target-ppc: Eliminate redundant and incorrect function booke206_page_size_to_tlb
David Gibson wrote on 06/26/2016 08:36:52 PM: > From: David Gibson > To: Aaron Larson > Cc: ag...@suse.de, qemu-devel@nongnu.org, qemu-...@nongnu.org > Date: 06/26/2016 08:58 PM > Subject: Re: [PATCH] target-ppc: Eliminate redundant and incorrect function booke206_page_size_to_tlb > > On Fri, Jun 24, 2016 at 12:11:00PM -0700, Aaron Larson wrote: > > > > Eliminate redundant and incorrect booke206_page_size_to_tlb function > > from ppce500_spin.c in preference to previously existing but newly > > exported definition from e500.c > > > > Signed-off-by: Aaron Larson > > Uh.. sorry.. can you provide a reference explaining why the removed > version is wrong? Doesn't this depend on which MMU Architecture > Version we're emulating? Sure, the code is internally inconsistent (shift assumed didn't match shift defined). I will provide an update commit message, similar to the original posting I made a few days ago with the "direction" corrected. I didn't verify what sub-architectures/platforms are affected. I've been assuming it was just ppce500. If it is important I can do a bit of research, but the way code is coupled to platforms is sometimes surprising to me, so I'm not sure I would trust my analysis. Let me know if you need this analysis as part of the updated comment.
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size
On 17 Jun 2016 22:55:47 Scott Wood wrote:
On 06/17/2016 05:13 PM, Aaron Larson wrote:
AL> The root cause is that the function computing the size of the TLB
AL> entry, namely booke206_page_size_to_tlb ... [is wrong]
AL> --- a/hw/ppc/ppce500_spin.c
AL> +++ b/hw/ppc/ppce500_spin.c
AL> @@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
AL> /* Create -kernel TLB entries for BookE, linearly spanning 256MB. */
AL> static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
AL> {
AL> -return ctz32(size >> 10) >> 1;
AL> ...
AL> +return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);
SW> The patch that changed MAS1_TSIZE_SHIFT from 8 to 7 was around the
SW> same time as the patch that added this code, which is probably why
SW> adjusting it got missed. Commit 2bd9543cd3 did update the
SW> equivalent code in ppce500_mpc8544ds.c, which now resides in
SW> hw/ppc/e500.c and has been changed to not assume a power-of-2
SW> size. The ppce500_spin version should be eliminated.
Scott, Are you suggesting that the e500.c:booke206_page_size_to_tlb()
function be made out of line and exported so that it can be used by
ppce500_spin.c? If so I'll submit a patch post haste.
I am uncertain though because that still leaves a lot of similar, but
still different code between ppce500_spin.c and e500.c.
[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size
When e500 PPC is booted multi-core, the non-boot cores are started via
the spin table. ppce500_spin.c:spin_kick() calls
mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
the created TLB entry is only 256KB.
The root cause is that the function computing the size of the TLB
entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined
by latter PPC cores, specifically (n**4)KB. The result is then used by
mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but
MAS1_TSIZE_SHIFT is defined assuming TLB entries are (n**2)KB. I.e., a
difference of shift=7 or shift=8.
Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since
the macro is used elsewhere.
Signed-off-by: Aaron Larson
---
hw/ppc/ppce500_spin.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index 76bd78b..7e38f0c 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
/* Create -kernel TLB entries for BookE, linearly spanning 256MB. */
static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
{
-return ctz32(size >> 10) >> 1;
+/* The EREF indicates that TLB pages are (4 to the power of 2)KB, which
+ * corresponds to MAS1_TSIZE_SHIFT=8, but to support legacy processors that
+ * assume TLB pages are (2 to the power of 2)KB MAS1_TSIZE_SHIFT is
+ * currently 7. */
+return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);
}
static void mmubooke_create_initial_mapping(CPUPPCState *env,
--
2.7.4
[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size
[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size
[Qemu-devel] PPC e500spin pir improperly initialized
Note change of subject from "Determining interest in PPC e500spin, yield". Thomas Huth wrote on 06/16/2016 01:47:05 AM: Aaron Larson wrote on 15.06.2016 22:12 in ppce500_spin.c AL> @@ -104,6 +108,16 @@ AL> AL> cpu_synchronize_state(cpu); AL> stl_p(&curspin->pir, env->spr[SPR_PIR]); AL> +/* The stl_p() above seems wrong to me. First of all, it seems more appropriate AL> + * in a guest ROM/BOOT code than in qemu emulation. However, SPR_PIR is never AL> + * initialized, so the effect of the stl_p() is to overwrite the curspin->pir AL> + * with 0. It makes more sense to load the SPR_PIR with the curspin->pir, which AL> + * is what the following does. AL> + *env->spr[SPR_PIR]=ldl_p(&curspin->pir); AL> + * Alternately SPR_PIR could be initialized from SPR_BOOKE_PIR which is properly AL> + * initialized, so this could also work: AL> + *env->spr[SPR_PIR] = env->spr[SPR_BOOKE_PIR] AL> +*/ AL> env->nip = ldq_p(&curspin->addr) & (map_size - 1); AL> env->gpr[3] = ldq_p(&curspin->r3); AL> env->gpr[4] = 0; TH> I'm not very familiar with the e500 code, but as far as I understand the TH> ppce500_spin.c code, it provides the spin table facility from ePAPR for the TH> guests that is normally provided by the boot firmware instead. Some more TH> information why this has been done can be found in the original commit TH> message here: TH> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5c145dacacad04f751c TH> TH> So it's right to set up curspin->pir here (not the other way round), but TH> I think SPR_PIR was just a typo and should be SPR_BOOKE_PIR instead, TH> since the PIR register for BookE CPUs has the number 286 and not 1023. TH> So does it work for you if you simply replace the line with: TH> TH> stl_p(&curspin->pir, env->spr[SPR_BOOKE_PIR]); I verified that the spin table is properly initialized if SPR_BOOKE_PIR is used. However this is superfluous since spin_reset() has already initialized the PV spin table pir. I wasn't sure if there was a desire to set the SPR_PIR as well for some reason. I think any of the following would be acceptable: 1. If the SPR_PIR needs to be set for some reason (why I'm not sure), then set SPR_PIR to SPR_BOOKE_PIR. 2. Change SPR_PIR to SPR_BOOKE_PIR. 3. Delete the line that sets curspin->pir to SPR_PIR. I'm fine submitting a patch for whatever solution folks deem appropriate.
Re: [Qemu-devel] [Qemu-ppc] Determining interest in PPC e500spin, yield, and openpic patches
Thomas Huth wrote on 06/16/2016 01:25:45 AM: > Thanks for your patch! However, patches have to follow certain rules > before they can be included in QEMU. Please read through Sorry for the broken patch, and the long delay. I'm not a git user so its taken a while to climb the curve. I didn't get 'git send-email' working, but hopefully the next patch will be ok.
Re: [Qemu-devel] [Qemu-ppc] Determining interest in PPC e500spin, yield, and openpic patches
David Gibson wrote on 06/14/2016 11:17:57 PM: Aaron Larson AL> 1. There is a defect in ppce500_spin.c:spin_kick() that creates an AL>incorrectly sized TLB entry. This was reported as bug AL>https://bugs.launchpad.net/qemu/+bug/1587535 I can provide a AL>patch if desired. DG> Absolutely. OK, I'll start with this one. Let me know if there is anything you'd like me to do with that bug report. When e500 PPC is booted multi-core, the non-boot cores are started via the spin table. ppce500_spin.c:spin_kick() calls mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but the created TLB entry is only 256KB. The root cause is that the function computing the size of the TLB entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined by latter PPC cores, specifically n to the power of FOUR * 1KB. The result is then used by mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but MAS1_TSIZE_SHIFT is defined assuming TLB entries are n to the power of TWO * 1KB. I.e., a difference of shift=7 or shift=8. Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since the macro is used elsewhere. The following patch has a fix for that, and also raises a separate issue that I'd be happy to resolve after getting some guidance. ppce500_spin-tlb.patch Description: Binary data
[Qemu-devel] Determining interest in PPC e500spin, yield, and openpic patches
We've used older versions of QEMU for several years as a virtual target for our OS. Many thanks to the community for providing this platform. We've been working to get our OS running under QEMU 2.x and have identified a few bugs in QEMU, have made some enhancements, and are still tracking down some other curious behaviors. I'm looking for some guidance as to how, and whether, you'd like patches for the following. 1. There is a defect in ppce500_spin.c:spin_kick() that creates an incorrectly sized TLB entry. This was reported as bug https://bugs.launchpad.net/qemu/+bug/1587535 I can provide a patch if desired. 2. We have implemented the PPC "yield" instruction. I can provide a patch if desired. 3. We're working on support for openpic timers. We're not finished, but it would be helpful to know if a patch is desired or if we should expect to maintain the changes independently. 4. We're currently tracking down why in our e500 (both unicore and multi-core) PPC QEMU 2.5 guest (x86 host), that with interrupts disabled, after enabling the decrementer and issuing a "wait" instruction QEMU continues to "busy loop", consuming an entire host CPU doing apparently nothing. As expected, issuing a "wait" prior to enabling the decrementer leaves the host process idle. We found the bug in the PPC "wait" instruction implementation that was independently reported and resolved last week, but that did not fix the problem. We also have our OS running on the g3beige and using MSR.POW which causes the host to "sleep", but we are having no joy with e500 and "wait". Any pointers would be appreciated. When we find something we'll report back.
