Re: [Bug 1887318] [NEW] impossible to install in OSX Yosemite 10.10.5

[G 3]

On Jul 12, 2020, at 10:02 PM, qemu-devel-requ...@nongnu.org wrote:


Message: 6
Date: Mon, 13 Jul 2020 00:17:30 -
From: JuanPabloCuervo <1887...@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1887318] [NEW] impossible to install in OSX Yosemite
10.10.5
Message-ID:
	 
<159459945016.20204.12821765315233915598.malonedeb@chaenomeles.canonic 
al.com>


Content-Type: text/plain; charset="utf-8"

Public bug reported:

the Brew method has glib problems, glib is impossible to install.
the MacPorts method has a very long .log file.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "main.log"
   https://bugs.launchpad.net/bugs/1887318/+attachment/5392136/ 
+files/main.log


--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1887318

Title:
  impossible to install in OSX Yosemite 10.10.5

Status in QEMU:
  New

Bug description:
  the Brew method has glib problems, glib is impossible to install.
  the MacPorts method has a very long .log file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1887318/+subscriptions


This is why we need installer files for QEMU. They make life so much  
easier than building from source.

Re: [PATCH v2 1/6] qapi/audio: add documentation for AudioFormat

[G 3]

On Sun, Mar 8, 2020 at 3:33 PM Volker Rümelin  wrote:

> The review for patch ed2a4a7941 "audio: proper support for
> float samples in mixeng" suggested this would be a good idea.
>
> Acked-by: Markus Armbruster 
> Signed-off-by: Volker Rümelin 
> ---
>   
>
> Your patch applied cleanly to the latest commit I tried it out with. For
testing I used qemu-system-i386 with the AC97 sound card and a Windows 2000
guest. The audio played perfectly.

Tested-by: John Arbuckle 

Fwd: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

[G 3]

-- Forwarded message -
From: G 3 
Date: Wed, Mar 4, 2020 at 1:35 PM
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
To: BALATON Zoltan 




On Mon, Mar 2, 2020 at 6:16 PM BALATON Zoltan  wrote:

> On Mon, 2 Mar 2020, Richard Henderson wrote:
> > On 3/2/20 3:42 AM, BALATON Zoltan wrote:
> >>> The "hardfloat" option works (with other targets) only with ieee745
> >>> accumulative exceptions, when the most common of those exceptions,
> inexact, has
> >>> already been raised.  And thus need not be raised a second time.
> >>
> >> Why exactly it's done that way? What are the differences between IEEE FP
> >> implementations that prevents using hardfloat most of the time instead
> of only
> >> using it in some (although supposedly common) special cases?
> >
> > While it is possible to read the host's ieee exception word after the
> hardfloat
> > operation, there are two reasons that is undesirable:
> >
> > (1) It is *slow*.  So slow that it's faster to run the softfloat code
> instead.
> > I thought it would be easier to find the benchmark numbers that Emilio
> > generated when this was tested, but I can't find it.
>
> I remember those benchmarks too and this is also what the paper Alex
> referred to also confirmed. Also I've found that enabling hardfloat for
> PPC without doing anything else is slightly slower (on a recent CPU, on
> older CPUs could be even slower). Interetingly however it does give a
> speedup for vector instructions (maybe because they don't clear flags
> between each sub operation). Does that mean these vector instruction
> helpers are also buggy regarding exceptions?
>

I am all intrigued by these vector instructions. Apple was really big on
using them back in the day so programs like Quicktime and iTunes definitely
use them. I'm not sure if the PowerPC's altivec vector instructions map to
host vector instructions already, but if they don't, mapping them would
give us a huge speedup in certain places. Would anyone know if this was
already done in QEMU?

Re: R: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

[G 3]

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.

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
> >
>

Re: should we have a new 'tools' manual?

[G 3]

So far we've been converting docs to Sphinx and assigning them
to manuals according to the division originally set out by
Paolo on the wiki: https://wiki.qemu.org/Features/Documentation

 * QEMU User-mode Emulation User's Guide (docs/user)
 * QEMU System Emulation User's Guide (docs/system)
 * QEMU System Emulation Management and Interoperability Guide
(docs/interop)
 * QEMU System Emulation Guest Hardware Specifications (docs/specs)
 * QEMU Developer's Guide (docs/devel, not shipped to end-users)

but some of our documentation has always been a bit of an awkward
fit into this classification:
 * qemu-img
 * qemu-nbd
 * virtfs-proxy-helper
etc. I've tended to put these things into interop/.

The proposal from Dan and David was that we should add a sixth
top-level manual
 * QEMU Tools Guide (docs/tools)

which would be a more coherent place for these to live.

This seems like a good idea to me -- do people agree? What's
our definition of a "tool", or do we just know one when we see it?
What in particular should go in tools/ ?

thanks
-- PMM

I think adding a tool section is a good idea and a more natural fit for
something like qemu-img. I think a tool is a program that is not QEMU but
comes with QEMU.

Re: [PATCH] ui/cocoa: Drop workarounds for pre-10.12 OSX

[G 3]

> Date: Sat,  1 Feb 2020 17:05:34 +
> From: Peter Maydell 
> To: qemu-devel@nongnu.org
> Cc: Gerd Hoffmann 
> Subject: [PATCH] ui/cocoa: Drop workarounds for pre-10.12 OSX
> Message-ID: <20200201170534.22123-1-peter.mayd...@linaro.org>
>
> Our official OSX support policy covers the last two released versions.
> Currently that is 10.14 and 10.15.  We also may work on older versions, but
> don't guarantee it.
>
> In commit 50290c002c045280f8d in mid-2019 we introduced some uses of
> CLOCK_MONOTONIC which incidentally broke compilation for pre-10.12 OSX
> versions (see LP:1861551). We don't intend to fix that, so we might
> as well drop the code in ui/cocoa.m which caters for pre-10.12
> versions as well. (For reference, 10.11 fell out of Apple extended
> security support in September 2018.)
>
> Signed-off-by: Peter Maydell 
> ---
> The bug report is recent, but this was also pointed out on
> the mailing list back in June 2019. Since nobody has cared
> to try to fix it, we clearly don't care about 10.11 in
> practice as well as in theory.]
> ---
>  ui/cocoa.m | 59 --
>  1 file changed, 59 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index fbb5b1b45f..f9945bc712 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -42,60 +42,10 @@
>  #include 
>  #include "hw/core/cpu.h"
>
> -#ifndef MAC_OS_X_VERSION_10_5
> -#define MAC_OS_X_VERSION_10_5 1050
> -#endif
> -#ifndef MAC_OS_X_VERSION_10_6
> -#define MAC_OS_X_VERSION_10_6 1060
> -#endif
> -#ifndef MAC_OS_X_VERSION_10_9
> -#define MAC_OS_X_VERSION_10_9 1090
> -#endif
> -#ifndef MAC_OS_X_VERSION_10_10
> -#define MAC_OS_X_VERSION_10_10 101000
> -#endif
> -#ifndef MAC_OS_X_VERSION_10_12
> -#define MAC_OS_X_VERSION_10_12 101200
> -#endif
>  #ifndef MAC_OS_X_VERSION_10_13
>  #define MAC_OS_X_VERSION_10_13 101300
>  #endif
>
> -/* macOS 10.12 deprecated many constants, #define the new names for older
> SDKs */
> -#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_12
> -#define NSEventMaskAny  NSAnyEventMask
> -#define NSEventModifierFlagCapsLock NSAlphaShiftKeyMask
> -#define NSEventModifierFlagShiftNSShiftKeyMask
> -#define NSEventModifierFlagCommand  NSCommandKeyMask
> -#define NSEventModifierFlagControl  NSControlKeyMask
> -#define NSEventModifierFlagOption   NSAlternateKeyMask
> -#define NSEventTypeFlagsChanged NSFlagsChanged
> -#define NSEventTypeKeyUpNSKeyUp
> -#define NSEventTypeKeyDown  NSKeyDown
> -#define NSEventTypeMouseMoved   NSMouseMoved
> -#define NSEventTypeLeftMouseDownNSLeftMouseDown
> -#define NSEventTypeRightMouseDown   NSRightMouseDown
> -#define NSEventTypeOtherMouseDown   NSOtherMouseDown
> -#define NSEventTypeLeftMouseDragged NSLeftMouseDragged
> -#define NSEventTypeRightMouseDraggedNSRightMouseDragged
> -#define NSEventTypeOtherMouseDraggedNSOtherMouseDragged
> -#define NSEventTypeLeftMouseUp  NSLeftMouseUp
> -#define NSEventTypeRightMouseUp NSRightMouseUp
> -#define NSEventTypeOtherMouseUp NSOtherMouseUp
> -#define NSEventTypeScrollWheel  NSScrollWheel
> -#define NSTextAlignmentCenter   NSCenterTextAlignment
> -#define NSWindowStyleMaskBorderless NSBorderlessWindowMask
> -#define NSWindowStyleMaskClosable   NSClosableWindowMask
> -#define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask
> -#define NSWindowStyleMaskTitled NSTitledWindowMask
> -#endif
> -/* 10.13 deprecates NSFileHandlingPanelOKButton in favour of
> - * NSModalResponseOK, which was introduced in 10.9. Define
> - * it for older versions.
> - */
> -#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_9
> -#define NSModalResponseOK NSFileHandlingPanelOKButton
> -#endif
>  /* 10.14 deprecates NSOnState and NSOffState in favor of
>   * NSControlStateValueOn/Off, which were introduced in 10.13.
>   * Define for older versions
> @@ -465,11 +415,7 @@ - (void) drawRect:(NSRect) rect
>  COCOA_DEBUG("QemuCocoaView: drawRect\n");
>
>  // get CoreGraphic context
> -#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_10
> -CGContextRef viewContextRef = [[NSGraphicsContext currentContext]
> graphicsPort];
> -#else
>  CGContextRef viewContextRef = [[NSGraphicsContext currentContext]
> CGContext];
> -#endif
>
>  CGContextSetInterpolationQuality (viewContextRef,
> kCGInterpolationNone);
>  CGContextSetShouldAntialias (viewContextRef, NO);
> @@ -1075,9 +1021,7 @@ - (void) raiseAllKeys
>   --
>  */
>  @interface QemuCocoaAppController : NSObject
> -#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6)
>  NSApplicationDelegate>
> -#endif
>  {
>  }
>  - (void)doToggleFullScreen:(id)sender;
> @@ -1126,9 +1070,6 @@ - (id) init
>  [normalWindow setAcceptsMouseMovedEvents:YES];
>  [normalWindow setTitle:@"QEMU"];
>  

Re: QEMU HTML documentation now on qemu.org

[G 3]

> You can now access the latest QEMU HTML documentation built from

https://wiki.qemu.org/docs/qemu-doc.html


This is a welcome start. Could we add version support to the URL?

What I mean is add the version number to the path of the URL.
Like this:
https://wiki.qemu.org/docs/4.2/qemu-doc.html

This way users of older versions of QEMU can still access documentation
relevant to his or her version.

Thank you.

Re: [Bug 1850570] [NEW] Cannot use usb-host on Mac OS

[G 3]

>
> Message: 9
> Date: Wed, 30 Oct 2019 01:46:54 -
> From: John Canada <1850...@bugs.launchpad.net>
> To: qemu-devel@nongnu.org
> Subject: [Bug 1850570] [NEW] Cannot use usb-host on Mac OS
> Message-ID:
> <
> 157240001496.28481.10507378472210680134.malone...@chaenomeles.canonical.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Public bug reported:
>
> 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
>
> ** Affects: qemu
>  Importance: Undecided
>  Status: New
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/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 

Re: Qemu-devel Digest, Vol 198, Issue 358

[G 3]

On Tue, Sep 24, 2019 at 1:05 PM G 3  wrote:

> On top
>
>
> Message: 9
>> Date: Tue, 24 Sep 2019 10:56:53 -
>> From: Adrian Vladu 
>> To: qemu-devel@nongnu.org
>> Subject: [Bug 1826175] Re: Compilation on MSYS2/MinGW-w64 fails with
>> error: "No rule to make target capstone.lib"
>> Message-ID:
>> <
>> 156932261321.27303.8940310087786694778.mal...@soybean.canonical.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> The fix in upstream capstone has been merged:
>>
>> https://github.com/aquynh/capstone/commit/29893c63e34ee21846744d02c396ae3c801b936b
>>
>> --
>> You received this bug notification because you are a member of qemu-
>> devel-ml, which is subscribed to QEMU.
>> https://bugs.launchpad.net/bugs/1826175
>>
>> Title:
>>   Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make
>>   target capstone.lib"
>>
>> Status in QEMU:
>>   New
>>
>> Bug description:
>>   I submitted this bug to Capstone directly but I figured it'd be useful
>>   to post it here too. The IS_MINGW check in the Makefile for Capstone
>>   fails under MSYS2 MinGW-w64 because cc --version doesn't have mingw in
>>   the output anymore:
>>
>>   $ whereis cc
>>   cc: /mingw64/bin/cc.exe
>>
>>   $ cc --version
>>   cc.exe (Rev2, Built by MSYS2 project) 8.3.0
>>   Copyright (C) 2018 Free Software Foundation, Inc.
>>   This is free software; see the source for copying conditions.  There is
>> NO
>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>>   Really simple patch:
>>
>>   diff --git "a/Makefile" "b/Makefile"
>>   index 063f50db..1d9f042e 100644
>>   --- "a/Makefile"
>>   +++ "b/Makefile"
>>   @@ -288,7 +288,7 @@ CFLAGS := $(CFLAGS:-fPIC=)
>># On Windows we need the shared library to be executable
>>else
>># mingw?
>>   -IS_MINGW := $(shell $(CC) --version | grep -i mingw | wc -l)
>>   +IS_MINGW := $(shell $(CC) --version | grep -i msys2 | wc -l)
>>ifeq ($(IS_MINGW),1)
>>EXT = dll
>>AR_EXT = lib
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/qemu/+bug/1826175/+subscriptions
>>
>> 
>>
>
Hi Peter, could we make capstone disabled by default please? It does cause
compiling problems and isn't needed to use QEMU.

Re: [Qemu-devel] [PATCH] Implement Fraction Rounded bit in FPSCR for PowerPC

[G 3]

Thank you for the suggestion.

For the added note, did you want specific places listed? If so please let
me know these places.

Thank you.

On Tue, May 21, 2019 at 11:30 PM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 5/21/19 8:06 PM, John Arbuckle wrote:
> > Implement the PowerPC floating point status and control register flag
> Fraction Rounded.
> >
> > Signed-off-by: John Arbuckle 
> > ---
> >  fpu/softfloat.c   | 15 ---
> >  include/fpu/softfloat-types.h |  1 +
> >  target/ppc/fpu_helper.c   |  4 
> >  3 files changed, 17 insertions(+), 3 deletions(-)
>
> Please split the target/ppc part away from the softfloat part.
>
> Also, we should note that there are more places within softfloat that need
> to
> be adjusted so that float_float_rounded is fully supported.
>
>
> r~
>

Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

[G 3]

On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:


On 19/04/2019 00.47, John Arbuckle wrote:
Capstone is not necessary in order to use QEMU. Disable it by  
default.

This will save the user the pain of having to figure why QEMU isn't
building when this library is missing.

Signed-off-by: John Arbuckle 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 1c563a7027..77d7967f92 100755
--- a/configure
+++ b/configure
@@ -433,7 +433,7 @@ opengl_dmabuf="no"
 cpuid_h="no"
 avx2_opt=""
 zlib="yes"
-capstone=""
+capstone="no"
 lzo=""
 snappy=""
 bzip2=""


AFAIK we ship capstone as a submodule, so how can this be missing?  
Also,
our philosophy is to keep everything enabled by default if  
possible, so
that the code paths don't bitrot. Thus I don't think that disabling  
this

by default is a good idea. ... so if you've got a problem here, there
must be another solution (e.g. is the system capstone detection not
working right on your system?).

 Thomas


Thank you for replying. Capstone comes with QEMU? Every time I try to  
compile QEMU I see an error relating to Capstone not being on my  
system. Why do you feel that disabling Capstone by default is not a  
good idea?


Here is the error message I see when compiling QEMU:

