Re: [RFC PATCH 37/42] gitlab-ci: Add job to test the MIPS r5900o32el target

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 6:31 AM, Thomas Huth wrote:
> On 14/02/2021 18.59, Philippe Mathieu-Daudé wrote:
>> Add a job to build the MIPS r5900o32el (linux-user) target
>> and run the TCG tests.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   .gitlab-ci.yml | 12 
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index 28a83afb914..7d7559416e3 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -622,6 +622,18 @@ build-without-default-features:
>>  
>> --target-list-exclude=arm-softmmu,i386-softmmu,mipsel-softmmu,mips64-softmmu,ppc-softmmu
>>
>>   MAKE_CHECK_ARGS: check-unit
>>   +build-r5900-user:
>> +  <<: *native_build_job_definition
>> +  variables:
>> +    IMAGE: fedora
> 
> Don't you have to use the new gentoo-mipsr5900el-cross image to get the
> cross-compiler?

Yes you are right. I split this in 2 hoping [*] we can make the TCG
testing optional (as the gentoo cross container image):

build-user-r5900:
  <<: *native_build_job_definition
  variables:
IMAGE: fedora
CONFIGURE_ARGS: --disable-tools --disable-docs --disable-blobs
--enable-debug-tcg
TARGETS: r5900o32el-linux-user
  artifacts:
expire_in: 2 days
paths:
  - build

check-user-r5900:
  <<: *native_test_job_definition
  needs:
- job: build-user-r5900
  artifacts: true
- job: mipsr5900el-gentoo-cross-container
  variables:
IMAGE: fedora
MAKE_CHECK_ARGS: run-tcg-tests-r5900o32el-linux-user

[*] currently 'needs' is limited:

  If "needs:" is set to point to a job that is not instantiated
  because of "only/except" rules or otherwise does not exist,
  the pipeline is not created and a YAML error is shown.

(See https://docs.gitlab.com/ee/ci/yaml/README.html#needs)

Regards,

Phil.



Re: [RFC PATCH 37/42] gitlab-ci: Add job to test the MIPS r5900o32el target

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 9:07 AM, Philippe Mathieu-Daudé wrote:
> On 2/15/21 6:31 AM, Thomas Huth wrote:
>> On 14/02/2021 18.59, Philippe Mathieu-Daudé wrote:
>>> Add a job to build the MIPS r5900o32el (linux-user) target
>>> and run the TCG tests.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>   .gitlab-ci.yml | 12 
>>>   1 file changed, 12 insertions(+)
>>>
>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>>> index 28a83afb914..7d7559416e3 100644
>>> --- a/.gitlab-ci.yml
>>> +++ b/.gitlab-ci.yml
>>> @@ -622,6 +622,18 @@ build-without-default-features:
>>>  
>>> --target-list-exclude=arm-softmmu,i386-softmmu,mipsel-softmmu,mips64-softmmu,ppc-softmmu
>>>
>>>   MAKE_CHECK_ARGS: check-unit
>>>   +build-r5900-user:
>>> +  <<: *native_build_job_definition
>>> +  variables:
>>> +    IMAGE: fedora
>>
>> Don't you have to use the new gentoo-mipsr5900el-cross image to get the
>> cross-compiler?
> 
> Yes you are right. I split this in 2 hoping [*] we can make the TCG
> testing optional (as the gentoo cross container image):
> 
> build-user-r5900:
>   <<: *native_build_job_definition
>   variables:
> IMAGE: fedora
> CONFIGURE_ARGS: --disable-tools --disable-docs --disable-blobs
> --enable-debug-tcg
> TARGETS: r5900o32el-linux-user
>   artifacts:
> expire_in: 2 days
> paths:
>   - build
> 
> check-user-r5900:
>   <<: *native_test_job_definition
>   needs:
> - job: build-user-r5900
>   artifacts: true
> - job: mipsr5900el-gentoo-cross-container
>   variables:
> IMAGE: fedora
> MAKE_CHECK_ARGS: run-tcg-tests-r5900o32el-linux-user
> 
> [*] currently 'needs' is limited:
> 
>   If "needs:" is set to point to a job that is not instantiated
>   because of "only/except" rules or otherwise does not exist,
>   the pipeline is not created and a YAML error is shown.
> 
> (See https://docs.gitlab.com/ee/ci/yaml/README.html#needs)

I forgot to include the job results:

[build, Duration: 7 minutes 43 seconds]
https://gitlab.com/philmd/qemu/-/jobs/1029721393

[integration tests, Duration: 6 minutes 42 seconds]
https://gitlab.com/philmd/qemu/-/jobs/1029784692



Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement

2021-02-15 Thread Vitaly Kuznetsov
Igor Mammedov  writes:

>> >
>> > Please try reusing scratch CPU approach, see
>> >   kvm_arm_get_host_cpu_features()
>> > for an example. You will very likely end up with simpler series,
>> > compared to reinventing wheel.  
>> 
>> Even if I do that (and I serioulsy doubt it's going to be easier than
>> just adding two 'u64's, kvm_arm_get_host_cpu_features() alone is 200
> it does a lot more then what you need, kvm_arm_create_scratch_host_vcpu()
> which it uses will do the job and even that could be made smaller
> for hv usecase.
>
>> lines long) this is not going to give us what we need to distinguish
>> between
>> 
>> 'hv-passthrough,hv-evmcs'
>> 
>> and 
>> 
>> 'hv-passthrough'
>> 
>> when 'hv-evmcs' *is* supported by the host. When guest CPU lacks VMX we
>> don't want to enable it unless it was requested explicitly (former but
>> not the later).
> could you elaborate more on it, i.e. why do we need to distinguish and why
> do we need evmcs without VMX if user asked for it (will it be usable)
>

We need to distinguish because that would be sane.

Enlightened VMCS is an extension to VMX, it can't be used without
it. Genuine Hyper-V doesn't have a knob for enabling and disabling it,
it comes with nesting (-ExposeVirtualizationExtensions $true). When we
create a default set of Hyper-V enlightenments (either 'hv-default' or
'hv-passthrough') we should be as close as possible to genuine Hyper-V
to not create unsupported Frankenstiens which can break with any Windows
update (because nobody tested these configurations). That bein said, if
guest CPU lacks VMX it is counter-productive to expose EVMCS. However,
there is a problem with explicit enablement: what should

'hv-passthrough,hv-evmcs' option do? Just silently drop EVMCS? Doesn't
sound sane to me.

>> Moreover, instead of just adding two 'u64's we're now doing an ioctl
>> which can fail, be subject to limits,... Creating and destroying a CPU
>> is also slow. Sorry, I hardly see how this is better, maybe just from
>> 'code purity' point of view.
> readable and easy to maintain code is not a thing to neglect.

Of couse, but 'scratch CPU' idea is not a good design decision, it is an
ugly hack we should get rid of in ARM land, not try bringing it to other
architectures. Generally, KVM should allow to query all its capabilities
without the need to create a vCPU or, if not possible, we should create
'real' QEMU VCPUs and use one/all of the to query capabilities, avoiding
'scratch' because:
- Creating and destroying a vCPU makes VM startup slower, much
slower. E.g. for a single-CPU VM you're doubling the time required to
create vCPUs!
- vCPUs in KVM are quite memory consuming. Just 'struct kvm_vcpu_arch'
was something like 12kb last time I looked at it. 

I have no clue why scratch vCPUs were implemented on ARM, however, I'd
very much want us to avoid doing the same on x86. We do have use-cases
where startup time and consumed memory is important. There is a point in
limiting ioctls for security reasons (e.g. if I'm creating a single vCPU
VM I may want to limit userspace process to one and only one
KVM_CREATE_VCPU call).

Now to the code you complain about. The 'hard to read and maintain' code
is literaly this:

+static void x86_hv_feature_set(Object *obj, bool value, int feature)
+{
+X86CPU *cpu = X86_CPU(obj);
+
+if (value) {
+cpu->hyperv_features |= BIT(feature);
+cpu->hyperv_features_on |= BIT(feature);
+cpu->hyperv_features_off &= ~BIT(feature);
+} else {
+cpu->hyperv_features &= ~BIT(feature);
+cpu->hyperv_features_on &= ~BIT(feature);
+cpu->hyperv_features_off |= BIT(feature);
+}
+}

I can add as many comments here as needed, however, I don't see what
requires additional explanaition. We just want to know two things:
- What's the 'effective' setting of the control
- Was it explicitly enabled or disabled on the command line.

Custom parsers are not new in QEMU and they're not going anywhere I
believe. There are options with simple enablent and there are some with
additional considerations. Trying to make CPU objects somewhat 'special'
by forcing all options to be of type-1 (and thus crippling user
experience) is not the way to go IMHO. I'd very much like us to go in
another direction, make our option parser better so my very simple
use-case is covered 'out-of-the-box'.

-- 
Vitaly




Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement

2021-02-15 Thread Vitaly Kuznetsov
Igor Mammedov  writes:

> On Fri, 12 Feb 2021 16:26:03 +0100
> Vitaly Kuznetsov  wrote:
>
>> Vitaly Kuznetsov  writes:
>> 
>> > Igor Mammedov  writes:
>> >  
>> >>
>> >> Please try reusing scratch CPU approach, see
>> >>   kvm_arm_get_host_cpu_features()
>> >> for an example. You will very likely end up with simpler series,
>> >> compared to reinventing wheel.  
>> >
>> > Even if I do that (and I serioulsy doubt it's going to be easier than
>> > just adding two 'u64's, kvm_arm_get_host_cpu_features() alone is 200
>> > lines long) this is not going to give us what we need to distinguish
>> > between
>> >
>> > 'hv-passthrough,hv-evmcs'
>> >
>> > and 
>> >
>> > 'hv-passthrough'
>> >
>> > when 'hv-evmcs' *is* supported by the host. When guest CPU lacks VMX we
>> > don't want to enable it unless it was requested explicitly (former but
>> > not the later).  
>> 
>> ... and if for whatever reason we decide that this is also bad/not
>> needed, I can just drop patches 16-18 from the series (leaving
>> 'hv-passthrough,hv-feature=off' problem to better times).
> that's also an option,
> we would need to make sure that hv-passthrough is mutually exclusive
> with ''all'' other hv- properties to avoid above combination being
> ever (mis)used.

That's an option to finally get these patches merged, not a good option
for end users. 

'hv-passthrough,hv-feature' works today and it's useful. Should we drop
it?

'hv-passthrough/hv-default' and 'hv-passthrough/hv-default,hv-evmcs'
should give us sane results.

'hv-passthrough,hv-feature=off' is convenient.

Why droppping this all? To save 9 (nine) lines of code in the parser? 

-- 
Vitaly




Re: can surface_bits_per_pixel() for the console surface ever return anything other than 32 ?

2021-02-15 Thread Gerd Hoffmann
On Fri, Feb 12, 2021 at 06:38:16PM +, Peter Maydell wrote:
> On Thu, 11 Feb 2021 at 10:12, Gerd Hoffmann  wrote:
> >
> >   Hi,
> >
> > > I notice that as well as handling surface_bits_per_pixel()
> > > possibly returning 8, 15, 16, 24, these devices also seem to
> > > check for the possibility it returns 0 (presumably meaning
> > > "no surface" or "no surface yet" ?).
> >
> > Depends a bit on how the surface is created.
> >
> > When using host memory as backing storage (typical workflow is
> > qemu_console_resize() + qemu_console_surface() calls) bits per pixel is
> > 32 no matter what (format is PIXMAN_x8r8g8b8 to be exact).  I think this
> > is true for most if not all arm display devices.
> 
> Quick follow-up check: this is always RGB, ie is_surface_bgr()
> will always return false, right ?

Yes, always rgb (in host native byte order).

take care,
  Gerd




[PATCH] net: Use id_generate() in the network subsystem, too

2021-02-15 Thread Thomas Huth
We already got a global function called id_generate() to create unique
IDs within QEMU. Let's use it in the network subsytem, too, instead of
inventing our own ID scheme here.

Signed-off-by: Thomas Huth 
---
 include/qemu/id.h | 1 +
 net/net.c | 6 +++---
 util/id.c | 1 +
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/qemu/id.h b/include/qemu/id.h
index b55c406e69..46b759b284 100644
--- a/include/qemu/id.h
+++ b/include/qemu/id.h
@@ -5,6 +5,7 @@ typedef enum IdSubSystems {
 ID_QDEV,
 ID_BLOCK,
 ID_CHR,
+ID_NET,
 ID_MAX  /* last element, used as array size */
 } IdSubSystems;
 
diff --git a/net/net.c b/net/net.c
index fb7b7dcc25..ca30df963d 100644
--- a/net/net.c
+++ b/net/net.c
@@ -43,6 +43,7 @@
 #include "qemu/cutils.h"
 #include "qemu/config-file.h"
 #include "qemu/ctype.h"
+#include "qemu/id.h"
 #include "qemu/iov.h"
 #include "qemu/qemu-print.h"
 #include "qemu/main-loop.h"
