Re: [Qemu-devel] [PATCH 1/3] Unified Datagram Socket Transport

2017-07-18 Thread Anton Ivanov

[snip]


Could we keep l2tpv3 option?


The l2tpv3 test is actually a test for recvmmsg. If you can do one 
recvmmsg transport you can do all of them.


Yes, but I wonder whether or not the check for recvmmsg is too simple. 
We probably want something like what AV_VSOCK did, test the support of 
each transport through socket().


We may need this in the future.

I do not think we need it for the first 3 transports lined up for this - 
l2tpv3, gre and raw.  The only reqs are recvmmsg (and sendmmsg in the 
future) and raw sockets. They are very simple :)


So unless we try to fold all of raw initialization (on/off for offloads, 
etc) into the driver we should not need more tests for now. We will need 
them once we add more transports.


By the way - on raw, in addition to cost of timestamps, recvmmsg and 
especially sendmmsg in most cases will have lower number of copies 
compared to tpacket. IMHO there is still a very important use case for 
tpacket, but it will require hw/ work - vm used as a forensic tap. We 
will need to emulate one of the drivers which convey the timestamp so 
that a pcap/tpacket implementation in the VM can get a precise timestamp 
"at real capture".









  if test "$cap_ng" = "yes" ; then
echo "CONFIG_LIBCAP=y" >> $config_host_mak
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 67ba5e26fb..8026ad778a 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_L2TPV3) += l2tpv3.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o


[...]


  -s = DO_UPCAST(NetL2TPV3State, nc, nc);
+s->params = p;
  +s->form_header = &l2tpv3_form_header;
+s->verify_header = &l2tpv3_verify_header;
  s->queue_head = 0;
  s->queue_tail = 0;
  s->header_mismatch = false;


Why not move all above into qemu_new_unified_net()?


Only queue head/tail assignment can move.

raw which uses same backend does not use header_mismatch. Form/verify 
header are different for each sub-transport. F.e. for gre you need 
the gre one, for raw you need the raw one, etc.


Right, I mean pass function pointer to qemu_new_unified_net().


Ack - will do in the next revision.


[snip]

--
Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/




Re: [Qemu-devel] [PULL 00/16] Migration

2017-07-18 Thread Juan Quintela
no-re...@patchew.org wrote:
> Hi,
>
> This series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.

> cc: unrecognized option '-no-integrated-as'
> cc: unrecognized option '-no-integrated-as'

I hope this is not my fault
   GTESTER tests/test-vmstate

> Failed to load simple/primitive:b_1
> Failed to load simple/primitive:i64_2
> Failed to load simple/primitive:i32_1
> Failed to load simple/primitive:i32_1
> Failed to load test/with_tmp:a
> Failed to load test/tmp_child_parent:f
> Failed to load test/tmp_child:parent
> Failed to load test/with_tmp:tmp
> Failed to load test/tmp_child:diff
> Failed to load test/with_tmp:tmp
> Failed to load test/tmp_child:diff
> Failed to load test/with_tmp:tmp


Dave, any good clue?


> ERROR:/tmp/qemu-test/src/tests/test-qga.c:78:fixture_setup: assertion failed 
> (fixture->fd != -1): (-1 != -1)
> GTester: last random seed: R02Sf37f37a8c5f8ed60d31dbaff962d3c9c
> make: *** [check-tests/test-qga] Error 1
> make: *** Waiting for unfinished jobs
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> Back to tcg accelerator.
> Traceback (most recent call last):
>   File "./tests/docker/docker.py", line 382, in 
> sys.exit(main())
>   File "./tests/docker/docker.py", line 379, in main
> return args.cmdobj.run(args, argv)
>   File "./tests/docker/docker.py", line 237, in run
> return Docker().run(argv, args.keep, quiet=args.quiet)
>   File "./tests/docker/docker.py", line 205, in run
> quiet=quiet)
>   File "./tests/docker/docker.py", line 123, in _do_check
> return subprocess.check_call(self._command + cmd, **kwargs)
>   File "/usr/lib64/python2.7/subprocess.py", line 186, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['docker', 'run', '--label', 
> 'com.qemu.instance.uuid=656d0ada6bee11e794aa525400c803e1', '-u', '0', '-t', 
> '--rm', '--net=none', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', 
> '-e', 'V=', '-e', 'J=8', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 
> 'CCACHE_DIR=/var/tmp/ccache', '-v', 
> '/var/tmp/patchew-tester-tmp-uic4vhqy/src/docker-src.2017-07-18-15.22.06.26333:/var/tmp/qemu:z,ro',
>  '-v', '/root/.cache/qemu-docker-ccache:/var/tmp/ccache:z', 'qemu:centos6', 
> '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2
> tests/docker/Makefile.include:124: recipe for target 'docker-run' failed
> make[1]: *** [docker-run] Error 1
> make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-uic4vhqy/src'
> tests/docker/Makefile.include:156: recipe for target 
> 'docker-run-test-quick@centos6' failed
> make: *** [docker-run-test-quick@centos6] Error 2

I am pretty sure that this should be a problem somewhere else, not this
patch, no?

Thanks, Juan.



Re: [Qemu-devel] [PATCH for-2.10 00/10] Correct two minor QMP interface design flaws

2017-07-18 Thread Kevin Wolf
Am 18.07.2017 um 18:08 hat Daniel P. Berrange geschrieben:
> On Tue, Jul 18, 2017 at 03:41:16PM +0200, Markus Armbruster wrote:
> > blockdev-add and migrate-set-parameters overload empty strings to mean
> > something entirely different.  See my memo "qapi: Stop abusing
> > "special" values for something entirely different" for details.
> > 
> > Message-ID: <87379zhrhn@dusky.pond.sub.org>
> > https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg04526.html
> > 
> > This series deprecates these usages of "" in favour of JSON null.
> > Because we're so close to the 2.10 freeze, the implementation is
> > intentionally stupid: rewrite null to "" at first opportunity.  The
> > proper way to do it would be rewriting "" to null, but that requires
> > fixing up code to work with null.  There are TODO comments for that.
> > I'm willing to take care of them in the next development cycle.
> 
> I tested the migrate-set-parameters QMP command with this applied and
> I can still pass "" as the tls-hostname.
> 
> When using query-migrate-parameters we still see "" too.
> 
> So from POV of avoiding regressions for existing usage, we look OK
> here.

Opportunity for a follow-up patch: Automate these tests.

Kevin



Re: [Qemu-devel] [PULL 00/21] Block layer patches

2017-07-18 Thread Kevin Wolf
Am 18.07.2017 um 20:57 hat no-re...@patchew.org geschrieben:
> **
> ERROR:/tmp/qemu-test/src/tests/test-qga.c:78:fixture_setup: assertion failed 
> (fixture->fd != -1): (-1 != -1)
> GTester: last random seed: R02S1e410abb69660daf8fd594a35e52f43b
> make: *** [check-tests/test-qga] Error 1
> make: *** Waiting for unfinished jobs

The patches don't touch qga and I can't reproduce the failure, so I
assume this was just intermittent failure due to a preexisting problem.

Kevin



Re: [Qemu-devel] [PULL 00/14] tcg-next patch queue

2017-07-18 Thread no-reply
Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] [PULL 00/14] tcg-next patch queue
Message-id: 20170719045722.25492-1-...@twiddle.net
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-build@min-glib
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
761fbf9 tcg: Pass generic CPUState to gen_intermediate_code()
a42f4d1 tcg/tci: enable bswap16_i64
2bde084 target/alpha: optimize gen_cvtlq() using deposit op
acd9a6a target/sparc: optimize gen_op_mulscc() using deposit op
384d7a6 target/sparc: optimize various functions using extract op
e22758f target/ppc: optimize various functions using extract op
721b786 target/m68k: optimize bcd_flags() using extract op
e64ab6f target/arm: optimize aarch32 rev16
c1f9071 target/arm: Optimize aarch64 rev16
f1b33df coccinelle: add a script to optimize tcg op using tcg_gen_extract()
bc3d4b2 coccinelle: ignore ASTs pre-parsed cached C files
df4ac1e tcg: Expand glue macros before stringifying helper names
5d7d521 util/cacheinfo: Add missing include for ppc linux
48c0ac4 tcg/mips: reserve a register for the guest_base.

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-u4aqlrve/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-u4aqlrve/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
git-1.7.1-8.el6.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ flex bison zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=b6bcaa6deb7d
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -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
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS pr

Re: [Qemu-devel] [PATCH v2 00/45] tcg: support for multipleTCGcontexts

2017-07-18 Thread jiang.biao2
> For this specific case, the primary problem will be the implicit memory 
> barriers that the i386 guest requires, but that the mips64 host does not 
> provide.
> 
> For tcg/mips/, TCG_TARGET_DEFAULT_MO should be 0, because the mips 
> architecture 
> does not have any implicit memory ordering.  All memory barriers are explicit 
> via SYNC instructions.
> 
> For target/i386, TCG_GUEST_DEFAULT_MO is TCG_MO_ALL & ~TCG_MO_ST_LD, or
> 
> TCG_MO_LD_LD | TCG_MO_LD_ST | TCG_MO_ST_ST
> 
> which means that implicit memory barriers exist between load/load, 
> load/store, 
> store/store, but not store/load.
> 
> In order to fix this, we need to add the missing barriers to the opcode 
> stream.
> 
> The simplest fix for this is to put a call
> 
> tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC)
> 
> at the end of gen_ldst_i32 and gen_ldst_i64.  That should be good enough to 
> make your specific case operate correctly.
> 
> A proper fix will involve (1) emitting those barriers only if the barrier is 
> not implied by the host and (2) optimizing away redundant barriers.
> 
Thanks very much. That really helps a lot.

I'll dig deeper into that and maybe feedback some patches.

Re: [Qemu-devel] [PATCH 1/3] Unified Datagram Socket Transport

2017-07-18 Thread Jason Wang



On 2017年07月19日 13:48, Anton Ivanov wrote:



On 19/07/17 06:39, Jason Wang wrote:



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

1. Creates a common backend for socket transports using
recvmmsg().
2. Migrates L2TPv3 to the new backend


It would be better if you could further split out 2 from this patch.



Signed-off-by: Anton Ivanov 
---
  configure |  10 +-
  net/Makefile.objs |   2 +-
  net/l2tpv3.c  | 531 
+-

  net/net.c |   4 +-
  net/unified.c | 406 +
  net/unified.h | 118 
  6 files changed, 613 insertions(+), 458 deletions(-)
  create mode 100644 net/unified.c
  create mode 100644 net/unified.h

diff --git a/configure b/configure
index a3f0522e8f..99a60b723c 100755
--- a/configure
+++ b/configure
@@ -1862,7 +1862,7 @@ if ! compile_object -Werror ; then
  fi
##
-# L2TPV3 probe
+# UNIFIED probe
cat > $TMPC <
@@ -1870,9 +1870,9 @@ cat > $TMPC <> $config_host_mak
  fi
-if test "$l2tpv3" = "yes" ; then
-  echo "CONFIG_L2TPV3=y" >> $config_host_mak
+if test "$unified" = "yes" ; then
+  echo "CONFIG_UNIFIED=y" >> $config_host_mak
  fi


Could we keep l2tpv3 option?


The l2tpv3 test is actually a test for recvmmsg. If you can do one 
recvmmsg transport you can do all of them.


Yes, but I wonder whether or not the check for recvmmsg is too simple. 
We probably want something like what AV_VSOCK did, test the support of 
each transport through socket().







  if test "$cap_ng" = "yes" ; then
echo "CONFIG_LIBCAP=y" >> $config_host_mak
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 67ba5e26fb..8026ad778a 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_L2TPV3) += l2tpv3.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o


[...]


  -s = DO_UPCAST(NetL2TPV3State, nc, nc);
+s->params = p;
  +s->form_header = &l2tpv3_form_header;
+s->verify_header = &l2tpv3_verify_header;
  s->queue_head = 0;
  s->queue_tail = 0;
  s->header_mismatch = false;


Why not move all above into qemu_new_unified_net()?


Only queue head/tail assignment can move.

raw which uses same backend does not use header_mismatch. Form/verify 
header are different for each sub-transport. F.e. for gre you need the 
gre one, for raw you need the raw one, etc.


Right, I mean pass function pointer to qemu_new_unified_net().