CHK version_gen.h
make[1]: *** No rule to make target `/Users/John/qemu-git/capstone/ 
libcapstone.a'.  Stop.

make: *** [subdir-capstone] Error 2

Re: [Qemu-devel] Questions about EDID

[G 3]

If the value is already in the list, then something else must be happening
that prevents the custom resolution from reaching the guest. Would you know
where in the list the custom resolution is added? My guess right now is the
size of the list is being reported incorrectly - the custom resolution
isn't being counted. When the operating system iterates thru the list it
might stop right before the custom resolution value, preventing its
inclusion.

On Fri, Mar 1, 2019 at 12:47 AM Gerd Hoffmann  wrote:

> On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote:
> > On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
> > mark.cave-ayl...@ilande.co.uk> wrote:
> >
> > > On 27/02/2019 05:27, Gerd Hoffmann wrote:
> > >
> > > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> > > >> When I use edid=on, I do see a lot of extra resolutions available in
> > > Mac OS
> > > >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> > > kind
> > > >> of rule like the resolution value has to be divisible by a certain
> > > number?
> > > >
> > > > qemu doesn't have such a requirement.
> > > > Might be the guest drivers have.
> > > > Try making width/height multiple of 8 or 16.
> > >
> > > Right, at the moment all the MacOS driver does is parse the resolution
> > > list from the
> > > EDID and add them to the dropdown list - it doesn't support the xres
> and
> > > yres properties.
> > >
> >
> > Gerd, could the xres +yres numbers be added to the list of resolutions
> > then?
>
> That is already the case:
>
> qemu-edid -x 1234 -y 567 | edid-decode
> [ ... ]
> First detailed timing is preferred timing
> Established timings supported:
>   640x480@60Hz
>   800x600@60Hz
>   1024x768@60Hz
> Standard timings supported:
>   2048x1152@60Hz
>   1920x1080@60Hz
> Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm
>1234 1542 1579 1665 hborder 0
>
> 567  569  571  586 vborder 0
> ^^^
>-hsync -vsync
> [ ... ]
>
> cheers,
>   Gerd
>
>

Re: [Qemu-devel] [PATCH v3 7/7] ui/cocoa: Perform UI operations only on the main thread

[G 3]

On Mon, Feb 25, 2019 at 5:24 AM Peter Maydell 
wrote:

> The OSX Mojave release is more picky about enforcing the Cocoa API
> restriction that only the main thread may perform UI calls. To
> accommodate this we need to restructure the Cocoa code:
>  * the special OSX main() creates a second thread and uses
>that to call the vl.c qemu_main(); the original main
>thread goes into the OSX event loop
>  * the refresh, switch and update callbacks asynchronously
>tell the main thread to do the necessary work
>  * the refresh callback no longer does the "get events from the
>UI event queue and handle them" loop, since we now use
>the stock OSX event loop. Instead our NSApplication sendEvent
>method will either deal with them or pass them on to OSX
>
> All these things have to be changed in one commit, to avoid
> breaking bisection.
>
> Note that since we use dispatch_get_main_queue(), this bumps
> our minimum version requirement to OSX 10.10 Yosemite (released
> in 2014, unsupported by Apple since 2017).
>
> I think eliminating support for Macintosh operating systems older than
10.10 is a mistake. These operating systems may be old but are far from
useless. They are fully capable of handling QEMU. I do believe that fixing
support for Mac OS 10.14 and maintaining support for older versions of Mac
OS is possible. Calling methods and functions on the main thread can be
done using performSelectorOnMainThread.

Thank you.

Re: [Qemu-devel] [PATCH v3 1/7] ui/cocoa: Ensure we have the iothread lock when calling into QEMU

[G 3]

On Mon, Feb 25, 2019 at 5:24 AM Peter Maydell 
wrote:

> The Cocoa UI should run on the main thread; this is enforced
> in OSX Mojave. In order to be able to run on the main thread,
> we need to make sure we hold the iothread lock whenever we
> call into various QEMU UI midlayer functions.
>
> Signed-off-by: Peter Maydell 
> Reviewed-by: Roman Bolshakov 
> Tested-by: Roman Bolshakov 
> Message-id: 20190214102816.3393-2-peter.mayd...@linaro.org
> ---
> Changes since v2: add with_iothread_lock wrap to the
> qmp_stop()/qmp_cont() calls
> ---
>  ui/cocoa.m | 91 ++
>  1 file changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index e2567d6946..f1171c4865 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -129,6 +129,21 @@
>  NSTextField *pauseLabel;
>  NSArray * supportedImageFileTypes;
>
> +// Utility function to run specified code block with iothread lock held
> +typedef void (^CodeBlock)(void);
>

Please don't use blocks. It would lock Mac OS X users into having to use
CLang. GCC does not support this non-standard extension.

C function pointers and Objective-C's selectors could work in place of
blocks.

Thank you.

Re: [Qemu-devel] Questions about EDID

[G 3]

On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
mark.cave-ayl...@ilande.co.uk> wrote:

> On 27/02/2019 05:27, Gerd Hoffmann wrote:
>
> > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> >> When I use edid=on, I do see a lot of extra resolutions available in
> Mac OS
> >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> kind
> >> of rule like the resolution value has to be divisible by a certain
> number?
> >
> > qemu doesn't have such a requirement.
> > Might be the guest drivers have.
> > Try making width/height multiple of 8 or 16.
>
> Right, at the moment all the MacOS driver does is parse the resolution
> list from the
> EDID and add them to the dropdown list - it doesn't support the xres and
> yres properties.
>

Gerd, could the xres +yres numbers be added to the list of resolutions
then?

Re: [Qemu-devel] Questions about EDID

[G 3]

When I use edid=on, I do see a lot of extra resolutions available in Mac OS
9 and Mac OS X, just not the resolution I want to use. Is there some kind
of rule like the resolution value has to be divisible by a certain number?

On Tue, Feb 26, 2019 at 1:43 AM Gerd Hoffmann  wrote:

> On Mon, Feb 25, 2019 at 09:49:22PM -0500, Programmingkid wrote:
> >
> > > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann  wrote:
> > >
> > > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote:
> > >> Hi Gerd, I was wondering if you have made any documentation for your
> EDID
> > >> patches. If you have could you provide a link please?
> > >
> > > No docs.
> > >
> > >> Also could a feature be added that allows the user to specify
> resolutions
> > >> to be made available to the guest?
> > >>
> > >> Maybe it could work like this: -device
> VGA,edid=on,res=1366x768,7680x4320
> > >
> > > A single resolution works (via xres + yres properties).
> >
> > Could you send an example of the xres and yres properties please?
> > I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888
>
> That is correct.  But you also need a guest driver with edid support.
>
> I think the macos driver got support for that, for linux support landed
> in the 5.0 devel cycle.
>
> cheers,
>   Gerd
>
>

[Qemu-devel] Questions about EDID

[G 3]

Hi Gerd, I was wondering if you have made any documentation for your EDID
patches. If you have could you provide a link please?

Also could a feature be added that allows the user to specify resolutions
to be made available to the guest?

Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320

Thank you.

Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: replace scrollingDeltaY with deltaY

[G 3]

On Jul 11, 2018, at 5:18 PM, Peter Maydell wrote:

On 9 July 2018 at 16:02, John Arbuckle   
wrote:

The NSEvent class method scrollingDeltaY is available
for Mac OS 10.7 and newer. Since QEMU supports Mac OS
10.5 and up, we need to be using a method that is
available on these version of Mac OS X. The deltaY
method is a method that does the same thing as
scrollingDeltaY and is available on Mac OS 10.5 and
up. So we replace scrollingDeltaY with deltaY.

We only check deltaY's value if it is not zero
because zero means no scrolling took place.


Not quite -- it means that the scrolling was fine enough
that it doesn't add up to a big movement. If you use a
fine-scrolling input device (I used the trackpad on my
macbook air), then you will get a sequence of events
like this for a very slow trackpad scroll:

scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -3
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -3
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -3
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -3
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY 0 scrollingDeltaY -4
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY -2
scroll: deltaY 0 scrollingDeltaY 0

(interestingly it does give events with both deltas 0; maybe
that event had a horizontal scroll component to it).

Larger scroll gestures get you this sort of thing:

scroll: deltaY 0 scrollingDeltaY 0
scroll: deltaY 0 scrollingDeltaY -1
scroll: deltaY -3 scrollingDeltaY -31
scroll: deltaY -3 scrollingDeltaY -36
scroll: deltaY -2 scrollingDeltaY -30
scroll: deltaY 0 scrollingDeltaY 0
scroll: deltaY -1 scrollingDeltaY -16
scroll: deltaY -3 scrollingDeltaY -32
scroll: deltaY -3 scrollingDeltaY -30
scroll: deltaY -2 scrollingDeltaY -28
scroll: deltaY -2 scrollingDeltaY -25
scroll: deltaY -2 scrollingDeltaY -23
scroll: deltaY -1 scrollingDeltaY -19
scroll: deltaY -1 scrollingDeltaY -15
scroll: deltaY -1 scrollingDeltaY -14
scroll: deltaY 0 scrollingDeltaY -12

where OSX has decided that there's enough movement to
report a deltaY change, not just the fine-grained
scrollingDeltaY.

Anyway, since the QEMU input layer doesn't provide a mechanism
for reporting fine-scrolling I guess this patch is OK.
If we get complaints about the trackpad no longer being
as responsive as it used to be to scrolls then we can
look at doing something more complicated then.

I'll tweak the comments and put this in for 3.0 rc1.


Signed-off-by: John Arbuckle 
---
v3 changes:
- Added a comment explaining why we drop scrolling events in both  
the code and

the patch comment.

v2 changes:
- Added a condition that drops scroll events that have a deltaY  
value of zero.


 ui/cocoa.m | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 2991ed4f19..3bae090101 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -802,14 +802,19 @@ - (void) handleEvent:(NSEvent *)event
  * This is in-line with standard Mac OS X UI behaviour.
  */

+/*
+ * When deltaY is zero, it means the scrolling device  
did not move

+ * for this event. So we drop the event.
+ */
+if ([event deltaY] != 0) {
 /* Determine if this is a scroll up or scroll down  
event */

-buttons = ([event scrollingDeltaY] > 0) ?
-INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
-qemu_input_queue_btn(dcl->con, buttons, true);
-qemu_input_event_sync();
-qemu_input_queue_btn(dcl->con, buttons, false);
-qemu_input_event_sync();
-
+buttons = ([event deltaY] > 0) ?
+INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
+qemu_input_queue_btn(dcl->con, buttons, true);
+qemu_input_event_sync();
+qemu_input_queue_btn(dcl->con, buttons, false);
+qemu_input_event_sync();
+}
 /*
  * Since deltaY also reports scroll wheel events we  
prevent mouse

  * movement code from executing.
--
2.14.3 (Apple Git-98)



thanks
-- PMM


Excellent job investing. 

Re: [Qemu-devel] [PATCH v2] ui/cocoa.m: replace scrollingDeltaY with deltaY

[G 3]

On Jul 6, 2018, at 5:11 AM, Peter Maydell wrote:

On 6 July 2018 at 03:53, John Arbuckle   
wrote:

The NSEvent class method scrollingDeltaY is available
for Mac OS 10.7 and newer. Since QEMU supports Mac OS
10.5 and up, we need to be using a method that is
available on these version of Mac OS X. The deltaY
method is a method that does the same thing as
scrollingDeltaY and is available on Mac OS 10.5 and
up. So we simply replace scrollingDeltaY with deltaY.


Commit message doesn't match code change.


Did you want me to add information on dropping events with a
deltaY value of zero?




Signed-off-by: John Arbuckle 
---
v2 changes:
- Added a condition that drops scroll events that have a deltaY  
value of zero.


 ui/cocoa.m | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 2991ed4..f371469 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -802,14 +802,15 @@ QemuCocoaView *cocoaView;
  * This is in-line with standard Mac OS X UI behaviour.
  */

+if ([event deltaY] != 0) {


This could use a comment about why we need to check it.


Sounds good.



 /* Determine if this is a scroll up or scroll down  
event */

-buttons = ([event scrollingDeltaY] > 0) ?
-INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
-qemu_input_queue_btn(dcl->con, buttons, true);
-qemu_input_event_sync();
-qemu_input_queue_btn(dcl->con, buttons, false);
-qemu_input_event_sync();
-
+buttons = ([event deltaY] > 0) ?
+INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
+qemu_input_queue_btn(dcl->con, buttons, true);
+qemu_input_event_sync();
+qemu_input_queue_btn(dcl->con, buttons, false);
+qemu_input_event_sync();
+}
 /*
  * Since deltaY also reports scroll wheel events we  
prevent mouse

  * movement code from executing.
--
2.7.2


thanks
-- PMM

[Qemu-devel] RISC-V platform

[G 3]

Hi, I noticed your RISC-V patches on the mailing list and had a  
question that I think you may be able to answer. Has anyone defined a  
RISC-V platform yet? What I mean is defining what devices would be  
found on a RISC-V motherboard. I do hope to see RISC-V based desktop  
systems one day. But before that day can come the platform for this  
chip would have to be established. Could the SiFive board be the  
basis for such a standard?

Re: [Qemu-devel] [PATCH] fix fdiv instruction

[G 3]

On Jun 26, 2018, at 9:49 AM, Richard Henderson wrote:


On 06/25/2018 03:23 PM, Programmingkid wrote:


On Jun 25, 2018, at 5:08 PM, Richard Henderson  
 wrote:


On Mon, Jun 25, 2018, 08:23 G 3  wrote:


Try

uint64_t expected_answer = 0xdeadbeef;
...
c.i = expected_answer;
asm volatile("fdiv %0, %1, %2" : "+f"(c.d) : "f"(1.0),  
"f"(0.0));


to avoid depending on uninitialized data.  (This expected value is
an SNaN with a deadbeef marker Just to be Sure.)


r~



Ok I made this program and tried it on my iMac G5 (PowerPC 970).

#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
 double d;
 uint64_t i;
};
typedef union Converter Converter;

int main (int argc, const char * argv[]) {
 Converter answer;
 answer.i = 0xdeadbeef;
 //asm volatile("mtfsb1 27"); /* Set ZE bit */
 asm volatile("fdiv %0, %1, %2" : "=f"(answer.d) : "f"(1.0),
"f"(0.0));

Need +f for inout operand.
This didn't test what you expected.


What do you mean by inout operand?


An operand that is both input and output.


If you could send me some sample code I will test it out.


I did, you just didn't read it properly.
Here it is again:

  asm volatile("fdiv %0, %1, %2"
   : "+f"(answer.d) : "f"(1.0), "f"(0.0));
 

r~



I used the +f constraint and did see different results. Computer used  
was an iMac G5 (PowerPC 970).


If FPSCR[ZE] is set:
answer = 0xdeadbeef  (changed from 0x0)

if FPSCR[ZE] is not set:
answer = 0x7ff0  (no change from before)


I then tried this program in QEMU without any of my patches applied.  
Here is the result:


If FPSCR[ZE] is set or not set, answer = 0x7ff0. This  
indicates to me that the fdiv instruction needs a little work. This  
is what I think should happen. If division by zero takes  place and  
the FPSCR[ZE] bit is set, then the value in the destination register  
should not be altered (rather than returning zero).



Here is the program used:

#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
double d;
uint64_t i;
};

typedef union Converter Converter;

int main (int argc, const char * argv[]) {

Converter answer;
answer.i = 0xdeadbeef;
//asm volatile("mtfsb1 27"); /* Set ZE bit */
asm volatile("fdiv %0, %1, %2" : "+f"(answer.d) : "f"(1.0),  
"f"(0.0));

printf("answer = 0x%" PRIx64 "\n", answer.i);
return 0;
}

Re: [Qemu-devel] [PATCH] fix fdiv instruction

[G 3]

On Jun 24, 2018, at 11:47 PM, Richard Henderson wrote:


On 06/24/2018 11:38 AM, Programmingkid wrote:

void test_division_by_zero()
{
Converter c;
uint64_t expected_answer = 0x0;
uint32_t actual_fpscr, expected_fpscr = 0xc410;
reset_fpscr();
set_fpscr_bit(ZE);
asm volatile("fdiv %0, %1, %2" : "=f"(c.d) : "f"(1.0), "f"(0.0));


Try

uint64_t expected_answer = 0xdeadbeef;
...
c.i = expected_answer;
asm volatile("fdiv %0, %1, %2" : "+f"(c.d) : "f"(1.0), "f"(0.0));

to avoid depending on uninitialized data.  (This expected value is
an SNaN with a deadbeef marker Just to be Sure.)


r~



Ok I made this program and tried it on my iMac G5 (PowerPC 970).

#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
double d;
uint64_t i;
};
typedef union Converter Converter;

int main (int argc, const char * argv[]) {
Converter answer;
answer.i = 0xdeadbeef;
//asm volatile("mtfsb1 27"); /* Set ZE bit */
asm volatile("fdiv %0, %1, %2" : "=f"(answer.d) : "f"(1.0),  
"f"(0.0));

printf("answer = 0x%" PRIx64 "\n", answer.i);
return 0;
}

The result was the same.

When the FPSCR[ZE] bit is set, the answer is 0x0.

When the FPSCR[ZE] bit is not set, the answer is 0x7ff0.

This seems to be an undocumented feature. 

Re: [Qemu-devel] [PATCH] fix fdiv instruction

[G 3]

On Jun 24, 2018, at 8:46 PM, David Gibson wrote:


On Fri, Jun 22, 2018 at 10:22:58PM -0400, John Arbuckle wrote:

When the fdiv instruction divides a finite number by zero,
the result actually depends on the FPSCR[ZE] bit. If this
bit is set, the return value is zero. If it is not set
the result should be either positive or negative infinity.
The sign of this result would depend on the sign of the
two inputs. What currently happens is only infinity is
returned even if the FPSCR[ZE] bit is set. This patch
fixes this problem by actually checking the FPSCR[ZE] bit
when deciding what the answer should be.

fdiv is suppose to only set the FPSCR's FPRF bits during a
division by zero situation when the FPSCR[ZE] is not set.
What currently happens is these bits are always set. This
patch fixes this problem by checking the FPSCR[ZE] bit to
decide if the FPRF bits should be set.

https://www.pdfdrive.net/powerpc-microprocessor-family-the- 
programming-environments-for-32-e3087633.html

This document has the information on the fdiv. Page 133 has the
information on what action is executed when a division by zero
situation takes place.


I'm looking at that table and there is definitely no mention of a 0
*result* in any situation.  So this patch is definitely wrong on that
point.  If there's something else this is fixing, then the commit
message needs to describe that.


I did not find any mention of a zero result *yet*. There could be  
mention of something in another document. I will see what I can find.  
Right now I do have example code that I ran on a PowerPC 970 CPU and  
the results are as follows:


When dividing by zero:

if FPSCR[ZE] is enabled
then answer = 0
if FPSCR[ZE] is disabled
then answer = 0x7ff0

I think this feature may be undocumented.

Here is the example program I used. When I ran this program, the  
FPSCR is set to zero initially (all bits disabled). When the mtfsb1  
instruction is executed, the ZE bit is set. I ran this program twice.  
Once with the mtfsb1 line uncommented, and another time with the line  
commented. The result for the answer was different in each situation.


#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
double d;
uint64_t i;
};
typedef union Converter Converter;

int main (int argc, const char * argv[]) {
Converter answer;
//asm volatile("mtfsb1 27"); /* Set ZE bit */
asm volatile("fdiv %0, %1, %2" : "=f"(answer.d) : "f"(1.0),  
"f"(0.0));

printf("answer = 0x%" PRIx64 "\n", answer.i);
return 0;
}

Re: [Qemu-devel] Help with Windows NT 4.0

[G 3]

On Aug 15, 2017, at 6:27 PM, Paolo Bonzini wrote:


On 15/08/2017 20:46, Programmingkid wrote:


On Aug 14, 2017, at 2:51 AM, Paolo Bonzini   
wrote:


On 13/08/2017 21:13, Programmingkid wrote:

Lately I found out that Windows NT 4.0 seems to work well with the
486 and pentium processors. Using "-cpu 486" made installing it
actually work. Now I am seeing another issue. When I boot  
Windows NT

4.0 I see this error message:

*** STOP: 0x007B (0x807A8610,0x,0x,0x)
INACESSIBLE_BOOT_DEVICE

Would anyone know a way to solve this issue?


Hervé is probably the best person to answer this question.  Maybe  
try

installing it with SCSI disks ("-drive if=scsi,id=hd,file=... -drive
if=scsi,id=cd,file=... -device lsi -device scsi-hd,drive=hd -device
scsi-cd,drive=cd").

Thanks,

Paolo


Thanks for the help. Unfortunately trying to boot from the install  
CD leads to the INACCESSIBLE_BOOT_DEVICE error when using SCSI.


Try with 0.12.


After doing a lot of bisecting I found a patch that did break Windows  
NT 4.0 compatibility long ago. Not sure if it is the problem we face  
today. This is it:


commit 2bec46dc97571a3c34b18fe4ca198e7bfbdca41f
Author: aliguori 
Date:   Mon Nov 24 20:21:41 2008 +

vga optimization (Glauber Costa)

Hypervisors like KVM perform badly while doing mmio on
a loop, because it'll generate an exit on each access.
This is the case with VGA, which results in very bad
performance.

In this patch, we map the linear frame buffer as RAM,
make sure it has dirty region tracking enabled, and then
just let the region to be written.

Re: [Qemu-devel] Help with Windows NT 4.0

[G 3]

On Aug 15, 2017, at 6:27 PM, Paolo Bonzini wrote:


On 15/08/2017 20:46, Programmingkid wrote:


On Aug 14, 2017, at 2:51 AM, Paolo Bonzini   
wrote:


On 13/08/2017 21:13, Programmingkid wrote:

Lately I found out that Windows NT 4.0 seems to work well with the
486 and pentium processors. Using "-cpu 486" made installing it
actually work. Now I am seeing another issue. When I boot  
Windows NT

4.0 I see this error message:

*** STOP: 0x007B (0x807A8610,0x,0x,0x)
INACESSIBLE_BOOT_DEVICE

Would anyone know a way to solve this issue?


Hervé is probably the best person to answer this question.  Maybe  
try

installing it with SCSI disks ("-drive if=scsi,id=hd,file=... -drive
if=scsi,id=cd,file=... -device lsi -device scsi-hd,drive=hd -device
scsi-cd,drive=cd").

Thanks,

Paolo


Thanks for the help. Unfortunately trying to boot from the install  
CD leads to the INACCESSIBLE_BOOT_DEVICE error when using SCSI.


Try with 0.12.

Paolo


Here is what I tried and the results:
QEMUWindows NT 4.0 Status
-   
0.9.1   Works
0.10.2  Freezes at the blue startup screen
0.13.0  Freezes at the blue startup screen
1.0.1   Freezes at the blue startup screen

I'm working to find if a single commit broke QEMU's Windows NT 4.0  
compatibility. I think its possible the BIOS might be the issue. 

[Qemu-devel] Moxie target wiki page

[G 3]

I have recent made a wiki page for the Moxie target in QEMU. I need  
some more information on it. Would you know the build directions and  
the suggested command-line for running this target? Any information  
you could supply would be appreciated. Thanks.


Here is the page: http://wiki.qemu.org/Documentation/Platforms/Moxie

[Qemu-devel] New documentation page for MicroBlaze target

[G 3]

I have made a new documentation page for the MicroBlaze target in  
QEMU. If there are any suggestions or additions anyone would like to  
make I would be glad to help.


http://wiki.qemu.org/Documentation/Platforms/MicroBlaze

Re: [Qemu-devel] qemu_system_reset_request() broken w.r.t BQL locking regime

[G 3]

On Jul 5, 2017, at 12:42 PM, qemu-devel-requ...@nongnu.org wrote:


Hi,

An interesting bug was reported on #qemu today. It was bisected to
8d04fb55 (drop global lock for TCG) and only occurred when QEMU was  
run
with taskset -c 0. Originally the fingers where pointed at mttcg  
but it

occurs in both single and multi-threaded modes.

I think the problem is qemu_system_reset_request() is certainly racy
when resetting a running CPU. AFAICT:

  - Guest resets board, writing to some hw address (e.g.
arm_sysctl_write)
  - This triggers qemu_system_reset_request 
(SHUTDOWN_CAUSE_GUEST_RESET)

  - We exit iowrite and drop the BQL
  - vl.c schedules qemu_system_reset- 
>qemu_devices_reset...arm_cpu_reset

  - we start writing new values to CPU env while still in TCG code
  - CHAOS!

The general solution for this is to ensure these sort of tasks are  
done
with safe work in the CPUs context when we know nothing else is  
running.

It seems this is probably best done by modifying
qemu_system_reset_request to queue work up on current_cpu and  
execute it

as safe work - I don't think the vl.c thread should ever be messing
about with calling cpu_reset directly.


Maybe vl.c should be changed so it registers a request to reset the  
emulator instead.


So instead of cpu_reset()

we do

request_cpu_reset()



Looking at the calls most of these are made by device code but I  
see KVM
also does it. I just wanted to check this was a reasonable approach  
and

wouldn't upset anything else.

Any thoughts?


I think the problem with the QEMU monitor command "stop" (which  
causes the emulator to crash) is related to this issue as well.

Re: [Qemu-devel] [PATCH] Improve Cocoa modifier key handling

[G 3]

On Jun 24, 2017, at 8:14 AM, Peter Maydell wrote:

On 23 June 2017 at 21:05, Programmingkid  
 wrote:

This patch is incompatible with anything below Mac OS 10.10.


Oops. Thanks for the report.


We support Mac OS 10.5 and up. I was able to make this patch work
on Mac OS 10.6 by changing this line:

NSEventModifierFlags modifiers = [event modifierFlags];

to this:

NSUInteger modifiers = [event modifierFlags];

This wouldn't be enough. The [event modifierFlags] code would have to
be replaced because the modifierFlags function is not available on
Mac OS 10.5.


Please disregard what I said about the [event modifierFlags] code. It  
turns out it has been available since Mac OS 10.0. Sorry for the  
mistake.




Do you still use 10.5? It's a decade old now, and I notice that
in the QEMU 2.5 changelog we actually said we were going to
remove 10.5 support. So one option would be to simply remove
10.5 support entirely, if nobody needs it any more.


I do have a computer with 10.5 on it. I will be happy to help support  
Mac OS 10.5.

Re: [Qemu-devel] [Qemu-ppc] Floating point unit bugs

[G 3]

On Jun 22, 2017, at 3:25 AM, Peter Maydell wrote:


On 22 June 2017 at 03:54, G 3 <programmingk...@gmail.com> wrote:
The advantage a test image would have is the user doesn't have to  
worry
about compiling a test using a cross compiler. Everything the user  
would

need to test QEMU is already inside the image file (hopefully).

Is the setup you want something like running 'make test' ? I  
imagine binary
files included with QEMU would test the emulated CPU. There would  
be no need

to cross compile anything.


I want our tests to be easy to add new tests for, and easy
for anybody to recreate the binary files. Certainly providing
pre-built binaries would be helpful (faster than rebuilding
whole system images), but we must have an automated mechanism
for saying "build this image from sources" too, so that if
we want to update the test program later it's easy to do that,
or if we want to add a second test that's like the first
one but slightly modified we can easily do that too.


So what you want is a test system that is easy to write. Maybe as  
easy as writing a python script? What I thought up is a collection of  
functions that implement assembly language code. Say you want to make  
a test that runs the fadds instruction. You might run it like this:


def my_float_test:
inputA = 0.5
inputB = 0.25
result = fadds(inputA, inputB)
if result != 0.75:
print("Error with fadds calculation")
if get_FPSCR() != expect_fpscr_value:
print("FPSCR error")


Then all we would be left to figure out is how to turn this code into  
a mach-o or elf binary. Then again this might not be a requirement.  
What if we had python running on the guest. The above code might work  
as is. No cross compiling required.


Implementing the callable assembly language code from python could be  
done using a single command-line program. This program would simply  
receive its arguments and return a value. If this program was called  
assembly _adapter, it would run like this:


% assembly_adapter fadds 0.5 0.25

The return value of this command is where we would see the result.  
This command-line program would only need to be compiled once and  
included with QEMU. The format of this program's arguments would be  
something like this:


This input would probably work for most instructions but doesn't  
necessarily need to be applied to all instructions.


Would this kind of system be something you want? 

Re: [Qemu-devel] [Qemu-ppc] Floating point unit bugs

[G 3]

On Jun 21, 2017, at 12:28 PM, Peter Maydell wrote:


On 21 June 2017 at 17:27, G 3 <programmingk...@gmail.com> wrote:

On Jun 21, 2017, at 12:20 PM, Peter Maydell wrote:

We don't yet have any mechanism for having tests that need to
be compiled for the target architecture, do we?



I don't know about that but I do know we have image files that can  
be booted
in various guest. These image files could include tests like the  
floating

point test.

Here is the link to the test images page:
http://wiki.qemu.org/Testing/System_Images


Yes -- those are almost all very out of date, not reproducible
at all and don't cover very many of our systems, because we
don't have a good mechanism for writing tests that need
to be built for the target architecture. I'd like us to
have a setup so that it's easy to say "just add a new test",
rather than accumulating more random images on the wiki...


The advantage a test image would have is the user doesn't have to  
worry about compiling a test using a cross compiler. Everything the  
user would need to test QEMU is already inside the image file  
(hopefully).


Is the setup you want something like running 'make test' ? I imagine  
binary files included with QEMU would test the emulated CPU. There  
would be no need to cross compile anything. 

Re: [Qemu-devel] [Qemu-ppc] Floating point unit bugs

[G 3]

On Jun 21, 2017, at 12:20 PM, Peter Maydell wrote:

On 21 June 2017 at 17:14, Philippe Mathieu-Daudé   
wrote:
do you think you can add your test as a qtest, to run it with  
check-qtest?


We don't yet have any mechanism for having tests that need to
be compiled for the target architecture, do we?


I don't know about that but I do know we have image files that can be  
booted in various guest. These image files could include tests like  
the floating point test.


Here is the link to the test images page:
http://wiki.qemu.org/Testing/System_Images

Re: [Qemu-devel] [Qemu-ppc] Floating point unit bugs

[G 3]

On Jun 21, 2017, at 12:14 PM, Philippe Mathieu-Daudé wrote:


Hi John,

On 05/09/2017 10:58 AM, G 3 wrote:


On May 9, 2017, at 5:55 AM, BALATON Zoltan wrote:


On Tue, 9 May 2017, Aurelien Jarno wrote:

| main.c: In function 'print_fpscr_settings':
| main.c:73:26: warning: suggest parentheses around comparison in
operand of '&' [-Wparentheses]
|  if ((fpscr >> i) & 0x1 == 1) {
|   ^


Actually the compiler is correct here, this should be:

if ((fpscr >> i & 0x1) == 1) {

or even just

if (fpscr >> i & 1) {

because & is lower priority than == but the result may still be the
same by chance if 0x1 == 1 is always 1 and ANDing the shifted value
with this is either 0 or 1 so it may give the correct result but not
the way one would think looking at the expression.


I changed it to this:
if (((fpscr >> i) & 0x1) == 1)

Thank you.


do you think you can add your test as a qtest, to run it with check- 
qtest?


Regards,

Phil.


I would like to see floating point tests added to QEMU. Problem is  
they will always fail due to a ton of bugs with the floating point unit.

Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts

[G 3]

On Jun 18, 2017, at 4:36 PM, alar...@ddci.com wrote:


G 3 <programmingk...@gmail.com> wrote on 06/18/2017 09:45:25 AM:


From: Aaron Larson <alar...@ddci.com>
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.


I guess I should have asked what differences did you see in QEMU's  
behavior?

Re: [Qemu-devel] [PATCH v3] target-ppc: Enable open-pic timers to count and generate interrupts

[G 3]

On Jun 18, 2017, at 6:50 AM, qemu-devel-requ...@nongnu.org wrote:

On Fri, Jun 16, 2017 at 11:31:02AM -0500, alar...@ddci.com wrote:

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.



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?


Does QEMU behave differently after this patch is implemented? 

Re: [Qemu-devel] [PATCH risu] ppc64: Fix patterns for rotate doubleword instructions

[G 3]

On May 30, 2017, at 8:01 AM, Peter Maydell wrote:


On 25 May 2017 at 21:05,   wrote:

What do you think about sharing the same ppc64.risu file to ppc
and ppc64/ppc64le. Then, instead of:

 PPC64LE 0...

we'd have:

 PPC 0...

So, specific instructions would be:

 PPC64LE 0...
 PPC64 0...
 PPC32 0...

It will allow users to select the arch by using patterns like: ./ 
risugen

--pattern "PPC64*", or --pattern "PPC32*".


I think we should aim to share the files, but that we should
have a better mechanism than just a convention on the pattern
name (which is easy to make mistakes with and also makes it
harder to use the --pattern argument for the purpose it was
intended for, since you have to combine your desired pattern
with the pattern to select the right bit of the instruction set).
This isn't limited to PPC either -- for ARM we'd like to be
able to mark instructions as ARMv7/ARMv8/present in some
optional instruction set extension, etc.


Do you want to add an architecture option?

--pattern 'F.*' --arch PPC32

In this example only the instructions that begin with the letter F  
and have PPC32 as an encodingname are used.




We could perhaps do that with an optional field in the
lines in the risu file to mark what part of the instruction
set they're in, and a command line argument to select the
instruction set variant(s) desired.


I thought we already had this feature.

From the readme file:

insnname encodingname bitfield ... [ [ !blockname ] { blocktext } ]

Isn't the encodingname field the field we could use to select the  
variant we want?




Another possible approach would be to have the PPC32 insns
in their own file, and some sort of #include directive to
pull them into the PPC64 file.

This is all "adding extra features to risu", though, so I
don't insist it be done.


The #include directive does sound interesting but if you really want  
one PowerPC risu file then Jose's way would be the way to go. Risu as  
it is can handle this.

Re: [Qemu-devel] [PATCH risu] ppc64: Fix patterns for rotate doubleword instructions

[G 3]

On May 22, 2017, at 4:32 AM, qemu-devel-requ...@nongnu.org wrote:


Message: 2
Date: Mon, 22 May 2017 12:33:29 +0530
From: Nikunj A Dadhania 
To: Sandipan Das 
Cc: qemu-devel@nongnu.org, peter.mayd...@linaro.org,
jos...@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH risu] ppc64: Fix patterns for rotate
doubleword instructions
Message-ID:
	<87a865nzjy.fsf@abhimanyu.i-did-not-set--mail-host-address--so- 
tickle-me>


Content-Type: text/plain

Sandipan Das  writes:


The patterns for the following instructions are fixed:
 * Rotate Left Doubleword then Clear Right (rldcr[.])
 * Rotate Left Doubleword Immediate then Clear Right (rldicr[.])
 * Rotate Left Doubleword Immediate then Mask Insert (rldimi[.])

Signed-off-by: Sandipan Das 
---
 ppc64.risu | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/ppc64.risu b/ppc64.risu
index 28df9da..0f29248 100644
--- a/ppc64.risu
+++ b/ppc64.risu
@@ -1451,7 +1451,7 @@ RLDCLd PPC64LE 00 rs:5 ra:5 rb:5 mb:6  
10001 \
 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }


 # format:MDS book:I page:103 PPC SR rldcr Rotate Left Dword then  
Clear Right

-RLCDR PPC64LE 00 rs:5 ra:5 rb:5 mb:6 10010 \
+RLDCR PPC64LE 00 rs:5 ra:5 rb:5 mb:6 10010 \
 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }
 # format:MDS book:I page:103 PPC SR rldcr Rotate Left Dword then  
Clear Right

 RLDCRd PPC64LE 00 rs:5 ra:5 rb:5 mb:6 10011 \
@@ -1472,17 +1472,17 @@ RLDICLd PPC64LE 00 rs:5 ra:5 sh:5 mb:6  
000 sha:1 1 \

 !constraints { $rs != 1 && $ra != 1 && $rs != 13 && $ra != 13; }

 # format:MD book:I page:105 PPC SR rldicr[.] Rotate Left Dword  
Immediate then Clear Right

-RLDICR PPC64LE 00 rs:5 ra:5 rb:5 me:6 00010 \
+RLDICR PPC64LE 00 rs:5 ra:5 rb:5 me:6 001 sha:1 0 \


   RLDICR PPC64LE 00 rs:5 ra:5 sh:5 me:6 001 sha:1 0

Also "rb:5" be changed as "sh:5"?

 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }
 # format:MD book:I page:105 PPC SR rldicr[.] Rotate Left Dword  
Immediate then Clear Right

-RLDICRd PPC64LE 00 rs:5 ra:5 rb:5 me:6 00011 \
+RLDICRd PPC64LE 00 rs:5 ra:5 rb:5 me:6 001 sha:1 1 \


   RLDICRd PPC64LE 00 rs:5 ra:5 sh:5 me:6 001 sha:1 0


 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }


 # format:MD book:I page:105 PPC SR rldimi[.] Rotate Left Dword  
Immediate then Mask Insert

-RLDIMI PPC64LE 00 rs:5 ra:5 rb:5 me:6 00110 \
+RLDIMI PPC64LE 00 rs:5 ra:5 rb:5 me:6 011 sha:1 0 \


   RLDIMI PPC64LE 00 rs:5 ra:5 sh:5 me:6 011 sha:1 0


 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }
 # format:MD book:I page:105 PPC SR rldimi[.] Rotate Left Dword  
Immediate then Mask Insert

-RLDIMId PPC64LE 00 rs:5 ra:5 rb:5 me:6 00111 \
+RLDIMId PPC64LE 00 rs:5 ra:5 rb:5 me:6 011 sha:1 1 \


   RLDIMId PPC64LE 00 rs:5 ra:5 sh:5 me:6 011 sha:1 1

 !constraints { $rs != 1 && $ra != 1 && $rb != 1 && $rs != 13 &&  
$ra != 13 && $rb != 13; }


 # format:M book:I page:102 v:P1 SR rlwimi[.] Rotate Left Word  
Immediate then Mask Insert

--
2.7.4


Regards,
Nikunj


Hello I have also done some work risu. My patches add ppc32 support.  
Well my patches were made to work with Mac OS X but they are required  
to work with Linux. Do you think you could help port these patches to  
Linux?


ppc.risu:
https://patchwork.kernel.org/patch/9697489/

risu_ppc.c:
https://patchwork.kernel.org/patch/9697491/

risu_reginfo_ppc.c:
https://patchwork.kernel.org/patch/9697493/

risu_reginfo_ppc.h:
https://patchwork.kernel.org/patch/9697495/

risugen_ppc.pm:
https://patchwork.kernel.org/patch/9697497/

Add ppc support to configure:
https://patchwork.kernel.org/patch/9697499/

Add verbose option:
https://patchwork.kernel.org/patch/9697501/

Add end of test message:
https://patchwork.kernel.org/patch/9697503/

Add more descriptive comment for mismatch or end of test condition:
https://patchwork.kernel.org/patch/9697505/

[Qemu-devel] [PATCH 1/1] Improve Cocoa modifier key handling

[G 3]

On May 13, 2017, at 11:58 AM, qemu-devel-requ...@nongnu.org wrote:



I had two problems with QEMU on macOS:
 1) Sometimes when alt-tabbing to QEMU it would act as if the 'a' key
was pressed so I'd get 'a'.
 2) Using Sikuli to programatically send keys to the QEMU window text
like "foo_bar" would come out as "fooa-bar".

They looked similar and after much digging the problem turned out  
to be

the same. When QEMU's ui/cocoa.m received an NSFlagsChanged NSEvent it
looked at the keyCode to determine what modifier key changed. This
usually works fine but sometimes the keyCode is 0 and the app should
instead be looking at the modifierFlags bitmask. Key code 0 is the 'a'
key.

I added code that handles keyCode == 0 differently. It checks the
modifierFlags and if they differ from QEMU's idea of which modifier
keys are currently pressed it toggles those changed keys.

This fixes my problems and seems work fine.

The patch itself is an attachment.

Ian
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Improve-Cocoa-modifier-key-handling.patch
Type: application/octet-stream
Size: 4920 bytes
Desc: not available
URL: 


Could you send your patch via email to the qemu developer list? I am  
interested in testing it. Attachments don't work here.

Re: [Qemu-devel] Future of SoftFloat use in QEMU

[G 3]

Hi,

We've got a task coming up to implement half-precision floating point
(FP16) for ARMv8.2. As you know pretty much all our floating point in
QEMU is handled by our internal fork of John R. Hauser's BSD SoftFloat
library. Our current implementation is based on version 2a which  
doesn't

support FP16.

As it happens there has been a new release of SoftFloat recently.
Version 3 is a complete re-write which made a number of changes, some
notable ones being:

  - Complete rewrite, different use license than earlier releases.
  - Renaming most types and functions, upgrading some algorithms
- restructuring the source files, and making SoftFloat into a  
true library.
  - Added functions to convert between floating-point and unsigned  
integers,

both 32-bit and 64-bit (uint32_t and uint64_t).
  - Added functions for fused multiply-add, for all supported  
floating-point

formats except 80-bit double-extended-precision.
  - Added support for a fifth rounding mode, near_maxMag (round to  
nearest,

with ties to maximum magnitude, away from zero).

And in the most recent release as of February 2017, 3c:

  - Added optional rounding mode odd (round to odd, also known as  
jamming).
  - Implemented the common 16-bit “half-precision” floating-point  
format

(float16_t)

See: http://www.jhauser.us/arithmetic/SoftFloat-3c/doc/SoftFloat- 
history.html


Of course the softfloat in QEMU's tree hasn't been static either.  
We've

made numerous changes over the years to add and fix various features,
including features that have since been added to the upstream  
softfloat.
It seems unlikely we could switch to the newer softfloat without  
risking

breaking something. However if we look at back-porting stuff from the
newer library we essentially get to own our version of softfloat
forever.

So what else can we do?

We could investigate having both libraries included in QEMU. It seems
the API has changed quite a bit so that might be possible although  
there

would be hackage involved in having two different softfloat.h's
involved.

This would be useful if we wanted to take a piecemeal approach to
updating the library. For example we could just use softfloat3 when we
need the newer features (e.g. FP16).

Or we could convert one architecture at a time so each qemu binary  
links

against either a version 2 or version 3 softfloat library. Of course
that does run the risk of permanently holding two versions of  
softfloat

in the code if the less maintained guest architectures don't convert
quickly.

So any thoughts about what would make the best approach?

--
Alex Bennée



Given all the features this new library has I suggest we do upgrade  
to Softfloat 3c. Your idea on keeping both two versions of this  
library until all targets have been converted sound like an effective  
plan.

Re: [Qemu-devel] [Qemu-ppc] Floating point unit bugs

[G 3]

On May 9, 2017, at 5:55 AM, BALATON Zoltan wrote:


On Tue, 9 May 2017, Aurelien Jarno wrote:

| main.c: In function 'print_fpscr_settings':
| main.c:73:26: warning: suggest parentheses around comparison in  
operand of '&' [-Wparentheses]

|  if ((fpscr >> i) & 0x1 == 1) {
|   ^


Actually the compiler is correct here, this should be:

if ((fpscr >> i & 0x1) == 1) {

or even just

if (fpscr >> i & 1) {

because & is lower priority than == but the result may still be the  
same by chance if 0x1 == 1 is always 1 and ANDing the shifted value  
with this is either 0 or 1 so it may give the correct result but  
not the way one would think looking at the expression.


I changed it to this:
if (((fpscr >> i) & 0x1) == 1)

Thank you.

Re: [Qemu-devel] Floating point unit bugs

[G 3]

Here is version two of the floating point test program:

/ 
 
**

 * File: main.c
 * Date: 4-30-2017
 * Description: Implement a test program for various floating point  
instructions.

 * Note: tests made to work with PowerPC G3 and G5 only.
 * Compiling on Mac OS X: use gcc-3.3 -force_cpusubtype_ALL
 * Note: fsqrt test will not work on PowerPC G3.
 * Version: 2
  
 
**/


#include 
#include 
#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
double d;
uint64_t i;
};

typedef union Converter Converter;

/* Describes the name and description of each bit of the FPSCR */
struct fpscr_info
{
char name[8];
char description[100];
};

struct fpscr_info finfo[] =
{
"FX", "Floating-point exception summary",
"FEX", "Floating-point enabled exception summary",
"VX", "Floating-point invalid operation exception summary",
"OX", "Floating-point overflow exception",
"UX", "Floating-point underflow exception",
"ZX", "Floating-point zero divide exception",
"XX", "Floating-point inexact exception",
"VXSNAN", "Floating-point invalid operation exception for SNaN",
"VXISI", "Floating-point invalid operation exception for ∞ - ∞",
"VXIDI", "Floating-point invalid operation exception for ∞/∞",
"VXZDZ", "Floating-point invalid operation exception for 0/0",
"VXIMZ", "Floating-point invalid operation exception for ∞ * 0",
"VXVC", "Floating-point invalid operation exception for invalid  
compare",

"FR", "Floating-point fraction rounded",
"FI", "Floating-point fraction inexact",
"FPRF", "Floating-point result class descriptor ",
"FPRF", "Floating-point less than or negative",
"FPRF", "Floating-point greater than or positive",
"FPRF", "Floating-point equal or zero",
"FPRF", "Floating-point unordered or NaN",
"NO NAME", "Reserved - you shouldn't be seeing this",
"VXSOFT", "Floating-point invalid operation exception for  
software request",
"VXSQRT", "Floating-point invalid operation exception for  
invalid square root",
"VXCVI", "Floating-point invalid operation exception for invalid  
integer convert",

"VE", "Floating-point invalid operation exception enable",
"OE", "IEEE floating-point overflow exception enable",
"UE", "IEEE floating-point underflow exception enable",
"ZE", "IEEE floating-point zero divide exception enable",
"XE", "Floating-point inexact exception enable",
"NI", "Floating-point non-IEEE mode",
"RN", "Rounding bit 0",
"RN", "Rounding bit 1",
};

// Prints all the FPSCR settings that are set in the input
void print_fpscr_settings(uint32_t fpscr)
{
int i;
for (i = 0; i < 32; i++) {
if ((fpscr >> i) & 0x1 == 1) {
/* right description = 31 - i  Oddity of IBM  
documentation */
printf("bit %d: %s - %s\n", 31-i, finfo[31-i].name, finfo 
[31-i].description);

}
}
}


#define ZE 27
#define set_fpscr_bit(x) asm volatile ("mtfsb1 %0" : : "i"(x))

/* Keeps track of the number of tests that failed */
int failed_tests = 0;

// Reset the FPSCR
void reset_fpscr()
{
asm volatile("mtfsb0 0");
asm volatile("mtfsb0 1");
asm volatile("mtfsb0 2");
asm volatile("mtfsb0 3");
asm volatile("mtfsb0 4");
asm volatile("mtfsb0 5");
asm volatile("mtfsb0 6");
asm volatile("mtfsb0 7");
asm volatile("mtfsb0 8");
asm volatile("mtfsb0 9");
asm volatile("mtfsb0 10");
asm volatile("mtfsb0 11");
asm volatile("mtfsb0 12");
asm volatile("mtfsb0 13");
asm volatile("mtfsb0 14");
asm volatile("mtfsb0 15");
asm volatile("mtfsb0 16");
asm volatile("mtfsb0 17");
asm volatile("mtfsb0 18");
asm volatile("mtfsb0 19");
asm volatile("mtfsb0 20");
asm volatile("mtfsb0 21");
asm volatile("mtfsb0 22");
asm volatile("mtfsb0 23");
asm volatile("mtfsb0 24");
asm volatile("mtfsb0 25");
asm volatile("mtfsb0 26");
asm volatile("mtfsb0 27");
asm volatile("mtfsb0 28");
asm volatile("mtfsb0 29");
asm volatile("mtfsb0 30");
asm volatile("mtfsb0 31");

/* Check if everything is alright */
uint32_t fpscr;
Converter c;
asm volatile("mffs %0" : "=f"(c.d));
fpscr = (uint32_t)c.i;
if (fpscr != 0) {
printf("Warning: fpscr not equal to zero: 0x%x\n", fpscr);
}
}

/*
 * The action to take if a test fails
 * Input one: message string
 * Input two: actual fpscr value
 * Input three: expected fpscr value
 * Input four: actual answer
 * Input five: expected answer
 */
 void test_failed(const char *message, uint32_t actual_fpscr,  
uint32_t expected_fpscr,

  uint64_t actual_answer, uint64_t expected_answer)
 {
printf("%s\n", message);
printf("expected answer: 0x%" PRIx64 " (%f)\n", expected_answer,  

Re: [Qemu-devel] Floating point unit bugs

[G 3]

On May 8, 2017, at 6:13 PM, Aurelien Jarno wrote:


On 2017-05-07 17:48, G 3 wrote:

I made a diagnostic program for the floating point unit. It will test
various PowerPC floating point instructions for compatibility with  
the
PowerPC G3 processor. It was tested on a PowerPC G3 and G5 system.  
The
results of the program in qemu-system-ppc were pretty bad. About  
every

instruction tested is not implemented correctly.

Here is the download link to the program: http://www.mediafire.com/ 
file/6j9tqubvk73lkw1/floating_point_test_program.zip


Some comments on the code.


/* Check if everything is alright */
uint32_t fpscr;
asm volatile("mffs f0");
asm volatile("stfd f0, 40(r1)");
asm volatile("lwz %0, 44(r1)" : "=r"(fpscr));
if (fpscr != 0) {
printf("Warning: fpscr not equal to zero: 0x%x\n", fpscr);
}


This is overly complicated and just doesn't compile with recent GCC
versions.


Which version of GCC had the problem? GCC 5.2 and GCC 3.3 seems to  
work fine. GCC 4.0 did not work. Could you send me the error message?



What about something like:

Converter c;
asm volatile("mffs %0" : "=f"(c.d));
fpscr = (uint32_t)c.i;


This way does work also.





/*
 * The action to take if a test fails
 * Input one: message string
 * Input two: actual fpscr value
 * Input three: expected fpscr value
 * Input four: actual answer
 * Input five: expected answer
 */
 void test_failed(const char *message, uint32_t actual_fpscr,  
uint32_t

expected_fpscr,
  uint64_t actual_answer, uint64_t expected_answer)
 {
printf("%s\n", message);
printf("expected answer: 0x%" PRIx64 "\n", expected_answer);
printf("  actual answer: 0x%" PRIx64 "\n", actual_fpscr);


This is wrong. It should be actual_answer instead of actual_fpscr.  
That

is why all the instructions seems totally wrongly implemented.


Thanks for catching this error. Actually this would only effect the  
"actual answer:" output field. The comparison between expected_answer  
and actual_answer in each individual test is still valid.



Note that
compiling with -Wall would give you a warning:

| main.c: In function ‘test_failed’:
| main.c:146:5: warning: format ‘%llx’ expects argument of type  
‘long long unsigned int’, but argument 2 has type ‘uint32_t’ [- 
Wformat=]

|  printf("  actual answer: 0x%" PRIx64 "\n", actual_fpscr);
|  ^



Replacing actual_fpscr with actual_answer should solve this problem.

Re: [Qemu-devel] Floating point unit bugs

[G 3]

On May 8, 2017, at 5:54 PM, Aurelien Jarno wrote:


On 2017-05-07 17:48, G 3 wrote:

I made a diagnostic program for the floating point unit. It will test
various PowerPC floating point instructions for compatibility with  
the
PowerPC G3 processor. It was tested on a PowerPC G3 and G5 system.  
The
results of the program in qemu-system-ppc were pretty bad. About  
every

instruction tested is not implemented correctly.


I don't say that qemu-system-ppc is bug free, but this looks  
suspicious

that about every instruction is buggy.


I really hope you don't think I'm blaming anyone. I'm only reporting  
the results of the test.



Have you tried to run your
program on a real G3 or G5 system?


Yes. I made sure it ran on a real G3 and G5 system without problem  
before testing it on QEMU. I suspect the Motorola designed G4  
processor will not be compatible. I don't have a working G4 system to  
verify this unfortunately.




[ snip ]



Here is the full test results after running this program in qemu- 
system-ppc

with a Mac OS 10.4 guest:




fadd test failed
expected answer: 0x3ff4
  actual answer: 0x82004024
expected fpscr: 0x82064000
  actual fpscr: 0x82004000


This looks highly suspicious that the actual answer match the expected
answer.


You can use this web page to find the decimal value: http:// 
www6.uniovi.es/~antonio/uned/ieee754/IEEE-754hex64.html


0x3ff4 = 1.2002
0x82004024 = -4.8529708162167760e-299

The expected answer and actual answer are very far from each other.

[Qemu-devel] Floating point unit bugs

[G 3]

I made a diagnostic program for the floating point unit. It will test  
various PowerPC floating point instructions for compatibility with  
the PowerPC G3 processor. It was tested on a PowerPC G3 and G5  
system. The results of the program in qemu-system-ppc were pretty  
bad. About every instruction tested is not implemented correctly.


Here is the download link to the program: http://www.mediafire.com/ 
file/6j9tqubvk73lkw1/floating_point_test_program.zip


Here is the full source code to the program:
/ 
 
**

 * File: main.c
 * Date: 4-30-2017
 * Description: Implement a test program for various floating point  
instructions.

 * Note: tests made to work with PowerPC G3 and G5 only.
 * Compiling on Mac OS X: use gcc-3.3 -force_cpusubtype_ALL
 * Note: fsqrt test will not work on PowerPC G3.
  
 
**/


#include 
#include 
#include 
#include 
#include 

// Used to convert unsigned integer <--> double
union Converter
{
double d;
uint64_t i;
};

typedef union Converter Converter;

/* Describes the name and description of each bit of the FPSCR */
struct fpscr_info
{
char name[8];
char description[100];
};

struct fpscr_info finfo[] =
{
"FX", "Floating-point exception summary",
"FEX", "Floating-point enabled exception summary",
"VX", "Floating-point invalid operation exception summary",
"OX", "Floating-point overflow exception",
"UX", "Floating-point underflow exception",
"ZX", "Floating-point zero divide exception",
"XX", "Floating-point inexact exception",
"VXSNAN", "Floating-point invalid operation exception for SNaN",
"VXISI", "Floating-point invalid operation exception for ∞ - ∞",
"VXIDI", "Floating-point invalid operation exception for ∞/∞",
"VXZDZ", "Floating-point invalid operation exception for 0/0",
"VXIMZ", "Floating-point invalid operation exception for ∞ * 0",
"VXVC", "Floating-point invalid operation exception for invalid  
compare",

"FR", "Floating-point fraction rounded",
"FI", "Floating-point fraction inexact",
"FPRF", "Floating-point result class descriptor ",
"FPRF", "Floating-point less than or negative",
"FPRF", "Floating-point greater than or positive",
"FPRF", "Floating-point equal or zero",
"FPRF", "Floating-point unordered or NaN",
"NO NAME", "Reserved - you shouldn't be seeing this",
"VXSOFT", "Floating-point invalid operation exception for  
software request",
"VXSQRT", "Floating-point invalid operation exception for  
invalid square root",
"VXCVI", "Floating-point invalid operation exception for invalid  
integer convert",

"VE", "Floating-point invalid operation exception enable",
"OE", "IEEE floating-point overflow exception enable",
"UE", "IEEE floating-point underflow exception enable",
"ZE", "IEEE floating-point zero divide exception enable",
"XE", "Floating-point inexact exception enable",
"NI", "Floating-point non-IEEE mode",
"RN", "Rounding bit 0",
"RN", "Rounding bit 1",
};

// Prints all the FPSCR settings that are set in the input
void print_fpscr_settings(uint32_t fpscr)
{
int i;
for (i = 0; i < 32; i++) {
if ((fpscr >> i) & 0x1 == 1) {
/* right description = 31 - i  Oddity of IBM  
documentation */
printf("bit %d: %s - %s\n", 31-i, finfo[31-i].name, finfo 
[31-i].description);

}
}
}


#define ZE 27
#define set_fpscr_bit(x) asm volatile ("mtfsb1 %0" : : "i"(x))

/* Keeps track of the number of tests that failed */
int failed_tests = 0;

// Reset the FPSCR
void reset_fpscr()
{
asm volatile("mtfsb0 0");
asm volatile("mtfsb0 1");
asm volatile("mtfsb0 2");
asm volatile("mtfsb0 3");
asm volatile("mtfsb0 4");
asm volatile("mtfsb0 5");
asm volatile("mtfsb0 6");
asm volatile("mtfsb0 7");
asm volatile("mtfsb0 8");
asm volatile("mtfsb0 9");
asm volatile("mtfsb0 10");
asm volatile("mtfsb0 11");
asm volatile("mtfsb0 12");
asm volatile("mtfsb0 13");
asm volatile("mtfsb0 14");
asm volatile("mtfsb0 15");
asm volatile("mtfsb0 16");
asm volatile("mtfsb0 17");
asm volatile("mtfsb0 18");
asm volatile("mtfsb0 19");
asm volatile("mtfsb0 20");
asm volatile("mtfsb0 21");
asm volatile("mtfsb0 22");
asm volatile("mtfsb0 23");
asm volatile("mtfsb0 24");
asm volatile("mtfsb0 25");
asm volatile("mtfsb0 26");
asm volatile("mtfsb0 27");
asm volatile("mtfsb0 28");
asm volatile("mtfsb0 29");
asm volatile("mtfsb0 30");
asm volatile("mtfsb0 31");

/* Check if everything is alright */
uint32_t fpscr;
asm volatile("mffs f0");
asm volatile("stfd f0, 40(r1)");
asm volatile("lwz %0, 44(r1)" : "=r"(fpscr));
if (fpscr != 0) {
printf("Warning: fpscr not equal to zero: 0x%x\n", fpscr);
}
}

[Qemu-devel] risugen: test only instructions that begin with the letter F

[G 3]

I'm trying to test all the floating point instructions only. They  
tend to begin with the letter f. Is there a way to have risugen only  
use instructions that begin with the letter F?

[Qemu-devel] Help with MIPS documentation

[G 3]

A MIPS page has just been put up here: http://wiki.qemu.org/ 
Documentation/Platforms/MIPS


I have tried to give as much info as I could about MIPS and QEMU but  
I am no MIPS expert. What I need are pictures of qemu-system-mips in  
action and any other information that could be provided. Other things  
that would be useful:


Guest operating system status:
- Windows NT 3.5
- Windows NT 4.0
- IRIX
- Linux
- Any other operating systems I may have missed

Example command lines for running qemu-system-mips would be very  
helpful.


Links to MIPS software that could run in qemu-system-mips.

Any help would be appreciated.

Re: [Qemu-devel] [PATCH 1/9] Add ppc.risu file

[G 3]

On Apr 25, 2017, at 9:16 AM, Eric Blake wrote:


On 04/24/2017 10:17 PM, G 3 wrote:

Add the ppc.risu file. It defines the format for various PowerPC
instructions.


Your emails are missing In-Reply-To and References headers, which  
means

you posted 10 top-level threads instead of 9 replies to the 0/9 cover
letter. Please fix that, as it becomes awkward to track a series  
that is

not properly threaded.


I did try to use git send-email but it failed. It was due to some  
missing perl module. The computer I had to use to test risu on is 12  
years old. I expected there to be some software incompatibilities.

Re: [Qemu-devel] [PATCH 2/9] Add risu_ppc.c file

[G 3]

On Apr 25, 2017, at 4:36 AM, Peter Maydell wrote:


On 25 April 2017 at 04:18, G 3 <programmingk...@gmail.com> wrote:

Add the risu_ppc.c file. It defines several functions used by risu.

Signed-off-by: John Arbuckle <programmingk...@gmail.com>
---
 risu_ppc.c | 41 +
 1 file changed, 41 insertions(+)
 create mode 100644 risu_ppc.c

diff --git a/risu_ppc.c b/risu_ppc.c
new file mode 100644
index 000..70a1cf7
--- /dev/null
+++ b/risu_ppc.c
@@ -0,0 +1,41 @@
+/*
+ * File: risu_ppc.c
+ * Date: 3-27-2017
+ * Description: Implement advance_pc(), set_ucontext_paramreg(),
+ *  get_reginfo_paramreg(), get_risuop()
+ */
+
+#include "risu.h"
+
+/* Advances the program counter register to the next instruction */
+void advance_pc(void *vuc)
+{
+ucontext_t *uc = (ucontext_t*)vuc;
+uc->uc_mcontext->ss.srr0 += 4;
+}
+
+/* Sets register r0 to the address of a memory block. */
+void set_ucontext_paramreg(void *vuc, uint64_t value)
+{
+ucontext_t *uc = vuc;
+uc->uc_mcontext->ss.r0 = value;
+}


This doesn't look like it matches the Linux PPC uc_mcontext
struct, which (like the ppc64 one) has a uc_mcontext.regs
field, not uc_mcontext->ss.

Risu is a Linux program, so all CPU backends must build
on Linux. It could perhaps be ported to other host OSes,
but we'd need to put in more infrastructure for dealing
with host OS differences, not just have "PPC works only
on OSX and the others work only on Linux".

thanks
-- PMM


What about having it work on both Mac OS X and Linux? A few #ifdef's  
should work.

Re: [Qemu-devel] [PATCH 3/9] Add risu_reginfo_ppc.c file

[G 3]

On Apr 25, 2017, at 4:17 AM, Peter Maydell wrote:


On 25 April 2017 at 04:19, G 3 <programmingk...@gmail.com> wrote:
Add the risu_reginfo_ppc.c file. It handles operations involving  
the reginfo

structure.



+/* check each floating point register */
+for (i = 0; i < NUMBER_OF_FPR; i++) {
+if (r1->fpr[i] != r2->fpr[i]) {
+if (!(isnan(r1->fpr[i]) && isnan(r2->fpr[i]))) {
+if ( fabs(r1->fpr[i] - r2->fpr[i]) < 0.01) {
+debug_print("float point register %d mismatch
detected\n", i);
+return 0;
+}


This is definitely wrong. Risu is supposed to check for exact
binary correctness, so you simply want to compare the binary
values of the FP regs, not check whether they're vaguely
close to the right answer.


Remove the isnan and fabs lines?



+/*
+ * Shows the classification of a floating point value.
+ * Input: floating point value
+ * Output: string description
+ */
+const char *show_classification(double x) {
+switch(fpclassify(x)) {
+case FP_INFINITE:  return "Inf";
+case FP_NAN:   return "NaN";
+case FP_NORMAL:return "normal";
+case FP_SUBNORMAL: return "subnormal";
+case FP_ZERO:  return "zero";
+default:   return "unknown";
+}
+}


None of the other backends do this. If we want to do it
(and I'm not convinced it's worth the effort) we should
do it consistently everywhere.


It does help with understanding what is different with two floating  
point values. But if you don't want it removing it is fine with me.

Re: [Qemu-devel] [PATCH 1/9] Add ppc.risu file

[G 3]

On Apr 25, 2017, at 4:14 AM, Peter Maydell wrote:


On 25 April 2017 at 04:17, G 3 <programmingk...@gmail.com> wrote:

Add the ppc.risu file. It defines the format for various PowerPC
instructions.

Signed-off-by: John Arbuckle <programmingk...@gmail.com>
---
 ppc.risu | 527
+++
 1 file changed, 527 insertions(+)
 create mode 100644 ppc.risu

diff --git a/ppc.risu b/ppc.risu
new file mode 100644
index 000..b6d6aee
--- /dev/null
+++ b/ppc.risu
@@ -0,0 +1,527 @@
+ 
###

+# File: ppc.risu
+# Date: 3-27-2017
+# Description: Specifies PowerPC instruction test patterns.
+ 
###


Missing copyright and license statement.


+
+.mode ppc
+
+# Note: register r1 cannot be used because it is the stack pointer.
+# The branching, VEA, and OEA instructions cannot be used here  
currently.

+
+ADD PPC 01 rD:5 rA:5 rB:5 OE:1 11010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ADDC PPC 01 rD:5 rA:5 rB:5 OE:1 01010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ADDE PPC 01 rD:5 rA:5 rB:5 OE:1 010001010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }



There's an awful lot of duplication with ppc64 here. Is it
worth trying to share?


thanks
-- PMM


That would be difficult. There are a lot of new instructions in ppc64  
that don't exist in ppc32.

[Qemu-devel] [PATCH 9/9] Add more descriptive comment for mismatch or end of test condition

[G 3]

Replace the comment "mismatch, or end of test" with "called for a  
mismatch,

or for the end of a test". This describes what happens better.

Signed-off-by: John Arbuckle 
---
 risu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/risu.c b/risu.c
index e7cbd57..bd771b1 100644
--- a/risu.c
+++ b/risu.c
@@ -48,7 +48,7 @@ void master_sigill(int sig, siginfo_t *si, void *uc)
  advance_pc(uc);
  return;
   default:
- /* mismatch, or end of test */
+ /* called for a mismatch, or for the end of a test */
  siglongjmp(jmpbuf, 1);
}
 }
--
2.10.2

[Qemu-devel] [PATCH 7/9] Add verbose option

[G 3]

Add an option that prints each instruction that is currently being  
tested.

To use this option, just add "--v" to risu's command-line.

Signed-off-by: John Arbuckle 
---
 risu.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/risu.c b/risu.c
index 7e42160..ed5b605 100644
--- a/risu.c
+++ b/risu.c
@@ -37,6 +37,8 @@ sigjmp_buf jmpbuf;
 /* Should we test for FP exception status bits? */
 int test_fp_exc = 0;

+int verbose_mode = 0;
+
 void master_sigill(int sig, siginfo_t *si, void *uc)
 {
switch (recv_and_compare_register_info(master_socket, uc))
@@ -125,7 +127,8 @@ int master(int sock)
 {
if (sigsetjmp(jmpbuf, 1))
{
-  return report_match_status();
+int return_status = report_match_status();
+exit(return_status);
}
master_socket = sock;
set_sigill_handler(_sigill);
@@ -177,6 +180,7 @@ int main(int argc, char **argv)
 { "host", required_argument, 0, 'h' },
 { "port", required_argument, 0, 'p' },
 { "test-fp-exc", no_argument, _fp_exc, 1 },
+{ "verbose testing", no_argument, 0, 'v'},
 { 0,0,0,0 }
  };
   int optidx = 0;
@@ -209,6 +213,11 @@ int main(int argc, char **argv)
 usage();
 exit(1);
  }
+ case 'v':  /* Prints each instruction being tested */
+ {
+verbose_mode = 1;
+break;
+ }
  default:
 abort();
   }
--
2.10.2

[Qemu-devel] [PATCH 8/9] Add end of test message

[G 3]

Print the message "End of test" on the risu host end.

Signed-off-by: John Arbuckle 
---
 risu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/risu.c b/risu.c
index ed5b605..e7cbd57 100644
--- a/risu.c
+++ b/risu.c
@@ -63,6 +63,7 @@ void apprentice_sigill(int sig, siginfo_t *si, void  
*uc)

  return;
   case 1:
  /* end of test */
+ printf("End of test\n");
  exit(0);
   default:
  /* mismatch */
--
2.10.2

[Qemu-devel] [PATCH 6/9] Add ppc support to configure

[G 3]

Add ppc support to the configure script.

Signed-off-by: John Arbuckle 
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 055e6d6..7881b18 100755
--- a/configure
+++ b/configure
@@ -56,6 +56,8 @@ guess_arch() {
 else
 ARCH="ppc64le"
 fi
+elif check_define __ppc__ ; then
+ARCH="ppc"
 else
 echo "This cpu is not supported by risu. Try -h. " >&2
 exit 1
@@ -92,7 +94,7 @@ Some influential environment variables:
prefixed with the given string.

   ARCH force target architecture instead of trying to  
detect it.

-   Valid values=[arm|aarch64|ppc64|ppc64le|m68k]
+   Valid values=[arm|aarch64|ppc64|ppc64le|m68k|ppc]

   CC   C compiler command
   CFLAGS   C compiler flags
--
2.10.2

[Qemu-devel] [PATCH 5/9] Add risugen_ppc.pm file

[G 3]

Add the risugen_ppc.pm file. It is used to generate the instructions  
that risu

runs.

Signed-off-by: John Arbuckle 
---
 risugen_ppc.pm | 744 +++ 
++

 1 file changed, 744 insertions(+)
 create mode 100644 risugen_ppc.pm

diff --git a/risugen_ppc.pm b/risugen_ppc.pm
new file mode 100644
index 000..2faae81
--- /dev/null
+++ b/risugen_ppc.pm
@@ -0,0 +1,744 @@
+#!/usr/bin/perl -w
+### 


+# File: risugen_ppc.pm
+# Date: 4-14-2017
+# Description: Perl module for generating PowerPC instructions with  
risugen.

+# Based on Jose Ricardo Ziviani (IBM) - ppc64 implementation
+### 


+
+# risugen -- generate a test binary file for use with risu
+# See 'risugen --help' for usage information.
+package risugen_ppc;
+
+use strict;
+use warnings;
+use bigint;
+use risugen_common;
+
+require Exporter;
+
+our @ISA= qw(Exporter);
+our @EXPORT = qw(write_test_code);
+
+# Has all debug messages printed if set to 1
+my $debug = 0;
+
+# First available slot in the stack
+my $available_stack_slot = 40;
+
+my $OP_COMPARE = 0;# compare registers
+my $OP_TESTEND = 1;# end of test, stop
+
+# prints debugging information if DEBUG is set to 1
+sub debug_print {
+if ($debug == 1) {
+my $test = sprintf(shift, @_);
+print $test;
+}
+}
+
+# setup the environment for a memory access involving two registers
+# first input: general purpose register rA
+# second input: general purpose register rB
+sub reg_plus_reg($$)
+{
+my ($rA, $rB) = @_;
+my $value;
+my $low_bits;
+my $high_bits;
+
+$value = rand();
+
+# Has to be loaded like this because we can't just load a 32 bit  
value

+$low_bits = $value & 0x;
+$high_bits = $value >> 16;
+
+# Add a value into the expected memory location
+write_lis(10, $high_bits);  # lis r10, $high_bits
+write_ori(10, 10, $low_bits);   # ori r10, r10, $low_bits
+write_stw(10, $available_stack_slot);   # stw r10,  
$available_stack_slot(r1)

+
+# setup the two registers to find the memory location
+write_mr($rA, 1);   # mr $rA, r1
+write_li($rB, $available_stack_slot);   # li $rB,  
$available_stack_slot

+return $rA;
+}
+
+# Handle register + immediate addressing mode
+# first input: base register
+# second input: immediate value (offset)
+sub reg_plus_imm($$)
+{
+my ($base_register, $number) = @_;
+
+# load a random floating point value into memory
+my $float_value = rand();
+my $ieee_value = convert_to_IEEE($float_value);
+my $ieee_high_bits; # the upper 16 bits of $ieee_value
+my $ieee_low_bits;  # the lower 16 bits of $ieee_value
+
+$ieee_high_bits = $ieee_value >> 16;
+$ieee_low_bits = $ieee_value & 0x;
+write_lis(10, $ieee_high_bits);   # lis r10, $ieee_high_bits
+write_ori(10, 10, $ieee_low_bits);# ori r10, r10,  
$ieee_low_bits

+write_stw(10, $number);   # stw r10, $number(r1)
+write_mr($base_register, 1);  # mr $base_register, r1
+return $base_register;
+}
+
+# convert float value to IEEE 754
+# input: floating point value (e.g. 1.23)
+# output: IEEE 754 single precision value
+sub convert_to_IEEE($)
+{
+my $float_value = $_[0];
+my $ieee_value = unpack "L", pack "f", $float_value;
+return $ieee_value;
+}
+
+# returns a random double precision IEEE 754 value
+# output: 64 bit number
+sub get_random_IEEE_double_value()
+{
+my @number_array = (0x40270, 0x405EDCCD,
+0x40700A66, 0x412E240CA45A1CAC,
+0x407C3E8F5C28F5C3, 0x408DBF189374BC6A);
+my $size_of_array = scalar @number_array;
+my $index = int rand($size_of_array);
+return $number_array[$index];
+}
+
+# writes ppc assembly code to load a IEEE 754 double value
+# input one: general purpose register number
+# input two: immediate value (offset)
+# output: IEEE 754 double value
+sub load_double_float_imm($$)
+{
+my ($rA, $number) = @_;
+
+my $ieee_double;   # ieee 754 double float value
+my $ieee_high_bits; # the upper 16 bits of $ieee_double
+my $ieee_low_bits;  # the lower 16 bits of $ieee_double
+my $higher_32_bits;
+my $lower_32_bits;
+
+$ieee_double = get_random_IEEE_double_value();
+
+# loading a 64 bit double value is going to take some work
+
+# load the higher 32 bits
+$higher_32_bits = $ieee_double >> 32;  # push the lower 32 bits out
+$ieee_high_bits = $higher_32_bits >> 16;
+$ieee_low_bits = $higher_32_bits & 0x;
+write_lis(10, $ieee_high_bits);   # lis r10, $ieee_high_bits
+write_ori(10, 10, $ieee_low_bits);# ori r10, r10,  
$ieee_low_bits

+write_stw(10, $number);   # stw r10, $number(r1)
+

[Qemu-devel] [PATCH 4/9] Add risu_reginfo_ppc.h file

[G 3]

Add the risu_reginfo_ppc.h file. It defines the reginfo structure.

Signed-off-by: John Arbuckle 
---
 risu_reginfo_ppc.h | 32 
 1 file changed, 32 insertions(+)
 create mode 100644 risu_reginfo_ppc.h

diff --git a/risu_reginfo_ppc.h b/risu_reginfo_ppc.h
new file mode 100644
index 000..c3b342d
--- /dev/null
+++ b/risu_reginfo_ppc.h
@@ -0,0 +1,32 @@
+/**
+ * File: risu_reginfo_ppc.h
+ * Description: 32 bit powerpc registers
+ * Date: 3-26-2017
+ **/
+
+#ifndef RISU_REGINFO_PPC_H
+#define RISU_REGINFO_PPC_H
+
+struct reginfo
+{
+uint32_t faulting_insn;
+uint32_t previous_instruction;  /* The instruction before the  
faulting instruction */
+uint32_t second_previous_instruction;  /* The second instruction  
before the faulting instruction */

+
+/** User Model UISA */
+
+uint32_t gpr[32];/* General Purpose Registers */
+double fpr[32];  /* Floating-point Registers */
+uint32_t cr; /* Condition Register */
+uint32_t fpscr;  /* Floating-point Status and Control  
Register */

+uint32_t xer;/* Fixed-point Exception Register */
+uint32_t lr; /* Link Register */
+uint32_t ctr;/* Count Register */
+
+/*
+ * Since we can't test any registers in the Supervisor Model,  
they are not

+ * included.
+ */
+};
+
+#endif /* RISU_REGINFO_PPC_H */
--
2.10.2

[Qemu-devel] [PATCH 3/9] Add risu_reginfo_ppc.c file

[G 3]

Add the risu_reginfo_ppc.c file. It handles operations involving the  
reginfo

structure.

Signed-off-by: John Arbuckle 
---
 risu_reginfo_ppc.c | 273 +++ 
++

 1 file changed, 273 insertions(+)
 create mode 100644 risu_reginfo_ppc.c

diff --git a/risu_reginfo_ppc.c b/risu_reginfo_ppc.c
new file mode 100644
index 000..123e5fa
--- /dev/null
+++ b/risu_reginfo_ppc.c
@@ -0,0 +1,273 @@
+/***
+ * File: risu_reginfo_ppc.c
+ * Description: PowerPC register validation code.
+ * Note: This file was made to work on Mac OS X.
+ * Date: 3-26-2017
+ ***/
+
+#include 
+#include 
+#include 
+
+#include "risu.h"
+#include "risu_reginfo_ppc.h"
+
+#define NUMBER_OF_GPR 32/* Number of general purpose registers */
+#define NUMBER_OF_FPR 32/* Number of floating point registers */
+#define DEBUG 0 /* Set to 1 for debug printing */
+#define debug_print(...) \
+do { if (DEBUG) fprintf(stderr, __VA_ARGS__); } while (0)
+
+extern int verbose_mode;
+
+/* reginfo_init: initialize with a ucontext */
+void reginfo_init(struct reginfo *ri, ucontext_t *uc)
+{
+debug_print("reginfo_init() called\n");
+
+int i;
+
+/* init the program counter (PC) */
+ri->faulting_insn = *((uint32_t *)uc->uc_mcontext->ss.srr0);
+
+/* Tells use the instruction that ran before any problem was  
detected */
+ri->previous_instruction = *((uint32_t *)(uc->uc_mcontext- 
>ss.srr0 - 4));

+
+/*
+ * Tells the second from faulting instruction that caused a  
problem. Needed
+ * because the cleanup instruction for the register that held a  
memory

+ * address is in the way.
+ */
+ ri->second_previous_instruction = *((uint32_t *)(uc- 
>uc_mcontext->ss.srr0 - 8));

+
+/* Displays each instruction and the previous instruction being  
tested */

+if(verbose_mode) {
+printf("testing instruction: 0x%08x 0x%08x\n", ri- 
>previous_instruction

+  , ri->second_previous_instruction);
+}
+
+/* init the general purpose registers */
+ri->gpr[0] = uc->uc_mcontext->ss.r0;
+ri->gpr[1] = 0xdeadbeef;/* stack pointer */
+ri->gpr[2] = uc->uc_mcontext->ss.r2;
+ri->gpr[3] = uc->uc_mcontext->ss.r3;
+ri->gpr[4] = uc->uc_mcontext->ss.r4;
+ri->gpr[5] = uc->uc_mcontext->ss.r5;
+ri->gpr[6] = uc->uc_mcontext->ss.r6;
+ri->gpr[7] = uc->uc_mcontext->ss.r7;
+ri->gpr[8] = uc->uc_mcontext->ss.r8;
+ri->gpr[9] = uc->uc_mcontext->ss.r9;
+ri->gpr[10] = uc->uc_mcontext->ss.r10;
+ri->gpr[11] = uc->uc_mcontext->ss.r11;
+ri->gpr[12] = uc->uc_mcontext->ss.r12;
+ri->gpr[13] = uc->uc_mcontext->ss.r13;
+ri->gpr[14] = uc->uc_mcontext->ss.r14;
+ri->gpr[15] = uc->uc_mcontext->ss.r15;
+ri->gpr[16] = uc->uc_mcontext->ss.r16;
+ri->gpr[17] = uc->uc_mcontext->ss.r17;
+ri->gpr[18] = uc->uc_mcontext->ss.r18;
+ri->gpr[19] = uc->uc_mcontext->ss.r19;
+ri->gpr[20] = uc->uc_mcontext->ss.r20;
+ri->gpr[21] = uc->uc_mcontext->ss.r21;
+ri->gpr[22] = uc->uc_mcontext->ss.r22;
+ri->gpr[23] = uc->uc_mcontext->ss.r23;
+ri->gpr[24] = uc->uc_mcontext->ss.r24;
+ri->gpr[25] = uc->uc_mcontext->ss.r25;
+ri->gpr[26] = uc->uc_mcontext->ss.r26;
+ri->gpr[27] = uc->uc_mcontext->ss.r27;
+ri->gpr[28] = uc->uc_mcontext->ss.r28;
+ri->gpr[29] = uc->uc_mcontext->ss.r29;
+ri->gpr[30] = uc->uc_mcontext->ss.r30;
+ri->gpr[31] = uc->uc_mcontext->ss.r31;
+
+/* init the floating-point registers */
+for (i = 0; i < NUMBER_OF_FPR; i++) {
+ri->fpr[i] = uc->uc_mcontext->fs.fpregs[i];
+}
+
+/* init the condition register */
+ri->cr = uc->uc_mcontext->ss.cr;
+
+/* init the floating point status and control register */
+ri->fpscr = uc->uc_mcontext->fs.fpscr;
+
+/* init the fixed-point exception register */
+ri->xer = uc->uc_mcontext->ss.xer;
+
+/* init the link register */
+ri->lr = uc->uc_mcontext->ss.lr;
+
+/* init the count register */
+ri->ctr = uc->uc_mcontext->ss.ctr;
+}
+
+/* reginfo_is_eq: compare the reginfo structs, returns nonzero if  
equal */

+int reginfo_is_eq(struct reginfo *r1, struct reginfo *r2)
+{
+debug_print("reginfo_is_eq() called\n");
+
+int i;
+
+/* check each general purpose register */
+for (i = 0; i < NUMBER_OF_GPR; i++) {
+if (r1->gpr[i] != r2->gpr[i]) {
+debug_print("general purpose register %d mismatch  
detected\n", i);

+return 0;
+}
+}
+
+/* check each floating point register */
+for (i = 0; i < NUMBER_OF_FPR; i++) {
+if (r1->fpr[i] != r2->fpr[i]) {
+if (!(isnan(r1->fpr[i]) && isnan(r2->fpr[i]))) {
+if ( fabs(r1->fpr[i] - r2->fpr[i]) < 0.01) {
+debug_print("float point register %d mismatch  
detected\n", 

[Qemu-devel] [PATCH 2/9] Add risu_ppc.c file

[G 3]

Add the risu_ppc.c file. It defines several functions used by risu.

Signed-off-by: John Arbuckle 
---
 risu_ppc.c | 41 +
 1 file changed, 41 insertions(+)
 create mode 100644 risu_ppc.c

diff --git a/risu_ppc.c b/risu_ppc.c
new file mode 100644
index 000..70a1cf7
--- /dev/null
+++ b/risu_ppc.c
@@ -0,0 +1,41 @@
+/*
+ * File: risu_ppc.c
+ * Date: 3-27-2017
+ * Description: Implement advance_pc(), set_ucontext_paramreg(),
+ *  get_reginfo_paramreg(), get_risuop()
+ */
+
+#include "risu.h"
+
+/* Advances the program counter register to the next instruction */
+void advance_pc(void *vuc)
+{
+ucontext_t *uc = (ucontext_t*)vuc;
+uc->uc_mcontext->ss.srr0 += 4;
+}
+
+/* Sets register r0 to the address of a memory block. */
+void set_ucontext_paramreg(void *vuc, uint64_t value)
+{
+ucontext_t *uc = vuc;
+uc->uc_mcontext->ss.r0 = value;
+}
+
+/*
+ * Returns the register that keeps track of a memory block address.
+ * Used for the load and store to memory instructions like LFD.
+ * Returns general purpose register r0.
+ */
+uint64_t get_reginfo_paramreg(struct reginfo *ri)
+{
+return ri->gpr[0];
+}
+
+int get_risuop(struct reginfo *ri)
+{
+uint32_t insn = ri->faulting_insn;
+uint32_t op = insn & 0xf;
+uint32_t key = insn & ~0xf;
+uint32_t risukey = 0x5af0;
+return (key != risukey) ? -1 : op;
+}
--
2.10.2

[Qemu-devel] [PATCH 1/9] Add ppc.risu file

[G 3]

Add the ppc.risu file. It defines the format for various PowerPC  
instructions.


Signed-off-by: John Arbuckle 
---
 ppc.risu | 527 + 
++

 1 file changed, 527 insertions(+)
 create mode 100644 ppc.risu

diff --git a/ppc.risu b/ppc.risu
new file mode 100644
index 000..b6d6aee
--- /dev/null
+++ b/ppc.risu
@@ -0,0 +1,527 @@
+### 


+# File: ppc.risu
+# Date: 3-27-2017
+# Description: Specifies PowerPC instruction test patterns.
+### 


+
+.mode ppc
+
+# Note: register r1 cannot be used because it is the stack pointer.
+# The branching, VEA, and OEA instructions cannot be used here  
currently.

+
+ADD PPC 01 rD:5 rA:5 rB:5 OE:1 11010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ADDC PPC 01 rD:5 rA:5 rB:5 OE:1 01010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ADDE PPC 01 rD:5 rA:5 rB:5 OE:1 010001010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ADDI PPC 001110 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+ADDIC PPC 001100 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+# ADDIC. and ADDIC are two different instructions
+ADDICp PPC 001101 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+ADDIS PPC 00 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+ADDME PPC 01 rD:5 rA:5 0 OE:1 011101010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1; }
+
+ADDZE PPC 01 rD:5 rA:5 0 OE:1 011001010 Rc:1 \
+!constraints { $rD != 1 && $rA != 1; }
+
+AND PPC 01 rD:5 rA:5 rB:5 011100 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+ANDC PPC 01 rD:5 rA:5 rB:5 00 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+# ANDI. - p stands for period
+ANDIp PPC 011100 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+# ANDIS. - p stands for period
+ANDISp PPC 011101 rD:5 rA:5 imm:16 \
+!constraints { $rD != 1 && $rA != 1; }
+
+# For the CMP* instructions, if you want to test the PowerPC G5, set  
L to 1

+# in the constraints.
+
+CMP PPC 01 crfD:3 0 L:1 rA:5 rB:5 00 0 \
+!constraints { $rA != 1 && $rB != 1 && $L == 0; }
+
+CMPI PPC 001011 crfD:3 0 L:1 rA:5 imm:16 \
+!constraints { $rA != 1 && $L == 0; }
+
+CMPL PPC 01 crfD:3 0 L:1 rA:5 rB:5 10 0 \
+!constraints { $rA != 1 && $rB == 1 && $L == 0; }
+
+CMPLI PPC 001010 crfD:3 0 L:1 rA:5 imm:16 \
+!constraints { $rA != 1 && $L == 0; }
+
+CNTLZWX PPC 01 rS:5 rA:5 0 011010 Rc:1 \
+!constraints { $rS != 1 && $rA != 1; }
+
+CRAND PPC 010011 crbD:5 crbA:5 crbB:5 010001 0
+
+CRANDC PPC 010011 crbD:5 crbA:5 crbB:5 001001 0
+
+CREQV PPC 010011 crbD:5 crbA:5 crbB:5 010011 0
+
+CRNAND PPC 010011 crbD:5 crbA:5 crbB:5 001111 0
+
+CRNOR PPC 010011 crbD:5 crbA:5 crbB:5 11 0
+
+CROR PPC 010011 crbD:5 crbA:5 crbB:5 011101 0
+
+CRORC PPC 010011 crbD:5 crbA:5 crbB:5 011011 0
+
+CRXOR PPC 010011 crbD:5 crbA:5 crbB:5 001101 0
+
+DIVW PPC 01 rD:5 rA:5 rB:5 OE:1 01011 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+DIVWU PPC 01 rD:5 rA:5 rB:5 OE:1 111001011 Rc:1 \
+!constraints { $rD != 1 && $rA != 1 && $rB != 1; }
+
+EQV PPC 01 rS:5 rA:5 rB:5 0100011100 Rc:1 \
+!constraints { $rS != 1 && $rA != 1 && $rB != 1; }
+
+EXTSB PPC 01 rS:5 rA:5 0 1110111010 Rc:1 \
+!constraints { $rS != 1 && $rA != 1; }
+
+EXTSH PPC 01 rS:5 rA:5 0 1110011010 Rc:1 \
+!constraints { $rS != 1 && $rA != 1; }
+
+FABS PPC 11 fD:5 0 fB:5 011000 Rc:1
+
+FADD PPC 11 fD:5 fA:5 fB:5 0 10101 Rc:1
+
+FADDS PPC 111011 fD:5 fA:5 fB:5 0 10101 Rc:1
+
+FCMPO PPC 11 crfD:3 00 fA:5 fB:5 10 0
+
+FCMPU PPC 11 crfD:3 00 fA:5 fB:5 00 0
+
+FCTIW PPC 11 fD:5 0 fB:5 0011100
+
+FCTIWZ PPC 11 fD:5 0 fB:5 00 Rc:1
+
+FDIV PPC 11 fD:5 fA:5 fB:5 0 10010 Rc:1
+
+FDIVS PPC 111011 fD:5 fA:5 fB:5 0 10010 Rc:1
+
+FMADD PPC 11 fD:5 fA:5 fB:5 fC:5 11101 Rc:1
+
+FMADDS PPC 111011 fD:5 fA:5 fB:5 fC:5 11101 Rc:1
+
+FMR PPC 11 fD:5 0 fB:5 0001001000 Rc:1
+
+FMSUB PPC 11 fD:5 fA:5 fB:5 fC:5 11100 Rc:1
+
+FMSUBS PPC 111011 fD:5 fA:5 fB:5 fC:5 11100 Rc:1
+
+FMUL PPC 11 fD:5 fA:5 0 fC:5 11001 Rc:1
+
+FMULS PPC 111011 fD:5 fA:5 0 fC:5 11001 Rc:1
+
+FNABS PPC 11 fD:5 0 fB:5 0010001000 Rc:1
+
+FNEG PPC 11 fD:5 0 fB:5 101000 Rc:1
+
+FNMADD PPC 11 fD:5 fA:5 fB:5 fC:5 1 Rc:1
+
+FNMADDS PPC 111011 fD:5 fA:5 fB:5 fC:5 1 Rc:1
+
+FNMSUB PPC 11 fD:5 fA:5 fB:5 fC:5 0 Rc:1
+
+FNMSUBS PPC 111011 fD:5 fA:5 fB:5 fC:5 0 Rc:1
+
+# The value placed into register fD may vary between implementations  
- too hard to test

+#FRES PPC 111011 fD:5 0 fB:5 0 11000 Rc:1
+
+FRSP PPC 11 fD:5 0 

[Qemu-devel] [PATCH 0/9] Add PowerPC support to risu

[G 3]

Makes risu usable on a PowerPC Macintosh running Mac OS X.

John Arbuckle (9):
  Add ppc.risu file.
  Add risu_ppc.c file.
  Add risu_reginfo_ppc.c file.
  Add risu_reginfo_ppc.h file
  Add risugen_ppc.pm file.
  Add ppc support to configure
  Add verbose option.
  Add end of test message
  Add more descriptive comment for mismatch or end of test condition.

 configure  |   4 +-
 ppc.risu   | 527 +
 risu.c |  14 +-
 risu_ppc.c |  41 +++
 risu_reginfo_ppc.c | 273 
 risu_reginfo_ppc.h |  32 +++
 risugen_ppc.pm | 744 +++ 
++

 7 files changed, 1632 insertions(+), 3 deletions(-)
 create mode 100644 ppc.risu
 create mode 100644 risu_ppc.c
 create mode 100644 risu_reginfo_ppc.c
 create mode 100644 risu_reginfo_ppc.h
 create mode 100644 risugen_ppc.pm

--
2.10.2

[Qemu-devel] define constant in .risu file

[G 3]

Is there a way to define a constant in a .risu file? Something like  
this:


my $upper_imm_limit = 500;

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[G 3]

On Apr 7, 2017, at 1:49 PM, luigi burdo wrote:


Tested on PowerMac G5 Quad  and 380% of system load and working on
Fedora 25 PPC64 host and Ubuntu Mate 17.04 guest  (patched the 2.9  
rc3)


The machine configuration was this

sudo ./qemu-system-ppc64 -cpu POWER8 -vga none -machine  
pseries-2.5,usb=off -m 2G  -smp 4,cores=4,threads=1 -accel  
tcg,thread=multi  -kerne vmlinuz-append root=/dev/sda   -device  
ich9-ahci,id=ahci   -device ide-drive,drive=disk0 -drive file=/dev/ 
sda4,if=none,id=disk0   -net nic,model=pcnet -net user -soundhw  
hda  -display sdl -vga virtio


vga virtio working too
here a shot
https://scontent-mxp1-1.xx.fbcdn.net/v/ 
t1.0-9/17796379_10208795258860396_7825547329794577576_n.jpg? 
oh=526d6ddeb67c817053582d5b9ee56c71=594D7BDF


Thanks
Luigi


Do you have any timings? Did the guest run faster?

Re: [Qemu-devel] is qemu able to run multiple system emulation simultaneously

[G 3]

On Apr 7, 2017, at 3:08 AM, Jiahuan Zhang wrote:




On 7 April 2017 at 08:26, Jiahuan Zhang <jiahuanzhan...@gmail.com>  
wrote:

On 6 April 2017 at 19:58, G 3 <programmingk...@gmail.com> wrote:

On Apr 6, 2017, at 12:00 PM, qemu-devel-requ...@nongnu.org wrote:

Dear QEMU developers,

I need multiple ARM-based hardware emulation runing simultaneously  
in one

PC.
I wander if QEMU is capble to run two system emulation at the same  
time.

Or I have to use two QEMU for two system emulation

If the former is possible, where can i find some docs about it? I have
searched two days, the result is not positive.

Please help. Thanks in advance.

Best regards,
Jiahuan

My vote goes to running multiple instances of QEMU at the same  
time. It is easy to do and works.


Just done a try. Multiple system emulation can be done by running  
multiple instances of QEMU. You are right! Thanks.


You're welcome.

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

[G 3]

On Apr 6, 2017, at 1:08 PM, luigi burdo wrote:



Hi i can help test it too on my two Be machine.
If some one help me to find where is the patch or where i can  
download  the commits


Thanks
Luigi



Here are the patches:

1/3 https://patchwork.ozlabs.org/patch/747691/
2/3 https://patchwork.ozlabs.org/patch/747692/
3/3 https://patchwork.ozlabs.org/patch/747688/ 

Re: [Qemu-devel] is qemu able to run multiple system emulation simultaneously

[G 3]

On Apr 6, 2017, at 12:00 PM, qemu-devel-requ...@nongnu.org wrote:


Dear QEMU developers,

I need multiple ARM-based hardware emulation runing simultaneously  
in one

PC.
I wander if QEMU is capble to run two system emulation at the same  
time.

Or I have to use two QEMU for two system emulation

If the former is possible, where can i find some docs about it? I have
searched two days, the result is not positive.

Please help. Thanks in advance.

Best regards,
Jiahuan


My vote goes to running multiple instances of QEMU at the same time.  
It is easy to do and works.

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

[G 3]

On Apr 6, 2017, at 9:32 AM, Cédric Le Goater wrote:


On 04/06/2017 03:28 PM, G 3 wrote:


On Apr 6, 2017, at 9:26 AM, Cédric Le Goater wrote:


Hello Nikunj,

On 04/06/2017 12:22 PM, Nikunj A Dadhania wrote:

The series enables Multi-Threaded TCG on PPC64

Patch 01: Use atomic_cmpxchg in store conditional
  02: Handle first write to page during atomic operation
  03: Generate memory barriers for sync/isync and load/store  
conditional


Patches are based on ppc-for-2.10

Tested using following:
./ppc64-softmmu/qemu-system-ppc64 -cpu POWER8 -vga none - 
nographic -machine pseries,usb=off -m 2G  -smp  
8,cores=8,threads=1 -accel tcg,thread=multi  f23.img


I tried it with a Ubuntu 16.04.2 guest using stress --cpu 8. It  
looked

good : the CPU usage of QEMU reached 760% on the host.


What was your guest operating system?


The guest is an Ubuntu 16.04.2 and the host is an Ubuntu 17.04.

C.


Thank you for the information.

What you could do is run QEMU in emulation mode (non-kvm mode) and  
time how long it takes Ubuntu to boot up with one emulated core vs  
how long it takes to boot up on say 4 emulated cores. This would be a  
good start:


Boot up times:

one core:

two cores:

four cores:

eight cores:

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

[G 3]

On Apr 6, 2017, at 9:26 AM, Cédric Le Goater wrote:


Hello Nikunj,

On 04/06/2017 12:22 PM, Nikunj A Dadhania wrote:

The series enables Multi-Threaded TCG on PPC64

Patch 01: Use atomic_cmpxchg in store conditional
  02: Handle first write to page during atomic operation
  03: Generate memory barriers for sync/isync and load/store  
conditional


Patches are based on ppc-for-2.10

Tested using following:
./ppc64-softmmu/qemu-system-ppc64 -cpu POWER8 -vga none -nographic  
-machine pseries,usb=off -m 2G  -smp 8,cores=8,threads=1 -accel  
tcg,thread=multi  f23.img


I tried it with a Ubuntu 16.04.2 guest using stress --cpu 8. It looked
good : the CPU usage of QEMU reached 760% on the host.


What was your guest operating system?

[Qemu-devel] Python support in Risu

[G 3]

I was wondering if someone wrote a risugen_*.pm file in python and it  
still worked with risugen, would you accept that patch?

Re: [Qemu-devel] [PATCH v3 0/2] hw/i386: Update FADT to Revision 3 (ACPI 2.0)

[G 3]

On Mar 15, 2017, at 10:25 AM, qemu-devel-requ...@nongnu.org wrote:


On Wed, Mar 15, 2017 at 07:20:25PM +1300, Phil Dennis-Jordan wrote:
This updates the FADT generated for x86/64 machine types from  
Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) As  
previously, the goal is to make running macOS/OS X guests  
smoother. With a Rev1 FADT, rebooting such a guest doesn't work,  
as the OS uses the reset register information from the FADT.  
Switching to a Rev3 (ACPI 2.0) FADT solves this problem.


The previous discussion of this raised a bunch of points, which  
I'll address/clarify here as well:


 1. No runtime option. The preference was expressed that we try to  
stay backwards-compatible with legacy guests as opposed to adding  
a runtime option for different APCI versions. ACPI 2.0/FADT Rev3  
is the minimum version required for exposing the reset register,  
and it is also backwards-compatible with 1.0/Rev1, so that seemed  
a good version to target.


 2. Legacy guest testing. I've tested this successfully (no  
apparent regressions) with:
   * Windows XP x86 (both "pc" and "q35" machine types, the latter  
using -device piix4-ide)

   * Windows 7, both 32-bit and 64-bit editions
   * Windows 10 x64
   * Fedora 7 x86 Live image
   * Fedora 25 x86_64 Live image
   * Ubuntu 10.04.4 AMD64 Live image
Any other specific OSes and versions I should check?


Windows 2000

[Qemu-devel] [PATCH Risu v2 0/3] PPC64 Improvements

[G 3]

On Mar 9, 2017, at 3:08 PM, qemu-devel-requ...@nongnu.org wrote:



v2:
 - applied code review

This patchset include initial support to PPC64 (Big-Endian), that  
is pretty

much the same: only some fixes in configure and risugen.
Also, it adds a better random initialization of VSX registers.

Jose Ricardo Ziviani (3):
  risugen_ppc64: Load random 128-bit data to VSX registers
  configure: Add initial support to PPC64 (big endian)
  risugen,risugen_ppc64.pm: Add support ppc64 (big-endian)

 configure|  9 -
 risugen  |  6 +-
 risugen_ppc64.pm | 44 +---
 3 files changed, 42 insertions(+), 17 deletions(-)

--
2.7.4


Would this patch set work with the IBM PowerPC 970 (G5) CPU?

[Qemu-devel] Risu and the PowerPC 970

[G 3]

Does Risu support the PowerPC 970? I tried compiling it but I saw  
this error:


gcc  -Wall -D_GNU_SOURCE -DARCH=ppc64 -g  -o risu.o -c risu.c
In file included from risu.c:29:
risu.h:27:30: error: risu_reginfo_ppc64.h: No such file or directory
make: *** [Makefile:44: risu.o] Error 1

The PowerPC 970 is a 64-bit PowerPC CPU.

My configure line:
ARCH=ppc64 ./configure

I cloned Risu from here:
https://git.linaro.org/people/peter.maydell/risu.git

Re: [Qemu-devel] git master build failure in 9pfs

[G 3]

On Mar 3, 2017, at 11:21 AM, Daniel P. Berrange wrote:


On Fri, Mar 03, 2017 at 10:55:01AM -0500, G 3 wrote:


On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote:


On Fri, 3 Mar 2017 10:28:00 -0500
G 3 <programmingk...@gmail.com> wrote:


On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote:

On 02/03/17 17:40, Daniel P. Berrange wrote:


On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote:
Does anyone else see the following error when trying to build  
git

master?

cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs
-I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/
include
-I/usr/include/pixman-1
-I/home/build/src/qemu/git/qemu/dtc/libfdt
-Werror -pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -m64 -mcx16 -
D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12   -I/home/build/src/qemu/git/qemu/ 
tests -

MMD -MP
-MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 - 
U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -g   -c -o hw/9pfs/9p-util.o hw/9pfs/9p- 
util.c

In file included from hw/9pfs/9p-util.c:15:0:
hw/9pfs/9p-util.h: In function ?openat_dir?:
hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first  
use in

this
function)
hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is
reported
only once for each function it appears in
hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void
function
[-Werror=return-type]

Build platform is Debian Wheezy on an x86_64 host.


IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has  
2.13.


So unless we want to make this 9pfs code a configurable
option, this
means Debian Wheezy is no longer a supportable platform for QEMU.


Oh sure, I appreciate that wheezy is getting towards then end  
of its

lifetime - it's just a little bit inconvenient to break my
development
environment just as we enter 2.9 freeze ;)

If everyone agrees that wheezy is no longer supported after 2.9
then I
can look to upgrading, however my QEMU development is done on my
laptop
which is also setup for my day job so it's not a simple case of  
just

switching the repository and running dist-upgrade to get me going
again...


I remember years ago something like O_PATH was not defined on  
Mac OS

X,
so the solution was to define the constant as zero. Something like
this:

#ifndef O_PATH
#define O_PATH 0
#endif

Maybe this might work in 9p-util.h.



Yes. Please send a patch and I'll merge it.

Cheers.

--
Greg



Here is the patch. I think we should let Mark or some else test it  
to see if

it does fix the problem before a real patch is submitted.

---
 hw/9pfs/9p-util.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 091f3ce..254d2a9 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,10 @@
 #ifndef QEMU_9P_UTIL_H
 #define QEMU_9P_UTIL_H

+#ifndef O_PATH
+#define O_PATH 0
+#endif


Isn't the use of O_PATH required in order to fix the recent
security vulnerability in 9p ?  If so, then defining it to
0 means the QEMU is silently becoming vulnerable once again
which I don't think is a good idea.


I haven't found any documentation that states O_PATH is required
to keep things secure.

https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04231.html
This post does talk about fixing security issues with the 9pfs protocol,
but there is no mention of the 9p-util.h file.

Greg Kurz - do you have an option on O_PATH and security?

Re: [Qemu-devel] git master build failure in 9pfs

[G 3]

On Mar 3, 2017, at 10:58 AM, Peter Maydell wrote:


On 3 March 2017 at 15:55, G 3 <programmingk...@gmail.com> wrote:
Here is the patch. I think we should let Mark or some else test it  
to see if

it does fix the problem before a real patch is submitted.

---
 hw/9pfs/9p-util.h | 4 
 1 file changed, 4 insertions(+)


We can't take any patch without a Signed-off-by: line, not
even a three line one.


This was more of a RFC kind of patch. It is a pre-patch. I honestly  
don't know if it will work.






diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 091f3ce..254d2a9 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,10 @@
 #ifndef QEMU_9P_UTIL_H
 #define QEMU_9P_UTIL_H

+#ifndef O_PATH
+#define O_PATH 0
+#endif


Could use a comment explaining why it's OK to define it in
a way that means it's a no-op on hosts without it.


Ok.




+
 static inline void close_preserve_errno(int fd)
 {
 int serrno = errno;
--
2.10.2


thanks
-- PMM


Thank you.

Re: [Qemu-devel] git master build failure in 9pfs

[G 3]

On Mar 3, 2017, at 10:44 AM, Greg Kurz wrote:


On Fri, 3 Mar 2017 10:28:00 -0500
G 3 <programmingk...@gmail.com> wrote:


On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote:

On 02/03/17 17:40, Daniel P. Berrange wrote:


On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote:

Does anyone else see the following error when trying to build git
master?

cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs
-I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/
include
-I/usr/include/pixman-1   -I/home/build/src/qemu/git/qemu/dtc/ 
libfdt

-Werror -pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -m64 -mcx16 -
D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing- 
prototypes

-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12   -I/home/build/src/qemu/git/qemu/tests -
MMD -MP
-MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -g   -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c
In file included from hw/9pfs/9p-util.c:15:0:
hw/9pfs/9p-util.h: In function ?openat_dir?:
hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in
this
function)
hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is
reported
only once for each function it appears in
hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void
function
[-Werror=return-type]

Build platform is Debian Wheezy on an x86_64 host.


IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13.

So unless we want to make this 9pfs code a configurable option,  
this

means Debian Wheezy is no longer a supportable platform for QEMU.


Oh sure, I appreciate that wheezy is getting towards then end of its
lifetime - it's just a little bit inconvenient to break my  
development

environment just as we enter 2.9 freeze ;)

If everyone agrees that wheezy is no longer supported after 2.9  
then I

can look to upgrading, however my QEMU development is done on my
laptop
which is also setup for my day job so it's not a simple case of just
switching the repository and running dist-upgrade to get me going
again...


I remember years ago something like O_PATH was not defined on Mac  
OS X,
so the solution was to define the constant as zero. Something like  
this:


#ifndef O_PATH
#define O_PATH 0
#endif

Maybe this might work in 9p-util.h.



Yes. Please send a patch and I'll merge it.

Cheers.

--
Greg



Here is the patch. I think we should let Mark or some else test it to  
see if it does fix the problem before a real patch is submitted.


---
 hw/9pfs/9p-util.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 091f3ce..254d2a9 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,10 @@
 #ifndef QEMU_9P_UTIL_H
 #define QEMU_9P_UTIL_H

+#ifndef O_PATH
+#define O_PATH 0
+#endif
+
 static inline void close_preserve_errno(int fd)
 {
 int serrno = errno;
--
2.10.2

Re: [Qemu-devel] git master build failure in 9pfs

[G 3]

On Mar 3, 2017, at 9:59 AM, qemu-devel-requ...@nongnu.org wrote:

On 02/03/17 17:40, Daniel P. Berrange wrote:


On Thu, Mar 02, 2017 at 05:28:24PM +, Mark Cave-Ayland wrote:
Does anyone else see the following error when trying to build git  
master?


cc -I/home/build/src/qemu/git/qemu/hw/9pfs -Ihw/9pfs
-I/home/build/src/qemu/git/qemu/tcg
-I/home/build/src/qemu/git/qemu/tcg/i386
-I/home/build/src/qemu/git/qemu/linux-headers
-I/home/build/src/qemu/git/qemu/linux-headers -I.
-I/home/build/src/qemu/git/qemu -I/home/build/src/qemu/git/qemu/ 
include

-I/usr/include/pixman-1   -I/home/build/src/qemu/git/qemu/dtc/libfdt
-Werror -pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -m64 -mcx16 - 
D_GNU_SOURCE

-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-all -I/usr/include/p11-kit-1
-I/usr/include/libpng12   -I/home/build/src/qemu/git/qemu/tests - 
MMD -MP

-MT hw/9pfs/9p-util.o -MF hw/9pfs/9p-util.d -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -g   -c -o hw/9pfs/9p-util.o hw/9pfs/9p-util.c
In file included from hw/9pfs/9p-util.c:15:0:
hw/9pfs/9p-util.h: In function ?openat_dir?:
hw/9pfs/9p-util.h:25:57: error: ?O_PATH? undeclared (first use in  
this

function)
hw/9pfs/9p-util.h:25:57: note: each undeclared identifier is  
reported

only once for each function it appears in
hw/9pfs/9p-util.h:26:1: error: control reaches end of non-void  
function

[-Werror=return-type]

Build platform is Debian Wheezy on an x86_64 host.


IIUC, O_PATH was introduced in glibc 2.14 and Wheezy only has 2.13.

So unless we want to make this 9pfs code a configurable option, this
means Debian Wheezy is no longer a supportable platform for QEMU.


Oh sure, I appreciate that wheezy is getting towards then end of its
lifetime - it's just a little bit inconvenient to break my development
environment just as we enter 2.9 freeze ;)

If everyone agrees that wheezy is no longer supported after 2.9 then I
can look to upgrading, however my QEMU development is done on my  
laptop

which is also setup for my day job so it's not a simple case of just
switching the repository and running dist-upgrade to get me going  
again...


I remember years ago something like O_PATH was not defined on Mac OS X,
so the solution was to define the constant as zero. Something like this:

#ifndef O_PATH
#define O_PATH 0
#endif

Maybe this might work in 9p-util.h.

[Qemu-devel] GSOC: Add support for Mac OS 8.6

[G 3]

Hi, would anyone like to mentor for the possible Google Summer of  
Code project of adding support for Mac OS 8.6 to QEMU? 

[Qemu-devel] Qemu-devel] Interested in GSoC 2017: Add a Hypervisor.framework accelerator

[G 3]

On Feb 27, 2017, at 3:59 PM, qemu-devel-requ...@nongnu.org wrote:


Hello, my name is Sergio G?mez.
It seems that QEMU has been accepted into GSoC 2017. I'm interested in
working with QEMU due to my interest in virtual machines in general.
Particularly, taking into account that I have experience developing a
(simple) emulator, and a (very simple) operating system, and done lots
of C and Assembly Language programming, I find the project proposal
"Add a Hypervisor.framework accelerator", mentored by Mr. Alexander
Graf an ideal and stimulating task for me to tackle.

Besides considering having the technical knowledge to accomplish what
is proposed, I think that my communication skills would also be very
valuable not only for this project, but to continue involved with QEMU
(which is what I'd like).

I wrote to Mr. Stefan Hajnoczi a while ago showing my interest in QEMU
and GSoC 2017. I've been studying some of the project's code, for
example, the C routines that are 'hooked' into the C runtime before
main() which does some work for initializing the QEMU Object Model
(QOM), which I've also been studying a little bit.

I feel very comfortable writing and debugging low-level code, with all
its intricacies. I would like and opportunity to show these skills.

I am looking forward to his opportunity and full of motivation to get
involved with the QEMU project.

Thank you for your attention, and feedback on how to proceed would  
be great.


Would this be for Mac OS X's Hypervisor?

Re: [Qemu-devel] [PATCH v14 00/24] MTTCG Base enabling patches with ARM enablement

[G 3]

Hi I was wondering if your MTTCG patches have been tested with a  
PowerPC guest yet. Also do you have a repo someone could clone to  
test out all your patches?

Re: [Qemu-devel] [PATCH 00/22] target/openrisc updates

[G 3]

On Feb 23, 2017, at 9:09 AM, Stafford Horne wrote:


On Mon, Feb 13, 2017 at 10:33:09PM -0500, Programmingkid wrote:


On Feb 13, 2017, at 10:25 PM, Richard Henderson wrote:


On 02/10/2017 11:39 AM, Stafford Horne wrote:

On Thu, Feb 09, 2017 at 09:10:51AM -0500, G 3 wrote:


On Feb 8, 2017, at 11:52 PM, qemu-devel-requ...@nongnu.org wrote:


Message: 6
Date: Wed,  8 Feb 2017 20:51:32 -0800
From: Richard Henderson <r...@twiddle.net>
To: qemu-devel@nongnu.org
Cc: sho...@gmail.com
Subject: [Qemu-devel] [PATCH 00/22] target/openrisc updates
Message-ID: <20170209045154.16868-1-...@twiddle.net>

The bulk of this patch set is 2-3 years old, and was mostly
reviewed by Bastian Koppelmann.  But it languished because
there were reports of it not booting kernel images, and I
had problems putting together a set of tools that could even
build a kernel.

The OpenRISC community has picked up activity recently,
with Stafford Horne upstreaming some of the compiler tools.
He has even done some testing for me of this patch set.


r~


I see you are working on OpenRISC. Would you be able to help
me improve its wiki page?

http://wiki.qemu-project.org/Documentation/Platforms/OpenRISC

Right now there isn't much information on OpenRISC here. I'm
hoping to make it a lot useful to anyone who is interesting in  
this

platform.

Would you know of any links to software that works in OpenRISC?

Pictures of the OpenRISC target running anything would be great  
also.


What is your suggested command-line for using OpenRISC?

If you have any suggestions on how to improve the page place don't
hesitate to let me know.



Hi Richard, G 3,

I am not sure if Richard has the time for this.  But I kind of  
got him
started back on the openrisc work, it would be my fault to  
burden him
with even more work :).  Also, I was helping to do some tests so  
I have

some example commands.


:-)

I don't have a lot of time, but I think I can help to update the  
above.

Probably Richard and I could work together?

I was recently working on updating the openrisc page

 http://openrisc.io

I think I could link between the two for toolchain compile  
guides and

software guides (i.e. debugging and linux).

Richard what do you think?


Probably the most beneficial thing that we can do is create a  
kernel+initrd that boots into a busybox root shell.  Similar to  
the other test images that we have at


 http://wiki.qemu-project.org/Testing/System_Images


r~



We could do both the test image and a wiki page.


I posted a test image to the wiki

 http://wiki.qemu-project.org/Testing/System_Images

However, someone on the #qemu irc room mentioned its not ideal to post
any images on the wiki and existing images should be taken down due to
copyright issues.  I don't quite follow, should we be concerned?


If this is a Linux test image, it should be fine. Could we add a link  
to the test image to the wiki page?




Also, I did start adding some commands to the wiki, any feedback
appreciated.

  http://wiki.qemu-project.org/Documentation/Platforms/OpenRISC

-Stafford


Thank you so much for all your work. The wiki page looks great. For  
the maintainer, is Jia Liu still maintaining it? I never received a  
reply from him.  Would you be interested in being a maintainer?


This line in the wiki doesn't sound right:
"To get good traces you can also add the following, this will output  
trace info the a file z"


Maybe this:
"To get good traces you can also add the following, this will output  
trace info to the file z"


If z is a file, I really suggest renaming it to something more  
descriptive.


Thank you.

Re: [Qemu-devel] [PATCH 00/22] target/openrisc updates

[G 3]

On Feb 8, 2017, at 11:52 PM, qemu-devel-requ...@nongnu.org wrote:


Message: 6
Date: Wed,  8 Feb 2017 20:51:32 -0800
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: sho...@gmail.com
Subject: [Qemu-devel] [PATCH 00/22] target/openrisc updates
Message-ID: <20170209045154.16868-1-...@twiddle.net>

The bulk of this patch set is 2-3 years old, and was mostly
reviewed by Bastian Koppelmann.  But it languished because
there were reports of it not booting kernel images, and I
had problems putting together a set of tools that could even
build a kernel.

The OpenRISC community has picked up activity recently,
with Stafford Horne upstreaming some of the compiler tools.
He has even done some testing for me of this patch set.


r~


I see you are working on OpenRISC. Would you be able to help
me improve its wiki page?

http://wiki.qemu-project.org/Documentation/Platforms/OpenRISC

Right now there isn't much information on OpenRISC here. I'm
hoping to make it a lot useful to anyone who is interesting in this
platform.

Would you know of any links to software that works in OpenRISC?

Pictures of the OpenRISC target running anything would be great also.

What is your suggested command-line for using OpenRISC?

If you have any suggestions on how to improve the page place don't
hesitate to let me know.

Thank you.

Re: [Qemu-devel] Qemu-devel] Poll on QEMU documentation project

[G 3]

On Feb 1, 2017, at 6:17 PM, Paolo Bonzini wrote:




On 01/02/2017 14:50, G 3 wrote:

I was thinking maybe we should add Rich Text Format, or maybe even a
word processing format like OpenOffice, or Microsoft Word to the  
list of

possible formats. These formats are super easy to use. No formatting
rules to have to learn. All the user needs to do is just type up  
their
contribute to the documentation in a word processor. The word  
processor
would do all the formatting work. Tables, links, stylized text are  
all
possible. This would allow us to export to other formats like  
HTML, PDF,

and ascii text.


That's exactly what we _don't_ want.

We need documentation to be consistent.  RTF, OpenOffice, etc. are
presentation-based format (or at least 99% users use them as such),  
and

this automatically disqualifies them.  We don't want our documentation
to be a mixture of Arial, Times New Roman and Comic Sans depending on
the user that's contributing.  Besides, conversion of word processor
documents to HTML usually looks terrible.

The requirements for the format are:

* support for HTML and man as output formats, optionally PDF and text
* support for QEMU's usual submission workflow
* producing documentation with a consistent look
* tool support and extensibility
* being easy to use and not too obscure

in this order.  Based on this, the only formats we could plausibly use
are Texinfo (if only because that's what we use now), Markdown,
restructuredText, Docbook and Asciidoc.  The poll mentioned all of  
these

except Asciidoc, plus LaTeX as a "control group".

Paolo


Ok. I understand.

For the above requirements of "tool support and extensibility", what  
do you mean by this? Do you mean command-line tool support? What do  
you mean by extensibility?

Re: [Qemu-devel] Qemu-devel] Poll on QEMU documentation project

[G 3]

I was thinking maybe we should add Rich Text Format, or maybe even a  
word processing format like OpenOffice, or Microsoft Word to the list  
of possible formats. These formats are super easy to use. No  
formatting rules to have to learn. All the user needs to do is just  
type up their contribute to the documentation in a word processor.  
The word processor would do all the formatting work. Tables, links,  
stylized text are all possible. This would allow us to export to  
other formats like HTML, PDF, and ascii text.

Re: [Qemu-devel] Qemu-devel] Poll on QEMU documentation project

[G 3]

On Jan 26, 2017, at 12:30 PM, Paolo Bonzini wrote:




On 26/01/2017 18:28, G 3 wrote:


On Jan 26, 2017, at 12:00 PM, qemu-devel-requ...@nongnu.org wrote:



Hi all,

as you may know I've been collecting some ideas about  
documentation for

QEMU at http://wiki.qemu-project.org/Features/Documentation.

I've now prepared a poll to understand how familiars developers  
are with
various documentation tools.  I've CCed people with most commits  
to QEMU

documentation, or with whom I have discussed about this before, but
everybody's opinion is of course welcome!

The poll is hosted with Google Forms and you can fill it in at
https://goo.gl/Yfxj1M.  If you hate Google Forms, contact me  
offlist and
I'll send you the questions by email (and remind you when I need  
someone

to review my patches).

Paolo


tl;dr: poll is at https://goo.gl/Yfxj1M



For this question:
What's your opinion on the maintainability of the following
documentation formats?

Is it from 1(least maintainable) to 5 (most maintainable)?

The survey looks good. I will take it.


Yes, all of them are 1=bad 5=good.

Paolo


Could we add HTML to the list of documentation formats?

[Qemu-devel] Qemu-devel] Poll on QEMU documentation project

[G 3]

On Jan 26, 2017, at 12:00 PM, qemu-devel-requ...@nongnu.org wrote:



Hi all,

as you may know I've been collecting some ideas about documentation  
for

QEMU at http://wiki.qemu-project.org/Features/Documentation.

I've now prepared a poll to understand how familiars developers are  
with
various documentation tools.  I've CCed people with most commits to  
QEMU

documentation, or with whom I have discussed about this before, but
everybody's opinion is of course welcome!

The poll is hosted with Google Forms and you can fill it in at
https://goo.gl/Yfxj1M.  If you hate Google Forms, contact me  
offlist and
I'll send you the questions by email (and remind you when I need  
someone

to review my patches).

Paolo


tl;dr: poll is at https://goo.gl/Yfxj1M



For this question:
What's your opinion on the maintainability of the following  
documentation formats?


Is it from 1(least maintainable) to 5 (most maintainable)?

The survey looks good. I will take it.

Re: [Qemu-devel] [Qemu-ppc] PowerPC question

[G 3]

The version of qemu-system-ppc you are using is kind of old. Version  
2.8.0 is the newest version. I suggest trying the newest version  
before trying to fix a broken feature in an older version.


http://wiki.qemu.org/Download

On Dec 27, 2016, at 1:57 PM, Дмитрий Смирнов wrote:


qemu-system-ppc version: 2.5.1.1

Ubuntu 14.04
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
GTK 2.0, libsdl1.2-dev
./configure --target-list="ppc-softmmu" --disable-xfsctl

By zero meaning, do you mean this: decr = 0
Yes.


2016-12-27 21:16 GMT+03:00 G 3 <programmingk...@gmail.com>:
When I type 'info registers', I see 'DECR 3919147695' at the top of  
the screen, so it appears to be working. I think we need more  
information from you.


qemu-system-ppc version:

gcc version (gcc -v):

Host info: Ubuntu 

Front-end (GTK, SDL, ...):

Compile command: ./configure 

Note: please respond to this email with "reply all". That way  
everyone can try to help you.


On Dec 27, 2016, at 1:06 PM, Дмитрий Смирнов wrote:

All the registers, which are printing with 'info registers', dump  
to file before (./target-ppc/translate.c), but there is no SPR_DECR.
I tried to add in 'translate.c' and ./monitor.c some code (print of  
cpu_ppc_load_decr(env), print of env->spr[SPR_DECR]), but I have  
zero meaning. Also I tried 'p $decr' with the same answer.


By zero meaning, do you mean this: decr = 0

Maybe I have this problem, because I using VirtualBox->Ubuntu->Qemu?

This should not be a problem. An emulator can run anywhere.


2016-12-27 18:52 GMT+03:00 G 3 <programmingk...@gmail.com>:


On Dec 27, 2016, at 10:38 AM, qemu-ppc-requ...@nongnu.org wrote:

Hello, devs!

I'm using ppc-softmmu target, and in my qemu monitor I need to  
print the

SPR_DECR meaning, but I don't understand how.
Could anyone help me with my problem?

Best regards!

I think you want to try the 'info registers' command in the monitor.

Re: [Qemu-devel] [Qemu-ppc] PowerPC question

[G 3]

When I type 'info registers', I see 'DECR 3919147695' at the top of  
the screen, so it appears to be working. I think we need more  
information from you.


qemu-system-ppc version:

gcc version (gcc -v):

Host info: Ubuntu 

Front-end (GTK, SDL, ...):

Compile command: ./configure 

Note: please respond to this email with "reply all". That way  
everyone can try to help you.


On Dec 27, 2016, at 1:06 PM, Дмитрий Смирнов wrote:

All the registers, which are printing with 'info registers', dump  
to file before (./target-ppc/translate.c), but there is no SPR_DECR.
I tried to add in 'translate.c' and ./monitor.c some code (print of  
cpu_ppc_load_decr(env), print of env->spr[SPR_DECR]), but I have  
zero meaning. Also I tried 'p $decr' with the same answer.


By zero meaning, do you mean this: decr = 0


Maybe I have this problem, because I using VirtualBox->Ubuntu->Qemu?


This should not be a problem. An emulator can run anywhere.



2016-12-27 18:52 GMT+03:00 G 3 <programmingk...@gmail.com>:

On Dec 27, 2016, at 10:38 AM, qemu-ppc-requ...@nongnu.org wrote:

Hello, devs!

I'm using ppc-softmmu target, and in my qemu monitor I need to  
print the

SPR_DECR meaning, but I don't understand how.
Could anyone help me with my problem?

Best regards!

I think you want to try the 'info registers' command in the monitor.

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[G 3]

On Dec 5, 2016, at 9:15 AM, Paolo Bonzini wrote:




On 05/12/2016 14:47, G 3 wrote:


So now I have to figure out which commands to use. This script would
have to work on all operating systems that QEMU is built on. This  
page

has some pretty good information on how to do this:
http://stackoverflow.com/questions/12422289/bash-command-to-covert- 
html-page-to-a-text-file


No, I just want to do that once and get rid of the Hosts/ pages.

Paolo


Really? Why? I thought they were very useful. Where would people who  
are doing a web search go for building information? 

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[G 3]

On Dec 3, 2016, at 3:41 AM, Paolo Bonzini wrote:




On 02/12/2016 23:59, Programmingkid wrote:
I thought we could use a Hosts page to sort all the host  
documentation we have. It is located here: http://wiki.qemu.org/Hosts


Here is what I have so far:

AIX
Darwin
FreeBSD, NetBSD, OpenBSD
Linux
Mac OS X
Solaris
Windows



Since this stuff changes rarely, it should be in the source tree
instead.  You can link to the source tree from the wiki with something
like this:

{{src|path=BUILDING|description=the BUILDING file in the source tree}}

Would you like to make a patch moving the information from the wiki to
such a file?

Paolo


I think I now know what you want. You want a shell script that would  
take each link in the http://wiki.qemu.org/Hosts file, convert the  
html data into text of the linked file, then append that text to a  
file called BUILDING. So in the end we have a file called BUILDING  
that would look like this:



QEMU Building Directions:

AIX
.

Darwin
.

FreeBSD, NetBSD, OpenBSD


Linux
.

Mac OS X


Solaris


Windows



So now I have to figure out which commands to use. This script would  
have to work on all operating systems that QEMU is built on. This  
page has some pretty good information on how to do this: http:// 
stackoverflow.com/questions/12422289/bash-command-to-covert-html-page- 
to-a-text-file


I think I will work on a python script to do this job.

Re: [Qemu-devel] ARM documentation

[G 3]

On Nov 30, 2016, at 6:58 PM, Alistair Francis wrote:


On Fri, Nov 18, 2016 at 4:53 PM, Programmingkid
<programmingk...@gmail.com> wrote:


On Nov 18, 2016, at 7:31 PM, Programmingkid wrote:



On Nov 18, 2016, at 4:10 PM, Alistair Francis wrote:

On Fri, Nov 11, 2016 at 8:53 AM, G 3 <programmingk...@gmail.com>  
wrote:


On Nov 11, 2016, at 11:31 AM, Alex Bennée wrote:



G 3 <programmingk...@gmail.com> writes:


On Nov 11, 2016, at 8:27 AM, G 3 wrote:



On Nov 11, 2016, at 8:08 AM, Stefan Hajnoczi wrote:


On Fri, Nov 11, 2016 at 12:09:31AM -0500, G 3 wrote:


I was wondering if there is a list somewhere of all the ARM
boards QEMU
supports. I want to add a section to the ARM wiki page  
that lists

at least a
few of them.



Are you looking for something more detailed than the  
following?


$ arm-softmmu/qemu-system-arm -M \?
Supported machines are:
akitaSharp SL-C1000 (Akita) PDA (PXA270)
ast2500-evb  Aspeed AST2500 EVB (ARM1176)
borzoi   Sharp SL-C3100 (Borzoi) PDA (PXA270)
canon-a1100  Canon PowerShot A1100 IS
cheetah  Palm Tungsten|E aka. Cheetah PDA  
(OMAP310)

collie   Sharp SL-5500 (Collie) PDA (SA-1110)
connex   Gumstix Connex (PXA255)
cubieboard   cubietech cubieboard
highbank Calxeda Highbank (ECX-1000)
imx25-pdkARM i.MX25 PDK board (ARM926)
integratorcp ARM Integrator/CP (ARM926EJ-S)
kzm  ARM KZM Emulation Baseboard (ARM1136)
lm3s6965evb  Stellaris LM3S6965EVB
lm3s811evb   Stellaris LM3S811EVB
mainstoneMainstone II (PXA27x)
midway   Calxeda Midway (ECX-2000)
musicpal Marvell 88w8618 / MusicPal (ARM926EJ-S)
n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
netduino2Netduino 2 Machine
none empty machine
nuri Samsung NURI board (Exynos4210)
palmetto-bmc OpenPOWER Palmetto BMC (ARM926EJ-S)
raspi2   Raspberry Pi 2
realview-eb  ARM RealView Emulation Baseboard  
(ARM926EJ-S)
realview-eb-mpcore   ARM RealView Emulation Baseboard  
(ARM11MPCore)
realview-pb-a8   ARM RealView Platform Baseboard for  
Cortex-A8
realview-pbx-a9  ARM RealView Platform Baseboard  
Explore for

Cortex-A9
sabreliteFreescale i.MX6 Quad SABRE Lite Board  
(Cortex

A9)
smdkc210 Samsung SMDKC210 board (Exynos4210)
spitzSharp SL-C3000 (Spitz) PDA (PXA270)
sx1  Siemens SX1 (OMAP310) V2
sx1-v1   Siemens SX1 (OMAP310) V1
terrier  Sharp SL-C3200 (Terrier) PDA (PXA270)
tosa Sharp SL-6000 (Tosa) PDA (PXA255)
verdex   Gumstix Verdex (PXA270)
versatileab  ARM Versatile/AB (ARM926EJ-S)
versatilepb  ARM Versatile/PB (ARM926EJ-S)
vexpress-a15 ARM Versatile Express for Cortex-A15
vexpress-a9  ARM Versatile Express for Cortex-A9
virt-2.6 QEMU 2.6 ARM Virtual Machine
virt-2.7 QEMU 2.7 ARM Virtual Machine
virt QEMU 2.8 ARM Virtual Machine (alias of  
virt-2.8)

virt-2.8 QEMU 2.8 ARM Virtual Machine
xilinx-zynq-a9   Xilinx Zynq Platform Baseboard for  
Cortex-A9

z2   Zipit Z2 (PXA27x)

$ aarch64-softmmu/qemu-system-aarch64 -M \?
Supported machines are:
akitaSharp SL-C1000 (Akita) PDA (PXA270)
ast2500-evb  Aspeed AST2500 EVB (ARM1176)
borzoi   Sharp SL-C3100 (Borzoi) PDA (PXA270)
canon-a1100  Canon PowerShot A1100 IS
cheetah  Palm Tungsten|E aka. Cheetah PDA  
(OMAP310)

collie   Sharp SL-5500 (Collie) PDA (SA-1110)
connex   Gumstix Connex (PXA255)
cubieboard   cubietech cubieboard
highbank Calxeda Highbank (ECX-1000)
imx25-pdkARM i.MX25 PDK board (ARM926)
integratorcp ARM Integrator/CP (ARM926EJ-S)
kzm  ARM KZM Emulation Baseboard (ARM1136)
lm3s6965evb  Stellaris LM3S6965EVB
lm3s811evb   Stellaris LM3S811EVB
mainstoneMainstone II (PXA27x)
midway   Calxeda Midway (ECX-2000)
musicpal Marvell 88w8618 / MusicPal (ARM926EJ-S)
n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
netduino2Netduino 2 Machine
none empty machine
nuri Samsung NURI board (Exynos4210)
palmetto-bmc OpenPOWER Palmetto BMC (ARM926EJ-S)
raspi2   Raspberry Pi 2
realview-eb  ARM RealView Emulation Baseboard  
(ARM926EJ-S)
realview-eb-mpcore   ARM RealView Emulation Baseboard  
(ARM11MPCore)
realview-pb-a8   ARM RealView Platform Baseboard for  
Cortex-A8
realview-pbx-a9  ARM RealView Platform Baseboard  
Explore for

Cortex-A9
sabreliteFreescale i.MX6 Quad SABRE Lite B

[Qemu-devel] [Bug in qemu-system-ppc running Mac OS 9 on Windows 10]

[G 3]

On Nov 25, 2016, at 9:26 AM, qemu-devel-requ...@nongnu.org wrote:


Hi all,

I've been experiencing issues when installing Mac OS 9.x using
qemu-system-ppc.exe in Windows 10. After booting from CD image,
partitioning a fresh disk image often hangs Qemu. When using a
pre-partitioned disk image, the OS installation process halts
somewhere during the process. The issues can be resolved by setting
qemu-system-ppc.exe to run in Windows 7 compatibility mode.
AFAIK all Qemu builds for Windows since Mac OS 9 became available as
guest are affected.
The issue is reproducible by installing Qemu for Windows from Stephan
Weil on Windows 10 and boot/install Mac OS 9.x

Best regards and thanks for looking into this,
Howard


I assume there was some kind of behavior change for some of the  
Windows API between Windows 7 and Windows 10, that is my guess as to  
why the compatibility mode works. Could you run 'make check' on your  
system, once in Windows 7 and once in Windows 10. Maybe the tests  
will tell us something. I'm hoping that one of the tests succeeds in  
Windows 7 and fails in Windows 10. That would help us pinpoint what  
the problem is.


What I mean by run in Windows 7 is set the mingw environment to run  
in Windows 7 compatibility mode (if possible). If you have Windows 7  
on another partition you could boot from, that would be better.


Good luck.

p.s. use 'make check -k' to allow all the tests to run (even if one  
or more of the tests fails). 

Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

On Nov 21, 2016, at 3:36 PM, Eric Blake wrote:


On 11/21/2016 02:12 PM, G 3 wrote:


On Nov 21, 2016, at 5:02 AM, Paolo Bonzini wrote:




On 21/11/2016 07:30, G 3 wrote:

When I try to use qemu-system-i386, I see this error message:

qobject/qjson.c:69: failed assertion `obj != NULL'.