@@ -,8 +1112,7 @@ static int net_client_init(QemuOpts *opts, bool 
is_netdev, Error **errp)
 
 /* Create an ID for -net if the user did not specify one */
 if (!is_netdev && !qemu_opts_id(opts)) {
-static int idx;
-qemu_opts_set_id(opts, g_strdup_printf("__org.qemu.net%i", idx++));
+qemu_opts_set_id(opts, id_generate(ID_NET));
 }
 
 if (visit_type_Netdev(v, NULL, &object, errp)) {
@@ -1467,7 +1467,7 @@ static int net_param_nic(void *dummy, QemuOpts *opts, 
Error **errp)
 /* Create an ID if the user did not specify one */
 nd_id = g_strdup(qemu_opts_id(opts));
 if (!nd_id) {
-nd_id = g_strdup_printf("__org.qemu.nic%i", idx);
+nd_id = id_generate(ID_NET);
 qemu_opts_set_id(opts, nd_id);
 }
 
diff --git a/util/id.c b/util/id.c
index 5addb4460e..ded41c5025 100644
--- a/util/id.c
+++ b/util/id.c
@@ -35,6 +35,7 @@ static const char *const id_subsys_str[ID_MAX] = {
 [ID_QDEV]  = "qdev",
 [ID_BLOCK] = "block",
 [ID_CHR] = "chr",
+[ID_NET] = "net",
 };
 
 /*
-- 
2.27.0




Re: [PATCH v7 03/14] block: check return value of bdrv_open_child and drop error propagation

2021-02-15 Thread Kevin Wolf
Am 13.02.2021 um 00:13 hat Eric Blake geschrieben:
> On 2/2/21 6:49 AM, Vladimir Sementsov-Ogievskiy wrote:
> > This patch is generated by cocci script:
> > 
> > @@
> > symbol bdrv_open_child, errp, local_err;
> > expression file;
> > @@
> > 
> >   file = bdrv_open_child(...,
> > -&local_err
> > +errp
> > );
> > - if (local_err)
> > + if (!file)
> >   {
> >   ...
> > - error_propagate(errp, local_err);
> >   ...
> >   }
> > 
> > with command
> > 
> > spatch --sp-file x.cocci --macro-file scripts/cocci-macro-file.h \
> > --in-place --no-show-diff --max-width 80 --use-gitgrep block
> 
> With this patch applied, 'check unit-test' fails with:
> 
> Running test test-replication
> Unexpected error in bdrv_open_driver() at ../block.c:1481:
> Could not open '/tmp/p_local_disk.z1Ugyc': Invalid argument
> ERROR test-replication - missing test plan
> 
> Directly reverting it has ripple effect on later patches in the series.
> 
> Running test-replication under gdb gives this backtrace:
> 
> Thread 1 "test-replicatio" received signal SIGABRT, Aborted.
> 0x76f6f9d5 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x76f6f9d5 in raise () from /lib64/libc.so.6
> #1  0x76f588a4 in abort () from /lib64/libc.so.6
> #2  0x556ad820 in error_handle_fatal (
> errp=0x55790568 , err=0x55859010)
> at ../util/error.c:40
> #3  0x556ae3cf in error_propagate (
> dst_errp=0x55790568 , local_err=0x55859010)
> at ../util/error.c:286
> #4  0x5558cc9e in bdrv_img_create (
> filename=0x55822500 "/tmp/p_local_disk.DVFoWt",
> fmt=0x556e809a "qcow2", base_filename=0x0, base_fmt=0x0,
> options=0x0,
> img_size=67108864, flags=2, quiet=true, errp=0x55790568
> )
> at ../block.c:6312

The problem is this hunk:

diff --git a/block/qcow2.c b/block/qcow2.c
index 5d94f45be9..e8dd42d73b 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1611,9 +1611,8 @@ static int coroutine_fn qcow2_do_open(BlockDriverState 
*bs, QDict *options,
 /* Open external data file */
 s->data_file = bdrv_open_child(NULL, options, "data-file", bs,
&child_of_bds, BDRV_CHILD_DATA,
-   true, &local_err);
-if (local_err) {
-error_propagate(errp, local_err);
+   true, errp);
+if (!s->data_file) {
 ret = -EINVAL;
 goto fail;
 }

bdrv_open_child() can return NULL in non-error cases, when the child is
optional and it isn't given. The test doesn't use an external data file,
so this returns NULL without setting an error, which now gets turned
into -EINVAL instead.

This makes the most basic tests fail with qcow2 (iotests 001 is enough).

The other hunks in this patch don't suffer from the same problem because
they pass allow_none=false.

Kevin




Re: [RFC PATCH 00/42] target/mips: Reintroduce the R5900 CPU (with more testing)

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/14/21 6:58 PM, Philippe Mathieu-Daudé wrote:
> The R5900 CPU was removed some time ago (frankly I don't remember
> why). This series add it back, but to prove it works, we also add
> testing at the end.
> 
> The main motivation is to have MIPS R5900 coverage, but to be able
> to run real world r5900 binaries, I had to implement more opcodes.
> 
> 42 patches are a lot, but 3 are already queued in linux-user-for-6.0,
> and the 11 last ones are pure testing. I suppose in next versions
> I'll split the testing patches, but to show the final objective I
> included them in here.
> 
> I tagged it RFC because some parts because:
> 
> - We'd rather not add yet another target, but we need the
>   ILP32-on-64bit ABI (o32 64-bit)
> 
> - RDHWR glibc kludge for user-mode
> 
> - Avocado patches are only here to show the final test.
>   They are useful for my set of tests, but not meant to
>   be merged in mainstream.
> 
> - gitlab jobs are only here to show the tests work.
>   If the target is ever accepted, it would go in an already
>   existing job.
> 
> I'm OK to maintain 64-bit o32 and the testing out of tree, but the
> TCG opcodes are worthwhile review for mainstream.

I forgot to mention, to debug this target with gdb (the various
multimedia opcodes are not recognized by QEMU disas).

I start QEMU listening for GDB with:

$ qemu-r5900o32el -g 1234 ...

Then start Debian's gdb-multiarch via Docker:

$ docker run -it --rm -v /tmp:/tmp -u $UID --network=host \
  registry.gitlab.com/qemu-project/qemu/qemu/debian10 \
  gdb-multiarch -q \
--ex 'set architecture mips:5900' --ex 'set endian little'
The target architecture is assumed to be mips:5900
The target is assumed to be little endian
(gdb)

Connect to QEMU on host:

(gdb) target remote 172.17.0.1:1234

Opcodes are displayed properly:

(gdb) x/20i 0x0002553c
   0x2553c: pcpyld  a1,a1,a1
   0x25540: li  a2,255
   0x25544: andit1,a0,0x7
   0x25548: beqzt1,0x255fc
   0x2554c: andit1,a0,0xf
   0x25550: lw  t0,0(a0)
   0x25554: addiu   a0,a0,4
   0x25558: pceqb   t2,t0,zero
   0x2555c: pceqb   t3,t0,a1
   0x25560: or  t4,t3,t2
   0x25564: pextlw  t4,zero,t4
   0x25568: beqzt4,0x255fc

One limitation is we can not access the upper halves of
the 128-bit general purpose registers :(
[Maybe we can but I don't know how...]

Regards,

Phil.



[PULL 03/15] travis.yml: Move the --enable-modules test to the gitlab-CI

2021-02-15 Thread Alex Bennée
From: Thomas Huth 

Simply add the flag to an existing job, no need for yet another
job here.

Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Reviewed-by: Wainer dos Santos Moschetta 
Reviewed-by: Alex Bennée 
Message-Id: <20210211045455.456371-4-th...@redhat.com>
Message-Id: <20210211122750.22645-4-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5f3d42221a..da2fad1249 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -222,6 +222,7 @@ build-system-centos:
   variables:
 IMAGE: centos8
 CONFIGURE_ARGS: --disable-nettle --enable-gcrypt --enable-fdt=system
+--enable-modules
 TARGETS: ppc64-softmmu or1k-softmmu s390x-softmmu
   x86_64-softmmu rx-softmmu sh4-softmmu nios2-softmmu
 MAKE_CHECK_ARGS: check-build
diff --git a/.travis.yml b/.travis.yml
index 533a60c130..7744ec3a2f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -131,12 +131,6 @@ jobs:
 - CONFIG="--enable-debug-tcg --disable-system"
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-debug-tcg"
 
-# Module builds are mostly of interest to major distros
-- name: "GCC modules (main-softmmu)"
-  env:
-- CONFIG="--enable-modules --target-list=${MAIN_SOFTMMU_TARGETS}"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
-
 
 # Using newer GCC with sanitizers
 - name: "GCC9 with sanitizers (softmmu)"
-- 
2.20.1




[PULL 00/15] testing and gdbstub updates

2021-02-15 Thread Alex Bennée
The following changes since commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8:

  Merge remote-tracking branch 'remotes/ericb/tags/pull-bitmaps-2021-02-12' 
into staging (2021-02-13 21:26:00 +)

are available in the Git repository at:

  https://github.com/stsquad/qemu.git tags/pull-testing-gdbstub-150221-1

for you to fetch changes up to 8886ff2844dc1a62dc4722ac65daf57c27dda2ee:

  tests/tcg: fix silent skipping of softmmu gdb tests (2021-02-15 09:38:54 
+)


testing and gdbstub updates:

  - more migration of Travis to GitLab
  - drop Travis container
  - remove last of shippable
  - clean up gdbstub MAINTAINERS
  - remove gdb_get_floatN() helpers
  - don't be quiet about skipping gdb tests


Alex Bennée (2):
  .shippable: remove the last bits
  tests/tcg: fix silent skipping of softmmu gdb tests

Daniel P. Berrangé (1):
  tests/docker: remove travis container

Peter Maydell (6):
  MAINTAINERS: Add gdbstub.h to the "GDB stub" section
  target/sh4: Drop use of gdb_get_float32() and ldfl_p()
  target/m68k: Drop use of gdb_get_float64() and ldfq_p()
  target/ppc: Drop use of gdb_get_float64() and ldfq_p()
  gdbstub: Remove unused gdb_get_float32() and gdb_get_float64()
  bswap.h: Remove unused float-access functions

Philippe Mathieu-Daudé (2):
  travis.yml: Move gprof/gcov test across to gitlab
  travis-ci: Disable C++ optional objects on AArch64 container

Thomas Huth (4):
  travis.yml: Move the -fsanitize=undefined test to the gitlab-CI
  travis.yml: Move the --enable-modules test to the gitlab-CI
  travis.yml: (Re-)move the --enable-debug jobs
  travis.yml: Move the -fsanitize=thread testing to the gitlab-CI

 docs/devel/loads-stores.rst|  14 +--
 docs/devel/testing.rst |  14 ---
 include/exec/cpu-all.h |   8 --
 include/exec/gdbstub.h |  20 
 include/qemu/bswap.h   |  60 ---
 target/m68k/helper.c   |   5 +-
 target/ppc/gdbstub.c   |   8 +-
 target/sh4/gdbstub.c   |   8 +-
 target/ppc/translate_init.c.inc|   4 +-
 .gitlab-ci.yml |  40 +++-
 .shippable.yml |  23 -
 .travis.yml| 113 +
 MAINTAINERS|   5 +-
 scripts/{travis => ci}/coverage-summary.sh |   2 +-
 tests/docker/Makefile.include  |  11 +-
 tests/docker/dockerfiles/travis.docker |  17 
 tests/docker/dockerfiles/ubuntu2004.docker |   2 +
 tests/docker/travis|  22 
 tests/docker/travis.py |  47 -
 tests/tcg/multiarch/system/Makefile.softmmu-target |   6 +-
 20 files changed, 66 insertions(+), 363 deletions(-)
 delete mode 100644 .shippable.yml
 rename scripts/{travis => ci}/coverage-summary.sh (92%)
 delete mode 100644 tests/docker/dockerfiles/travis.docker
 delete mode 100755 tests/docker/travis
 delete mode 100755 tests/docker/travis.py

-- 
2.20.1




[PULL 02/15] travis.yml: Move the -fsanitize=undefined test to the gitlab-CI

2021-02-15 Thread Alex Bennée
From: Thomas Huth 

Add it to the existing Clang job and also add a job that covers the
linux-user code with this compiler flag. To make sure that the detected
problems are not simply ignored, let's also use "-fno-sanitize-recover=..."
now instead.

Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Message-Id: <20210211045455.456371-3-th...@redhat.com>
Message-Id: <20210211122750.22645-3-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 222858b553..5f3d42221a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -432,14 +432,24 @@ build-some-softmmu-plugins:
 TARGETS: xtensa-softmmu arm-softmmu aarch64-softmmu alpha-softmmu
 MAKE_CHECK_ARGS: check-tcg
 
-build-clang:
+clang-system:
   <<: *native_build_job_definition
   variables:
 IMAGE: fedora
 CONFIGURE_ARGS: --cc=clang --cxx=clang++
+  --extra-cflags=-fsanitize=undefined 
--extra-cflags=-fno-sanitize-recover=undefined
 TARGETS: alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
-  ppc-softmmu s390x-softmmu arm-linux-user
-MAKE_CHECK_ARGS: check
+  ppc-softmmu s390x-softmmu
+MAKE_CHECK_ARGS: check-qtest check-tcg
+
+clang-user:
+  <<: *native_build_job_definition
+  variables:
+IMAGE: debian-all-test-cross
+CONFIGURE_ARGS: --cc=clang --cxx=clang++ --disable-system
+  
--target-list-exclude=microblazeel-linux-user,aarch64_be-linux-user,i386-linux-user,m68k-linux-user,mipsn32el-linux-user,xtensaeb-linux-user
+  --extra-cflags=-fsanitize=undefined 
--extra-cflags=-fno-sanitize-recover=undefined
+MAKE_CHECK_ARGS: check-unit check-tcg
 
 # These targets are on the way out
 build-deprecated:
diff --git a/.travis.yml b/.travis.yml
index 05fa1ca905..533a60c130 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -138,33 +138,6 @@ jobs:
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
 
 
-# Test with Clang for compile portability (Travis uses clang-5.0)
-- name: "Clang (user)"
-  env:
-- CONFIG="--disable-system --host-cc=clang --cxx=clang++"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-clang-default"
-  compiler: clang
-
-
-- name: "Clang (main-softmmu)"
-  env:
-- CONFIG="--target-list=${MAIN_SOFTMMU_TARGETS}
-  --host-cc=clang --cxx=clang++"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-clang-sanitize"
-  compiler: clang
-  before_script:
-- mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
-- ${SRC_DIR}/configure ${CONFIG} --extra-cflags="-fsanitize=undefined 
-Werror" || { cat config.log meson-logs/meson-log.txt && exit 1; }
-
-
-- name: "Clang (other-softmmu)"
-  env:
-- CONFIG="--disable-user --target-list-exclude=${MAIN_SOFTMMU_TARGETS}
-  --host-cc=clang --cxx=clang++"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-clang-default"
-  compiler: clang
-
-
 # Using newer GCC with sanitizers
 - name: "GCC9 with sanitizers (softmmu)"
   dist: bionic
-- 
2.20.1




[PULL 06/15] .shippable: remove the last bits

2021-02-15 Thread Alex Bennée
Shippable is about to sunset in May 2021 [1] and we had already moved
a chunk of the crossbuilds to GitLab. We already cross build
mips-softmmu targets since:

  6bcb5fc0f7 ("gitlab-ci: Add cross-compiling build tests")

and x86 is very well covered.

[1]: 
https://blog.shippable.com/the-next-step-in-the-evolution-of-shippable-jfrog-pipelines

Signed-off-by: Alex Bennée 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210211122750.22645-7-alex.ben...@linaro.org>

diff --git a/.shippable.yml b/.shippable.yml
deleted file mode 100644
index 97bfa2a0f3..00
--- a/.shippable.yml
+++ /dev/null
@@ -1,23 +0,0 @@
-language: c
-git:
-   submodules: false
-env:
-  global:
-- LC_ALL=C
-  matrix:
-- IMAGE=debian-amd64
-  TARGET_LIST=x86_64-softmmu,x86_64-linux-user
-- IMAGE=debian-mips-cross
-  TARGET_LIST=mips-softmmu
-build:
-  pre_ci_boot:
-image_name: registry.gitlab.com/qemu-project/qemu/qemu/${IMAGE}
-image_tag: latest
-pull: true
-options: "-e HOME=/root"
-  ci:
-- unset CC
-- mkdir build
-- cd build
-- ../configure --disable-docs ${QEMU_CONFIGURE_OPTS} 
--target-list=${TARGET_LIST}
-- make -j$(($(getconf _NPROCESSORS_ONLN) + 1))
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f0781b7cc..6295dfe781 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3236,12 +3236,10 @@ S: Maintained
 F: .github/lockdown.yml
 F: .travis.yml
 F: scripts/ci/
-F: .shippable.yml
 F: tests/docker/
 F: tests/vm/
 F: scripts/archive-source.sh
 W: https://travis-ci.org/qemu/qemu
-W: https://app.shippable.com/github/qemu/qemu
 W: http://patchew.org/QEMU/
 
 FreeBSD Hosted Continuous Integration
-- 
2.20.1




[PULL 01/15] travis.yml: Move gprof/gcov test across to gitlab

2021-02-15 Thread Alex Bennée
From: Philippe Mathieu-Daudé 

Similarly to commit 8cdb2cef3f1, move the gprof/gcov test to GitLab.

The coverage-summary.sh script is not Travis-CI specific, make it
generic.

[thuth: Add gcovr and bsdmainutils which are required for the
coverage-summary.sh script to the ubuntu docker file,
and use 'check' as test target]

Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Reviewed-by: Alex Bennée 
Reviewed-by: Wainer dos Santos Moschetta 
Message-Id: <20201108204535.2319870-10-phi...@redhat.com>
Message-Id: <20210211045455.456371-2-th...@redhat.com>
Message-Id: <20210211122750.22645-2-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 28a83afb91..222858b553 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -467,6 +467,18 @@ check-deprecated:
 MAKE_CHECK_ARGS: check-tcg
   allow_failure: true
 
+# gprof/gcov are GCC features
+gprof-gcov:
+  <<: *native_build_job_definition
+  variables:
+IMAGE: ubuntu2004
+CONFIGURE_ARGS: --enable-gprof --enable-gcov
+MAKE_CHECK_ARGS: check
+TARGETS: aarch64-softmmu ppc64-softmmu s390x-softmmu x86_64-softmmu
+  timeout: 70m
+  after_script:
+- ${CI_PROJECT_DIR}/scripts/ci/coverage-summary.sh
+
 build-oss-fuzz:
   <<: *native_build_job_definition
   variables:
diff --git a/.travis.yml b/.travis.yml
index 5f1dea873e..05fa1ca905 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -52,7 +52,6 @@ addons:
   - ninja-build
   - sparse
   - uuid-dev
-  - gcovr
   # Tests dependencies
   - genisoimage
 
@@ -166,20 +165,6 @@ jobs:
   compiler: clang
 
 
-# gprof/gcov are GCC features
-- name: "GCC gprof/gcov"
-  dist: bionic
-  addons:
-apt:
-  packages:
-- ninja-build
-  env:
-- CONFIG="--enable-gprof --enable-gcov --disable-libssh
-  --target-list=${MAIN_SOFTMMU_TARGETS}"
-  after_success:
-- ${SRC_DIR}/scripts/travis/coverage-summary.sh
-
-
 # Using newer GCC with sanitizers
 - name: "GCC9 with sanitizers (softmmu)"
   dist: bionic
diff --git a/MAINTAINERS b/MAINTAINERS
index de5fe1c65f..7f0781b7cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3235,7 +3235,7 @@ R: Philippe Mathieu-Daudé 
 S: Maintained
 F: .github/lockdown.yml
 F: .travis.yml
-F: scripts/travis/
+F: scripts/ci/
 F: .shippable.yml
 F: tests/docker/
 F: tests/vm/
diff --git a/scripts/travis/coverage-summary.sh b/scripts/ci/coverage-summary.sh
similarity index 92%
rename from scripts/travis/coverage-summary.sh
rename to scripts/ci/coverage-summary.sh
index d7086cf9ca..8d9fb4de40 100755
--- a/scripts/travis/coverage-summary.sh
+++ b/scripts/ci/coverage-summary.sh
@@ -3,7 +3,7 @@
 # Author: Alex Bennée 
 #
 # Summerise the state of code coverage with gcovr and tweak the output
-# to be more sane on Travis hosts. As we expect to be executed on a
+# to be more sane on CI runner. As we expect to be executed on a
 # throw away CI instance we do spam temp files all over the shop. You
 # most likely don't want to execute this script but just call gcovr
 # directly. See also "make coverage-report"
diff --git a/tests/docker/dockerfiles/ubuntu2004.docker 
b/tests/docker/dockerfiles/ubuntu2004.docker
index 8519584d2b..9750016e51 100644
--- a/tests/docker/dockerfiles/ubuntu2004.docker
+++ b/tests/docker/dockerfiles/ubuntu2004.docker
@@ -1,8 +1,10 @@
 FROM ubuntu:20.04
 ENV PACKAGES flex bison \
+bsdmainutils \
 ccache \
 clang-10\
 gcc \
+gcovr \
 genisoimage \
 gettext \
 git \
-- 
2.20.1




[PULL 05/15] travis.yml: Move the -fsanitize=thread testing to the gitlab-CI

2021-02-15 Thread Alex Bennée
From: Thomas Huth 

Use clang-10, so we can also use the --enable-tsan configure
option instead of only passing the flag via --extra-cflags.

Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Reviewed-by: Alex Bennée 
Message-Id: <20210211045455.456371-6-th...@redhat.com>
Message-Id: <20210211122750.22645-6-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e878cc0847..7adb9a4cef 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -452,6 +452,15 @@ clang-user:
   --extra-cflags=-fsanitize=undefined 
--extra-cflags=-fno-sanitize-recover=undefined
 MAKE_CHECK_ARGS: check-unit check-tcg
 
+tsan-build:
+  <<: *native_build_job_definition
+  variables:
+IMAGE: ubuntu2004
+CONFIGURE_ARGS: --enable-tsan --cc=clang-10 --cxx=clang++-10 --disable-docs
+--enable-fdt=system --enable-slirp=system
+TARGETS: x86_64-softmmu ppc64-softmmu riscv64-softmmu x86_64-linux-user
+MAKE_CHECK_ARGS: bench V=1
+
 # These targets are on the way out
 build-deprecated:
   <<: *native_build_job_definition
diff --git a/.travis.yml b/.travis.yml
index f0e2b1059c..0a4f38b9d8 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -119,57 +119,6 @@ after_script:
 jobs:
   include:
 
-
-# Using newer GCC with sanitizers
-- name: "GCC9 with sanitizers (softmmu)"
-  dist: bionic
-  addons:
-apt:
-  update: true
-  sources:
-# PPAs for newer toolchains
-- ubuntu-toolchain-r-test
-  packages:
-# Extra toolchains
-- gcc-9
-- g++-9
-# Build dependencies
-- libaio-dev
-- libattr1-dev
-- libbrlapi-dev
-- libcap-ng-dev
-- libgnutls28-dev
-- libgtk-3-dev
-- libiscsi-dev
-- liblttng-ust-dev
-- libnfs-dev
-- libncurses5-dev
-- libnss3-dev
-- libpixman-1-dev
-- libpng-dev
-- librados-dev
-- libsdl2-dev
-- libsdl2-image-dev
-- libseccomp-dev
-- libspice-protocol-dev
-- libspice-server-dev
-- liburcu-dev
-- libusb-1.0-0-dev
-- libvte-2.91-dev
-- ninja-build
-- sparse
-- uuid-dev
-  language: generic
-  compiler: none
-  env:
-- COMPILER_NAME=gcc CXX=g++-9 CC=gcc-9
-- CONFIG="--cc=gcc-9 --cxx=g++-9 --disable-linux-user"
-- TEST_CMD=""
-  before_script:
-- mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
-- ${SRC_DIR}/configure ${CONFIG} --extra-cflags="-g3 -O0 
-fsanitize=thread" || { cat config.log meson-logs/meson-log.txt && exit 1; }
-
-
 - name: "[aarch64] GCC check-tcg"
   arch: arm64
   dist: focal
-- 
2.20.1




[PULL 07/15] travis-ci: Disable C++ optional objects on AArch64 container

2021-02-15 Thread Alex Bennée
From: Philippe Mathieu-Daudé 

Travis-CI seems to have enforced memory limit on containers,
and the 'GCC check-tcg' job started to fail on AArch64 [*]:

  [2041/3679] Compiling C++ object libcommon.fa.p/disas_nanomips.cpp.o
  FAILED: libcommon.fa.p/disas_nanomips.cpp.o
  {standard input}: Assembler messages:
  {standard input}:577781: Warning: end of file not at end of a line; newline 
inserted
  {standard input}:577882: Error: unknown pseudo-op: `.lvl35769'
  {standard input}: Error: open CFI at the end of file; missing .cfi_endproc 
directive
  c++: fatal error: Killed signal terminated program cc1plus
  compilation terminated.

Until we have a replacement for this job on Gitlab-CI, disable
compilation of C++ files by forcing the c++ compiler to /bin/false
so Meson build system can not detect it:

  $ ../configure --cxx=/bin/false

  Compilation
   C compiler: cc
  Host C compiler: cc
 C++ compiler: NO

[*] https://travis-ci.org/github/qemu/qemu/jobs/757819402#L3754

Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Reviewed-by: Wainer dos Santos Moschetta 
Message-Id: <20210207121239.2288530-1-f4...@amsat.org>
Message-Id: <20210211122750.22645-8-alex.ben...@linaro.org>

diff --git a/.travis.yml b/.travis.yml
index 0a4f38b9d8..fc27fd6330 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -150,7 +150,7 @@ jobs:
   - genisoimage
   env:
 - TEST_CMD="make check check-tcg V=1"
-- CONFIG="--disable-containers --target-list=${MAIN_SOFTMMU_TARGETS}"
+- CONFIG="--disable-containers --target-list=${MAIN_SOFTMMU_TARGETS} 
--cxx=/bin/false"
 - UNRELIABLE=true
 
 - name: "[ppc64] GCC check-tcg"
-- 
2.20.1




[PULL 12/15] target/ppc: Drop use of gdb_get_float64() and ldfq_p()

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them.  We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purposes when used in places like the function
prototypes of TCG helper functions.

This means that there's no need for a special gdb_get_float64()
function to write a float64 value to the GDB protocol buffer; we can
just use gdb_get_reg64().

Similarly, for reading a value out of the GDB buffer into a float64
we can use ldq_p() and need not use ldfq_p().

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: David Gibson 
Message-Id: <20210208113428.7181-4-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-13-alex.ben...@linaro.org>

diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
index 01459dd31d..c28319fb97 100644
--- a/target/ppc/gdbstub.c
+++ b/target/ppc/gdbstub.c
@@ -130,7 +130,7 @@ int ppc_cpu_gdb_read_register(CPUState *cs, GByteArray 
*buf, int n)
 gdb_get_regl(buf, env->gpr[n]);
 } else if (n < 64) {
 /* fprs */
-gdb_get_float64(buf, *cpu_fpr_ptr(env, n - 32));
+gdb_get_reg64(buf, *cpu_fpr_ptr(env, n - 32));
 } else {
 switch (n) {
 case 64:
@@ -184,7 +184,7 @@ int ppc_cpu_gdb_read_register_apple(CPUState *cs, 
GByteArray *buf, int n)
 gdb_get_reg64(buf, env->gpr[n]);
 } else if (n < 64) {
 /* fprs */
-gdb_get_float64(buf, *cpu_fpr_ptr(env, n - 32));
+gdb_get_reg64(buf, *cpu_fpr_ptr(env, n - 32));
 } else if (n < 96) {
 /* Altivec */
 gdb_get_reg64(buf, n - 64);
@@ -241,7 +241,7 @@ int ppc_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 env->gpr[n] = ldtul_p(mem_buf);
 } else if (n < 64) {
 /* fprs */
-*cpu_fpr_ptr(env, n - 32) = ldfq_p(mem_buf);
+*cpu_fpr_ptr(env, n - 32) = ldq_p(mem_buf);
 } else {
 switch (n) {
 case 64:
@@ -291,7 +291,7 @@ int ppc_cpu_gdb_write_register_apple(CPUState *cs, uint8_t 
*mem_buf, int n)
 env->gpr[n] = ldq_p(mem_buf);
 } else if (n < 64) {
 /* fprs */
-*cpu_fpr_ptr(env, n - 32) = ldfq_p(mem_buf);
+*cpu_fpr_ptr(env, n - 32) = ldq_p(mem_buf);
 } else {
 switch (n) {
 case 64 + 32:
diff --git a/target/ppc/translate_init.c.inc b/target/ppc/translate_init.c.inc
index 3ec45cbc19..e7324e85cd 100644
--- a/target/ppc/translate_init.c.inc
+++ b/target/ppc/translate_init.c.inc
@@ -9923,7 +9923,7 @@ static int gdb_get_float_reg(CPUPPCState *env, GByteArray 
*buf, int n)
 {
 uint8_t *mem_buf;
 if (n < 32) {
-gdb_get_float64(buf, *cpu_fpr_ptr(env, n));
+gdb_get_reg64(buf, *cpu_fpr_ptr(env, n));
 mem_buf = gdb_get_reg_ptr(buf, 8);
 ppc_maybe_bswap_register(env, mem_buf, 8);
 return 8;
@@ -9941,7 +9941,7 @@ static int gdb_set_float_reg(CPUPPCState *env, uint8_t 
*mem_buf, int n)
 {
 if (n < 32) {
 ppc_maybe_bswap_register(env, mem_buf, 8);
-*cpu_fpr_ptr(env, n) = ldfq_p(mem_buf);
+*cpu_fpr_ptr(env, n) = ldq_p(mem_buf);
 return 8;
 }
 if (n == 32) {
-- 
2.20.1




[PULL 04/15] travis.yml: (Re-)move the --enable-debug jobs

2021-02-15 Thread Alex Bennée
From: Thomas Huth 

We already have similar jobs in the gitlab-CI ("build-some-softmmu" and
"build-user-plugins"), so let's switch one of them to use --enable-debug
instead of --enable-debug-tcg, then we can simply drop these jobs from
the Travis-CI.

Signed-off-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Reviewed-by: Alex Bennée 
Reviewed-by: Wainer dos Santos Moschetta 
Message-Id: <20210211045455.456371-5-th...@redhat.com>
Message-Id: <20210211122750.22645-5-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index da2fad1249..e878cc0847 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -403,7 +403,7 @@ build-some-softmmu:
   <<: *native_build_job_definition
   variables:
 IMAGE: debian-all-test-cross
-CONFIGURE_ARGS: --disable-tools --enable-debug-tcg
+CONFIGURE_ARGS: --disable-tools --enable-debug
 TARGETS: xtensa-softmmu arm-softmmu aarch64-softmmu alpha-softmmu
 MAKE_CHECK_ARGS: check-tcg
 
diff --git a/.travis.yml b/.travis.yml
index 7744ec3a2f..f0e2b1059c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -118,18 +118,6 @@ after_script:
 
 jobs:
   include:
-# --enable-debug implies --enable-debug-tcg, also runs quite a bit slower
-- name: "GCC debug (main-softmmu)"
-  env:
-- CONFIG="--enable-debug --target-list=${MAIN_SOFTMMU_TARGETS}"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-debug"
-
-
-# TCG debug can be run just on its own and is mostly agnostic to 
user/softmmu distinctions
-- name: "GCC debug (user)"
-  env:
-- CONFIG="--enable-debug-tcg --disable-system"
-- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-debug-tcg"
 
 
 # Using newer GCC with sanitizers
-- 
2.20.1




[PULL 09/15] MAINTAINERS: Add gdbstub.h to the "GDB stub" section

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

The F: patterns in the "GDB stub" section forgot gdbstub.h; add it.

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Alex Bennée 
Message-Id: <20210208113729.25170-1-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-10-alex.ben...@linaro.org>

diff --git a/MAINTAINERS b/MAINTAINERS
index 6295dfe781..8201f12271 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2340,6 +2340,7 @@ M: Alex Bennée 
 R: Philippe Mathieu-Daudé 
 S: Maintained
 F: gdbstub*
+F: include/exec/gdbstub.h
 F: gdb-xml/
 F: tests/tcg/multiarch/gdbstub/
 
-- 
2.20.1




[PULL 08/15] tests/docker: remove travis container

2021-02-15 Thread Alex Bennée
From: Daniel P. Berrangé 

The travis container that we have no longer matches what travis
currently uses. As all x86 jobs are being moved to GitLab CI too,
there is no compelling reason to update the travis container. It
is simpler to just remove it.

Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Wainer dos Santos Moschetta 
Message-Id: <20210209135011.1224992-2-berra...@redhat.com>
Message-Id: <20210211122750.22645-9-alex.ben...@linaro.org>

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 209f9d8172..00ce16de48 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -357,20 +357,6 @@ source and build it.
 
 The full list of tests is printed in the ``make docker`` help.
 
-Tools
--
-
-There are executables that are created to run in a specific Docker environment.
-This makes it easy to write scripts that have heavy or special dependencies,
-but are still very easy to use.
-
-Currently the only tool is ``travis``, which mimics the Travis-CI tests in a
-container. It runs in the ``travis`` image:
-
-.. code::
-
-  make docker-travis@travis
-
 Debugging a Docker test failure
 ---
 
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 93b29ad823..7cab761bf5 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -21,8 +21,6 @@ DOCKER_REGISTRY := $(if 
$(REGISTRY),$(REGISTRY),registry.gitlab.com/qemu-project
 DOCKER_TESTS := $(notdir $(shell \
find $(SRC_PATH)/tests/docker/ -name 'test-*' -type f))
 
-DOCKER_TOOLS := travis
-
 ENGINE := auto
 
 DOCKER_SCRIPT=$(SRC_PATH)/tests/docker/docker.py --engine $(ENGINE)
@@ -126,7 +124,7 @@ ifneq ($(HOST_ARCH),x86_64)
 DOCKER_PARTIAL_IMAGES += debian-mips-cross debian-mipsel-cross 
debian-mips64el-cross
 DOCKER_PARTIAL_IMAGES += debian-ppc64el-cross
 DOCKER_PARTIAL_IMAGES += debian-s390x-cross
-DOCKER_PARTIAL_IMAGES += fedora travis
+DOCKER_PARTIAL_IMAGES += fedora
 endif
 
 docker-image-debian-alpha-cross: docker-image-debian10
@@ -147,8 +145,6 @@ docker-image-debian-s390x-cross: docker-image-debian10
 docker-image-debian-sh4-cross: docker-image-debian10
 docker-image-debian-sparc64-cross: docker-image-debian10
 
-docker-image-travis: NOUSER=1
-
 # Specialist build images, sometimes very limited tools
 docker-image-debian-tricore-cross: docker-image-debian10
 docker-image-debian-all-test-cross: docker-image-debian10
@@ -174,7 +170,7 @@ DOCKER_PARTIAL_IMAGES += fedora-i386-cross fedora-cris-cross
 
 # Expand all the pre-requistes for each docker image and test combination
 $(foreach i,$(filter-out $(DOCKER_PARTIAL_IMAGES),$(DOCKER_IMAGES)), \
-   $(foreach t,$(DOCKER_TESTS) $(DOCKER_TOOLS), \
+   $(foreach t,$(DOCKER_TESTS), \
$(eval .PHONY: docker-$t@$i) \
$(eval docker-$t@$i: docker-image-$i docker-run-$t@$i) \
) \
@@ -212,9 +208,6 @@ endif
@echo 'Available tests:'
@echo '$(DOCKER_TESTS)'
@echo
-   @echo 'Available tools:'
-   @echo '$(DOCKER_TOOLS)'
-   @echo
@echo 'Special variables:'
@echo 'TARGET_LIST=a,b,cOverride target list in builds.'
@echo 'EXTRA_CONFIGURE_OPTS="..."'
diff --git a/tests/docker/dockerfiles/travis.docker 
b/tests/docker/dockerfiles/travis.docker
deleted file mode 100644
index cd1435a7e9..00
--- a/tests/docker/dockerfiles/travis.docker
+++ /dev/null
@@ -1,17 +0,0 @@
-#
-# Travis Image - this is broadly the same image that we run our CI
-# tests on.
-#
-FROM travisci/ci-sardonyx:packer-1552557266-f909ac5
-ENV DEBIAN_FRONTEND noninteractive
-ENV LANG en_US.UTF-8
-ENV LC_ALL en_US.UTF-8
-RUN sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
-RUN apt-get update
-RUN apt-get -y build-dep qemu
-RUN apt-get -y install device-tree-compiler python3 python3-yaml dh-autoreconf 
gdb strace lsof net-tools gcovr ninja-build
-# Travis tools require PhantomJS / Neo4j / Maven accessible
-# in their PATH (QEMU build won't access them).
-ENV PATH 
/usr/local/phantomjs/bin:/usr/local/phantomjs:/usr/local/neo4j-3.2.7/bin:/usr/local/maven-3.5.2/bin:/usr/local/cmake-3.9.2/bin:/usr/local/clang-5.0.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
-ENV FEATURES clang pyyaml docs
-USER travis
diff --git a/tests/docker/travis b/tests/docker/travis
deleted file mode 100755
index 47c03677d6..00
--- a/tests/docker/travis
+++ /dev/null
@@ -1,22 +0,0 @@
-#!/bin/bash -e
-#
-# Mimic a travis testing matrix
-#
-# Copyright (c) 2016 Red Hat Inc.
-#
-# Authors:
-#  Fam Zheng 
-#
-# This work is licensed under the terms of the GNU GPL, version 2
-# or (at your option) any later version. See the COPYING file in
-# the top-level directory.
-
-. common.rc
-
-requires pyyaml
-cmdfile=/tmp/travis_cmd_list.sh
-$QEMU_SRC/tests/docker/travis.py $QEMU_SRC/.travis.yml > $cmdfile
-chmod +x $cmdfile
-cd "$QEMU_SRC"
-unset BUILD_DIR SRC_DIR
-$cmdf

[PULL 15/15] tests/tcg: fix silent skipping of softmmu gdb tests

2021-02-15 Thread Alex Bennée
Signed-off-by: Alex Bennée 
Message-Id: <20210211122750.22645-16-alex.ben...@linaro.org>

diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target 
b/tests/tcg/multiarch/system/Makefile.softmmu-target
index 4657f6e4cf..625ed792c6 100644
--- a/tests/tcg/multiarch/system/Makefile.softmmu-target
+++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
@@ -27,5 +27,9 @@ run-gdbstub-memory: memory
--bin $< --test $(MULTIARCH_SRC)/gdbstub/memory.py, \
"softmmu gdbstub support")
 
-MULTIARCH_RUNS += run-gdbstub-memory
+else
+run-gdbstub-%:
+   $(call skip-test, "gdbstub test $*", "need working gdb")
 endif
+
+MULTIARCH_RUNS += run-gdbstub-memory
-- 
2.20.1




[PULL 13/15] gdbstub: Remove unused gdb_get_float32() and gdb_get_float64()

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

The functions gdb_get_float32() and gdb_get_float64() are now unused;
remove them.

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210208113428.7181-5-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-14-alex.ben...@linaro.org>

diff --git a/include/exec/gdbstub.h b/include/exec/gdbstub.h
index ff0b7bc45e..a024a0350d 100644
--- a/include/exec/gdbstub.h
+++ b/include/exec/gdbstub.h
@@ -135,26 +135,6 @@ static inline int gdb_get_reg128(GByteArray *buf, uint64_t 
val_hi,
 return 16;
 }
 
-static inline int gdb_get_float32(GByteArray *array, float32 val)
-{
-uint8_t buf[sizeof(CPU_FloatU)];
-
-stfl_p(buf, val);
-g_byte_array_append(array, buf, sizeof(buf));
-
-return sizeof(buf);
-}
-
-static inline int gdb_get_float64(GByteArray *array, float64 val)
-{
-uint8_t buf[sizeof(CPU_DoubleU)];
-
-stfq_p(buf, val);
-g_byte_array_append(array, buf, sizeof(buf));
-
-return sizeof(buf);
-}
-
 static inline int gdb_get_zeroes(GByteArray *array, size_t len)
 {
 guint oldlen = array->len;
-- 
2.20.1




[PULL 11/15] target/m68k: Drop use of gdb_get_float64() and ldfq_p()

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them.  We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purposes when used in places like the function
prototypes of TCG helper functions.

This means that there's no need for a special gdb_get_float64()
function to write a float64 value to the GDB protocol buffer; we can
just use gdb_get_reg64().

Similarly, for reading a value out of the GDB buffer into a float64
we can use ldq_p() and need not use ldfq_p().

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Laurent Vivier 
Message-Id: <20210208113428.7181-3-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-12-alex.ben...@linaro.org>

diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index 4185ca94ce..137a3e1a3d 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -72,8 +72,7 @@ static int cf_fpu_gdb_get_reg(CPUM68KState *env, GByteArray 
*mem_buf, int n)
 {
 if (n < 8) {
 float_status s;
-return gdb_get_float64(mem_buf,
-   floatx80_to_float64(env->fregs[n].d, &s));
+return gdb_get_reg64(mem_buf, floatx80_to_float64(env->fregs[n].d, 
&s));
 }
 switch (n) {
 case 8: /* fpcontrol */
@@ -90,7 +89,7 @@ static int cf_fpu_gdb_set_reg(CPUM68KState *env, uint8_t 
*mem_buf, int n)
 {
 if (n < 8) {
 float_status s;
-env->fregs[n].d = float64_to_floatx80(ldfq_p(mem_buf), &s);
+env->fregs[n].d = float64_to_floatx80(ldq_p(mem_buf), &s);
 return 8;
 }
 switch (n) {
-- 
2.20.1




[PULL 10/15] target/sh4: Drop use of gdb_get_float32() and ldfl_p()

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them.  We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purposes when used in places like the function
prototypes of TCG helper functions.

This means that there's no need for a special gdb_get_float32()
function to write a float32 value to the GDB protocol buffer; we can
just use gdb_get_reg32().

Similarly, for reading a value out of the GDB buffer into a float32
we can use ldl_p() and need not use ldfl_p().

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210208113428.7181-2-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-11-alex.ben...@linaro.org>

diff --git a/target/sh4/gdbstub.c b/target/sh4/gdbstub.c
index 34ad3ca050..3488f68e32 100644
--- a/target/sh4/gdbstub.c
+++ b/target/sh4/gdbstub.c
@@ -58,9 +58,9 @@ int superh_cpu_gdb_read_register(CPUState *cs, GByteArray 
*mem_buf, int n)
 return gdb_get_regl(mem_buf, env->fpscr);
 case 25 ... 40:
 if (env->fpscr & FPSCR_FR) {
-return gdb_get_float32(mem_buf, env->fregs[n - 9]);
+return gdb_get_reg32(mem_buf, env->fregs[n - 9]);
 }
-return gdb_get_float32(mem_buf, env->fregs[n - 25]);
+return gdb_get_reg32(mem_buf, env->fregs[n - 25]);
 case 41:
 return gdb_get_regl(mem_buf, env->ssr);
 case 42:
@@ -119,9 +119,9 @@ int superh_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 break;
 case 25 ... 40:
 if (env->fpscr & FPSCR_FR) {
-env->fregs[n - 9] = ldfl_p(mem_buf);
+env->fregs[n - 9] = ldl_p(mem_buf);
 } else {
-env->fregs[n - 25] = ldfl_p(mem_buf);
+env->fregs[n - 25] = ldl_p(mem_buf);
 }
 break;
 case 41:
-- 
2.20.1




[PULL 14/15] bswap.h: Remove unused float-access functions

2021-02-15 Thread Alex Bennée
From: Peter Maydell 

The float-access functions stfl_*, stfq*, ldfl* and ldfq* are now
unused; remove them.  (Accesses to float64 and float32 types can be
made with the ldl/stl/ldq/stq functions, as float64 and float32 are
guaranteed to be typedefs for normal integer types.)

Signed-off-by: Peter Maydell 
Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210208113428.7181-6-peter.mayd...@linaro.org>
Message-Id: <20210211122750.22645-15-alex.ben...@linaro.org>

diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index ee43f5dfee..568274baec 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -24,16 +24,12 @@ potentially unaligned pointer values.
 
 Function names follow the pattern:
 
-load: ``ld{type}{sign}{size}_{endian}_p(ptr)``
+load: ``ld{sign}{size}_{endian}_p(ptr)``
 
-store: ``st{type}{size}_{endian}_p(ptr, val)``
-
-``type``
- - (empty) : integer access
- - ``f`` : float access
+store: ``st{size}_{endian}_p(ptr, val)``
 
 ``sign``
- - (empty) : for 32 or 64 bit sizes (including floats and doubles)
+ - (empty) : for 32 or 64 bit sizes
  - ``u`` : unsigned
  - ``s`` : signed
 
@@ -67,8 +63,8 @@ of size ``sz`` bytes.
 
 
 Regexes for git grep
- - ``\``
- - ``\``
+ - ``\``
+ - ``\``
  - ``\``
  - ``\``
 
diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
index cfb1d79331..babf0a8959 100644
--- a/include/exec/cpu-all.h
+++ b/include/exec/cpu-all.h
@@ -125,13 +125,9 @@ static inline void tswap64s(uint64_t *s)
 #define ldsw_p(p) ldsw_be_p(p)
 #define ldl_p(p) ldl_be_p(p)
 #define ldq_p(p) ldq_be_p(p)
-#define ldfl_p(p) ldfl_be_p(p)
-#define ldfq_p(p) ldfq_be_p(p)
 #define stw_p(p, v) stw_be_p(p, v)
 #define stl_p(p, v) stl_be_p(p, v)
 #define stq_p(p, v) stq_be_p(p, v)
-#define stfl_p(p, v) stfl_be_p(p, v)
-#define stfq_p(p, v) stfq_be_p(p, v)
 #define ldn_p(p, sz) ldn_be_p(p, sz)
 #define stn_p(p, sz, v) stn_be_p(p, sz, v)
 #else
@@ -139,13 +135,9 @@ static inline void tswap64s(uint64_t *s)
 #define ldsw_p(p) ldsw_le_p(p)
 #define ldl_p(p) ldl_le_p(p)
 #define ldq_p(p) ldq_le_p(p)
-#define ldfl_p(p) ldfl_le_p(p)
-#define ldfq_p(p) ldfq_le_p(p)
 #define stw_p(p, v) stw_le_p(p, v)
 #define stl_p(p, v) stl_le_p(p, v)
 #define stq_p(p, v) stq_le_p(p, v)
-#define stfl_p(p, v) stfl_le_p(p, v)
-#define stfq_p(p, v) stfq_le_p(p, v)
 #define ldn_p(p, sz) ldn_le_p(p, sz)
 #define stn_p(p, sz, v) stn_le_p(p, sz, v)
 #endif
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 8b01c38040..4aaf992b5d 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -400,36 +400,6 @@ static inline void stq_le_p(void *ptr, uint64_t v)
 stq_he_p(ptr, le_bswap(v, 64));
 }
 
-/* float access */
-
-static inline float32 ldfl_le_p(const void *ptr)
-{
-CPU_FloatU u;
-u.l = ldl_le_p(ptr);
-return u.f;
-}
-
-static inline void stfl_le_p(void *ptr, float32 v)
-{
-CPU_FloatU u;
-u.f = v;
-stl_le_p(ptr, u.l);
-}
-
-static inline float64 ldfq_le_p(const void *ptr)
-{
-CPU_DoubleU u;
-u.ll = ldq_le_p(ptr);
-return u.d;
-}
-
-static inline void stfq_le_p(void *ptr, float64 v)
-{
-CPU_DoubleU u;
-u.d = v;
-stq_le_p(ptr, u.ll);
-}
-
 static inline int lduw_be_p(const void *ptr)
 {
 return (uint16_t)be_bswap(lduw_he_p(ptr), 16);
@@ -465,36 +435,6 @@ static inline void stq_be_p(void *ptr, uint64_t v)
 stq_he_p(ptr, be_bswap(v, 64));
 }
 
-/* float access */
-
-static inline float32 ldfl_be_p(const void *ptr)
-{
-CPU_FloatU u;
-u.l = ldl_be_p(ptr);
-return u.f;
-}
-
-static inline void stfl_be_p(void *ptr, float32 v)
-{
-CPU_FloatU u;
-u.f = v;
-stl_be_p(ptr, u.l);
-}
-
-static inline float64 ldfq_be_p(const void *ptr)
-{
-CPU_DoubleU u;
-u.ll = ldq_be_p(ptr);
-return u.d;
-}
-
-static inline void stfq_be_p(void *ptr, float64 v)
-{
-CPU_DoubleU u;
-u.d = v;
-stq_be_p(ptr, u.ll);
-}
-
 static inline unsigned long leul_to_cpu(unsigned long v)
 {
 #if HOST_LONG_BITS == 32
-- 
2.20.1




Re: [PATCH] linux-user/elfload: do not assume MAP_FIXED_NOREPLACE kernel support

2021-02-15 Thread Alex Bennée


Vincent Fazio  writes:

> On Sun, Feb 14, 2021 at 6:50 AM Laurent Vivier  wrote:
>>
>> Le 14/02/2021 à 12:24, Alex Bennée a écrit :
>> >
>> > Vincent Fazio  writes:
>> >
>> >> From: Vincent Fazio 
>> >>
>> >> Previously, pgd_find_hole_fallback assumed that if the build host's libc
>> >> had MAP_FIXED_NOREPLACE defined that the address returned by mmap would
>> >> match the requested address. This is not a safe assumption for Linux
>> >> kernels prior to 4.17
>> >
>> > It doesn't as we have in osdep.h:
>> >
>> >   #ifndef MAP_FIXED_NOREPLACE
>> >   #define MAP_FIXED_NOREPLACE 0
>> >   #endif
>> >
>> > which is to say to assume if MAP_FIXED_NOREPLACE is defined the kernel
>> > should have given us what we want otherwise we do the check.
>>
>>
>> But what is the purpose of the "if (MAP_FIXED_NOREPLACE != 0 ||"?
>> Can't we rely only on "mmap_start == (void *) align_start"?
>>
>> Thanks,
>> Laurent
>>
>
> I think we have to rely on address matching. The problem is
> specifically when MAP_FIXED_NOREPLACE is defined and is passed to mmap
> but the running kernel doesn't know what to do with the flag so
> returns a value that is not what was hinted at. Previously the code
> assumed that if MAP_FIXED_NOREPLACE was defined that the returned
> address would match, but that isn't always the case if the kernel
> doesn't have support for the flag. The 4.4, 4.9 and 4.14 LTS kernels
> are still in use and could run into this problem.

Ahh right so I think this is a case of binaries being built on a
different platform than kernel they are running on. In which case the
flag would be defined but the underlying kernel fails to identify it. Is
this a container like case by any chance?

If I'd read the man page closer:

   Note   that   older   kernels   which   do   not  recognize  the
   MAP_FIXED_NOREPLACE flag will typically (upon detecting a colli‐
   sion  with a preexisting mapping) fall back to a "non-MAP_FIXED"
   type of behavior: they will return an address that is  different
   from  the  requested  address.   Therefore,  backward-compatible
   software should check the returned address against the requested
   address.

so yes we should avoid short circuiting the return address check.

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Kevin Wolf
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> even luminous (version 12.2) is unmaintained for over 3 years now.
> Bump the requirement to get rid of the ifdef'ry in the code.
> 
> Signed-off-by: Peter Lieven 

> diff --git a/meson.build b/meson.build
> index 5943aa8a51..02d263ad33 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -691,19 +691,24 @@ if not get_option('rbd').auto() or have_block
> required: get_option('rbd'),
> kwargs: static_kwargs)
>if librados.found() and librbd.found()
> -if cc.links('''
> +result = cc.run('''

Doesn't running compiled binaries break cross compilation?

>#include 
>#include 
>int main(void) {
>  rados_t cluster;
>  rados_create(&cluster, NULL);
> +rados_shutdown(cluster);
> +#if LIBRBD_VERSION_CODE < LIBRBD_VERSION(1, 12, 0)
> +return 1;
> +#endif
>  return 0;

Would #error achieve what you want without running the binary?

But most, if not all, other version checks use pkg-config instead of
trying to compile code, so that's probably what we should be doing here,
too.

> -  }''', dependencies: [librbd, librados])
> +}''', dependencies: [librbd, librados], name: 'librbd version check')
> +if result.compiled() and result.returncode() == 0
>rbd = declare_dependency(dependencies: [librbd, librados])
>  elif get_option('rbd').enabled()
> -  error('could not link librados')
> +  error('librados/librbd >= 12.0.0 required')
>  else
> -  warning('could not link librados, disabling')
> +  warning('librados/librbd >= 12.0.0 not found, disabling rbd support')
>  endif
>endif
>  endif

Kevin




Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Daniel P . Berrangé
On Mon, Feb 15, 2021 at 11:11:23AM +0100, Kevin Wolf wrote:
> Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> > even luminous (version 12.2) is unmaintained for over 3 years now.
> > Bump the requirement to get rid of the ifdef'ry in the code.
> > 
> > Signed-off-by: Peter Lieven 
> 
> > diff --git a/meson.build b/meson.build
> > index 5943aa8a51..02d263ad33 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -691,19 +691,24 @@ if not get_option('rbd').auto() or have_block
> > required: get_option('rbd'),
> > kwargs: static_kwargs)
> >if librados.found() and librbd.found()
> > -if cc.links('''
> > +result = cc.run('''
> 
> Doesn't running compiled binaries break cross compilation?
> 
> >#include 
> >#include 
> >int main(void) {
> >  rados_t cluster;
> >  rados_create(&cluster, NULL);
> > +rados_shutdown(cluster);
> > +#if LIBRBD_VERSION_CODE < LIBRBD_VERSION(1, 12, 0)
> > +return 1;
> > +#endif
> >  return 0;
> 
> Would #error achieve what you want without running the binary?
> 
> But most, if not all, other version checks use pkg-config instead of
> trying to compile code, so that's probably what we should be doing here,
> too.

Yep, for something that is merely a version number check there's no
need to compile anything. pkg-config can just validate the version
straightup.

> 
> > -  }''', dependencies: [librbd, librados])
> > +}''', dependencies: [librbd, librados], name: 'librbd version check')
> > +if result.compiled() and result.returncode() == 0
> >rbd = declare_dependency(dependencies: [librbd, librados])
> >  elif get_option('rbd').enabled()
> > -  error('could not link librados')
> > +  error('librados/librbd >= 12.0.0 required')
> >  else
> > -  warning('could not link librados, disabling')
> > +  warning('librados/librbd >= 12.0.0 not found, disabling rbd support')
> >  endif
> >endif
> >  endif

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [PATCH V2 4/7] block/rbd: add bdrv_attach_aio_context

2021-02-15 Thread Kevin Wolf
Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:
> Signed-off-by: Peter Lieven 
> ---
>  block/rbd.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/block/rbd.c b/block/rbd.c
> index f68ebcf240..7abd0252c9 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -91,6 +91,7 @@ typedef struct BDRVRBDState {
>  char *namespace;
>  uint64_t image_size;
>  uint64_t object_size;
> +AioContext *aio_context;
>  } BDRVRBDState;

A commit message explaining the why would be helpful here.

This is already stored in BlockDriverState, which should be available
everywhere. Keeping redundant information needs a good justification,
which seems unlikely when BlockDriverState and BDRVRBDState are already
connected through the BlockDriverState.opaque pointer.

The rest of the series doesn't seem to make more use of it either.

Kevin




[PATCH] hw/display/tcx: Drop unnecessary code for handling BGR format outputs

2021-02-15 Thread Peter Maydell
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel, RGB. The TCX code already
assumes 32bpp, but it still has some checks of is_surface_bgr()
in an attempt to support 32bpp BGR. is_surface_bgr() will always
return false for the qemu_console_surface(), unless the display
device itself has deliberately created an alternate-format
surface via a function like qemu_create_displaysurface_from().

Drop the never-used BGR-handling code, and assert that we have
a 32-bit surface rather than just doing nothing if it isn't.

Signed-off-by: Peter Maydell 
---
Tested by booting Linux on an SS-5.
---
 hw/display/tcx.c | 31 ---
 1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 965f92ff6b7..d3db3046572 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -128,15 +128,10 @@ static int tcx_check_dirty(TCXState *s, 
DirtyBitmapSnapshot *snap,
 
 static void update_palette_entries(TCXState *s, int start, int end)
 {
-DisplaySurface *surface = qemu_console_surface(s->con);
 int i;
 
 for (i = start; i < end; i++) {
-if (is_surface_bgr(surface)) {
-s->palette[i] = rgb_to_pixel32bgr(s->r[i], s->g[i], s->b[i]);
-} else {
-s->palette[i] = rgb_to_pixel32(s->r[i], s->g[i], s->b[i]);
-}
+s->palette[i] = rgb_to_pixel32(s->r[i], s->g[i], s->b[i]);
 }
 tcx_set_dirty(s, 0, memory_region_size(&s->vram_mem));
 }
@@ -181,21 +176,18 @@ static void tcx_draw_cursor32(TCXState *s1, uint8_t *d,
 }
 
 /*
-  XXX Could be much more optimal:
-  * detect if line/page/whole screen is in 24 bit mode
-  * if destination is also BGR, use memcpy
-  */
+ * XXX Could be much more optimal:
+ * detect if line/page/whole screen is in 24 bit mode
+ */
 static inline void tcx24_draw_line32(TCXState *s1, uint8_t *d,
  const uint8_t *s, int width,
  const uint32_t *cplane,
  const uint32_t *s24)
 {
-DisplaySurface *surface = qemu_console_surface(s1->con);
-int x, bgr, r, g, b;
+int x, r, g, b;
 uint8_t val, *p8;
 uint32_t *p = (uint32_t *)d;
 uint32_t dval;
-bgr = is_surface_bgr(surface);
 for(x = 0; x < width; x++, s++, s24++) {
 if (be32_to_cpu(*cplane) & 0x0300) {
 /* 24-bit direct, BGR order */
@@ -204,10 +196,7 @@ static inline void tcx24_draw_line32(TCXState *s1, uint8_t 
*d,
 b = *p8++;
 g = *p8++;
 r = *p8;
-if (bgr)
-dval = rgb_to_pixel32bgr(r, g, b);
-else
-dval = rgb_to_pixel32(r, g, b);
+dval = rgb_to_pixel32(r, g, b);
 } else {
 /* 8-bit pseudocolor */
 val = *s;
@@ -230,9 +219,7 @@ static void tcx_update_display(void *opaque)
 int y, y_start, dd, ds;
 uint8_t *d, *s;
 
-if (surface_bits_per_pixel(surface) != 32) {
-return;
-}
+assert(surface_bits_per_pixel(surface) == 32);
 
 page = 0;
 y_start = -1;
@@ -283,9 +270,7 @@ static void tcx24_update_display(void *opaque)
 uint8_t *d, *s;
 uint32_t *cptr, *s24;
 
-if (surface_bits_per_pixel(surface) != 32) {
-return;
-}
+assert(surface_bits_per_pixel(surface) == 32);
 
 page = 0;
 y_start = -1;
-- 
2.20.1




Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Daniel P . Berrangé
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
> even luminous (version 12.2) is unmaintained for over 3 years now.
> Bump the requirement to get rid of the ifdef'ry in the code.

We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:

  https://qemu.readthedocs.io/en/latest/system/build-platforms.html

At this time RHEL-7 is usually the oldest platform, and it
builds with RBD 10.2.5, so we can't bump the version to 12.2.

I'm afraid this patch has to be dropped.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [RFC v18 12/15] i386: separate fpu_helper into user and softmmu parts

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:

> Signed-off-by: Claudio Fontana 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



[PATCH 3/9] hw/display/tc6393xb: Expand out macros in template header

2021-02-15 Thread Peter Maydell
Now the template header is included only for BITS==32, expand
out all the macros that depended on the BITS setting.

Signed-off-by: Peter Maydell 
---
 hw/display/tc6393xb_template.h | 35 --
 1 file changed, 4 insertions(+), 31 deletions(-)

diff --git a/hw/display/tc6393xb_template.h b/hw/display/tc6393xb_template.h
index 78629c07f97..7789ffc4399 100644
--- a/hw/display/tc6393xb_template.h
+++ b/hw/display/tc6393xb_template.h
@@ -21,25 +21,7 @@
  * with this program; if not, see .
  */
 
-#if BITS == 8
-# define SET_PIXEL(addr, color)  (*(uint8_t *)addr = color)
-#elif BITS == 15 || BITS == 16
-# define SET_PIXEL(addr, color)  (*(uint16_t *)addr = color)
-#elif BITS == 24
-# define SET_PIXEL(addr, color)  \
-do { \
-addr[0] = color; \
-addr[1] = (color) >> 8;  \
-addr[2] = (color) >> 16; \
-} while (0)
-#elif BITS == 32
-# define SET_PIXEL(addr, color)  (*(uint32_t *)addr = color)
-#else
-# error unknown bit depth
-#endif
-
-
-static void glue(tc6393xb_draw_graphic, BITS)(TC6393xbState *s)
+static void tc6393xb_draw_graphic32(TC6393xbState *s)
 {
 DisplaySurface *surface = qemu_console_surface(s->con);
 int i;
@@ -49,24 +31,15 @@ static void glue(tc6393xb_draw_graphic, BITS)(TC6393xbState 
*s)
 data_buffer = s->vram_ptr;
 data_display = surface_data(surface);
 for(i = 0; i < s->scr_height; i++) {
-#if (BITS == 16)
-memcpy(data_display, data_buffer, s->scr_width * 2);
-data_buffer += s->scr_width;
-data_display += surface_stride(surface);
-#else
 int j;
-for (j = 0; j < s->scr_width; j++, data_display += BITS / 8, 
data_buffer++) {
+for (j = 0; j < s->scr_width; j++, data_display += 4, data_buffer++) {
 uint16_t color = *data_buffer;
-uint32_t dest_color = glue(rgb_to_pixel, BITS)(
+uint32_t dest_color = rgb_to_pixel32(
((color & 0xf800) * 0x108) >> 11,
((color & 0x7e0) * 0x41) >> 9,
((color & 0x1f) * 0x21) >> 2
);
-SET_PIXEL(data_display, dest_color);
+*(uint32_t *)data_display = dest_color;
 }
-#endif
 }
 }
-
-#undef BITS
-#undef SET_PIXEL
-- 
2.20.1




[PATCH 4/9] hw/display/tc6393xb: Inline tc6393xb_draw_graphic32() at its callsite

2021-02-15 Thread Peter Maydell
The function tc6393xb_draw_graphic32() is called in exactly one place,
so just inline the function body at its callsite. This allows us to
drop the template header entirely.

The code move includes a single added space after 'for' to fix
the coding style.

Signed-off-by: Peter Maydell 
---
 hw/display/tc6393xb_template.h | 45 --
 hw/display/tc6393xb.c  | 23 ++---
 2 files changed, 19 insertions(+), 49 deletions(-)
 delete mode 100644 hw/display/tc6393xb_template.h

diff --git a/hw/display/tc6393xb_template.h b/hw/display/tc6393xb_template.h
deleted file mode 100644
index 7789ffc4399..000
--- a/hw/display/tc6393xb_template.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * Toshiba TC6393XB I/O Controller.
- * Found in Sharp Zaurus SL-6000 (tosa) or some
- * Toshiba e-Series PDAs.
- *
- * FB support code. Based on G364 fb emulator
- *
- * Copyright (c) 2007 Hervé Poussineau
- *
- * 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.
- *
- * 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 .
- */
-
-static void tc6393xb_draw_graphic32(TC6393xbState *s)
-{
-DisplaySurface *surface = qemu_console_surface(s->con);
-int i;
-uint16_t *data_buffer;
-uint8_t *data_display;
-
-data_buffer = s->vram_ptr;
-data_display = surface_data(surface);
-for(i = 0; i < s->scr_height; i++) {
-int j;
-for (j = 0; j < s->scr_width; j++, data_display += 4, data_buffer++) {
-uint16_t color = *data_buffer;
-uint32_t dest_color = rgb_to_pixel32(
-   ((color & 0xf800) * 0x108) >> 11,
-   ((color & 0x7e0) * 0x41) >> 9,
-   ((color & 0x1f) * 0x21) >> 2
-   );
-*(uint32_t *)data_display = dest_color;
-}
-}
-}
diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c
index 4cddb1a99ad..1f28223c7be 100644
--- a/hw/display/tc6393xb.c
+++ b/hw/display/tc6393xb.c
@@ -410,12 +410,27 @@ static void tc6393xb_nand_writeb(TC6393xbState *s, hwaddr 
addr, uint32_t value)
 (uint32_t) addr, value & 0xff);
 }
 
-#define BITS 32
-#include "tc6393xb_template.h"
-
 static void tc6393xb_draw_graphic(TC6393xbState *s, int full_update)
 {
-tc6393xb_draw_graphic32(s);
+DisplaySurface *surface = qemu_console_surface(s->con);
+int i;
+uint16_t *data_buffer;
+uint8_t *data_display;
+
+data_buffer = s->vram_ptr;
+data_display = surface_data(surface);
+for (i = 0; i < s->scr_height; i++) {
+int j;
+for (j = 0; j < s->scr_width; j++, data_display += 4, data_buffer++) {
+uint16_t color = *data_buffer;
+uint32_t dest_color = rgb_to_pixel32(
+   ((color & 0xf800) * 0x108) >> 11,
+   ((color & 0x7e0) * 0x41) >> 9,
+   ((color & 0x1f) * 0x21) >> 2
+   );
+*(uint32_t *)data_display = dest_color;
+}
+}
 dpy_gfx_update_full(s->con);
 }
 
-- 
2.20.1




[PATCH 8/9] hw/display/omap_lcdc: Inline template header into C file

2021-02-15 Thread Peter Maydell
We only include the template header once, so just inline it into the
source file for the device.

Signed-off-by: Peter Maydell 
---
 hw/display/omap_lcd_template.h | 154 -
 hw/display/omap_lcdc.c | 127 ++-
 2 files changed, 125 insertions(+), 156 deletions(-)
 delete mode 100644 hw/display/omap_lcd_template.h

diff --git a/hw/display/omap_lcd_template.h b/hw/display/omap_lcd_template.h
deleted file mode 100644
index a2f86eee3c8..000
--- a/hw/display/omap_lcd_template.h
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * QEMU OMAP LCD Emulator templates
- *
- * Copyright (c) 2006 Andrzej Zaborowski  
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS''
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
- * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
- * 2-bit colour
- */
-static void draw_line2_32(void *opaque, uint8_t *d, const uint8_t *s,
-  int width, int deststep)
-{
-uint16_t *pal = opaque;
-uint8_t v, r, g, b;
-
-do {
-v = ldub_p((void *) s);
-r = (pal[v & 3] >> 4) & 0xf0;
-g = pal[v & 3] & 0xf0;
-b = (pal[v & 3] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-v >>= 2;
-r = (pal[v & 3] >> 4) & 0xf0;
-g = pal[v & 3] & 0xf0;
-b = (pal[v & 3] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-v >>= 2;
-r = (pal[v & 3] >> 4) & 0xf0;
-g = pal[v & 3] & 0xf0;
-b = (pal[v & 3] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-v >>= 2;
-r = (pal[v & 3] >> 4) & 0xf0;
-g = pal[v & 3] & 0xf0;
-b = (pal[v & 3] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-s++;
-width -= 4;
-} while (width > 0);
-}
-
-/*
- * 4-bit colour
- */
-static void draw_line4_32(void *opaque, uint8_t *d, const uint8_t *s,
-  int width, int deststep)
-{
-uint16_t *pal = opaque;
-uint8_t v, r, g, b;
-
-do {
-v = ldub_p((void *) s);
-r = (pal[v & 0xf] >> 4) & 0xf0;
-g = pal[v & 0xf] & 0xf0;
-b = (pal[v & 0xf] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-v >>= 4;
-r = (pal[v & 0xf] >> 4) & 0xf0;
-g = pal[v & 0xf] & 0xf0;
-b = (pal[v & 0xf] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-d += 4;
-s++;
-width -= 2;
-} while (width > 0);
-}
-
-/*
- * 8-bit colour
- */
-static void draw_line8_32(void *opaque, uint8_t *d, const uint8_t *s,
-  int width, int deststep)
-{
-uint16_t *pal = opaque;
-uint8_t v, r, g, b;
-
-do {
-v = ldub_p((void *) s);
-r = (pal[v] >> 4) & 0xf0;
-g = pal[v] & 0xf0;
-b = (pal[v] << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-s++;
-d += 4;
-} while (-- width != 0);
-}
-
-/*
- * 12-bit colour
- */
-static void draw_line12_32(void *opaque, uint8_t *d, const uint8_t *s,
-   int width, int deststep)
-{
-uint16_t v;
-uint8_t r, g, b;
-
-do {
-v = lduw_le_p((void *) s);
-r = (v >> 4) & 0xf0;
-g = v & 0xf0;
-b = (v << 4) & 0xf0;
-((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-s += 2;
-d += 4;
-} while (-- width != 0);
-}
-
-/*
- * 16-bit colour
- */
-static void draw_line16_32(void *opaque, uint8_t *d, const uint8_t *s,
-   int width, int deststep)
-{
-uint16_t v;
-uint8_t r, g, b;
-
-do {
-v = lduw_le_p((void *) s);
-r = (v >> 8) & 0xf

[PATCH 0/9] arm: drop dead code for non-32-bit-RGB surfaces

2021-02-15 Thread Peter Maydell
This patchset removes dead code (including a couple of 'template'
headers) for handling UI surfaces that are formats other than
32-bit RGB for the musicpal, tc6393xb and omap_lcdc display devices.

For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB, so the legacy code in these
devices which was handling the possibility that the console surface
was some other format can all be deleted.

Notes:
 (1) the patch "hw/display/omap_lcdc: Drop broken bigendian ifdef"
 fixes a bug introduced in commit ea644cf343129 in 2016 in a
 previous partial start on this cleanup
 (2) the omap_lcdc changes are tested only with 'make check' as I
 don't have any test images for the OMAP1.

With these plus the other on-list patches, the only remaining
'template' header files in hw/display are pl110 (which needs it to
handle the different guest-side pixel formats) and the
milkymist-vgafb device.  Milkymist is in the 'deprecated and will be
deleted in a few releases' bucket so it's not worth doing this
cleanup for it, since it's not blocking any API transition.
(I'll take this task off the BiteSizedTasks list shortly.)

After the musicpal cleanup and the tcx patch I just posted, there
will be no more users of is_surface_bgr(), so that could then be
deleted.

thanks
-- PMM

Peter Maydell (9):
  hw/arm/musicpal: Remove dead code for non-32-bit-RGB surfaces
  hw/display/tc6393xb: Remove dead code for handling non-32bpp surfaces
  hw/display/tc6393xb: Expand out macros in template header
  hw/display/tc6393xb: Inline tc6393xb_draw_graphic32() at its callsite
  hw/display/omap_lcdc: Expand out macros in template header
  hw/display/omap_lcdc: Drop broken bigendian ifdef
  hw/display/omap_lcdc: Fix coding style issues in template header
  hw/display/omap_lcdc: Inline template header into C file
  hw/display/omap_lcdc: Delete unnecessary macro

 hw/display/omap_lcd_template.h | 169 -
 hw/display/tc6393xb_template.h |  72 --
 include/ui/console.h   |  10 --
 hw/arm/musicpal.c  |  64 +
 hw/display/omap_lcdc.c | 129 -
 hw/display/tc6393xb.c  |  48 --
 6 files changed, 165 insertions(+), 327 deletions(-)
 delete mode 100644 hw/display/omap_lcd_template.h
 delete mode 100644 hw/display/tc6393xb_template.h

-- 
2.20.1




[PATCH 6/9] hw/display/omap_lcdc: Drop broken bigendian ifdef

2021-02-15 Thread Peter Maydell
The draw_line16_32() function in the omap_lcdc template header
includes an ifdef for the case where HOST_WORDS_BIGENDIAN matches
TARGET_WORDS_BIGENDIAN.  This is trying to optimise for "source
bitmap and destination bitmap format match", but it is broken,
because in this function the formats don't match: the source is
16-bit colour and the destination is 32-bit colour, so a memcpy()
will produce corrupted graphics output.  Drop the bogus ifdef.

This bug was introduced in commit ea644cf343129, when we dropped
support for DEPTH values other than 32 from the template header.
The old #if line was
  #if DEPTH == 16 && defined(HOST_WORDS_BIGENDIAN) == 
defined(TARGET_WORDS_BIGENDIAN)
and this was mistakenly changed to
  #if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
rather than deleting the #if as now having an always-false condition.

Fixes: ea644cf343129
Signed-off-by: Peter Maydell 
---
 hw/display/omap_lcd_template.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/display/omap_lcd_template.h b/hw/display/omap_lcd_template.h
index c7c5025fb04..22e51d9bffb 100644
--- a/hw/display/omap_lcd_template.h
+++ b/hw/display/omap_lcd_template.h
@@ -139,9 +139,6 @@ static void draw_line12_32(void *opaque, uint8_t *d, const 
uint8_t *s,
 static void draw_line16_32(void *opaque, uint8_t *d, const uint8_t *s,
int width, int deststep)
 {
-#if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
-memcpy(d, s, width * 2);
-#else
 uint16_t v;
 uint8_t r, g, b;
 
@@ -154,5 +151,4 @@ static void draw_line16_32(void *opaque, uint8_t *d, const 
uint8_t *s,
 s += 2;
 d += 4;
 } while (-- width != 0);
-#endif
 }
-- 
2.20.1




[PATCH 2/9] hw/display/tc6393xb: Remove dead code for handling non-32bpp surfaces

2021-02-15 Thread Peter Maydell
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the tc6393xb display device which was handling the
possibility that the console surface was some other format.

Signed-off-by: Peter Maydell 
---
 include/ui/console.h  | 10 --
 hw/display/tc6393xb.c | 33 +
 2 files changed, 1 insertion(+), 42 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index d30e972d0b5..ed086f9f1ad 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -266,16 +266,6 @@ PixelFormat qemu_default_pixelformat(int bpp);
 DisplaySurface *qemu_create_displaysurface(int width, int height);
 void qemu_free_displaysurface(DisplaySurface *surface);
 
-static inline int is_surface_bgr(DisplaySurface *surface)
-{
-if (PIXMAN_FORMAT_BPP(surface->format) == 32 &&
-PIXMAN_FORMAT_TYPE(surface->format) == PIXMAN_TYPE_ABGR) {
-return 1;
-} else {
-return 0;
-}
-}
-
 static inline int is_buffer_shared(DisplaySurface *surface)
 {
 return !(surface->flags & QEMU_ALLOCATED_FLAG);
diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c
index 49a676d1b0e..4cddb1a99ad 100644
--- a/hw/display/tc6393xb.c
+++ b/hw/display/tc6393xb.c
@@ -410,43 +410,12 @@ static void tc6393xb_nand_writeb(TC6393xbState *s, hwaddr 
addr, uint32_t value)
 (uint32_t) addr, value & 0xff);
 }
 
-#define BITS 8
-#include "tc6393xb_template.h"
-#define BITS 15
-#include "tc6393xb_template.h"
-#define BITS 16
-#include "tc6393xb_template.h"
-#define BITS 24
-#include "tc6393xb_template.h"
 #define BITS 32
 #include "tc6393xb_template.h"
 
 static void tc6393xb_draw_graphic(TC6393xbState *s, int full_update)
 {
-DisplaySurface *surface = qemu_console_surface(s->con);
-
-switch (surface_bits_per_pixel(surface)) {
-case 8:
-tc6393xb_draw_graphic8(s);
-break;
-case 15:
-tc6393xb_draw_graphic15(s);
-break;
-case 16:
-tc6393xb_draw_graphic16(s);
-break;
-case 24:
-tc6393xb_draw_graphic24(s);
-break;
-case 32:
-tc6393xb_draw_graphic32(s);
-break;
-default:
-printf("tc6393xb: unknown depth %d\n",
-   surface_bits_per_pixel(surface));
-return;
-}
-
+tc6393xb_draw_graphic32(s);
 dpy_gfx_update_full(s->con);
 }
 
-- 
2.20.1




[PATCH 1/9] hw/arm/musicpal: Remove dead code for non-32-bit-RGB surfaces

2021-02-15 Thread Peter Maydell
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the milkymist display device which was handling the
possibility that the console surface was some other format.

Signed-off-by: Peter Maydell 
---
 hw/arm/musicpal.c | 64 ++-
 1 file changed, 24 insertions(+), 40 deletions(-)

diff --git a/hw/arm/musicpal.c b/hw/arm/musicpal.c
index 6aec84aeed8..9cebece2de0 100644
--- a/hw/arm/musicpal.c
+++ b/hw/arm/musicpal.c
@@ -512,53 +512,37 @@ static uint8_t scale_lcd_color(musicpal_lcd_state *s, 
uint8_t col)
 }
 }
 
-#define SET_LCD_PIXEL(depth, type) \
-static inline void glue(set_lcd_pixel, depth) \
-(musicpal_lcd_state *s, int x, int y, type col) \
-{ \
-int dx, dy; \
-DisplaySurface *surface = qemu_console_surface(s->con); \
-type *pixel = &((type *) surface_data(surface))[(y * 128 * 3 + x) * 3]; \
-\
-for (dy = 0; dy < 3; dy++, pixel += 127 * 3) \
-for (dx = 0; dx < 3; dx++, pixel++) \
-*pixel = col; \
+static inline void set_lcd_pixel32(musicpal_lcd_state *s,
+   int x, int y, uint32_t col)
+{
+int dx, dy;
+DisplaySurface *surface = qemu_console_surface(s->con);
+uint32_t *pixel =
+&((uint32_t *) surface_data(surface))[(y * 128 * 3 + x) * 3];
+
+for (dy = 0; dy < 3; dy++, pixel += 127 * 3) {
+for (dx = 0; dx < 3; dx++, pixel++) {
+*pixel = col;
+}
+}
 }
-SET_LCD_PIXEL(8, uint8_t)
-SET_LCD_PIXEL(16, uint16_t)
-SET_LCD_PIXEL(32, uint32_t)
 
 static void lcd_refresh(void *opaque)
 {
 musicpal_lcd_state *s = opaque;
-DisplaySurface *surface = qemu_console_surface(s->con);
 int x, y, col;
 
-switch (surface_bits_per_pixel(surface)) {
-case 0:
-return;
-#define LCD_REFRESH(depth, func) \
-case depth: \
-col = func(scale_lcd_color(s, (MP_LCD_TEXTCOLOR >> 16) & 0xff), \
-   scale_lcd_color(s, (MP_LCD_TEXTCOLOR >> 8) & 0xff), \
-   scale_lcd_color(s, MP_LCD_TEXTCOLOR & 0xff)); \
-for (x = 0; x < 128; x++) { \
-for (y = 0; y < 64; y++) { \
-if (s->video_ram[x + (y/8)*128] & (1 << (y % 8))) { \
-glue(set_lcd_pixel, depth)(s, x, y, col); \
-} else { \
-glue(set_lcd_pixel, depth)(s, x, y, 0); \
-} \
-} \
-} \
-break;
-LCD_REFRESH(8, rgb_to_pixel8)
-LCD_REFRESH(16, rgb_to_pixel16)
-LCD_REFRESH(32, (is_surface_bgr(surface) ?
- rgb_to_pixel32bgr : rgb_to_pixel32))
-default:
-hw_error("unsupported colour depth %i\n",
- surface_bits_per_pixel(surface));
+col = rgb_to_pixel32(scale_lcd_color(s, (MP_LCD_TEXTCOLOR >> 16) & 0xff),
+ scale_lcd_color(s, (MP_LCD_TEXTCOLOR >> 8) & 0xff),
+ scale_lcd_color(s, MP_LCD_TEXTCOLOR & 0xff));
+for (x = 0; x < 128; x++) {
+for (y = 0; y < 64; y++) {
+if (s->video_ram[x + (y / 8) * 128] & (1 << (y % 8))) {
+set_lcd_pixel32(s, x, y, col);
+} else {
+set_lcd_pixel32(s, x, y, 0);
+}
+}
 }
 
 dpy_gfx_update(s->con, 0, 0, 128*3, 64*3);
-- 
2.20.1




[PATCH] tests/qemu-iotests: Remove test 259 from the "auto" group

2021-02-15 Thread Thomas Huth
Tests in the "auto" group should support qcow2 so that they can
be run during "make check-block". Test 259 only supports "raw", so
it currently always gets skipped when running "make check-block".
Let's skip this unnecessary step and remove it from the auto group.

Signed-off-by: Thomas Huth 
---
 tests/qemu-iotests/259 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/259 b/tests/qemu-iotests/259
index 76cde429c4..1b15e8fb48 100755
--- a/tests/qemu-iotests/259
+++ b/tests/qemu-iotests/259
@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# group: rw auto quick
+# group: rw quick
 #
 # Test generic image creation fallback (by using NBD)
 #
-- 
2.27.0




[PATCH 5/9] hw/display/omap_lcdc: Expand out macros in template header

2021-02-15 Thread Peter Maydell
The omap_lcdc template header is already only included once, for
DEPTH==32, but it still has all the macro-driven parameterization
for other depths. Expand out all the macros in the header.

Signed-off-by: Peter Maydell 
---
 hw/display/omap_lcd_template.h | 67 ++
 1 file changed, 28 insertions(+), 39 deletions(-)

diff --git a/hw/display/omap_lcd_template.h b/hw/display/omap_lcd_template.h
index 1025ff3825d..c7c5025fb04 100644
--- a/hw/display/omap_lcd_template.h
+++ b/hw/display/omap_lcd_template.h
@@ -27,18 +27,11 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#if DEPTH == 32
-# define BPP 4
-# define PIXEL_TYPE uint32_t
-#else
-# error unsupport depth
-#endif
-
 /*
  * 2-bit colour
  */
-static void glue(draw_line2_, DEPTH)(void *opaque,
-uint8_t *d, const uint8_t *s, int width, int deststep)
+static void draw_line2_32(void *opaque, uint8_t *d, const uint8_t *s,
+  int width, int deststep)
 {
 uint16_t *pal = opaque;
 uint8_t v, r, g, b;
@@ -48,26 +41,26 @@ static void glue(draw_line2_, DEPTH)(void *opaque,
 r = (pal[v & 3] >> 4) & 0xf0;
 g = pal[v & 3] & 0xf0;
 b = (pal[v & 3] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 v >>= 2;
 r = (pal[v & 3] >> 4) & 0xf0;
 g = pal[v & 3] & 0xf0;
 b = (pal[v & 3] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 v >>= 2;
 r = (pal[v & 3] >> 4) & 0xf0;
 g = pal[v & 3] & 0xf0;
 b = (pal[v & 3] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 v >>= 2;
 r = (pal[v & 3] >> 4) & 0xf0;
 g = pal[v & 3] & 0xf0;
 b = (pal[v & 3] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 s ++;
 width -= 4;
 } while (width > 0);
@@ -76,8 +69,8 @@ static void glue(draw_line2_, DEPTH)(void *opaque,
 /*
  * 4-bit colour
  */
-static void glue(draw_line4_, DEPTH)(void *opaque,
-uint8_t *d, const uint8_t *s, int width, int deststep)
+static void draw_line4_32(void *opaque, uint8_t *d, const uint8_t *s,
+  int width, int deststep)
 {
 uint16_t *pal = opaque;
 uint8_t v, r, g, b;
@@ -87,14 +80,14 @@ static void glue(draw_line4_, DEPTH)(void *opaque,
 r = (pal[v & 0xf] >> 4) & 0xf0;
 g = pal[v & 0xf] & 0xf0;
 b = (pal[v & 0xf] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 v >>= 4;
 r = (pal[v & 0xf] >> 4) & 0xf0;
 g = pal[v & 0xf] & 0xf0;
 b = (pal[v & 0xf] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
-d += BPP;
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
+d += 4;
 s ++;
 width -= 2;
 } while (width > 0);
@@ -103,8 +96,8 @@ static void glue(draw_line4_, DEPTH)(void *opaque,
 /*
  * 8-bit colour
  */
-static void glue(draw_line8_, DEPTH)(void *opaque,
-uint8_t *d, const uint8_t *s, int width, int deststep)
+static void draw_line8_32(void *opaque, uint8_t *d, const uint8_t *s,
+  int width, int deststep)
 {
 uint16_t *pal = opaque;
 uint8_t v, r, g, b;
@@ -114,17 +107,17 @@ static void glue(draw_line8_, DEPTH)(void *opaque,
 r = (pal[v] >> 4) & 0xf0;
 g = pal[v] & 0xf0;
 b = (pal[v] << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
 s ++;
-d += BPP;
+d += 4;
 } while (-- width != 0);
 }
 
 /*
  * 12-bit colour
  */
-static void glue(draw_line12_, DEPTH)(void *opaque,
-uint8_t *d, const uint8_t *s, int width, int deststep)
+static void draw_line12_32(void *opaque, uint8_t *d, const uint8_t *s,
+   int width, int deststep)
 {
 uint16_t v;
 uint8_t r, g, b;
@@ -134,17 +127,17 @@ static void glue(draw_line12_, DEPTH)(void *opaque,
 r = (v >> 4) & 0xf0;
 g = v & 0xf0;
 b = (v << 4) & 0xf0;
-((PIXEL_TYPE *) d)[0] = glue(rgb_to_pixel, DEPTH)(r, g, b);
+((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
 s += 2;
-d += BPP;
+d += 4;
 } while (-- width != 0);
 }
 
 /*
  * 16-bit colour
  */
-static void glue(draw_line16_, DEPTH)(void *opaque,

[PATCH 7/9] hw/display/omap_lcdc: Fix coding style issues in template header

2021-02-15 Thread Peter Maydell
Fix some minor coding style issues in the template header,
so checkpatch doesn't complain when we move the code.

Signed-off-by: Peter Maydell 
---
 hw/display/omap_lcd_template.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/display/omap_lcd_template.h b/hw/display/omap_lcd_template.h
index 22e51d9bffb..a2f86eee3c8 100644
--- a/hw/display/omap_lcd_template.h
+++ b/hw/display/omap_lcd_template.h
@@ -61,7 +61,7 @@ static void draw_line2_32(void *opaque, uint8_t *d, const 
uint8_t *s,
 b = (pal[v & 3] << 4) & 0xf0;
 ((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
 d += 4;
-s ++;
+s++;
 width -= 4;
 } while (width > 0);
 }
@@ -88,7 +88,7 @@ static void draw_line4_32(void *opaque, uint8_t *d, const 
uint8_t *s,
 b = (pal[v & 0xf] << 4) & 0xf0;
 ((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
 d += 4;
-s ++;
+s++;
 width -= 2;
 } while (width > 0);
 }
@@ -108,7 +108,7 @@ static void draw_line8_32(void *opaque, uint8_t *d, const 
uint8_t *s,
 g = pal[v] & 0xf0;
 b = (pal[v] << 4) & 0xf0;
 ((uint32_t *) d)[0] = rgb_to_pixel32(r, g, b);
-s ++;
+s++;
 d += 4;
 } while (-- width != 0);
 }
-- 
2.20.1




Re: [Virtio-fs] [PATCH 07/24] DAX: virtio-fs: Add vhost-user slave commands for mapping

2021-02-15 Thread Chirantan Ekbote
On Wed, Feb 10, 2021 at 4:04 AM Dr. David Alan Gilbert (git)
 wrote:
>
> From: "Dr. David Alan Gilbert" 
> +
> +typedef struct {
> +/* Offsets within the file being mapped */
> +uint64_t fd_offset[VHOST_USER_FS_SLAVE_ENTRIES];
> +/* Offsets within the cache */
> +uint64_t c_offset[VHOST_USER_FS_SLAVE_ENTRIES];
> +/* Lengths of sections */
> +uint64_t len[VHOST_USER_FS_SLAVE_ENTRIES];
> +/* Flags, from VHOST_USER_FS_FLAG_* */
> +uint64_t flags[VHOST_USER_FS_SLAVE_ENTRIES];
> +} VhostUserFSSlaveMsg;
> +

Is it too late to change this?  This struct allocates space for up to
8 entries but most of the time the server will only try to set up one
mapping at a time so only 32 out of the 256 bytes in the message are
actually being used.  We're just wasting time memcpy'ing bytes that
will never be used.  Is there some reason this can't be dynamically
sized?  Something like:

typedef struct {
/* Number of mapping requests */
uint16_t num_requests;
/* `num_requests` mapping requests */
   MappingRequest requests[];
} VhostUserFSSlaveMsg;

typedef struct {
/* Offset within the file being mapped */
uint64_t fd_offset;
/* Offset within the cache */
uint64_t c_offset;
/* Length of section */
uint64_t len;
/* Flags, from VHOST_USER_FS_FLAG_* */
uint64_t flags;
} MappingRequest;

The current pre-allocated structure both wastes space when there are
fewer than 8 requests and requires extra messages to be sent when
there are more than 8 requests.  I realize that in the grand scheme of
things copying 224 extra bytes is basically not noticeable but it just
irks me that we could fix this really easily before it gets propagated
to too many other places.

Chirantan

> --
> 2.29.2
>
> ___
> Virtio-fs mailing list
> virtio...@redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs
>



[PATCH 9/9] hw/display/omap_lcdc: Delete unnecessary macro

2021-02-15 Thread Peter Maydell
The macro draw_line_func is used only once; just expand it.

Signed-off-by: Peter Maydell 
---
 hw/display/omap_lcdc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/display/omap_lcdc.c b/hw/display/omap_lcdc.c
index 2db04fad2fc..0ba42ef637c 100644
--- a/hw/display/omap_lcdc.c
+++ b/hw/display/omap_lcdc.c
@@ -70,8 +70,6 @@ static void omap_lcd_interrupts(struct omap_lcd_panel_s *s)
 qemu_irq_lower(s->irq);
 }
 
-#define draw_line_func drawfn
-
 /*
  * 2-bit colour
  */
@@ -202,7 +200,7 @@ static void omap_update_display(void *opaque)
 {
 struct omap_lcd_panel_s *omap_lcd = (struct omap_lcd_panel_s *) opaque;
 DisplaySurface *surface;
-draw_line_func draw_line;
+drawfn draw_line;
 int size, height, first, last;
 int width, linesize, step, bpp, frame_offset;
 hwaddr frame_base;
-- 
2.20.1




Re: [PATCH v2 00/12] block/export: vhost-user-blk server tests and input validation

2021-02-15 Thread Kevin Wolf
Am 07.12.2020 um 18:20 hat Stefan Hajnoczi geschrieben:
> v2:
>  * Add abrt handler that terminates qemu-storage-daemon to
>vhost-user-blk-test. No more orphaned processes on test failure. [Peter]
>  * Fix sector number calculation in vhost-user-blk-server.c
>  * Introduce VIRTIO_BLK_SECTOR_BITS/SIZE to make code clearer [Max]
>  * Fix vhost-user-blk-server.c blk_size double byteswap
>  * Fix vhost-user-blk blkcfg->num_queues endianness [Peter]
>  * Squashed cleanups into Coiby vhost-user-blk-test commit so the code is
>easier to review
> 
> The vhost-user-blk server test was already in Michael Tsirkin's recent vhost
> pull request, but was dropped because it exposed vhost-user regressions
> (b7c1bd9d7848 and the Based-on tag below). Now that the vhost-user regressions
> are fixed we can re-introduce the test case.
> 
> This series adds missing input validation that led to a Coverity report. The
> virtio-blk read, write, discard, and write zeroes commands need to check
> sector/byte ranges and other inputs. This solves the issue Peter Maydell 
> raised
> in "[PATCH for-5.2] block/export/vhost-user-blk-server.c: Avoid potential
> integer overflow".
> 
> Merging just the input validation patches would be possible too, but I prefer
> to merge the corresponding tests so the code is exercised by the CI.

Is this series still open? I don't see it in master.

Kevin




Re: [PATCH v3 1/7] spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical()

2021-02-15 Thread Greg Kurz
On Thu, 11 Feb 2021 19:52:40 -0300
Daniel Henrique Barboza  wrote:

> drc_isolate_logical() is used to move the DRC from the "Configured" to the
> "Available" state, erroring out if the DRC is in the unexpected "Unisolate"
> state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC is already in
> "Available" or in "Unusable" state.
> 
> When moving from "Configured" to "Available", the DRC is moved to the
> LOGICAL_AVAILABLE state, a drc->unplug_requested check is done and, if true,
> spapr_drc_detach() is called.
> 
> What spapr_drc_detach() does then is:
> 
> - set drc->unplug_requested to true. In fact, this is the only place where
> unplug_request is set to true;
> - does nothing else if drc->state != drck->empty_state. If the DRC state
> is equal to drck->empty_state, spapr_drc_release() is called. For logical
> DRCs, drck->empty_state = LOGICAL_UNUSABLE.
> 
> In short, calling spapr_drc_detach() in drc_isolate_logical() does nothing. 
> It'll
> set unplug_request to true again ('again' since it was already true - 
> otherwise the
> function wouldn't be called), and will return without calling 
> spapr_drc_release()
> because the DRC is not in LOGICAL_UNUSABLE, since drc_isolate_logical() just
> moved it to LOGICAL_AVAILABLE. The only place where the logical DRC is 
> released
> is when called from drc_set_unusable(), when it is moved to the "Unusable" 
> state.
> As it should, according to PAPR.
> 
> Even though calling spapr_drc_detach() in drc_isolate_logical() is benign, 
> removing
> it will avoid further thought about the matter. So let's go ahead and do that.
> 

Good catch. This path looks useless for logical DRCs indeed.

> As a note, this logic was introduced in commit bbf5c878ab76. Since then, the 
> DRC
> handling code was refactored and enhanced, and PAPR itself went through some
> changes in the DRC area as well. It is expected that some assumptions we had 
> back
> then are now deprecated.
> 

As specified in [1]:

Please do not use lines that are longer than 76 characters in your
commit message (so that the text still shows up nicely with "git show"
in a 80-columns terminal window).

[1] 
https://wiki.qemu.org/Contribute/SubmitAPatch#Write_a_meaningful_commit_message

> Signed-off-by: Daniel Henrique Barboza 
> ---
>  hw/ppc/spapr_drc.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
> index 8571d5bafe..84bd3c881f 100644
> --- a/hw/ppc/spapr_drc.c
> +++ b/hw/ppc/spapr_drc.c
> @@ -132,19 +132,6 @@ static uint32_t drc_isolate_logical(SpaprDrc *drc)
>  
>  drc->state = SPAPR_DRC_STATE_LOGICAL_AVAILABLE;
>  
> -/* if we're awaiting release, but still in an unconfigured state,
> - * it's likely the guest is still in the process of configuring
> - * the device and is transitioning the devices to an ISOLATED
> - * state as a part of that process. so we only complete the
> - * removal when this transition happens for a device in a
> - * configured state, as suggested by the state diagram from PAPR+
> - * 2.7, 13.4
> - */
> -if (drc->unplug_requested) {
> -uint32_t drc_index = spapr_drc_index(drc);
> -trace_spapr_drc_set_isolation_state_finalizing(drc_index);

I was expecting a change in hw/ppc/trace-events to ditch this trace,
but it is still called by drc_isolate_physical(), so we're good.

Reviewed-by: Greg Kurz 

> -spapr_drc_detach(drc);
> -}
>  return RTAS_OUT_SUCCESS;
>  }
>  




Re: [RFC PATCH 6/6] softmmu: Restrict watchpoint handlers to TCG accelerator

2021-02-15 Thread Claudio Fontana
On 1/18/21 10:36 AM, Philippe Mathieu-Daudé wrote:
> On 1/18/21 10:10 AM, Claudio Fontana wrote:
>> On 1/17/21 5:48 PM, Philippe Mathieu-Daudé wrote:
>>> Watchpoint funtions use cpu_restore_state() which is only
>>> available when TCG accelerator is built. Restrict them
>>> to TCG.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>
>> I am doing some of this in my series, and I did not notice that
>> cpu_watchpoint_insert was also TCG only.
>>
>> Probably we should merge this somehow.
>>
>> I thought it was used by gdbstub.c as well, passing flags BP_GDB .
> 
> BP_MEM_ACCESS for watchpoint.
> 
>> I noticed that gdbstub does something else entirely for kvm_enabled(), ie, 
>> kvm_insert_breakpoint,
>> but what about the other accels, it seems that the code flows to the 
>> cpu_breakpoint_insert and watchpoint_insert..?
>>
>> should cpu_breakpoint_insert have the same fate then?
>>
>> And is this really all TCG specific?
>>
>> From gdbstub.c:1020:
>>
>> static int gdb_breakpoint_insert(int type, target_ulong addr, target_ulong 
>> len)
>> {
>> CPUState *cpu;
>> int err = 0;
>>
>> if (kvm_enabled()) {
>> return kvm_insert_breakpoint(gdbserver_state.c_cpu, addr, len, type);
> 
> Doh I missed that. I remember Peter and Richard explained it once
> but I forgot and couldn't find on the list, maybe it was on IRC.
> 
> See i.e. in target/arm/kvm64.c:
> 
>  312 int kvm_arch_insert_hw_breakpoint(target_ulong addr,
>  313   target_ulong len, int type)
>  314 {
>  315 switch (type) {
>  316 case GDB_BREAKPOINT_HW:
>  317 return insert_hw_breakpoint(addr);
>  318 break;
>  319 case GDB_WATCHPOINT_READ:
>  320 case GDB_WATCHPOINT_WRITE:
>  321 case GDB_WATCHPOINT_ACCESS:
>  322 return insert_hw_watchpoint(addr, len, type);
>  323 default:
>  324 return -ENOSYS;
>  325 }
>  326 }
> 
>>
>>> ---
>>> RFC because we could keep that code by adding an empty
>>> stub for cpu_restore_state(), but it is unclear as
>>> the function is named generically.
>>> ---
>>>  include/hw/core/cpu.h | 4 ++--
>>>  softmmu/physmem.c | 4 
>>>  2 files changed, 6 insertions(+), 2 deletions(-)
> 

Hello Philippe,

I have reached this issue again when working on the ARM part of the cleanup,
did we reach a conclusion on whether cpu_watchpoint_insert is TCG-specific or 
not,

and more in general about breakpoints and watchpoints?

The way I encountered this issue now is during the KVM/TCG split in target/arm.

there are calls in target/arm/cpu.c and machine.c of the kind:

hw_breakpoint_update_all()
hw_watchpoint_update_all()

is this all TCG-specific,

including also hw_watchpoint_update(), hw_breakpoint_update() ?

kvm64.c seems to have its own handling of breakpoints, including arrays:

GArray *hw_breakpoints, *hw_watchpoints;

while the TCG stuff relies on cpu->watchpoints in softmmu/physmem.c:

$ gid watchpoints
include/hw/core/cpu.h:139: * address before attempting to match it against 
watchpoints.
include/hw/core/cpu.h:388:QTAILQ_HEAD(, CPUWatchpoint) watchpoints;
linux-user/main.c:210:/* Clone all break/watchpoints.
linux-user/main.c:212:   BP_CPU break/watchpoints are handled correctly on 
clone. */
linux-user/main.c:214:QTAILQ_INIT(&new_cpu->watchpoints);
linux-user/main.c:218:QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:791:/* keep all GDB-injected watchpoints in front */
softmmu/physmem.c:793:QTAILQ_INSERT_HEAD(&cpu->watchpoints, wp, entry);
softmmu/physmem.c:795:QTAILQ_INSERT_TAIL(&cpu->watchpoints, wp, entry);
softmmu/physmem.c:816:QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:829:QTAILQ_REMOVE(&cpu->watchpoints, watchpoint, entry);
softmmu/physmem.c:836:/* Remove all matching watchpoints.  */
softmmu/physmem.c:841:QTAILQ_FOREACH_SAFE(wp, &cpu->watchpoints, entry, 
next) {
softmmu/physmem.c:868:/* Return flags for watchpoints that match addr + prot.  
*/
softmmu/physmem.c:874:QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:906:QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:911: * Don't process the watchpoints when we 
are
accel/tcg/cpu-exec.c:511:QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
accel/tcg/cpu-exec.c:822:   after-access watchpoints.  Since this 
request should never
hw/core/cpu.c:361:QTAILQ_INIT(&cpu->watchpoints);


Even in i386 there is a bit of confusion still, and I think sorting out this 
could improve the code on i386 as well..

Thanks for any comment,

Ciao,

CLaudio











Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement

2021-02-15 Thread Andrew Jones
On Mon, Feb 15, 2021 at 09:53:50AM +0100, Vitaly Kuznetsov wrote:
> I have no clue why scratch vCPUs were implemented on ARM, however, I'd

We don't have an ioctl like KVM_GET_SUPPORTED_CPUID, which operates on
the KVM fd. Perhaps we should.

Thanks,
drew




Re: [PATCH] hw/ide/ahci: map cmd_fis as DMA_DIRECTION_TO_DEVICE

2021-02-15 Thread Kevin Wolf
Am 19.01.2021 um 17:40 hat Alexander Bulekov geschrieben:
> cmd_fis is mapped as DMA_DIRECTION_FROM_DEVICE, however, it is read
> from, and not written to anywhere. Fix the DMA_DIRECTION and mark
> cmd_fis as read-only in the code.
> 
> Signed-off-by: Alexander Bulekov 

Thanks, applied to the block branch.

Kevin




Re: [PATCH] xen-block: fix reporting of discard feature

2021-02-15 Thread Kevin Wolf
Am 18.01.2021 um 16:49 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Roger Pau Monne 
> > Sent: 18 January 2021 15:34
> > To: qemu-devel@nongnu.org
> > Cc: Roger Pau Monne ; Arthur Borsboom 
> > ; Stefano
> > Stabellini ; Anthony Perard 
> > ; Paul Durrant
> > ; Kevin Wolf ; Max Reitz 
> > ; xen-
> > de...@lists.xenproject.org; qemu-bl...@nongnu.org
> > Subject: [PATCH] xen-block: fix reporting of discard feature
> > 
> > Linux blkfront expects both "discard-granularity" and
> > "discard-alignment" present on xenbus in order to properly enable the
> > feature, not exposing "discard-alignment" left some Linux blkfront
> > versions with a broken discard setup. This has also been addressed in
> > Linux with:
> > 
> > https://lore.kernel.org/lkml/20210118151528.81668-1-roger@citrix.com/T/#u
> > 
> > Fix QEMU to report a "discard-alignment" of 0, in order for it to work
> > with older Linux frontends.
> > 
> > Reported-by: Arthur Borsboom 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Paul Durrant 

Thanks, applied to the block branch.

Kevin




Re: libvfio-user library in QEMU

2021-02-15 Thread Stefan Hajnoczi
On Fri, Feb 12, 2021 at 12:08:11PM +, Jag Raman wrote:
> If we have to use libvfio-user library in QEMU, could we link the library 
> with the QEMU binary based on some config options?

Yes, meson_options.txt can be used.

> Secondly, the remote process in multi-process QEMU uses the same QEMU binary 
> for the remote process as well. Is this OK with libvfio-user, to start with? 
> Or do you think a separate binary is preferred for the remote process?

For now the extra library dependency doesn't seem like a big problem.

The long term question is how to build with vfio-user device backends:

1. Single-device binaries. For example "make qemu-vfio-user-e1000" would
   build a vfio-user-e1000 binary from hw/net/e1000.c.

2. Multi-device binaries. For example "make qemu-vfio-user-backend"
   would build a vfio-user-backend binary with certain devices enabled.
   The set of devices could be specified via Kconfig or maybe on the
   command-line E1000=y VIRTIO_NET_PCI=y.

Build system support for this should minimize duplication with
monolithic QEMU's meson and Kconfig scripts.

It would also be great to avoid boilerplate. It should not be necessary
to write a lot of code to build a new device type as a vfio-user device
backend.

> From previous discussions, I recall that libvfio-user would be git submodule 
> in QEMU repo. Is this still the preferred approach?

Yes, I haven't heard anything else since that discussion so I think the
plan is to use a git submodule.

Maybe later when the libvfio-user interface is stable and it's shipped
as a package by distributions the submodule will be replaced by a
traditional external library dependency.

Stefan


signature.asc
Description: PGP signature


Re: [PATCH 4/9] hw/display/tc6393xb: Inline tc6393xb_draw_graphic32() at its callsite

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The function tc6393xb_draw_graphic32() is called in exactly one place,
> so just inline the function body at its callsite. This allows us to
> drop the template header entirely.
> 
> The code move includes a single added space after 'for' to fix
> the coding style.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/display/tc6393xb_template.h | 45 --
>  hw/display/tc6393xb.c  | 23 ++---
>  2 files changed, 19 insertions(+), 49 deletions(-)
>  delete mode 100644 hw/display/tc6393xb_template.h

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH 6/9] hw/display/omap_lcdc: Drop broken bigendian ifdef

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The draw_line16_32() function in the omap_lcdc template header
> includes an ifdef for the case where HOST_WORDS_BIGENDIAN matches
> TARGET_WORDS_BIGENDIAN.  This is trying to optimise for "source
> bitmap and destination bitmap format match", but it is broken,
> because in this function the formats don't match: the source is
> 16-bit colour and the destination is 32-bit colour, so a memcpy()
> will produce corrupted graphics output.  Drop the bogus ifdef.
> 
> This bug was introduced in commit ea644cf343129, when we dropped
> support for DEPTH values other than 32 from the template header.
> The old #if line was
>   #if DEPTH == 16 && defined(HOST_WORDS_BIGENDIAN) == 
> defined(TARGET_WORDS_BIGENDIAN)
> and this was mistakenly changed to
>   #if defined(HOST_WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
> rather than deleting the #if as now having an always-false condition.
> 
> Fixes: ea644cf343129
> Signed-off-by: Peter Maydell 
> ---
>  hw/display/omap_lcd_template.h | 4 
>  1 file changed, 4 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH 8/9] hw/display/omap_lcdc: Inline template header into C file

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> We only include the template header once, so just inline it into the
> source file for the device.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/display/omap_lcd_template.h | 154 -
>  hw/display/omap_lcdc.c | 127 ++-
>  2 files changed, 125 insertions(+), 156 deletions(-)
>  delete mode 100644 hw/display/omap_lcd_template.h

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH 9/9] hw/display/omap_lcdc: Delete unnecessary macro

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> The macro draw_line_func is used only once; just expand it.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/display/omap_lcdc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH 7/9] hw/display/omap_lcdc: Fix coding style issues in template header

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/15/21 11:32 AM, Peter Maydell wrote:
> Fix some minor coding style issues in the template header,
> so checkpatch doesn't complain when we move the code.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/display/omap_lcd_template.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 



Re: Call for Google Summer of Code 2021 project ideas

2021-02-15 Thread Paolo Bonzini

On 14/01/21 17:36, John Snow wrote:



The sane way to evade the language design problem is to use the existing
QMP language.


I wouldn't mind implementing this for version 0.1 -- just allow 
copy-pasting JSON into the input bar -- it's a feature I wanted anyway.


I think the only way out of language design is to instead design a TUI 
for inputting JSON.  For example:


* after typing the ' for a key you can autocomplete the next field, 
using the TAB key similar to vi


* after typing the : the TUI tells you the field type

* after typing the ' for an enum, the TAB brings up a menu to pick an enum

* after typing the last character in a key or value you automatically 
get a suggestion for what to type next (comma and next apostrophe after 
a value, colon and possible apostrophe/bracket/brace for a key)


One idea that has worked for me in the past was to write a mockup that 
shows what things are going to look like, with fake user interaction. 
You would have something like


   // {
   keypress("{")
   show_suggestion("'")
   // '
   keypress("'")
   start_autocomplete_choices(["execute", "arguments"])
   // TAB
   await asyncio.sleep(1)
   do_autocomplete()
   // '
   await asyncio.sleep(1)
   keypress("'")
   // string argument, propose ' for the value automatically
   show_suggestion(": '")
   // TAB
   await asyncio.sleep(1)
   do_autocomplete()
   start_autocomplete_choices("query-status", "query-kvm") # many more

etc.

Then you plug in an incremental lexer, so that you can e.g. replace

   show_autocomplete(": '")

with

   lex_state(Lexer.AFTER_KEY); // this would come from the lexer
   show_autocomplete("'")  // this would come from the schema

And then again plug the incremental visitor to autocomplete on the 
schema types.


Another advantage of this approach is that you also have a natural API 
for the mocks, and thus it becomes easier to write testcases.


Paolo




[Bug 1914535] Re: PL110 8-bit mode is not emulated correctly

2021-02-15 Thread Peter Maydell
Do you have a test case (QEMU command line and all necessary image
files) that demonstrates this, please ?


** Tags added: arm

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

Title:
  PL110 8-bit mode is not emulated correctly

Status in QEMU:
  New

Bug description:
  When the emulated pl110/pl111 is switched programmatically to 8-bit
  color depth mode, the display is drawn green and blue, but the real
  PL110 displays grayscale in 8-bit mode.

  The bug appears in qemu-system-arm version 3.1.0 (Debian
  1:3.1+dfsg-8+deb10u8) and qemu-system-arm version 5.2.50
  (v5.2.0-1579-g99ae0cd90d).

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



Re: [PATCH] spice-app: avoid crash when core spice module doesn't loaded

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/13/21 4:23 AM, Bruce Rogers wrote:
> When qemu is built with modules, but a given module doesn't load
> qemu should handle that gracefully. When ui-spice-core.so isn't
> able to be loaded and qemu is invoked with -display spice-app or
> -spice, qemu will dereference a null pointer. With this change we
> check the pointer before dereferencing and error out in a normal
> way.
> 
> Signed-off-by: Bruce Rogers 
> ---
>  ui/spice-app.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé 




Re: [RFC v18 01/15] i386: split cpu accelerators from cpu.c, using AccelCPUClass

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:

> i386 is the first user of AccelCPUClass, allowing to split
> cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c   host x86 cpu functions and "host" cpu type
> kvm/kvm-cpu.cKVM x86 AccelCPUClass
> hvf/hvf-cpu.cHVF x86 AccelCPUClass
> tcg/tcg-cpu.cTCG x86 AccelCPUClass
>
> Signed-off-by: Claudio Fontana 

Seems reasonable to me:

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH] tests/qemu-iotests: Remove test 259 from the "auto" group

2021-02-15 Thread Kevin Wolf
Am 15.02.2021 um 11:38 hat Thomas Huth geschrieben:
> Tests in the "auto" group should support qcow2 so that they can
> be run during "make check-block". Test 259 only supports "raw", so
> it currently always gets skipped when running "make check-block".
> Let's skip this unnecessary step and remove it from the auto group.
> 
> Signed-off-by: Thomas Huth 

And it's only nbd, too.

Thanks, applied to the block branch.

Kevin




Re: [RFC v18 02/15] cpu: call AccelCPUClass::cpu_realizefn in cpu_exec_realizefn

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:

> move the call to accel_cpu->cpu_realizefn to the general
> cpu_exec_realizefn from target/i386, so it does not need to be
> called for every target explicitly as we enable more targets.
>
> Signed-off-by: Claudio Fontana 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Peter Lieven

Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:

On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:

even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.

We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:

   https://qemu.readthedocs.io/en/latest/system/build-platforms.html

At this time RHEL-7 is usually the oldest platform, and it
builds with RBD 10.2.5, so we can't bump the version to 12.2.

I'm afraid this patch has to be dropped.



I have asked exactly this question before I started work on this series and got 
reply

from Jason that he sees no problem in bumping to a release which is already 
unmaintained

for 3 years.


If qemu 6.0 is required to build on RHEL-7 than I am afraid we can abandon the 
whole series.


Peter





Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Peter Lieven

Am 15.02.21 um 11:19 schrieb Daniel P. Berrangé:

On Mon, Feb 15, 2021 at 11:11:23AM +0100, Kevin Wolf wrote:

Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:

even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.

Signed-off-by: Peter Lieven 
diff --git a/meson.build b/meson.build
index 5943aa8a51..02d263ad33 100644
--- a/meson.build
+++ b/meson.build
@@ -691,19 +691,24 @@ if not get_option('rbd').auto() or have_block
 required: get_option('rbd'),
 kwargs: static_kwargs)
if librados.found() and librbd.found()
-if cc.links('''
+result = cc.run('''

Doesn't running compiled binaries break cross compilation?


#include 
#include 
int main(void) {
  rados_t cluster;
  rados_create(&cluster, NULL);
+rados_shutdown(cluster);
+#if LIBRBD_VERSION_CODE < LIBRBD_VERSION(1, 12, 0)
+return 1;
+#endif
  return 0;

Would #error achieve what you want without running the binary?

But most, if not all, other version checks use pkg-config instead of
trying to compile code, so that's probably what we should be doing here,
too.

Yep, for something that is merely a version number check there's no
need to compile anything. pkg-config can just validate the version
straightup.



I would have loved to, but at least the Ubuntu/Debian packages do not contain

pkg-config files. I can switch to #error, of course. My initial version of the 
patch

distinguished between can't compile and version is too old. With #error we just

can say doesn't compile, but I think this would be ok.


Peter





Re: [RFC v18 03/15] accel: introduce new accessor functions

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:

> avoid open coding the accesses to cpu->accel_cpu interfaces,
> and instead introduce:
>
> accel_cpu_instance_init,
> accel_cpu_realizefn
>
> to be used by the targets/ initfn code,
> and by cpu_exec_realizefn respectively.
>
> Signed-off-by: Claudio Fontana 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [RFC v18 06/15] meson: add target_user_arch

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:

> the lack of target_user_arch makes it hard to fully leverage the
> build system in order to separate user code from softmmu code.
>
> Provide it, so that we can avoid the proliferation of #ifdef
> in target code.
>
> Signed-off-by: Claudio Fontana 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [RFC v18 00/15] i386 cleanup PART 2

2021-02-15 Thread Alex Bennée


Claudio Fontana  writes:


> Looking forward to your comments on this proposal,
>


So I've reviewed as much as I'm comfortable with - I'm going to defer to
the x86 experts on the split of stuff for x86. However from my point of
view I think it's a nice step in improving modularity and reducing the
maze of #ifdefs in the code.

-- 
Alex Bennée



Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns

2021-02-15 Thread Kevin Wolf
Am 13.01.2021 um 15:15 hat Stefan Hajnoczi geschrieben:
> On Wed, Jan 13, 2021 at 01:51:17PM +0100, BALATON Zoltan wrote:
> > On Wed, 13 Jan 2021, Stefan Hajnoczi wrote:
> > > On Tue, Jan 12, 2021 at 09:44:03PM +0100, BALATON Zoltan wrote:
> > > > On Tue, 12 Jan 2021, Stefan Hajnoczi wrote:
> > > > > It is possible to repeat the --trace option to specify multiple
> > > > > patterns. This may be preferrable to users who do not want to create a
> > > > > file with a list of patterns.
> > > > > 
> > > > > Suggested-by: BALATON Zoltan 
> > > > > Signed-off-by: Stefan Hajnoczi 
> > > > > ---
> > > > > docs/devel/tracing.rst | 9 +++--
> > > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst
> > > > > index 4ebf8e38ea..8777c19d14 100644
> > > > > --- a/docs/devel/tracing.rst
> > > > > +++ b/docs/devel/tracing.rst
> > > > > @@ -22,10 +22,15 @@ events::
> > > > > This output comes from the "log" trace backend that is enabled by 
> > > > > default when
> > > > > ``./configure --enable-trace-backends=BACKENDS`` was not explicitly 
> > > > > specified.
> > > > > 
> > > > > -More than one trace event pattern can be specified by providing a 
> > > > > file
> > > > > -instead::
> > > > > +Multiple patterns can be specified by repeating the ``--trace`` 
> > > > > option::
> > > > > +
> > > > > +$ qemu --trace "kvm_*" --trace "virtio_*" ...
> > > > 
> > > > QEMU options are single dash with double dash accepted for 
> > > > compatibility but
> > > > help and other docs have single dash so these (and below) should be 
> > > > -trace.
> > > > (Also a bit less typing for otherwise already way too long command 
> > > > lines.)
> > > 
> > > Is this documented somewhere?
> > 
> > Maybe qemu-system-* -help ?
> 
> I mean developer documentation like CODING_STYLE.rst so we can point to
> that when someone submits a patch that does not use the preferred
> syntax.
> 
> > > I was under the impression that '-' is legacy syntax and '--' is the
> > > preferred syntax. There are examples of '--' on the QEMU man page.
> > 
> > -- is also accepted but they are the same as single dash options. Some tools
> > may have -- syntax preferred but not QEMU itself. If so that may be an
> > inconsistency.
> > 
> > > Let's reach agreement, document it, and then make the documentation
> > > consistent.
> > 
> > Since we don't have long and short arguments for the same options (like
> > -m,--memory) I think -- does not make much sense. Also single dash is less
> > typing and there are other programs using the same convention (e.g. whole X
> > Window System) so I think the current one dash options are fine and should
> > be kept consistent. As long as we can agree on this I can agree with that.
> > :-)
> 
> I'm fine with either (or even using both interchangeably) but want to
> make sure it's agreed for all of QEMU so we can really follow it and
> don't need to spend time on it in the future.
> 
> Kevin: You used '--' in qemu-storage-daemon --help. Does this mean you
> want QEMU to stop using '-'?

qemu-storage-daemon just follows the example of the other tools which
use getopt() instead of a hand-written parser, which means that in all
of the tools, long options require '--'.

I don't have a strong opinion about '-' in the system emulator, though
if I tried out dropping it, I guess I'd find my muscle memory does have
one.

Kevin


signature.asc
Description: PGP signature


Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Daniel P . Berrangé
On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
> Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
> > On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
> > > even luminous (version 12.2) is unmaintained for over 3 years now.
> > > Bump the requirement to get rid of the ifdef'ry in the code.
> > We have clear rules on when we bump minimum versions, determined by
> > the OS platforms we target:
> > 
> >https://qemu.readthedocs.io/en/latest/system/build-platforms.html
> > 
> > At this time RHEL-7 is usually the oldest platform, and it
> > builds with RBD 10.2.5, so we can't bump the version to 12.2.
> > 
> > I'm afraid this patch has to be dropped.
> 
> 
> I have asked exactly this question before I started work on this series and 
> got reply
> 
> from Jason that he sees no problem in bumping to a release which is already 
> unmaintained
> 
> for 3 years.

I'm afraid Jason is wrong here.  It doesn't matter what the upstream
consider the support status to be. QEMU targets what the OS vendors
ship, and they still consider this to be a supported version.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [RFC PATCH 34/42] gitlab-ci: Build MIPS R5900 cross-toolchain (Gentoo based)

2021-02-15 Thread Philippe Mathieu-Daudé
On 2/14/21 6:59 PM, Philippe Mathieu-Daudé wrote:
> Add a job to build the Gentoo based MIPS R5900 cross-toolchain image.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .gitlab-ci.d/containers.yml | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
> index 587bd4ba2e3..f441e608446 100644
> --- a/.gitlab-ci.d/containers.yml
> +++ b/.gitlab-ci.d/containers.yml
> @@ -152,6 +152,13 @@ mipsel-debian-cross-container:
>variables:
>  NAME: debian-mipsel-cross
>  
> +mipsr5900el-gentoo-cross-container:
> +  <<: *container_job_definition
> +  variables:
> +NAME: gentoo-mipsr5900el-cross
> +EXTRA_FILES: 
> tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
> +  timeout: 1h 30m

Well, depending of the runner hardware / load, this is not
enough:

Duration: 132 minutes 17 seconds
https://gitlab.com/philmd/qemu/-/jobs/1029975495

I'll use "2h 30" instead. I'm still looking how to make this job
optional (or manual).



Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Peter Lieven

Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:

On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:

Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:

On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:

even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.

We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:

https://qemu.readthedocs.io/en/latest/system/build-platforms.html

At this time RHEL-7 is usually the oldest platform, and it
builds with RBD 10.2.5, so we can't bump the version to 12.2.

I'm afraid this patch has to be dropped.


I have asked exactly this question before I started work on this series and got 
reply

from Jason that he sees no problem in bumping to a release which is already 
unmaintained

for 3 years.

I'm afraid Jason is wrong here.  It doesn't matter what the upstream
consider the support status to be. QEMU targets what the OS vendors
ship, and they still consider this to be a supported version.



Okay, but the whole coroutine stuff would get a total mess with all the 
ifdef'ry.

Would it be an option to make a big ifdef in the rbd driver? One with old code for 
< 12.0.0 and one

with new code for >= 12.0.0?


Peter





Re: [PATCH V2 4/7] block/rbd: add bdrv_attach_aio_context

2021-02-15 Thread Peter Lieven

Am 15.02.21 um 11:20 schrieb Kevin Wolf:

Am 26.01.2021 um 12:25 hat Peter Lieven geschrieben:

Signed-off-by: Peter Lieven 
---
  block/rbd.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/block/rbd.c b/block/rbd.c
index f68ebcf240..7abd0252c9 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -91,6 +91,7 @@ typedef struct BDRVRBDState {
  char *namespace;
  uint64_t image_size;
  uint64_t object_size;
+AioContext *aio_context;
  } BDRVRBDState;

A commit message explaining the why would be helpful here.

This is already stored in BlockDriverState, which should be available
everywhere. Keeping redundant information needs a good justification,
which seems unlikely when BlockDriverState and BDRVRBDState are already
connected through the BlockDriverState.opaque pointer.

The rest of the series doesn't seem to make more use of it either.



You are right. I was not aware that the aio_context is already there.

We keep a local copy of aio_context in iscsi and nfs driver as well. That

is where I got it from. I will change it if we don't drop the series completely.


Peter






Re: [RFC v18 00/15] i386 cleanup PART 2

2021-02-15 Thread Claudio Fontana
On 2/15/21 12:37 PM, Alex Bennée wrote:
> 
> Claudio Fontana  writes:
> 
> 
>> Looking forward to your comments on this proposal,
>>
> 
> 
> So I've reviewed as much as I'm comfortable with - I'm going to defer to
> the x86 experts on the split of stuff for x86. However from my point of
> view I think it's a nice step in improving modularity and reducing the
> maze of #ifdefs in the code.
> 

Thanks a lot Alex for your review.

If I can leverage your TCG knowledge a bit more, as I forgot a lot about it,

have you noticed in "i386: split tcg btp_helper into softmmu and user parts"
and "i386: split smm helper (softmmu)"

those new

#ifndef CONFIG_USER_ONLY?

Basically we remove some preamble stuff that would end up calling empty stubs 
for user mode,
but do you think there could be some other consequence I am not seeing?

Maybe there is even more that could be removed in the code immediately 
preceding those CONFIG_USER_ONLY?

In particular I am referring to patches:

  i386: split tcg btp_helper into softmmu and user parts
  i386: split smm helper (softmmu)

I am commenting those patches now inline, so that it is easier to see what I am 
talking about.

Again, thanks a lot!

Claudio



Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release

2021-02-15 Thread Daniel P . Berrangé
On Mon, Feb 15, 2021 at 12:45:01PM +0100, Peter Lieven wrote:
> Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:
> > On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
> > > Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
> > > > On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
> > > > > even luminous (version 12.2) is unmaintained for over 3 years now.
> > > > > Bump the requirement to get rid of the ifdef'ry in the code.
> > > > We have clear rules on when we bump minimum versions, determined by
> > > > the OS platforms we target:
> > > > 
> > > > https://qemu.readthedocs.io/en/latest/system/build-platforms.html
> > > > 
> > > > At this time RHEL-7 is usually the oldest platform, and it
> > > > builds with RBD 10.2.5, so we can't bump the version to 12.2.
> > > > 
> > > > I'm afraid this patch has to be dropped.
> > > 
> > > I have asked exactly this question before I started work on this series 
> > > and got reply
> > > 
> > > from Jason that he sees no problem in bumping to a release which is 
> > > already unmaintained
> > > 
> > > for 3 years.
> > I'm afraid Jason is wrong here.  It doesn't matter what the upstream
> > consider the support status to be. QEMU targets what the OS vendors
> > ship, and they still consider this to be a supported version.
> 
> 
> Okay, but the whole coroutine stuff would get a total mess with all the 
> ifdef'ry.

Doesn't seem like the write zeros code is adding much more comapred to
the ifdefs that already exist... 


> Would it be an option to make a big ifdef in the rbd driver? One with old 
> code for < 12.0.0 and one
> 
> with new code for >= 12.0.0?

..but I don't have a strong opinion on that, since I'm not maintaining this
driver.


BTW, we will be free to drop RHEL-7 in the next development cycle of
QEMU, starting after the forthcoming 6.0.0 release is out, as it will
fall out of our OS support matrix.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [RFC v18 08/15] i386: split smm helper (softmmu)

2021-02-15 Thread Claudio Fontana
On 2/12/21 1:36 PM, Claudio Fontana wrote:
> smm is only really useful for softmmu, split in two modules
> around the CONFIG_USER_ONLY, in order to remove the ifdef
> and use the build system instead.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/i386/helper.h   |  4 
>  target/i386/tcg/seg_helper.c   |  2 ++
>  target/i386/tcg/{ => softmmu}/smm_helper.c | 19 ++-
>  target/i386/tcg/translate.c|  2 ++
>  target/i386/tcg/meson.build|  1 -
>  target/i386/tcg/softmmu/meson.build|  1 +
>  6 files changed, 11 insertions(+), 18 deletions(-)
>  rename target/i386/tcg/{ => softmmu}/smm_helper.c (98%)
> 
> diff --git a/target/i386/helper.h b/target/i386/helper.h
> index c2ae2f7e61..8ffda4cdc6 100644
> --- a/target/i386/helper.h
> +++ b/target/i386/helper.h
> @@ -70,7 +70,11 @@ DEF_HELPER_1(clac, void, env)
>  DEF_HELPER_1(stac, void, env)
>  DEF_HELPER_3(boundw, void, env, tl, int)
>  DEF_HELPER_3(boundl, void, env, tl, int)
> +
> +#ifndef CONFIG_USER_ONLY
>  DEF_HELPER_1(rsm, void, env)
> +#endif /* !CONFIG_USER_ONLY */
> +
>  DEF_HELPER_2(into, void, env, int)
>  DEF_HELPER_2(cmpxchg8b_unlocked, void, env, tl)
>  DEF_HELPER_2(cmpxchg8b, void, env, tl)
> diff --git a/target/i386/tcg/seg_helper.c b/target/i386/tcg/seg_helper.c
> index 180d47f0e9..f0cb1bffe7 100644
> --- a/target/i386/tcg/seg_helper.c
> +++ b/target/i386/tcg/seg_helper.c
> @@ -1351,7 +1351,9 @@ bool x86_cpu_exec_interrupt(CPUState *cs, int 
> interrupt_request)
>  case CPU_INTERRUPT_SMI:
>  cpu_svm_check_intercept_param(env, SVM_EXIT_SMI, 0, 0);
>  cs->interrupt_request &= ~CPU_INTERRUPT_SMI;
> +#ifndef CONFIG_USER_ONLY
>  do_smm_enter(cpu);
> +#endif
>  break;
>  case CPU_INTERRUPT_NMI:
>  cpu_svm_check_intercept_param(env, SVM_EXIT_NMI, 0, 0);
> diff --git a/target/i386/tcg/smm_helper.c 
> b/target/i386/tcg/softmmu/smm_helper.c
> similarity index 98%
> rename from target/i386/tcg/smm_helper.c
> rename to target/i386/tcg/softmmu/smm_helper.c
> index 62d027abd3..ee53b26629 100644
> --- a/target/i386/tcg/smm_helper.c
> +++ b/target/i386/tcg/softmmu/smm_helper.c
> @@ -1,5 +1,5 @@
>  /*
> - *  x86 SMM helpers
> + *  x86 SMM helpers (softmmu-only)
>   *
>   *  Copyright (c) 2003 Fabrice Bellard
>   *
> @@ -18,27 +18,14 @@
>   */
>  
>  #include "qemu/osdep.h"
> -#include "qemu/main-loop.h"
>  #include "cpu.h"
>  #include "exec/helper-proto.h"
>  #include "exec/log.h"
> -#include "helper-tcg.h"
> +#include "tcg/helper-tcg.h"
>  
>  
>  /* SMM support */
>  
> -#if defined(CONFIG_USER_ONLY)
> -
> -void do_smm_enter(X86CPU *cpu)
> -{
> -}
> -
> -void helper_rsm(CPUX86State *env)
> -{
> -}
> -
> -#else
> -
>  #ifdef TARGET_X86_64
>  #define SMM_REVISION_ID 0x00020064
>  #else
> @@ -330,5 +317,3 @@ void helper_rsm(CPUX86State *env)
>  qemu_log_mask(CPU_LOG_INT, "SMM: after RSM\n");
>  log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), CPU_DUMP_CCOP);
>  }
> -
> -#endif /* !CONFIG_USER_ONLY */
> diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
> index af1faf9342..5075ac4830 100644
> --- a/target/i386/tcg/translate.c
> +++ b/target/i386/tcg/translate.c
> @@ -8321,7 +8321,9 @@ static target_ulong disas_insn(DisasContext *s, 
> CPUState *cpu)
>  goto illegal_op;
>  gen_update_cc_op(s);
>  gen_jmp_im(s, s->pc - s->cs_base);
> +#ifndef CONFIG_USER_ONLY
>  gen_helper_rsm(cpu_env);
> +#endif /* CONFIG_USER_ONLY */
>  gen_eob(s);
>  break;

Hello Alex,

this is something I wanted to bring in the foreground:

while before we were generating an empty helper call for CONFIG_USER_ONLY,
now we are not generating anything.



>  case 0x1b8: /* SSE4.2 popcnt */
> diff --git a/target/i386/tcg/meson.build b/target/i386/tcg/meson.build
> index 68fa0c3187..ec5daa1edc 100644
> --- a/target/i386/tcg/meson.build
> +++ b/target/i386/tcg/meson.build
> @@ -8,7 +8,6 @@ i386_ss.add(when: 'CONFIG_TCG', if_true: files(
>'misc_helper.c',
>'mpx_helper.c',
>'seg_helper.c',
> -  'smm_helper.c',
>'svm_helper.c',
>'tcg-cpu.c',
>'translate.c'), if_false: files('tcg-stub.c'))
> diff --git a/target/i386/tcg/softmmu/meson.build 
> b/target/i386/tcg/softmmu/meson.build
> index 4ab30cc32e..35ba16dc3d 100644
> --- a/target/i386/tcg/softmmu/meson.build
> +++ b/target/i386/tcg/softmmu/meson.build
> @@ -1,3 +1,4 @@
>  i386_softmmu_ss.add(when: ['CONFIG_TCG', 'CONFIG_SOFTMMU'], if_true: files(
>'tcg-cpu.c',
> +  'smm_helper.c',
>  ))
> 




[PATCH v2 00/24] hw/arm: New board model mps3-an524

2021-02-15 Thread Peter Maydell
This patchseries implements a new board model in the mps2/mps3 family,
based on Application Note AN524:
https://developer.arm.com/documentation/dai0524/latest/

v1->v2 changes (very minor):
 * renamed have-switches to has_switches
 * added missing initializations of num_leds and has_switches
   for new board model
Patches still needing review: 10 - 18, 20


Like the other MPS models, this board is an FPGA image; the AN524
image is based on the SSE-200, like the mps2-an521, but it is
for the MPS3 board rather than the MPS2+. The major differences
are QSPI flash and USB (which we don't model), and support for
2GB of RAM (which we do). Since the MPS3 is very similar to the
MPS2, I've implemented mps3-an524 as a subclass of TYPE_MPS2TZ_MACHINE,
sharing most of the code with mps2-an505 and mps2-an521.

The motivation for this model is two-fold:
 * Linaro's Zephyr team would like it, so they can test their
code targeting the MPS3 on QEMU
 * It's a useful stepping-stone towards a future MPS family model
   which uses the SSE-300 and Cortex-M55. All the "make various bits
   of mps2-tz.c be driven by per-board data structures rather than
   hardcoding them" changes will be needed for that future board model.
   This way they can be code-reviewed now, rather than making the
   future patchseries even bigger (it will be pretty large even so,
   because of all the "implement SSE-300 model" patches).

thanks
-- PMM


Peter Maydell (24):
  hw/arm/mps2-tz: Make SYSCLK frequency board-specific
  hw/misc/mps2-scc: Support configurable number of OSCCLK values
  hw/arm/mps2-tz: Correct the OSCCLK settings for mps2-an505 and
mps2-an511
  hw/arm/mps2-tz: Make the OSCCLK settings be configurable per-board
  hw/misc/mps2-fpgaio: Make number of LEDs configurable by board
  hw/misc/mps2-fpgaio: Support SWITCH register
  hw/arm/mps2-tz: Make FPGAIO switch and LED config per-board
  hw/arm/mps2-tz: Condition IRQ splitting on number of CPUs, not board
type
  hw/arm/mps2-tz: Make number of IRQs board-specific
  hw/misc/mps2-scc: Implement CFG_REG5 and CFG_REG6 for MPS3 AN524
  hw/arm/mps2-tz: Correct wrong interrupt numbers for DMA and SPI
  hw/arm/mps2-tz: Allow PPCPortInfo structures to specify device
interrupts
  hw/arm/mps2-tz: Move device IRQ info to data structures
  hw/arm/mps2-tz: Size the uart-irq-orgate based on the number of UARTs
  hw/arm/mps2-tz: Allow boards to have different PPCInfo data
  hw/arm/mps2-tz: Make RAM arrangement board-specific
  hw/arm/mps2-tz: Set MachineClass default_ram info from RAMInfo data
  hw/arm/mps2-tz: Support ROMs as well as RAMs
  hw/arm/mps2-tz: Get armv7m_load_kernel() size argument from RAMInfo
  hw/arm/mps2-tz: Add new mps3-an524 board
  hw/arm/mps2-tz: Stub out USB controller for mps3-an524
  hw/arm/mps2-tz: Provide PL031 RTC on mps3-an524
  docs/system/arm/mps2.rst: Document the new mps3-an524 board
  hw/arm/mps2: Update old infocenter.arm.com URLs

 docs/system/arm/mps2.rst |  24 +-
 include/hw/arm/armsse.h  |   4 +-
 include/hw/misc/armsse-cpuid.h   |   2 +-
 include/hw/misc/armsse-mhu.h |   2 +-
 include/hw/misc/iotkit-secctl.h  |   2 +-
 include/hw/misc/iotkit-sysctl.h  |   2 +-
 include/hw/misc/iotkit-sysinfo.h |   2 +-
 include/hw/misc/mps2-fpgaio.h|   8 +-
 include/hw/misc/mps2-scc.h   |  10 +-
 hw/arm/mps2-tz.c | 632 +--
 hw/arm/mps2.c|   5 +
 hw/misc/armsse-cpuid.c   |   2 +-
 hw/misc/armsse-mhu.c |   2 +-
 hw/misc/iotkit-sysctl.c  |   2 +-
 hw/misc/iotkit-sysinfo.c |   2 +-
 hw/misc/mps2-fpgaio.c|  43 ++-
 hw/misc/mps2-scc.c   |  93 -
 17 files changed, 680 insertions(+), 157 deletions(-)

-- 
2.20.1




[PATCH v2 02/24] hw/misc/mps2-scc: Support configurable number of OSCCLK values

2021-02-15 Thread Peter Maydell
Currently the MPS2 SCC device implements a fixed number of OSCCLK
values (3).  The variant of this device in the MPS3 AN524 board has 6
OSCCLK values.  Switch to using a PROP_ARRAY, which allows board code
to specify how large the OSCCLK array should be as well as its
values.

With a variable-length property array, the SCC no longer specifies
default values for the OSCCLKs, so we must set them explicitly in the
board code.  This defaults are actually incorrect for the an521 and
an505; we will correct this bug in a following patch.

This is a migration compatibility break for all the mps boards.

Signed-off-by: Peter Maydell 
---
It would be possible to avoid the compat break, but we've already
broken compat for the mps boards this release cycle (eg in commit
eeae0b2bf4e69de2) when we added Clock support to the armsse code, so
there's no point in trying to keep compat for this change.
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/misc/mps2-scc.h |  7 +++
 hw/arm/mps2-tz.c   |  5 +
 hw/arm/mps2.c  |  5 +
 hw/misc/mps2-scc.c | 24 +---
 4 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/include/hw/misc/mps2-scc.h b/include/hw/misc/mps2-scc.h
index f65d8732031..514da49f69e 100644
--- a/include/hw/misc/mps2-scc.h
+++ b/include/hw/misc/mps2-scc.h
@@ -19,8 +19,6 @@
 #define TYPE_MPS2_SCC "mps2-scc"
 OBJECT_DECLARE_SIMPLE_TYPE(MPS2SCC, MPS2_SCC)
 
-#define NUM_OSCCLK 3
-
 struct MPS2SCC {
 /*< private >*/
 SysBusDevice parent_obj;
@@ -39,8 +37,9 @@ struct MPS2SCC {
 uint32_t dll;
 uint32_t aid;
 uint32_t id;
-uint32_t oscclk[NUM_OSCCLK];
-uint32_t oscclk_reset[NUM_OSCCLK];
+uint32_t num_oscclk;
+uint32_t *oscclk;
+uint32_t *oscclk_reset;
 };
 
 #endif
diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 82ce6262817..7c066c11ed4 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -219,6 +219,11 @@ static MemoryRegion *make_scc(MPS2TZMachineState *mms, 
void *opaque,
 qdev_prop_set_uint32(sccdev, "scc-cfg4", 0x2);
 qdev_prop_set_uint32(sccdev, "scc-aid", 0x0028);
 qdev_prop_set_uint32(sccdev, "scc-id", mmc->scc_id);
+/* This will need to be per-FPGA image eventually */
+qdev_prop_set_uint32(sccdev, "len-oscclk", 3);
+qdev_prop_set_uint32(sccdev, "oscclk[0]", 5000);
+qdev_prop_set_uint32(sccdev, "oscclk[1]", 24576000);
+qdev_prop_set_uint32(sccdev, "oscclk[2]", 2500);
 sysbus_realize(SYS_BUS_DEVICE(scc), &error_fatal);
 return sysbus_mmio_get_region(SYS_BUS_DEVICE(sccdev), 0);
 }
diff --git a/hw/arm/mps2.c b/hw/arm/mps2.c
index 39add416db5..81413b7133e 100644
--- a/hw/arm/mps2.c
+++ b/hw/arm/mps2.c
@@ -373,6 +373,11 @@ static void mps2_common_init(MachineState *machine)
 qdev_prop_set_uint32(sccdev, "scc-cfg4", 0x2);
 qdev_prop_set_uint32(sccdev, "scc-aid", 0x0028);
 qdev_prop_set_uint32(sccdev, "scc-id", mmc->scc_id);
+/* All these FPGA images have the same OSCCLK configuration */
+qdev_prop_set_uint32(sccdev, "len-oscclk", 3);
+qdev_prop_set_uint32(sccdev, "oscclk[0]", 5000);
+qdev_prop_set_uint32(sccdev, "oscclk[1]", 24576000);
+qdev_prop_set_uint32(sccdev, "oscclk[2]", 2500);
 sysbus_realize(SYS_BUS_DEVICE(&mms->scc), &error_fatal);
 sysbus_mmio_map(SYS_BUS_DEVICE(sccdev), 0, 0x4002f000);
 object_initialize_child(OBJECT(mms), "fpgaio",
diff --git a/hw/misc/mps2-scc.c b/hw/misc/mps2-scc.c
index ce1dfe93562..52a4e183b71 100644
--- a/hw/misc/mps2-scc.c
+++ b/hw/misc/mps2-scc.c
@@ -57,7 +57,7 @@ static bool scc_cfg_write(MPS2SCC *s, unsigned function,
 {
 trace_mps2_scc_cfg_write(function, device, value);
 
-if (function != 1 || device >= NUM_OSCCLK) {
+if (function != 1 || device >= s->num_oscclk) {
 qemu_log_mask(LOG_GUEST_ERROR,
   "MPS2 SCC config write: bad function %d device %d\n",
   function, device);
@@ -75,7 +75,7 @@ static bool scc_cfg_write(MPS2SCC *s, unsigned function,
 static bool scc_cfg_read(MPS2SCC *s, unsigned function,
  unsigned device, uint32_t *value)
 {
-if (function != 1 || device >= NUM_OSCCLK) {
+if (function != 1 || device >= s->num_oscclk) {
 qemu_log_mask(LOG_GUEST_ERROR,
   "MPS2 SCC config read: bad function %d device %d\n",
   function, device);
@@ -227,7 +227,7 @@ static void mps2_scc_reset(DeviceState *dev)
 s->cfgctrl = 0x10;
 s->cfgstat = 0;
 s->dll = 0x0001;
-for (i = 0; i < NUM_OSCCLK; i++) {
+for (i = 0; i < s->num_oscclk; i++) {
 s->oscclk[i] = s->oscclk_reset[i];
 }
 for (i = 0; i < ARRAY_SIZE(s->led); i++) {
@@ -254,12 +254,14 @@ static void mps2_scc_realize(DeviceState *dev, Error 
**errp)
   LED_COLOR_GREEN, name);
 g_free(name);
 }
+
+s->oscclk = g_new0(uint32_t, s->num_oscclk);
 }
 
 static const VMStateDescri

[PATCH v2 03/24] hw/arm/mps2-tz: Correct the OSCCLK settings for mps2-an505 and mps2-an511

2021-02-15 Thread Peter Maydell
We were previously using the default OSCCLK settings, which are
correct for the older MPS2 boards (mps2-an385, mps2-an386,
mps2-an500, mps2-an511), but wrong for the mps2-an505 and mps2-511
implemented in mps2-tz.c.  Now we're setting the values explicitly we
can fix them to be correct.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 7c066c11ed4..976f5f5c682 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -221,8 +221,8 @@ static MemoryRegion *make_scc(MPS2TZMachineState *mms, void 
*opaque,
 qdev_prop_set_uint32(sccdev, "scc-id", mmc->scc_id);
 /* This will need to be per-FPGA image eventually */
 qdev_prop_set_uint32(sccdev, "len-oscclk", 3);
-qdev_prop_set_uint32(sccdev, "oscclk[0]", 5000);
-qdev_prop_set_uint32(sccdev, "oscclk[1]", 24576000);
+qdev_prop_set_uint32(sccdev, "oscclk[0]", 4000);
+qdev_prop_set_uint32(sccdev, "oscclk[1]", 2458);
 qdev_prop_set_uint32(sccdev, "oscclk[2]", 2500);
 sysbus_realize(SYS_BUS_DEVICE(scc), &error_fatal);
 return sysbus_mmio_get_region(SYS_BUS_DEVICE(sccdev), 0);
-- 
2.20.1




[PATCH v2 10/24] hw/misc/mps2-scc: Implement CFG_REG5 and CFG_REG6 for MPS3 AN524

2021-02-15 Thread Peter Maydell
The AN524 version of the SCC interface has different behaviour for
some of the CFG registers; implement it.

Each board in this family can have minor differences in the meaning
of the CFG registers, so rather than trying to specify all the
possible semantics via individual device properties, we make the
behaviour conditional on the part-number field of the SCC_ID register
which the board code already passes us.

For the AN524, the differences are:
 * CFG3 is reserved rather than being board switches
 * CFG5 is a new register ("ACLK Frequency in Hz")
 * CFG6 is a new register ("Clock divider for BRAM")

We implement both of the new registers as reads-as-written.

Signed-off-by: Peter Maydell 
---
 include/hw/misc/mps2-scc.h |  3 ++
 hw/misc/mps2-scc.c | 71 --
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/include/hw/misc/mps2-scc.h b/include/hw/misc/mps2-scc.h
index 514da49f69e..49d070616aa 100644
--- a/include/hw/misc/mps2-scc.h
+++ b/include/hw/misc/mps2-scc.h
@@ -29,7 +29,10 @@ struct MPS2SCC {
 
 uint32_t cfg0;
 uint32_t cfg1;
+uint32_t cfg2;
 uint32_t cfg4;
+uint32_t cfg5;
+uint32_t cfg6;
 uint32_t cfgdata_rtn;
 uint32_t cfgdata_out;
 uint32_t cfgctrl;
diff --git a/hw/misc/mps2-scc.c b/hw/misc/mps2-scc.c
index 52a4e183b71..562ace06a58 100644
--- a/hw/misc/mps2-scc.c
+++ b/hw/misc/mps2-scc.c
@@ -31,8 +31,11 @@
 
 REG32(CFG0, 0)
 REG32(CFG1, 4)
+REG32(CFG2, 8)
 REG32(CFG3, 0xc)
 REG32(CFG4, 0x10)
+REG32(CFG5, 0x14)
+REG32(CFG6, 0x18)
 REG32(CFGDATA_RTN, 0xa0)
 REG32(CFGDATA_OUT, 0xa4)
 REG32(CFGCTRL, 0xa8)
@@ -49,6 +52,12 @@ REG32(DLL, 0x100)
 REG32(AID, 0xFF8)
 REG32(ID, 0xFFC)
 
+static int scc_partno(MPS2SCC *s)
+{
+/* Return the partno field of the SCC_ID (0x524, 0x511, etc) */
+return extract32(s->id, 4, 8);
+}
+
 /* Handle a write via the SYS_CFG channel to the specified function/device.
  * Return false on error (reported to guest via SYS_CFGCTRL ERROR bit).
  */
@@ -100,7 +109,18 @@ static uint64_t mps2_scc_read(void *opaque, hwaddr offset, 
unsigned size)
 case A_CFG1:
 r = s->cfg1;
 break;
+case A_CFG2:
+if (scc_partno(s) != 0x524) {
+/* CFG2 reserved on other boards */
+goto bad_offset;
+}
+r = s->cfg2;
+break;
 case A_CFG3:
+if (scc_partno(s) == 0x524) {
+/* CFG3 reserved on AN524 */
+goto bad_offset;
+}
 /* These are user-settable DIP switches on the board. We don't
  * model that, so just return zeroes.
  */
@@ -109,6 +129,20 @@ static uint64_t mps2_scc_read(void *opaque, hwaddr offset, 
unsigned size)
 case A_CFG4:
 r = s->cfg4;
 break;
+case A_CFG5:
+if (scc_partno(s) != 0x524) {
+/* CFG5 reserved on other boards */
+goto bad_offset;
+}
+r = s->cfg5;
+break;
+case A_CFG6:
+if (scc_partno(s) != 0x524) {
+/* CFG6 reserved on other boards */
+goto bad_offset;
+}
+r = s->cfg6;
+break;
 case A_CFGDATA_RTN:
 r = s->cfgdata_rtn;
 break;
@@ -131,6 +165,7 @@ static uint64_t mps2_scc_read(void *opaque, hwaddr offset, 
unsigned size)
 r = s->id;
 break;
 default:
+bad_offset:
 qemu_log_mask(LOG_GUEST_ERROR,
   "MPS2 SCC read: bad offset %x\n", (int) offset);
 r = 0;
@@ -159,6 +194,30 @@ static void mps2_scc_write(void *opaque, hwaddr offset, 
uint64_t value,
 led_set_state(s->led[i], extract32(value, i, 1));
 }
 break;
+case A_CFG2:
+if (scc_partno(s) != 0x524) {
+/* CFG2 reserved on other boards */
+goto bad_offset;
+}
+/* AN524: QSPI Select signal */
+s->cfg2 = value;
+break;
+case A_CFG5:
+if (scc_partno(s) != 0x524) {
+/* CFG5 reserved on other boards */
+goto bad_offset;
+}
+/* AN524: ACLK frequency in Hz */
+s->cfg5 = value;
+break;
+case A_CFG6:
+if (scc_partno(s) != 0x524) {
+/* CFG6 reserved on other boards */
+goto bad_offset;
+}
+/* AN524: Clock divider for BRAM */
+s->cfg6 = value;
+break;
 case A_CFGDATA_OUT:
 s->cfgdata_out = value;
 break;
@@ -202,6 +261,7 @@ static void mps2_scc_write(void *opaque, hwaddr offset, 
uint64_t value,
 s->dll = deposit32(s->dll, 24, 8, extract32(value, 24, 8));
 break;
 default:
+bad_offset:
 qemu_log_mask(LOG_GUEST_ERROR,
   "MPS2 SCC write: bad offset 0x%x\n", (int) offset);
 break;
@@ -222,6 +282,9 @@ static void mps2_scc_reset(DeviceState *dev)
 trace_mps2_scc_reset();
 s->cfg0 = 0;
 s->cfg1 = 0;
+s->cfg2 = 0;
+s->cfg5 = 0;
+s->cfg6 = 0;
 s->cfgdata_rtn

[PATCH v2 01/24] hw/arm/mps2-tz: Make SYSCLK frequency board-specific

2021-02-15 Thread Peter Maydell
The AN524 has a different SYSCLK frequency from the AN505 and AN521;
make the SYSCLK frequency a field in the MPS2TZMachineClass rather
than a compile-time constant so we can support the AN524.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 90caa914934..82ce6262817 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -76,6 +76,7 @@ struct MPS2TZMachineClass {
 MachineClass parent;
 MPS2TZFPGAType fpga_type;
 uint32_t scc_id;
+uint32_t sysclk_frq; /* Main SYSCLK frequency in Hz */
 const char *armsse_type;
 };
 
@@ -111,8 +112,6 @@ struct MPS2TZMachineState {
 
 OBJECT_DECLARE_TYPE(MPS2TZMachineState, MPS2TZMachineClass, MPS2TZ_MACHINE)
 
-/* Main SYSCLK frequency in Hz */
-#define SYSCLK_FRQ 2000
 /* Slow 32Khz S32KCLK frequency in Hz */
 #define S32KCLK_FRQ (32 * 1000)
 
@@ -186,6 +185,7 @@ static MemoryRegion *make_unimp_dev(MPS2TZMachineState *mms,
 static MemoryRegion *make_uart(MPS2TZMachineState *mms, void *opaque,
const char *name, hwaddr size)
 {
+MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 CMSDKAPBUART *uart = opaque;
 int i = uart - &mms->uart[0];
 int rxirqno = i * 2;
@@ -196,7 +196,7 @@ static MemoryRegion *make_uart(MPS2TZMachineState *mms, 
void *opaque,
 
 object_initialize_child(OBJECT(mms), name, uart, TYPE_CMSDK_APB_UART);
 qdev_prop_set_chr(DEVICE(uart), "chardev", serial_hd(i));
-qdev_prop_set_uint32(DEVICE(uart), "pclk-frq", SYSCLK_FRQ);
+qdev_prop_set_uint32(DEVICE(uart), "pclk-frq", mmc->sysclk_frq);
 sysbus_realize(SYS_BUS_DEVICE(uart), &error_fatal);
 s = SYS_BUS_DEVICE(uart);
 sysbus_connect_irq(s, 0, get_sse_irq_in(mms, txirqno));
@@ -403,7 +403,7 @@ static void mps2tz_common_init(MachineState *machine)
 
 /* These clocks don't need migration because they are fixed-frequency */
 mms->sysclk = clock_new(OBJECT(machine), "SYSCLK");
-clock_set_hz(mms->sysclk, SYSCLK_FRQ);
+clock_set_hz(mms->sysclk, mmc->sysclk_frq);
 mms->s32kclk = clock_new(OBJECT(machine), "S32KCLK");
 clock_set_hz(mms->s32kclk, S32KCLK_FRQ);
 
@@ -670,6 +670,7 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->fpga_type = FPGA_AN505;
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m33");
 mmc->scc_id = 0x41045050;
+mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
 mmc->armsse_type = TYPE_IOTKIT;
 }
 
@@ -685,6 +686,7 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->fpga_type = FPGA_AN521;
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m33");
 mmc->scc_id = 0x41045210;
+mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
 mmc->armsse_type = TYPE_SSE200;
 }
 
-- 
2.20.1




[PATCH v2 05/24] hw/misc/mps2-fpgaio: Make number of LEDs configurable by board

2021-02-15 Thread Peter Maydell
The MPS2 board has 2 LEDs, but the MPS3 board has 10 LEDs.  The
FPGAIO device is similar on both sets of boards, but the LED0
register has correspondingly more bits that have an effect.  Add a
device property for number of LEDs.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/misc/mps2-fpgaio.h |  5 -
 hw/misc/mps2-fpgaio.c | 31 +++
 2 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/include/hw/misc/mps2-fpgaio.h b/include/hw/misc/mps2-fpgaio.h
index a010fdb2b6d..bfe73134e78 100644
--- a/include/hw/misc/mps2-fpgaio.h
+++ b/include/hw/misc/mps2-fpgaio.h
@@ -28,13 +28,16 @@
 #define TYPE_MPS2_FPGAIO "mps2-fpgaio"
 OBJECT_DECLARE_SIMPLE_TYPE(MPS2FPGAIO, MPS2_FPGAIO)
 
+#define MPS2FPGAIO_MAX_LEDS 32
+
 struct MPS2FPGAIO {
 /*< private >*/
 SysBusDevice parent_obj;
 
 /*< public >*/
 MemoryRegion iomem;
-LEDState *led[2];
+LEDState *led[MPS2FPGAIO_MAX_LEDS];
+uint32_t num_leds;
 
 uint32_t led0;
 uint32_t prescale;
diff --git a/hw/misc/mps2-fpgaio.c b/hw/misc/mps2-fpgaio.c
index 6af0e8f837a..b28a1be22cc 100644
--- a/hw/misc/mps2-fpgaio.c
+++ b/hw/misc/mps2-fpgaio.c
@@ -177,9 +177,14 @@ static void mps2_fpgaio_write(void *opaque, hwaddr offset, 
uint64_t value,
 
 switch (offset) {
 case A_LED0:
-s->led0 = value & 0x3;
-led_set_state(s->led[0], value & 0x01);
-led_set_state(s->led[1], value & 0x02);
+if (s->num_leds != 0) {
+int i;
+
+s->led0 = value & MAKE_64BIT_MASK(0, s->num_leds);
+for (i = 0; i < s->num_leds; i++) {
+led_set_state(s->led[i], value & (1 << i));
+}
+}
 break;
 case A_PRESCALE:
 resync_counter(s);
@@ -238,7 +243,7 @@ static void mps2_fpgaio_reset(DeviceState *dev)
 s->pscntr = 0;
 s->pscntr_sync_ticks = now;
 
-for (size_t i = 0; i < ARRAY_SIZE(s->led); i++) {
+for (size_t i = 0; i < s->num_leds; i++) {
 device_cold_reset(DEVICE(s->led[i]));
 }
 }
@@ -256,11 +261,19 @@ static void mps2_fpgaio_init(Object *obj)
 static void mps2_fpgaio_realize(DeviceState *dev, Error **errp)
 {
 MPS2FPGAIO *s = MPS2_FPGAIO(dev);
+int i;
 
-s->led[0] = led_create_simple(OBJECT(dev), GPIO_POLARITY_ACTIVE_HIGH,
-  LED_COLOR_GREEN, "USERLED0");
-s->led[1] = led_create_simple(OBJECT(dev), GPIO_POLARITY_ACTIVE_HIGH,
-  LED_COLOR_GREEN, "USERLED1");
+if (s->num_leds > MPS2FPGAIO_MAX_LEDS) {
+error_setg(errp, "num-leds cannot be greater than %d",
+   MPS2FPGAIO_MAX_LEDS);
+return;
+}
+
+for (i = 0; i < s->num_leds; i++) {
+g_autofree char *ledname = g_strdup_printf("USERLED%d", i);
+s->led[i] = led_create_simple(OBJECT(dev), GPIO_POLARITY_ACTIVE_HIGH,
+  LED_COLOR_GREEN, ledname);
+}
 }
 
 static bool mps2_fpgaio_counters_needed(void *opaque)
@@ -303,6 +316,8 @@ static const VMStateDescription mps2_fpgaio_vmstate = {
 static Property mps2_fpgaio_properties[] = {
 /* Frequency of the prescale counter */
 DEFINE_PROP_UINT32("prescale-clk", MPS2FPGAIO, prescale_clk, 2000),
+/* Number of LEDs controlled by LED0 register */
+DEFINE_PROP_UINT32("num-leds", MPS2FPGAIO, num_leds, 2),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
2.20.1




[PATCH v2 04/24] hw/arm/mps2-tz: Make the OSCCLK settings be configurable per-board

2021-02-15 Thread Peter Maydell
The AN505 and AN511 happen to share the same OSCCLK values, but the
AN524 will have a different set (and more of them), so split the
settings out to be per-board.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 976f5f5c682..9add1453cc2 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -77,6 +77,8 @@ struct MPS2TZMachineClass {
 MPS2TZFPGAType fpga_type;
 uint32_t scc_id;
 uint32_t sysclk_frq; /* Main SYSCLK frequency in Hz */
+uint32_t len_oscclk;
+const uint32_t *oscclk;
 const char *armsse_type;
 };
 
@@ -115,6 +117,12 @@ OBJECT_DECLARE_TYPE(MPS2TZMachineState, 
MPS2TZMachineClass, MPS2TZ_MACHINE)
 /* Slow 32Khz S32KCLK frequency in Hz */
 #define S32KCLK_FRQ (32 * 1000)
 
+static const uint32_t an505_oscclk[] = {
+4000,
+2458,
+2500,
+};
+
 /* Create an alias of an entire original MemoryRegion @orig
  * located at @base in the memory map.
  */
@@ -213,17 +221,18 @@ static MemoryRegion *make_scc(MPS2TZMachineState *mms, 
void *opaque,
 MPS2SCC *scc = opaque;
 DeviceState *sccdev;
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
+int i;
 
 object_initialize_child(OBJECT(mms), "scc", scc, TYPE_MPS2_SCC);
 sccdev = DEVICE(scc);
 qdev_prop_set_uint32(sccdev, "scc-cfg4", 0x2);
 qdev_prop_set_uint32(sccdev, "scc-aid", 0x0028);
 qdev_prop_set_uint32(sccdev, "scc-id", mmc->scc_id);
-/* This will need to be per-FPGA image eventually */
-qdev_prop_set_uint32(sccdev, "len-oscclk", 3);
-qdev_prop_set_uint32(sccdev, "oscclk[0]", 4000);
-qdev_prop_set_uint32(sccdev, "oscclk[1]", 2458);
-qdev_prop_set_uint32(sccdev, "oscclk[2]", 2500);
+qdev_prop_set_uint32(sccdev, "len-oscclk", mmc->len_oscclk);
+for (i = 0; i < mmc->len_oscclk; i++) {
+g_autofree char *propname = g_strdup_printf("oscclk[%d]", i);
+qdev_prop_set_uint32(sccdev, propname, mmc->oscclk[i]);
+}
 sysbus_realize(SYS_BUS_DEVICE(scc), &error_fatal);
 return sysbus_mmio_get_region(SYS_BUS_DEVICE(sccdev), 0);
 }
@@ -676,6 +685,8 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m33");
 mmc->scc_id = 0x41045050;
 mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
+mmc->oscclk = an505_oscclk;
+mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
 mmc->armsse_type = TYPE_IOTKIT;
 }
 
@@ -692,6 +703,8 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m33");
 mmc->scc_id = 0x41045210;
 mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
+mmc->oscclk = an505_oscclk; /* AN521 is the same as AN505 here */
+mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
 mmc->armsse_type = TYPE_SSE200;
 }
 
-- 
2.20.1




[PATCH v2 18/24] hw/arm/mps2-tz: Support ROMs as well as RAMs

2021-02-15 Thread Peter Maydell
The AN505 and AN521 don't have any read-only memory, but the AN524
does; add a flag to ROMInfo to mark a region as ROM.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 08dd2cbaa40..cc9d70ece54 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -92,8 +92,10 @@ typedef struct RAMInfo {
  * Flag values:
  *  IS_ALIAS: this RAM area is an alias to the upstream end of the
  *MPC specified by its .mpc value
+ *  IS_ROM: this RAM area is read-only
  */
 #define IS_ALIAS 1
+#define IS_ROM 2
 
 struct MPS2TZMachineClass {
 MachineClass parent;
@@ -209,6 +211,7 @@ static MemoryRegion *mr_for_raminfo(MPS2TZMachineState *mms,
 if (raminfo->mrindex < 0) {
 /* Means this RAMInfo is for QEMU's "system memory" */
 MachineState *machine = MACHINE(mms);
+assert(!(raminfo->flags & IS_ROM));
 return machine->ram;
 }
 
@@ -217,6 +220,9 @@ static MemoryRegion *mr_for_raminfo(MPS2TZMachineState *mms,
 
 memory_region_init_ram(ram, NULL, raminfo->name,
raminfo->size, &error_fatal);
+if (raminfo->flags & IS_ROM) {
+memory_region_set_readonly(ram, true);
+}
 return ram;
 }
 
-- 
2.20.1




[PATCH v2 07/24] hw/arm/mps2-tz: Make FPGAIO switch and LED config per-board

2021-02-15 Thread Peter Maydell
Set the FPGAIO num-leds and have-switches properties explicitly
per-board, rather than relying on the defaults.  The AN505 and AN521
both have the same settings as the default values, but the AN524 will
be different.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 9add1453cc2..6e345cf1f09 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -79,6 +79,8 @@ struct MPS2TZMachineClass {
 uint32_t sysclk_frq; /* Main SYSCLK frequency in Hz */
 uint32_t len_oscclk;
 const uint32_t *oscclk;
+uint32_t fpgaio_num_leds; /* Number of LEDs in FPGAIO LED0 register */
+bool fpgaio_has_switches; /* Does FPGAIO have SWITCH register? */
 const char *armsse_type;
 };
 
@@ -241,8 +243,11 @@ static MemoryRegion *make_fpgaio(MPS2TZMachineState *mms, 
void *opaque,
  const char *name, hwaddr size)
 {
 MPS2FPGAIO *fpgaio = opaque;
+MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 
 object_initialize_child(OBJECT(mms), "fpgaio", fpgaio, TYPE_MPS2_FPGAIO);
+qdev_prop_set_uint32(DEVICE(fpgaio), "num-leds", mmc->fpgaio_num_leds);
+qdev_prop_set_bit(DEVICE(fpgaio), "has-switches", 
mmc->fpgaio_has_switches);
 sysbus_realize(SYS_BUS_DEVICE(fpgaio), &error_fatal);
 return sysbus_mmio_get_region(SYS_BUS_DEVICE(fpgaio), 0);
 }
@@ -687,6 +692,8 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
 mmc->oscclk = an505_oscclk;
 mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
+mmc->fpgaio_num_leds = 2;
+mmc->fpgaio_has_switches = false;
 mmc->armsse_type = TYPE_IOTKIT;
 }
 
@@ -705,6 +712,8 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->sysclk_frq = 20 * 1000 * 1000; /* 20MHz */
 mmc->oscclk = an505_oscclk; /* AN521 is the same as AN505 here */
 mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
+mmc->fpgaio_num_leds = 2;
+mmc->fpgaio_has_switches = false;
 mmc->armsse_type = TYPE_SSE200;
 }
 
-- 
2.20.1




[PATCH v2 12/24] hw/arm/mps2-tz: Allow PPCPortInfo structures to specify device interrupts

2021-02-15 Thread Peter Maydell
The mps2-tz code uses PPCPortInfo data structures to define what
devices are present and how they are wired up.  Currently we use
these to specify device types and addresses, but hard-code the
interrupt line wiring in each make_* helper function.  This works for
the two boards we have at the moment, but the AN524 has some devices
with different interrupt assignments.

This commit adds the framework to allow PPCPortInfo structures to
specify interrupt numbers.  We add an array of interrupt numbers to
the PPCPortInfo struct, and pass it through to the make_* helpers.
The following commit will change the make_* helpers over to using the
framework.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index ff8b7e5f1ae..085746ac3e6 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -170,7 +170,8 @@ static qemu_irq get_sse_irq_in(MPS2TZMachineState *mms, int 
irqno)
  * needs to be plugged into the downstream end of the PPC port.
  */
 typedef MemoryRegion *MakeDevFn(MPS2TZMachineState *mms, void *opaque,
-const char *name, hwaddr size);
+const char *name, hwaddr size,
+const int *irqs);
 
 typedef struct PPCPortInfo {
 const char *name;
@@ -178,6 +179,7 @@ typedef struct PPCPortInfo {
 void *opaque;
 hwaddr addr;
 hwaddr size;
+int irqs[3]; /* currently no device needs more IRQ lines than this */
 } PPCPortInfo;
 
 typedef struct PPCInfo {
@@ -186,8 +188,9 @@ typedef struct PPCInfo {
 } PPCInfo;
 
 static MemoryRegion *make_unimp_dev(MPS2TZMachineState *mms,
-   void *opaque,
-   const char *name, hwaddr size)
+void *opaque,
+const char *name, hwaddr size,
+const int *irqs)
 {
 /* Initialize, configure and realize a TYPE_UNIMPLEMENTED_DEVICE,
  * and return a pointer to its MemoryRegion.
@@ -202,7 +205,8 @@ static MemoryRegion *make_unimp_dev(MPS2TZMachineState *mms,
 }
 
 static MemoryRegion *make_uart(MPS2TZMachineState *mms, void *opaque,
-   const char *name, hwaddr size)
+   const char *name, hwaddr size,
+   const int *irqs)
 {
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 CMSDKAPBUART *uart = opaque;
@@ -227,7 +231,8 @@ static MemoryRegion *make_uart(MPS2TZMachineState *mms, 
void *opaque,
 }
 
 static MemoryRegion *make_scc(MPS2TZMachineState *mms, void *opaque,
-  const char *name, hwaddr size)
+  const char *name, hwaddr size,
+  const int *irqs)
 {
 MPS2SCC *scc = opaque;
 DeviceState *sccdev;
@@ -249,7 +254,8 @@ static MemoryRegion *make_scc(MPS2TZMachineState *mms, void 
*opaque,
 }
 
 static MemoryRegion *make_fpgaio(MPS2TZMachineState *mms, void *opaque,
- const char *name, hwaddr size)
+ const char *name, hwaddr size,
+ const int *irqs)
 {
 MPS2FPGAIO *fpgaio = opaque;
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
@@ -262,7 +268,8 @@ static MemoryRegion *make_fpgaio(MPS2TZMachineState *mms, 
void *opaque,
 }
 
 static MemoryRegion *make_eth_dev(MPS2TZMachineState *mms, void *opaque,
-  const char *name, hwaddr size)
+  const char *name, hwaddr size,
+  const int *irqs)
 {
 SysBusDevice *s;
 NICInfo *nd = &nd_table[0];
@@ -281,7 +288,8 @@ static MemoryRegion *make_eth_dev(MPS2TZMachineState *mms, 
void *opaque,
 }
 
 static MemoryRegion *make_mpc(MPS2TZMachineState *mms, void *opaque,
-  const char *name, hwaddr size)
+  const char *name, hwaddr size,
+  const int *irqs)
 {
 TZMPC *mpc = opaque;
 int i = mpc - &mms->ssram_mpc[0];
@@ -318,7 +326,8 @@ static MemoryRegion *make_mpc(MPS2TZMachineState *mms, void 
*opaque,
 }
 
 static MemoryRegion *make_dma(MPS2TZMachineState *mms, void *opaque,
-  const char *name, hwaddr size)
+  const char *name, hwaddr size,
+  const int *irqs)
 {
 PL080State *dma = opaque;
 int i = dma - &mms->dma[0];
@@ -373,7 +382,8 @@ static MemoryRegion *make_dma(MPS2TZMachineState *mms, void 
*opaque,
 }
 
 static MemoryRegion *make_spi(MPS2TZMachineState *mms, void *opaque,
-  const char *name, hwaddr size)
+  const char *name, hwaddr size,
+  const int *irq

[PATCH v2 06/24] hw/misc/mps2-fpgaio: Support SWITCH register

2021-02-15 Thread Peter Maydell
MPS3 boards have an extra SWITCH register in the FPGAIO block which
reports the value of some switches.  Implement this, governed by a
property the board code can use to specify whether whether it exists.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/misc/mps2-fpgaio.h |  1 +
 hw/misc/mps2-fpgaio.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/include/hw/misc/mps2-fpgaio.h b/include/hw/misc/mps2-fpgaio.h
index bfe73134e78..0d3c8eef56c 100644
--- a/include/hw/misc/mps2-fpgaio.h
+++ b/include/hw/misc/mps2-fpgaio.h
@@ -38,6 +38,7 @@ struct MPS2FPGAIO {
 MemoryRegion iomem;
 LEDState *led[MPS2FPGAIO_MAX_LEDS];
 uint32_t num_leds;
+bool has_switches;
 
 uint32_t led0;
 uint32_t prescale;
diff --git a/hw/misc/mps2-fpgaio.c b/hw/misc/mps2-fpgaio.c
index b28a1be22cc..acbd0be9f4b 100644
--- a/hw/misc/mps2-fpgaio.c
+++ b/hw/misc/mps2-fpgaio.c
@@ -35,6 +35,7 @@ REG32(CLK100HZ, 0x14)
 REG32(COUNTER, 0x18)
 REG32(PRESCALE, 0x1c)
 REG32(PSCNTR, 0x20)
+REG32(SWITCH, 0x28)
 REG32(MISC, 0x4c)
 
 static uint32_t counter_from_tickoff(int64_t now, int64_t tick_offset, int frq)
@@ -156,7 +157,15 @@ static uint64_t mps2_fpgaio_read(void *opaque, hwaddr 
offset, unsigned size)
 resync_counter(s);
 r = s->pscntr;
 break;
+case A_SWITCH:
+if (!s->has_switches) {
+goto bad_offset;
+}
+/* User-togglable board switches. We don't model that, so report 0. */
+r = 0;
+break;
 default:
+bad_offset:
 qemu_log_mask(LOG_GUEST_ERROR,
   "MPS2 FPGAIO read: bad offset %x\n", (int) offset);
 r = 0;
@@ -318,6 +327,7 @@ static Property mps2_fpgaio_properties[] = {
 DEFINE_PROP_UINT32("prescale-clk", MPS2FPGAIO, prescale_clk, 2000),
 /* Number of LEDs controlled by LED0 register */
 DEFINE_PROP_UINT32("num-leds", MPS2FPGAIO, num_leds, 2),
+DEFINE_PROP_BOOL("has-switches", MPS2FPGAIO, has_switches, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
2.20.1




[PATCH v2 20/24] hw/arm/mps2-tz: Add new mps3-an524 board

2021-02-15 Thread Peter Maydell
Add support for the mps3-an524 board; this is an SSE-200 based FPGA
image, like the existing mps2-an521.  It has a usefully larger amount
of RAM, and a PL031 RTC, as well as some more minor differences.

In real hardware this image runs on a newer generation of the FPGA
board, the MPS3 rather than the older MPS2.  Architecturally the two
boards are similar, so we implement the MPS3 boards in the mps2-tz.c
file as variations of the existing MPS2 boards.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 139 +--
 1 file changed, 135 insertions(+), 4 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index da27caa332d..5e12ee2c3d3 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -16,6 +16,7 @@
  * This source file covers the following FPGA images, for TrustZone cores:
  *  "mps2-an505" -- Cortex-M33 as documented in ARM Application Note AN505
  *  "mps2-an521" -- Dual Cortex-M33 as documented in Application Note AN521
+ *  "mps2-an524" -- Dual Cortex-M33 as documented in Application Note AN524
  *
  * Links to the TRM for the board itself and to the various Application
  * Notes which document the FPGA images can be found here:
@@ -27,11 +28,13 @@
  * http://infocenter.arm.com/help/topic/com.arm.doc.dai0505b/index.html
  * Application Note AN521:
  * http://infocenter.arm.com/help/topic/com.arm.doc.dai0521c/index.html
+ * Application Note AN524:
+ * https://developer.arm.com/documentation/dai0524/latest/
  *
  * The AN505 defers to the Cortex-M33 processor ARMv8M IoT Kit FVP User Guide
  * (ARM ECM0601256) for the details of some of the device layout:
  *   
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html
- * Similarly, the AN521 uses the SSE-200, and the SSE-200 TRM defines
+ * Similarly, the AN521 and AN524 use the SSE-200, and the SSE-200 TRM defines
  * most of the device layout:
  *  
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
  *
@@ -65,12 +68,13 @@
 #include "hw/qdev-clock.h"
 #include "qom/object.h"
 
-#define MPS2TZ_NUMIRQ_MAX 92
+#define MPS2TZ_NUMIRQ_MAX 95
 #define MPS2TZ_RAM_MAX 4
 
 typedef enum MPS2TZFPGAType {
 FPGA_AN505,
 FPGA_AN521,
+FPGA_AN524,
 } MPS2TZFPGAType;
 
 /*
@@ -121,13 +125,15 @@ struct MPS2TZMachineState {
 TZPPC ppc[5];
 TZMPC mpc[3];
 PL022State spi[5];
-ArmSbconI2CState i2c[4];
+ArmSbconI2CState i2c[5];
 UnimplementedDeviceState i2s_audio;
 UnimplementedDeviceState gpio[4];
 UnimplementedDeviceState gfx;
+UnimplementedDeviceState cldc;
+UnimplementedDeviceState rtc;
 PL080State dma[4];
 TZMSC msc[4];
-CMSDKAPBUART uart[5];
+CMSDKAPBUART uart[6];
 SplitIRQ sec_resp_splitter;
 qemu_or_irq uart_irq_orgate;
 DeviceState *lan9118;
@@ -139,6 +145,7 @@ struct MPS2TZMachineState {
 #define TYPE_MPS2TZ_MACHINE "mps2tz"
 #define TYPE_MPS2TZ_AN505_MACHINE MACHINE_TYPE_NAME("mps2-an505")
 #define TYPE_MPS2TZ_AN521_MACHINE MACHINE_TYPE_NAME("mps2-an521")
+#define TYPE_MPS3TZ_AN524_MACHINE MACHINE_TYPE_NAME("mps3-an524")
 
 OBJECT_DECLARE_TYPE(MPS2TZMachineState, MPS2TZMachineClass, MPS2TZ_MACHINE)
 
@@ -151,6 +158,15 @@ static const uint32_t an505_oscclk[] = {
 2500,
 };
 
+static const uint32_t an524_oscclk[] = {
+2400,
+3200,
+5000,
+5000,
+24576000,
+2375,
+};
+
 static const RAMInfo an505_raminfo[] = { {
 .name = "ssram-0",
 .base = 0x,
@@ -188,6 +204,37 @@ static const RAMInfo an505_raminfo[] = { {
 },
 };
 
+static const RAMInfo an524_raminfo[] = { {
+.name = "bram",
+.base = 0x,
+.size = 512 * KiB,
+.mpc = 0,
+.mrindex = 0,
+}, {
+.name = "sram",
+.base = 0x2000,
+.size = 32 * 4 * KiB,
+.mpc = 1,
+.mrindex = 1,
+}, {
+/* We don't model QSPI flash yet; for now expose it as simple ROM */
+.name = "QSPI",
+.base = 0x2800,
+.size = 8 * MiB,
+.mpc = 1,
+.mrindex = 2,
+.flags = IS_ROM,
+}, {
+.name = "DDR",
+.base = 0x6000,
+.size = 2 * GiB,
+.mpc = 2,
+.mrindex = -1,
+}, {
+.name = NULL,
+},
+};
+
 static const RAMInfo *find_raminfo_for_mpc(MPS2TZMachineState *mms, int mpc)
 {
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
@@ -717,12 +764,66 @@ static void mps2tz_common_init(MachineState *machine)
 },
 };
 
+const PPCInfo an524_ppcs[] = { {
+.name = "apb_ppcexp0",
+.ports = {
+{ "bram-mpc", make_mpc, &mms->mpc[0], 0x58007000, 0x1000 },
+{ "qspi-mpc", make_mpc, &mms->mpc[1], 0x58008000, 0x1000 },
+{ "ddr-mpc", make_mpc, &mms->mpc[2], 0x58009000, 0x1000 },
+},
+}, {
+.n

[PATCH v2 08/24] hw/arm/mps2-tz: Condition IRQ splitting on number of CPUs, not board type

2021-02-15 Thread Peter Maydell
In the mps2-tz board code, we handle devices whose interrupt lines
must be wired to all CPUs by creating IRQ splitter devices for the
AN521, because it has 2 CPUs, but wiring the device IRQ directly to
the SSE/IoTKit input for the AN505, which has only 1 CPU.

We can avoid making an explicit check on the board type constant by
instead creating and using the IRQ splitters for any board with more
than 1 CPU.  This avoids having to add extra cases to the
conditionals every time we add new boards.

Signed-off-by: Peter Maydell 
---
This removes the only current user of mmc->fpga_type, but we're
going to want it again later in the series.
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 6e345cf1f09..5561c30b126 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -139,17 +139,14 @@ static void make_ram_alias(MemoryRegion *mr, const char 
*name,
 static qemu_irq get_sse_irq_in(MPS2TZMachineState *mms, int irqno)
 {
 /* Return a qemu_irq which will signal IRQ n to all CPUs in the SSE. */
-MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
+MachineClass *mc = MACHINE_GET_CLASS(mms);
 
 assert(irqno < MPS2TZ_NUMIRQ);
 
-switch (mmc->fpga_type) {
-case FPGA_AN505:
-return qdev_get_gpio_in_named(DEVICE(&mms->iotkit), "EXP_IRQ", irqno);
-case FPGA_AN521:
+if (mc->max_cpus > 1) {
 return qdev_get_gpio_in(DEVICE(&mms->cpu_irq_splitter[irqno]), 0);
-default:
-g_assert_not_reached();
+} else {
+return qdev_get_gpio_in_named(DEVICE(&mms->iotkit), "EXP_IRQ", irqno);
 }
 }
 
@@ -437,10 +434,12 @@ static void mps2tz_common_init(MachineState *machine)
 sysbus_realize(SYS_BUS_DEVICE(&mms->iotkit), &error_fatal);
 
 /*
- * The AN521 needs us to create splitters to feed the IRQ inputs
- * for each CPU in the SSE-200 from each device in the board.
+ * If this board has more than one CPU, then we need to create splitters
+ * to feed the IRQ inputs for each CPU in the SSE from each device in the
+ * board. If there is only one CPU, we can just wire the device IRQ
+ * directly to the SSE's IRQ input.
  */
-if (mmc->fpga_type == FPGA_AN521) {
+if (mc->max_cpus > 1) {
 for (i = 0; i < MPS2TZ_NUMIRQ; i++) {
 char *name = g_strdup_printf("mps2-irq-splitter%d", i);
 SplitIRQ *splitter = &mms->cpu_irq_splitter[i];
-- 
2.20.1




[PATCH v2 14/24] hw/arm/mps2-tz: Size the uart-irq-orgate based on the number of UARTs

2021-02-15 Thread Peter Maydell
We create an OR gate to wire together the overflow IRQs for all the
UARTs on the board; this has to have twice the number of inputs as
there are UARTs, since each UART feeds it a TX overflow and an RX
overflow interrupt line.  Replace the hardcoded '10' with a
calculation based on the size of the uart[] array in the
MPS2TZMachineState.  (We rely on OR gate inputs that are never wired
up or asserted being treated as always-zero.)

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 014ba775783..f1a9c5f65a5 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -516,13 +516,18 @@ static void mps2tz_common_init(MachineState *machine)
  */
 memory_region_add_subregion(system_memory, 0x8000, machine->ram);
 
-/* The overflow IRQs for all UARTs are ORed together.
+/*
+ * The overflow IRQs for all UARTs are ORed together.
  * Tx, Rx and "combined" IRQs are sent to the NVIC separately.
- * Create the OR gate for this.
+ * Create the OR gate for this: it has one input for the TX overflow
+ * and one for the RX overflow for each UART we might have.
+ * (If the board has fewer than the maximum possible number of UARTs
+ * those inputs are never wired up and are treated as always-zero.)
  */
 object_initialize_child(OBJECT(mms), "uart-irq-orgate",
 &mms->uart_irq_orgate, TYPE_OR_IRQ);
-object_property_set_int(OBJECT(&mms->uart_irq_orgate), "num-lines", 10,
+object_property_set_int(OBJECT(&mms->uart_irq_orgate), "num-lines",
+2 * ARRAY_SIZE(mms->uart),
 &error_fatal);
 qdev_realize(DEVICE(&mms->uart_irq_orgate), NULL, &error_fatal);
 qdev_connect_gpio_out(DEVICE(&mms->uart_irq_orgate), 0,
-- 
2.20.1




[PATCH v2 13/24] hw/arm/mps2-tz: Move device IRQ info to data structures

2021-02-15 Thread Peter Maydell
Move the specification of the IRQ information for the uart, ethernet,
dma and spi devices to the data structures.  (The other devices
handled by the PPCPortInfo structures don't have any interrupt lines
we need to wire up.)

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 52 +++-
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 085746ac3e6..014ba775783 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -208,12 +208,10 @@ static MemoryRegion *make_uart(MPS2TZMachineState *mms, 
void *opaque,
const char *name, hwaddr size,
const int *irqs)
 {
+/* The irq[] array is tx, rx, combined, in that order */
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 CMSDKAPBUART *uart = opaque;
 int i = uart - &mms->uart[0];
-int rxirqno = i * 2 + 32;
-int txirqno = i * 2 + 33;
-int combirqno = i + 42;
 SysBusDevice *s;
 DeviceState *orgate_dev = DEVICE(&mms->uart_irq_orgate);
 
@@ -222,11 +220,11 @@ static MemoryRegion *make_uart(MPS2TZMachineState *mms, 
void *opaque,
 qdev_prop_set_uint32(DEVICE(uart), "pclk-frq", mmc->sysclk_frq);
 sysbus_realize(SYS_BUS_DEVICE(uart), &error_fatal);
 s = SYS_BUS_DEVICE(uart);
-sysbus_connect_irq(s, 0, get_sse_irq_in(mms, txirqno));
-sysbus_connect_irq(s, 1, get_sse_irq_in(mms, rxirqno));
+sysbus_connect_irq(s, 0, get_sse_irq_in(mms, irqs[0]));
+sysbus_connect_irq(s, 1, get_sse_irq_in(mms, irqs[1]));
 sysbus_connect_irq(s, 2, qdev_get_gpio_in(orgate_dev, i * 2));
 sysbus_connect_irq(s, 3, qdev_get_gpio_in(orgate_dev, i * 2 + 1));
-sysbus_connect_irq(s, 4, get_sse_irq_in(mms, combirqno));
+sysbus_connect_irq(s, 4, get_sse_irq_in(mms, irqs[2]));
 return sysbus_mmio_get_region(SYS_BUS_DEVICE(uart), 0);
 }
 
@@ -283,7 +281,7 @@ static MemoryRegion *make_eth_dev(MPS2TZMachineState *mms, 
void *opaque,
 
 s = SYS_BUS_DEVICE(mms->lan9118);
 sysbus_realize_and_unref(s, &error_fatal);
-sysbus_connect_irq(s, 0, get_sse_irq_in(mms, 48));
+sysbus_connect_irq(s, 0, get_sse_irq_in(mms, irqs[0]));
 return sysbus_mmio_get_region(s, 0);
 }
 
@@ -329,6 +327,7 @@ static MemoryRegion *make_dma(MPS2TZMachineState *mms, void 
*opaque,
   const char *name, hwaddr size,
   const int *irqs)
 {
+/* The irq[] array is DMACINTR, DMACINTERR, DMACINTTC, in that order */
 PL080State *dma = opaque;
 int i = dma - &mms->dma[0];
 SysBusDevice *s;
@@ -373,9 +372,9 @@ static MemoryRegion *make_dma(MPS2TZMachineState *mms, void 
*opaque,
 
 s = SYS_BUS_DEVICE(dma);
 /* Wire up DMACINTR, DMACINTERR, DMACINTTC */
-sysbus_connect_irq(s, 0, get_sse_irq_in(mms, 58 + i * 3));
-sysbus_connect_irq(s, 1, get_sse_irq_in(mms, 56 + i * 3));
-sysbus_connect_irq(s, 2, get_sse_irq_in(mms, 57 + i * 3));
+sysbus_connect_irq(s, 0, get_sse_irq_in(mms, irqs[0]));
+sysbus_connect_irq(s, 1, get_sse_irq_in(mms, irqs[1]));
+sysbus_connect_irq(s, 2, get_sse_irq_in(mms, irqs[2]));
 
 g_free(mscname);
 return sysbus_mmio_get_region(s, 0);
@@ -394,13 +393,12 @@ static MemoryRegion *make_spi(MPS2TZMachineState *mms, 
void *opaque,
  * lines are set via the "MISC" register in the MPS2 FPGAIO device.
  */
 PL022State *spi = opaque;
-int i = spi - &mms->spi[0];
 SysBusDevice *s;
 
 object_initialize_child(OBJECT(mms), name, spi, TYPE_PL022);
 sysbus_realize(SYS_BUS_DEVICE(spi), &error_fatal);
 s = SYS_BUS_DEVICE(spi);
-sysbus_connect_irq(s, 0, get_sse_irq_in(mms, 51 + i));
+sysbus_connect_irq(s, 0, get_sse_irq_in(mms, irqs[0]));
 return sysbus_mmio_get_region(s, 0);
 }
 
@@ -551,16 +549,16 @@ static void mps2tz_common_init(MachineState *machine)
 }, {
 .name = "apb_ppcexp1",
 .ports = {
-{ "spi0", make_spi, &mms->spi[0], 0x40205000, 0x1000 },
-{ "spi1", make_spi, &mms->spi[1], 0x40206000, 0x1000 },
-{ "spi2", make_spi, &mms->spi[2], 0x40209000, 0x1000 },
-{ "spi3", make_spi, &mms->spi[3], 0x4020a000, 0x1000 },
-{ "spi4", make_spi, &mms->spi[4], 0x4020b000, 0x1000 },
-{ "uart0", make_uart, &mms->uart[0], 0x4020, 0x1000 },
-{ "uart1", make_uart, &mms->uart[1], 0x40201000, 0x1000 },
-{ "uart2", make_uart, &mms->uart[2], 0x40202000, 0x1000 },
-{ "uart3", make_uart, &mms->uart[3], 0x40203000, 0x1000 },
-{ "uart4", make_uart, &mms->uart[4], 0x40204000, 0x1000 },
+{ "spi0", make_spi, &mms->spi[0], 0x40205000, 0x1000, { 51 } },
+{ "spi1", make_spi, &mms->spi[1], 0x40206000, 0x1000, { 52 } },
+{ "spi2", make_spi, &mms->spi[2], 0x40209000, 0x1000, { 53 } },
+{ "spi3", make_s

[PATCH v2 09/24] hw/arm/mps2-tz: Make number of IRQs board-specific

2021-02-15 Thread Peter Maydell
The AN524 has more interrupt lines than the AN505 and AN521; make
numirq board-specific rather than a compile-time constant.

Since the difference is small (92 on the current boards and 95 on the
new one) we don't dynamically allocate the cpu_irq_splitter[] array
but leave it as a fixed length array whose size is the maximum needed
for any of the boards.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 5561c30b126..6362652e617 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -65,7 +65,7 @@
 #include "hw/qdev-clock.h"
 #include "qom/object.h"
 
-#define MPS2TZ_NUMIRQ 92
+#define MPS2TZ_NUMIRQ_MAX 92
 
 typedef enum MPS2TZFPGAType {
 FPGA_AN505,
@@ -81,6 +81,7 @@ struct MPS2TZMachineClass {
 const uint32_t *oscclk;
 uint32_t fpgaio_num_leds; /* Number of LEDs in FPGAIO LED0 register */
 bool fpgaio_has_switches; /* Does FPGAIO have SWITCH register? */
+int numirq; /* Number of external interrupts */
 const char *armsse_type;
 };
 
@@ -105,7 +106,7 @@ struct MPS2TZMachineState {
 SplitIRQ sec_resp_splitter;
 qemu_or_irq uart_irq_orgate;
 DeviceState *lan9118;
-SplitIRQ cpu_irq_splitter[MPS2TZ_NUMIRQ];
+SplitIRQ cpu_irq_splitter[MPS2TZ_NUMIRQ_MAX];
 Clock *sysclk;
 Clock *s32kclk;
 };
@@ -140,8 +141,9 @@ static qemu_irq get_sse_irq_in(MPS2TZMachineState *mms, int 
irqno)
 {
 /* Return a qemu_irq which will signal IRQ n to all CPUs in the SSE. */
 MachineClass *mc = MACHINE_GET_CLASS(mms);
+MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 
-assert(irqno < MPS2TZ_NUMIRQ);
+assert(irqno < mmc->numirq);
 
 if (mc->max_cpus > 1) {
 return qdev_get_gpio_in(DEVICE(&mms->cpu_irq_splitter[irqno]), 0);
@@ -428,7 +430,7 @@ static void mps2tz_common_init(MachineState *machine)
 iotkitdev = DEVICE(&mms->iotkit);
 object_property_set_link(OBJECT(&mms->iotkit), "memory",
  OBJECT(system_memory), &error_abort);
-qdev_prop_set_uint32(iotkitdev, "EXP_NUMIRQ", MPS2TZ_NUMIRQ);
+qdev_prop_set_uint32(iotkitdev, "EXP_NUMIRQ", mmc->numirq);
 qdev_connect_clock_in(iotkitdev, "MAINCLK", mms->sysclk);
 qdev_connect_clock_in(iotkitdev, "S32KCLK", mms->s32kclk);
 sysbus_realize(SYS_BUS_DEVICE(&mms->iotkit), &error_fatal);
@@ -439,8 +441,9 @@ static void mps2tz_common_init(MachineState *machine)
  * board. If there is only one CPU, we can just wire the device IRQ
  * directly to the SSE's IRQ input.
  */
+assert(mmc->numirq <= MPS2TZ_NUMIRQ_MAX);
 if (mc->max_cpus > 1) {
-for (i = 0; i < MPS2TZ_NUMIRQ; i++) {
+for (i = 0; i < mmc->numirq; i++) {
 char *name = g_strdup_printf("mps2-irq-splitter%d", i);
 SplitIRQ *splitter = &mms->cpu_irq_splitter[i];
 
@@ -693,6 +696,7 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
 mmc->fpgaio_num_leds = 2;
 mmc->fpgaio_has_switches = false;
+mmc->numirq = 92;
 mmc->armsse_type = TYPE_IOTKIT;
 }
 
@@ -713,6 +717,7 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->len_oscclk = ARRAY_SIZE(an505_oscclk);
 mmc->fpgaio_num_leds = 2;
 mmc->fpgaio_has_switches = false;
+mmc->numirq = 92;
 mmc->armsse_type = TYPE_SSE200;
 }
 
-- 
2.20.1




[PATCH v2 24/24] hw/arm/mps2: Update old infocenter.arm.com URLs

2021-02-15 Thread Peter Maydell
Update old infocenter.arm.com URLs to the equivalent developer.arm.com
ones (the old URLs should redirect, but we might as well avoid the
redirection notice, and the new URLs are pleasantly shorter).

This commit covers the links to the MPS2 board TRM, the various
Application Notes, the IoTKit and SSE-200 documents.

Signed-off-by: Peter Maydell 
---
There are some other infocenter URLs in the codebase; we should
probably update those too, but they don't really fit in with this
patchset, so I'll do them separately later.
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/arm/armsse.h  |  4 ++--
 include/hw/misc/armsse-cpuid.h   |  2 +-
 include/hw/misc/armsse-mhu.h |  2 +-
 include/hw/misc/iotkit-secctl.h  |  2 +-
 include/hw/misc/iotkit-sysctl.h  |  2 +-
 include/hw/misc/iotkit-sysinfo.h |  2 +-
 include/hw/misc/mps2-fpgaio.h|  2 +-
 hw/arm/mps2-tz.c | 11 +--
 hw/misc/armsse-cpuid.c   |  2 +-
 hw/misc/armsse-mhu.c |  2 +-
 hw/misc/iotkit-sysctl.c  |  2 +-
 hw/misc/iotkit-sysinfo.c |  2 +-
 hw/misc/mps2-fpgaio.c|  2 +-
 hw/misc/mps2-scc.c   |  2 +-
 14 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/include/hw/arm/armsse.h b/include/hw/arm/armsse.h
index 676cd4f36b0..09284ca75cf 100644
--- a/include/hw/arm/armsse.h
+++ b/include/hw/arm/armsse.h
@@ -14,9 +14,9 @@
  * hardware, which include the IoT Kit and the SSE-050, SSE-100 and
  * SSE-200. Currently we model:
  *  - the Arm IoT Kit which is documented in
- * 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html
+ *https://developer.arm.com/documentation/ecm0601256/latest
  *  - the SSE-200 which is documented in
- * 
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
+ *https://developer.arm.com/documentation/101104/latest/
  *
  * The IoTKit contains:
  *  a Cortex-M33
diff --git a/include/hw/misc/armsse-cpuid.h b/include/hw/misc/armsse-cpuid.h
index a61355e5161..9c0926322cb 100644
--- a/include/hw/misc/armsse-cpuid.h
+++ b/include/hw/misc/armsse-cpuid.h
@@ -12,7 +12,7 @@
 /*
  * This is a model of the "CPU_IDENTITY" register block which is part of the
  * Arm SSE-200 and documented in
- * 
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
+ * https://developer.arm.com/documentation/101104/latest/
  *
  * QEMU interface:
  *  + QOM property "CPUID": the value to use for the CPUID register
diff --git a/include/hw/misc/armsse-mhu.h b/include/hw/misc/armsse-mhu.h
index 2671b5b978b..41925ded89b 100644
--- a/include/hw/misc/armsse-mhu.h
+++ b/include/hw/misc/armsse-mhu.h
@@ -12,7 +12,7 @@
 /*
  * This is a model of the Message Handling Unit (MHU) which is part of the
  * Arm SSE-200 and documented in
- * 
http://infocenter.arm.com/help/topic/com.arm.doc.101104_0100_00_en/corelink_sse200_subsystem_for_embedded_technical_reference_manual_101104_0100_00_en.pdf
+ * https://developer.arm.com/documentation/101104/latest/
  *
  * QEMU interface:
  *  + sysbus MMIO region 0: the system information register bank
diff --git a/include/hw/misc/iotkit-secctl.h b/include/hw/misc/iotkit-secctl.h
index 54c212b515c..227d44abe49 100644
--- a/include/hw/misc/iotkit-secctl.h
+++ b/include/hw/misc/iotkit-secctl.h
@@ -11,7 +11,7 @@
 
 /* This is a model of the security controller which is part of the
  * Arm IoT Kit and documented in
- * 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html
+ * https://developer.arm.com/documentation/ecm0601256/latest
  *
  * QEMU interface:
  *  + sysbus MMIO region 0 is the "secure privilege control block" registers
diff --git a/include/hw/misc/iotkit-sysctl.h b/include/hw/misc/iotkit-sysctl.h
index 2b5636b218c..2bc391138db 100644
--- a/include/hw/misc/iotkit-sysctl.h
+++ b/include/hw/misc/iotkit-sysctl.h
@@ -12,7 +12,7 @@
 /*
  * This is a model of the "system control element" which is part of the
  * Arm IoTKit and documented in
- * 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html
+ * https://developer.arm.com/documentation/ecm0601256/latest
  * Specifically, it implements the "system information block" and
  * "system control register" blocks.
  *
diff --git a/include/hw/misc/iotkit-sysinfo.h b/include/hw/misc/iotkit-sysinfo.h
index 7e620e2eafe..055771d2098 100644
--- a/include/hw/misc/iotkit-sysinfo.h
+++ b/include/hw/misc/iotkit-sysinfo.h
@@ -12,7 +12,7 @@
 /*
  * This is a model of the "system information block" which is part of the
  * Arm IoTKit and documented in
- * 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html
+ * https://developer.arm.com/documentation/ecm0601256/latest
  * QEMU interface:
  *  + QOM property "SYS_VERSION": value to use for SYS_VERSION register
  *  + QOM proper

[PATCH v2 15/24] hw/arm/mps2-tz: Allow boards to have different PPCInfo data

2021-02-15 Thread Peter Maydell
The AN505 and AN521 have the same device layout, but the AN524 is
somewhat different.  Allow for more than one PPCInfo array, which can
be selected based on the board type.

Signed-off-by: Peter Maydell 
---
We can't just put the arrays at file-scope and set up pointers
to them in the MPS2TZMachineClass struct, because the array
members include entries like "&mms->uart[0]" which is only valid
inside the mps2tz_common_init() function.
---
 hw/arm/mps2-tz.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index f1a9c5f65a5..a79966a7187 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -423,6 +423,8 @@ static void mps2tz_common_init(MachineState *machine)
 MemoryRegion *system_memory = get_system_memory();
 DeviceState *iotkitdev;
 DeviceState *dev_splitter;
+const PPCInfo *ppcs;
+int num_ppcs;
 int i;
 
 if (strcmp(machine->cpu_type, mc->default_cpu_type) != 0) {
@@ -544,7 +546,7 @@ static void mps2tz_common_init(MachineState *machine)
  *  + wire up the PPC's control lines to the IoTKit object
  */
 
-const PPCInfo ppcs[] = { {
+const PPCInfo an505_ppcs[] = { {
 .name = "apb_ppcexp0",
 .ports = {
 { "ssram-0", make_mpc, &mms->ssram_mpc[0], 0x58007000, 0x1000 
},
@@ -598,7 +600,17 @@ static void mps2tz_common_init(MachineState *machine)
 },
 };
 
-for (i = 0; i < ARRAY_SIZE(ppcs); i++) {
+switch (mmc->fpga_type) {
+case FPGA_AN505:
+case FPGA_AN521:
+ppcs = an505_ppcs;
+num_ppcs = ARRAY_SIZE(an505_ppcs);
+break;
+default:
+g_assert_not_reached();
+}
+
+for (i = 0; i < num_ppcs; i++) {
 const PPCInfo *ppcinfo = &ppcs[i];
 TZPPC *ppc = &mms->ppc[i];
 DeviceState *ppcdev;
-- 
2.20.1




[PATCH v2 11/24] hw/arm/mps2-tz: Correct wrong interrupt numbers for DMA and SPI

2021-02-15 Thread Peter Maydell
On the MPS2 boards, the first 32 interrupt lines are entirely
internal to the SSE; interrupt lines for devices outside the SSE
start at 32.  In the application notes that document each FPGA image,
the interrupt wiring is documented from the point of view of the CPU,
so '0' is the first of the SSE's interrupts and the devices in the
FPGA image itself are '32' and up: so the UART 0 Receive interrupt is
32, the SPI #0 interrupt is 51, and so on.

Within our implementation, because the external interrupts must be
connected to the EXP_IRQ[0...n] lines of the SSE object, we made the
get_sse_irq_in() function take an irqno whose values start at 0 for
the first FPGA device interrupt.  In this numbering scheme the UART 0
Receive interrupt is 0, the SPI #0 interrupt is 19, and so on.

The result of these two different numbering schemes has been that
half of the devices were wired up to the wrong IRQs: the UART IRQs
are wired up correctly, but the DMA and SPI devices were passing
start-at-32 values to get_sse_irq_in() and so being mis-connected.

Fix the bug by making get_sse_irq_in() take values specified with the
same scheme that the hardware manuals use, to avoid confusion.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 6362652e617..ff8b7e5f1ae 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -139,11 +139,21 @@ static void make_ram_alias(MemoryRegion *mr, const char 
*name,
 
 static qemu_irq get_sse_irq_in(MPS2TZMachineState *mms, int irqno)
 {
-/* Return a qemu_irq which will signal IRQ n to all CPUs in the SSE. */
+/*
+ * Return a qemu_irq which will signal IRQ n to all CPUs in the
+ * SSE.  The irqno should be as the CPU sees it, so the first
+ * external-to-the-SSE interrupt is 32.
+ */
 MachineClass *mc = MACHINE_GET_CLASS(mms);
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 
-assert(irqno < mmc->numirq);
+assert(irqno >= 32 && irqno < (mmc->numirq + 32));
+
+/*
+ * Convert from "CPU irq number" (as listed in the FPGA image
+ * documentation) to the SSE external-interrupt number.
+ */
+irqno -= 32;
 
 if (mc->max_cpus > 1) {
 return qdev_get_gpio_in(DEVICE(&mms->cpu_irq_splitter[irqno]), 0);
@@ -197,9 +207,9 @@ static MemoryRegion *make_uart(MPS2TZMachineState *mms, 
void *opaque,
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 CMSDKAPBUART *uart = opaque;
 int i = uart - &mms->uart[0];
-int rxirqno = i * 2;
-int txirqno = i * 2 + 1;
-int combirqno = i + 10;
+int rxirqno = i * 2 + 32;
+int txirqno = i * 2 + 33;
+int combirqno = i + 42;
 SysBusDevice *s;
 DeviceState *orgate_dev = DEVICE(&mms->uart_irq_orgate);
 
@@ -266,7 +276,7 @@ static MemoryRegion *make_eth_dev(MPS2TZMachineState *mms, 
void *opaque,
 
 s = SYS_BUS_DEVICE(mms->lan9118);
 sysbus_realize_and_unref(s, &error_fatal);
-sysbus_connect_irq(s, 0, get_sse_irq_in(mms, 16));
+sysbus_connect_irq(s, 0, get_sse_irq_in(mms, 48));
 return sysbus_mmio_get_region(s, 0);
 }
 
@@ -507,7 +517,7 @@ static void mps2tz_common_init(MachineState *machine)
 &error_fatal);
 qdev_realize(DEVICE(&mms->uart_irq_orgate), NULL, &error_fatal);
 qdev_connect_gpio_out(DEVICE(&mms->uart_irq_orgate), 0,
-  get_sse_irq_in(mms, 15));
+  get_sse_irq_in(mms, 47));
 
 /* Most of the devices in the FPGA are behind Peripheral Protection
  * Controllers. The required order for initializing things is:
-- 
2.20.1




[PATCH v2 19/24] hw/arm/mps2-tz: Get armv7m_load_kernel() size argument from RAMInfo

2021-02-15 Thread Peter Maydell
The armv7m_load_kernel() function takes a mem_size argument which it
expects to be the size of the memory region at guest address 0.  (It
uses this argument only as a limit on how large a raw image file it
can load at address zero).

Instead of hardcoding this value, find the RAMInfo corresponding to
the 0 address and extract its size.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index cc9d70ece54..da27caa332d 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -525,6 +525,20 @@ static void create_non_mpc_ram(MPS2TZMachineState *mms)
 }
 }
 
+static uint32_t boot_ram_size(MPS2TZMachineState *mms)
+{
+/* Return the size of the RAM block at guest address zero */
+const RAMInfo *p;
+MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
+
+for (p = mmc->raminfo; p->name; p++) {
+if (p->base == 0) {
+return p->size;
+}
+}
+g_assert_not_reached();
+}
+
 static void mps2tz_common_init(MachineState *machine)
 {
 MPS2TZMachineState *mms = MPS2TZ_MACHINE(machine);
@@ -789,7 +803,8 @@ static void mps2tz_common_init(MachineState *machine)
 
 create_non_mpc_ram(mms);
 
-armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename, 0x40);
+armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename,
+   boot_ram_size(mms));
 }
 
 static void mps2_tz_idau_check(IDAUInterface *ii, uint32_t address,
-- 
2.20.1




Re: [PATCH v2 11/12] spitz: put some Spitz-family devices into the correct category

2021-02-15 Thread Philippe Mathieu-Daudé
Hi,

On 11/30/20 9:36 AM, Gan Qixin wrote:
> Some Spitz-family devices have no category, put them into the correct 
> category.
> 
> Signed-off-by: Gan Qixin 
> ---
> Cc: Peter Maydell 
> ---
>  hw/arm/spitz.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/arm/spitz.c b/hw/arm/spitz.c
> index 32bdeacfd3..0e5e8a4634 100644
> --- a/hw/arm/spitz.c
> +++ b/hw/arm/spitz.c
> @@ -1218,6 +1218,7 @@ static void corgi_ssp_class_init(ObjectClass *klass, 
> void *data)
>  k->realize = corgi_ssp_realize;
>  k->transfer = corgi_ssp_transfer;
>  dc->vmsd = &vmstate_corgi_ssp_regs;
> +set_bit(DEVICE_CATEGORY_MISC, dc->categories);

OK.

>  }
>  
>  static const TypeInfo corgi_ssp_info = {
> @@ -1247,6 +1248,7 @@ static void spitz_lcdtg_class_init(ObjectClass *klass, 
> void *data)
>  k->realize = spitz_lcdtg_realize;
>  k->transfer = spitz_lcdtg_transfer;
>  dc->vmsd = &vmstate_spitz_lcdtg_regs;
> +set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);

This is not a display device, but a regulator to
control the display backlight. DEVICE_CATEGORY_MISC
seems more appropriate.

>  }
>  
>  static const TypeInfo spitz_lcdtg_info = {
> 

Regards,

Phil.



[PATCH v2 16/24] hw/arm/mps2-tz: Make RAM arrangement board-specific

2021-02-15 Thread Peter Maydell
The AN505 and AN521 have the same layout of RAM; the AN524 does not.
Replace the current hard-coding of where the RAM is and which parts
of it are behind which MPCs with a data-driven approach.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 175 +--
 1 file changed, 138 insertions(+), 37 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index a79966a7187..18f75eacfcd 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -66,12 +66,35 @@
 #include "qom/object.h"
 
 #define MPS2TZ_NUMIRQ_MAX 92
+#define MPS2TZ_RAM_MAX 4
 
 typedef enum MPS2TZFPGAType {
 FPGA_AN505,
 FPGA_AN521,
 } MPS2TZFPGAType;
 
+/*
+ * Define the layout of RAM in a board, including which parts are
+ * behind which MPCs.
+ * mrindex specifies the index into mms->ram[] to use for the backing RAM;
+ * -1 means "use the system RAM".
+ */
+typedef struct RAMInfo {
+const char *name;
+uint32_t base;
+uint32_t size;
+int mpc; /* MPC number, -1 for "not behind an MPC" */
+int mrindex;
+int flags;
+} RAMInfo;
+
+/*
+ * Flag values:
+ *  IS_ALIAS: this RAM area is an alias to the upstream end of the
+ *MPC specified by its .mpc value
+ */
+#define IS_ALIAS 1
+
 struct MPS2TZMachineClass {
 MachineClass parent;
 MPS2TZFPGAType fpga_type;
@@ -82,6 +105,7 @@ struct MPS2TZMachineClass {
 uint32_t fpgaio_num_leds; /* Number of LEDs in FPGAIO LED0 register */
 bool fpgaio_has_switches; /* Does FPGAIO have SWITCH register? */
 int numirq; /* Number of external interrupts */
+const RAMInfo *raminfo;
 const char *armsse_type;
 };
 
@@ -89,12 +113,11 @@ struct MPS2TZMachineState {
 MachineState parent;
 
 ARMSSE iotkit;
-MemoryRegion ssram[3];
-MemoryRegion ssram1_m;
+MemoryRegion ram[MPS2TZ_RAM_MAX];
 MPS2SCC scc;
 MPS2FPGAIO fpgaio;
 TZPPC ppc[5];
-TZMPC ssram_mpc[3];
+TZMPC mpc[3];
 PL022State spi[5];
 ArmSbconI2CState i2c[4];
 UnimplementedDeviceState i2s_audio;
@@ -126,6 +149,77 @@ static const uint32_t an505_oscclk[] = {
 2500,
 };
 
+static const RAMInfo an505_raminfo[] = { {
+.name = "ssram-0",
+.base = 0x,
+.size = 0x0040,
+.mpc = 0,
+.mrindex = 0,
+}, {
+.name = "ssram-1",
+.base = 0x2800,
+.size = 0x0020,
+.mpc = 1,
+.mrindex = 1,
+}, {
+.name = "ssram-2",
+.base = 0x2820,
+.size = 0x0020,
+.mpc = 2,
+.mrindex = 2,
+}, {
+.name = "ssram-0-alias",
+.base = 0x0040,
+.size = 0x0040,
+.mpc = 0,
+.mrindex = 3,
+.flags = IS_ALIAS,
+}, {
+/* Use the largest bit of contiguous RAM as our "system memory" */
+.name = "mps.ram",
+.base = 0x8000,
+.size = 16 * MiB,
+.mpc = -1,
+.mrindex = -1,
+}, {
+.name = NULL,
+},
+};
+
+static const RAMInfo *find_raminfo_for_mpc(MPS2TZMachineState *mms, int mpc)
+{
+MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
+const RAMInfo *p;
+
+for (p = mmc->raminfo; p->name; p++) {
+if (p->mpc == mpc && !(p->flags & IS_ALIAS)) {
+return p;
+}
+}
+/* if raminfo array doesn't have an entry for each MPC this is a bug */
+g_assert_not_reached();
+}
+
+static MemoryRegion *mr_for_raminfo(MPS2TZMachineState *mms,
+const RAMInfo *raminfo)
+{
+/* Return an initialized MemoryRegion for the RAMInfo. */
+MemoryRegion *ram;
+
+if (raminfo->mrindex < 0) {
+/* Means this RAMInfo is for QEMU's "system memory" */
+MachineState *machine = MACHINE(mms);
+return machine->ram;
+}
+
+assert(raminfo->mrindex < MPS2TZ_RAM_MAX);
+ram = &mms->ram[raminfo->mrindex];
+
+memory_region_init_ram(ram, NULL, raminfo->name,
+   raminfo->size, &error_fatal);
+return ram;
+}
+
 /* Create an alias of an entire original MemoryRegion @orig
  * located at @base in the memory map.
  */
@@ -290,35 +384,23 @@ static MemoryRegion *make_mpc(MPS2TZMachineState *mms, 
void *opaque,
   const int *irqs)
 {
 TZMPC *mpc = opaque;
-int i = mpc - &mms->ssram_mpc[0];
-MemoryRegion *ssram = &mms->ssram[i];
+int i = mpc - &mms->mpc[0];
 MemoryRegion *upstream;
-char *mpcname = g_strdup_printf("%s-mpc", name);
-static uint32_t ramsize[] = { 0x0040, 0x0020, 0x0020 };
-static uint32_t rambase[] = { 0x, 0x2800, 0x2820 };
+const RAMInfo *raminfo = find_raminfo_for_mpc(mms, i);
+MemoryRegion *ram = mr_for_raminfo(mms, raminfo);
 
-memory_region_init_ram(ssram, NULL, name, ramsize[i], &error_fatal);
-
-object_initialize_child(OBJECT(mms), mpcname, mpc, TYPE_TZ_MPC);
-object_property_set_link(OBJECT(mpc), "downstream", OBJECT(ssram),
+objec

[PATCH v2 22/24] hw/arm/mps2-tz: Provide PL031 RTC on mps3-an524

2021-02-15 Thread Peter Maydell
The AN524 has a PL031 RTC, which we have a model of; provide it
rather than an unimplemented-device stub.

Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/mps2-tz.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 183c3920903..2c385422373 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -60,6 +60,7 @@
 #include "hw/misc/tz-msc.h"
 #include "hw/arm/armsse.h"
 #include "hw/dma/pl080.h"
+#include "hw/rtc/pl031.h"
 #include "hw/ssi/pl022.h"
 #include "hw/i2c/arm_sbcon_i2c.h"
 #include "hw/net/lan9118.h"
@@ -132,8 +133,8 @@ struct MPS2TZMachineState {
 UnimplementedDeviceState gpio[4];
 UnimplementedDeviceState gfx;
 UnimplementedDeviceState cldc;
-UnimplementedDeviceState rtc;
 UnimplementedDeviceState usb;
+PL031State rtc;
 PL080State dma[4];
 TZMSC msc[4];
 CMSDKAPBUART uart[6];
@@ -596,6 +597,23 @@ static MemoryRegion *make_i2c(MPS2TZMachineState *mms, 
void *opaque,
 return sysbus_mmio_get_region(s, 0);
 }
 
+static MemoryRegion *make_rtc(MPS2TZMachineState *mms, void *opaque,
+  const char *name, hwaddr size,
+  const int *irqs)
+{
+PL031State *pl031 = opaque;
+SysBusDevice *s;
+
+object_initialize_child(OBJECT(mms), name, pl031, TYPE_PL031);
+s = SYS_BUS_DEVICE(pl031);
+sysbus_realize(s, &error_fatal);
+/*
+ * The board docs don't give an IRQ number for the PL031, so
+ * presumably it is not connected.
+ */
+return sysbus_mmio_get_region(s, 0);
+}
+
 static void create_non_mpc_ram(MPS2TZMachineState *mms)
 {
 /*
@@ -846,7 +864,7 @@ static void mps2tz_common_init(MachineState *machine)
 
 { /* port 9 reserved */ },
 { "clcd", make_unimp_dev, &mms->cldc, 0x4130a000, 0x1000 },
-{ "rtc", make_unimp_dev, &mms->rtc, 0x4130b000, 0x1000 },
+{ "rtc", make_rtc, &mms->rtc, 0x4130b000, 0x1000 },
 },
 }, {
 .name = "ahb_ppcexp0",
-- 
2.20.1




Re: [RFC v18 10/15] i386: split tcg btp_helper into softmmu and user parts

2021-02-15 Thread Claudio Fontana
On 2/12/21 1:36 PM, Claudio Fontana wrote:
> Signed-off-by: Claudio Fontana 
> ---
>  target/i386/helper.h |   7 +
>  target/i386/tcg/helper-tcg.h |   3 +
>  target/i386/tcg/bpt_helper.c | 276 -
>  target/i386/tcg/softmmu/bpt_helper.c | 293 +++
>  target/i386/tcg/translate.c  |   4 +
>  target/i386/tcg/softmmu/meson.build  |   1 +
>  6 files changed, 308 insertions(+), 276 deletions(-)
>  create mode 100644 target/i386/tcg/softmmu/bpt_helper.c
> 
> diff --git a/target/i386/helper.h b/target/i386/helper.h
> index 8ffda4cdc6..095520f81f 100644
> --- a/target/i386/helper.h
> +++ b/target/i386/helper.h
> @@ -46,7 +46,11 @@ DEF_HELPER_2(read_crN, tl, env, int)
>  DEF_HELPER_3(write_crN, void, env, int, tl)
>  DEF_HELPER_2(lmsw, void, env, tl)
>  DEF_HELPER_1(clts, void, env)
> +
> +#ifndef CONFIG_USER_ONLY
>  DEF_HELPER_FLAGS_3(set_dr, TCG_CALL_NO_WG, void, env, int, tl)
> +#endif /* !CONFIG_USER_ONLY */
> +
>  DEF_HELPER_FLAGS_2(get_dr, TCG_CALL_NO_WG, tl, env, int)
>  DEF_HELPER_2(invlpg, void, env, tl)
>  
> @@ -100,7 +104,10 @@ DEF_HELPER_3(outw, void, env, i32, i32)
>  DEF_HELPER_2(inw, tl, env, i32)
>  DEF_HELPER_3(outl, void, env, i32, i32)
>  DEF_HELPER_2(inl, tl, env, i32)
> +
> +#ifndef CONFIG_USER_ONLY
>  DEF_HELPER_FLAGS_4(bpt_io, TCG_CALL_NO_WG, void, env, i32, i32, tl)
> +#endif /* !CONFIG_USER_ONLY */
>  
>  DEF_HELPER_3(svm_check_intercept_param, void, env, i32, i64)
>  DEF_HELPER_4(svm_check_io, void, env, i32, i32, i32)
> diff --git a/target/i386/tcg/helper-tcg.h b/target/i386/tcg/helper-tcg.h
> index c133c63555..b420b3356d 100644
> --- a/target/i386/tcg/helper-tcg.h
> +++ b/target/i386/tcg/helper-tcg.h
> @@ -92,4 +92,7 @@ void do_interrupt_x86_hardirq(CPUX86State *env, int intno, 
> int is_hw);
>  /* smm_helper.c */
>  void do_smm_enter(X86CPU *cpu);
>  
> +/* bpt_helper.c */
> +bool check_hw_breakpoints(CPUX86State *env, bool force_dr6_update);
> +
>  #endif /* I386_HELPER_TCG_H */
> diff --git a/target/i386/tcg/bpt_helper.c b/target/i386/tcg/bpt_helper.c
> index 979230ac12..fb2a65ac9c 100644
> --- a/target/i386/tcg/bpt_helper.c
> +++ b/target/i386/tcg/bpt_helper.c
> @@ -19,223 +19,9 @@
>  
>  #include "qemu/osdep.h"
>  #include "cpu.h"
> -#include "exec/exec-all.h"
>  #include "exec/helper-proto.h"
>  #include "helper-tcg.h"
>  
> -
> -#ifndef CONFIG_USER_ONLY
> -static inline bool hw_local_breakpoint_enabled(unsigned long dr7, int index)
> -{
> -return (dr7 >> (index * 2)) & 1;
> -}
> -
> -static inline bool hw_global_breakpoint_enabled(unsigned long dr7, int index)
> -{
> -return (dr7 >> (index * 2)) & 2;
> -
> -}
> -static inline bool hw_breakpoint_enabled(unsigned long dr7, int index)
> -{
> -return hw_global_breakpoint_enabled(dr7, index) ||
> -   hw_local_breakpoint_enabled(dr7, index);
> -}
> -
> -static inline int hw_breakpoint_type(unsigned long dr7, int index)
> -{
> -return (dr7 >> (DR7_TYPE_SHIFT + (index * 4))) & 3;
> -}
> -
> -static inline int hw_breakpoint_len(unsigned long dr7, int index)
> -{
> -int len = ((dr7 >> (DR7_LEN_SHIFT + (index * 4))) & 3);
> -return (len == 2) ? 8 : len + 1;
> -}
> -
> -static int hw_breakpoint_insert(CPUX86State *env, int index)
> -{
> -CPUState *cs = env_cpu(env);
> -target_ulong dr7 = env->dr[7];
> -target_ulong drN = env->dr[index];
> -int err = 0;
> -
> -switch (hw_breakpoint_type(dr7, index)) {
> -case DR7_TYPE_BP_INST:
> -if (hw_breakpoint_enabled(dr7, index)) {
> -err = cpu_breakpoint_insert(cs, drN, BP_CPU,
> -&env->cpu_breakpoint[index]);
> -}
> -break;
> -
> -case DR7_TYPE_IO_RW:
> -/* Notice when we should enable calls to bpt_io.  */
> -return hw_breakpoint_enabled(env->dr[7], index)
> -   ? HF_IOBPT_MASK : 0;
> -
> -case DR7_TYPE_DATA_WR:
> -if (hw_breakpoint_enabled(dr7, index)) {
> -err = cpu_watchpoint_insert(cs, drN,
> -hw_breakpoint_len(dr7, index),
> -BP_CPU | BP_MEM_WRITE,
> -&env->cpu_watchpoint[index]);
> -}
> -break;
> -
> -case DR7_TYPE_DATA_RW:
> -if (hw_breakpoint_enabled(dr7, index)) {
> -err = cpu_watchpoint_insert(cs, drN,
> -hw_breakpoint_len(dr7, index),
> -BP_CPU | BP_MEM_ACCESS,
> -&env->cpu_watchpoint[index]);
> -}
> -break;
> -}
> -if (err) {
> -env->cpu_breakpoint[index] = NULL;
> -}
> -return 0;
> -}
> -
> -static void hw_breakpoint_remove(CPUX86State *env, int index)
> -{
> -CPUState *cs = env_cpu(env);
> -
> -switch (hw_breakpoint_type(env->dr[7], index)) {
> -case DR7_TYPE_BP_INST:
> -if (env->cpu_brea

[PATCH v2 17/24] hw/arm/mps2-tz: Set MachineClass default_ram info from RAMInfo data

2021-02-15 Thread Peter Maydell
Instead of hardcoding the MachineClass default_ram_size and
default_ram_id fields, set them on class creation by finding the
entry in the RAMInfo array which is marked as being the QEMU system
RAM.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 18f75eacfcd..08dd2cbaa40 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -811,8 +811,26 @@ static void mps2tz_class_init(ObjectClass *oc, void *data)
 
 mc->init = mps2tz_common_init;
 iic->check = mps2_tz_idau_check;
-mc->default_ram_size = 16 * MiB;
-mc->default_ram_id = "mps.ram";
+}
+
+static void mps2tz_set_default_ram_info(MPS2TZMachineClass *mmc)
+{
+/*
+ * Set mc->default_ram_size and default_ram_id from the
+ * information in mmc->raminfo.
+ */
+MachineClass *mc = MACHINE_CLASS(mmc);
+const RAMInfo *p;
+
+for (p = mmc->raminfo; p->name; p++) {
+if (p->mrindex < 0) {
+/* Found the entry for "system memory" */
+mc->default_ram_size = p->size;
+mc->default_ram_id = p->name;
+return;
+}
+}
+g_assert_not_reached();
 }
 
 static void mps2tz_an505_class_init(ObjectClass *oc, void *data)
@@ -835,6 +853,7 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 92;
 mmc->raminfo = an505_raminfo;
 mmc->armsse_type = TYPE_IOTKIT;
+mps2tz_set_default_ram_info(mmc);
 }
 
 static void mps2tz_an521_class_init(ObjectClass *oc, void *data)
@@ -857,6 +876,7 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 92;
 mmc->raminfo = an505_raminfo; /* AN521 is the same as AN505 here */
 mmc->armsse_type = TYPE_SSE200;
+mps2tz_set_default_ram_info(mmc);
 }
 
 static const TypeInfo mps2tz_info = {
-- 
2.20.1




Re: [RFC PATCH 34/42] gitlab-ci: Build MIPS R5900 cross-toolchain (Gentoo based)

2021-02-15 Thread Daniel P . Berrangé
On Mon, Feb 15, 2021 at 12:42:50PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/14/21 6:59 PM, Philippe Mathieu-Daudé wrote:
> > Add a job to build the Gentoo based MIPS R5900 cross-toolchain image.
> > 
> > Signed-off-by: Philippe Mathieu-Daudé 
> > ---
> >  .gitlab-ci.d/containers.yml | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
> > index 587bd4ba2e3..f441e608446 100644
> > --- a/.gitlab-ci.d/containers.yml
> > +++ b/.gitlab-ci.d/containers.yml
> > @@ -152,6 +152,13 @@ mipsel-debian-cross-container:
> >variables:
> >  NAME: debian-mipsel-cross
> >  
> > +mipsr5900el-gentoo-cross-container:
> > +  <<: *container_job_definition
> > +  variables:
> > +NAME: gentoo-mipsr5900el-cross
> > +EXTRA_FILES: 
> > tests/docker/dockerfiles/gentoo-mipsr5900el-cross.docker.d/crossdev.conf
> > +  timeout: 1h 30m
> 
> Well, depending of the runner hardware / load, this is not
> enough:
> 
> Duration: 132 minutes 17 seconds
> https://gitlab.com/philmd/qemu/-/jobs/1029975495

Yeah that's waaay too long to be part of standard CI.

> I'll use "2h 30" instead. I'm still looking how to make this job
> optional (or manual).

If it is manual who is ever going to run it and be willing to wait
2 hours for it. This just feels too long to be useful.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




  1   2   3   4   5   >