@@ -549,9 +188,9 @@ int net_init_l2tpv3(const Netdev *netdev,
  l2tpv3 = &netdev->u.l2tpv3;
if (l2tpv3->has_ipv6 && l2tpv3->ipv6) {
-s->ipv6 = l2tpv3->ipv6;
+p->ipv6 = l2tpv3->ipv6;
  } else {
-s->ipv6 = false;
+p->ipv6 = false;


[...]


  diff --git a/net/unified.c b/net/unified.c


Not a native speaker, but I think we need a better name here e.g udst 
which is short for Unified Datagram Socket Transport?


I am not a native speaker either :)

I am OK - let's call it udst as this is more descriptive and this 
clearly delineates that you cannot

migrate tcp/socket to it.


Ok.









[...]


+
+static ssize_t net_unified_receive_dgram_iov(NetClientState *nc,
+const struct iovec *iov,
+int iovcnt)
+{
+NetUnifiedState *s = DO_UPCAST(NetUnifiedState, nc, nc);
+
+struct msghdr message;
+int ret;
+
+if (iovcnt > MAX_UNIFIED_IOVCNT - 1) {
+error_report(
+"iovec too long %d > %d, change unified.h",
+iovcnt, MAX_UNIFIED_IOVCNT
+);
+return -1;
+}
+if (s->offset > 0) {


net_l2tpv3_receive_dgram_iov() does not have this check. I guess it 
s->offset=0 will be used by other transport. Maybe it's better to 
delay this change until is has a real user or add a comment here.


The real user is in patch No 2. Raw.


Ok.

Thanks.





Re: [Qemu-devel] [PATCH v4 0/8] KASLR kernel dump support

2017-07-18 Thread Ladi Prosek
On Tue, Jul 18, 2017 at 6:18 PM, Marc-André Lureau
 wrote:
> Hi
>
> On Tue, Jul 18, 2017 at 6:05 PM Ladi Prosek  wrote:
>>
>>
>> > I would like to hear from Ladi how he intended to use the device in
>> > the future, and if he would also prefer ACPI methods and what those
>> > methods should be.
>>
>> We should be able to drive pretty much anything from Windows. I wrote
>> a dummy driver for your earlier prototype just to be sure that ACPI
>> methods are fine, as I had not done or seen that before.
>>
>> There are constraints which may be unique to Windows, though. If the
>> dump-support data is kept in guest-allocated memory, the guest must be
>> able to revoke it (set / call the method with NULL PA?) because
>> Windows drivers must free everything on unload. Unlike Linux, I don't
>
>
> Well, the currently proposed vmcoreinfo device has a 4k memory region to put
> anything you want, Windows shouldn't be allowed to touch it directly (e820
> regions iirc)

Got it. And we would likely use it to put just addr/size there to make
updates atomic. I think we're supposed to update our dump-support data
on memory hot-plug for example.

>> think we can get a piece of memory at startup and keep it for as long
>> as the OS running. It would be flagged as a memory leak. But that
>> should be easy to have. Can't really think of anything else.
>
>
> The question is what kind of data you want to give to the host to help with
> debug. Is this something that can be as simple as addr/size, or you would
> rather have a 4k page to put various things there.

The size of the dump header as currently provided by Windows (that's
the dump-support data we want to pass to the host) is 4k. So I
wouldn't put it directly in the page anyway. That, plus the desire to
update the data at least somewhat atomically, would make me prefer a
simple addr/size pair I think.

>>
>>
>> >>>
>> >>> >> > instead of exporting a physical addess and storing address there.
>> >>> >> > This
>> >>> >> > way you can add more methods as you add functionality.
>> >>> >>
>> >>> >> I'm not saying this is a bad idea (especially because I don't fully
>> >>> >> understand your point), but I will say that I'm quite sad that you
>> >>> >> are
>> >>> >> sending Marc-André back to the drawing board after he posted v4 --
>> >>> >> also
>> >>> >> invalidating my review efforts. :/
>> >>> >>
>> >>> >> Laszlo
>> >>> >
>> >>> > You are right, I should have looked at this sooner. Early RFC
>> >>> > suggested writing into fw cfg directly. I couldn't find any
>> >>> > discussion around this - why was this abandoned?
>> >>>
>> >>> Violation (or rather abuse) of layers iirc
>> >>
>> >> Hmm.  I tried to find discussion about that and failed.  It is
>> >> available
>> >> through QEMU0002 in ACPI - would it be OK if guests went through that?
>> >
>> > I wouldn't mind, although merging functionality in a single device
>> > isn't what I would think of first. I guess Ladi would be happier with
>> > a single device. I suppose it shouldn't break drivers if we had
>> > memory, io, methods etc to the device?
>>
>> Yeah, it would be nice if this was part of pvpanic. Even something
>> really simple like:
>>
>>  /* The bit of supported pv event */
>>  #define PVPANIC_F_PANICKED  0
>> +#define PVPANIC_F_DUMP_INFO_SET  1
>
>
> QEMU0002 is fw_cfg

Ah, sorry, I got confused.

>>
>>
>> - memory_region_init_io(&s->io, OBJECT(s), &pvpanic_ops, s, "pvpanic",
>> 1);
>> +memory_region_init_io(&s->io, OBJECT(s), &pvpanic_ops, s,
>> "pvpanic", 32); // or whatever
>>
>> The guest writes to two or three registers: PA, size, type?, then sets
>> the PVPANIC_F_DUMP_INFO_SET bit.
>>
>> Although not sure if extending the I/O region is OK. And of course I
>> only need this on x86 :p
>>
>
> I would rather have a solution that works on various archs. It's a shame
> pvpanic was designed with x86 only in mind imho.

Understood. Thanks!

>
> --
> Marc-André Lureau



Re: [Qemu-devel] [PATCH 3/3] Unified Datagram Socket Transport - raw support

2017-07-18 Thread Jason Wang



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

This adds raw socket support to the unified socket driver.


Interesting, in fact, I've finished a tpacket backend. Let me post it 
sometime after hardfreeze.



Signed-off-by: Anton Ivanov 
---
  net/Makefile.objs |   2 +-
  net/clients.h |   3 ++
  net/net.c |   5 +++
  net/raw.c | 123 ++
  qapi-schema.json  |  25 +--
  qemu-options.hx   |  33 +++
  6 files changed, 186 insertions(+), 5 deletions(-)
  create mode 100644 net/raw.c

diff --git a/net/Makefile.objs b/net/Makefile.objs
index 128164e39b..54cf7dd194 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o gre.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o gre.o raw.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o
diff --git a/net/clients.h b/net/clients.h
index 8f8a59aee3..98d8ae59b7 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -53,6 +53,9 @@ int net_init_l2tpv3(const Netdev *netdev, const char *name,
  int net_init_gre(const Netdev *netdev, const char *name,
  NetClientState *peer, Error **errp);
  
+int net_init_raw(const Netdev *netdev, const char *name,

+NetClientState *peer, Error **errp);
+
  #ifdef CONFIG_VDE
  int net_init_vde(const Netdev *netdev, const char *name,
   NetClientState *peer, Error **errp);
diff --git a/net/net.c b/net/net.c
index b75b6e8154..2d988a120c 100644
--- a/net/net.c
+++ b/net/net.c
@@ -962,6 +962,7 @@ static int (* const 
net_client_init_fun[NET_CLIENT_DRIVER__MAX])(
  #ifdef CONFIG_UNIFIED
  [NET_CLIENT_DRIVER_L2TPV3] = net_init_l2tpv3,
  [NET_CLIENT_DRIVER_GRE] = net_init_gre,
+[NET_CLIENT_DRIVER_RAW] = net_init_raw,
  #endif
  };
  
@@ -1017,6 +1018,10 @@ static int net_client_init1(const void *object, bool is_netdev, Error **errp)

  legacy.type = NET_CLIENT_DRIVER_GRE;
  legacy.u.gre = opts->u.gre;
  break;
+case NET_LEGACY_OPTIONS_TYPE_RAW:
+legacy.type = NET_CLIENT_DRIVER_RAW;
+legacy.u.raw = opts->u.raw;
+break;
  case NET_LEGACY_OPTIONS_TYPE_SOCKET:
  legacy.type = NET_CLIENT_DRIVER_SOCKET;
  legacy.u.socket = opts->u.socket;
diff --git a/net/raw.c b/net/raw.c
new file mode 100644
index 00..73e2fd9fe3
--- /dev/null
+++ b/net/raw.c
@@ -0,0 +1,123 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2015-2017 Cambridge Greys Limited
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2012-2014 Cisco Systems
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include 
+#include 
+#include 
+#include "net/net.h"
+ #include 
+#include 
+#include 
+#include "clients.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/option.h"
+#include "qemu/sockets.h"
+#include "qemu/iov.h"
+#include "qemu/main-loop.h"
+#include "unified.h"
+
+static int noop(void *us, uint8_t *buf)
+{
+return 0;
+}
+
+int net_init_raw(const Netdev *netdev,
+const char *name,
+NetClientState *peer, Error **errp)
+{
+
+const NetdevRawOptions *raw;
+NetUnifiedState *s;
+NetClientState *nc;
+
+int fd = -1;
+int err;
+
+struct ifreq ifr;
+struct sockaddr_ll sock;
+
+
+nc = qemu_new_unified_net_client(name, peer);
+
+s = DO_UPCAST(NetUnifiedState, nc, nc);
+
+fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
+if (fd == -1) {
+err = -errno;
+error_report("raw_open : raw socket creation failed,

Re: [Qemu-devel] [PATCH 2/3] Unified Datagram Socket Transport - GRE support

2017-07-18 Thread Anton Ivanov

OK. Will address both comments in next version.

Brgds,

A.


On 19/07/17 06:48, Jason Wang wrote:



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

This adds GRETAP support to the unified socket driver.

Signed-off-by: Anton Ivanov 
---
  net/Makefile.objs |   2 +-
  net/clients.h |   4 +
  net/gre.c | 313 
++

  net/net.c |   5 +
  qapi-schema.json  |  46 +++-
  qemu-options.hx   |  63 ++-
  6 files changed, 425 insertions(+), 8 deletions(-)
  create mode 100644 net/gre.c

diff --git a/net/Makefile.objs b/net/Makefile.objs
index 8026ad778a..128164e39b 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o gre.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o
diff --git a/net/clients.h b/net/clients.h
index 5cae479730..8f8a59aee3 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -49,6 +49,10 @@ int net_init_bridge(const Netdev *netdev, const 
char *name,

int net_init_l2tpv3(const Netdev *netdev, const char *name,
  NetClientState *peer, Error **errp);
+
+int net_init_gre(const Netdev *netdev, const char *name,
+NetClientState *peer, Error **errp);
+
  #ifdef CONFIG_VDE
  int net_init_vde(const Netdev *netdev, const char *name,
   NetClientState *peer, Error **errp);
diff --git a/net/gre.c b/net/gre.c
new file mode 100644
index 00..ee8c36dd4d
--- /dev/null
+++ b/net/gre.c
@@ -0,0 +1,313 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2015-2017 Cambridge GREys Limited
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2012-2014 Cisco Systems
+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a copy
+ * of this software and associated documentation files (the 
"Software"), to deal
+ * in the Software without restriction, including without limitation 
the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, 
and/or sell
+ * copies of the Software, and to permit persons to whom the 
Software is

+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be 
included in

+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
DEALINGS IN

+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include 
+#include "net/net.h"
+#include "clients.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/option.h"
+#include "qemu/sockets.h"
+#include "qemu/iov.h"
+#include "qemu/main-loop.h"
+#include "unified.h"
+
+/* IANA-assigned IP protocol ID for GRE */
+
+
+#ifndef IPPROTO_GRE
+#define IPPROTO_GRE 0x2F
+#endif
+
+#define GRE_MODE_CHECKSUM htons(8 << 12)   /* checksum */
+#define GRE_MODE_RESERVED htons(4 << 12)   /* unused */
+#define GRE_MODE_KEY  htons(2 << 12)   /* KEY present */
+#define GRE_MODE_SEQUENCE htons(1 << 12)   /* no sequence */
+
+
+/* GRE TYPE for Ethernet in GRE aka GRETAP */
+
+#define GRE_IRB htons(0x6558)
+
+struct gre_minimal_header {
+   uint16_t header;
+   uint16_t arptype;
+};
+
+typedef struct GRETunnelParams {
+/*
+ * GRE parameters
+ */
+
+uint32_t rx_key;
+uint32_t tx_key;
+uint32_t sequence;
+
+/* Flags */
+
+bool ipv6;
+bool udp;
+bool has_sequence;
+bool pin_sequence;
+bool checksum;
+bool key;
+
+/* Precomputed GRE specific offsets */
+
+uint32_t key_offset;
+uint32_t sequence_offset;
+uint32_t checksum_offset;
+
+struct gre_minimal_header header_bits;
+
+} GRETunnelParams;
+
+
+
+static void gre_form_header(void *us)
+{
+NetUnifiedState *s = (NetUnifiedState *) us;
+GRETunnelParams *p = (GRETunnelParams *) s->params;
+
+uint32_t *sequence;
+
+*((uint32_t *) s->header_buf) = *((uint32_t *) &p->header_bits);
+
+if (p->key) {
+stl_be_p(
+(uint32_t *) (s->header_buf + p->key_offset),
+p->tx_key
+);
+}
+if (p->has_sequence) {
+sequence = (uint32_t *)(s->header_buf + p->sequence_offset);
+if (p->pin_sequence) {
+*sequence = 0;
+} else {
+stl_be_p(sequence, +

Re: [Qemu-devel] [PATCH 1/3] Unified Datagram Socket Transport

2017-07-18 Thread Anton Ivanov



On 19/07/17 06:39, Jason Wang wrote:



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

1. Creates a common backend for socket transports using
recvmmsg().
2. Migrates L2TPv3 to the new backend


It would be better if you could further split out 2 from this patch.



Signed-off-by: Anton Ivanov 
---
  configure |  10 +-
  net/Makefile.objs |   2 +-
  net/l2tpv3.c  | 531 
+-

  net/net.c |   4 +-
  net/unified.c | 406 +
  net/unified.h | 118 
  6 files changed, 613 insertions(+), 458 deletions(-)
  create mode 100644 net/unified.c
  create mode 100644 net/unified.h

diff --git a/configure b/configure
index a3f0522e8f..99a60b723c 100755
--- a/configure
+++ b/configure
@@ -1862,7 +1862,7 @@ if ! compile_object -Werror ; then
  fi
##
-# L2TPV3 probe
+# UNIFIED probe
cat > $TMPC <
@@ -1870,9 +1870,9 @@ cat > $TMPC <> $config_host_mak
  fi
-if test "$l2tpv3" = "yes" ; then
-  echo "CONFIG_L2TPV3=y" >> $config_host_mak
+if test "$unified" = "yes" ; then
+  echo "CONFIG_UNIFIED=y" >> $config_host_mak
  fi


Could we keep l2tpv3 option?


The l2tpv3 test is actually a test for recvmmsg. If you can do one 
recvmmsg transport you can do all of them.





  if test "$cap_ng" = "yes" ; then
echo "CONFIG_LIBCAP=y" >> $config_host_mak
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 67ba5e26fb..8026ad778a 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_L2TPV3) += l2tpv3.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o
diff --git a/net/l2tpv3.c b/net/l2tpv3.c
index 6745b78990..05413c9cbd 100644
--- a/net/l2tpv3.c
+++ b/net/l2tpv3.c
@@ -1,6 +1,7 @@
  /*
   * QEMU System Emulator
   *
+ * Copyright (c) 2015-2017 Cambridge Greys Limited
   * Copyright (c) 2003-2008 Fabrice Bellard
   * Copyright (c) 2012-2014 Cisco Systems
   *
@@ -34,19 +35,9 @@
  #include "qemu/sockets.h"
  #include "qemu/iov.h"
  #include "qemu/main-loop.h"
+#include "unified.h"
-/* The buffer size needs to be investigated for optimum numbers and
- * optimum means of paging in on different systems. This size is
- * chosen to be sufficient to accommodate one packet with some headers
- */
-
-#define BUFFER_ALIGN sysconf(_SC_PAGESIZE)
-#define BUFFER_SIZE 2048
-#define IOVSIZE 2
-#define MAX_L2TPV3_MSGCNT 64
-#define MAX_L2TPV3_IOVCNT (MAX_L2TPV3_MSGCNT * IOVSIZE)
-
  /* Header set to 0x3 signifies a data packet */
#define L2TPV3_DATA_PACKET 0x3
@@ -57,31 +48,7 @@
  #define IPPROTO_L2TP 0x73
  #endif
  -typedef struct NetL2TPV3State {
-NetClientState nc;
-int fd;
-
-/*
- * these are used for xmit - that happens packet a time
- * and for first sign of life packet (easier to parse that once)
- */
-
-uint8_t *header_buf;
-struct iovec *vec;
-
-/*
- * these are used for receive - try to "eat" up to 32 packets at 
a time

- */
-
-struct mmsghdr *msgvec;
-
-/*
- * peer address
- */
-
-struct sockaddr_storage *dgram_dst;
-uint32_t dst_size;
-
+typedef struct L2TPV3TunnelParams {
  /*
   * L2TPv3 parameters
   */
@@ -90,37 +57,8 @@ typedef struct NetL2TPV3State {
  uint64_t tx_cookie;
  uint32_t rx_session;
  uint32_t tx_session;
-uint32_t header_size;
  uint32_t counter;
  -/*
-* DOS avoidance in error handling
-*/
-
-bool header_mismatch;
-
-/*
- * Ring buffer handling
- */
-
-int queue_head;
-int queue_tail;
-int queue_depth;
-
-/*
- * Precomputed offsets
- */
-
-uint32_t offset;
-uint32_t cookie_offset;
-uint32_t counter_offset;
-uint32_t session_offset;
-
-/* Poll Control */
-
-bool read_poll;
-bool write_poll;
-
  /* Flags */
bool ipv6;
@@ -130,189 +68,62 @@ typedef struct NetL2TPV3State {
  bool cookie;
  bool cookie_is_64;
  -} NetL2TPV3State;
-
-static void net_l2tpv3_send(void *opaque);
-static void l2tpv3_writable(void *opaque);
-
-static void l2tpv3_update_fd_handler(NetL2TPV3State *s)
-{
-qemu_set_fd_handler(s->fd,
-s->read_poll ? net_l2tpv3_send : NULL,
-s->write_poll ? l2tpv3_writable : NULL,
-s);
-}
-
-static void l2tpv3_read_poll(NetL2TPV3State *s, bool enable)
-{
-if (s->read_poll != enable) {
-s->read_poll = enable;
-l2tpv3_update_fd_handler(s);
-}
-}
+/* Precomputed L2TPV3 specific offsets */
+uint32_t cookie_offset;
+uint32_t counter_offset;
+uint32_t session_offset;
  -static void l2tpv3_write_poll(N

Re: [Qemu-devel] [PATCH 2/3] Unified Datagram Socket Transport - GRE support

2017-07-18 Thread Jason Wang



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

This adds GRETAP support to the unified socket driver.

Signed-off-by: Anton Ivanov 
---
  net/Makefile.objs |   2 +-
  net/clients.h |   4 +
  net/gre.c | 313 ++
  net/net.c |   5 +
  qapi-schema.json  |  46 +++-
  qemu-options.hx   |  63 ++-
  6 files changed, 425 insertions(+), 8 deletions(-)
  create mode 100644 net/gre.c

diff --git a/net/Makefile.objs b/net/Makefile.objs
index 8026ad778a..128164e39b 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o gre.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o
diff --git a/net/clients.h b/net/clients.h
index 5cae479730..8f8a59aee3 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -49,6 +49,10 @@ int net_init_bridge(const Netdev *netdev, const char *name,
  
  int net_init_l2tpv3(const Netdev *netdev, const char *name,

  NetClientState *peer, Error **errp);
+
+int net_init_gre(const Netdev *netdev, const char *name,
+NetClientState *peer, Error **errp);
+
  #ifdef CONFIG_VDE
  int net_init_vde(const Netdev *netdev, const char *name,
   NetClientState *peer, Error **errp);
diff --git a/net/gre.c b/net/gre.c
new file mode 100644
index 00..ee8c36dd4d
--- /dev/null
+++ b/net/gre.c
@@ -0,0 +1,313 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2015-2017 Cambridge GREys Limited
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2012-2014 Cisco Systems
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include 
+#include "net/net.h"
+#include "clients.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/option.h"
+#include "qemu/sockets.h"
+#include "qemu/iov.h"
+#include "qemu/main-loop.h"
+#include "unified.h"
+
+/* IANA-assigned IP protocol ID for GRE */
+
+
+#ifndef IPPROTO_GRE
+#define IPPROTO_GRE 0x2F
+#endif
+
+#define GRE_MODE_CHECKSUM htons(8 << 12)   /* checksum */
+#define GRE_MODE_RESERVED htons(4 << 12)   /* unused */
+#define GRE_MODE_KEY  htons(2 << 12)   /* KEY present */
+#define GRE_MODE_SEQUENCE htons(1 << 12)   /* no sequence */
+
+
+/* GRE TYPE for Ethernet in GRE aka GRETAP */
+
+#define GRE_IRB htons(0x6558)
+
+struct gre_minimal_header {
+   uint16_t header;
+   uint16_t arptype;
+};
+
+typedef struct GRETunnelParams {
+/*
+ * GRE parameters
+ */
+
+uint32_t rx_key;
+uint32_t tx_key;
+uint32_t sequence;
+
+/* Flags */
+
+bool ipv6;
+bool udp;
+bool has_sequence;
+bool pin_sequence;
+bool checksum;
+bool key;
+
+/* Precomputed GRE specific offsets */
+
+uint32_t key_offset;
+uint32_t sequence_offset;
+uint32_t checksum_offset;
+
+struct gre_minimal_header header_bits;
+
+} GRETunnelParams;
+
+
+
+static void gre_form_header(void *us)
+{
+NetUnifiedState *s = (NetUnifiedState *) us;
+GRETunnelParams *p = (GRETunnelParams *) s->params;
+
+uint32_t *sequence;
+
+*((uint32_t *) s->header_buf) = *((uint32_t *) &p->header_bits);
+
+if (p->key) {
+stl_be_p(
+(uint32_t *) (s->header_buf + p->key_offset),
+p->tx_key
+);
+}
+if (p->has_sequence) {
+sequence = (uint32_t *)(s->header_buf + p->sequence_offset);
+if (p->pin_sequence) {
+*sequence = 0;
+} else {
+stl_be_p(sequence, ++p->sequence);
+}
+}
+}
+
+static int gre_verify_header(void *us, uint8_t *buf)
+{
+
+NetUnifiedSta

Re: [Qemu-devel] [PATCH 1/3] Unified Datagram Socket Transport

2017-07-18 Thread Jason Wang



On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:

From: Anton Ivanov 

1. Creates a common backend for socket transports using
recvmmsg().
2. Migrates L2TPv3 to the new backend


It would be better if you could further split out 2 from this patch.



Signed-off-by: Anton Ivanov 
---
  configure |  10 +-
  net/Makefile.objs |   2 +-
  net/l2tpv3.c  | 531 +-
  net/net.c |   4 +-
  net/unified.c | 406 +
  net/unified.h | 118 
  6 files changed, 613 insertions(+), 458 deletions(-)
  create mode 100644 net/unified.c
  create mode 100644 net/unified.h

diff --git a/configure b/configure
index a3f0522e8f..99a60b723c 100755
--- a/configure
+++ b/configure
@@ -1862,7 +1862,7 @@ if ! compile_object -Werror ; then
  fi
  
  ##

-# L2TPV3 probe
+# UNIFIED probe
  
  cat > $TMPC <
  #include 
@@ -1870,9 +1870,9 @@ cat > $TMPC <  
  ##

@@ -5458,8 +5458,8 @@ fi
  if test "$netmap" = "yes" ; then
echo "CONFIG_NETMAP=y" >> $config_host_mak
  fi
-if test "$l2tpv3" = "yes" ; then
-  echo "CONFIG_L2TPV3=y" >> $config_host_mak
+if test "$unified" = "yes" ; then
+  echo "CONFIG_UNIFIED=y" >> $config_host_mak
  fi


Could we keep l2tpv3 option?


  if test "$cap_ng" = "yes" ; then
echo "CONFIG_LIBCAP=y" >> $config_host_mak
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 67ba5e26fb..8026ad778a 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o
  common-obj-y += socket.o
  common-obj-y += dump.o
  common-obj-y += eth.o
-common-obj-$(CONFIG_L2TPV3) += l2tpv3.o
+common-obj-$(CONFIG_UNIFIED) += l2tpv3.o unified.o
  common-obj-$(CONFIG_POSIX) += vhost-user.o
  common-obj-$(CONFIG_SLIRP) += slirp.o
  common-obj-$(CONFIG_VDE) += vde.o
diff --git a/net/l2tpv3.c b/net/l2tpv3.c
index 6745b78990..05413c9cbd 100644
--- a/net/l2tpv3.c
+++ b/net/l2tpv3.c
@@ -1,6 +1,7 @@
  /*
   * QEMU System Emulator
   *
+ * Copyright (c) 2015-2017 Cambridge Greys Limited
   * Copyright (c) 2003-2008 Fabrice Bellard
   * Copyright (c) 2012-2014 Cisco Systems
   *
@@ -34,19 +35,9 @@
  #include "qemu/sockets.h"
  #include "qemu/iov.h"
  #include "qemu/main-loop.h"
+#include "unified.h"
  
  
-/* The buffer size needs to be investigated for optimum numbers and

- * optimum means of paging in on different systems. This size is
- * chosen to be sufficient to accommodate one packet with some headers
- */
-
-#define BUFFER_ALIGN sysconf(_SC_PAGESIZE)
-#define BUFFER_SIZE 2048
-#define IOVSIZE 2
-#define MAX_L2TPV3_MSGCNT 64
-#define MAX_L2TPV3_IOVCNT (MAX_L2TPV3_MSGCNT * IOVSIZE)
-
  /* Header set to 0x3 signifies a data packet */
  
  #define L2TPV3_DATA_PACKET 0x3

@@ -57,31 +48,7 @@
  #define IPPROTO_L2TP 0x73
  #endif
  
-typedef struct NetL2TPV3State {

-NetClientState nc;
-int fd;
-
-/*
- * these are used for xmit - that happens packet a time
- * and for first sign of life packet (easier to parse that once)
- */
-
-uint8_t *header_buf;
-struct iovec *vec;
-
-/*
- * these are used for receive - try to "eat" up to 32 packets at a time
- */
-
-struct mmsghdr *msgvec;
-
-/*
- * peer address
- */
-
-struct sockaddr_storage *dgram_dst;
-uint32_t dst_size;
-
+typedef struct L2TPV3TunnelParams {
  /*
   * L2TPv3 parameters
   */
@@ -90,37 +57,8 @@ typedef struct NetL2TPV3State {
  uint64_t tx_cookie;
  uint32_t rx_session;
  uint32_t tx_session;
-uint32_t header_size;
  uint32_t counter;
  
-/*

-* DOS avoidance in error handling
-*/
-
-bool header_mismatch;
-
-/*
- * Ring buffer handling
- */
-
-int queue_head;
-int queue_tail;
-int queue_depth;
-
-/*
- * Precomputed offsets
- */
-
-uint32_t offset;
-uint32_t cookie_offset;
-uint32_t counter_offset;
-uint32_t session_offset;
-
-/* Poll Control */
-
-bool read_poll;
-bool write_poll;
-
  /* Flags */
  
  bool ipv6;

@@ -130,189 +68,62 @@ typedef struct NetL2TPV3State {
  bool cookie;
  bool cookie_is_64;
  
-} NetL2TPV3State;

-
-static void net_l2tpv3_send(void *opaque);
-static void l2tpv3_writable(void *opaque);
-
-static void l2tpv3_update_fd_handler(NetL2TPV3State *s)
-{
-qemu_set_fd_handler(s->fd,
-s->read_poll ? net_l2tpv3_send : NULL,
-s->write_poll ? l2tpv3_writable : NULL,
-s);
-}
-
-static void l2tpv3_read_poll(NetL2TPV3State *s, bool enable)
-{
-if (s->read_poll != enable) {
-s->read_poll = enable;
-l2tpv3_update_fd_handler(s);
-}
-}
+/* Precomputed L2TPV3 specific offsets */
+uint32_t cookie_offset;
+uint32_t counter_offset;
+uint32_t session_offset;
  
-static void l2tpv3_write_

[Qemu-devel] [PULL 10/14] target/sparc: optimize various functions using extract op

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Done with the Coccinelle semantic patch
scripts/coccinelle/tcg_gen_extract.cocci.

Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 target/sparc/translate.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index aa6734d..67a83b7 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -380,29 +380,25 @@ static inline void gen_goto_tb(DisasContext *s, int 
tb_num,
 static inline void gen_mov_reg_N(TCGv reg, TCGv_i32 src)
 {
 tcg_gen_extu_i32_tl(reg, src);
-tcg_gen_shri_tl(reg, reg, PSR_NEG_SHIFT);
-tcg_gen_andi_tl(reg, reg, 0x1);
+tcg_gen_extract_tl(reg, reg, PSR_NEG_SHIFT, 1);
 }
 
 static inline void gen_mov_reg_Z(TCGv reg, TCGv_i32 src)
 {
 tcg_gen_extu_i32_tl(reg, src);
-tcg_gen_shri_tl(reg, reg, PSR_ZERO_SHIFT);
-tcg_gen_andi_tl(reg, reg, 0x1);
+tcg_gen_extract_tl(reg, reg, PSR_ZERO_SHIFT, 1);
 }
 
 static inline void gen_mov_reg_V(TCGv reg, TCGv_i32 src)
 {
 tcg_gen_extu_i32_tl(reg, src);
-tcg_gen_shri_tl(reg, reg, PSR_OVF_SHIFT);
-tcg_gen_andi_tl(reg, reg, 0x1);
+tcg_gen_extract_tl(reg, reg, PSR_OVF_SHIFT, 1);
 }
 
 static inline void gen_mov_reg_C(TCGv reg, TCGv_i32 src)
 {
 tcg_gen_extu_i32_tl(reg, src);
-tcg_gen_shri_tl(reg, reg, PSR_CARRY_SHIFT);
-tcg_gen_andi_tl(reg, reg, 0x1);
+tcg_gen_extract_tl(reg, reg, PSR_CARRY_SHIFT, 1);
 }
 
 static inline void gen_op_add_cc(TCGv dst, TCGv src1, TCGv src2)
@@ -638,8 +634,7 @@ static inline void gen_op_mulscc(TCGv dst, TCGv src1, TCGv 
src2)
 // env->y = (b2 << 31) | (env->y >> 1);
 tcg_gen_andi_tl(r_temp, cpu_cc_src, 0x1);
 tcg_gen_shli_tl(r_temp, r_temp, 31);
-tcg_gen_shri_tl(t0, cpu_y, 1);
-tcg_gen_andi_tl(t0, t0, 0x7fff);
+tcg_gen_extract_tl(t0, cpu_y, 1, 31);
 tcg_gen_or_tl(t0, t0, r_temp);
 tcg_gen_andi_tl(cpu_y, t0, 0x);
 
-- 
2.9.4




[Qemu-devel] [PULL 14/14] tcg: Pass generic CPUState to gen_intermediate_code()

2017-07-18 Thread Richard Henderson
From: Lluís Vilanova 

Needed to implement a target-agnostic gen_intermediate_code()
in the future.

Reviewed-by: David Gibson 
Reviewed-by: Richard Henderson 
Reviewed-by: Alex Benneé 
Reviewed-by: Emilio G. Cota 
Signed-off-by: Lluís Vilanova 
Message-Id: <150002025498.22386.18051908483085660588.st...@frigg.lan>
Signed-off-by: Richard Henderson 
---
 include/exec/exec-all.h   | 2 +-
 target/arm/translate.h| 4 ++--
 accel/tcg/translate-all.c | 2 +-
 target/alpha/translate.c  | 5 ++---
 target/arm/translate-a64.c| 6 +++---
 target/arm/translate.c| 6 +++---
 target/cris/translate.c   | 7 +++
 target/hppa/translate.c   | 5 ++---
 target/i386/translate.c   | 5 ++---
 target/lm32/translate.c   | 4 ++--
 target/m68k/translate.c   | 5 ++---
 target/microblaze/translate.c | 4 ++--
 target/mips/translate.c   | 5 ++---
 target/moxie/translate.c  | 4 ++--
 target/nios2/translate.c  | 5 ++---
 target/openrisc/translate.c   | 4 ++--
 target/ppc/translate.c| 5 ++---
 target/s390x/translate.c  | 5 ++---
 target/sh4/translate.c| 5 ++---
 target/sparc/translate.c  | 5 ++---
 target/tilegx/translate.c | 5 ++---
 target/tricore/translate.c| 5 ++---
 target/unicore32/translate.c  | 5 ++---
 target/xtensa/translate.c | 5 ++---
 24 files changed, 49 insertions(+), 64 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 87b1b74..440fc31 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -66,7 +66,7 @@ typedef ram_addr_t tb_page_addr_t;
 
 #include "qemu/log.h"
 
-void gen_intermediate_code(CPUArchState *env, struct TranslationBlock *tb);
+void gen_intermediate_code(CPUState *cpu, struct TranslationBlock *tb);
 void restore_state_to_opc(CPUArchState *env, struct TranslationBlock *tb,
   target_ulong *data);
 
diff --git a/target/arm/translate.h b/target/arm/translate.h
index 12fd79b..2fe144b 100644
--- a/target/arm/translate.h
+++ b/target/arm/translate.h
@@ -149,7 +149,7 @@ static void disas_set_insn_syndrome(DisasContext *s, 
uint32_t syn)
 
 #ifdef TARGET_AARCH64
 void a64_translate_init(void);
-void gen_intermediate_code_a64(ARMCPU *cpu, TranslationBlock *tb);
+void gen_intermediate_code_a64(CPUState *cpu, TranslationBlock *tb);
 void gen_a64_set_pc_im(uint64_t val);
 void aarch64_cpu_dump_state(CPUState *cs, FILE *f,
 fprintf_function cpu_fprintf, int flags);
@@ -158,7 +158,7 @@ static inline void a64_translate_init(void)
 {
 }
 
-static inline void gen_intermediate_code_a64(ARMCPU *cpu, TranslationBlock *tb)
+static inline void gen_intermediate_code_a64(CPUState *cpu, TranslationBlock 
*tb)
 {
 }
 
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 090ebad..37ecafa 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -1280,7 +1280,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
 tcg_func_start(&tcg_ctx);
 
 tcg_ctx.cpu = ENV_GET_CPU(env);
-gen_intermediate_code(env, tb);
+gen_intermediate_code(cpu, tb);
 tcg_ctx.cpu = NULL;
 
 trace_translate_block(tb, tb->pc, tb->tc_ptr);
diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 2bffbae..2abf319 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -2909,10 +2909,9 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 return ret;
 }
 
-void gen_intermediate_code(CPUAlphaState *env, struct TranslationBlock *tb)
+void gen_intermediate_code(CPUState *cs, struct TranslationBlock *tb)
 {
-AlphaCPU *cpu = alpha_env_get_cpu(env);
-CPUState *cs = CPU(cpu);
+CPUAlphaState *env = cs->env_ptr;
 DisasContext ctx, *ctxp = &ctx;
 target_ulong pc_start;
 target_ulong pc_mask;
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 5bb0f8e..883e9df 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -11179,10 +11179,10 @@ static void disas_a64_insn(CPUARMState *env, 
DisasContext *s)
 free_tmp_a64(s);
 }
 
-void gen_intermediate_code_a64(ARMCPU *cpu, TranslationBlock *tb)
+void gen_intermediate_code_a64(CPUState *cs, TranslationBlock *tb)
 {
-CPUState *cs = CPU(cpu);
-CPUARMState *env = &cpu->env;
+CPUARMState *env = cs->env_ptr;
+ARMCPU *cpu = arm_env_get_cpu(env);
 DisasContext dc1, *dc = &dc1;
 target_ulong pc_start;
 target_ulong next_page_start;
diff --git a/target/arm/translate.c b/target/arm/translate.c
index d3003ae..d1a5f56 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -11795,10 +11795,10 @@ static bool insn_crosses_page(CPUARMState *env, 
DisasContext *s)
 }
 
 /* generate intermediate code for basic block 'tb'.  */
-void gen_intermediate_code(CPUARMState *env, TranslationBlock *tb)
+void gen_intermediate_code(CPUState *cs, TranslationBlock *tb)
 {
+CPUARMState *env = cs->env_ptr;
 ARMCPU *cpu = arm_env_get_cpu(env);
-CPUState 

[Qemu-devel] [PULL 13/14] tcg/tci: enable bswap16_i64

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Altough correctly implemented, bswap16_i64() never got tested/executed so the
safety TODO() statement was never removed.

Since it got now tested the TODO() can be removed.

while running Alex Bennée's image aarch64-linux-3.15rc2-buildroot.img:

Trace 0x7fa1904b0890 [0: ffc00036cd04]

IN:
0xffc00036cd24:  5ac00694  rev16 w20, w20

OP:
  ffc00036cd24  
 ext32u_i64 tmp3,x20
 ext16u_i64 tmp2,tmp3
 bswap16_i64 x20,tmp2
 movi_i64 tmp4,$0x10
 shr_i64 tmp2,tmp3,tmp4
 ext16u_i64 tmp2,tmp2
 bswap16_i64 tmp2,tmp2
 deposit_i64 x20,x20,tmp2,$0x10,$0x10

Linking TBs 0x7fa1904b0890 [ffc00036cd04] index 0 -> 0x7fa1904b0aa0 
[ffc00036cd24]
Trace 0x7fa1904b0aa0 [0: ffc00036cd24]
TODO qemu/tci.c:1049: tcg_qemu_tb_exec()
qemu/tci.c:1049: tcg fatal error
Aborted

Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Jaroslaw Pelczar 
Reviewed-by: Alex Bennée 
Reviewed-by: Eric Blake 
Reviewed-by: Stefan Weil 
Message-Id: <20170718045540.16322-11-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 tcg/tci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tcg/tci.c b/tcg/tci.c
index 4bdc645..f39bfb9 100644
--- a/tcg/tci.c
+++ b/tcg/tci.c
@@ -1046,7 +1046,6 @@ uintptr_t tcg_qemu_tb_exec(CPUArchState *env, uint8_t 
*tb_ptr)
 break;
 #if TCG_TARGET_HAS_bswap16_i64
 case INDEX_op_bswap16_i64:
-TODO();
 t0 = *tb_ptr++;
 t1 = tci_read_r16(&tb_ptr);
 tci_write_reg64(t0, bswap16(t1));
-- 
2.9.4




[Qemu-devel] [PULL 08/14] target/m68k: optimize bcd_flags() using extract op

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Done with the Coccinelle semantic patch
scripts/coccinelle/tcg_gen_extract.cocci.

Signed-off-by: Philippe Mathieu-Daudé 
Acked-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
Message-Id: <20170718045540.16322-5-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 target/m68k/translate.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 3a519b7..e709e6c 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -1749,8 +1749,7 @@ static void bcd_flags(TCGv val)
 tcg_gen_andi_i32(QREG_CC_C, val, 0x0ff);
 tcg_gen_or_i32(QREG_CC_Z, QREG_CC_Z, QREG_CC_C);
 
-tcg_gen_shri_i32(QREG_CC_C, val, 8);
-tcg_gen_andi_i32(QREG_CC_C, QREG_CC_C, 1);
+tcg_gen_extract_i32(QREG_CC_C, val, 8, 1);
 
 tcg_gen_mov_i32(QREG_CC_X, QREG_CC_C);
 }
-- 
2.9.4




[Qemu-devel] [PULL 11/14] target/sparc: optimize gen_op_mulscc() using deposit op

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20170718045540.16322-9-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 target/sparc/translate.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 67a83b7..a425efb 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -632,11 +632,8 @@ static inline void gen_op_mulscc(TCGv dst, TCGv src1, TCGv 
src2)
 
 // b2 = T0 & 1;
 // env->y = (b2 << 31) | (env->y >> 1);
-tcg_gen_andi_tl(r_temp, cpu_cc_src, 0x1);
-tcg_gen_shli_tl(r_temp, r_temp, 31);
 tcg_gen_extract_tl(t0, cpu_y, 1, 31);
-tcg_gen_or_tl(t0, t0, r_temp);
-tcg_gen_andi_tl(cpu_y, t0, 0x);
+tcg_gen_deposit_tl(cpu_y, cpu_y, cpu_cc_src, 31, 1);
 
 // b1 = N ^ V;
 gen_mov_reg_N(t0, cpu_psr);
-- 
2.9.4




[Qemu-devel] [PULL 07/14] target/arm: optimize aarch32 rev16

2017-07-18 Thread Richard Henderson
From: Aurelien Jarno 

Use the same mask to avoid having to load two different constants, as
suggested by Richard Henderson.

Signed-off-by: Aurelien Jarno 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20170516230159.4195-2-aurel...@aurel32.net>
Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index e27736c..d3003ae 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -343,11 +343,13 @@ static void gen_smul_dual(TCGv_i32 a, TCGv_i32 b)
 static void gen_rev16(TCGv_i32 var)
 {
 TCGv_i32 tmp = tcg_temp_new_i32();
+TCGv_i32 mask = tcg_const_i32(0x00ff00ff);
 tcg_gen_shri_i32(tmp, var, 8);
-tcg_gen_andi_i32(tmp, tmp, 0x00ff00ff);
+tcg_gen_and_i32(tmp, tmp, mask);
+tcg_gen_and_i32(var, var, mask);
 tcg_gen_shli_i32(var, var, 8);
-tcg_gen_andi_i32(var, var, 0xff00ff00);
 tcg_gen_or_i32(var, var, tmp);
+tcg_temp_free_i32(mask);
 tcg_temp_free_i32(tmp);
 }
 
-- 
2.9.4




[Qemu-devel] [PULL 03/14] tcg: Expand glue macros before stringifying helper names

2017-07-18 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 include/exec/helper-tcg.h | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/exec/helper-tcg.h b/include/exec/helper-tcg.h
index bb92877..b0c5baf 100644
--- a/include/exec/helper-tcg.h
+++ b/include/exec/helper-tcg.h
@@ -6,31 +6,35 @@
 
 #include "exec/helper-head.h"
 
+/* Need one more level of indirection before stringification
+   to get all the macros expanded first.  */
+#define str(s) #s
+
 #define DEF_HELPER_FLAGS_0(NAME, FLAGS, ret) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) },
 
 #define DEF_HELPER_FLAGS_1(NAME, FLAGS, ret, t1) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) | dh_sizemask(t1, 1) },
 
 #define DEF_HELPER_FLAGS_2(NAME, FLAGS, ret, t1, t2) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) | dh_sizemask(t1, 1) \
 | dh_sizemask(t2, 2) },
 
 #define DEF_HELPER_FLAGS_3(NAME, FLAGS, ret, t1, t2, t3) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) | dh_sizemask(t1, 1) \
 | dh_sizemask(t2, 2) | dh_sizemask(t3, 3) },
 
 #define DEF_HELPER_FLAGS_4(NAME, FLAGS, ret, t1, t2, t3, t4) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) | dh_sizemask(t1, 1) \
 | dh_sizemask(t2, 2) | dh_sizemask(t3, 3) | dh_sizemask(t4, 4) },
 
 #define DEF_HELPER_FLAGS_5(NAME, FLAGS, ret, t1, t2, t3, t4, t5) \
-  { .func = HELPER(NAME), .name = #NAME, .flags = FLAGS, \
+  { .func = HELPER(NAME), .name = str(NAME), .flags = FLAGS, \
 .sizemask = dh_sizemask(ret, 0) | dh_sizemask(t1, 1) \
 | dh_sizemask(t2, 2) | dh_sizemask(t3, 3) | dh_sizemask(t4, 4) \
 | dh_sizemask(t5, 5) },
@@ -39,6 +43,7 @@
 #include "trace/generated-helpers.h"
 #include "tcg-runtime.h"
 
+#undef str
 #undef DEF_HELPER_FLAGS_0
 #undef DEF_HELPER_FLAGS_1
 #undef DEF_HELPER_FLAGS_2
-- 
2.9.4




[Qemu-devel] [PULL 01/14] tcg/mips: reserve a register for the guest_base.

2017-07-18 Thread Richard Henderson
From: Jiang Biao 

Reserve a register for the guest_base using ppc code for reference.
By doing so, we do not have to recompute it for every memory load.

Signed-off-by: Jiang Biao 
Signed-off-by: Richard Henderson 
Message-Id: <1499677934-2249-1-git-send-email-jiang.bi...@zte.com.cn>
---
 tcg/mips/tcg-target.inc.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 85756b8..1a8169f 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -85,6 +85,10 @@ static const char * const 
tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
 #define TCG_TMP2  TCG_REG_T8
 #define TCG_TMP3  TCG_REG_T7
 
+#ifndef CONFIG_SOFTMMU
+#define TCG_GUEST_BASE_REG TCG_REG_S1
+#endif
+
 /* check if we really need so many registers :P */
 static const int tcg_target_reg_alloc_order[] = {
 /* Call saved registers.  */
@@ -1547,8 +1551,7 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
*args, bool is_64)
 } else if (guest_base == (int16_t)guest_base) {
 tcg_out_opc_imm(s, ALIAS_PADDI, base, addr_regl, guest_base);
 } else {
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, guest_base);
-tcg_out_opc_reg(s, ALIAS_PADD, base, TCG_TMP0, addr_regl);
+tcg_out_opc_reg(s, ALIAS_PADD, base, TCG_GUEST_BASE_REG, addr_regl);
 }
 tcg_out_qemu_ld_direct(s, data_regl, data_regh, base, opc, is_64);
 #endif
@@ -1652,8 +1655,7 @@ static void tcg_out_qemu_st(TCGContext *s, const TCGArg 
*args, bool is_64)
 } else if (guest_base == (int16_t)guest_base) {
 tcg_out_opc_imm(s, ALIAS_PADDI, base, addr_regl, guest_base);
 } else {
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, guest_base);
-tcg_out_opc_reg(s, ALIAS_PADD, base, TCG_TMP0, addr_regl);
+tcg_out_opc_reg(s, ALIAS_PADD, base, TCG_GUEST_BASE_REG, addr_regl);
 }
 tcg_out_qemu_st_direct(s, data_regl, data_regh, base, opc);
 #endif
@@ -2452,6 +2454,13 @@ static void tcg_target_qemu_prologue(TCGContext *s)
TCG_REG_SP, SAVE_OFS + i * REG_SIZE);
 }
 
+#ifndef CONFIG_SOFTMMU
+if (guest_base) {
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_GUEST_BASE_REG, guest_base);
+tcg_regset_set_reg(s->reserved_regs, TCG_GUEST_BASE_REG);
+}
+#endif
+
 /* Call generated code */
 tcg_out_opc_reg(s, OPC_JR, 0, tcg_target_call_iarg_regs[1], 0);
 /* delay slot */
-- 
2.9.4




[Qemu-devel] [PULL 12/14] target/alpha: optimize gen_cvtlq() using deposit op

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20170718045540.16322-10-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 232af9e..2bffbae 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -756,11 +756,9 @@ static void gen_cvtlq(TCGv vc, TCGv vb)
 
 /* The arithmetic right shift here, plus the sign-extended mask below
yields a sign-extended result without an explicit ext32s_i64.  */
-tcg_gen_sari_i64(tmp, vb, 32);
-tcg_gen_shri_i64(vc, vb, 29);
-tcg_gen_andi_i64(tmp, tmp, (int32_t)0xc000);
-tcg_gen_andi_i64(vc, vc, 0x3fff);
-tcg_gen_or_i64(vc, vc, tmp);
+tcg_gen_shri_i64(tmp, vb, 29);
+tcg_gen_sari_i64(vc, vb, 32);
+tcg_gen_deposit_i64(vc, vc, tmp, 0, 30);
 
 tcg_temp_free(tmp);
 }
-- 
2.9.4




[Qemu-devel] [PULL 05/14] coccinelle: add a script to optimize tcg op using tcg_gen_extract()

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

The following thread was helpful while writing this script:

https://github.com/coccinelle/coccinelle/issues/86

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20170718045540.16322-3-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 scripts/coccinelle/tcg_gen_extract.cocci | 107 +++
 1 file changed, 107 insertions(+)
 create mode 100644 scripts/coccinelle/tcg_gen_extract.cocci

diff --git a/scripts/coccinelle/tcg_gen_extract.cocci 
b/scripts/coccinelle/tcg_gen_extract.cocci
new file mode 100644
index 000..81e66a3
--- /dev/null
+++ b/scripts/coccinelle/tcg_gen_extract.cocci
@@ -0,0 +1,107 @@
+// optimize TCG using extract op
+//
+// Copyright: (C) 2017 Philippe Mathieu-Daudé. GPLv2+.
+// Confidence: High
+// Options: --macro-file scripts/cocci-macro-file.h
+//
+// Nikunj A Dadhania optimization:
+// http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg05211.html
+// Aurelien Jarno optimization:
+// http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg01466.html
+//
+// This script can be run either using spatch locally or via a docker image:
+//
+// $ spatch \
+// --macro-file scripts/cocci-macro-file.h \
+// --sp-file scripts/coccinelle/tcg_gen_extract.cocci \
+// --keep-comments --in-place \
+// --use-gitgrep --dir target
+//
+// $ docker run --rm -v `pwd`:`pwd` -w `pwd` philmd/coccinelle \
+// --macro-file scripts/cocci-macro-file.h \
+// --sp-file scripts/coccinelle/tcg_gen_extract.cocci \
+// --keep-comments --in-place \
+// --use-gitgrep --dir target
+
+@initialize:python@
+@@
+import sys
+fd = sys.stderr
+def debug(msg="", trailer="\n"):
+fd.write("[DBG] " + msg + trailer)
+def low_bits_count(value):
+bits_count = 0
+while (value & (1 << bits_count)):
+bits_count += 1
+return bits_count
+def Mn(order): # Mersenne number
+return (1 << order) - 1
+
+@match@
+identifier ret;
+metavariable arg;
+constant ofs, msk;
+position shr_p, and_p;
+@@
+(
+tcg_gen_shri_i32@shr_p
+|
+tcg_gen_shri_i64@shr_p
+|
+tcg_gen_shri_tl@shr_p
+)(ret, arg, ofs);
+...  WHEN != ret
+(
+tcg_gen_andi_i32@and_p
+|
+tcg_gen_andi_i64@and_p
+|
+tcg_gen_andi_tl@and_p
+)(ret, ret, msk);
+
+@script:python verify_len depends on match@
+ret_s << match.ret;
+msk_s << match.msk;
+shr_p << match.shr_p;
+extract_len;
+@@
+is_optimizable = False
+debug("candidate at %s:%s" % (shr_p[0].file, shr_p[0].line))
+try: # only eval integer, no #define like 'SR_M' (cpp did this, else some 
headers are missing).
+msk_v = long(msk_s.strip("UL"), 0)
+msk_b = low_bits_count(msk_v)
+if msk_b == 0:
+debug("  value: 0x%x low_bits: %d" % (msk_v, msk_b))
+else:
+debug("  value: 0x%x low_bits: %d [Mersenne number: 0x%x]" % (msk_v, 
msk_b, Mn(msk_b)))
+is_optimizable = Mn(msk_b) == msk_v # check low_bits
+coccinelle.extract_len = "%d" % msk_b
+debug("  candidate %s optimizable" % ("IS" if is_optimizable else "is 
NOT"))
+except:
+debug("  ERROR (check included headers?)")
+cocci.include_match(is_optimizable)
+debug()
+
+@replacement depends on verify_len@
+identifier match.ret;
+metavariable match.arg;
+constant match.ofs, match.msk;
+position match.shr_p, match.and_p;
+identifier verify_len.extract_len;
+@@
+(
+-tcg_gen_shri_i32@shr_p(ret, arg, ofs);
++tcg_gen_extract_i32(ret, arg, ofs, extract_len);
+...  WHEN != ret
+-tcg_gen_andi_i32@and_p(ret, ret, msk);
+|
+-tcg_gen_shri_i64@shr_p(ret, arg, ofs);
++tcg_gen_extract_i64(ret, arg, ofs, extract_len);
+...  WHEN != ret
+-tcg_gen_andi_i64@and_p(ret, ret, msk);
+|
+-tcg_gen_shri_tl@shr_p(ret, arg, ofs);
++tcg_gen_extract_tl(ret, arg, ofs, extract_len);
+...  WHEN != ret
+-tcg_gen_andi_tl@and_p(ret, ret, msk);
+)
-- 
2.9.4




[Qemu-devel] [PULL 06/14] target/arm: Optimize aarch64 rev16

2017-07-18 Thread Richard Henderson
It is much shorter to reverse all 4 half-words in parallel
than extract, reverse, and deposit each in turn.

Suggested-by: Aurelien Jarno 
Signed-off-by: Richard Henderson 
---
 target/arm/translate-a64.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 3fa3902..5bb0f8e 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -4043,25 +4043,13 @@ static void handle_rev16(DisasContext *s, unsigned int 
sf,
 TCGv_i64 tcg_rd = cpu_reg(s, rd);
 TCGv_i64 tcg_tmp = tcg_temp_new_i64();
 TCGv_i64 tcg_rn = read_cpu_reg(s, rn, sf);
+TCGv_i64 mask = tcg_const_i64(sf ? 0x00ff00ff00ff00ffull : 0x00ff00ff);
 
-tcg_gen_andi_i64(tcg_tmp, tcg_rn, 0x);
-tcg_gen_bswap16_i64(tcg_rd, tcg_tmp);
-
-tcg_gen_shri_i64(tcg_tmp, tcg_rn, 16);
-tcg_gen_andi_i64(tcg_tmp, tcg_tmp, 0x);
-tcg_gen_bswap16_i64(tcg_tmp, tcg_tmp);
-tcg_gen_deposit_i64(tcg_rd, tcg_rd, tcg_tmp, 16, 16);
-
-if (sf) {
-tcg_gen_shri_i64(tcg_tmp, tcg_rn, 32);
-tcg_gen_andi_i64(tcg_tmp, tcg_tmp, 0x);
-tcg_gen_bswap16_i64(tcg_tmp, tcg_tmp);
-tcg_gen_deposit_i64(tcg_rd, tcg_rd, tcg_tmp, 32, 16);
-
-tcg_gen_shri_i64(tcg_tmp, tcg_rn, 48);
-tcg_gen_bswap16_i64(tcg_tmp, tcg_tmp);
-tcg_gen_deposit_i64(tcg_rd, tcg_rd, tcg_tmp, 48, 16);
-}
+tcg_gen_shri_i64(tcg_tmp, tcg_rn, 8);
+tcg_gen_and_i64(tcg_rd, tcg_rn, mask);
+tcg_gen_and_i64(tcg_tmp, tcg_tmp, mask);
+tcg_gen_shli_i64(tcg_rd, tcg_rd, 8);
+tcg_gen_or_i64(tcg_rd, tcg_rd, tcg_tmp);
 
 tcg_temp_free_i64(tcg_tmp);
 }
-- 
2.9.4




[Qemu-devel] [PULL 09/14] target/ppc: optimize various functions using extract op

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

Done with the Coccinelle semantic patch
scripts/coccinelle/tcg_gen_extract.cocci.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Acked-by: David Gibson 
Message-Id: <20170718045540.16322-6-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 target/ppc/translate.c  | 21 +++--
 target/ppc/translate/vsx-impl.inc.c | 24 
 2 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index c0cd64d..de271af 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -873,8 +873,7 @@ static inline void gen_op_arith_add(DisasContext *ctx, TCGv 
ret, TCGv arg1,
 }
 tcg_gen_xor_tl(cpu_ca, t0, t1);/* bits changed w/ carry */
 tcg_temp_free(t1);
-tcg_gen_shri_tl(cpu_ca, cpu_ca, 32);   /* extract bit 32 */
-tcg_gen_andi_tl(cpu_ca, cpu_ca, 1);
+tcg_gen_extract_tl(cpu_ca, cpu_ca, 32, 1);
 if (is_isa300(ctx)) {
 tcg_gen_mov_tl(cpu_ca32, cpu_ca);
 }
@@ -1404,8 +1403,7 @@ static inline void gen_op_arith_subf(DisasContext *ctx, 
TCGv ret, TCGv arg1,
 tcg_temp_free(inv1);
 tcg_gen_xor_tl(cpu_ca, t0, t1); /* bits changes w/ carry */
 tcg_temp_free(t1);
-tcg_gen_shri_tl(cpu_ca, cpu_ca, 32);/* extract bit 32 */
-tcg_gen_andi_tl(cpu_ca, cpu_ca, 1);
+tcg_gen_extract_tl(cpu_ca, cpu_ca, 32, 1);
 if (is_isa300(ctx)) {
 tcg_gen_mov_tl(cpu_ca32, cpu_ca);
 }
@@ -4336,8 +4334,7 @@ static void gen_mfsrin(DisasContext *ctx)
 
 CHK_SV;
 t0 = tcg_temp_new();
-tcg_gen_shri_tl(t0, cpu_gpr[rB(ctx->opcode)], 28);
-tcg_gen_andi_tl(t0, t0, 0xF);
+tcg_gen_extract_tl(t0, cpu_gpr[rB(ctx->opcode)], 28, 4);
 gen_helper_load_sr(cpu_gpr[rD(ctx->opcode)], cpu_env, t0);
 tcg_temp_free(t0);
 #endif /* defined(CONFIG_USER_ONLY) */
@@ -4368,8 +4365,7 @@ static void gen_mtsrin(DisasContext *ctx)
 CHK_SV;
 
 t0 = tcg_temp_new();
-tcg_gen_shri_tl(t0, cpu_gpr[rB(ctx->opcode)], 28);
-tcg_gen_andi_tl(t0, t0, 0xF);
+tcg_gen_extract_tl(t0, cpu_gpr[rB(ctx->opcode)], 28, 4);
 gen_helper_store_sr(cpu_env, t0, cpu_gpr[rD(ctx->opcode)]);
 tcg_temp_free(t0);
 #endif /* defined(CONFIG_USER_ONLY) */
@@ -4403,8 +4399,7 @@ static void gen_mfsrin_64b(DisasContext *ctx)
 
 CHK_SV;
 t0 = tcg_temp_new();
-tcg_gen_shri_tl(t0, cpu_gpr[rB(ctx->opcode)], 28);
-tcg_gen_andi_tl(t0, t0, 0xF);
+tcg_gen_extract_tl(t0, cpu_gpr[rB(ctx->opcode)], 28, 4);
 gen_helper_load_sr(cpu_gpr[rD(ctx->opcode)], cpu_env, t0);
 tcg_temp_free(t0);
 #endif /* defined(CONFIG_USER_ONLY) */
@@ -4435,8 +4430,7 @@ static void gen_mtsrin_64b(DisasContext *ctx)
 
 CHK_SV;
 t0 = tcg_temp_new();
-tcg_gen_shri_tl(t0, cpu_gpr[rB(ctx->opcode)], 28);
-tcg_gen_andi_tl(t0, t0, 0xF);
+tcg_gen_extract_tl(t0, cpu_gpr[rB(ctx->opcode)], 28, 4);
 gen_helper_store_sr(cpu_env, t0, cpu_gpr[rS(ctx->opcode)]);
 tcg_temp_free(t0);
 #endif /* defined(CONFIG_USER_ONLY) */
@@ -5414,8 +5408,7 @@ static void gen_mfsri(DisasContext *ctx)
 CHK_SV;
 t0 = tcg_temp_new();
 gen_addr_reg_index(ctx, t0);
-tcg_gen_shri_tl(t0, t0, 28);
-tcg_gen_andi_tl(t0, t0, 0xF);
+tcg_gen_extract_tl(t0, t0, 28, 4);
 gen_helper_load_sr(cpu_gpr[rd], cpu_env, t0);
 tcg_temp_free(t0);
 if (ra != 0 && ra != rd)
diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 7f12908..85ed135 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1248,8 +1248,7 @@ static void gen_xsxexpdp(DisasContext *ctx)
 gen_exception(ctx, POWERPC_EXCP_VSXU);
 return;
 }
-tcg_gen_shri_i64(rt, cpu_vsrh(xB(ctx->opcode)), 52);
-tcg_gen_andi_i64(rt, rt, 0x7FF);
+tcg_gen_extract_i64(rt, cpu_vsrh(xB(ctx->opcode)), 52, 11);
 }
 
 static void gen_xsxexpqp(DisasContext *ctx)
@@ -1262,8 +1261,7 @@ static void gen_xsxexpqp(DisasContext *ctx)
 gen_exception(ctx, POWERPC_EXCP_VSXU);
 return;
 }
-tcg_gen_shri_i64(xth, xbh, 48);
-tcg_gen_andi_i64(xth, xth, 0x7FFF);
+tcg_gen_extract_i64(xth, xbh, 48, 15);
 tcg_gen_movi_i64(xtl, 0);
 }
 
@@ -1323,8 +1321,7 @@ static void gen_xsxsigdp(DisasContext *ctx)
 zr = tcg_const_i64(0);
 nan = tcg_const_i64(2047);
 
-tcg_gen_shri_i64(exp, cpu_vsrh(xB(ctx->opcode)), 52);
-tcg_gen_andi_i64(exp, exp, 0x7FF);
+tcg_gen_extract_i64(exp, cpu_vsrh(xB(ctx->opcode)), 52, 11);
 tcg_gen_movi_i64(t0, 0x0010);
 tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, zr, zr, t0);
 tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, nan, zr, t0);
@@ -1352,8 +1349,7 @@ static void gen_xsxsigqp(DisasContext *ctx)
 zr = tcg_const_i64(0);
 nan = tcg_const_i64(32767

[Qemu-devel] [PULL 00/14] tcg-next patch queue

2017-07-18 Thread Richard Henderson
This edition is a real mix:
  * Code gen improvement for mips64 host (Jiang)
  * Build fix for ppc-linux (Philippe)
  * Runtime fix for tci (Philippe)
  * Fix atomic helper names in debugging dumps (rth)

  * Cross-target tcg code gen improvements (Philippe)
This one had no obvious tree through which it should go,
so I went ahead and took them all.

  * Cherry-picked the first patch from Lluis' generic translate loop,
wherein the interface to gen_intermediate_code changes trivially.
It's the only patch from that series that touches all targets,
and I see little point carrying it around further.


r~


The following changes since commit 6887dc6700ccb7820d8a9d370f421ee361c748e8:

  Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170718' into 
staging (2017-07-18 21:13:48 +0100)

are available in the git repository at:

  git://github.com/rth7680/qemu.git tags/pull-tcg-20170718

for you to fetch changes up to 3d48caee9e2c18385be60bb0467fa1f61d325c64:

  tcg: Pass generic CPUState to gen_intermediate_code() (2017-07-18 14:26:13 
-1000)


Queued tcg and tcg code gen related cleanups


Aurelien Jarno (1):
  target/arm: optimize aarch32 rev16

Jiang Biao (1):
  tcg/mips: reserve a register for the guest_base.

Lluís Vilanova (1):
  tcg: Pass generic CPUState to gen_intermediate_code()

Philippe Mathieu-Daudé (9):
  util/cacheinfo: Add missing include for ppc linux
  coccinelle: ignore ASTs pre-parsed cached C files
  coccinelle: add a script to optimize tcg op using tcg_gen_extract()
  target/m68k: optimize bcd_flags() using extract op
  target/ppc: optimize various functions using extract op
  target/sparc: optimize various functions using extract op
  target/sparc: optimize gen_op_mulscc() using deposit op
  target/alpha: optimize gen_cvtlq() using deposit op
  tcg/tci: enable bswap16_i64

Richard Henderson (2):
  tcg: Expand glue macros before stringifying helper names
  target/arm: Optimize aarch64 rev16

 include/exec/exec-all.h  |   2 +-
 include/exec/helper-tcg.h|  17 +++--
 target/arm/translate.h   |   4 +-
 accel/tcg/translate-all.c|   2 +-
 target/alpha/translate.c |  13 ++--
 target/arm/translate-a64.c   |  30 +++--
 target/arm/translate.c   |  12 ++--
 target/cris/translate.c  |   7 +-
 target/hppa/translate.c  |   5 +-
 target/i386/translate.c  |   5 +-
 target/lm32/translate.c  |   4 +-
 target/m68k/translate.c  |   8 +--
 target/microblaze/translate.c|   4 +-
 target/mips/translate.c  |   5 +-
 target/moxie/translate.c |   4 +-
 target/nios2/translate.c |   5 +-
 target/openrisc/translate.c  |   4 +-
 target/ppc/translate.c   |  26 +++-
 target/ppc/translate/vsx-impl.inc.c  |  24 +++
 target/s390x/translate.c |   5 +-
 target/sh4/translate.c   |   5 +-
 target/sparc/translate.c |  25 +++-
 target/tilegx/translate.c|   5 +-
 target/tricore/translate.c   |   5 +-
 target/unicore32/translate.c |   5 +-
 target/xtensa/translate.c|   5 +-
 tcg/mips/tcg-target.inc.c|  17 +++--
 tcg/tci.c|   1 -
 util/cacheinfo.c |   1 +
 .gitignore   |   2 +
 scripts/coccinelle/tcg_gen_extract.cocci | 107 +++
 31 files changed, 218 insertions(+), 146 deletions(-)
 create mode 100644 scripts/coccinelle/tcg_gen_extract.cocci



[Qemu-devel] [PULL 04/14] coccinelle: ignore ASTs pre-parsed cached C files

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

files generated using coccinelle tool: 'spatch --use-cache'

Reviewed-by: Eric Blake 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20170718045540.16322-2-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 09c2363..cf65316 100644
--- a/.gitignore
+++ b/.gitignore
@@ -116,6 +116,8 @@ tags
 TAGS
 docker-src.*
 *~
+*.ast_raw
+*.depend_raw
 trace.h
 trace.c
 trace-ust.h
-- 
2.9.4




[Qemu-devel] [PULL 02/14] util/cacheinfo: Add missing include for ppc linux

2017-07-18 Thread Richard Henderson
From: Philippe Mathieu-Daudé 

This include was forgotten when splitting cacheinfo.c out of
tcg/ppc/tcg-target.inc.c (see commit b255b2c8).

For a Centos7 host, the include path


  

  


implicitly pulls in the desired AT_* defines.
Not so for Debian Jessie.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20170711015524.22936-1-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
 util/cacheinfo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/util/cacheinfo.c b/util/cacheinfo.c
index 6253049..593940f 100644
--- a/util/cacheinfo.c
+++ b/util/cacheinfo.c
@@ -129,6 +129,7 @@ static void arch_cache_info(int *isize, int *dsize)
 }
 
 #elif defined(_ARCH_PPC) && defined(__linux__)
+# include "elf.h"
 
 static void arch_cache_info(int *isize, int *dsize)
 {
-- 
2.9.4




Re: [Qemu-devel] [PATCH v2] hmp: allow cpu index for "info lapic"

2017-07-18 Thread wang.yi59
Hi Eduardo,

Thank you for your reply!

>On Mon, Jul 17, 2017 at 09:49:37PM -0400, Yi Wang wrote:

>> Add [vcpu] index support for hmp command "info lapic", which is

>> useful when debugging ipi and so on. Current behavior is not

>> changed when the parameter isn't specified.

>> 

>> Signed-off-by: Yi Wang 

>> Signed-off-by: Yun Liu 

>

>We have 8 monitor commands (see below) that use the CPU set by

>the "cpu" command (mon_get_cpu()) as input.  Why is "info lapic"

>special?

When we debugging a problem of ipi, we wanted to verify lapic info

on each vCPU, but we found that we could only get vCPU 0's lapic

through "info lapic", so we supposed this patch could help those

who have the same problem as us.




>

>* info cpustats

>* info lapic

>* info mem

>* info registers

>* info tlb

>* x

>* memsave

>* inject-nmi (QMP)

Monitor command "info registers" already have "-a" parameter to

show all vCPU's info. -)

May I send some new patches for the other monitor commands, which may

be helpful for analyzing multiple cpu problems?





---

Best wishes

Yi Wang

[Qemu-devel] [PULL 8/8] target/alpha: Log temp leaks

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index aaaf28f..90e6d52 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -3013,6 +3013,8 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 }
 
 gen_tb_start(tb);
+tcg_clear_temp_count();
+
 do {
 tcg_gen_insn_start(ctx.pc);
 num_insns++;
@@ -3035,6 +3037,10 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 ret = translate_one(ctxp, insn);
 free_context_temps(ctxp);
 
+if (tcg_check_temp_count()) {
+qemu_log("TCG temporary leak before "TARGET_FMT_lx"\n", ctx.pc);
+}
+
 /* If we reach a page boundary, are single stepping,
or exhaust instruction count, stop generation.  */
 if (ret == NO_EXIT
-- 
2.9.4




[Qemu-devel] [PULL 7/8] target/alpha: Fix temp leak in gen_fbcond

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 326af7f..aaaf28f 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -613,8 +613,12 @@ static ExitStatus gen_fbcond(DisasContext *ctx, TCGCond 
cond, int ra,
  int32_t disp)
 {
 TCGv cmp_tmp = tcg_temp_new();
+ExitStatus ret;
+
 gen_fold_mzero(cond, cmp_tmp, load_fpr(ctx, ra));
-return gen_bcond_internal(ctx, cond, cmp_tmp, disp);
+ret = gen_bcond_internal(ctx, cond, cmp_tmp, disp);
+tcg_temp_free(cmp_tmp);
+return ret;
 }
 
 static void gen_fcmov(DisasContext *ctx, TCGCond cond, int ra, int rb, int rc)
-- 
2.9.4




[Qemu-devel] [PULL 5/8] target/alpha: Fix temp leak in gen_mtpr

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index d684a7b..5e37b1a 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -1392,7 +1392,6 @@ static ExitStatus gen_mfpr(DisasContext *ctx, TCGv va, 
int regno)
 
 static ExitStatus gen_mtpr(DisasContext *ctx, TCGv vb, int regno)
 {
-TCGv tmp;
 int data;
 
 switch (regno) {
@@ -1408,9 +1407,12 @@ static ExitStatus gen_mtpr(DisasContext *ctx, TCGv vb, 
int regno)
 
 case 253:
 /* WAIT */
-tmp = tcg_const_i64(1);
-tcg_gen_st32_i64(tmp, cpu_env, -offsetof(AlphaCPU, env) +
-   offsetof(CPUState, halted));
+{
+TCGv_i32 tmp = tcg_const_i32(1);
+tcg_gen_st_i32(tmp, cpu_env, -offsetof(AlphaCPU, env) +
+ offsetof(CPUState, halted));
+tcg_temp_free_i32(tmp);
+}
 return gen_excp(ctx, EXCP_HALTED, 0);
 
 case 252:
-- 
2.9.4




[Qemu-devel] [PULL 3/8] target/alpha: Merge several flag bytes into ENV->FLAGS

2017-07-18 Thread Richard Henderson
The flags are arranged such that we can manipulate them either
a whole, or as individual bytes.  The computation within
cpu_get_tb_cpu_state is now reduced to a single load and mask.

Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/cpu.h   | 70 +
 hw/alpha/dp264.c |  1 -
 linux-user/main.c| 25 +++--
 target/alpha/cpu.c   |  7 ++--
 target/alpha/helper.c| 12 +++
 target/alpha/machine.c   | 10 ++
 target/alpha/translate.c | 91 +++-
 7 files changed, 117 insertions(+), 99 deletions(-)

diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index aa83417..e95be2b 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -242,13 +242,11 @@ struct CPUAlphaState {
 uint8_t fpcr_dyn_round;
 uint8_t fpcr_flush_to_zero;
 
-/* The Internal Processor Registers.  Some of these we assume always
-   exist for use in user-mode.  */
-uint8_t ps;
-uint8_t intr_flag;
-uint8_t pal_mode;
-uint8_t fen;
+/* Mask of PALmode, Processor State et al.  Most of this gets copied
+   into the TranslatorBlock flags and controls code generation.  */
+uint32_t flags;
 
+/* The high 32-bits of the processor cycle counter.  */
 uint32_t pcc_ofs;
 
 /* These pass data from the exception logic in the translator and
@@ -398,24 +396,37 @@ enum {
 };
 
 /* Processor status constants.  */
-enum {
-/* Low 3 bits are interrupt mask level.  */
-PS_INT_MASK = 7,
+/* Low 3 bits are interrupt mask level.  */
+#define PS_INT_MASK   7u
 
-/* Bits 4 and 5 are the mmu mode.  The VMS PALcode uses all 4 modes;
-   The Unix PALcode only uses bit 4.  */
-PS_USER_MODE = 8
-};
+/* Bits 4 and 5 are the mmu mode.  The VMS PALcode uses all 4 modes;
+   The Unix PALcode only uses bit 4.  */
+#define PS_USER_MODE  8u
+
+/* CPUAlphaState->flags constants.  These are layed out so that we
+   can set or reset the pieces individually by assigning to the byte,
+   or manipulated as a whole.  */
+
+#define ENV_FLAG_PAL_SHIFT0
+#define ENV_FLAG_PS_SHIFT 8
+#define ENV_FLAG_RX_SHIFT 16
+#define ENV_FLAG_FEN_SHIFT24
+
+#define ENV_FLAG_PAL_MODE (1u << ENV_FLAG_PAL_SHIFT)
+#define ENV_FLAG_PS_USER  (PS_USER_MODE << ENV_FLAG_PS_SHIFT)
+#define ENV_FLAG_RX_FLAG  (1u << ENV_FLAG_RX_SHIFT)
+#define ENV_FLAG_FEN  (1u << ENV_FLAG_FEN_SHIFT)
+
+#define ENV_FLAG_TB_MASK \
+(ENV_FLAG_PAL_MODE | ENV_FLAG_PS_USER | ENV_FLAG_FEN)
 
 static inline int cpu_mmu_index(CPUAlphaState *env, bool ifetch)
 {
-if (env->pal_mode) {
-return MMU_KERNEL_IDX;
-} else if (env->ps & PS_USER_MODE) {
-return MMU_USER_IDX;
-} else {
-return MMU_KERNEL_IDX;
+int ret = env->flags & ENV_FLAG_PS_USER ? MMU_USER_IDX : MMU_KERNEL_IDX;
+if (env->flags & ENV_FLAG_PAL_MODE) {
+ret = MMU_KERNEL_IDX;
 }
+return ret;
 }
 
 enum {
@@ -482,31 +493,12 @@ QEMU_NORETURN void alpha_cpu_unassigned_access(CPUState 
*cpu, hwaddr addr,
int unused, unsigned size);
 #endif
 
-/* Bits in TB->FLAGS that control how translation is processed.  */
-enum {
-TB_FLAGS_PAL_MODE = 1,
-TB_FLAGS_FEN = 2,
-TB_FLAGS_USER_MODE = 8,
-};
-
 static inline void cpu_get_tb_cpu_state(CPUAlphaState *env, target_ulong *pc,
 target_ulong *cs_base, uint32_t 
*pflags)
 {
-int flags = 0;
-
 *pc = env->pc;
 *cs_base = 0;
-
-if (env->pal_mode) {
-flags = TB_FLAGS_PAL_MODE;
-} else {
-flags = env->ps & PS_USER_MODE;
-}
-if (env->fen) {
-flags |= TB_FLAGS_FEN;
-}
-
-*pflags = flags;
+*pflags = env->flags & ENV_FLAG_TB_MASK;
 }
 
 #endif /* ALPHA_CPU_H */
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 85405da..3b307ad 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -123,7 +123,6 @@ static void clipper_init(MachineState *machine)
 
 /* Start all cpus at the PALcode RESET entry point.  */
 for (i = 0; i < smp_cpus; ++i) {
-cpus[i]->env.pal_mode = 1;
 cpus[i]->env.pc = palcode_entry;
 cpus[i]->env.palbr = palcode_entry;
 }
diff --git a/linux-user/main.c b/linux-user/main.c
index ad03c9e..2b38d39 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3037,16 +3037,13 @@ void cpu_loop(CPUAlphaState *env)
 abi_long sysret;
 
 while (1) {
+bool arch_interrupt = true;
+
 cpu_exec_start(cs);
 trapnr = cpu_exec(cs);
 cpu_exec_end(cs);
 process_queued_cpu_work(cs);
 
-/* All of the traps imply a transition through PALcode, which
-   implies an REI instruction has been executed.  Which means
-   that the intr_flag should be cleared.  */
-env->intr_flag = 0;
-
 switch (trapnr) {
 case EXCP_RESET:
 fprintf(stderr, "Reset requested.

[Qemu-devel] [PULL 2/8] target/alpha: Copy tb->flags into DisasContext

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 4a627fc..48be19a 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -49,6 +49,7 @@ struct DisasContext {
 #ifndef CONFIG_USER_ONLY
 uint64_t palbr;
 #endif
+uint32_t tbflags;
 int mem_idx;
 
 /* implver and amask values for this CPU.  */
@@ -452,7 +453,7 @@ static ExitStatus gen_store_conditional(DisasContext *ctx, 
int ra, int rb,
 static bool in_superpage(DisasContext *ctx, int64_t addr)
 {
 #ifndef CONFIG_USER_ONLY
-return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0
+return ((ctx->tbflags & TB_FLAGS_USER_MODE) == 0
 && addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1
 && ((addr >> 41) & 3) == 2);
 #else
@@ -1167,7 +1168,7 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int 
palcode)
 
 #ifndef CONFIG_USER_ONLY
 /* Privileged PAL code */
-if (palcode < 0x40 && (ctx->tb->flags & TB_FLAGS_USER_MODE) == 0) {
+if (palcode < 0x40 && (ctx->tbflags & TB_FLAGS_USER_MODE) == 0) {
 TCGv tmp;
 switch (palcode) {
 case 0x01:
@@ -1258,7 +1259,7 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int 
palcode)
 uint64_t exc_addr = ctx->pc;
 uint64_t entry = ctx->palbr;
 
-if (ctx->tb->flags & TB_FLAGS_PAL_MODE) {
+if (ctx->tbflags & TB_FLAGS_PAL_MODE) {
 exc_addr |= 1;
 } else {
 tcg_gen_movi_i64(tmp, 1);
@@ -1452,7 +1453,7 @@ static ExitStatus gen_mtpr(DisasContext *ctx, TCGv vb, 
int regno)
 
 #define REQUIRE_TB_FLAG(FLAG)   \
 do {\
-if ((ctx->tb->flags & (FLAG)) == 0) {   \
+if ((ctx->tbflags & (FLAG)) == 0) { \
 goto invalid_opc;   \
 }   \
 } while (0)
@@ -2932,6 +2933,7 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 
 ctx.tb = tb;
 ctx.pc = pc_start;
+ctx.tbflags = tb->flags;
 ctx.mem_idx = cpu_mmu_index(env, false);
 ctx.implver = env->implver;
 ctx.amask = env->amask;
@@ -2941,7 +2943,7 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 ctx.ir = cpu_std_ir;
 #else
 ctx.palbr = env->palbr;
-ctx.ir = (tb->flags & TB_FLAGS_PAL_MODE ? cpu_pal_ir : cpu_std_ir);
+ctx.ir = (ctx.tbflags & TB_FLAGS_PAL_MODE ? cpu_pal_ir : cpu_std_ir);
 #endif
 
 /* ??? Every TB begins with unset rounding mode, to be initialized on
-- 
2.9.4




[Qemu-devel] [PULL 6/8] target/alpha: Fix temp leak in gen_call_pal

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 5e37b1a..326af7f 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -1189,7 +1189,6 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int 
palcode)
 #ifndef CONFIG_USER_ONLY
 /* Privileged PAL code */
 if (palcode < 0x40 && (ctx->tbflags & ENV_FLAG_PS_USER) == 0) {
-TCGv tmp;
 switch (palcode) {
 case 0x01:
 /* CFLUSH */
@@ -1222,10 +1221,12 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int 
palcode)
 ld_flag_byte(ctx->ir[IR_V0], ENV_FLAG_PS_SHIFT);
 
 /* But make sure and store only the 3 IPL bits from the user.  */
-tmp = tcg_temp_new();
-tcg_gen_andi_i64(tmp, ctx->ir[IR_A0], PS_INT_MASK);
-st_flag_byte(tmp, ENV_FLAG_PS_SHIFT);
-tcg_temp_free(tmp);
+{
+TCGv tmp = tcg_temp_new();
+tcg_gen_andi_i64(tmp, ctx->ir[IR_A0], PS_INT_MASK);
+st_flag_byte(tmp, ENV_FLAG_PS_SHIFT);
+tcg_temp_free(tmp);
+}
 
 /* Allow interrupts to be recognized right away.  */
 tcg_gen_movi_i64(cpu_pc, ctx->pc);
@@ -1254,9 +1255,12 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int 
palcode)
 
 case 0x3E:
 /* WTINT */
-tmp = tcg_const_i64(1);
-tcg_gen_st32_i64(tmp, cpu_env, -offsetof(AlphaCPU, env) +
-   offsetof(CPUState, halted));
+{
+TCGv_i32 tmp = tcg_const_i32(1);
+tcg_gen_st_i32(tmp, cpu_env, -offsetof(AlphaCPU, env) +
+ offsetof(CPUState, halted));
+tcg_temp_free_i32(tmp);
+}
 tcg_gen_movi_i64(ctx->ir[IR_V0], 0);
 return gen_excp(ctx, EXCP_HALTED, 0);
 
-- 
2.9.4




[Qemu-devel] [PULL 0/8] target/alpha cleanups

2017-07-18 Thread Richard Henderson
The new title holder for perf top is helper_lookup_tb_ptr.
Those targets that have a complicated cpu_get_tb_cpu_state
function are going to regret that.

This cleans up the Alpha version of that function such that it is
just two loads and one mask.  Which is one practically-free mask
away from being as minimal as one can get.

Also, in anticipation of LLuis' generic translation loop, fix all
of the temporary leaks.  They all seem to have been on insns that
end the TB, so in practice they weren't harmful, but...


r~


The following changes since commit 6887dc6700ccb7820d8a9d370f421ee361c748e8:

  Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170718' into 
staging (2017-07-18 21:13:48 +0100)

are available in the git repository at:

  git://github.com/rth7680/qemu.git tags/pull-axp-20170718

for you to fetch changes up to 8aa5c65fd3d4612d8ab690bef0980d26f30f381d:

  target/alpha: Log temp leaks (2017-07-18 18:42:05 -1000)


Queued target/alpha patches


Richard Henderson (8):
  target/alpha: Remove amask from tb->flags
  target/alpha: Copy tb->flags into DisasContext
  target/alpha: Merge several flag bytes into ENV->FLAGS
  target/alpha: Fix temp leak in gen_bcond
  target/alpha: Fix temp leak in gen_mtpr
  target/alpha: Fix temp leak in gen_call_pal
  target/alpha: Fix temp leak in gen_fbcond
  target/alpha: Log temp leaks

 target/alpha/cpu.h   |  79 +++--
 hw/alpha/dp264.c |   1 -
 linux-user/main.c|  25 +++---
 target/alpha/cpu.c   |   7 +-
 target/alpha/helper.c|  12 +--
 target/alpha/machine.c   |  10 +--
 target/alpha/translate.c | 221 +--
 7 files changed, 194 insertions(+), 161 deletions(-)



[Qemu-devel] [PULL 4/8] target/alpha: Fix temp leak in gen_bcond

2017-07-18 Thread Richard Henderson
Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 140d6f3..d684a7b 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -565,16 +565,16 @@ static ExitStatus gen_bcond_internal(DisasContext *ctx, 
TCGCond cond,
 static ExitStatus gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
 int32_t disp, int mask)
 {
-TCGv cmp_tmp;
-
 if (mask) {
-cmp_tmp = tcg_temp_new();
-tcg_gen_andi_i64(cmp_tmp, load_gpr(ctx, ra), 1);
-} else {
-cmp_tmp = load_gpr(ctx, ra);
-}
+TCGv tmp = tcg_temp_new();
+ExitStatus ret;
 
-return gen_bcond_internal(ctx, cond, cmp_tmp, disp);
+tcg_gen_andi_i64(tmp, load_gpr(ctx, ra), 1);
+ret = gen_bcond_internal(ctx, cond, tmp, disp);
+tcg_temp_free(tmp);
+return ret;
+}
+return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra), disp);
 }
 
 /* Fold -0.0 for comparison with COND.  */
-- 
2.9.4




[Qemu-devel] [PULL 1/8] target/alpha: Remove amask from tb->flags

2017-07-18 Thread Richard Henderson
This value is constant for the cpu and does not need
to be stored within the TB.

Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/alpha/cpu.h   |  9 ---
 target/alpha/translate.c | 70 ++--
 2 files changed, 38 insertions(+), 41 deletions(-)

diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index 691ac00..aa83417 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -487,14 +487,6 @@ enum {
 TB_FLAGS_PAL_MODE = 1,
 TB_FLAGS_FEN = 2,
 TB_FLAGS_USER_MODE = 8,
-
-TB_FLAGS_AMASK_SHIFT = 4,
-TB_FLAGS_AMASK_BWX = AMASK_BWX << TB_FLAGS_AMASK_SHIFT,
-TB_FLAGS_AMASK_FIX = AMASK_FIX << TB_FLAGS_AMASK_SHIFT,
-TB_FLAGS_AMASK_CIX = AMASK_CIX << TB_FLAGS_AMASK_SHIFT,
-TB_FLAGS_AMASK_MVI = AMASK_MVI << TB_FLAGS_AMASK_SHIFT,
-TB_FLAGS_AMASK_TRAP = AMASK_TRAP << TB_FLAGS_AMASK_SHIFT,
-TB_FLAGS_AMASK_PREFETCH = AMASK_PREFETCH << TB_FLAGS_AMASK_SHIFT,
 };
 
 static inline void cpu_get_tb_cpu_state(CPUAlphaState *env, target_ulong *pc,
@@ -513,7 +505,6 @@ static inline void cpu_get_tb_cpu_state(CPUAlphaState *env, 
target_ulong *pc,
 if (env->fen) {
 flags |= TB_FLAGS_FEN;
 }
-flags |= env->amask << TB_FLAGS_AMASK_SHIFT;
 
 *pflags = flags;
 }
diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 232af9e..4a627fc 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -51,14 +51,15 @@ struct DisasContext {
 #endif
 int mem_idx;
 
+/* implver and amask values for this CPU.  */
+int implver;
+int amask;
+
 /* Current rounding mode for this TB.  */
 int tb_rm;
 /* Current flush-to-zero setting for this TB.  */
 int tb_ftz;
 
-/* implver value for this CPU.  */
-int implver;
-
 /* The set of registers active in the current context.  */
 TCGv *ir;
 
@@ -1442,6 +1443,13 @@ static ExitStatus gen_mtpr(DisasContext *ctx, TCGv vb, 
int regno)
 }   \
 } while (0)
 
+#define REQUIRE_AMASK(FLAG) \
+do {\
+if ((ctx->amask & AMASK_##FLAG) == 0) { \
+goto invalid_opc;   \
+}   \
+} while (0)
+
 #define REQUIRE_TB_FLAG(FLAG)   \
 do {\
 if ((ctx->tb->flags & (FLAG)) == 0) {   \
@@ -1532,7 +1540,7 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 
 case 0x0A:
 /* LDBU */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_BWX);
+REQUIRE_AMASK(BWX);
 gen_load_mem(ctx, &tcg_gen_qemu_ld8u, ra, rb, disp16, 0, 0);
 break;
 case 0x0B:
@@ -1541,17 +1549,17 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 break;
 case 0x0C:
 /* LDWU */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_BWX);
+REQUIRE_AMASK(BWX);
 gen_load_mem(ctx, &tcg_gen_qemu_ld16u, ra, rb, disp16, 0, 0);
 break;
 case 0x0D:
 /* STW */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_BWX);
+REQUIRE_AMASK(BWX);
 gen_store_mem(ctx, &tcg_gen_qemu_st16, ra, rb, disp16, 0, 0);
 break;
 case 0x0E:
 /* STB */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_BWX);
+REQUIRE_AMASK(BWX);
 gen_store_mem(ctx, &tcg_gen_qemu_st8, ra, rb, disp16, 0, 0);
 break;
 case 0x0F:
@@ -1832,10 +1840,7 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 case 0x61:
 /* AMASK */
 REQUIRE_REG_31(ra);
-{
-uint64_t amask = ctx->tb->flags >> TB_FLAGS_AMASK_SHIFT;
-tcg_gen_andi_i64(vc, vb, ~amask);
-}
+tcg_gen_andi_i64(vc, vb, ~ctx->amask);
 break;
 case 0x64:
 /* CMOVLE */
@@ -2048,7 +2053,7 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 break;
 
 case 0x14:
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_FIX);
+REQUIRE_AMASK(FIX);
 vc = dest_fpr(ctx, rc);
 switch (fpfn) { /* fn11 & 0x3F */
 case 0x04:
@@ -2525,14 +2530,14 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 vc = dest_gpr(ctx, rc);
 if (fn7 == 0x70) {
 /* FTOIT */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_FIX);
+REQUIRE_AMASK(FIX);
 REQUIRE_REG_31(rb);
 va = load_fpr(ctx, ra);
 tcg_gen_mov_i64(vc, va);
 break;
 } else if (fn7 == 0x78) {
 /* FTOIS */
-REQUIRE_TB_FLAG(TB_FLAGS_AMASK_FIX);
+REQUIRE_AMASK(FIX);
 REQUIRE_REG_31(rb);
 t32 = tcg_temp_new_i32();
 va = load_fpr(ctx, ra);
@@ -2546,117 +2551,117 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 switch (fn7) {
 case 0x00

[Qemu-devel] [PATCH for-2.10] util: Introduce include/qemu/cpuid.h

2017-07-18 Thread Richard Henderson
Clang 3.9 passes the CONFIG_AVX2_OPT configure test.  However, the
supplied  does not contain the bit_AVX2 define that we use
when detecting whether the routine can be enabled.

Introduce a qemu-specific header that uses the compiler's definition
of __cpuid et al, but supplies any missing bit_* definitions needed.
This avoids introducing any extra ifdefs to util/bufferiszero.c, and
allows quite a few to be removed from tcg/i386/tcg-target.inc.c.

Signed-off-by: Richard Henderson 
---

Peter, this is the clang 3.9 problem I mentioned the other day,
when attempting to reproduce the other clang 3.8 problem.


r~

---
 include/qemu/cpuid.h  | 57 +++
 tcg/i386/tcg-target.inc.c | 36 +++---
 util/bufferiszero.c   |  7 +++---
 configure | 43 +++
 4 files changed, 92 insertions(+), 51 deletions(-)
 create mode 100644 include/qemu/cpuid.h

diff --git a/include/qemu/cpuid.h b/include/qemu/cpuid.h
new file mode 100644
index 000..6930170
--- /dev/null
+++ b/include/qemu/cpuid.h
@@ -0,0 +1,57 @@
+/* cpuid.h: Macros to identify the properties of an x86 host.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef QEMU_CPUID_H
+#define QEMU_CPUID_H
+
+#ifndef CONFIG_CPUID_H
+# error " is unusable with this compiler"
+#endif
+
+#include 
+
+/* Cover the uses that we have within qemu.  */
+/* ??? Irritating that we have the same information in target/i386/.  */
+
+/* Leaf 1, %edx */
+#ifndef bit_CMOV
+#define bit_CMOV(1 << 15)
+#endif
+#ifndef bit_SSE2
+#define bit_SSE2(1 << 26)
+#endif
+
+/* Leaf 1, %ecx */
+#ifndef bit_SSE4_1
+#define bit_SSE4_1  (1 << 19)
+#endif
+#ifndef bit_MOVBE
+#define bit_MOVBE   (1 << 22)
+#endif
+#ifndef bit_OSXSAVE
+#define bit_OSXSAVE (1 << 27)
+#endif
+#ifndef bit_AVX
+#define bit_AVX (1 << 28)
+#endif
+
+/* Leaf 7, %ebx */
+#ifndef bit_BMI
+#define bit_BMI (1 << 3)
+#endif
+#ifndef bit_AVX2
+#define bit_AVX2(1 << 5)
+#endif
+#ifndef bit_BMI2
+#define bit_BMI2(1 << 8)
+#endif
+
+/* Leaf 0x8001, %ecx */
+#ifndef bit_LZCNT
+#define bit_LZCNT   (1 << 5)
+#endif
+
+#endif /* QEMU_CPUID_H */
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index 01e3b4e..e4b120a 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -109,40 +109,30 @@ static const int tcg_target_call_oarg_regs[] = {
detection, as we're not going to go so far as our own inline assembly.
If not available, default values will be assumed.  */
 #if defined(CONFIG_CPUID_H)
-#include 
+#include "qemu/cpuid.h"
 #endif
 
-/* For 32-bit, we are going to attempt to determine at runtime whether cmov
-   is available.  */
+/* For 64-bit, we always know that CMOV is available.  */
 #if TCG_TARGET_REG_BITS == 64
 # define have_cmov 1
-#elif defined(CONFIG_CPUID_H) && defined(bit_CMOV)
+#elif defined(CONFIG_CPUID_H)
 static bool have_cmov;
 #else
 # define have_cmov 0
 #endif
 
-/* If bit_MOVBE is defined in cpuid.h (added in GCC version 4.6), we are
-   going to attempt to determine at runtime whether movbe is available.  */
-#if defined(CONFIG_CPUID_H) && defined(bit_MOVBE)
-static bool have_movbe;
-#else
-# define have_movbe 0
-#endif
-
 /* We need these symbols in tcg-target.h, and we can't properly conditionalize
it there.  Therefore we always define the variable.  */
 bool have_bmi1;
 bool have_popcnt;
 
-#if defined(CONFIG_CPUID_H) && defined(bit_BMI2)
+#ifdef CONFIG_CPUID_H
+static bool have_movbe;
 static bool have_bmi2;
-#else
-# define have_bmi2 0
-#endif
-#if defined(CONFIG_CPUID_H) && defined(bit_LZCNT)
 static bool have_lzcnt;
 #else
+# define have_movbe 0
+# define have_bmi2 0
 # define have_lzcnt 0
 #endif
 
@@ -2619,36 +2609,26 @@ static void tcg_target_init(TCGContext *s)
available, we'll use a small forward branch.  */
 have_cmov = (d & bit_CMOV) != 0;
 #endif
-#ifndef have_movbe
 /* MOVBE is only available on Intel Atom and Haswell CPUs, so we
need to probe for it.  */
 have_movbe = (c & bit_MOVBE) != 0;
-#endif
-#ifdef bit_POPCNT
 have_popcnt = (c & bit_POPCNT) != 0;
-#endif
 }
 
 if (max >= 7) {
 /* BMI1 is available on AMD Piledriver and Intel Haswell CPUs.  */
 __cpuid_count(7, 0, a, b, c, d);
-#ifdef bit_BMI
 have_bmi1 = (b & bit_BMI) != 0;
-#endif
-#ifndef have_bmi2
 have_bmi2 = (b & bit_BMI2) != 0;
-#endif
 }
-#endif
 
-#ifndef have_lzcnt
 max = __get_cpuid_max(0x800, 0);
 if (max >= 1) {
 __cpuid(0x8001, a, b, c, d);
 /* LZCNT was introduced with AMD Barcelona and Intel Haswell CPUs.  */
 have_lzcnt = (c & bit_LZCNT) != 0;
 }
-#endif
+#endif /* CONFIG_CPUID_H */
 
 if (TCG_TARGET_REG_BITS == 64) {
 tcg_regset_set32(tcg_target_availab

Re: [Qemu-devel] [PATCH] spapr: make default PHB optionnal

2017-07-18 Thread David Gibson
On Tue, Jul 04, 2017 at 10:47:22AM +0200, Greg Kurz wrote:
> On Tue, 4 Jul 2017 17:29:01 +1000
> David Gibson  wrote:
> 
> > On Mon, Jul 03, 2017 at 06:48:25PM +0200, Greg Kurz wrote:
> > > The sPAPR machine always create a default PHB during initialization, even
> > > if -nodefaults was passed on the command line. This forces the user to
> > > rely on -global if she wants to set properties of the default PHB, such
> > > as numa_node.
> > > 
> > > This patch introduces a new machine create-default-phb property to control
> > > whether the default PHB must be created or not. It defaults to on in order
> > > to preserve old setups (which is also the motivation to not alter the
> > > current behavior of -nodefaults).
> > > 
> > > If create-default-phb is set to off, the default PHB isn't created, nor
> > > any other device usually created with it. It is mandatory to provide
> > > a PHB on the command line to be able to use PCI devices (otherwise QEMU
> > > won't start). For example, the following creates a PHB with the same
> > > mappings as the default PHB and also sets the NUMA affinity:
> > > 
> > > -machine type=pseries,create-default-phb=off \
> > > -numa node,nodeid=0 -device spapr-pci-host-bridge,index=0,numa_node=0
> > > 
> > > Signed-off-by: Greg Kurz   
> > 
> > So, I agree that the distinction between default devices that are
> > disabled with -nodefaults and default devices that aren't is a big
> > mess in qemu configuration.  But on the other hand this only addresses
> > one tiny aspect of that, and in the meantime means we will silently
> > ignore some other configuration options in some conditions.
> > 
> > So, what's the immediate benefit / use case for this?
> > 
> 
> With the current code base, the only way to set properties of the default
> PHB, is to pass -global spapr-pci-host-bridge.prop=value for each property.
> The immediate benefit of this patch is to unify the way libvirt passes
> PHB description to the command line:

I thought you could use -set to set things more explicitly.  But I'll
admit, I can never remember how the syntax of that works.
> 
> ie, do:
> 
> -machine type=pseries,create-default-phb=off \
> -device spapr-pci-host-bridge,prop1=a,prop2=b,prop3=c \
> -device spapr-pci-host-bridge,prop1=d,prop2=e,prop3=f
> 
> instead of:
> 
> -machine type=pseries \
> -global spapr-pci-host-bridge.prop1=a \
> -global spapr-pci-host-bridge.prop2=b \
> -global spapr-pci-host-bridge.prop3=c \
> -device spapr-pci-host-bridge,prop1=d,prop2=e,prop3=f
> 
> > > ---
> > >  hw/ppc/spapr.c |   63 
> > > ++--
> > >  include/hw/ppc/spapr.h |2 ++
> > >  2 files changed, 47 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index ba8f57a5a054..3395bb3774b9 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -2103,7 +2103,7 @@ static void ppc_spapr_init(MachineState *machine)
> > >  sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
> > >  const char *kernel_filename = machine->kernel_filename;
> > >  const char *initrd_filename = machine->initrd_filename;
> > > -PCIHostState *phb;
> > > +PCIHostState *phb = NULL;
> > >  int i;
> > >  MemoryRegion *sysmem = get_system_memory();
> > >  MemoryRegion *ram = g_new(MemoryRegion, 1);
> > > @@ -2294,7 +2294,9 @@ static void ppc_spapr_init(MachineState *machine)
> > >  /* Set up PCI */
> > >  spapr_pci_rtas_init();
> > >  
> > > -phb = spapr_create_phb(spapr, 0);
> > > +if (spapr->create_default_phb) {
> > > +phb = spapr_create_phb(spapr, 0);
> > > +}
> > >  
> > >  for (i = 0; i < nb_nics; i++) {
> > >  NICInfo *nd = &nd_table[i];
> > > @@ -2305,7 +2307,7 @@ static void ppc_spapr_init(MachineState *machine)
> > >  
> > >  if (strcmp(nd->model, "ibmveth") == 0) {
> > >  spapr_vlan_create(spapr->vio_bus, nd);
> > > -} else {
> > > +} else if (phb) {
> > >  pci_nic_init_nofail(&nd_table[i], phb->bus, nd->model, NULL);
> > >  }
> > >  }
> > > @@ -2314,24 +2316,26 @@ static void ppc_spapr_init(MachineState *machine)
> > >  spapr_vscsi_create(spapr->vio_bus);
> > >  }
> > >  
> > > -/* Graphics */
> > > -if (spapr_vga_init(phb->bus, &error_fatal)) {
> > > -spapr->has_graphics = true;
> > > -machine->usb |= defaults_enabled() && !machine->usb_disabled;
> > > -}
> > > -
> > > -if (machine->usb) {
> > > -if (smc->use_ohci_by_default) {
> > > -pci_create_simple(phb->bus, -1, "pci-ohci");
> > > -} else {
> > > -pci_create_simple(phb->bus, -1, "nec-usb-xhci");
> > > +if (phb) {
> > > +/* Graphics */
> > > +if (spapr_vga_init(phb->bus, &error_fatal)) {
> > > +spapr->has_graphics = true;
> > > +machine->usb |= defaults_enabled() && !machine->usb_disable

[Qemu-devel] [Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

Status in QEMU:
  Expired

Bug description:
  ARMv7a has lot of undefined instruction from its instruction opcode
  space. This undefined instructions are very useful for replacing
  sensitive non-priviledged instructions of guest operating systems
  (virtualization). The undefined instruction exception executes at
   + 0x4, where  can be 0x0 or
  0xfff0. Currently, in qemu 0.14.0 undefined instruction fault at
  0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0,
  seems like this is a new bug. As as example, if we try to execute
  value "0xec019800" in qemu 0.14.0 then it should cause undefined
  exception at +0x4 since "0xec019800" is an undefined
  instruction.

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



Re: [Qemu-devel] [PATCH] spapr: make default PHB optionnal

2017-07-18 Thread David Gibson
On Wed, Jul 12, 2017 at 05:09:37PM +0530, Shivaprasad G Bhat wrote:
> 
> 
> On 07/12/2017 04:25 PM, Andrea Bolognani wrote:
> > [libvir-list added to the loop]
> > 
> > On Tue, 2017-07-04 at 10:47 +0200, Greg Kurz wrote:
> > > On Tue, 4 Jul 2017 17:29:01 +1000 David Gibson 
> > >  wrote:
> > > > On Mon, Jul 03, 2017 at 06:48:25PM +0200, Greg Kurz wrote:
> > > > > The sPAPR machine always create a default PHB during initialization, 
> > > > > even
> > > > > if -nodefaults was passed on the command line. This forces the user to
> > > > > rely on -global if she wants to set properties of the default PHB, 
> > > > > such
> > > > > as numa_node.
> > > > > This patch introduces a new machine create-default-phb property to 
> > > > > control
> > > > > whether the default PHB must be created or not. It defaults to on in 
> > > > > order
> > > > > to preserve old setups (which is also the motivation to not alter the
> > > > > current behavior of -nodefaults).
> > > > > If create-default-phb is set to off, the default PHB isn't created, 
> > > > > nor
> > > > > any other device usually created with it. It is mandatory to provide
> > > > > a PHB on the command line to be able to use PCI devices (otherwise 
> > > > > QEMU
> > > > > won't start). For example, the following creates a PHB with the same
> > > > > mappings as the default PHB and also sets the NUMA affinity:
> > > > >   -machine type=pseries,create-default-phb=off \
> > > > >   -numa node,nodeid=0 -device 
> > > > > spapr-pci-host-bridge,index=0,numa_node=0
> > > > So, I agree that the distinction between default devices that are
> > > > disabled with -nodefaults and default devices that aren't is a big
> > > > mess in qemu configuration.  But on the other hand this only addresses
> > > > one tiny aspect of that, and in the meantime means we will silently
> > > > ignore some other configuration options in some conditions.
> > > > So, what's the immediate benefit / use case for this?
> 
> Setting numa_node for emulated devices is the benefit for now. On x86, I
> figured there is
> no way to set the numa_node for the root controller and the emulated devices
> sitting there
> all have numa_node set to -1. Only the devices on the pxb can have a
> sensible value specified.

Given that we have the equivalent restriction on x86, I'm not seeing
removing it on Power as a priority.

> Does it mean, the emulated devices/drivers don't care about the numa_node
> they are on?

Probably not.  If nothing else, I expect the slowdown of bad NUMA
affinity is probably not significant compared to the general slowness
of an emulated device. Since the device is also in software, the
standard NUMA stuff on the host may already migrate the relevant
things to match the (host) NUMA node where the guest code is running,
so it may be strictly irrelevant in that sense as well.

> Would it be fine on PPC to disallow setting the NUMA node for the default
> PHB because that is where
> all the emulated devices sit ?
> 
> > > With the current code base, the only way to set properties of the default
> > > PHB, is to pass -global spapr-pci-host-bridge.prop=value for each 
> > > property.
> > > The immediate benefit of this patch is to unify the way libvirt passes
> > > PHB description to the command line:
> > > ie, do:
> > >   -machine type=pseries,create-default-phb=off \
> > >   -device spapr-pci-host-bridge,prop1=a,prop2=b,prop3=c \
> > >   -device spapr-pci-host-bridge,prop1=d,prop2=e,prop3=f
> > > instead of:
> > >   -machine type=pseries \
> > >   -global spapr-pci-host-bridge.prop1=a \
> > >   -global spapr-pci-host-bridge.prop2=b \
> > >   -global spapr-pci-host-bridge.prop3=c \
> > >   -device spapr-pci-host-bridge,prop1=d,prop2=e,prop3=f
> > So, I'm thinking about this mostly in terms of NUMA nodes
> > because that's the use case I'm aware of.
> > 
> > The problem with using -global is not that it requires using
> > a different syntax to set properties for the default PHB,
> > but rather that such properties are then inherited by all
> > other PHBs unless explicitly overridden. Not creating the
> > default PHB at all would solve the issue.
> > 
> > On the other hand, libvirt would then need to either
> > 
> >1) only allow setting NUMA nodes for PHBs if QEMU supports
> >   the new option, leaving QEMU < 2.10 users behind; or
> > 
> >2) implement handling for both the new and old behavior.
> > 
> > I'm not sure we could get away with 1), and going for 2)
> > means more work both for QEMU and libvirt developers for
> > very little actual gain, so I'd be inclined to scrap this
> > and just build the libvirt glue on top of the existing
> > interface.
> > 
> > That is, of course, unless
> > 
> >1) having a random selection of PHBs not assigned to any
> >   NUMA node is a sensible use case. This is something
> >   we just can't do reliably with the current interface:
> >   we can decide to set the NUMA node only for say, PH

[Qemu-devel] [Bug 796202] Re: Doing a 64 bit load from a 32 bit local APIC register is allowed

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Doing a 64 bit load from a 32 bit local APIC register is allowed

Status in QEMU:
  Expired

Bug description:
  Doing

  u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;

  and later in an interrupt handler

  movq (lapic_idregister), %rcx
  movq (%rcx), %rcx

  in a linux kernel module works in qemu 0.13.91 but not on real hardware (it 
simply reboots).
  On real hardware only

  movl (%rcx), %ecx

  works (also in qemu).

  Commandline:
  qemu-system-x86_64 \
-kernel $LINUXDIR/arch/x86_64/boot/bzImage \
-hda $BUILDROOTDIR/output/images/rootfs.ext2 \
-append "root=/dev/sda rw rootfstype=ext2 maxcpus=4" \
-cpu phenom \
-smp 4 \
-gdb tcp::1234 \
-net nic -net user

  Guest:
  Vanilla Linux Kernel 2.6.37.6 64-bit with buildroot

  Mikael Pettersson from the linux kernel mailinglist told me it's an
  accepts-invalid bug in qemu.

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



[Qemu-devel] [Bug 959992] Re: segfault in apic_report_irq_delivered when booting tinycore_3.3.iso

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  segfault in apic_report_irq_delivered when booting tinycore_3.3.iso

Status in QEMU:
  Expired

Bug description:
  it git head (33cf629) sometimes it segfaults in
  apic_report_irq_delivered() and backtrace is looping in
  apic_update_irq(#3-#4)

  Log:
  C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L 
..\pc-bios -cdrom tinycore_3.3.iso
  GNU gdb (GDB) 7.3
  Copyright (C) 2011 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "mingw32".
  For bug reporting instructions, please see:
  ...
  Reading symbols from 
C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
  done.
  (gdb) r
  Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L 
..\\pc-bios -cdrom tinycore_3.3.iso
  [New Thread 9012.0x2348]
  [New Thread 9012.0x2860]
  [New Thread 9012.0x2b64]

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 9012.0x2b64]
  0x0053cde8 in apic_report_irq_delivered (delivered=0)
  at C:/msys/home/User/qemu/hw/apic_common.c:110
  110 {
  (gdb) bt
  #0  0x0053cde8 in apic_report_irq_delivered (delivered=0)
  at C:/msys/home/User/qemu/hw/apic_common.c:110
  #1  0x0053b9eb in apic_set_irq (s=0x1d7aff8, vector_num=,
  trigger_mode=0) at C:/msys/home/User/qemu/hw/apic.c:390
  #2  0x0053b990 in apic_update_irq (s=0x1d7aff8)
  at C:/msys/home/User/qemu/hw/apic.c:376
  #3  apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
  #4  0x0053b990 in apic_update_irq (s=0x1d7aff8)
  at C:/msys/home/User/qemu/hw/apic.c:376
  #5  apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
  #6  0x0053b990 in apic_update_irq (s=0x1d7aff8)
  at C:/msys/home/User/qemu/hw/apic.c:376
  #7  apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
  ...

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



[Qemu-devel] [Bug 1234179] Re: QEMU segfaults during Windows 7 unattended install

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  QEMU segfaults during Windows 7 unattended install

Status in QEMU:
  Expired

Bug description:
  During today's automated qemu.git testing, a segmentation fault while
  installing Windows 7 SP1 happened.

  qemu.git top commit: 
  10/02 01:30:24 INFO |   git:0150| git commit ID is 
a684f3cf9b9b9c3cb82be87aafc463de8974610c (tag v1.4.0-4237-ga684f3c)

  commit a684f3cf9b9b9c3cb82be87aafc463de8974610c
  Merge: 349cd52 1cf9412
  Author: Anthony Liguori 
  Date:   Mon Sep 30 17:15:27 2013 -0500

  Merge remote-tracking branch 'kraxel/seabios-1.7.3.2' into staging
  
  # By Gerd Hoffmann
  # Via Gerd Hoffmann
  * kraxel/seabios-1.7.3.2:
update seabios from 1.7.2.2 to 1.7.3.2
  
  Message-id: 1380533055-24960-1-git-send-email-kra...@redhat.com

  We have the core file saved in our test servers, we can make
  arrangements to transfer it if there's someone interested in
  investigating further. The framework saved the 'bt full' of the core
  file, that was missing some debug info:

  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  Core was generated by `/usr/local/autotest/tests/virt/qemu/qemu -S -name 
virt-tests-vm1 -M pc -nodefau'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x7ffc8fb86cf0 in pixman_image_get_data () from 
/lib64/libpixman-1.so.0
  #0  0x7ffc8fb86cf0 in pixman_image_get_data () from 
/lib64/libpixman-1.so.0
  No symbol table info available.
  #1  0x7ffc9165b05c in ?? ()
  No symbol table info available.
  #2  0x7ffc9382b540 in ?? ()
  No symbol table info available.
  #3  0x7ffc8f359a8d in clock_gettime () from /lib64/libc.so.6
  No symbol table info available.
  #4  0x7ffc9382b5a8 in ?? ()
  No symbol table info available.
  #5  0x00019382b4c0 in ?? ()
  No symbol table info available.
  #6  0x in ?? ()
  No symbol table info available.

  Extra info:

  Commits for the submodules:

  10/02 01:30:29 DEBUG|base_utils:0134| [stdout] Submodule path 'dtc': checked 
out 'bc895d6d09695d05ceb8b52486ffe861d6cfbdde'
  10/02 01:30:51 DEBUG|base_utils:0134| [stdout] Submodule path 'pixman': 
checked out '97336fad32acf802003855cd8bd6477fa49a12e3'
  10/02 01:30:58 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/SLOF': 
checked out '8cfdfc43f4c4c8c8dfa4b7cf16f7c19c84eee812'
  10/02 01:31:16 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/ipxe': 
checked out '09c5109b8585178172c7608de8d52e9d9af0b680'
  10/02 01:31:20 DEBUG|base_utils:0134| [stdout] Submodule path 
'roms/openbios': checked out '0f3d51ef22ec9166beb3ed434d253029ed7cfe84'
  10/02 01:31:21 DEBUG|base_utils:0134| [stdout] Submodule path 
'roms/qemu-palcode': checked out 'c87a92639b28ac42bc8f6c67443543b405dc479b'
  10/02 01:31:27 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/seabios': 
checked out 'ece025f5980bae88fa677bc9c0d24d2e580e205d'
  10/02 01:31:28 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/sgabios': 
checked out '23d474943dcd55d0550a3d20b3d30e9040a4f15b'
  10/02 01:31:31 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/vgabios': 
checked out '19ea12c230ded95928ecaef0db47a82231c2e485'

  Configure options:

  10/02 01:31:32 DEBUG|base_utils:0099| Running 
'/usr/local/autotest/tmp/virt/src/qemu/configure --target-list=x86_64-softmmu 
--disable-strip --prefix=/usr/local/autotest/tests/virt/qemu/install_root'
  10/02 01:31:35 DEBUG|env_proces:0829| (address cache) DHCP lease OK: 
00:30:48:c5:d6:e2 --> 10.16.72.38
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Install prefix
/usr/local/autotest/tests/virt/qemu/install_root
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] BIOS directory
/usr/local/autotest/tests/virt/qemu/install_root/share/qemu
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] binary directory  
/usr/local/autotest/tests/virt/qemu/install_root/bin
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] library directory 
/usr/local/autotest/tests/virt/qemu/install_root/lib
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libexec directory 
/usr/local/autotest/tests/virt/qemu/install_root/libexec
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] include directory 
/usr/local/autotest/tests/virt/qemu/install_root/include
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] config directory  
/usr/local/autotest/tests/virt/qemu/install_root/etc
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] local state directory   
/usr/local/autotest/tests/virt/qemu/install_root/var
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Manual directory  
/usr/local/autotest/tests/virt/qemu/install_root/share/man
  10/02 01:31:40 DEBUG|base_utils:0134| [stdout] ELF interp prefix

[Qemu-devel] [Bug 1198350] Re: USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument

Status in QEMU:
  Expired

Bug description:
  Host Gentoo linux 32bit
  Guest Windows XP SP3
  qemu 1.4.2 and
  qemu fresh get clone and build 2013-07-04 (version1.5.50)
  qemu command line

  qemu-system-i386 -enable-kvm localtime -m 2047 -boot d
  /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb
  -device usb-ehci,id=ehci -usbdevice host:1493:19

  The device I am trying to use with the guest is an interface for the
  Suunto Ambit 2 GPS watch which has no linux support.

  When the USB device is plugged in qemu reports to the command line:

  USBDEVFS_DISCONNECT: Invalid argument
  Invalid argument

  dmesg shows

  [237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci
  [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but 
max is 0
  [237755.582781] usb 2-1.5: config 1 has no interface number 0
  [237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019
  [237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
  [237755.583633] usb 2-1.5: Product: Ambit
  [237755.583634] usb 2-1.5: Manufacturer: Suunto
  [237755.583636] usb 2-1.5: SerialNumber: CE8309511700
  [237756.584937] usb 2-1.5: reset full-speed USB device number 34 using 
ehci-pci
  [237756.832658] usb 2-1.5: reset full-speed USB device number 34 using 
ehci-pci
  [237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not 
claim interface 1 before use

  In the windows guest Device Manager a HID device is listed but nothing
  else happens, no found new hardware dialog or the Suunto software
  (which is sitting there waiting) is not triggered as it should be.

  I have tried successfully with several other devices (flash drive,
  mouse, printer and video capture device). Because this device pretends
  to be an HID device my kernel's hid-generic driver was picking it up
  first until I modified hid-core.c to ignore this vendorid/productid.
  But still no joy.

  I'm guessing it has something to do with the the dmesg lines:

  [237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but 
max is 0
  [237755.582781] usb 2-1.5: config 1 has no interface number 0

  But read that these warnings are not important though I don't get them
  for other devices. Nor do I get:

  [237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did
  not claim interface 1 before use

  I've done alot of searching and I've run out of ideas. Any help would
  be great.

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



[Qemu-devel] [Bug 726619] Re: loadvm does not load (offline) snapshot anymore

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  loadvm does not load (offline) snapshot anymore

Status in QEMU:
  Expired

Bug description:
  qemu Version: 0.14.0
  The problem is present in the current code from git master as well.

  Loading a snapshot that was created while qemu was not running (using
  qemu-img) does not seem to work anymore.

  Using "loadvm " in the qemu monitor does not have the
  desired effect. Not even an error message is displayed.

  I was able to track down the problem (using git bisect) to this commit:
  
http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a

  After reverting that commit in my local git checkout everything is
  workin as expected again.

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



[Qemu-devel] [Bug 924943] Re: usb-host devices given by command line are routed incomplete to the guest

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  usb-host devices given by command line are routed incomplete to the
  guest

Status in QEMU:
  Expired

Bug description:
  affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches 
(older versions not tested)
  affected guests: linux, windows
  test hardware: standard usb key (or any other piece of USB hardware) that 
works perfectly when plugged in after guest bootup

  Several Sequences have been tested:
  - start qemu with  -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet 
-device usb-host,bus=ehci.0
  - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S 
(to not start up the guest directly) + at the console prompt: "device_add 
usb-host" then "c" to start the guest.

  For the linux guest, I get a usb device listed and detected as /dev/sdb when 
plugging it in at runtime. At startup linux does NOT detect it.
  For the windows guest, I get a usb device listed and detected as "removable 
media" when plugging it in at runtime. At startup Windows does detect 
"something" that is listed in the device manager as Generic Mass Storage 
device, but with a yellow exclamation mark and there is no removable media 
listed in Explorer

  If you need further testings, just let me know.

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



[Qemu-devel] [Bug 1034423] Re: Guests running OpenIndiana (and relatives) fail to boot on AMD hardware

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Guests running OpenIndiana (and relatives) fail to boot on AMD
  hardware

Status in QEMU:
  Expired

Bug description:
  First observed with OpenSolaris 2009.06, and also applies to the
  latest OpenIndiana release.

  Version: qemu-kvm 1.1.1

  Hardware:

  2 x AMD Opteron 6128 8-core processors, 64GB RAM.

  These guests boot on equivalent Intel hardware.

  To reproduce:

  qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
  -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
  151a5-live-x86.iso -boot order=dc

  I've tested with "-vga std" and various different emulated CPU types,
  to no effect.

  What happens:

  GRUB loads, and offers multiple boot options, but none work. Some kind
  of kernel panic flies by very fast before restarting the VM, and
  careful use of the screenshot button reveals that it reads as follows:

  panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
  rp=fec2b48c add r=0

  #df Double fault
  pid=0, pc=0xault
  pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
  cr0: 80050011 cr4:b8
  cr2: 0cr3: ae2f000
gs:1b0fs:  0   es: 160   
ds:  160
   edi:0  esi:  0 ebp: 0 
esp: fec2b4c4
   ebx: c0010015 edx:  0 ecx: 0 eax: 
fec40400
   trp: 8  err:  0 eip: fe800377  cs:   
158
   efl: 202 usp: fec40090  ss:   160
  tss.tss_link: 0x0
  tss.tss_esp0:   0x0
  tss.tss_ss0: 0x160
  tss.tss_esp1:   0x0
  tss.tss_ss1:  0x0
  tss.tss esp2: 0x0
  tss.tss_ss2:  0x0
  tss.tss_cr3:   0xae2f000
  tss.tss_eip:   0xfec40400
  tss.tss_eflags:  0x202
  tss.tss_eax:  0xfec40400
  tss.tss_ebx:  0xc0010015
  tss.tss_ecx:  0xc001
  tss.tss_edx:  0x0
  tss.tss_esp:  0xfec40090

  Warning - stack not written to the dumpbuf
  fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
  fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
  fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)

  If there's any more, I haven't managed to catch it.

  Solaris 11 does not seem to suffer from the same issue, although the
  first message that appears at boot (after the version info) is "trap:
  Unkown trap type 8 in user mode". Could be related?

  As always, thanks in advance and please let me know if I can help to
  test, or provide any more information.

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



[Qemu-devel] [Bug 752476] Re: monitor command mouse_button 1 moves mouse

2017-07-18 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  monitor command mouse_button 1 moves mouse

Status in QEMU:
  Expired

Bug description:
  via the qemu -monitor interface, it is possible to move and click the mouse 
using
  mouse_move 2 1
  mouse_button 1
  but the mouse_button command always moves the mouse to (0,0) making it rather 
unusable to (auto-)trigger any widgets in the VM from the outside.

  Would be nice to have this available for my qemu/kvm based os-autoinst
  testing framework.

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



Re: [Qemu-devel] [PATCH v3] spapr: disable decrementer during reset

2017-07-18 Thread David Gibson
On Wed, Jul 19, 2017 at 09:20:52AM +0530, Nikunj A Dadhania wrote:
> David Gibson  writes:
> 
> > On Tue, Jul 18, 2017 at 10:53:01AM +0530, Nikunj A Dadhania wrote:
> >> David Gibson  writes:
> >> 
> >> > On Mon, Jul 17, 2017 at 09:46:39AM +0530, Nikunj A Dadhania wrote:
> >> >> Rebooting a SMP TCG guest is broken for both single/multi threaded TCG.
> >> >> 
> >> >> When reset happens, all the CPUs are in halted state. First CPU is 
> >> >> brought out
> >> >> of reset and secondary CPUs would be initialized by the guest kernel 
> >> >> using a
> >> >> rtas call start-cpu.
> >> >> 
> >> >> However, in case of TCG, decrementer interrupts keep on coming and 
> >> >> waking the
> >> >> secondary CPUs up.
> >> >> 
> >> >> These secondary CPUs would see the decrementer interrupt pending, which 
> >> >> makes
> >> >> cpu::has_work() to bring them out of wait loop and start executing
> >> >> tcg_exec_cpu().
> >> >> 
> >> >> The problem with this is all the CPUs wake up and start booting SLOF 
> >> >> image,
> >> >> causing the following exception(4 CPUs TCG VM):
> >> >
> >> > Ok, I'm still trying to understand why the behaviour on reboot is
> >> > different from the first boot.
> >> 
> >> During first boot, the cpu is in the stopped state, so
> >> cpus.c:cpu_thread_is_idle returns true and CPU remains in halted state
> >> until rtas start-cpu. Therefore, we never check the cpu_has_work()
> >> 
> >> In case of reboot, all CPUs are resumed after reboot. So we check the
> >> next condition cpu_has_work() in cpu_thread_is_idle(), where we see a
> >> DECR interrupt and remove the CPU from halted state as the CPU has
> >> work.
> >
> > Ok, so it sounds like we should set stopped on all the secondary CPUs
> > on reset as well.  What's causing them to be resumed after the reset
> > at the moment?
> 
> That is part of the main loop in vl.c, when reset is requested. All the
> vcpus are paused (stopped == true) then system reset is issued, and all
> cpus are resumed (stopped == false). Which is correct.

is it?  Seems we have a different value of 'stopped' on the first boot
compared to reoboots, which doesn't seem right.

> static bool main_loop_should_exit(void)
> {
> [...]
> request = qemu_reset_requested();
> if (request) {
> pause_all_vcpus();
> qemu_system_reset(request);
> resume_all_vcpus();
> if (!runstate_check(RUN_STATE_RUNNING) &&
> !runstate_check(RUN_STATE_INMIGRATE)) {
> runstate_set(RUN_STATE_PRELAUNCH);
> }
> }
> [...]
> }
> 
> The CPUs are in halted state, i.e. cpu::halted = 1. We have set
> cpu::halted = 0 for the primary CPU, aka first_cpu, in
> spapr.c::ppc_spapr_reset()
> 
> In case of TCG, we have a decr callback (per CPU) scheduled once the
> machine is started which keeps on running and interrupting irrespective
> of the state of the machine.

Right.  The thing is "halted" means waiting-for-interrupt; it's mostly
used for things like x86 hlt instruction, H_CEDE, short-term nap modes
and so forth.  We're abusing it a little for keeping the secondary
CPUs offline until they're explicitly started.

Trouble is, there isn't a clearly better option - stopped is
automatically turned off after reset as above, so it can't be used for
"stopped under firmware / hypervisor authority".

> tb_env->decr_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &cpu_ppc_decr_cb, cpu);
> 
> Which keeps on queueing the interrupt to the CPUs. All the other CPUs
> are in a tight loop checking cpu_thread_is_idle(), which returns false
> when it sees the decrementer interrupt, the cpu starts executing:
> 
> cpu_exec()
>   -> cpu_handle_halt()
>  -> sees cpu_has_work() and sets cpu->halted = 0
> 
> And the execution resumes, when it shouldnt have. Ideally, for secondary
> CPUs, cpu::halted flag is cleared in rtas start-cpu call.
> 
> Initially, I thought we should not have interrupt during reset state.
> That was the reason of ignoring decr interrupt when msr_ee was disabled
> in my previous patch. BenH suggested that it is wrong from HW
> perspective.
> 
> Regards,
> Nikunj
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread David Gibson
On Wed, Jul 19, 2017 at 02:18:17PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-07-19 at 14:01 +1000, David Gibson wrote:
> > On Wed, Jul 19, 2017 at 01:56:57PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote:
> > > > On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> > > > > Let's provide an empty shell for the XIVE controller model with a
> > > > > couple of attributes for the IRQ number allocator. The latter is
> > > > > largely inspired by OPAL which allocates IPI IRQ numbers from the
> > > > > bottom of the IRQ number space and allocates the HW IRQ numbers from
> > > > > the top.
> > > > > 
> > > > > The number of IPIs is simply deduced from the max number of CPUs the
> > > > > guest supports and we provision a arbitrary number of HW irqs.
> > > > > 
> > > > > The XIVE object is kept private because it will hold internal tables
> > > > > which do not need to be exposed to sPAPR.
> > > 
> > > It does have an MMIO presence though... more than one even. There's the
> > > TIMA (per-HW thread control area) and there's the per-interrupt MMIO
> > > space which are exposed to the guest. There's also the per-queue
> > > MMIO control area too.
> > 
> > Ok.  Always?  Or just on powernv?
> > 
> > If it only has an MMIO presence on powernv, then the "core" xive
> > object should probably be TYPE_DEVICE, with the powernv specific
> > device being a SysBusDevice which incorporates the core xive device
> > inside it.
> 
> No the ones above are on PAPR. PowerNV has even more :-)

Ok.  SusBusDevice is reasonable then.

> The TIMA (thread management area) is the MMIO area through which
> you control the current CPU priority etc...
> 
> It's designed in HW to "know" which core/thread is accessing it (it's
> at a fixed address) and respond appropriately based on that and which
> virtual CPU has been activated on that core/thread.
> 
> It's part of what allows XIVE to deliver interrupts without any HV
> calls.
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v2] hmp: allow cpu index for "info lapic"

2017-07-18 Thread wang.yi59
>On Mon, 17 Jul 2017 21:49:37 -0400

>Yi Wang  wrote:

>

>> Add [vcpu] index support for hmp command "info lapic", which is

>> useful when debugging ipi and so on. Current behavior is not

>> changed when the parameter isn't specified.

>we shouldn't expose cpu_index to users anymore,

>

>I would suggest using to use real APIC ID here but we don't

>have monitor command that returns APIC IDs for present cpus.




Would you like to explain the reason we shouldn't use cpu_index any

more, which is more straightforward than socket-id/core-id/thread-id?

As Eduardo wrote in the next reply, "CPU #" is already a perfectly

good identifier for a human interface :-)

Many thanks.





---

Best wishes

Yi Wang

Re: [Qemu-devel] [PATCH v2 00/45] tcg: support for multiple TCGcontexts

2017-07-18 Thread Richard Henderson

On 07/18/2017 04:17 PM, jiang.bi...@zte.com.cn wrote:

Does that mean both the MTTCG feature and this patch set are all about system
mode, and have nothing to do with linux-user mode?


Yes.



 > MTTCG has only been enabled on a few targets: alpha, arm, ppc64.
 > Look for "mttcg=yes" in configure.
 >
 > In order for MTTCG to be enabled, the target must be adjusted so that
 > (1) all atomic instructions are implemented with atomic tcg operations,
 > (2) define TCG_GUEST_DEFAULT_MO to indicate any barriers implied by
 > normal memory operations by the target architecture.
 >
 > For target/mips, neither of these things are complete.
 >
 > MTTCG has only been enabled on one host: i386.
 > Look for TCG_TARGET_DEFAULT_MO in tcg/*/tcg-target.h.
 >
 > In order for MTTCG to be enabled, the target memory order must not be 
stronger
 > than the host memory order.  Since i386 has a very strong host memory order, 
it
 > is easy for it to emulate any guest.  When the host has a weak memory order, 
we
 > need to add the additional barriers that are implied by the target.  This is
 > work that has not been done.
 >
 > I am not sure why we have not already added this definition to all of the 
other
 > tcg hosts.  I think this is just oversight, since almost everyone uses x86_64
 > linux as the host for testing tcg.  However, since all of the supported 
targets
 > have weak memory orders we ought to be able to support them with any host.

In my case, I use Mips64 host and i386 target, does that mean I can not enable
the MTTCG?


Yes.

It would be only a small amount of work to enable MTTCG for this combination. 
Since soft code freeze for QEMU 2.10 is today, that will have to happen for the 
next development window.



 > For user mode, we should still follow the rules for MTTCG, but we do not.
 > Instead we take it on faith that they have been and execute the code in
 > parallel anyway.  This faith is often misplaced and it does mean that
 > unsupported targets execute user mode code incorrectly.

What do you exactly mean about the *unsupported targets*? mips? arm? i386?


See above, where I list the supported targets and supported hosts.

What is the main reason for the incorrectly execution of multithread app for 
user mode?


Incorrect implementation of atomic operations and incorrect memory barriers.

Specificly for my case(i386 target on Mips64 host in user mode),  how to 
improved the situation?


For this specific case, the primary problem will be the implicit memory 
barriers that the i386 guest requires, but that the mips64 host does not provide.


For tcg/mips/, TCG_TARGET_DEFAULT_MO should be 0, because the mips architecture 
does not have any implicit memory ordering.  All memory barriers are explicit 
via SYNC instructions.


For target/i386, TCG_GUEST_DEFAULT_MO is TCG_MO_ALL & ~TCG_MO_ST_LD, or

TCG_MO_LD_LD | TCG_MO_LD_ST | TCG_MO_ST_ST

which means that implicit memory barriers exist between load/load, load/store, 
store/store, but not store/load.


In order to fix this, we need to add the missing barriers to the opcode stream.

The simplest fix for this is to put a call

tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC)

at the end of gen_ldst_i32 and gen_ldst_i64.  That should be good enough to 
make your specific case operate correctly.


A proper fix will involve (1) emitting those barriers only if the barrier is 
not implied by the host and (2) optimizing away redundant barriers.



r~



Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread Benjamin Herrenschmidt
On Wed, 2017-07-19 at 14:01 +1000, David Gibson wrote:
> On Wed, Jul 19, 2017 at 01:56:57PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote:
> > > On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> > > > Let's provide an empty shell for the XIVE controller model with a
> > > > couple of attributes for the IRQ number allocator. The latter is
> > > > largely inspired by OPAL which allocates IPI IRQ numbers from the
> > > > bottom of the IRQ number space and allocates the HW IRQ numbers from
> > > > the top.
> > > > 
> > > > The number of IPIs is simply deduced from the max number of CPUs the
> > > > guest supports and we provision a arbitrary number of HW irqs.
> > > > 
> > > > The XIVE object is kept private because it will hold internal tables
> > > > which do not need to be exposed to sPAPR.
> > 
> > It does have an MMIO presence though... more than one even. There's the
> > TIMA (per-HW thread control area) and there's the per-interrupt MMIO
> > space which are exposed to the guest. There's also the per-queue
> > MMIO control area too.
> 
> Ok.  Always?  Or just on powernv?
> 
> If it only has an MMIO presence on powernv, then the "core" xive
> object should probably be TYPE_DEVICE, with the powernv specific
> device being a SysBusDevice which incorporates the core xive device
> inside it.

No the ones above are on PAPR. PowerNV has even more :-)

The TIMA (thread management area) is the MMIO area through which
you control the current CPU priority etc...

It's designed in HW to "know" which core/thread is accessing it (it's
at a fixed address) and respond appropriately based on that and which
virtual CPU has been activated on that core/thread.

It's part of what allows XIVE to deliver interrupts without any HV
calls.

Cheers,
Ben.



Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread Benjamin Herrenschmidt
On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote:
> 
> I'm somewhat uncomfortable with an irq allocater here in the intc
> code.  As a rule, irq allocation is the responsibility of the machine,
> not any sub-component.  Furthermore, it should allocate in a way which
> is repeatable, since they need to stay stable across reboots and
> migrations.
> 
> And, yes, we have an allocator of sorts in XICS - it has caused a
> number of problems in the past.

So

For a bare metal model (which we don't have yet) of XIVE, the IRQ
numbering is entirely an artifact of how the HW is configured. There
should thus be no interrupt numbers visible to qemu.

For a PAPR model things are a bit different, but if we want to
maximize code re-use between the two, we probably need to make sure
the interrupts "allocated" by the machine for XIVE can be represented
by the HW model.

That means:

 - Each chip has a range (high bits are the block ID, which maps to a
chip, low bits, around 512K to 1M interrupts is the per-chip space).

 - Interrupts 0...N of that range (N depends on how much backing
memory and MMIO space is provisioned for each chip) are "generic IPIs"
which are somewhat generic interrupt source that can be triggered with
an MMIO store and routed to any target. Those are used in PAPR for
things like IPIs and some type of accelerator interrupts.

 - Portions of that range (which may or may not overlap the 0...N
above, if they do they "shadow" the generic interrupts) can be
configured to be the HW sources from the various PCIe bridges and
the PSI controller.

Cheers,
Ben.

> > +}
> > +
> > +static Property xive_properties[] = {
> > +DEFINE_PROP_UINT32("nr-targets", XIVE, nr_targets, 0),
> > +DEFINE_PROP_END_OF_LIST(),
> > +};
> > +
> > +static void xive_class_init(ObjectClass *klass, void *data)
> > +{
> > +DeviceClass *dc = DEVICE_CLASS(klass);
> > +
> > +dc->realize = xive_realize;
> > +dc->props = xive_properties;
> > +dc->desc = "XIVE";
> > +}
> > +
> > +static const TypeInfo xive_info = {
> > +.name = TYPE_XIVE,
> > +.parent = TYPE_SYS_BUS_DEVICE,
> > +.instance_init = xive_init,
> > +.instance_size = sizeof(XIVE),
> > +.class_init = xive_class_init,
> > +};
> > +
> > +static void xive_register_types(void)
> > +{
> > +type_register_static(&xive_info);
> > +}
> > +
> > +type_init(xive_register_types)
> > diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> > new file mode 100644
> > index ..863f5a9c6b5f
> > --- /dev/null
> > +++ b/include/hw/ppc/xive.h
> > @@ -0,0 +1,27 @@
> > +/*
> > + * QEMU PowerPC XIVE model
> > + *
> > + * Copyright (c) 2017, IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License, version 2, as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, see .
> > + */
> > +
> > +#ifndef PPC_XIVE_H
> > +#define PPC_XIVE_H
> > +
> > +typedef struct XIVE XIVE;
> > +
> > +#define TYPE_XIVE "xive"
> > +#define XIVE(obj) OBJECT_CHECK(XIVE, (obj), TYPE_XIVE)
> > +
> > +#endif /* PPC_XIVE_H */
> 



Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread David Gibson
On Wed, Jul 19, 2017 at 01:56:57PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote:
> > On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> > > Let's provide an empty shell for the XIVE controller model with a
> > > couple of attributes for the IRQ number allocator. The latter is
> > > largely inspired by OPAL which allocates IPI IRQ numbers from the
> > > bottom of the IRQ number space and allocates the HW IRQ numbers from
> > > the top.
> > > 
> > > The number of IPIs is simply deduced from the max number of CPUs the
> > > guest supports and we provision a arbitrary number of HW irqs.
> > > 
> > > The XIVE object is kept private because it will hold internal tables
> > > which do not need to be exposed to sPAPR.
> 
> It does have an MMIO presence though... more than one even. There's the
> TIMA (per-HW thread control area) and there's the per-interrupt MMIO
> space which are exposed to the guest. There's also the per-queue
> MMIO control area too.

Ok.  Always?  Or just on powernv?

If it only has an MMIO presence on powernv, then the "core" xive
object should probably be TYPE_DEVICE, with the powernv specific
device being a SysBusDevice which incorporates the core xive device
inside it.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread Benjamin Herrenschmidt
On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote:
> On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> > Let's provide an empty shell for the XIVE controller model with a
> > couple of attributes for the IRQ number allocator. The latter is
> > largely inspired by OPAL which allocates IPI IRQ numbers from the
> > bottom of the IRQ number space and allocates the HW IRQ numbers from
> > the top.
> > 
> > The number of IPIs is simply deduced from the max number of CPUs the
> > guest supports and we provision a arbitrary number of HW irqs.
> > 
> > The XIVE object is kept private because it will hold internal tables
> > which do not need to be exposed to sPAPR.

It does have an MMIO presence though... more than one even. There's the
TIMA (per-HW thread control area) and there's the per-interrupt MMIO
space which are exposed to the guest. There's also the per-queue
MMIO control area too.

Ben.

> > Signed-off-by: Cédric Le Goater 
> > ---
> >  default-configs/ppc64-softmmu.mak |  1 +
> >  hw/intc/Makefile.objs |  1 +
> >  hw/intc/xive-internal.h   | 28 
> >  hw/intc/xive.c| 94 
> > +++
> >  include/hw/ppc/xive.h | 27 +++
> >  5 files changed, 151 insertions(+)
> >  create mode 100644 hw/intc/xive-internal.h
> >  create mode 100644 hw/intc/xive.c
> >  create mode 100644 include/hw/ppc/xive.h
> > 
> > diff --git a/default-configs/ppc64-softmmu.mak 
> > b/default-configs/ppc64-softmmu.mak
> > index 46c95993217d..1179c07e6e9f 100644
> > --- a/default-configs/ppc64-softmmu.mak
> > +++ b/default-configs/ppc64-softmmu.mak
> > @@ -56,6 +56,7 @@ CONFIG_SM501=y
> >  CONFIG_XICS=$(CONFIG_PSERIES)
> >  CONFIG_XICS_SPAPR=$(CONFIG_PSERIES)
> >  CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM))
> > +CONFIG_XIVE=$(CONFIG_PSERIES)
> >  # For PReP
> >  CONFIG_SERIAL_ISA=y
> >  CONFIG_MC146818RTC=y
> > diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> > index 78426a7dafcd..28b83456bfcc 100644
> > --- a/hw/intc/Makefile.objs
> > +++ b/hw/intc/Makefile.objs
> > @@ -35,6 +35,7 @@ obj-$(CONFIG_SH4) += sh_intc.o
> >  obj-$(CONFIG_XICS) += xics.o
> >  obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
> >  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
> > +obj-$(CONFIG_XIVE) += xive.o
> >  obj-$(CONFIG_POWERNV) += xics_pnv.o
> >  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
> >  obj-$(CONFIG_S390_FLIC) += s390_flic.o
> > diff --git a/hw/intc/xive-internal.h b/hw/intc/xive-internal.h
> > new file mode 100644
> > index ..155c2dcd6066
> > --- /dev/null
> > +++ b/hw/intc/xive-internal.h
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Copyright 2016,2017 IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +#ifndef _INTC_XIVE_INTERNAL_H
> > +#define _INTC_XIVE_INTERNAL_H
> > +
> > +#include 
> > +
> > +struct XIVE {
> > +SysBusDevice parent;
> 
> XIVE probably shouldn't be a SysBusDevice.  According to agraf, that
> should only be used for things which have an MMIO presence on a bus
> structure that's not worth the bother of more specifically modelling.
> 
> I don't think that's the case for XIVE, so it should just have
> TYPE_DEVICE as its parent.  There are several pseries things which
> already get this wrong (mostly because I made them before fully
> understanding the role of the SysBus), but we should avoid adding
> others.
> 
> > +/* Properties */
> > +uint32_t nr_targets;
> > +
> > +/* IRQ number allocator */
> > +uint32_t int_count; /* Number of interrupts: nr_targets + HW 
> > IRQs */
> > +uint32_t int_base;  /* Min index */
> > +uint32_t int_max;   /* Max index */
> > +uint32_t int_hw_bot;/* Bottom index of HW IRQ allocator */
> > +uint32_t int_ipi_top;   /* Highest IPI index handed out so far + 1 
> > */
> > +};
> > +
> > +#endif /* _INTC_XIVE_INTERNAL_H */
> > diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> > new file mode 100644
> > index ..5b4ea915d87c
> > --- /dev/null
> > +++ b/hw/intc/xive.c
> > @@ -0,0 +1,94 @@
> > +/*
> > + * QEMU PowerPC XIVE model
> > + *
> > + * Copyright (c) 2017, IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License, version 2, as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public

Re: [Qemu-devel] [RFC PATCH 00/26] guest exploitation of the XIVE interrupt controller (POWER9)

2017-07-18 Thread Benjamin Herrenschmidt
On Wed, 2017-07-19 at 13:00 +1000, David Gibson wrote:
> So, this is probably obvious, but I'm not considering this a candidate
> for qemu 2.10 (seeing as the soft freeze was yesterday).  I'll still
> try to review and, once ready, queue for 2.11.

Right. I need to review still and we need to make sure we have the
right plumbing for migration etc... and of course I need to do the
KVM bits. So it's definitely not 2.10 material.

Cheers,
Ben.




Re: [Qemu-devel] [PATCH v3] spapr: disable decrementer during reset

2017-07-18 Thread Nikunj A Dadhania
David Gibson  writes:

> On Tue, Jul 18, 2017 at 10:53:01AM +0530, Nikunj A Dadhania wrote:
>> David Gibson  writes:
>> 
>> > On Mon, Jul 17, 2017 at 09:46:39AM +0530, Nikunj A Dadhania wrote:
>> >> Rebooting a SMP TCG guest is broken for both single/multi threaded TCG.
>> >> 
>> >> When reset happens, all the CPUs are in halted state. First CPU is 
>> >> brought out
>> >> of reset and secondary CPUs would be initialized by the guest kernel 
>> >> using a
>> >> rtas call start-cpu.
>> >> 
>> >> However, in case of TCG, decrementer interrupts keep on coming and waking 
>> >> the
>> >> secondary CPUs up.
>> >> 
>> >> These secondary CPUs would see the decrementer interrupt pending, which 
>> >> makes
>> >> cpu::has_work() to bring them out of wait loop and start executing
>> >> tcg_exec_cpu().
>> >> 
>> >> The problem with this is all the CPUs wake up and start booting SLOF 
>> >> image,
>> >> causing the following exception(4 CPUs TCG VM):
>> >
>> > Ok, I'm still trying to understand why the behaviour on reboot is
>> > different from the first boot.
>> 
>> During first boot, the cpu is in the stopped state, so
>> cpus.c:cpu_thread_is_idle returns true and CPU remains in halted state
>> until rtas start-cpu. Therefore, we never check the cpu_has_work()
>> 
>> In case of reboot, all CPUs are resumed after reboot. So we check the
>> next condition cpu_has_work() in cpu_thread_is_idle(), where we see a
>> DECR interrupt and remove the CPU from halted state as the CPU has
>> work.
>
> Ok, so it sounds like we should set stopped on all the secondary CPUs
> on reset as well.  What's causing them to be resumed after the reset
> at the moment?

That is part of the main loop in vl.c, when reset is requested. All the
vcpus are paused (stopped == true) then system reset is issued, and all
cpus are resumed (stopped == false). Which is correct.

static bool main_loop_should_exit(void)
{
[...]
request = qemu_reset_requested();
if (request) {
pause_all_vcpus();
qemu_system_reset(request);
resume_all_vcpus();
if (!runstate_check(RUN_STATE_RUNNING) &&
!runstate_check(RUN_STATE_INMIGRATE)) {
runstate_set(RUN_STATE_PRELAUNCH);
}
}
[...]
}

The CPUs are in halted state, i.e. cpu::halted = 1. We have set
cpu::halted = 0 for the primary CPU, aka first_cpu, in
spapr.c::ppc_spapr_reset()

In case of TCG, we have a decr callback (per CPU) scheduled once the
machine is started which keeps on running and interrupting irrespective
of the state of the machine.

tb_env->decr_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &cpu_ppc_decr_cb, cpu);

Which keeps on queueing the interrupt to the CPUs. All the other CPUs
are in a tight loop checking cpu_thread_is_idle(), which returns false
when it sees the decrementer interrupt, the cpu starts executing:

cpu_exec()
  -> cpu_handle_halt()
 -> sees cpu_has_work() and sets cpu->halted = 0

And the execution resumes, when it shouldnt have. Ideally, for secondary
CPUs, cpu::halted flag is cleared in rtas start-cpu call.

Initially, I thought we should not have interrupt during reset state.
That was the reason of ignoring decr interrupt when msr_ee was disabled
in my previous patch. BenH suggested that it is wrong from HW
perspective.

Regards,
Nikunj




Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread David Gibson
On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> Let's provide an empty shell for the XIVE controller model with a
> couple of attributes for the IRQ number allocator. The latter is
> largely inspired by OPAL which allocates IPI IRQ numbers from the
> bottom of the IRQ number space and allocates the HW IRQ numbers from
> the top.
> 
> The number of IPIs is simply deduced from the max number of CPUs the
> guest supports and we provision a arbitrary number of HW irqs.
> 
> The XIVE object is kept private because it will hold internal tables
> which do not need to be exposed to sPAPR.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  default-configs/ppc64-softmmu.mak |  1 +
>  hw/intc/Makefile.objs |  1 +
>  hw/intc/xive-internal.h   | 28 
>  hw/intc/xive.c| 94 
> +++
>  include/hw/ppc/xive.h | 27 +++
>  5 files changed, 151 insertions(+)
>  create mode 100644 hw/intc/xive-internal.h
>  create mode 100644 hw/intc/xive.c
>  create mode 100644 include/hw/ppc/xive.h
> 
> diff --git a/default-configs/ppc64-softmmu.mak 
> b/default-configs/ppc64-softmmu.mak
> index 46c95993217d..1179c07e6e9f 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -56,6 +56,7 @@ CONFIG_SM501=y
>  CONFIG_XICS=$(CONFIG_PSERIES)
>  CONFIG_XICS_SPAPR=$(CONFIG_PSERIES)
>  CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM))
> +CONFIG_XIVE=$(CONFIG_PSERIES)
>  # For PReP
>  CONFIG_SERIAL_ISA=y
>  CONFIG_MC146818RTC=y
> diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> index 78426a7dafcd..28b83456bfcc 100644
> --- a/hw/intc/Makefile.objs
> +++ b/hw/intc/Makefile.objs
> @@ -35,6 +35,7 @@ obj-$(CONFIG_SH4) += sh_intc.o
>  obj-$(CONFIG_XICS) += xics.o
>  obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
>  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
> +obj-$(CONFIG_XIVE) += xive.o
>  obj-$(CONFIG_POWERNV) += xics_pnv.o
>  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
>  obj-$(CONFIG_S390_FLIC) += s390_flic.o
> diff --git a/hw/intc/xive-internal.h b/hw/intc/xive-internal.h
> new file mode 100644
> index ..155c2dcd6066
> --- /dev/null
> +++ b/hw/intc/xive-internal.h
> @@ -0,0 +1,28 @@
> +/*
> + * Copyright 2016,2017 IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +#ifndef _INTC_XIVE_INTERNAL_H
> +#define _INTC_XIVE_INTERNAL_H
> +
> +#include 
> +
> +struct XIVE {
> +SysBusDevice parent;

XIVE probably shouldn't be a SysBusDevice.  According to agraf, that
should only be used for things which have an MMIO presence on a bus
structure that's not worth the bother of more specifically modelling.

I don't think that's the case for XIVE, so it should just have
TYPE_DEVICE as its parent.  There are several pseries things which
already get this wrong (mostly because I made them before fully
understanding the role of the SysBus), but we should avoid adding
others.

> +/* Properties */
> +uint32_t nr_targets;
> +
> +/* IRQ number allocator */
> +uint32_t int_count; /* Number of interrupts: nr_targets + HW 
> IRQs */
> +uint32_t int_base;  /* Min index */
> +uint32_t int_max;   /* Max index */
> +uint32_t int_hw_bot;/* Bottom index of HW IRQ allocator */
> +uint32_t int_ipi_top;   /* Highest IPI index handed out so far + 1 */
> +};
> +
> +#endif /* _INTC_XIVE_INTERNAL_H */
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> new file mode 100644
> index ..5b4ea915d87c
> --- /dev/null
> +++ b/hw/intc/xive.c
> @@ -0,0 +1,94 @@
> +/*
> + * QEMU PowerPC XIVE model
> + *
> + * Copyright (c) 2017, IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */
> +#include "qemu/osdep.h"
> +#include "qemu/log.h"
> +#include "qapi/error.h"
> +#include "target/ppc/cpu.h"
> +#include "sysemu/cpus.h"
> +#include "sysemu/dma.h"
> +#include "monitor/monitor.h"
> +#include "hw/ppc/xive.h"
> +
> +#include "xive-internal.h"
> +
> +/*
> + * Main XIVE object

As with XICs, does it really make sense for there to be a "main" XIVE
object, or should be an interface attached to the machine?

> + */
> +
>

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

2017-07-18 Thread David Gibson
On Wed, Jul 19, 2017 at 01:08:49PM +1000, David Gibson wrote:
> On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote:
> > Let's provide an empty shell for the XIVE controller model with a
> > couple of attributes for the IRQ number allocator. The latter is
> > largely inspired by OPAL which allocates IPI IRQ numbers from the
> > bottom of the IRQ number space and allocates the HW IRQ numbers from
> > the top.
> > 
> > The number of IPIs is simply deduced from the max number of CPUs the
> > guest supports and we provision a arbitrary number of HW irqs.
> > 
> > The XIVE object is kept private because it will hold internal tables
> > which do not need to be exposed to sPAPR.
> > 
> > Signed-off-by: Cédric Le Goater 
> > ---
> >  default-configs/ppc64-softmmu.mak |  1 +
> >  hw/intc/Makefile.objs |  1 +
> >  hw/intc/xive-internal.h   | 28 
> >  hw/intc/xive.c| 94 
> > +++
> >  include/hw/ppc/xive.h | 27 +++
> >  5 files changed, 151 insertions(+)
> >  create mode 100644 hw/intc/xive-internal.h
> >  create mode 100644 hw/intc/xive.c
> >  create mode 100644 include/hw/ppc/xive.h
> > 
> > diff --git a/default-configs/ppc64-softmmu.mak 
> > b/default-configs/ppc64-softmmu.mak
> > index 46c95993217d..1179c07e6e9f 100644
> > --- a/default-configs/ppc64-softmmu.mak
> > +++ b/default-configs/ppc64-softmmu.mak
> > @@ -56,6 +56,7 @@ CONFIG_SM501=y
> >  CONFIG_XICS=$(CONFIG_PSERIES)
> >  CONFIG_XICS_SPAPR=$(CONFIG_PSERIES)
> >  CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM))
> > +CONFIG_XIVE=$(CONFIG_PSERIES)
> >  # For PReP
> >  CONFIG_SERIAL_ISA=y
> >  CONFIG_MC146818RTC=y
> > diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
> > index 78426a7dafcd..28b83456bfcc 100644
> > --- a/hw/intc/Makefile.objs
> > +++ b/hw/intc/Makefile.objs
> > @@ -35,6 +35,7 @@ obj-$(CONFIG_SH4) += sh_intc.o
> >  obj-$(CONFIG_XICS) += xics.o
> >  obj-$(CONFIG_XICS_SPAPR) += xics_spapr.o
> >  obj-$(CONFIG_XICS_KVM) += xics_kvm.o
> > +obj-$(CONFIG_XIVE) += xive.o
> >  obj-$(CONFIG_POWERNV) += xics_pnv.o
> >  obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
> >  obj-$(CONFIG_S390_FLIC) += s390_flic.o
> > diff --git a/hw/intc/xive-internal.h b/hw/intc/xive-internal.h
> > new file mode 100644
> > index ..155c2dcd6066
> > --- /dev/null
> > +++ b/hw/intc/xive-internal.h
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Copyright 2016,2017 IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +#ifndef _INTC_XIVE_INTERNAL_H
> > +#define _INTC_XIVE_INTERNAL_H
> > +
> > +#include 
> > +
> > +struct XIVE {
> > +SysBusDevice parent;
> 
> XIVE probably shouldn't be a SysBusDevice.  According to agraf, that
> should only be used for things which have an MMIO presence on a bus
> structure that's not worth the bother of more specifically modelling.
> 
> I don't think that's the case for XIVE, so it should just have
> TYPE_DEVICE as its parent.  There are several pseries things which
> already get this wrong (mostly because I made them before fully
> understanding the role of the SysBus), but we should avoid adding
> others.
> 
> > +/* Properties */
> > +uint32_t nr_targets;
> > +
> > +/* IRQ number allocator */
> > +uint32_t int_count; /* Number of interrupts: nr_targets + HW 
> > IRQs */
> > +uint32_t int_base;  /* Min index */
> > +uint32_t int_max;   /* Max index */
> > +uint32_t int_hw_bot;/* Bottom index of HW IRQ allocator */
> > +uint32_t int_ipi_top;   /* Highest IPI index handed out so far + 1 
> > */
> > +};
> > +
> > +#endif /* _INTC_XIVE_INTERNAL_H */
> > diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> > new file mode 100644
> > index ..5b4ea915d87c
> > --- /dev/null
> > +++ b/hw/intc/xive.c
> > @@ -0,0 +1,94 @@
> > +/*
> > + * QEMU PowerPC XIVE model
> > + *
> > + * Copyright (c) 2017, IBM Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License, version 2, as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, see .
> > + */
> > +#include "qemu/osdep.h"
> > +#include "qemu/log.h"
> > +#include "qapi/error.h"
> > +#include "target/ppc/cpu.h"
> > +#includ

Re: [Qemu-devel] [RFC PATCH 00/26] guest exploitation of the XIVE interrupt controller (POWER9)

2017-07-18 Thread David Gibson
On Wed, Jul 05, 2017 at 07:13:13PM +0200, Cédric Le Goater wrote:
> On a POWER9 sPAPR machine, the Client Architecture Support (CAS)
> negotiation process determines whether the guest operates with an
> interrupt controller using the XICS legacy model, as found on POWER8,
> or in XIVE exploitation mode, the newer POWER9 interrupt model. This
> patchset is a first proposal to add XIVE support in the sPAPR machine.
> 
> The first patches introduce the XIVE exploitation mode in CAS.
> 
> Follow models for the XIVE interrupt controller, source and presenter.
> We try to reuse the ICS and ICP models of XICS because the sPAPR
> machine is tied to the XICSFabric interface and should be using a
> common framework to be able to switch from one controller model to
> another. To be discussed of course.
> 
> Then comes support for the Hypervisor's call which are used to
> configure the interrupt sources and the event/notification queues of
> the guest.
> 
> Finally, the last patches try to integrate the XIVE interrupt model in
> the sPAPR machine and this not without a couple of serious hacks to
> have something to test. See 'Caveats' below for more details.
> 
> This is a first draft and I expect a lot of rewrite before it reaches
> mainline QEMU. Nevertheless, it compiles, boots and can be used for
> some testing.

So, this is probably obvious, but I'm not considering this a candidate
for qemu 2.10 (seeing as the soft freeze was yesterday).  I'll still
try to review and, once ready, queue for 2.11.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [RFC PATCH 05/26] ppc/xive: define XIVE internal tables

2017-07-18 Thread David Gibson
On Wed, Jul 05, 2017 at 07:13:18PM +0200, Cédric Le Goater wrote:
> The XIVE interrupt controller of the POWER9 uses a set of tables to
> redirect exception from event sources to CPU threads. Among which we
> choose to model :
> 
>  - the State Bit Entries (SBE), also known as Event State Buffer
>(ESB). This is a two bit state machine for each event source which
>is used to trigger events. The bits are named "P" (pending) and "Q"
>(queued) and can be controlled by MMIO.
> 
>  - the Interrupt Virtualization Entry (IVE) table, also known as Event
>Assignment Structure (EAS). This table is indexed by the IRQ number
>and is looked up to find the Event Queue associated with a
>triggered event.
> 
>  - the Event Queue Descriptor (EQD) table, also known as Event
>Notification Descriptor (END). The EQD contains fields that specify
>the Event Queue on which event data is posted (and later pulled by
>the OS) and also a target (or VPD) to notify.
> 
> An additional table was not modeled but we might need to to support
> the H_INT_SET_OS_REPORTING_LINE hcall:
> 
>  - the Virtual Processor Descriptor (VPD) table, also known as
>Notification Virtual Target (NVT).
> 
> The XIVE object is expanded with the tables described above. The size
> of each table depends on the number of provisioned IRQ and the maximum
> number of CPUs in the system. The indexing is very basic and might
> need to be improved for the EQs.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/intc/xive-internal.h | 95 
> +
>  hw/intc/xive.c  | 72 +
>  2 files changed, 167 insertions(+)
> 
> diff --git a/hw/intc/xive-internal.h b/hw/intc/xive-internal.h
> index 155c2dcd6066..8e755aa88a14 100644
> --- a/hw/intc/xive-internal.h
> +++ b/hw/intc/xive-internal.h
> @@ -11,6 +11,89 @@
>  
>  #include 
>  
> +/* Utilities to manipulate these (originaly from OPAL) */
> +#define MASK_TO_LSH(m)  (__builtin_ffsl(m) - 1)
> +#define GETFIELD(m, v)  (((v) & (m)) >> MASK_TO_LSH(m))
> +#define SETFIELD(m, v, val) \
> +(((v) & ~(m)) | typeof(v))(val)) << MASK_TO_LSH(m)) & (m)))
> +
> +#define PPC_BIT(bit)(0x8000UL >> (bit))
> +#define PPC_BIT32(bit)  (0x8000UL >> (bit))
> +#define PPC_BIT8(bit)   (0x80UL >> (bit))
> +#define PPC_BITMASK(bs, be) ((PPC_BIT(bs) - PPC_BIT(be)) | PPC_BIT(bs))
> +#define PPC_BITMASK32(bs, be)   ((PPC_BIT32(bs) - PPC_BIT32(be)) | \
> + PPC_BIT32(bs))
> +
> +/* IVE/EAS
> + *
> + * One per interrupt source. Targets that interrupt to a given EQ
> + * and provides the corresponding logical interrupt number (EQ data)
> + *
> + * We also map this structure to the escalation descriptor inside
> + * an EQ, though in that case the valid and masked bits are not used.
> + */
> +typedef struct XiveIVE {
> +/* Use a single 64-bit definition to make it easier to
> + * perform atomic updates
> + */
> +uint64_tw;
> +#define IVE_VALID   PPC_BIT(0)
> +#define IVE_EQ_BLOCKPPC_BITMASK(4, 7)/* Destination EQ block# */
> +#define IVE_EQ_INDEXPPC_BITMASK(8, 31)   /* Destination EQ index */
> +#define IVE_MASKED  PPC_BIT(32)  /* Masked */
> +#define IVE_EQ_DATA PPC_BITMASK(33, 63)  /* Data written to the EQ */
> +} XiveIVE;
> +
> +/* EQ */
> +typedef struct XiveEQ {
> +uint32_tw0;
> +#define EQ_W0_VALID PPC_BIT32(0)
> +#define EQ_W0_ENQUEUE   PPC_BIT32(1)
> +#define EQ_W0_UCOND_NOTIFY  PPC_BIT32(2)
> +#define EQ_W0_BACKLOG   PPC_BIT32(3)
> +#define EQ_W0_PRECL_ESC_CTL PPC_BIT32(4)
> +#define EQ_W0_ESCALATE_CTL  PPC_BIT32(5)
> +#define EQ_W0_END_OF_INTR   PPC_BIT32(6)
> +#define EQ_W0_QSIZE PPC_BITMASK32(12, 15)
> +#define EQ_W0_SW0   PPC_BIT32(16)
> +#define EQ_W0_FIRMWARE  EQ_W0_SW0 /* Owned by FW */
> +#define EQ_QSIZE_4K 0
> +#define EQ_QSIZE_64K4
> +#define EQ_W0_HWDEP PPC_BITMASK32(24, 31)
> +uint32_tw1;
> +#define EQ_W1_ESn   PPC_BITMASK32(0, 1)
> +#define EQ_W1_ESn_P PPC_BIT32(0)
> +#define EQ_W1_ESn_Q PPC_BIT32(1)
> +#define EQ_W1_ESe   PPC_BITMASK32(2, 3)
> +#define EQ_W1_ESe_P PPC_BIT32(2)
> +#define EQ_W1_ESe_Q PPC_BIT32(3)
> +#define EQ_W1_GENERATIONPPC_BIT32(9)
> +#define EQ_W1_PAGE_OFF  PPC_BITMASK32(10, 31)
> +uint32_tw2;
> +#define EQ_W2_MIGRATION_REG PPC_BITMASK32(0, 3)
> +#define EQ_W2_OP_DESC_HIPPC_BITMASK32(4, 31)
> +uint32_tw3;
> +#define EQ_W3_OP_DESC_LOPPC_BITMASK32(0, 31)
> +uint32_tw4;
> +#define EQ_W4_ESC_EQ_BLOCK  PPC_BITMASK32(4, 7)
> +#define EQ_W4_ESC_EQ_INDEX  PPC_BITMASK32(8, 31)
> +   

Re: [Qemu-devel] [PATCH RFC v2 7/9] s390x/pci: fence off instructions for non-pci

2017-07-18 Thread Yi Min Zhao



在 2017/7/18 下午10:24, Cornelia Huck 写道:

If a guest running on a machine without zpci issues a pci instruction,
throw them an exception.

Signed-off-by: Cornelia Huck 
---
  target/s390x/kvm.c | 54 +-
  1 file changed, 41 insertions(+), 13 deletions(-)

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 880eccd58a..6068c3 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1191,7 +1191,11 @@ static int kvm_clp_service_call(S390CPU *cpu, struct 
kvm_run *run)
  {
  uint8_t r2 = (run->s390_sieic.ipb & 0x000f) >> 16;

-return clp_service_call(cpu, r2);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+return clp_service_call(cpu, r2);
+} else {
+return -1;
+}

Hi Conny,

Should we use a global value to store s390_has_feat(S390_FEAT_ZPCI)?
I'm not sure it's a good idea.

Yi Min

  }

  static int kvm_pcilg_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1199,7 +1203,11 @@ static int kvm_pcilg_service_call(S390CPU *cpu, struct 
kvm_run *run)
  uint8_t r1 = (run->s390_sieic.ipb & 0x00f0) >> 20;
  uint8_t r2 = (run->s390_sieic.ipb & 0x000f) >> 16;

-return pcilg_service_call(cpu, r1, r2);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+return pcilg_service_call(cpu, r1, r2);
+} else {
+return -1;
+}
  }

  static int kvm_pcistg_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1207,7 +1215,11 @@ static int kvm_pcistg_service_call(S390CPU *cpu, struct 
kvm_run *run)
  uint8_t r1 = (run->s390_sieic.ipb & 0x00f0) >> 20;
  uint8_t r2 = (run->s390_sieic.ipb & 0x000f) >> 16;

-return pcistg_service_call(cpu, r1, r2);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+return pcistg_service_call(cpu, r1, r2);
+} else {
+return -1;
+}
  }

  static int kvm_stpcifc_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1216,10 +1228,14 @@ static int kvm_stpcifc_service_call(S390CPU *cpu, 
struct kvm_run *run)
  uint64_t fiba;
  uint8_t ar;

-cpu_synchronize_state(CPU(cpu));
-fiba = get_base_disp_rxy(cpu, run, &ar);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+cpu_synchronize_state(CPU(cpu));
+fiba = get_base_disp_rxy(cpu, run, &ar);

-return stpcifc_service_call(cpu, r1, fiba, ar);
+return stpcifc_service_call(cpu, r1, fiba, ar);
+} else {
+return -1;
+}
  }

  static int kvm_sic_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1247,7 +1263,11 @@ static int kvm_rpcit_service_call(S390CPU *cpu, struct 
kvm_run *run)
  uint8_t r1 = (run->s390_sieic.ipb & 0x00f0) >> 20;
  uint8_t r2 = (run->s390_sieic.ipb & 0x000f) >> 16;

-return rpcit_service_call(cpu, r1, r2);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+return rpcit_service_call(cpu, r1, r2);
+} else {
+return -1;
+}
  }

  static int kvm_pcistb_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1257,10 +1277,14 @@ static int kvm_pcistb_service_call(S390CPU *cpu, struct 
kvm_run *run)
  uint64_t gaddr;
  uint8_t ar;

-cpu_synchronize_state(CPU(cpu));
-gaddr = get_base_disp_rsy(cpu, run, &ar);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+cpu_synchronize_state(CPU(cpu));
+gaddr = get_base_disp_rsy(cpu, run, &ar);

-return pcistb_service_call(cpu, r1, r3, gaddr, ar);
+return pcistb_service_call(cpu, r1, r3, gaddr, ar);
+} else {
+return -1;
+}
  }

  static int kvm_mpcifc_service_call(S390CPU *cpu, struct kvm_run *run)
@@ -1269,10 +1293,14 @@ static int kvm_mpcifc_service_call(S390CPU *cpu, struct 
kvm_run *run)
  uint64_t fiba;
  uint8_t ar;

-cpu_synchronize_state(CPU(cpu));
-fiba = get_base_disp_rxy(cpu, run, &ar);
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+cpu_synchronize_state(CPU(cpu));
+fiba = get_base_disp_rxy(cpu, run, &ar);

-return mpcifc_service_call(cpu, r1, fiba, ar);
+return mpcifc_service_call(cpu, r1, fiba, ar);
+} else {
+return -1;
+}
  }

  static int handle_b9(S390CPU *cpu, struct kvm_run *run, uint8_t ipa1)





Re: [Qemu-devel] [PATCH RFC v2 8/9] s390x/kvm: msi route fixup for non-pci

2017-07-18 Thread Yi Min Zhao



在 2017/7/18 下午11:22, Cornelia Huck 写道:

On Tue, 18 Jul 2017 11:58:08 -0300
Philippe Mathieu-Daudé  wrote:


Hi Cornelia,

On Tue, Jul 18, 2017 at 11:24 AM, Cornelia Huck  wrote:

If we don't provide pci, we cannot have a pci device for which we
have to translate to adapter routes: just return -ENODEV.

Signed-off-by: Cornelia Huck 
---
  target/s390x/kvm.c | 33 +++--
  1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 6068c3..df0e5af151 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2424,22 +2424,27 @@ int kvm_arch_fixup_msi_route(struct 
kvm_irq_routing_entry *route,
  uint32_t idx = data >> ZPCI_MSI_VEC_BITS;
  uint32_t vec = data & ZPCI_MSI_VEC_MASK;

-pbdev = s390_pci_find_dev_by_idx(s390_get_phb(), idx);
-if (!pbdev) {
-DPRINTF("add_msi_route no dev\n");
-return -ENODEV;
-}
+if (s390_has_feat(S390_FEAT_ZPCI)) {
+pbdev = s390_pci_find_dev_by_idx(s390_get_phb(), idx);
+if (!pbdev) {
+DPRINTF("add_msi_route no dev\n");
+return -ENODEV;
+}

-pbdev->routes.adapter.ind_offset = vec;
+pbdev->routes.adapter.ind_offset = vec;

-route->type = KVM_IRQ_ROUTING_S390_ADAPTER;
-route->flags = 0;
-route->u.adapter.summary_addr = pbdev->routes.adapter.summary_addr;
-route->u.adapter.ind_addr = pbdev->routes.adapter.ind_addr;
-route->u.adapter.summary_offset = pbdev->routes.adapter.summary_offset;
-route->u.adapter.ind_offset = pbdev->routes.adapter.ind_offset;
-route->u.adapter.adapter_id = pbdev->routes.adapter.adapter_id;
-return 0;
+route->type = KVM_IRQ_ROUTING_S390_ADAPTER;
+route->flags = 0;
+route->u.adapter.summary_addr = pbdev->routes.adapter.summary_addr;
+route->u.adapter.ind_addr = pbdev->routes.adapter.ind_addr;
+route->u.adapter.summary_offset = pbdev->routes.adapter.summary_offset;
+route->u.adapter.ind_offset = pbdev->routes.adapter.ind_offset;
+route->u.adapter.adapter_id = pbdev->routes.adapter.adapter_id;
+return 0;
+} else {
+DPRINTF("fixup_msi_route on non-pci machine?!\n");
+return -ENODEV;
+}
  }

  int kvm_arch_add_msi_route_post(struct kvm_irq_routing_entry *route,
--
2.13.3

What about inverting the check?

+if (!s390_has_feat(S390_FEAT_ZPCI)) {
+DPRINTF("fixup_msi_route on non-pci machine?!\n");
+return -ENODEV;
+}

I usually prefer the more common branch on top, but (1) this causes
more changes in this case and (2) I'm not so sure if zpci on really is
the common case...


Sorry for my duplicated comment. I think we don't know which is more 
common. Currently 2.9
machine doesn' t support zpci facility. But in the future, how will the 
thing change?





Re: [Qemu-devel] [PATCH RFC v2 8/9] s390x/kvm: msi route fixup for non-pci

2017-07-18 Thread Yi Min Zhao
I think moving the new code on the top of this function would make it 
more readable.



在 2017/7/18 下午10:24, Cornelia Huck 写道:

+} else {
+DPRINTF("fixup_msi_route on non-pci machine?!\n");
+return -ENODEV;
+}





Re: [Qemu-devel] Question for iotests 188, 189 and 087

2017-07-18 Thread Jing Liu

Hi Eric,


On 2017/7/18 下午10:57, Eric Blake wrote:

On 07/17/2017 10:01 PM, Jing Liu wrote:

Hi all,

Do you anybody have iotests failure: 188, 189 and 087 of the latest qemu
upsteam?

I just wondered if it has something wrong with my test machines because
I have different results with two machines.

It might help to show the ./check command line you are using, as well as
the errors you are getting.  Right now, master is failing on 51, 140,
and 143 when I test across './check -raw', './check -qcow2', and
'./check nbd',

I used ./check -qcow2 to do it.
I tested on different machines and got different results. One is failed 
on 140 and 143. The other one told

me 087, 140, 143, 188, 189.
I guess it is because some configuration or libraries, and will also 
refer to other replies from the mail.

I'll check the details.

Thank you so much.

Jing



but not the three you mention.  But the iotests framework
allows a lot more combinations of testing (and we probably have some
lurking testsuite bugs on some of the more exotic combinations).






Re: [Qemu-devel] [PATCH v2 00/45] tcg: support for multiple TCGcontexts

2017-07-18 Thread jiang.biao2
> On 07/18/2017 02:22 PM, jiang.bi...@zte.com.cn wrote:



> > Seeing your work on multiple TCG, it seems that it has some kind of 
> > connection 
> > with the  MTTCG feature,
> > 
> > but I do not figure out how they are connected in detail.
> > 
> > Could you pls help to confirm the following questions:
> > 
> >  1.
> > 
> > what is the relationship between your patches and the MTTCG feature
> > mentioned by https://lwn.net/Articles/697265/?
> 
> The current MTTCG feature is in QEMU mainline.  It allows parallel execution 
> of 
> translated code in both system mode.  It does *not* allow parallel 
> translation 
> -- all translation is done with tb_lock held.
> 
> Note that we *always* have parallel execution in user mode.  However, this 
> can 
> and does lead to problems.  See below.
> 
> This patch set allows parallel translation in system mode.  This is shown to 
> improve the overall throughput.  It does *not* allow parallel translation in 
> user mode.  Firstly because user mode already shares more translations 
> between 
> threads (because it is running a single executable), and so the translation 
> routines are not high in the profile.  Secondly because there are additional 
> locking problems due to the fact that we have no bound on the number of user 
> threads.

Does that mean both the MTTCG feature and this patch set are all about system 


mode, and have nothing to do with linux-user mode?




>
>  2.
> 
> What is the current status of the development of the MTTCG feature?
> 
> MTTCG has only been enabled on a few targets: alpha, arm, ppc64.
> Look for "mttcg=yes" in configure.
> 
> In order for MTTCG to be enabled, the target must be adjusted so that
> (1) all atomic instructions are implemented with atomic tcg operations,
> (2) define TCG_GUEST_DEFAULT_MO to indicate any barriers implied by
> normal memory operations by the target architecture.
> 
> For target/mips, neither of these things are complete.
> 
> MTTCG has only been enabled on one host: i386.
> Look for TCG_TARGET_DEFAULT_MO in tcg/*/tcg-target.h.
> 
> In order for MTTCG to be enabled, the target memory order must not be 
> stronger 
> than the host memory order.  Since i386 has a very strong host memory order, 
> it 
> is easy for it to emulate any guest.  When the host has a weak memory order, 
> we 
> need to add the additional barriers that are implied by the target.  This is 
> work that has not been done.
> 
> I am not sure why we have not already added this definition to all of the 
> other 
> tcg hosts.  I think this is just oversight, since almost everyone uses x86_64 
> linux as the host for testing tcg.  However, since all of the supported 
> targets 
> have weak memory orders we ought to be able to support them with any host.
In my case, I use Mips64 host and i386 target, does that mean I can not enable 


the MTTCG?




> >  3.
> > 
> > Is there any problem with the multithread programme running with 
> > linux-user
> > qemu mode? would the situation be improved with  the MTTCG feature?
> > 
> > We need to use linux-user mode qemu to run multithread app, but there 
> > seems
> > to be many problem.
> 
> For user mode, we should still follow the rules for MTTCG, but we do not. 
> Instead we take it on faith that they have been and execute the code in 
> parallel anyway.  This faith is often misplaced and it does mean that 
> unsupported targets execute user mode code incorrectly.
What do you exactly mean about the *unsupported targets*? mips? arm? i386? 


What is the main reason for the incorrectly execution of multithread app for 
user mode?

Is MTTCG helpful for that?

Specificly for my case(i386 target on Mips64 host in user mode),  how to 
improved the situation?




Thanks a lot for your detailed explaination.

[Qemu-devel] host side todo list for virtio rdma

2017-07-18 Thread Michael S. Tsirkin
Here are some thoughts on bits that are still missing to get a working
virtio-rdma, with some suggestions. These are very preliminary but I
feel I kept these in my head (and discussed offline) for too long. All
of the below is just my personal humble opinion.

Feature Requirements:

The basic requirement is to be able to do RDMA to/from
VM memory, with support for VM migration and/or memory
overcommit and/or autonuma and/or THP.
Why are migration/overcommit/autonuma required?
Without these, you can do RDMA with device passthrough,
with likely better performance.

Feature Non-requirements:

It's not a requirement to support RDMA without VM exits,
e.g. like with device passthrough. While avoiding exits improves
performance, it would be handy to more than RDMA,
so there seems no reason to require it from RDMA when we
do not have it for e.g. network.

Assumptions:

It's OK to assume specific hardware capabilities at least initially.

High level architecture:

Follows the same lines as most other virtio devices:

+---
+ 
+ guest kernel
+ ^
+-|--
+ v
+ host kernel (kvm, vhost)
+ 
+ ^
+-|--
+ v
+ 
+ host userspace (QEMU, vhost-user)
+ 
+---

Each request is forwarded by host kernel to QEMU,
that executes it using the ibverbs library.

Most of this should be implementable host-side using existing
software. However, several issues remain and would need
infrastructure changes, as outlined below.

Host-side todo list for virtio-rdma support:

- Memory registration for guest userspace.

  Register memory region verb accepts a single virtual address,
  which supplies both the on-wire key for access and the
  range of memory to access. Guest kernel turns this into a
  list of pages (e.g. by get_user_pages); when forwarded to host this
  turns into a s/g list of virtual addresses in QEMU address space.

  Suggestion: add a new verb, along the lines of ibv_register_physical,
  which splits these two parameters, accepting the on-wire VA key
  and separately a list of userspace virtual address/size pairs.

- Memory registration for guest kernels.

  Another ability used by some in-kernel users is registering all of memory.
  Ranges not actually present are never accessed - this is OK as
  kernel users are trusted. Memory hotplug changes which ranges
  are present.

  Suggestion: add some throw-away memory and map all
  non-present ranges there. Add ibv_reregister_physical_mr or similar
  API to update mappings on guest memory hotplug/unplug.

- Memory overcommit/autonuma/THP.

  This includes techniques such as swap,KSM,COW, page migration.
  All these rely on ability to move pages around without
  breaking hardware access.

  Suggestion: for hardware that supports it,
  enabling on-demand paging for all registered memory seems
  to address the issue more or less transparently to guests.
  This isn't supported by all hardware but might be
  at least a reasonable first step.

- Migration: memory tracking.

  Migration requires detecting hardware access to pages
  either on write (pre-copy) or any access (post-copy).
  Post copy just requires ODP support to work with
  userfaultfd properly.
  Pre-copy would require a write-tracking API along
  the lines of one exposed by KVM or vhost.
  Each tracked page would be write-protected (causing faults on
  hardware access) on hardware write fault is generated
  and recorded, page is made writeable.

- Migration: moving QP numbers.

  QP numbers are exposed on the wire and so must move together
  with the VM.

  Suggestion: allow specifying QP number when creating a QP.
  To avoid conflicts between multiple users, initial version can limit
  library to a single user per device. Multiple VMs can simply
  attach to distinct VFs.

- Migration: moving QP state.

  When migrating the VM, a QP has to be torn down
  on source and created on destination.
  We have to migrate e.g. the current PSN - but what
  should happen when a new packet arrives on source
  after QP has been torn down?

  Suggestion 1: move QP to a special state "suspended" and ignore
  packets, or cause source to retransmit with e.g. an out of
  resources error. Retransmit counter might need to be
  adjusted compared to what guest requested to account
  for the extra need to retransmit.
  Is there a good existing QP state that does this?

  Suggestion 2: forward packets to destination somehow.
  Might overload the fabric as we are crossing e.g.
  pci bus multiple times.

- Migration: network update

  ROCE v1 and infiniband seem to tie connections to
  hardware specific GIDs which can not be moved by software.

  Suggestion: limit migration to RoCE v2 initially.

- Migration: packet loss recovery.

  As a RoCE address moves across the network, network has
  to be updated which takes time, meanwhile packet loss seems
  to be hard to avoid.

  Suggest

[Qemu-devel] [Bug 1703506] Re: SMT not supported by QEMU on AMD Ryzen CPU

2017-07-18 Thread A S
>Please confirm what's the QEMU command-line being used (especially the
-smp and -cpu options), and check if the bug persists if using "-cpu
host".

I'm using -cpu host already, here's just the cpu and smp commands:

-cpu 
host,hv_vendor_id=whatever,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,smep=off

  
-smp 12,sockets=1,cores=6,threads=2

The extra commands are just for VGA passthrough, but the problem still
occurs with just -cpu host (plus smep=off, problems with booting with it
enabled) and the above smp setting.

I've attached host output; I'm using a Windows guest and running
msinfo32 indicates:

AMD Ryzen 1600 Six-Core Processor, 3693 Mhz, 12 Core(s), 12 Logical
Processors(s)

Suggesting that the guest is seeing the host as 12 cores, 1 thread each,
rather than 6 cores, 2 threads each.

If Linux guest information would be more helpful, I'll set up a Linux
guest as well.

** Attachment added: "Host logs"
   
https://bugs.launchpad.net/qemu/+bug/1703506/+attachment/4917236/+files/qemu-ryzen-smt-logs.tar.gz

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

Title:
  SMT not supported by QEMU on AMD Ryzen CPU

Status in QEMU:
  New

Bug description:
  HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this
  message when setting the topology to threads=2:

  qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please
  configure -smp options properly.

  Checking in a Windows 10 guest reveals that SMT is not enabled, and
  from what I understand, QEMU converts the topology from threads to
  cores internally on AMD CPUs. This appears to cause performance
  problems in the guest perhaps because programs are assuming that these
  threads are actual cores.

  Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro
  guest

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



Re: [Qemu-devel] [PATCH v2 00/45] tcg: support for multiple TCG contexts

2017-07-18 Thread Richard Henderson

On 07/18/2017 02:22 PM, jiang.bi...@zte.com.cn wrote:
Seeing your work on multiple TCG, it seems that it has some kind of connection 
with the  MTTCG feature,


but I do not figure out how they are connected in detail.

Could you pls help to confirm the following questions:

 1.

what is the relationship between your patches and the MTTCG feature
mentioned by https://lwn.net/Articles/697265/?



The current MTTCG feature is in QEMU mainline.  It allows parallel execution of 
translated code in both system mode.  It does *not* allow parallel translation 
-- all translation is done with tb_lock held.


Note that we *always* have parallel execution in user mode.  However, this can 
and does lead to problems.  See below.


This patch set allows parallel translation in system mode.  This is shown to 
improve the overall throughput.  It does *not* allow parallel translation in 
user mode.  Firstly because user mode already shares more translations between 
threads (because it is running a single executable), and so the translation 
routines are not high in the profile.  Secondly because there are additional 
locking problems due to the fact that we have no bound on the number of user 
threads.




 2.

What is the current status of the development of the MTTCG feature?


MTTCG has only been enabled on a few targets: alpha, arm, ppc64.
Look for "mttcg=yes" in configure.

In order for MTTCG to be enabled, the target must be adjusted so that
(1) all atomic instructions are implemented with atomic tcg operations,
(2) define TCG_GUEST_DEFAULT_MO to indicate any barriers implied by
normal memory operations by the target architecture.

For target/mips, neither of these things are complete.

MTTCG has only been enabled on one host: i386.
Look for TCG_TARGET_DEFAULT_MO in tcg/*/tcg-target.h.

In order for MTTCG to be enabled, the target memory order must not be stronger 
than the host memory order.  Since i386 has a very strong host memory order, it 
is easy for it to emulate any guest.  When the host has a weak memory order, we 
need to add the additional barriers that are implied by the target.  This is 
work that has not been done.


I am not sure why we have not already added this definition to all of the other 
tcg hosts.  I think this is just oversight, since almost everyone uses x86_64 
linux as the host for testing tcg.  However, since all of the supported targets 
have weak memory orders we ought to be able to support them with any host.




 3.

Is there any problem with the multithread programme running with linux-user
qemu mode? would the situation be improved with  the MTTCG feature?

We need to use linux-user mode qemu to run multithread app, but there seems
to be many problem.


For user mode, we should still follow the rules for MTTCG, but we do not. 
Instead we take it on faith that they have been and execute the code in 
parallel anyway.  This faith is often misplaced and it does mean that 
unsupported targets execute user mode code incorrectly.



r~



Re: [Qemu-devel] [PATCH] Update references of "struct ucontext" to "ucontext_t"

2017-07-18 Thread Nathaniel McCallum
Yes, it is a dup. Sorry for the noise.

On Tue, Jul 18, 2017 at 9:03 PM, Eric Blake  wrote:
> On 07/18/2017 07:58 PM, Nathaniel McCallum wrote:
>> Glibc used to have:
>>
>>typedef struct ucontext { ... } ucontext_t;
>>
>> Glibc now has:
>>
>>typedef struct ucontext_t { ... } ucontext_t;
>>
>> However, Qemu used "struct ucontext" in declarations. This is a
>> private name and compatiblity cannot be guaranteed. This patch
>> updates Qemu to only use the standardized type name.
>>
>> Signed-off-by: Nathaniel McCallum 
>> ---
>
> Looks like this duplicates:
> https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06508.html
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>



Re: [Qemu-devel] [PATCH] replace struct ucontext with ucontext_t type

2017-07-18 Thread Eric Blake
On 06/29/2017 09:09 AM, Laurent Vivier wrote:

> ...
>> diff --git a/linux-user/signal.c b/linux-user/signal.c
>> index 3d18d1b3ee..2c55a4f600 100644
>> --- a/linux-user/signal.c
>> +++ b/linux-user/signal.c
>> @@ -3346,7 +3346,7 @@ static void setup_rt_frame(int sig, struct 
>> target_sigaction *ka,
>>  *
>>  *   a0 = signal number
>>  *   a1 = pointer to siginfo_t
>> -*   a2 = pointer to struct ucontext
>> +*   a2 = pointer to ucontext_t
>>  *
>>  * $25 and PC point to the signal handler, $29 points to the
>>  * struct sigframe.
>> @@ -3733,7 +3733,7 @@ struct target_signal_frame {
>>  
>>  struct rt_signal_frame {
>>  siginfo_t info;
>> -struct ucontext uc;
>> +ucontext_t uc;
>>  uint32_t tramp[2];
>>  };
>>  
>> @@ -3949,7 +3949,7 @@ struct rt_signal_frame {
>>  siginfo_t *pinfo;
>>  void *puc;
>>  siginfo_t info;
>> -struct ucontext uc;
>> +ucontext_t uc;
>>  uint16_t retcode[4];  /* Trampoline code. */
>>  };
>>  
> 
> I think these two rt_signal_frame are unused and can be removed.

Sounds like a separate patch, though.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] replace struct ucontext with ucontext_t type

2017-07-18 Thread Eric Blake
On 06/29/2017 08:18 AM, Daniel P. Berrange wrote:
> On Thu, Jun 29, 2017 at 10:05:13AM +0100, Peter Maydell wrote:
>> On 28 June 2017 at 21:44, Khem Raj  wrote:
>>> The ucontext_t type had a tag struct ucontext until now
>>> but newer glibc will drop it so we need to adjust and use
>>> the exposed type instead
>>
>> If true this seems like a bug in glibc to break
>> existing working programs, and it should be fixed there...
> 
> The glib commit message indicates it is intentional change, in order
> to get POSIX compliance:
> 
>   
> https://sourceware.org/git/?p=glibc.git;a=commit;h=251287734e89a52da3db682a8241eb6bccc050c9
> 
> NB, other parts of QEMU like the coroutine code are already
> using the 'ucontext_t' typedef, so attaining consistency across
> files is good regardless of the glibc change.

I agree. And since the issue has been reposted, I support the fix,
although Nathaniel's repost may have the better commit message.
https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg06005.html

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] Update references of "struct ucontext" to "ucontext_t"

2017-07-18 Thread Eric Blake
On 07/18/2017 07:58 PM, Nathaniel McCallum wrote:
> Glibc used to have:
> 
>typedef struct ucontext { ... } ucontext_t;
> 
> Glibc now has:
> 
>typedef struct ucontext_t { ... } ucontext_t;
> 
> However, Qemu used "struct ucontext" in declarations. This is a
> private name and compatiblity cannot be guaranteed. This patch
> updates Qemu to only use the standardized type name.
> 
> Signed-off-by: Nathaniel McCallum 
> ---

Looks like this duplicates:
https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06508.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH] Update references of "struct ucontext" to "ucontext_t"

2017-07-18 Thread Nathaniel McCallum
Glibc used to have:

   typedef struct ucontext { ... } ucontext_t;

Glibc now has:

   typedef struct ucontext_t { ... } ucontext_t;

However, Qemu used "struct ucontext" in declarations. This is a
private name and compatiblity cannot be guaranteed. This patch
updates Qemu to only use the standardized type name.

Signed-off-by: Nathaniel McCallum 
---
 linux-user/host/aarch64/hostdep.h |  2 +-
 linux-user/host/arm/hostdep.h |  2 +-
 linux-user/host/i386/hostdep.h|  2 +-
 linux-user/host/ppc64/hostdep.h   |  2 +-
 linux-user/host/s390x/hostdep.h   |  2 +-
 linux-user/host/x86_64/hostdep.h  |  2 +-
 linux-user/signal.c   | 10 +-
 tests/tcg/test-i386.c |  4 ++--
 user-exec.c   | 18 +-
 9 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/linux-user/host/aarch64/hostdep.h
b/linux-user/host/aarch64/hostdep.h
index 64f75cef49..a8d41a21ad 100644
--- a/linux-user/host/aarch64/hostdep.h
+++ b/linux-user/host/aarch64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 __u64 *pcreg = &uc->uc_mcontext.pc;

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/arm/hostdep.h b/linux-user/host/arm/hostdep.h
index 5c1ae60120..9276fe6ceb 100644
--- a/linux-user/host/arm/hostdep.h
+++ b/linux-user/host/arm/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 unsigned long *pcreg = &uc->uc_mcontext.arm_pc;

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/i386/hostdep.h b/linux-user/host/i386/hostdep.h
index d834bd80ea..073be74d87 100644
--- a/linux-user/host/i386/hostdep.h
+++ b/linux-user/host/i386/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 greg_t *pcreg = &uc->uc_mcontext.gregs[REG_EIP];

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/ppc64/hostdep.h b/linux-user/host/ppc64/hostdep.h
index 0b0f5f7821..98979ad917 100644
--- a/linux-user/host/ppc64/hostdep.h
+++ b/linux-user/host/ppc64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 unsigned long *pcreg = &uc->uc_mcontext.gp_regs[PT_NIP];

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/s390x/hostdep.h b/linux-user/host/s390x/hostdep.h
index 6f9da9c608..4f0171f36f 100644
--- a/linux-user/host/s390x/hostdep.h
+++ b/linux-user/host/s390x/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 unsigned long *pcreg = &uc->uc_mcontext.psw.addr;

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/host/x86_64/hostdep.h b/linux-user/host/x86_64/hostdep.h
index 3b4259633e..a4fefb5114 100644
--- a/linux-user/host/x86_64/hostdep.h
+++ b/linux-user/host/x86_64/hostdep.h
@@ -24,7 +24,7 @@ extern char safe_syscall_end[];
 /* Adjust the signal context to rewind out of safe-syscall if we're in it */
 static inline void rewind_if_in_safe_syscall(void *puc)
 {
-struct ucontext *uc = puc;
+ucontext_t *uc = puc;
 greg_t *pcreg = &uc->uc_mcontext.gregs[REG_RIP];

 if (*pcreg > (uintptr_t)safe_syscall_start
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 3d18d1b3ee..2c55a4f600 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -3346,7 +3346,7 @@ static void setup_rt_frame(int sig, struct
target_sigaction *ka,
 *
 *   a0 = signal number
 *   a1 = pointer to siginfo_t
-*   a2 = pointer to struct ucontext
+*   a2 = pointer to ucontext_t
 *
 * $25 and PC point to the signal handler, $29 points to the
 * struct sigframe.
@@ -3733,7 +3733,7 @@ struct target_signal_frame {

 struct rt_signal_frame {
 siginfo_t info;
-struct ucontext uc;
+ucontext_t uc;
 uint32_t tramp[2];
 };

@@ -3949,7 +3949,7 @@ struct rt_signal_frame {
 siginfo_t *pinfo;
 void *puc;
 siginfo_t info;
-struct ucontext uc;
+ucontext_t uc;
 uint16_t retcode[4];  /* Trampoline code. */
 };

@@ -4484,7 +4484,7 @@ static void setup_rt_frame(int sig, struct
target_sigactio

Re: [Qemu-devel] Hacks for building on gcc 7 / Fedora 26

2017-07-18 Thread Eric Blake
On 07/18/2017 06:59 PM, Richard Henderson wrote:

>> +++ w/hw/usb/bus.c
>> @@ -407,8 +407,9 @@ void usb_register_companion(const char *masterbus,
>> USBPort *ports[],
>>   void usb_port_location(USBPort *downstream, USBPort *upstream, int
>> portnr)
>>   {
>>   if (upstream) {
>> -snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
>> - upstream->path, portnr);
>> +int l = snprintf(downstream->path, sizeof(downstream->path),
>> "%s.%d",
>> + upstream->path, portnr);
>> +assert(l < sizeof(downstream->path));
> 
> Do you really need an assert there, or will
> 
> (void)l; /* "used" */
> 
> work as well?  You didn't mention what the reported error is, so I'm
> guessing.

The original error is that gcc 7 complains that snprintf is prone to
buffer overflow if the input is unbounded.  Adding the assert that we
KNOW the input is not unbounded is enough to shut up gcc, on Linux.
What was then drawn into question is whether assert still has that
property on mingw (since assert on mingw lacks the noreturn marking that
it has on Linux).

At this point, unless someone posts an actual failure of gcc 7 compiling
this code for mingw, I don't see why we have to change it; shutting up
the warning on Linux is good enough for the purpose of this patch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 1/2] vfio/ccw: allocate irq info with the right size

2017-07-18 Thread Dong Jia Shi
* Cornelia Huck  [2017-07-18 11:07:49 +0200]:

> On Tue, 18 Jul 2017 16:49:43 +0800
> Dong Jia Shi  wrote:
> 
> > * Cornelia Huck  [2017-07-18 10:32:13 +0200]:
> > 
> > > On Tue, 18 Jul 2017 03:49:25 +0200
> > > Dong Jia Shi  wrote:
> > >   
> > > > From: Jing Zhang 
> > > > 
> > > > When allocating memory for the vfio_irq_info parameter of the
> > > > VFIO_DEVICE_GET_IRQ_INFO ioctl, we used the wrong size. Let's
> > > > fix it by using the right size.
> > > > 
> > > > Reviewed-by: Dong Jia Shi 
> > > > Signed-off-by: Jing Zhang 
> > > > Signed-off-by: Dong Jia Shi 
> > > > ---
> > > >  hw/vfio/ccw.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> > > > index 12d0262336..8d97b53e77 100644
> > > > --- a/hw/vfio/ccw.c
> > > > +++ b/hw/vfio/ccw.c
> > > > @@ -168,7 +168,7 @@ static void 
> > > > vfio_ccw_register_io_notifier(VFIOCCWDevice *vcdev, Error **errp)
> > > >  return;
> > > >  }
> > > >  
> > > > -argsz = sizeof(*irq_set);
> > > > +argsz = sizeof(*irq_info);
> > > >  irq_info = g_malloc0(argsz);
> > > >  irq_info->index = VFIO_CCW_IO_IRQ_INDEX;
> > > >  irq_info->argsz = argsz;  
> > > 
> > > irq_set is larger than irq_info, but yes, let's do this correctly.
> > > 
> > > Out of curiosity, how did you spot this?
> > >   
> > 
> > I'm trying to reuse the code here, while introducing some new MMIO
> > regions, which you will see them some days later. ;>
> > 
> 
> Looking forward to that :)
> 

If they are lucky enough to survive the internal review to meet you.
haha.




Re: [Qemu-devel] [PATCH v2 00/45] tcg: support for multiple TCG contexts

2017-07-18 Thread jiang.biao2
Hi,

Seeing your work on multiple TCG, it seems that it has some kind of connection 
with the  MTTCG feature,

but I do not figure out how they are connected in detail.

Could you pls help to confirm the following questions:

what is the relationship between your patches and the MTTCG feature mentioned 
by https://lwn.net/Articles/697265/?

What is the current status of the development of the MTTCG feature?

Is
 there any problem with the multithread programme running with 
linux-user qemu mode? would the situation be improved with  the MTTCG 
feature?

We need to use linux-user mode qemu to run multithread app, but there seems to 
be many problem.





Thanks a lot.

Re: [Qemu-devel] [PATCH 02/29] pci: remove superfluous parenthesis

2017-07-18 Thread Richard Henderson

On 07/17/2017 08:09 PM, Philippe Mathieu-Daudé wrote:

  #define IOTEST_TEST(i) (iotest_test[((i) % ARRAY_SIZE(iotest_test))])
  #define IOTEST_TYPE(i) (iotest_type[((i) / ARRAY_SIZE(iotest_test))])


Looks like  array[(x)] is another candidate.


-#define IOTEST_MAX_TEST (ARRAY_SIZE(iotest_test))
-#define IOTEST_MAX_TYPE (ARRAY_SIZE(iotest_type))
+#define IOTEST_MAX_TEST ARRAY_SIZE(iotest_test)
+#define IOTEST_MAX_TYPE ARRAY_SIZE(iotest_type)



r~



Re: [Qemu-devel] [PATCH 4/4] target/i386: Don't use x86_cpu_load_def() on "max" CPU model

2017-07-18 Thread Eduardo Habkost
On Tue, Jul 18, 2017 at 03:27:26PM +0200, Igor Mammedov wrote:
> On Wed, 12 Jul 2017 13:20:58 -0300
> Eduardo Habkost  wrote:
> 
> > When commit 0bacd8b3046f ('i386: Don't set CPUClass::cpu_def on
> > "max" model') removed the CPUClass::cpu_def field, we kept using
> > the x86_cpu_load_def() helper directly in max_x86_cpu_initfn(),
> > emulating the previous behavior when CPUClass::cpu_def was set.
> > 
> > However, x86_cpu_load_def() is intended to help initialization of
> > CPU models from the builtin_x86_defs table, and does lots of
> > other steps that are not necessary for "max".
> > 
> > One of the things x86_cpu_load_def() do is to set the properties
> > listed at tcg_default_props/kvm_default_props.  We must not do
> > that on the "max" CPU model, otherwise under KVM we will
> > incorrectly report all KVM features as always available, and the
> > "svm" feature as always unavailable.  The latter caused the bug
> > reported at:
> Maybe add that all available features for 'max' are set later at realize() 
> time
> to ones actually supported by host.

I can add the following paragraph to the commit message.  Is it
enough to get your Reviewed-by?

target/i386: Don't use x86_cpu_load_def() on "max" CPU model

When commit 0bacd8b3046f ('i386: Don't set CPUClass::cpu_def on
"max" model') removed the CPUClass::cpu_def field, we kept using
the x86_cpu_load_def() helper directly in max_x86_cpu_initfn()
because it allowed us to reuse the old max_x86_cpu_class_init()
code.

However, the only X86CPUDefinition fields we really use are
vendor/family/model/stepping/model-id, and x86_cpu_load_def()
tries to do other stuff that is only necessary when using named
CPU models from builtin_x86_defs.

One of the things x86_cpu_load_def() do is to set the properties
listed at kvm_default_props.  We must not do that on "max" and
"host" CPU models, otherwise we will incorrectly report all KVM
features as always available, and incorrectly report the "svm"
feature as always unavailable under KVM.  The latter caused the
bug reported at:

  https://bugzilla.redhat.com/show_bug.cgi?id=1467599
  ("Unable to start domain: the CPU is incompatible with host CPU:
  Host CPU does not provide required features: svm")

Replace x86_cpu_load_def() with simple object_property_set*()
calls.  In addition to fixing the above bug, this makes the KVM
code very similar to the TCG code inside max_x86_cpu_initfn().

+   For reference, the full list of steps performed by
+   x86_cpu_load_def() is:
+   
+   * Setting min-level and min-xlevel.  Already done by
+ max_x86_cpu_initfn().
+   * Setting family/model/stepping/model-id.  Done by the code added
+ to max_x86_cpu_initfn() in this patch.
+   * Copying def->features.  Wrong because "-cpu max" features need to
+ be calculated at realize time.  This was not a problem in the
+ current code because host_cpudef.features was all zeroes.
+   * x86_cpu_apply_props() calls.  This causes the bug above, and
+ shouldn't be done.
+   * Setting CPUID_EXT_HYPERVISOR.  Not needed because it is already
+ reported by x86_cpu_get_supported_feature_word(), and because
+ "-cpu max" features need to be calculated at realize time.
+   * Setting CPU vendor to host CPU vendor if on KVM mode.
+ Redundant, because max_x86_cpu_initfn() already sets it to the
+ host CPU vendor.
+
Signed-off-by: Eduardo Habkost 

> 
> Also while looking at it, I've noticed that:
> x86_cpu_load_def()
>   ...
>   if (kvm_enabled()) {
>  
> if (!kvm_irqchip_in_kernel()) {   
>
> x86_cpu_change_kvm_default("x2apic", "off");  
>
> }
> 
> and
> 
> kvm_arch_get_supported_cpuid() also having
> if (!kvm_irqchip_in_kernel()) {   
>
> ret &= ~CPUID_EXT_X2APIC; 
>
> } 
> 
> so do we really need this duplication in x86_cpu_load_def()?

Those two pieces of code represent two different rules:

The first encodes the fact that we won't try to enable x2apic by
default if !kvm_irqchip_in_kernel().  It is required so we don't
get spurious "feature x2apic is unavailable" warnings (or fatal
errors if in enforce mode).

The second encodes the fact that we can't enable x2apic if
!kvm_irqchip_in_kernel().  It is required so we block the user
from enabling x2apic manually on the command-line.

It's true that the first rule is a direct consequence of the
second rule.  We could figure out a mechanism to make the code
for the second rule trigger the first rule automatically, but I'm
not sure it would be worth the extra complexity.  (And it's out
of the scope of this patch).

> 
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1467599
> >   ("Unable to start doma

Re: [Qemu-devel] Hacks for building on gcc 7 / Fedora 26

2017-07-18 Thread Richard Henderson

On 07/17/2017 03:48 AM, Eric Blake wrote:

On 07/17/2017 08:42 AM, Eric Blake wrote:

On 07/13/2017 08:07 AM, Philippe Mathieu-Daudé wrote:

On 04/07/2017 04:21 PM, Philippe Mathieu-Daudé wrote:

Hi Dave,

On 04/07/2017 11:38 AM, Dr. David Alan Gilbert wrote:

Hi,
Fedora 26 has gcc 7.0.1 which has the normal compliment
of new fussy warnings; so far I've posted :

tests/check-qdict: Fix missing brackets
slirp/smb: Replace constant strings by glib string

that fix one actual mistake and work around something it's being
fussy over.

But I've also got a pile of hacks, attached below that I'm
not too sure what I'll do with them yet, but they're attached


ping ... What do we do with them?


Well, now that I've upgraded to the just-released Fedora 26, it is now
mainline gcc and affecting my builds.  So we should really try and find
patches that silence the warnings (although it counts as bug fixes, so
it won't hurt if it doesn't make tomorrow's freeze deadline).


FWIW, most of these have been fixed in the meantime; the only remaining
hack I had to add was:

diff --git i/hw/usb/bus.c w/hw/usb/bus.c
index 5939b273b9..bce011058b 100644
--- i/hw/usb/bus.c
+++ w/hw/usb/bus.c
@@ -407,8 +407,9 @@ void usb_register_companion(const char *masterbus,
USBPort *ports[],
  void usb_port_location(USBPort *downstream, USBPort *upstream, int portnr)
  {
  if (upstream) {
-snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
- upstream->path, portnr);
+int l = snprintf(downstream->path, sizeof(downstream->path),
"%s.%d",
+ upstream->path, portnr);
+assert(l < sizeof(downstream->path));


Do you really need an assert there, or will

(void)l; /* "used" */

work as well?  You didn't mention what the reported error is, so I'm guessing.


r~



Re: [Qemu-devel] [PATCH v2 10/45] translate-all: guarantee that tb_hash only holds valid TBs

2017-07-18 Thread Richard Henderson

On 07/18/2017 01:30 PM, Emilio G. Cota wrote:

Should I do those updates in the same patch where tb->invalid is brought
over to cflags? Alternatives: have a later patch where all readers
are converted to atomic_read, or keep tb->invalid as a separate field (we
could use that 4-byte hole in struct tb_tc..)


I would prefer the readers be converted in a separate patch.
I wonder if an accessor inline might be in order?

static inline uint32_t tb_cflags(TranslationBlock *tb)
{
return atomic_read(tb->cflags);
}

That might keep line lengths from expanding too much...

Please don't try to do anything clever to re-use padding holes.
I think that's just confusing and probably premature optimization.


r~




Re: [Qemu-devel] [PATCH v2 10/45] translate-all: guarantee that tb_hash only holds valid TBs

2017-07-18 Thread Emilio G. Cota
On Mon, Jul 17, 2017 at 19:29:57 -1000, Richard Henderson wrote:
> On 07/17/2017 06:54 PM, Emilio G. Cota wrote:
> >What threw me off was that in lookup_tb_ptr we're not checking tb->invalid,
> >and that biased me into thinking that it's not needed. But I should have
> >tried harder. Also, that's a bug, and yet another reason to have tb_lookup,
> >so that we fix these things at once in one place.
> 
> Yes, me as well.  Quite right we need only one copy of this code.
> 
> >> (tb->flags & (CF_HASH_MASK | CF_INVALID)) == cf_mask
> >>
> >>So that we continue to check CF_INVALID each time we lookup a TB, but now we
> >>get it for free as a part of the other flags check.
> >
> >With the annoying atomic_read thrown in there :-) but yes, will do.
> 
> Yes of course.  ;-)

Gaah, we'll need to update all readers of tb->cflags, of which we have
plenty (~145, mostly in target code) to avoid C11 undefined behaviour
and make Paolo happy.

Should I do those updates in the same patch where tb->invalid is brought
over to cflags? Alternatives: have a later patch where all readers
are converted to atomic_read, or keep tb->invalid as a separate field (we
could use that 4-byte hole in struct tb_tc..)

E.



Re: [Qemu-devel] [PATCH v2] hmp: allow cpu index for "info lapic"

2017-07-18 Thread Eduardo Habkost
On Tue, Jul 18, 2017 at 04:54:17PM +0200, Igor Mammedov wrote:
> On Mon, 17 Jul 2017 21:49:37 -0400
> Yi Wang  wrote:
> 
> > Add [vcpu] index support for hmp command "info lapic", which is
> > useful when debugging ipi and so on. Current behavior is not
> > changed when the parameter isn't specified.
> we shouldn't expose cpu_index to users anymore,
> 
> I would suggest using to use real APIC ID here but we don't
> have monitor command that returns APIC IDs for present cpus.
> 
> "info hotpluggable-cpus" gives you a list of available CPUs
> it also gives you qom_path to cpu so potentially you could
> read apic-id property of cpu.
> 
> But we have only QMP variant of qom-get so monitor needs
> addition of qom-get command that will be a wrapper around
> QMP command.
> 
> It could be solved in 2 ways:
>  * use socket-id/core-id/thread-id to specify desired cpu
>/possible values in 'info hotpluggable-cpus'/
> 
>  * use apic-id value to specify interrupt controller
>- apic-id could be retrieved with new qom-get
>  (qom-get would also be useful to read other properties)
>- extend 'info registers' with apic id value
> for example instead of current:
> 
>  CPU#1
>  EAX=0c06 EBX= ECX=02ff EDX=
>  
> 
> it would look like:
> 
>  CPU#1 (socket-id: a, core-id: b, thread-id: c, apic-id: d)
>  ...

We already print "CPU #" on "info cpus", so  is already a
perfectly good identifier for a human interface.  I think HMP
should not require any identifier that isn't a simple number that
is shown very prominently on "info cpus".

If we don't want to use cpu_index as an identifier anymore, we
can start printing arch ID instead of cpu_index on commands that
print "CPU #", and change mon_get_cpu() and monitor_set_cpu()
accordingly.

-- 
Eduardo



Re: [Qemu-devel] [PATCH v2] hmp: allow cpu index for "info lapic"

2017-07-18 Thread Eduardo Habkost
On Mon, Jul 17, 2017 at 09:49:37PM -0400, Yi Wang wrote:
> Add [vcpu] index support for hmp command "info lapic", which is
> useful when debugging ipi and so on. Current behavior is not
> changed when the parameter isn't specified.
> 
> Signed-off-by: Yi Wang 
> Signed-off-by: Yun Liu 

We have 8 monitor commands (see below) that use the CPU set by
the "cpu" command (mon_get_cpu()) as input.  Why is "info lapic"
special?

* info cpustats
* info lapic
* info mem
* info registers
* info tlb
* x
* memsave
* inject-nmi (QMP)

-- 
Eduardo



Re: [Qemu-devel] [PULL 00/31] target/sh4 queue

2017-07-18 Thread Aurelien Jarno
On 2017-07-18 15:40, no-re...@patchew.org wrote:
> Hi,
> 
> This series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.
> 
> Subject: [Qemu-devel] [PULL 00/31] target/sh4 queue
> Message-id: 20170718215050.3812-1-aurel...@aurel32.net
> Type: series
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> set -e
> git submodule update --init dtc
> # Let docker tests dump environment info
> export SHOW_ENV=1
> export J=8
> time make docker-test-quick@centos6
> time make docker-test-build@min-glib
> time make docker-test-mingw@fedora
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> Switched to a new branch 'test'
> 3d16bb6 target/sh4: Use tcg_gen_lookup_and_goto_ptr
> 34df079 target/sh4: Implement fsrra
> ad2bb72 target/sh4: Add missing FPSCR.PR == 0 checks
> f7cf869 target/sh4: Implement fpchg
> 3ab5d19 target/sh4: Introduce CHECK_SH4A
> 3bb62bf target/sh4: Introduce CHECK_FPSCR_PR_*
> 907bcb9 target/sh4: Tidy misc illegal insn checks
> 04ed6b8 target/sh4: Unify code for CHECK_FPU_ENABLED
> 328fcad target/sh4: Unify code for CHECK_PRIVILEGED
> ed53477 target/sh4: Unify code for CHECK_NOT_DELAY_SLOT
> 7d9efde target/sh4: Simplify 64-bit fp reg-reg move
> 5386355 target/sh4: Load/store Dr as 64-bit quantities
> e542610 target/sh4: Merge DREG into fpr64 routines
> e74ac3e6 target/sh4: Eliminate unused XREG macro
> c1c6ee6 target/sh4: Hoist fp register bank selection
> d1b7466 target/sh4: Pass DisasContext to fpr64 routines
> bb17467 target/sh4: Unify cpu_fregs into FREG
> 6db404a target/sh4: Hoist register bank selection
> 0a0f12e linux-user/sh4: Clean env->flags on signal boundaries
> 2f7995c linux-user/sh4: Notice gUSA regions during signal delivery
> e532ba6 target/sh4: Recognize common gUSA sequences
> f47b13f target/sh4: Handle user-space atomics
> eb123e9 target/sh4: Adjust TB_FLAG_PENDING_MOVCA
> 1c3e6c5 target/sh4: Keep env->flags clean
> ae99c5a target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK
> 3f61bea target/sh4: Consolidate end-of-TB tests
> a4421f7 target/sh4: return result of fcmp using TCG
> 30390ef target/sh4: do not use a helper to implement fneg
> 8011852 target/sh4: fix FPSCR cause vs flag inversion
> 70f6b8e target/sh4: fix FPU unorderered compare
> a11e1bf target/sh4: do not check for PR bit for fabs instruction
> 
> === OUTPUT BEGIN ===
> Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
> Cloning into '/var/tmp/patchew-tester-tmp-8b_0jeat/src/dtc'...
> Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
>   BUILD   centos6
> make[1]: Entering directory '/var/tmp/patchew-tester-tmp-8b_0jeat/src'
>   ARCHIVE qemu.tgz
>   ARCHIVE dtc.tgz
>   COPYRUNNER
> RUN test-quick in qemu:centos6 
> Packages installed:
> SDL-devel-1.2.14-7.el6_7.1.x86_64
> bison-2.4.1-5.el6.x86_64
> ccache-3.1.6-2.el6.x86_64
> epel-release-6-8.noarch
> flex-2.5.35-9.el6.x86_64
> gcc-4.4.7-18.el6.x86_64
> git-1.7.1-8.el6.x86_64
> glib2-devel-2.28.8-9.el6.x86_64
> libfdt-devel-1.4.0-1.el6.x86_64
> make-3.81-23.el6.x86_64
> package g++ is not installed
> pixman-devel-0.32.8-1.el6.x86_64
> tar-1.23-15.el6_8.x86_64
> zlib-devel-1.2.3-29.el6.x86_64
> 
> Environment variables:
> PACKAGES=libfdt-devel ccache tar git make gcc g++ flex bison 
> zlib-devel glib2-devel SDL-devel pixman-devel epel-release
> HOSTNAME=47eb202b620f
> TERM=xterm
> MAKEFLAGS= -j8
> HISTSIZE=1000
> J=8
> USER=root
> CCACHE_DIR=/var/tmp/ccache
> EXTRA_CONFIGURE_OPTS=
> V=
> SHOW_ENV=1
> MAIL=/var/spool/mail/root
> PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/
> LANG=en_US.UTF-8
> TARGET_LIST=
> HISTCONTROL=ignoredups
> SHLVL=1
> HOME=/root
> TEST_DIR=/tmp/qemu-test
> LOGNAME=root
> LESSOPEN=||/usr/bin/lesspipe.sh %s
> FEATURES= dtc
> DEBUG=
> G_BROKEN_FILENAMES=1
> CCACHE_HASHDIR=
> _=/usr/bin/env
> 
> Configure options:
> --enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
> --prefix=/var/tmp/qemu-build/install
> No C++ compiler available; disabling C++ specific optional code
> Install prefix/var/tmp/qemu-build/install
> BIOS directory/var/tmp/qemu-build/install/share/qemu
> binary directory  /var/tmp/qemu-build/install/bin
> library directory /var/tmp/qemu-build/install/lib
> module directory  /var/tmp/qemu-build/install/lib/qemu
> libexec directory /var/tmp/qemu-build/install/libexec
> include directory /var/tmp/qemu-build/install/include
> config directory  /var/tmp/qemu-build/install/etc
> local state directory   /var/tmp/qemu-build/install/var
> Manual directory  /var/tmp/qemu-build/install/share/man
> ELF interp prefix /usr/gnemul/qemu-%M
> Source path   /tmp/qemu-test/src
> C compilercc
> Host C compiler   cc
> C++ compiler  
> Objective-C compiler cc
> ARFLAGS   rv
> CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
> QEMU_CFLAG

Re: [Qemu-devel] [PULL 00/31] target/sh4 queue

2017-07-18 Thread Aurelien Jarno
On 2017-07-18 15:42, no-re...@patchew.org wrote:
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Subject: [Qemu-devel] [PULL 00/31] target/sh4 queue
> Message-id: 20170718215050.3812-1-aurel...@aurel32.net
> Type: series
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> 
> BASE=base
> n=1
> total=$(git log --oneline $BASE.. | wc -l)
> failed=0
> 
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> 
> commits="$(git log --format=%H --reverse $BASE..)"
> for c in $commits; do
> echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
> if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; 
> then
> failed=1
> echo
> fi
> n=$((n+1))
> done
> 
> exit $failed
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
>  - [tag update]  patchew/20170717101632.23247-1-kra...@redhat.com -> 
> patchew/20170717101632.23247-1-kra...@redhat.com
> Switched to a new branch 'test'
> 3d16bb6 target/sh4: Use tcg_gen_lookup_and_goto_ptr
> 34df079 target/sh4: Implement fsrra
> ad2bb72 target/sh4: Add missing FPSCR.PR == 0 checks
> f7cf869 target/sh4: Implement fpchg
> 3ab5d19 target/sh4: Introduce CHECK_SH4A
> 3bb62bf target/sh4: Introduce CHECK_FPSCR_PR_*
> 907bcb9 target/sh4: Tidy misc illegal insn checks
> 04ed6b8 target/sh4: Unify code for CHECK_FPU_ENABLED
> 328fcad target/sh4: Unify code for CHECK_PRIVILEGED
> ed53477 target/sh4: Unify code for CHECK_NOT_DELAY_SLOT
> 7d9efde target/sh4: Simplify 64-bit fp reg-reg move
> 5386355 target/sh4: Load/store Dr as 64-bit quantities
> e542610 target/sh4: Merge DREG into fpr64 routines
> e74ac3e6 target/sh4: Eliminate unused XREG macro
> c1c6ee6 target/sh4: Hoist fp register bank selection
> d1b7466 target/sh4: Pass DisasContext to fpr64 routines
> bb17467 target/sh4: Unify cpu_fregs into FREG
> 6db404a target/sh4: Hoist register bank selection
> 0a0f12e linux-user/sh4: Clean env->flags on signal boundaries
> 2f7995c linux-user/sh4: Notice gUSA regions during signal delivery
> e532ba6 target/sh4: Recognize common gUSA sequences
> f47b13f target/sh4: Handle user-space atomics
> eb123e9 target/sh4: Adjust TB_FLAG_PENDING_MOVCA
> 1c3e6c5 target/sh4: Keep env->flags clean
> ae99c5a target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK
> 3f61bea target/sh4: Consolidate end-of-TB tests
> a4421f7 target/sh4: return result of fcmp using TCG
> 30390ef target/sh4: do not use a helper to implement fneg
> 8011852 target/sh4: fix FPSCR cause vs flag inversion
> 70f6b8e target/sh4: fix FPU unorderered compare
> a11e1bf target/sh4: do not check for PR bit for fabs instruction
> 
> === OUTPUT BEGIN ===
> Checking PATCH 1/31: target/sh4: do not check for PR bit for fabs 
> instruction...
> Checking PATCH 2/31: target/sh4: fix FPU unorderered compare...
> Checking PATCH 3/31: target/sh4: fix FPSCR cause vs flag inversion...
> Checking PATCH 4/31: target/sh4: do not use a helper to implement fneg...
> Checking PATCH 5/31: target/sh4: return result of fcmp using TCG...
> Checking PATCH 6/31: target/sh4: Consolidate end-of-TB tests...
> Checking PATCH 7/31: target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK...
> Checking PATCH 8/31: target/sh4: Keep env->flags clean...
> Checking PATCH 9/31: target/sh4: Adjust TB_FLAG_PENDING_MOVCA...
> Checking PATCH 10/31: target/sh4: Handle user-space atomics...
> Checking PATCH 11/31: target/sh4: Recognize common gUSA sequences...
> ERROR: braces {} are necessary for all arms of this statement
> #62: FILE: target/sh4/translate.c:1919:
> +do { if (i >= max_insns) goto fail; ctx->opcode = insns[i++]; } while (0)
> [...]
> 
> ERROR: space prohibited after that '*' (ctx:WxW)
> #184: FILE: target/sh4/translate.c:2041:
> +if (pc + (i + 1 + B7_0s) * 2 != pc_end) {
>   ^
> 
> ERROR: space prohibited after that '*' (ctx:WxW)
> #216: FILE: target/sh4/translate.c:2073:
> +|| pc + (i + 1 + B7_0s) * 2 != pc_end) {
>  ^
> 
> total: 3 errors, 0 warnings, 337 lines checked
> 
> Your patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> Checking PATCH 12/31: linux-user/sh4: Notice gUSA regions during signal 
> delivery...
> Checking PATCH 13/31: linux-user/sh4: Clean env->flags on signal boundaries...
> Checking PATCH 14/31: target/sh4: Hoist register bank selection...
> Checking PATCH 15/31: target/sh4: Unify cpu_fregs into FREG...
> Checking PATCH 16/31: target/sh4: Pass DisasContext to fpr64 routines...
> Checking PATCH 17/31: target/sh4: Hoist fp register bank selection...
> Checking PATCH 18/31: target/sh4: Eliminate unused XREG macro...
> Checking PATCH 19/31: target/sh4: Merge DREG into fpr64 routines...
> Checking PATCH 20/31: target/sh4: Load/store Dr as 64-bit quantitie

[Qemu-devel] windows qemu can't be debuged

2017-07-18 Thread tim3385
Hello, all:

I have compiled qemu in cygwin with mingw according to the qemu wiki. When I 
debug it with GDB, I get the error below:

.
Type "apropos word" to search for commands related to "word"...
Reading symbols from qemu-system-x86_64.exe...done.
(gdb) r -cdrom /t.iso -boot d -display sdl
Starting program: 
/cygdrive/c/emulator/mqemu/bin/debug/i686-w64-mingw32/x86_64-softmmu/qemu-system-x86_64.exe
 -cdrom /t.iso -boot d -display sdl
[New Thread 11372.0x26c8]
warning: `/cygdrive/c/windows/SYSTEM32/ntdll.dll': Shared library architecture 
i386:x86-64 is not compatible with target architecture i386.
warning: `/cygdrive/c/windows/System32/wow64.dll': Shared library architecture 
i386:x86-64 is not compatible with target architecture i386.
warning: `/cygdrive/c/windows/System32/wow64win.dll': Shared library 
architecture i386:x86-64 is not compatible with target architecture i386.
warning: dll path for "WOW64_IMAGE_SECTION" can not be evaluated
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "WOW64_IMAGE_SECTION" can not be evaluated
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "NOT_AN_IMAGE" can not be evaluated
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "NOT_AN_IMAGE" can not be evaluated
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: `/cygdrive/c/windows/System32/wow64cpu.dll': Shared library 
architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 11372.0x4110]
[New Thread 11372.0x1b84]
[New Thread 11372.0x1064]
[Thread 11372.0x1064 exited with code 3221225781]
[Thread 11372.0x1b84 exited with code 3221225781]
[Inferior 1 (process 11372) exited with code 03000465]

Somebody can help me? thanks.

ps. My build shell script is:
PWD="/emulator/qemu-2.9.0"

# Don't build in the QEMU source directory. Using a subdirectory is better.
# Here is an example of a debug build.
SRC_PATH=$PWD
BUILD_DIR="$PWD/bin/debug/i686-w64-mingw32"
mkdir -p $BUILD_DIR

cd $BUILD_DIR
echo -n "s1) Build folder has been created. Enter "
pwd

CMD="$SRC_PATH/configure \
--enable-debug \
--cross-prefix=i686-w64-mingw32- \
--host-cc=i686-w64-mingw32-gcc \
--enable-trace-backend=simple \
"

echo -e "s2) $CMD\n.."
$CMD

echo "s3) Make.."
make

best
Dong Hao
Sent from YoMail for Gmail

Re: [Qemu-devel] [PULL 00/31] target/sh4 queue

2017-07-18 Thread no-reply
Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PULL 00/31] target/sh4 queue
Message-id: 20170718215050.3812-1-aurel...@aurel32.net
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20170717101632.23247-1-kra...@redhat.com -> 
patchew/20170717101632.23247-1-kra...@redhat.com
Switched to a new branch 'test'
3d16bb6 target/sh4: Use tcg_gen_lookup_and_goto_ptr
34df079 target/sh4: Implement fsrra
ad2bb72 target/sh4: Add missing FPSCR.PR == 0 checks
f7cf869 target/sh4: Implement fpchg
3ab5d19 target/sh4: Introduce CHECK_SH4A
3bb62bf target/sh4: Introduce CHECK_FPSCR_PR_*
907bcb9 target/sh4: Tidy misc illegal insn checks
04ed6b8 target/sh4: Unify code for CHECK_FPU_ENABLED
328fcad target/sh4: Unify code for CHECK_PRIVILEGED
ed53477 target/sh4: Unify code for CHECK_NOT_DELAY_SLOT
7d9efde target/sh4: Simplify 64-bit fp reg-reg move
5386355 target/sh4: Load/store Dr as 64-bit quantities
e542610 target/sh4: Merge DREG into fpr64 routines
e74ac3e6 target/sh4: Eliminate unused XREG macro
c1c6ee6 target/sh4: Hoist fp register bank selection
d1b7466 target/sh4: Pass DisasContext to fpr64 routines
bb17467 target/sh4: Unify cpu_fregs into FREG
6db404a target/sh4: Hoist register bank selection
0a0f12e linux-user/sh4: Clean env->flags on signal boundaries
2f7995c linux-user/sh4: Notice gUSA regions during signal delivery
e532ba6 target/sh4: Recognize common gUSA sequences
f47b13f target/sh4: Handle user-space atomics
eb123e9 target/sh4: Adjust TB_FLAG_PENDING_MOVCA
1c3e6c5 target/sh4: Keep env->flags clean
ae99c5a target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK
3f61bea target/sh4: Consolidate end-of-TB tests
a4421f7 target/sh4: return result of fcmp using TCG
30390ef target/sh4: do not use a helper to implement fneg
8011852 target/sh4: fix FPSCR cause vs flag inversion
70f6b8e target/sh4: fix FPU unorderered compare
a11e1bf target/sh4: do not check for PR bit for fabs instruction

=== OUTPUT BEGIN ===
Checking PATCH 1/31: target/sh4: do not check for PR bit for fabs instruction...
Checking PATCH 2/31: target/sh4: fix FPU unorderered compare...
Checking PATCH 3/31: target/sh4: fix FPSCR cause vs flag inversion...
Checking PATCH 4/31: target/sh4: do not use a helper to implement fneg...
Checking PATCH 5/31: target/sh4: return result of fcmp using TCG...
Checking PATCH 6/31: target/sh4: Consolidate end-of-TB tests...
Checking PATCH 7/31: target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK...
Checking PATCH 8/31: target/sh4: Keep env->flags clean...
Checking PATCH 9/31: target/sh4: Adjust TB_FLAG_PENDING_MOVCA...
Checking PATCH 10/31: target/sh4: Handle user-space atomics...
Checking PATCH 11/31: target/sh4: Recognize common gUSA sequences...
ERROR: braces {} are necessary for all arms of this statement
#62: FILE: target/sh4/translate.c:1919:
+do { if (i >= max_insns) goto fail; ctx->opcode = insns[i++]; } while (0)
[...]

ERROR: space prohibited after that '*' (ctx:WxW)
#184: FILE: target/sh4/translate.c:2041:
+if (pc + (i + 1 + B7_0s) * 2 != pc_end) {
  ^

ERROR: space prohibited after that '*' (ctx:WxW)
#216: FILE: target/sh4/translate.c:2073:
+|| pc + (i + 1 + B7_0s) * 2 != pc_end) {
 ^

total: 3 errors, 0 warnings, 337 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 12/31: linux-user/sh4: Notice gUSA regions during signal 
delivery...
Checking PATCH 13/31: linux-user/sh4: Clean env->flags on signal boundaries...
Checking PATCH 14/31: target/sh4: Hoist register bank selection...
Checking PATCH 15/31: target/sh4: Unify cpu_fregs into FREG...
Checking PATCH 16/31: target/sh4: Pass DisasContext to fpr64 routines...
Checking PATCH 17/31: target/sh4: Hoist fp register bank selection...
Checking PATCH 18/31: target/sh4: Eliminate unused XREG macro...
Checking PATCH 19/31: target/sh4: Merge DREG into fpr64 routines...
Checking PATCH 20/31: target/sh4: Load/store Dr as 64-bit quantities...
Checking PATCH 21/31: target/sh4: Simplify 64-bit fp reg-reg move...
Checking PATCH 22/31: target/sh4: Unify code for CHECK_NOT_DELAY_SLOT...
Checking PATCH 23/31: target/sh4: Unify code for CHECK_PRIVILEGED...
Checking PATCH 24/31: target/sh4: Unify code for CHECK_FPU_ENABLE

Re: [Qemu-devel] [PULL 00/31] target/sh4 queue

2017-07-18 Thread no-reply
Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] [PULL 00/31] target/sh4 queue
Message-id: 20170718215050.3812-1-aurel...@aurel32.net
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-build@min-glib
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3d16bb6 target/sh4: Use tcg_gen_lookup_and_goto_ptr
34df079 target/sh4: Implement fsrra
ad2bb72 target/sh4: Add missing FPSCR.PR == 0 checks
f7cf869 target/sh4: Implement fpchg
3ab5d19 target/sh4: Introduce CHECK_SH4A
3bb62bf target/sh4: Introduce CHECK_FPSCR_PR_*
907bcb9 target/sh4: Tidy misc illegal insn checks
04ed6b8 target/sh4: Unify code for CHECK_FPU_ENABLED
328fcad target/sh4: Unify code for CHECK_PRIVILEGED
ed53477 target/sh4: Unify code for CHECK_NOT_DELAY_SLOT
7d9efde target/sh4: Simplify 64-bit fp reg-reg move
5386355 target/sh4: Load/store Dr as 64-bit quantities
e542610 target/sh4: Merge DREG into fpr64 routines
e74ac3e6 target/sh4: Eliminate unused XREG macro
c1c6ee6 target/sh4: Hoist fp register bank selection
d1b7466 target/sh4: Pass DisasContext to fpr64 routines
bb17467 target/sh4: Unify cpu_fregs into FREG
6db404a target/sh4: Hoist register bank selection
0a0f12e linux-user/sh4: Clean env->flags on signal boundaries
2f7995c linux-user/sh4: Notice gUSA regions during signal delivery
e532ba6 target/sh4: Recognize common gUSA sequences
f47b13f target/sh4: Handle user-space atomics
eb123e9 target/sh4: Adjust TB_FLAG_PENDING_MOVCA
1c3e6c5 target/sh4: Keep env->flags clean
ae99c5a target/sh4: Introduce TB_FLAG_ENVFLAGS_MASK
3f61bea target/sh4: Consolidate end-of-TB tests
a4421f7 target/sh4: return result of fcmp using TCG
30390ef target/sh4: do not use a helper to implement fneg
8011852 target/sh4: fix FPSCR cause vs flag inversion
70f6b8e target/sh4: fix FPU unorderered compare
a11e1bf target/sh4: do not check for PR bit for fabs instruction

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-8b_0jeat/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-8b_0jeat/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
git-1.7.1-8.el6.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ flex bison zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=47eb202b620f
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -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 -fn

[Qemu-devel] [PULL for-2.10 7/7] xen: don't use xenstore to save/restore physmap anymore

2017-07-18 Thread Stefano Stabellini
From: Igor Druzhinin 

If we have a system with xenforeignmemory_map2() implemented
we don't need to save/restore physmap on suspend/restore
anymore. In case we resume a VM without physmap - try to
recreate the physmap during memory region restore phase and
remap map cache entries accordingly. The old code is left
for compatibility reasons.

Signed-off-by: Igor Druzhinin 
Reviewed-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/i386/xen/xen-hvm.c   | 48 ++---
 hw/i386/xen/xen-mapcache.c  |  4 +++-
 include/hw/xen/xen_common.h |  1 +
 3 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 277919e..d9ccd5d 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -288,6 +288,7 @@ static XenPhysmap *get_physmapping(XenIOState *state,
 return NULL;
 }
 
+#ifdef XEN_COMPAT_PHYSMAP
 static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
ram_addr_t size, void 
*opaque)
 {
@@ -333,6 +334,12 @@ static int xen_save_physmap(XenIOState *state, XenPhysmap 
*physmap)
 }
 return 0;
 }
+#else
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+return 0;
+}
+#endif
 
 static int xen_add_to_physmap(XenIOState *state,
   hwaddr start_addr,
@@ -367,6 +374,26 @@ go_physmap:
 DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
 start_addr, start_addr + size);
 
+mr_name = memory_region_name(mr);
+
+physmap = g_malloc(sizeof(XenPhysmap));
+
+physmap->start_addr = start_addr;
+physmap->size = size;
+physmap->name = mr_name;
+physmap->phys_offset = phys_offset;
+
+QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+/* Now when we have a physmap entry we can replace a dummy mapping with
+ * a real one of guest foreign memory. */
+uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size);
+assert(p && p == memory_region_get_ram_ptr(mr));
+
+return 0;
+}
+
 pfn = phys_offset >> TARGET_PAGE_BITS;
 start_gpfn = start_addr >> TARGET_PAGE_BITS;
 for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -381,17 +408,6 @@ go_physmap:
 }
 }
 
-mr_name = memory_region_name(mr);
-
-physmap = g_malloc(sizeof (XenPhysmap));
-
-physmap->start_addr = start_addr;
-physmap->size = size;
-physmap->name = mr_name;
-physmap->phys_offset = phys_offset;
-
-QLIST_INSERT_HEAD(&state->physmap, physmap, list);
-
 xc_domain_pin_memory_cacheattr(xen_xc, xen_domid,
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
@@ -1157,6 +1173,7 @@ static void xen_exit_notifier(Notifier *n, void *data)
 xs_daemon_close(state->xenstore);
 }
 
+#ifdef XEN_COMPAT_PHYSMAP
 static void xen_read_physmap(XenIOState *state)
 {
 XenPhysmap *physmap = NULL;
@@ -1204,6 +1221,11 @@ static void xen_read_physmap(XenIOState *state)
 }
 free(entries);
 }
+#else
+static void xen_read_physmap(XenIOState *state)
+{
+}
+#endif
 
 static void xen_wakeup_notifier(Notifier *notifier, void *data)
 {
@@ -1330,7 +1352,11 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 state->bufioreq_local_port = rc;
 
 /* Init RAM management */
+#ifdef XEN_COMPAT_PHYSMAP
 xen_map_cache_init(xen_phys_offset_to_gaddr, state);
+#else
+xen_map_cache_init(NULL, state);
+#endif
 xen_ram_init(pcms, ram_size, ram_memory);
 
 qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 56986db..2a1fbd1 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -239,7 +239,7 @@ static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr, 
hwaddr size,
 hwaddr address_offset;
 hwaddr cache_size = size;
 hwaddr test_bit_size;
-bool translated = false;
+bool translated G_GNUC_UNUSED = false;
 bool dummy = false;
 
 tryagain:
@@ -307,11 +307,13 @@ tryagain:
 test_bit_size >> XC_PAGE_SHIFT,
 entry->valid_mapping)) {
 mapcache->last_entry = NULL;
+#ifdef XEN_COMPAT_PHYSMAP
 if (!translated && mapcache->phys_offset_to_gaddr) {
 phys_addr = mapcache->phys_offset_to_gaddr(phys_addr, size, 
mapcache->opaque);
 translated = true;
 goto tryagain;
 }
+#endif
 if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
 dummy = true;
 goto tryagain;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index e28ed48..86c7f26 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -80,6 +80,7 @@ extern xenforeignmemory_handle *x

[Qemu-devel] [PULL for-2.10 6/7] xen/mapcache: introduce xen_replace_cache_entry()

2017-07-18 Thread Stefano Stabellini
From: Igor Druzhinin 

This new call is trying to update a requested map cache entry
according to the changes in the physmap. The call is searching
for the entry, unmaps it and maps again at the same place using
a new guest address. If the mapping is dummy this call will
make it real.

This function makes use of a new xenforeignmemory_map2() call
with an extended interface that was recently introduced in
libxenforeignmemory [1].

[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html

Signed-off-by: Igor Druzhinin 
Reviewed-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 configure | 18 +
 hw/i386/xen/xen-mapcache.c| 85 +++
 include/hw/xen/xen_common.h   | 14 +++
 include/sysemu/xen-mapcache.h | 11 +-
 4 files changed, 119 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index e8798ce..bad50f5 100755
--- a/configure
+++ b/configure
@@ -2107,6 +2107,24 @@ EOF
 # Xen unstable
 elif
 cat > $TMPC <
+int main(void) {
+  xenforeignmemory_handle *xfmem;
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+
+  return 0;
+}
+EOF
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+  then
+  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+  xen_ctrl_version=41000
+  xen=yes
+elif
+cat > $TMPC <
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 39cb511..56986db 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void 
*opaque)
 }
 
 static void xen_remap_bucket(MapCacheEntry *entry,
+ void *vaddr,
  hwaddr size,
  hwaddr address_index,
  bool dummy)
@@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 err = g_malloc0(nb_pfn * sizeof (int));
 
 if (entry->vaddr_base != NULL) {
-ram_block_notify_remove(entry->vaddr_base, entry->size);
+if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
+ram_block_notify_remove(entry->vaddr_base, entry->size);
+}
 if (munmap(entry->vaddr_base, entry->size) != 0) {
 perror("unmap fails");
 exit(-1);
@@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 }
 
 if (!dummy) {
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
-   PROT_READ | PROT_WRITE,
+vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
+   PROT_READ | PROT_WRITE, 0,
nb_pfn, pfns, err);
 if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
+perror("xenforeignmemory_map2");
 exit(-1);
 }
 } else {
@@ -193,7 +196,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
  * We create dummy mappings where we are unable to create a foreign
  * mapping immediately due to certain circumstances (i.e. on resume 
now)
  */
-vaddr_base = mmap(NULL, size, PROT_READ | PROT_WRITE,
+vaddr_base = mmap(vaddr, size, PROT_READ | PROT_WRITE,
   MAP_ANON | MAP_SHARED, -1, 0);
 if (vaddr_base == NULL) {
 perror("mmap");
@@ -201,6 +204,10 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 }
 }
 
+if (!(entry->flags & XEN_MAPCACHE_ENTRY_DUMMY)) {
+ram_block_notify_add(vaddr_base, size);
+}
+
 entry->vaddr_base = vaddr_base;
 entry->paddr_index = address_index;
 entry->size = size;
@@ -213,7 +220,6 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
 }
 
-ram_block_notify_add(entry->vaddr_base, entry->size);
 bitmap_zero(entry->valid_mapping, nb_pfn);
 for (i = 0; i < nb_pfn; i++) {
 if (!err[i]) {
@@ -286,14 +292,14 @@ tryagain:
 if (!entry) {
 entry = g_malloc0(sizeof (MapCacheEntry));
 pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
 } else if (!entry->lock) {
 if (!entry->vaddr_base || entry->paddr_index != address_index ||
 entry->size != cache_size ||
 !test_bits(address_offset >> XC_PAGE_SHIFT,
 test_bit_size >> XC_PAGE_SHIFT,
 entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
 }
 }
 
@@ -490,3 +496,66 @@ void xen_invalidate_map_cache(void)
 
 mapcache_unlock();
 }

[Qemu-devel] [PULL for-2.10 3/7] xen-platform: separate unplugging of NVMe disks

2017-07-18 Thread Stefano Stabellini
Commit 090fa1c8 "add support for unplugging NVMe disks..." extended the
existing disk unplug flag to cover NVMe disks as well as IDE and SCSI.

The recent thread on the xen-devel mailing list [1] has highlighted that
this is not desirable behaviour: PV frontends should be able to distinguish
NVMe disks from other types of disk and should have separate control over
whether they are unplugged.

This patch defines a new bit in the unplug mask for this purpose (see Xen
commit [2]) and also tidies up the definitions of, and improves the
comments regarding, the previously exiting bits in the protocol.

[1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg02924.html
[2] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1096aa02

Signed-off-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/i386/xen/xen_platform.c | 47 ++
 1 file changed, 35 insertions(+), 12 deletions(-)

diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index f231558..9ba7474 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -87,10 +87,30 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 }
 }
 
-/* Xen Platform, Fixed IOPort */
-#define UNPLUG_ALL_DISKS 1
-#define UNPLUG_ALL_NICS 2
-#define UNPLUG_AUX_IDE_DISKS 4
+/*
+ * Unplug device flags.
+ *
+ * The logic got a little confused at some point in the past but this is
+ * what they do now.
+ *
+ * bit 0: Unplug all IDE and SCSI disks.
+ * bit 1: Unplug all NICs.
+ * bit 2: Unplug IDE disks except primary master. This is overridden if
+ *bit 0 is also present in the mask.
+ * bit 3: Unplug all NVMe disks.
+ *
+ */
+#define _UNPLUG_IDE_SCSI_DISKS 0
+#define UNPLUG_IDE_SCSI_DISKS (1u << _UNPLUG_IDE_SCSI_DISKS)
+
+#define _UNPLUG_ALL_NICS 1
+#define UNPLUG_ALL_NICS (1u << _UNPLUG_ALL_NICS)
+
+#define _UNPLUG_AUX_IDE_DISKS 2
+#define UNPLUG_AUX_IDE_DISKS (1u << _UNPLUG_AUX_IDE_DISKS)
+
+#define _UNPLUG_NVME_DISKS 3
+#define UNPLUG_NVME_DISKS (1u << _UNPLUG_NVME_DISKS)
 
 static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
@@ -122,7 +142,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void 
*opaque)
 {
 uint32_t flags = *(uint32_t *)opaque;
 bool aux = (flags & UNPLUG_AUX_IDE_DISKS) &&
-!(flags & UNPLUG_ALL_DISKS);
+!(flags & UNPLUG_IDE_SCSI_DISKS);
 
 /* We have to ignore passthrough devices */
 if (!strcmp(d->name, "xen-pci-passthrough")) {
@@ -135,12 +155,16 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void 
*opaque)
 break;
 
 case PCI_CLASS_STORAGE_SCSI:
-case PCI_CLASS_STORAGE_EXPRESS:
 if (!aux) {
 object_unparent(OBJECT(d));
 }
 break;
 
+case PCI_CLASS_STORAGE_EXPRESS:
+if (flags & UNPLUG_NVME_DISKS) {
+object_unparent(OBJECT(d));
+}
+
 default:
 break;
 }
@@ -158,10 +182,9 @@ static void platform_fixed_ioport_writew(void *opaque, 
uint32_t addr, uint32_t v
 switch (addr) {
 case 0: {
 PCIDevice *pci_dev = PCI_DEVICE(s);
-/* Unplug devices.  Value is a bitmask of which devices to
-   unplug, with bit 0 the disk devices, bit 1 the network
-   devices, and bit 2 the non-primary-master IDE devices. */
-if (val & (UNPLUG_ALL_DISKS | UNPLUG_AUX_IDE_DISKS)) {
+/* Unplug devices. See comment above flag definitions */
+if (val & (UNPLUG_IDE_SCSI_DISKS | UNPLUG_AUX_IDE_DISKS |
+   UNPLUG_NVME_DISKS)) {
 DPRINTF("unplug disks\n");
 pci_unplug_disks(pci_dev->bus, val);
 }
@@ -349,14 +372,14 @@ static void xen_platform_ioport_writeb(void *opaque, 
hwaddr addr,
  * If VMDP was to control both disk and LAN it would use 4.
  * If it controlled just disk or just LAN, it would use 8 below.
  */
-pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS);
+pci_unplug_disks(pci_dev->bus, UNPLUG_IDE_SCSI_DISKS);
 pci_unplug_nics(pci_dev->bus);
 }
 break;
 case 8:
 switch (val) {
 case 1:
-pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS);
+pci_unplug_disks(pci_dev->bus, UNPLUG_IDE_SCSI_DISKS);
 break;
 case 2:
 pci_unplug_nics(pci_dev->bus);
-- 
1.9.1




[Qemu-devel] [PULL for-2.10 5/7] xen/mapcache: add an ability to create dummy mappings

2017-07-18 Thread Stefano Stabellini
From: Igor Druzhinin 

Dummys are simple anonymous mappings that are placed instead
of regular foreign mappings in certain situations when we need
to postpone the actual mapping but still have to give a
memory region to QEMU to play with.

This is planned to be used for restore on Xen.

Signed-off-by: Igor Druzhinin 
Reviewed-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
---
 hw/i386/xen/xen-mapcache.c | 44 
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index e60156c..39cb511 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -53,6 +53,8 @@ typedef struct MapCacheEntry {
 uint8_t *vaddr_base;
 unsigned long *valid_mapping;
 uint8_t lock;
+#define XEN_MAPCACHE_ENTRY_DUMMY (1 << 0)
+uint8_t flags;
 hwaddr size;
 struct MapCacheEntry *next;
 } MapCacheEntry;
@@ -150,7 +152,8 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void 
*opaque)
 
 static void xen_remap_bucket(MapCacheEntry *entry,
  hwaddr size,
- hwaddr address_index)
+ hwaddr address_index,
+ bool dummy)
 {
 uint8_t *vaddr_base;
 xen_pfn_t *pfns;
@@ -177,11 +180,25 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 pfns[i] = (address_index << (MCACHE_BUCKET_SHIFT-XC_PAGE_SHIFT)) + i;
 }
 
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid, 
PROT_READ|PROT_WRITE,
-  nb_pfn, pfns, err);
-if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
-exit(-1);
+if (!dummy) {
+vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
+   PROT_READ | PROT_WRITE,
+   nb_pfn, pfns, err);
+if (vaddr_base == NULL) {
+perror("xenforeignmemory_map");
+exit(-1);
+}
+} else {
+/*
+ * We create dummy mappings where we are unable to create a foreign
+ * mapping immediately due to certain circumstances (i.e. on resume 
now)
+ */
+vaddr_base = mmap(NULL, size, PROT_READ | PROT_WRITE,
+  MAP_ANON | MAP_SHARED, -1, 0);
+if (vaddr_base == NULL) {
+perror("mmap");
+exit(-1);
+}
 }
 
 entry->vaddr_base = vaddr_base;
@@ -190,6 +207,12 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 entry->valid_mapping = (unsigned long *) g_malloc0(sizeof(unsigned long) *
 BITS_TO_LONGS(size >> XC_PAGE_SHIFT));
 
+if (dummy) {
+entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
+} else {
+entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
+}
+
 ram_block_notify_add(entry->vaddr_base, entry->size);
 bitmap_zero(entry->valid_mapping, nb_pfn);
 for (i = 0; i < nb_pfn; i++) {
@@ -211,6 +234,7 @@ static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr, 
hwaddr size,
 hwaddr cache_size = size;
 hwaddr test_bit_size;
 bool translated = false;
+bool dummy = false;
 
 tryagain:
 address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
@@ -262,14 +286,14 @@ tryagain:
 if (!entry) {
 entry = g_malloc0(sizeof (MapCacheEntry));
 pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
 } else if (!entry->lock) {
 if (!entry->vaddr_base || entry->paddr_index != address_index ||
 entry->size != cache_size ||
 !test_bits(address_offset >> XC_PAGE_SHIFT,
 test_bit_size >> XC_PAGE_SHIFT,
 entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
 }
 }
 
@@ -282,6 +306,10 @@ tryagain:
 translated = true;
 goto tryagain;
 }
+if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
+dummy = true;
+goto tryagain;
+}
 trace_xen_map_cache_return(NULL);
 return NULL;
 }
-- 
1.9.1




[Qemu-devel] [PULL for-2.10 2/7] xen_pt_msi.c: Check for xen_host_pci_get_* failures in xen_pt_msix_init()

2017-07-18 Thread Stefano Stabellini
From: Peter Maydell 

Check the return status of the xen_host_pci_get_* functions we call in
xen_pt_msix_init(), and fail device init if the reads failed rather than
ploughing ahead. (Spotted by Coverity: CID 777338.)

Signed-off-by: Peter Maydell 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_pt_msi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 62add06..ff9a79f 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -535,7 +535,11 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
 return -1;
 }
 
-xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+rc = xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, &control);
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_MSIX_FLAGS field\n");
+return rc;
+}
 total_entries = control & PCI_MSIX_FLAGS_QSIZE;
 total_entries += 1;
 
@@ -554,7 +558,11 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
+ XC_PAGE_SIZE - 1)
   & XC_PAGE_MASK);
 
-xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+rc = xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, &table_off);
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_MSIX_TABLE field\n");
+goto error_out;
+}
 bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
 table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
 msix->table_base = s->real_device.io_regions[bar_index].base_addr;
-- 
1.9.1




[Qemu-devel] [PULL for-2.10 4/7] xen: move physmap saving into a separate function

2017-07-18 Thread Stefano Stabellini
From: Igor Druzhinin 

Non-functional change.

Signed-off-by: Igor Druzhinin 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Paul Durrant 
---
 hw/i386/xen/xen-hvm.c | 57 ---
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 3d951a3..277919e 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -304,6 +304,36 @@ static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
 return start_addr;
 }
 
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+char path[80], value[17];
+
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+if (physmap->name) {
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+xen_domid, (uint64_t)physmap->phys_offset);
+if (!xs_write(state->xenstore, 0, path,
+  physmap->name, strlen(physmap->name))) {
+return -1;
+}
+}
+return 0;
+}
+
 static int xen_add_to_physmap(XenIOState *state,
   hwaddr start_addr,
   ram_addr_t size,
@@ -315,7 +345,6 @@ static int xen_add_to_physmap(XenIOState *state,
 XenPhysmap *physmap = NULL;
 hwaddr pfn, start_gpfn;
 hwaddr phys_offset = memory_region_get_ram_addr(mr);
-char path[80], value[17];
 const char *mr_name;
 
 if (get_physmapping(state, start_addr, size)) {
@@ -367,31 +396,7 @@ go_physmap:
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
XEN_DOMCTL_MEM_CACHEATTR_WB);
-
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-if (mr_name) {
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
-xen_domid, (uint64_t)phys_offset);
-if (!xs_write(state->xenstore, 0, path, mr_name, strlen(mr_name))) {
-return -1;
-}
-}
-
-return 0;
+return xen_save_physmap(state, physmap);
 }
 
 static int xen_remove_from_physmap(XenIOState *state,
-- 
1.9.1




[Qemu-devel] [PULL for-2.10 1/7] hw/xen: Set emu_mask for igd_opregion register

2017-07-18 Thread Stefano Stabellini
From: Xiong Zhang 

In igd passthrough environment, guest could only access opregion at the
first bootup time. Once guest shutdown, later guest couldn't access
opregion anymore.
This is because qemu set emulated guest opregion base address to host
register. Later guest get a wrong host opregion base address, and couldn't
access it anymore.

This patch set emu_mask for igd_opregion register, so guest won't set
guest opregion base address to host.

Signed-off-by: Xiong Zhang 
Acked-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/xen/xen_pt_config_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 6f18366..1f04ec5 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1535,6 +1535,7 @@ static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
 .offset = 0x0,
 .size   = 4,
 .init_val   = 0,
+.emu_mask   = 0x,
 .u.dw.read   = xen_pt_intel_opregion_read,
 .u.dw.write  = xen_pt_intel_opregion_write,
 },
-- 
1.9.1




[Qemu-devel] [PULL for-2.0 0/7] please pull xen-20170718-tag

2017-07-18 Thread Stefano Stabellini
The following changes since commit f9dada2baabb639feb988b3a564df7a06d214e18:

  Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into 
staging (2017-07-18 20:29:36 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170718-tag

for you to fetch changes up to 331b5189d756d431b1d18ae7097527ba3d3ea809:

  xen: don't use xenstore to save/restore physmap anymore (2017-07-18 14:16:52 
-0700)


Xen 2017/07/18


Igor Druzhinin (4):
  xen: move physmap saving into a separate function
  xen/mapcache: add an ability to create dummy mappings
  xen/mapcache: introduce xen_replace_cache_entry()
  xen: don't use xenstore to save/restore physmap anymore

Peter Maydell (1):
  xen_pt_msi.c: Check for xen_host_pci_get_* failures in xen_pt_msix_init()

Stefano Stabellini (1):
  xen-platform: separate unplugging of NVMe disks

Xiong Zhang (1):
  hw/xen: Set emu_mask for igd_opregion register

 configure |  18 +++
 hw/i386/xen/xen-hvm.c | 105 +++-
 hw/i386/xen/xen-mapcache.c| 121 ++
 hw/i386/xen/xen_platform.c|  47 +++-
 hw/xen/xen_pt_config_init.c   |   1 +
 hw/xen/xen_pt_msi.c   |  12 -
 include/hw/xen/xen_common.h   |  15 ++
 include/sysemu/xen-mapcache.h |  11 +++-
 8 files changed, 267 insertions(+), 63 deletions(-)



  1   2   3   4   5   6   >