The string argument is this: { 'seconds': %qd, 'microseconds': % 
qd }


Would anyone know how to fix this problem?


Please include the full backtrace.


#3  0x003ec69c in qobject_from_jsonf (string=0x443f44  
"{ 'seconds': %qd,

'microseconds': %qd }") at qobject/qjson.c:69
#4  0x0033f6e4 in timestamp_put (qdict=0x2052e00) at
/Users/john/desktop/qemu-2.0.0/monitor.c:476


Why on earth are you trying to compile qemu 2.0.0?  The latest version
we support on this list is currently 2.6.x for patch backports, with
2.7.0 as the latest stable release; and very soon now it will be 2.7.x
for backports and 2.8.0 as the latest stable release.

The source of your problem is that your platform defines PRId64 as  
'qd',
but the qemu JSON parser only recognizes lld (POSIX) or I64d  
(mingw) for

parsing 64-bit numbers.  We could enhance the JSON parser to recognize
the non-standard qd in addition to the hack we already have for mingw,
but I'd argue that using qobject_from_jsonf() is already less-than- 
useful.


On the other hand, timestamp_put() (which now lives in qapi/qmp- 
event.c,

rather than monitor.c) is still using qobject_from_jsonf() with PRId64
in current git master.  If you don't want to hack the JSON parser  
(and I

recommend that you don't), the alternative is to get rid of that
function call and replace it with an open-coded construction of a  
QDict
with manual population of its two members.  It's hard to argue that  
the
complexity of maintaining our pseudo-printf JSON parser for  
constructing

a QObject with one line is worth the effort compared to the three or
four lines to construct the same QObject by hand.


I would just like to note for anyone else who might face this problem  
in the

future that replacing %PRId64 with %lld fixed the problem. I made the
replacement in timestamp_put().

[Qemu-devel] check-qjson failure

[G 3]

On Nov 22, 2016, at 10:13 AM, Eric Blake wrote:


On 11/22/2016 09:02 AM, G 3 wrote:


I did run make check. It fails here:

GTESTER tests/check-qjson
qobject/qjson.c:69: failed assertion `obj != NULL'
GTester: last random seed: R02S40df2b0a1486871a176bb83135c07c90
make: *** [/Users/john/desktop/qemu-2.0.0/tests/Makefile:343:
check-tests/check-qjson] Error 1


That sounds like an independent failure; can you run 'gdb
tests/check-qjson' and get a backtrace for that (perhaps in a new
thread, since fixing it is different than this thread on
improving/eliminating qobject_from_json[fv])?



check-qga isn't run.


'make check -k' will let it run, rather than giving up early on the
first test failure of any earlier test.


Here is the backtrace for check-qjson:

#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x62fc in __eprintf (string=due to optimizations>, expression=to optimizations>, line=optimizations>, filename=optimizations>) at ../../../libgcc/libgcc2.c:2116
#3  0x8db8 in qobject_from_jsonf (string=0x10150 "%qd") at  
qobject/qjson.c:69

#4  0x40ac in vararg_number () at tests/check-qjson.c:978
#5  0x0026ad74 in g_test_run_suite_internal ()
#6  0x0026af74 in g_test_run_suite_internal ()
#7  0x0026af74 in g_test_run_suite_internal ()
#8  0x0026b0e4 in g_test_run_suite ()
#9  0x0026b140 in g_test_run ()
#10 0x6298 in main (argc=1, argv=0xb80c) at tests/check- 
qjson.c:1504

Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

On Nov 22, 2016, at 7:41 AM, Eric Blake wrote:


On 11/22/2016 04:06 AM, Markus Armbruster wrote:

Eric Blake  writes:


On 11/21/2016 02:36 PM, Eric Blake wrote:
The source of your problem is that your platform defines PRId64  
as 'qd',
but the qemu JSON parser only recognizes lld (POSIX) or I64d  
(mingw) for
parsing 64-bit numbers.  We could enhance the JSON parser to  
recognize
the non-standard qd in addition to the hack we already have for  
mingw,


Yes...

but I'd argue that using qobject_from_jsonf() is already less- 
than-useful.


In fact, we are down to only a handful of users of our modified  
'jsonf'

format (that is, strings that mix JSON with % modifiers):

hw/pci/pcie_aer.c: build a 5-element QDict
monitor.c: build a 1-element QDict which contains a 2-element QDict
qapi/qmp-dispatch.c: build a 2-element QDict
qapi/qmp-event.c: Build a 2-element QDict

plus the testsuite (check-qjson.c).


How did you find them?


git grep qobject_from_jsonf

I forgot about qobject_from_jsonv(), which is a bit more pervasive in
the testsuite, but even there, I only found a few additional uses of %
(that time, found by adding an assert(!strchr(format, '%')), then  
seeing

where it triggered during 'make check').  I should have the cleanup
series later today.  Technically, avoiding PRId64 in qmp-event.c is
worth having in 2.8 (it's a bug fix for Mac OS); but the rest of the
series is 2.9 material.  Note that at least one of the testsuite
conversions I'm making also used PRId64 - is the original poster even
running 'make check', as at least check-qga would be evidence of the
JSON parser failing to understand Mac's %qd.


I did run make check. It fails here:

GTESTER tests/check-qjson
qobject/qjson.c:69: failed assertion `obj != NULL'
GTester: last random seed: R02S40df2b0a1486871a176bb83135c07c90
make: *** [/Users/john/desktop/qemu-2.0.0/tests/Makefile:343: check- 
tests/check-qjson] Error 1


check-qga isn't run.

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Make uninorth interrupt swizzling identical to Grackle

[G 3]

On Nov 22, 2016, at 2:45 AM, qemu-devel-requ...@nongnu.org wrote:


Message: 4
Date: Tue, 22 Nov 2016 13:50:04 +1100
From: Benjamin Herrenschmidt 
To: BALATON Zoltan , Mark Cave-Ayland

Cc: David Gibson , qemu-...@nongnu.org,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Make uninorth
interrupt swizzling identical to Grackle
Message-ID: <1479783004.10230.57.ca...@kernel.crashing.org>
Content-Type: text/plain; charset="UTF-8"

On Tue, 2016-11-22 at 02:34 +0100, BALATON Zoltan wrote:
Is this going in for 2.8? If so, I'll need to apply the  
corresponding
patch to OpenBIOS to match and also do a PPC testing cycle to  
make sure
that there are no regressions on other OSs. Plus it would be  
useful to
get both pull requests in close proximity as this will break  
bisection.


(Adding BenH as these are his patches I just apparently forgot the  
cc.)


I'd appreciate if this could get in 2.8. As this is a bugfix this  
should?
be OK during the freeze. Likely there will be more rc cycles where  
it?

could be reverted if found to cause problems. But since it's already?
broken, applying this patch to QEMU should not break it more and  
adding?
the fix on the OpenBIOS side (patch 4/4) would complete the fix  
and may
actually make it work. This should only affect mac99 and this one  
patch is?
independent from the other three I've sent to OpenBIOS so this  
could be?
applied independently to get at least the interrupts fixed? if you  
can't?

test and apply the other three until the next pull.


Right, PCI IRQs are terminally broken already. This patch without the
OpenBIOS change won't hurt. With the OpenBIOS change, things start
working better :-)

I appologize for being basically MIA these days, way too busy with
other things. Feel free to pick up ownership of my patches if you
want to get them into upstreamable state, such as the SunGEM one.

I don't know if I'll have any bandwidth to work on that stuff again
until later next year.

Cheers,
Ben.


Can someone else take over the vga bios repo also?

Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

On Nov 21, 2016, at 3:46 PM, Eric Blake wrote:


On 11/21/2016 02:36 PM, Eric Blake wrote:
but I'd argue that using qobject_from_jsonf() is already less-than- 
useful.


In fact, we are down to only a handful of users of our modified  
'jsonf'

format (that is, strings that mix JSON with % modifiers):

hw/pci/pcie_aer.c: build a 5-element QDict
monitor.c: build a 1-element QDict which contains a 2-element QDict
qapi/qmp-dispatch.c: build a 2-element QDict
qapi/qmp-event.c: Build a 2-element QDict

plus the testsuite (check-qjson.c).


  It's hard to argue that the
complexity of maintaining our pseudo-printf JSON parser for  
constructing

a QObject with one line is worth the effort compared to the three or
four lines to construct the same QObject by hand.


I'm severely tempted to just rip out all of the poorly- 
underdocumented %
parsing from the JSON parser, as it will simplify our code, without  
much

pain in converting the four real users to just manually build up the
same objects.


Sounds like a good idea.

Re: [Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

On Nov 21, 2016, at 5:02 AM, Paolo Bonzini wrote:




On 21/11/2016 07:30, G 3 wrote:

When I try to use qemu-system-i386, I see this error message:

qobject/qjson.c:69: failed assertion `obj != NULL'.

This is the function where the assertion fails:

/*
 * IMPORTANT: This function aborts on error, thus it must not
 * be used with untrusted arguments.
 */
QObject *qobject_from_jsonf(const char *string, ...)
{
QObject *obj;
va_list ap;

va_start(ap, string);
obj = qobject_from_jsonv(string, );
va_end(ap);

assert(obj != NULL);
return obj;
}

The string argument is this: { 'seconds': %qd, 'microseconds': %qd }

Would anyone know how to fix this problem?


Please include the full backtrace.

Paolo


(gdb) bt
#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x003ddf3c in __eprintf (string=due to optimizations>, expression=to optimizations>, line=optimizations>, filename=optimizations>) at ../../../libgcc/libgcc2.c:2116
#3  0x003ec69c in qobject_from_jsonf (string=0x443f44 "{ 'seconds': % 
qd, 'microseconds': %qd }") at qobject/qjson.c:69
#4  0x0033f6e4 in timestamp_put (qdict=0x2052e00) at /Users/john/ 
desktop/qemu-2.0.0/monitor.c:476
#5  0x0033fd98 in monitor_protocol_event (event=QEVENT_RESUME,  
data=0x0) at /Users/john/desktop/qemu-2.0.0/monitor.c:665

#6  0x002a7a08 in vm_start () at vl.c:1731
#7  0x002b0bec in qemu_main (argc=5, argv=0xb748,  
envp=0xb760) at vl.c:4496
#8  0x00274980 in -[QemuCocoaAppController  
startEmulationWithArgc:argv:] (self=0x1a2ec90, _cmd=0x437398, argc=5,  
argv=0xb748) at ui/cocoa.m:863
#9  0x002748d0 in -[QemuCocoaAppController  
applicationDidFinishLaunching:] (self=0x1a2ec90, _cmd=0x437408,  
note=0x1a27170) at ui/cocoa.m:841

#10 0x92be6e1c in _nsnote_callback ()
#11 0x90805ec0 in __CFXNotificationPost ()
#12 0x907fdf20 in _CFXNotificationPostNotification ()
#13 0x92bd1224 in -[NSNotificationCenter  
postNotificationName:object:userInfo:] ()

#14 0x93793be8 in -[NSApplication _postDidFinishNotification] ()
#15 0x93793ad4 in -[NSApplication _sendFinishLaunchingNotification] ()
#16 0x9379361c in -[NSApplication(NSAppleEventHandling)  
_handleAEOpen:] ()
#17 0x937931c4 in -[NSApplication(NSAppleEventHandling)  
_handleCoreEvent:withReplyEvent:] ()
#18 0x92be7e28 in -[NSAppleEventManager  
dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()

#19 0x92be7c88 in _NSAppleEventManagerGenericHandler ()
#20 0x91500960 in aeDispatchAppleEvent ()
#21 0x915007fc in dispatchEventAndSendReply ()
#22 0x91500654 in aeProcessAppleEvent ()
#23 0x932b02e0 in AEProcessAppleEvent ()
#24 0x9379190c in _DPSNextEvent ()
#25 0x937913f8 in -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:] ()

#26 0x9378d93c in -[NSApplication run] ()
#27 0x002759f0 in main (argc=5, argv=0xb748) at ui/cocoa.m:1000

[Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

When I try to use qemu-system-i386, I see this error message:

qobject/qjson.c:69: failed assertion `obj != NULL'.

This is the function where the assertion fails:

/*
 * IMPORTANT: This function aborts on error, thus it must not
 * be used with untrusted arguments.
 */
QObject *qobject_from_jsonf(const char *string, ...)
{
QObject *obj;
va_list ap;

va_start(ap, string);
obj = qobject_from_jsonv(string, );
va_end(ap);

assert(obj != NULL);
return obj;
}

The string argument is this: { 'seconds': %qd, 'microseconds': %qd }

Would anyone know how to fix this problem?

[Qemu-devel] Suggested command-line for ARM

[G 3]

I tried making a suggested command-line section in your ARM wiki  
page, but my lack of experience with ARM prevents me from testing it.  
What do you think of this as the suggested command-line for qemu- 
system-aarch64:


qemu-system-aarch64 -m  -M  -drive  
if=none,file=,id=hd0 -device virtio-blk- 
device,drive=hd0 -netdev type=tap,id=net0 -device virtio-net- 
device,netdev=net0


If you know of a better one, please let me know. 

[Qemu-devel] Testing PowerPC floating point instructions

[G 3]

Is there an official way to test any of the PowerPC floating point  
instructions in QEMU?

Re: [Qemu-devel] [Qemu-ppc] Problem with QEMU PPC test image

[G 3]

On Nov 17, 2016, at 10:48 AM, Edgar E. Iglesias wrote:


On Thu, Nov 17, 2016 at 10:44:15AM -0500, G 3 wrote:


On Nov 17, 2016, at 8:39 AM, Thomas Huth wrote:


On 17.11.2016 03:25, Programmingkid wrote:
When I run this test disk image: http://wiki.qemu.org/download/ 
ppc-virtexml507-linux-2_6_34.tgz


I see these error messages:
/selftest.sh: line 6: /usr/bin/sha1test: not found
/selftest.sh: line 7: /usr/bin/hmactest: not found

Maybe /usr/bin/sha1sum is what the first test should be. I don't  
see

anything that looked like hmactest in the image file.


I guess these were test programs from the OpenSSL suite:

https://github.com/openssl/openssl/blob/master/test/sha1test.c
https://github.com/openssl/openssl/blob/master/test/hmactest.c

... but apparently have not been included in the image anymore.  
So I'd

suggest that you simply disable them in the selftest.sh script.

Thomas


Thanks for the help.


Hi,

Yes, I think I copied the /selftest.sh script from another rootfs for
another target that had all the openssl tests.

Cheers,
Edgar


Could floating point instructions tests be included in the test image?