Re: [PATCH v2 2/2] pci: add romsize property

2021-01-31 Thread Gerd Hoffmann
  Hi,

> +DEFINE_PROP_UINT32("romsize", PCIDevice, romsize, -1),

IIRC we have a DEFINE_PROP_SIZE() which can parse units and therefore
accepts -- for example -- "512k" or "1M".

take care,
  Gerd




[Bug 1890152] Re: malloc 0xff0000030 bytes with vmxnet3

2021-01-31 Thread Philippe Mathieu-Daudé
*** This bug is a duplicate of bug 1913873 ***
https://bugs.launchpad.net/bugs/1913873

Chronogically speaking #1913873 is a duplicate of #1890152...

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

Title:
  malloc 0xff030 bytes with vmxnet3

Status in QEMU:
  New

Bug description:
  Hello,
  This reproducer causes vmxnet3 to malloc 0xff030 bytes

  cat << EOF | ./i386-softmmu/qemu-system-i386 \
  -device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic 
  outl 0xcf8 0x80001014
  outl 0xcfc 0xe0001000
  outl 0xcf8 0x80001018
  outl 0xcf8 0x80001004
  outw 0xcfc 0x7
  write 0x0 0x1 0xe1
  write 0x1 0x1 0xfe
  write 0x2 0x1 0xbe
  write 0x3 0x1 0xba
  write 0x3e 0x1 0x05
  write 0x28 0x1 0xe1
  write 0x29 0x1 0xfe
  write 0x2a 0x1 0xff
  write 0x2b 0x1 0xff
  write 0x2c 0x1 0xff
  write 0x2d 0x1 0xff
  write 0x2e 0x1 0xff
  write 0x2f 0x1 0xff
  write 0x31c 0x1 0xff
  writeq 0xe0001020 0xef0bff5ecafe
  EOF


  =
  ==25727==ERROR: AddressSanitizer: allocator is out of memory trying to 
allocate 0xff030 bytes
  #0 0x56476a43731d in malloc 
(/home/alxndr/Development/qemu/general-fuzz/build/i386-softmmu/qemu-system-i386+0x2bba31d)
  #1 0x7fca345a8500 in g_malloc 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)
  #2 0x56476c616312 in vmxnet3_activate_device 
/home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1504:5
  #3 0x56476c6101ba in vmxnet3_handle_command 
/home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9
  #4 0x56476c60d30f in vmxnet3_io_bar1_write 
/home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9
  #5 0x56476b11d383 in memory_region_write_accessor 
/home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
  #6 0x56476b11c827 in access_with_adjusted_size 
/home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
  #7 0x56476b11a446 in memory_region_dispatch_write 
/home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
  #8 0x56476a4cb696 in flatview_write_continue 
/home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23
  #9 0x56476a4b3eb6 in flatview_write 
/home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14
  #10 0x56476a4b39d7 in address_space_write 
/home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18
  #11 0x56476b1c4614 in qtest_process_command 
/home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13
  #12 0x56476b1bbc18 in qtest_process_inbuf 
/home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9
  #13 0x56476b1ba8a5 in qtest_read 
/home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5
  #14 0x56476e063f03 in qemu_chr_be_write_impl 
/home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9
  #15 0x56476e064087 in qemu_chr_be_write 
/home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9
  #16 0x56476e078373 in fd_chr_read 
/home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9
  #17 0x56476e1cc734 in qio_channel_fd_source_dispatch 
/home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12
  #18 0x7fca345a2897 in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)

  
  -Alex

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



Re: [Bug 1913923] [NEW] assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach

2021-01-31 Thread Philippe Mathieu-Daudé
Cc'ing Dmitry Fleytman

On 1/31/21 5:29 AM, Gaoning Pan wrote:
> Public bug reported:
> 
> Hello,
> 
> I found an assertion failure in hw/net/vmxnet3.c:1793
> 
> This was found in latest version 5.2.0.
> 
> my reproduced is as follows:
> 
> 
> cat << EOF | ./qemu-system-x86_64 \
> -device vmxnet3 \
> -display none -nodefaults -qtest stdio 
> outl 0xcf8 0x80001014
> outl 0xcfc 0xf0001000
> outl 0xcf8 0x80001018
> outl 0xcf8 0x80001004
> outw 0xcfc 0x7
> writel 0x5c000 0xbabefee1
> writel 0x5c028 0x5d000
> writel 0x5c03c 0x01010101
> writel 0x5d038 0xe000 
> writel 0xf0001038 1
> EOF
> 
> 
> Backtrace is as follows:
> #0  0x7f6f641a5f47 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f6f641a78b1 in __GI_abort () at abort.c:79
> #2  0x7f6f67922315 in g_assertion_message () at 
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x7f6f6792237a in g_assertion_message_expr () at 
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x55edcaec96af in vmxnet3_io_bar1_write (opaque=0x62804100, 
> addr=56, val=1, size=4) at ../hw/net/vmxnet3.c:1793
> #5  0x55edcbd294c6 in memory_region_write_accessor (mr=0x62806b00, 
> addr=56, value=0x7fffd52ba848, size=4, shift=0, mask=4294967295, attrs=...) 
> at ../softmmu/memory.c:491
> #6  0x55edcbd299be in access_with_adjusted_size (addr=56, 
> value=0x7fffd52ba848, size=4, access_size_min=4, access_size_max=4, 
> access_fn=0x55edcbd2918c , mr=0x62806b00, 
> attrs=...) at ../softmmu/memory.c:552
> #7  0x55edcbd35ef2 in memory_region_dispatch_write (mr=0x62806b00, 
> addr=56, data=1, op=MO_32, attrs=...) at ../softmmu/memory.c:1501
> #8  0x55edcba1e554 in flatview_write_continue (fv=0x606619a0, 
> addr=4026535992, attrs=..., ptr=0x7fffd52bae80, len=4, addr1=56, l=4, 
> mr=0x62806b00) at ../softmmu/physmem.c:2759
> #9  0x55edcba1e8c5 in flatview_write (fv=0x606619a0, addr=4026535992, 
> attrs=..., buf=0x7fffd52bae80, len=4) at ../softmmu/physmem.c:2799
> #10 0x55edcba1f391 in address_space_write (as=0x60802620, 
> addr=4026535992, attrs=..., buf=0x7fffd52bae80, len=4) at 
> ../softmmu/physmem.c:2891
> #11 0x55edcbaff8d3 in qtest_process_command (chr=0x55edd03ff4a0 
> , words=0x6037f450) at ../softmmu/qtest.c:534
> #12 0x55edcbb04aa1 in qtest_process_inbuf (chr=0x55edd03ff4a0 
> , inbuf=0x6190fd00) at ../softmmu/qtest.c:797
> #13 0x55edcbb04bcc in qtest_read (opaque=0x55edd03ff4a0 , 
> buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 
> 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 
> 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 
> 0xe"..., size=225) at ../softmmu/qtest.c:809
> #14 0x55edcbe73742 in qemu_chr_be_write_impl (s=0x60f02110, 
> buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 
> 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 
> 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 
> 0xe"..., len=225) at ../chardev/char.c:201
> #15 0x55edcbe73820 in qemu_chr_be_write (s=0x60f02110, 
> buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 
> 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 
> 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 
> 0xe"..., len=225) at ../chardev/char.c:213
> #16 0x55edcbe9188e in fd_chr_read (chan=0x60802520, cond=(G_IO_IN | 
> G_IO_HUP), opaque=0x60f02110) at ../chardev/char-fd.c:68
> #17 0x55edcbe2379d in qio_channel_fd_source_dispatch 
> (source=0x60c25c00, callback=0x55edcbe915ac , 
> user_data=0x60f02110) at ../io/channel-watch.c:84
> #18 0x7f6f678fb285 in g_main_context_dispatch () at 
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #19 0x55edcc50b503 in glib_pollfds_poll () at ../util/main-loop.c:221
> #20 0x55edcc50b68b in os_host_main_loop_wait (timeout=0) at 
> ../util/main-loop.c:244
> #21 0x55edcc50b9a5 in main_loop_wait (nonblocking=0) at 
> ../util/main-loop.c:520
> #22 0x55edcbd8805b in qemu_main_loop () at ../softmmu/vl.c:1678
> #23 0x55edcab67e69 in main (argc=8, argv=0x7fffd52bd1d8, 
> envp=0x7fffd52bd220) at ../softmmu/main.c:50
> #24 0x7f6f64188b97 in __libc_start_main (main=0x55edcab67e2a , 
> argc=8, argv=0x7fffd52bd1d8, init=, fini=, 
> rtld_fini=, stack_end=0x7fffd52bd1c8) at 
> ../csu/libc-start.c:310
> #25 0x55edcab67d4a in _start ()




Re: [PATCH 4/6] m68k: add missing BUSCR/PCR CR defines, and BUSCR/PCR/CAAR CR to m68k_move_to/from

2021-01-31 Thread Philippe Mathieu-Daudé
On 2/1/21 1:01 AM, BALATON Zoltan wrote:
> From: Lucien Murray-Pitts 
> 
> The BUSCR/PCR CR defines were missing for 68060, and the move_to/from helper
> functions were also missing a decode for the 68060 M68K_CR_CAAR CR register.
> 
> Added missing defines, and respective decodes for all three CR registers to
> the helpers.
> 
> Although this patch defines them, the implementation is empty in this patch
> and these registers will result in a cpu abort - which is the default prior
> to this patch.
> 
> This patch aims to reach full coverage of all CR registers within the helpers.
> 
> Signed-off-by: Lucien Murray-Pitts 
> Reviewed-by: Laurent Vivier 
> Signed-off-by: BALATON Zoltan 
> ---
>  target/m68k/cpu.h|  4 
>  target/m68k/helper.c | 10 ++
>  2 files changed, 14 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé 



Re: [RFC 03/10] virtio: Add virtio_queue_get_idx

2021-01-31 Thread Eugenio Perez Martin
On Mon, Feb 1, 2021 at 7:10 AM Jason Wang  wrote:
>
>
> On 2021/1/30 上午4:54, Eugenio Pérez wrote:
> > Signed-off-by: Eugenio Pérez 
> > ---
> >   include/hw/virtio/virtio.h | 2 ++
> >   hw/virtio/virtio.c | 5 +
> >   2 files changed, 7 insertions(+)
> >
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 9988c6d5c9..9013c03424 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -399,6 +399,8 @@ static inline bool virtio_device_disabled(VirtIODevice 
> > *vdev)
> >   return unlikely(vdev->disabled || vdev->broken);
> >   }
> >
> > +unsigned virtio_queue_get_idx(const VirtIODevice *vdev, const VirtQueue 
> > *vq);
> > +
> >   bool virtio_legacy_allowed(VirtIODevice *vdev);
> >   bool virtio_legacy_check_disabled(VirtIODevice *vdev);
> >
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index ebb780fb42..3d14b0ef74 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -500,6 +500,11 @@ void virtio_queue_set_notification(VirtQueue *vq, int 
> > enable)
> >   }
> >   }
> >
> > +unsigned virtio_queue_get_idx(const VirtIODevice *vdev, const VirtQueue 
> > *vq)
> > +{
> > +return vq - vdev->vq;
> > +}
>
>
> It looks to me we had a dedicated index stored in VirtQueue:
> vq->queue_index.
>

You are right, I don't know why but missed it! It will be used in the
next series.

Thanks!

> Thanks
>
>
> > +
> >   int virtio_queue_ready(VirtQueue *vq)
> >   {
> >   return vq->vring.avail != 0;
>




Re: [PATCH] util/log: flush TB cache when log level changes

2021-01-31 Thread Pavel Dovgalyuk

On 25.01.2021 14:09, Alex Bennée wrote:


Pavel Dovgalyuk  writes:


On 22.01.2021 14:42, Alex Bennée wrote:


Pavel Dovgalyuk  writes:


Sometimes we need to collect the translation logs starting
from some point of the execution. Some TB listings may
be missed in this case, when blocks were translated before.
This patch clears TB cache to allow re-translation of such
code blocks.

Signed-off-by: Pavel Dovgalyuk 
---
   accel/tcg/translate-all.c |8 
   include/sysemu/tcg.h  |1 +
   stubs/meson.build |1 +
   stubs/tcg.c   |   12 
   util/log.c|3 +++
   5 files changed, 25 insertions(+)
   create mode 100644 stubs/tcg.c

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index e9de6ff9dd..3acb227c57 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -1461,6 +1461,14 @@ void tb_flush(CPUState *cpu)
   }
   }
   
+void tb_flush_all(void)

+{
+CPUState *cpu;
+CPU_FOREACH(cpu) {
+tb_flush(cpu);
+}
+}
+


This isn't needed - tb_flush flushes all translations although it does
need to be executed in a CPU context to do so.


   /*
* Formerly ifdef DEBUG_TB_CHECK. These debug functions are user-mode-only,
* so in order to prevent bit rot we compile them unconditionally in 
user-mode,
diff --git a/include/sysemu/tcg.h b/include/sysemu/tcg.h
index 00349fb18a..7415f11022 100644
--- a/include/sysemu/tcg.h
+++ b/include/sysemu/tcg.h
@@ -9,6 +9,7 @@
   #define SYSEMU_TCG_H
   
   void tcg_exec_init(unsigned long tb_size, int splitwx);

+void tb_flush_all(void);
   
   #ifdef CONFIG_TCG

   extern bool tcg_allowed;
diff --git a/stubs/meson.build b/stubs/meson.build
index 80b1d81a31..95e70f8542 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -38,6 +38,7 @@ stub_ss.add(files('set-fd-handler.c'))
   stub_ss.add(files('sysbus.c'))
   stub_ss.add(files('target-get-monitor-def.c'))
   stub_ss.add(files('target-monitor-defs.c'))
+stub_ss.add(files('tcg.c'))
   stub_ss.add(files('tpm.c'))
   stub_ss.add(files('trace-control.c'))
   stub_ss.add(files('uuid.c'))
diff --git a/stubs/tcg.c b/stubs/tcg.c
new file mode 100644
index 00..775a748c77
--- /dev/null
+++ b/stubs/tcg.c
@@ -0,0 +1,12 @@
+/*
+ * TCG stubs
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "sysemu/tcg.h"
+
+void tb_flush_all(void)
+{
+}
diff --git a/util/log.c b/util/log.c
index 2ee1500bee..2ff342a91b 100644
--- a/util/log.c
+++ b/util/log.c
@@ -26,6 +26,7 @@
   #include "trace/control.h"
   #include "qemu/thread.h"
   #include "qemu/lockable.h"
+#include "sysemu/tcg.h"
   
   static char *logfilename;

   static QemuMutex qemu_logfile_mutex;
@@ -84,6 +85,8 @@ void qemu_set_log(int log_flags)
   #ifdef CONFIG_TRACE_LOG
   qemu_loglevel |= LOG_TRACE;
   #endif
+tb_flush_all();
+


I would call tb_flush(current_cpu) or first_cpu here. But two things:

   - I'm not sure you have a CPU at all times qemu_set_log is called
   - It seems overly aggressive to throw away all translations every time
 the log level is changed. I would define a mask in log.h and have
 something like:


Do you propose removing the parameter from tb_flush or omitting the loop
from tb_flush_all?


No tb_flush should keep the CPU interface. In normal usage from the
emulation we always have a CPU to call. However for qemu_set_log you
will need to find a CPU to call or bail out if you can't. Maybe


It the following true? We can't get rid of CPU in tb_flush, because 
do_tb_flush must be executed in vCPU thread.
Can one CPU break others execution in case of SMP? Can we move flush to 
BH somehow?



something like:

   CPUStatus *cpu = current_cpu || first_cpu;
   if (cpu) {
   tb_flush(cpu);
   }



Then we'll have to expose all this CPU stuff to utils and add stubs for 
them.



my only worry is if qemu_set_log is called from outside a CPU context
(current_cpu will always be NULL) while first_cpu is in a exclusive
region. We could extend cpu_in_exclusive_context to be:

   cpu == current_cpu && cpu->in_exclusive_context

but that seems a little icky to me. Paolo, any thoughts?




if (log_flags & LOG_TRANSLATION) {
tb_flush();
}


   /*
* In all cases we only log if qemu_loglevel is set.
* Also:











[PATCH v2] replay: fix replay of the interrupts

2021-01-31 Thread Pavel Dovgalyuk
Sometimes interrupt event comes at the same time with
the virtual timers. In this case replay tries to proceed
the timers, because deadline for them is zero.
This patch allows processing interrupts and exceptions
by entering the vCPU execution loop, when deadline is zero,
but checkpoint associated with virtual timers is not ready
to be replayed.

Signed-off-by: Pavel Dovgalyuk 

---
v2:
 - changed replay mode check condition
---
 accel/tcg/tcg-cpus-icount.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/accel/tcg/tcg-cpus-icount.c b/accel/tcg/tcg-cpus-icount.c
index 9f45432275..8ed485db01 100644
--- a/accel/tcg/tcg-cpus-icount.c
+++ b/accel/tcg/tcg-cpus-icount.c
@@ -81,7 +81,13 @@ void icount_handle_deadline(void)
 int64_t deadline = qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL,
   QEMU_TIMER_ATTR_ALL);
 
-if (deadline == 0) {
+/*
+ * Instructions, interrupts, and exceptions are processed in cpu-exec.
+ * Don't interrupt cpu thread, when these events are waiting
+ * (i.e., there is no checkpoint)
+ */
+if (deadline == 0
+&& (replay_mode != REPLAY_MODE_PLAY || replay_has_checkpoint())) {
 icount_notify_aio_contexts();
 }
 }




Re: [PATCH] MAINTAINERS: update bsd-user maintainers

2021-01-31 Thread Thomas Huth

On 30/01/2021 17.46, Warner Losh wrote:

bsd-user: Add new mainatiners

The FreeBSD project has a number of enhancements to bsd-user. Add myself
as maintainer and Kyle Evans as a reviewer. Also add our github repo.

Signed-off-by: Warner Losh mailto:i...@bsdimp.com>>
---
  MAINTAINERS | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bcd88668bc..1b2c276eca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2845,9 +2845,12 @@ F: thunk.c
  F: accel/tcg/user-exec*.c

  BSD user
-S: Orphan
+M: Warner Losh mailto:i...@bsdimp.com>>
+R: Kyle Evans mailto:kev...@freebsd.org>>
+S: Maintained
  F: bsd-user/
  F: default-configs/*-bsd-user.mak


Oh, by the way, while you're at it, please update the second F: line to:

 F: default-configs/targets/*-bsd-user.mak

Otherwise the scripts/get_maintainer.pl script won't recognize the files 
correctly.


 Thomas




Re: [RFC 09/10] vhost: Route guest->host notification through shadow virtqueue

2021-01-31 Thread Jason Wang



On 2021/1/30 上午4:54, Eugenio Pérez wrote:

Shadow virtqueue notifications forwarding is disabled when vhost_dev
stops.

Signed-off-by: Eugenio Pérez 
---
  hw/virtio/vhost-shadow-virtqueue.h |   5 ++
  include/hw/virtio/vhost.h  |   4 +
  hw/virtio/vhost-shadow-virtqueue.c | 123 +-
  hw/virtio/vhost.c  | 135 -
  4 files changed, 264 insertions(+), 3 deletions(-)

diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
b/hw/virtio/vhost-shadow-virtqueue.h
index 6cc18d6acb..466f8ae595 100644
--- a/hw/virtio/vhost-shadow-virtqueue.h
+++ b/hw/virtio/vhost-shadow-virtqueue.h
@@ -17,6 +17,11 @@
  
  typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
  
+bool vhost_shadow_vq_start_rcu(struct vhost_dev *dev,

+   VhostShadowVirtqueue *svq);
+void vhost_shadow_vq_stop_rcu(struct vhost_dev *dev,
+  VhostShadowVirtqueue *svq);
+
  VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev *dev, int idx);
  
  void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);

diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index 2be782cefd..732a4b2a2b 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -55,6 +55,8 @@ struct vhost_iommu {
  QLIST_ENTRY(vhost_iommu) iommu_next;
  };
  
+typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;

+
  typedef struct VhostDevConfigOps {
  /* Vhost device config space changed callback
   */
@@ -83,7 +85,9 @@ struct vhost_dev {
  uint64_t backend_cap;
  bool started;
  bool log_enabled;
+bool sw_lm_enabled;
  uint64_t log_size;
+VhostShadowVirtqueue **shadow_vqs;
  Error *migration_blocker;
  const VhostOps *vhost_ops;
  void *opaque;
diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
b/hw/virtio/vhost-shadow-virtqueue.c
index c0c967a7c5..908c36c66d 100644
--- a/hw/virtio/vhost-shadow-virtqueue.c
+++ b/hw/virtio/vhost-shadow-virtqueue.c
@@ -8,15 +8,129 @@
   */
  
  #include "hw/virtio/vhost-shadow-virtqueue.h"

+#include "hw/virtio/vhost.h"
+#include "hw/virtio/virtio-access.h"
+
+#include "standard-headers/linux/vhost_types.h"
+#include "standard-headers/linux/virtio_ring.h"
  
  #include "qemu/error-report.h"

-#include "qemu/event_notifier.h"
+#include "qemu/main-loop.h"
  
  typedef struct VhostShadowVirtqueue {

  EventNotifier kick_notifier;
  EventNotifier call_notifier;
+const struct vhost_virtqueue *hvq;
+VirtIODevice *vdev;
+VirtQueue *vq;
  } VhostShadowVirtqueue;



So instead of doing things at virtio level, how about do the shadow 
stuffs at vhost level?


It works like:

virtio -> [shadow vhost backend] -> vhost backend

Then the QMP is used to plug the shadow vhost backend in the middle or not.

It looks kind of easier since we don't need to deal with virtqueue 
handlers etc.. Instead, we just need to deal with eventfd stuffs:


When shadow vhost mode is enabled, we just intercept the host_notifiers 
and guest_notifiers. When it was disabled, we just pass the host/guest 
notifiers to the real vhost backends?


Thanks


  
+static uint16_t vhost_shadow_vring_used_flags(VhostShadowVirtqueue *svq)

+{
+const struct vring_used *used = svq->hvq->used;
+return virtio_tswap16(svq->vdev, used->flags);
+}
+
+static bool vhost_shadow_vring_should_kick(VhostShadowVirtqueue *vq)
+{
+return !(vhost_shadow_vring_used_flags(vq) & VRING_USED_F_NO_NOTIFY);
+}
+
+static void vhost_shadow_vring_kick(VhostShadowVirtqueue *vq)
+{
+if (vhost_shadow_vring_should_kick(vq)) {
+event_notifier_set(>kick_notifier);
+}
+}
+
+static void handle_shadow_vq(VirtIODevice *vdev, VirtQueue *vq)
+{
+struct vhost_dev *hdev = vhost_dev_from_virtio(vdev);
+uint16_t idx = virtio_get_queue_index(vq);
+
+VhostShadowVirtqueue *svq = hdev->shadow_vqs[idx];
+
+vhost_shadow_vring_kick(svq);
+}
+
+/*
+ * Start shadow virtqueue operation.
+ * @dev vhost device
+ * @svq Shadow Virtqueue
+ *
+ * Run in RCU context
+ */
+bool vhost_shadow_vq_start_rcu(struct vhost_dev *dev,
+   VhostShadowVirtqueue *svq)
+{
+const VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(dev->vdev);
+EventNotifier *vq_host_notifier = virtio_queue_get_host_notifier(svq->vq);
+unsigned idx = virtio_queue_get_idx(svq->vdev, svq->vq);
+struct vhost_vring_file kick_file = {
+.index = idx,
+.fd = event_notifier_get_fd(>kick_notifier),
+};
+int r;
+bool ok;
+
+/* Check that notifications are still going directly to vhost dev */
+assert(virtio_queue_host_notifier_status(svq->vq));
+
+ok = k->set_vq_handler(dev->vdev, idx, handle_shadow_vq);
+if (!ok) {
+error_report("Couldn't set the vq handler");
+goto err_set_kick_handler;
+}
+
+r = dev->vhost_ops->vhost_set_vring_kick(dev, _file);
+if (r != 0) {
+error_report("Couldn't set kick fd: %s", 

Re: [PATCH] MAINTAINERS: update bsd-user maintainers

2021-01-31 Thread Thomas Huth

On 30/01/2021 17.46, Warner Losh wrote:

bsd-user: Add new mainatiners


s/mainatiners/maintainers/


The FreeBSD project has a number of enhancements to bsd-user. Add myself
as maintainer and Kyle Evans as a reviewer. Also add our github repo.


Thanks for taking care of this!


Signed-off-by: Warner Losh mailto:i...@bsdimp.com>>
---
  MAINTAINERS | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bcd88668bc..1b2c276eca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2845,9 +2845,12 @@ F: thunk.c
  F: accel/tcg/user-exec*.c

  BSD user
-S: Orphan
+M: Warner Losh mailto:i...@bsdimp.com>>
+R: Kyle Evans mailto:kev...@freebsd.org>>
+S: Maintained
  F: bsd-user/
  F: default-configs/*-bsd-user.mak
+T: git https://github.com/qemu-bsd-user/qemu-bse-user 
bsd-user-rebase-3.1


s/qemu-bse-user/qemu-bsd-user/

With the typos fixed:

Reviewed-by: Thomas Huth 

PS: Please avoid sending patches as HTML e-mails!




Re: [PATCH 0/9] Fix some style problems in net

2021-01-31 Thread zhanghan (J)
ping?This patch set about code style problem in net receives no replies.

Did I miss any response?

The link follows:
http://patchwork.ozlabs.org/project/qemu-devel/cover/20201222082340.67405-1-zhangha...@huawei.com/



Re: [PATCH 0/4] Fix some style problems in qobject

2021-01-31 Thread zhanghan (J)
ping?This patch set about code style problem in qobject  receives no replies.

Did I miss any response?

The link follows:
http://patchwork.ozlabs.org/project/qemu-devel/cover/20201228071129.24563-1-zhangha...@huawei.com/



Re: [RFC 05/10] vhost: Add vhost_dev_from_virtio

2021-01-31 Thread Jason Wang



On 2021/1/30 上午4:54, Eugenio Pérez wrote:

Signed-off-by: Eugenio Pérez 
---
  include/hw/virtio/vhost.h |  1 +
  hw/virtio/vhost.c | 17 +
  2 files changed, 18 insertions(+)

diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index 4a8bc75415..fca076e3f0 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -123,6 +123,7 @@ uint64_t vhost_get_features(struct vhost_dev *hdev, const 
int *feature_bits,
  void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits,
  uint64_t features);
  bool vhost_has_free_slot(void);
+struct vhost_dev *vhost_dev_from_virtio(const VirtIODevice *vdev);
  
  int vhost_net_set_backend(struct vhost_dev *hdev,

struct vhost_vring_file *file);
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 28c7d78172..8683d507f5 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -61,6 +61,23 @@ bool vhost_has_free_slot(void)
  return slots_limit > used_memslots;
  }
  
+/*

+ * Get the vhost device associated to a VirtIO device.
+ */
+struct vhost_dev *vhost_dev_from_virtio(const VirtIODevice *vdev)
+{
+struct vhost_dev *hdev;
+
+QLIST_FOREACH(hdev, _devices, entry) {
+if (hdev->vdev == vdev) {
+return hdev;
+}
+}
+
+assert(hdev);
+return NULL;
+}



I'm not sure this can work in the case of multiqueue. E.g vhost-net 
multiqueue is a N:1 mapping between vhost devics and virtio devices.


Thanks



+
  static void vhost_dev_sync_region(struct vhost_dev *dev,
MemoryRegionSection *section,
uint64_t mfirst, uint64_t mlast,





Re: [RFC 03/10] virtio: Add virtio_queue_get_idx

2021-01-31 Thread Jason Wang



On 2021/1/30 上午4:54, Eugenio Pérez wrote:

Signed-off-by: Eugenio Pérez 
---
  include/hw/virtio/virtio.h | 2 ++
  hw/virtio/virtio.c | 5 +
  2 files changed, 7 insertions(+)

diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 9988c6d5c9..9013c03424 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -399,6 +399,8 @@ static inline bool virtio_device_disabled(VirtIODevice 
*vdev)
  return unlikely(vdev->disabled || vdev->broken);
  }
  
+unsigned virtio_queue_get_idx(const VirtIODevice *vdev, const VirtQueue *vq);

+
  bool virtio_legacy_allowed(VirtIODevice *vdev);
  bool virtio_legacy_check_disabled(VirtIODevice *vdev);
  
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c

index ebb780fb42..3d14b0ef74 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -500,6 +500,11 @@ void virtio_queue_set_notification(VirtQueue *vq, int 
enable)
  }
  }
  
+unsigned virtio_queue_get_idx(const VirtIODevice *vdev, const VirtQueue *vq)

+{
+return vq - vdev->vq;
+}



It looks to me we had a dedicated index stored in VirtQueue: 
vq->queue_index.


Thanks



+
  int virtio_queue_ready(VirtQueue *vq)
  {
  return vq->vring.avail != 0;





Re: [PATCH] vhost: Check for valid vdev in vhost_backend_handle_iotlb_msg

2021-01-31 Thread Jason Wang



On 2021/1/29 下午5:07, Eugenio Pérez wrote:

Not checking this can lead to invalid dev->vdev member access in
vhost_device_iotlb_miss if backend issue an iotlb message in a bad
timing, either maliciously or by a bug.

Reproduced rebooting a guest with testpmd in txonly forward mode.
  #0  0x55994394 in vhost_device_iotlb_miss (
  dev=dev@entry=0x55a0012f6680, iova=10245279744, write=1)
  at ../hw/virtio/vhost.c:1013
  #1  0x5599ac31 in vhost_backend_handle_iotlb_msg (
  imsg=0x7ffddcfd32c0, dev=0x55a0012f6680)
  at ../hw/virtio/vhost-backend.c:411
  #2  vhost_backend_handle_iotlb_msg (dev=dev@entry=0x55a0012f6680,
  imsg=imsg@entry=0x7ffddcfd32c0)
  at ../hw/virtio/vhost-backend.c:404
  #3  0x559fffeded7b in slave_read (opaque=0x55a0012f6680)
  at ../hw/virtio/vhost-user.c:1464
  #4  0x55ac541b in aio_dispatch_handler (
  ctx=ctx@entry=0x55a0010a2120, node=0x55a0012d9e00)
  at ../util/aio-posix.c:329

Fixes: 6dcdd06e3b ("spec/vhost-user spec: Add IOMMU support")
Signed-off-by: Eugenio Pérez 



Acked-by: Jason Wang 



---
  hw/virtio/vhost-backend.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/hw/virtio/vhost-backend.c b/hw/virtio/vhost-backend.c
index 222bbcc62d..31b33bde37 100644
--- a/hw/virtio/vhost-backend.c
+++ b/hw/virtio/vhost-backend.c
@@ -406,6 +406,11 @@ int vhost_backend_handle_iotlb_msg(struct vhost_dev *dev,
  {
  int ret = 0;
  
+if (unlikely(!dev->vdev)) {

+error_report("Unexpected IOTLB message when virtio device is stopped");
+return -EINVAL;
+}
+
  switch (imsg->type) {
  case VHOST_IOTLB_MISS:
  ret = vhost_device_iotlb_miss(dev, imsg->iova,





[PATCH v2 1/2] target/i386: add "-cpu, lbr-fmt=*" support to enable guest LBR

2021-01-31 Thread Like Xu
The last branch recording (LBR) is a performance monitor unit (PMU)
feature on Intel processors that records a running trace of the most
recent branches taken by the processor in the LBR stack. The QEMU
could configure whether it's enabled or not for each guest via CLI.

The LBR feature would be enabled on the guest if:
- the KVM is enabled and the PMU is enabled and,
- the msr-based-feature IA32_PERF_CAPABILITIES is supporterd on KVM and,
- the supported returned value for lbr_fmt from this msr is not zero and,
- the requested guest vcpu model does support FEAT_1_ECX.CPUID_EXT_PDCM,
- the configured lbr-fmt value is the same as the host lbr_fmt value
  or use the QEMU option "-cpu host,migratable=no".

Cc: Eduardo Habkost 
Cc: Paolo Bonzini 
Signed-off-by: Like Xu 
---
 target/i386/cpu.c | 16 
 target/i386/cpu.h | 10 ++
 target/i386/kvm/kvm.c |  5 +++--
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ae89024d36..80a5d3f0c2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6504,6 +6504,13 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool 
verbose)
 x86_cpu_get_supported_feature_word(w, false);
 uint64_t requested_features = env->features[w];
 uint64_t unavailable_features = requested_features & ~host_feat;
+if (kvm_enabled() && w == FEAT_PERF_CAPABILITIES &&
+(requested_features & PERF_CAP_LBR_FMT)) {
+if ((host_feat & PERF_CAP_LBR_FMT) !=
+(requested_features & PERF_CAP_LBR_FMT)) {
+unavailable_features |= PERF_CAP_LBR_FMT;
+}
+}
 mark_unavailable_features(cpu, w, unavailable_features, prefix);
 }
 
@@ -6611,6 +6618,14 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 }
 }
 
+if (cpu->lbr_fmt) {
+if (!cpu->enable_pmu) {
+error_setg(errp, "LBR is unsupported since guest PMU is 
disabled.");
+return;
+}
+env->features[FEAT_PERF_CAPABILITIES] |= cpu->lbr_fmt;
+}
+
 /* mwait extended info: needed for Core compatibility */
 /* We always wake on interrupt even if host does not have the capability */
 cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
@@ -7184,6 +7199,7 @@ static Property x86_cpu_properties[] = {
 #endif
 DEFINE_PROP_INT32("node-id", X86CPU, node_id, CPU_UNSET_NUMA_NODE_ID),
 DEFINE_PROP_BOOL("pmu", X86CPU, enable_pmu, false),
+DEFINE_PROP_UINT8("lbr-fmt", X86CPU, lbr_fmt, 0),
 
 DEFINE_PROP_UINT32("hv-spinlocks", X86CPU, hyperv_spinlock_attempts,
HYPERV_SPINLOCK_NEVER_NOTIFY),
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d23a5b340a..64320bced2 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -354,6 +354,7 @@ typedef enum X86Seg {
 #define ARCH_CAP_TSX_CTRL_MSR  (1<<7)
 
 #define MSR_IA32_PERF_CAPABILITIES  0x345
+#define PERF_CAP_LBR_FMT  0x3f
 
 #define MSR_IA32_TSX_CTRL  0x122
 #define MSR_IA32_TSCDEADLINE0x6e0
@@ -1709,6 +1710,15 @@ struct X86CPU {
  */
 bool enable_pmu;
 
+/*
+ * Configure LBR_FMT bits on IA32_PERF_CAPABILITIES MSR.
+ * This can't be enabled by default yet because it doesn't have
+ * ABI stability guarantees, as it is only allowed to pass all
+ * LBR_FMT bits returned by kvm_arch_get_supported_msr_feature()
+ * (that depends on host CPU and kernel capabilities) to the guest.
+ */
+uint8_t lbr_fmt;
+
 /* LMCE support can be enabled/disabled via cpu option 'lmce=on/off'. It is
  * disabled by default to avoid breaking migration between QEMU with
  * different LMCE configurations.
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 6dc1ee052d..49745efb78 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -2705,8 +2705,9 @@ static void kvm_msr_entry_add_perf(X86CPU *cpu, 
FeatureWordArray f)
MSR_IA32_PERF_CAPABILITIES);
 
 if (kvm_perf_cap) {
-kvm_msr_entry_add(cpu, MSR_IA32_PERF_CAPABILITIES,
-kvm_perf_cap & f[FEAT_PERF_CAPABILITIES]);
+kvm_perf_cap = cpu->migratable ?
+(kvm_perf_cap & f[FEAT_PERF_CAPABILITIES]) : kvm_perf_cap;
+kvm_msr_entry_add(cpu, MSR_IA32_PERF_CAPABILITIES, kvm_perf_cap);
 }
 }
 
-- 
2.29.2




[PATCH v2 2/2] target/i386: add kvm_exact_match_flags to FeatureWordInfo

2021-01-31 Thread Like Xu
Eduardo has a suggestion: instead of hardcoding the
PERF_CAPABILITIES rules in this loop, this could become a
FeatureWordInfo field. It would be very useful for other
features like intel-pt, where we need some bits to match the
host too.

Suggested-by: Eduardo Habkost 
Signed-off-by: Like Xu 
---
 target/i386/cpu.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 80a5d3f0c2..8eaa5879ea 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -708,6 +708,8 @@ typedef struct FeatureWordInfo {
 uint64_t migratable_flags; /* Feature flags known to be migratable */
 /* Features that shouldn't be auto-enabled by "-cpu host" */
 uint64_t no_autoenable_flags;
+/* Bits that must match host exactly when using KVM */
+uint64_t kvm_exact_match_flags;
 } FeatureWordInfo;
 
 static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
@@ -1147,6 +1149,11 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
= {
 .msr = {
 .index = MSR_IA32_PERF_CAPABILITIES,
 },
+/*
+ * KVM is not able to emulate a VCPU with LBR_FMT different
+ * from the host, so LBR_FMT must match the host exactly.
+ */
+.kvm_exact_match_flags = PERF_CAP_LBR_FMT,
 },
 
 [FEAT_VMX_PROCBASED_CTLS] = {
@@ -6500,16 +6507,18 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool 
verbose)
 }
 
 for (w = 0; w < FEATURE_WORDS; w++) {
+FeatureWordInfo *fi = _word_info[w];
+uint64_t match_flags = fi->kvm_exact_match_flags;
 uint64_t host_feat =
 x86_cpu_get_supported_feature_word(w, false);
 uint64_t requested_features = env->features[w];
 uint64_t unavailable_features = requested_features & ~host_feat;
-if (kvm_enabled() && w == FEAT_PERF_CAPABILITIES &&
-(requested_features & PERF_CAP_LBR_FMT)) {
-if ((host_feat & PERF_CAP_LBR_FMT) !=
-(requested_features & PERF_CAP_LBR_FMT)) {
-unavailable_features |= PERF_CAP_LBR_FMT;
-}
+if (kvm_enabled() && match_flags) {
+uint64_t mismatches = (requested_features & match_flags) &&
+(requested_features ^ host_feat) & match_flags;
+mark_unavailable_features(cpu, w,
+mismatches, "feature doesn't match host");
+unavailable_features &= ~match_flags;
 }
 mark_unavailable_features(cpu, w, unavailable_features, prefix);
 }
-- 
2.29.2




Re: [PATCH v2] ppc/pnv: Set default RAM size to 1 GB

2021-01-31 Thread David Gibson
On Fri, Jan 29, 2021 at 12:17:19PM +0100, Cédric Le Goater wrote:
65;6201;1c> The memory layout of the PowerNV machine is defined as :
> 
>   #define KERNEL_LOAD_BASE((void *)0x2000)
>   #define KERNEL_LOAD_SIZE0x0800
> 
>   #define INITRAMFS_LOAD_BASE KERNEL_LOAD_BASE + KERNEL_LOAD_SIZE
>   #define INITRAMFS_LOAD_SIZE 0x0800
> 
>   #define SKIBOOT_BASE0x3000
>   #define SKIBOOT_SIZE0x01c1
> 
>   #define CPU_STACKS_BASE (SKIBOOT_BASE + SKIBOOT_SIZE)
>   #define STACK_SHIFT 15
>   #define STACK_SIZE  (1 << STACK_SHIFT)
> 
> The overall size of the CPU stacks is (max PIR + 1) * 32K and the
> machine easily reaches 800MB of minimum required RAM.
> 
> Any value below will result in a skiboot crash :
> 
> [0.034949905,3] MEM: Partial overlap detected between regions:
> [0.034959039,3] MEM: ibm,firmware-stacks [0x31c1-0x3a45] (new)
> [0.034968576,3] MEM: ibm,firmware-allocs-memory@0 
> [0x31c1-0x3840]
> [0.034980367,3] Out of memory adding skiboot reserved areas
> [0.035074945,3] ***
> [0.035093627,3] < assert failed at core/mem_region.c:1129 >
> [0.035104247,3] .
> [0.035108025,3]  .
> [0.035111651,3]   .
> [0.035115231,3] OO__)
> [0.035119198,3]<"__/
> [0.035122980,3] ^ ^
> 
> Signed-off-by: Cédric Le Goater 

Applied to ppc-for-6.0, thanks.

> ---
>  hw/ppc/pnv.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 50810df83815..77af846cdfea 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -21,6 +21,7 @@
>  #include "qemu-common.h"
>  #include "qemu/datadir.h"
>  #include "qemu/units.h"
> +#include "qemu/cutils.h"
>  #include "qapi/error.h"
>  #include "sysemu/qtest.h"
>  #include "sysemu/sysemu.h"
> @@ -725,8 +726,11 @@ static void pnv_init(MachineState *machine)
>  DeviceState *dev;
>  
>  /* allocate RAM */
> -if (machine->ram_size < (1 * GiB)) {
> -warn_report("skiboot may not work with < 1GB of RAM");
> +if (machine->ram_size < mc->default_ram_size) {
> +char *sz = size_to_str(mc->default_ram_size);
> +error_report("Invalid RAM size, should be bigger than %s", sz);
> +g_free(sz);
> +exit(EXIT_FAILURE);
>  }
>  memory_region_add_subregion(get_system_memory(), 0, machine->ram);
>  
> @@ -1994,7 +1998,7 @@ static void pnv_machine_class_init(ObjectClass *oc, 
> void *data)
>   * RAM defaults to less than 2048 for 32-bit hosts, and large
>   * enough to fit the maximum initrd size at it's load address
>   */
> -mc->default_ram_size = INITRD_LOAD_ADDR + INITRD_MAX_SIZE;
> +mc->default_ram_size = 1 * GiB;
>  mc->default_ram_id = "pnv.ram";
>  ispc->print_info = pnv_pic_print_info;
>  nc->nmi_monitor_handler = pnv_nmi;

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


signature.asc
Description: PGP signature


Re: [RFC PATCH v2 3/3] vfio: Avoid disabling and enabling vectors repeatedly in VFIO migration

2021-01-31 Thread Shenming Lu
On 2021/1/27 22:21, Alex Williamson wrote:
> On Wed, 27 Jan 2021 19:27:35 +0800
> Shenming Lu  wrote:
> 
>> On 2021/1/27 5:36, Alex Williamson wrote:
>>> On Wed, 9 Dec 2020 16:09:19 +0800
>>> Shenming Lu  wrote:
>>>   
 Different from the normal situation when the guest starts, we can
 know the max unmasked vetctor (at the beginning) after msix_load()
 in VFIO migration. So in order to avoid ineffectively disabling and  
>>>
>>> s/ineffectively/inefficiently/?  It's "effective" either way I think.  
>>
>> Yeah, I should say "inefficiently". :-)
>>
>>>   
 enabling vectors repeatedly, let's allocate all needed vectors first
 and then enable these unmasked vectors one by one without disabling.

 Signed-off-by: Shenming Lu 
 ---
  hw/pci/msix.c | 17 +
  hw/vfio/pci.c | 10 --
  include/hw/pci/msix.h |  2 ++
  3 files changed, 27 insertions(+), 2 deletions(-)

 diff --git a/hw/pci/msix.c b/hw/pci/msix.c
 index 67e34f34d6..bf291d3ff8 100644
 --- a/hw/pci/msix.c
 +++ b/hw/pci/msix.c
 @@ -557,6 +557,23 @@ unsigned int msix_nr_vectors_allocated(const 
 PCIDevice *dev)
  return dev->msix_entries_nr;
  }
  
 +int msix_get_max_unmasked_vector(PCIDevice *dev)
 +{
 +int max_unmasked_vector = -1;
 +int vector;
 +
 +if ((dev->config[dev->msix_cap + MSIX_CONTROL_OFFSET] &
 +(MSIX_ENABLE_MASK | MSIX_MASKALL_MASK)) == MSIX_ENABLE_MASK) {
 +for (vector = 0; vector < dev->msix_entries_nr; vector++) {
 +if (!msix_is_masked(dev, vector)) {
 +max_unmasked_vector = vector;
 +}
 +}
 +}
 +
 +return max_unmasked_vector;
 +}  
>>>
>>> Comments from QEMU PCI folks?
>>>   
 +
  static int msix_set_notifier_for_vector(PCIDevice *dev, unsigned int 
 vector)
  {
  MSIMessage msg;
 diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
 index 51dc373695..e755ed2514 100644
 --- a/hw/vfio/pci.c
 +++ b/hw/vfio/pci.c
 @@ -568,6 +568,9 @@ static void vfio_msix_vector_release(PCIDevice *pdev, 
 unsigned int nr)
  
  static void vfio_msix_enable(VFIOPCIDevice *vdev)
  {
 +int max_unmasked_vector = msix_get_max_unmasked_vector(>pdev);
 +unsigned int used_vector = MAX(max_unmasked_vector, 0);
 +  
>>>
>>> The above PCI function could also be done inline here pretty easily too:
>>>
>>> unsigned int nr, max_vec = 0;
>>>
>>> if (!msix_masked(>pdev))
>>> for (nr = 0; nr < msix_nr_vectors_allocated(>pdev); nr++) {
>>> if (!msix_is_masked(>pdev, nr)) {
>>> max_vec = nr;
>>> }
>>> }
>>> }
>>>
>>> It's a bit cleaner than the msix utility function, imo.  
>>
>> Yeah, it makes sense.
>>
>>>   
  vfio_disable_interrupts(vdev);
  
  vdev->msi_vectors = g_new0(VFIOMSIVector, vdev->msix->entries);
 @@ -586,9 +589,12 @@ static void vfio_msix_enable(VFIOPCIDevice *vdev)
   * triggering to userspace, then immediately release the vector, 
 leaving
   * the physical device with no vectors enabled, but MSI-X enabled, 
 just
   * like the guest view.
 + * If there are unmasked vectors (such as in migration) which will be
 + * enabled soon, we can allocate them here to avoid ineffectively 
 disabling
 + * and enabling vectors repeatedly later.  
>>>
>>> It just happens that migration triggers this usage model where the
>>> MSI-X enable bit is set with vectors unmasked in the vector table, but
>>> this is not unique to migration, guests can follow this pattern as well.
>>> Has this been tested with a variety of guests?  Logically it seems
>>> correct, but always good to prove so.  Thanks,  
>>
>> I have tested it in migration and normal guest startup (only the latest 
>> Linux).
>> And I can try to test with some other kernels, could you be more specific 
>> about this?
> 
> Minimally also Windows, ideally a BSD as well.  Thanks,
> 

Hi Alex,

I have tested this patch with a Windows guest (Windows Server 2012 R2 
Datacenter, Intel
X722 Ethernet controller (passthrough)) and nothing went wrong. And I found 
that it does
trigger our usage model in the normal guest startup: has all needed vectors 
already unmasked
in the vector table when calling vfio_msix_enable()...

Thanks,
Shenming



RE: [PATCH v4] blockjob: Fix crash with IOthread when block commit after snapshot

2021-01-31 Thread 仇大玉
Any comments?

It's really a bug and can cause the qemu to segmentfault.

Thanks,
Michael

-Original Message-
From: 仇大玉 
Sent: 2021年1月28日 13:16
To: qemu-bl...@nongnu.org; qemu-devel@nongnu.org
Cc: kw...@redhat.com; mre...@redhat.com; js...@redhat.com; 08005...@163.com
Subject: RE: [PATCH v4] blockjob: Fix crash with IOthread when block commit 
after snapshot

Any comments?

-Original Message-
From: 08005...@163.com <08005...@163.com> 
Sent: 2021年1月28日 9:31
To: kw...@redhat.com; mre...@redhat.com; js...@redhat.com
Cc: qemu-bl...@nongnu.org; qemu-devel@nongnu.org; 仇大玉 
Subject: [PATCH v4] blockjob: Fix crash with IOthread when block commit after 
snapshot

From: Michael Qiu 

v4: rebase to latest code

v3: reformat the commit log, remove duplicate content

v2: modify the coredump backtrace within commit log with the newest
qemu with master branch

Currently, if guest has workloads, IO thread will acquire aio_context lock 
before do io_submit, it leads to segmentfault when do block commit after 
snapshot. Just like below:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f7c7d91f700 (LWP 99907)] 0x5576d0f65aab in 
bdrv_mirror_top_pwritev at ../block/mirror.c:1437
1437../block/mirror.c: No such file or directory.
(gdb) p s->job
$17 = (MirrorBlockJob *) 0x0
(gdb) p s->stop
$18 = false

(gdb) bt

Switch to qemu main thread:
/lib/../lib64/libpthread.so.0
/lib/../lib64/libpthread.so.0
../util/qemu-thread-posix.c:79
qapi/qapi-commands-block-core.c:346
../qapi/qmp-dispatch.c:110
/lib/../lib64/libglib-2.0.so.0

In IO thread when do bdrv_mirror_top_pwritev, the job is NULL, and stop field 
is false, this means the MirrorBDSOpaque "s" object has not been initialized 
yet, and this object is initialized by block_job_create(), but the initialize 
process is stuck in acquiring the lock.

The rootcause is that qemu do release/acquire when hold the lock, at the same 
time, IO thread get the lock after release stage, and the crash occured.

Actually, in this situation, job->job.aio_context will not equal to 
qemu_get_aio_context(), and will be the same as bs->aio_context, thus, no need 
to release the lock, becasue bdrv_root_attach_child() will not change the 
context.

This patch fix this issue.

Signed-off-by: Michael Qiu 
---
 blockjob.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/blockjob.c b/blockjob.c
index 98ac8af982..51a09f3b60 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -214,13 +214,15 @@ int block_job_add_bdrv(BlockJob *job, const char *name, 
BlockDriverState *bs,
 BdrvChild *c;
 
 bdrv_ref(bs);
-if (job->job.aio_context != qemu_get_aio_context()) {
+if (bdrv_get_aio_context(bs) != job->job.aio_context &&
+job->job.aio_context != qemu_get_aio_context()) {
 aio_context_release(job->job.aio_context);
 }
 c = bdrv_root_attach_child(bs, name, _job, 0,
job->job.aio_context, perm, shared_perm, job,
errp);
-if (job->job.aio_context != qemu_get_aio_context()) {
+if (bdrv_get_aio_context(bs) != job->job.aio_context &&
+job->job.aio_context != qemu_get_aio_context()) {
 aio_context_acquire(job->job.aio_context);
 }
 if (c == NULL) {
--
2.22.0




[PATCH 2/6] m68k: cascade m68k_features by m680xx_cpu_initfn() to improve readability

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

The m680XX_cpu_initfn functions have been rearranged to cascade starting from
the base 68000, so that the 68010 then inherits from this, and so on until the
68060.

This makes it simpler to track features since in most cases the m68k were
product enhancements on each other, with only a few instructions being retired.

Because each cpu class inherits the previous CPU class, then for example
the 68020 also has the feature 68010, and 68000 and so on upto the 68060.

- Added 68010 cpu class, and moved correct features into 68000/68010.
- Added m68k_unset_feature to allow removing a feature in the inheritence

Signed-off-by: Lucien Murray-Pitts 
Reviewed-by: Laurent Vivier 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/cpu.c | 72 +--
 target/m68k/cpu.h |  1 +
 2 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index ccf1c490c0..5e7aec5b13 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -41,6 +41,11 @@ static void m68k_set_feature(CPUM68KState *env, int feature)
 env->features |= (1u << feature);
 }
 
+static void m68k_unset_feature(CPUM68KState *env, int feature)
+{
+env->features &= (-1u - (1u << feature));
+}
+
 static void m68k_cpu_reset(DeviceState *dev)
 {
 CPUState *s = CPU(dev);
@@ -115,25 +120,18 @@ static void m68000_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_MOVEP);
 }
 
-/* common features for 68020, 68030 and 68040 */
-static void m680x0_cpu_common(CPUM68KState *env)
+/*
+ * Adds BKPT, MOVE-from-SR *now priv instr, and MOVEC, MOVES, RTD
+ */
+static void m68010_cpu_initfn(Object *obj)
 {
-m68k_set_feature(env, M68K_FEATURE_M68000);
-m68k_set_feature(env, M68K_FEATURE_USP);
-m68k_set_feature(env, M68K_FEATURE_WORD_INDEX);
-m68k_set_feature(env, M68K_FEATURE_QUAD_MULDIV);
-m68k_set_feature(env, M68K_FEATURE_BRAL);
-m68k_set_feature(env, M68K_FEATURE_BCCL);
-m68k_set_feature(env, M68K_FEATURE_BITFIELD);
-m68k_set_feature(env, M68K_FEATURE_EXT_FULL);
-m68k_set_feature(env, M68K_FEATURE_SCALED_INDEX);
-m68k_set_feature(env, M68K_FEATURE_LONG_MULDIV);
-m68k_set_feature(env, M68K_FEATURE_FPU);
-m68k_set_feature(env, M68K_FEATURE_CAS);
-m68k_set_feature(env, M68K_FEATURE_BKPT);
+M68kCPU *cpu = M68K_CPU(obj);
+CPUM68KState *env = >env;
+
+m68000_cpu_initfn(obj);
+m68k_set_feature(env, M68K_FEATURE_M68010);
 m68k_set_feature(env, M68K_FEATURE_RTD);
-m68k_set_feature(env, M68K_FEATURE_CHK2);
-m68k_set_feature(env, M68K_FEATURE_MOVEP);
+m68k_set_feature(env, M68K_FEATURE_BKPT);
 }
 
 /*
@@ -148,8 +146,19 @@ static void m68020_cpu_initfn(Object *obj)
 M68kCPU *cpu = M68K_CPU(obj);
 CPUM68KState *env = >env;
 
-m680x0_cpu_common(env);
+m68010_cpu_initfn(obj);
+m68k_unset_feature(env, M68K_FEATURE_M68010);
 m68k_set_feature(env, M68K_FEATURE_M68020);
+m68k_set_feature(env, M68K_FEATURE_QUAD_MULDIV);
+m68k_set_feature(env, M68K_FEATURE_BRAL);
+m68k_set_feature(env, M68K_FEATURE_BCCL);
+m68k_set_feature(env, M68K_FEATURE_BITFIELD);
+m68k_set_feature(env, M68K_FEATURE_EXT_FULL);
+m68k_set_feature(env, M68K_FEATURE_SCALED_INDEX);
+m68k_set_feature(env, M68K_FEATURE_LONG_MULDIV);
+m68k_set_feature(env, M68K_FEATURE_FPU);
+m68k_set_feature(env, M68K_FEATURE_CAS);
+m68k_set_feature(env, M68K_FEATURE_CHK2);
 }
 
 /*
@@ -165,7 +174,8 @@ static void m68030_cpu_initfn(Object *obj)
 M68kCPU *cpu = M68K_CPU(obj);
 CPUM68KState *env = >env;
 
-m680x0_cpu_common(env);
+m68020_cpu_initfn(obj);
+m68k_unset_feature(env, M68K_FEATURE_M68020);
 m68k_set_feature(env, M68K_FEATURE_M68030);
 }
 
@@ -191,7 +201,8 @@ static void m68040_cpu_initfn(Object *obj)
 M68kCPU *cpu = M68K_CPU(obj);
 CPUM68KState *env = >env;
 
-m680x0_cpu_common(env);
+m68030_cpu_initfn(obj);
+m68k_unset_feature(env, M68K_FEATURE_M68030);
 m68k_set_feature(env, M68K_FEATURE_M68040);
 }
 
@@ -211,21 +222,13 @@ static void m68060_cpu_initfn(Object *obj)
 M68kCPU *cpu = M68K_CPU(obj);
 CPUM68KState *env = >env;
 
-m68k_set_feature(env, M68K_FEATURE_M68000);
-m68k_set_feature(env, M68K_FEATURE_USP);
-m68k_set_feature(env, M68K_FEATURE_WORD_INDEX);
-m68k_set_feature(env, M68K_FEATURE_BRAL);
-m68k_set_feature(env, M68K_FEATURE_BCCL);
-m68k_set_feature(env, M68K_FEATURE_BITFIELD);
-m68k_set_feature(env, M68K_FEATURE_EXT_FULL);
-m68k_set_feature(env, M68K_FEATURE_SCALED_INDEX);
-m68k_set_feature(env, M68K_FEATURE_LONG_MULDIV);
-m68k_set_feature(env, M68K_FEATURE_FPU);
-m68k_set_feature(env, M68K_FEATURE_CAS);
-m68k_set_feature(env, M68K_FEATURE_BKPT);
-m68k_set_feature(env, M68K_FEATURE_RTD);
-m68k_set_feature(env, M68K_FEATURE_CHK2);
+m68040_cpu_initfn(obj);
+m68k_unset_feature(env, M68K_FEATURE_M68040);
 m68k_set_feature(env, 

[PATCH 6/6] m68k: add MSP detection support for stack pointer swap helpers

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

On m68k there are two varities of stack pointers: USP with SSP or ISP/MSP.

Only the 68020/30/40 support the MSP register the stack swap helpers don't
support this feature.

This patch adds this support, as well as comments to CPUM68KState to
make it clear how stacks are handled

Signed-off-by: Lucien Murray-Pitts 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/cpu.c| 1 +
 target/m68k/cpu.h| 9 -
 target/m68k/helper.c | 3 ++-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 31f96df2a2..5586589301 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -160,6 +160,7 @@ static void m68020_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_FPU);
 m68k_set_feature(env, M68K_FEATURE_CAS);
 m68k_set_feature(env, M68K_FEATURE_CHK2);
+m68k_set_feature(env, M68K_FEATURE_MSP);
 }
 
 /*
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 5d2cb012e5..7c3feeaf8a 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -85,7 +85,13 @@ typedef struct CPUM68KState {
 uint32_t pc;
 uint32_t sr;
 
-/* SSP and USP.  The current_sp is stored in aregs[7], the other here.  */
+/*
+ * The 68020/30/40 support two supervisor stacks, ISP and MSP.
+ * The 68000/10, Coldfire, and CPU32 only have USP/SSP.
+ *
+ * The current_sp is stored in aregs[7], the other here.
+ * The USP, SSP, and if used the additional ISP for 68020/30/40.
+ */
 int current_sp;
 uint32_t sp[3];
 
@@ -484,6 +490,7 @@ enum m68k_features {
 M68K_FEATURE_CF_EMAC,
 M68K_FEATURE_CF_EMAC_B,   /* Revision B EMAC (dual accumulate). */
 M68K_FEATURE_USP, /* User Stack Pointer. (680[012346]0, ISA A+, B or C).*/
+M68K_FEATURE_MSP, /* Master Stack Pointer. (680[234]0) */
 M68K_FEATURE_EXT_FULL,/* 68020+ full extension word. */
 M68K_FEATURE_WORD_INDEX,  /* word sized address index registers. */
 M68K_FEATURE_SCALED_INDEX, /* scaled address index registers. */
diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index 1efd6e4f65..4185ca94ce 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -463,7 +463,8 @@ void m68k_switch_sp(CPUM68KState *env)
 env->sp[env->current_sp] = env->aregs[7];
 if (m68k_feature(env, M68K_FEATURE_M68000)) {
 if (env->sr & SR_S) {
-if (env->sr & SR_M) {
+/* SR:Master-Mode bit unimplemented then ISP is not available */
+if (!m68k_feature(env, M68K_FEATURE_MSP) || env->sr & SR_M) {
 new_sp = M68K_SSP;
 } else {
 new_sp = M68K_ISP;
-- 
2.21.3




[PATCH 5/6] m68k: MOVEC insn. should generate exception if wrong CR is accessed

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

Add CPU class detection for each CR type in the m68k_move_to/from helpers,
so that it throws and exception if an unsupported register is requested
for that CPU class.

Reclassified MOVEC insn. as only supported from 68010.

Signed-off-by: Lucien Murray-Pitts 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/cpu.c   |   1 +
 target/m68k/cpu.h   |   1 +
 target/m68k/helper.c| 188 ++--
 target/m68k/translate.c |   2 +-
 4 files changed, 146 insertions(+), 46 deletions(-)

diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 5e7aec5b13..31f96df2a2 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -132,6 +132,7 @@ static void m68010_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_M68010);
 m68k_set_feature(env, M68K_FEATURE_RTD);
 m68k_set_feature(env, M68K_FEATURE_BKPT);
+m68k_set_feature(env, M68K_FEATURE_MOVEC);
 }
 
 /*
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index ae34c94615..5d2cb012e5 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -497,6 +497,7 @@ enum m68k_features {
 M68K_FEATURE_RTD,   /* RTD insn. (680[12346]0, and CPU32) */
 M68K_FEATURE_CHK2,  /* CHK2 insn. (680[2346]0, and CPU32) */
 M68K_FEATURE_MOVEP, /* MOVEP insn. (680[01234]0, and CPU32) */
+M68K_FEATURE_MOVEC, /* MOVEC insn. (from 68010) */
 };
 
 static inline int m68k_feature(CPUM68KState *env, int feature)
diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index 69acdc3b35..1efd6e4f65 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -184,6 +184,14 @@ void HELPER(cf_movec_to)(CPUM68KState *env, uint32_t reg, 
uint32_t val)
 }
 }
 
+static void raise_exception_ra(CPUM68KState *env, int tt, uintptr_t raddr)
+{
+CPUState *cs = env_cpu(env);
+
+cs->exception_index = tt;
+cpu_loop_exit_restore(cs, raddr);
+}
+
 void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t reg, uint32_t val)
 {
 switch (reg) {
@@ -209,61 +217,104 @@ void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t 
reg, uint32_t val)
 env->cacr = val & 0x80008000;
 } else if (m68k_feature(env, M68K_FEATURE_M68060)) {
 env->cacr = val & 0xf8e0e000;
+} else {
+break;
 }
 m68k_switch_sp(env);
 return;
 /* MC680[46]0 */
 case M68K_CR_TC:
-env->mmu.tcr = val;
-return;
+if (m68k_feature(env, M68K_FEATURE_M68040)
+ || m68k_feature(env, M68K_FEATURE_M68060)) {
+env->mmu.tcr = val;
+return;
+}
+break;
 /* MC68040 */
 case M68K_CR_MMUSR:
-env->mmu.mmusr = val;
-return;
+if (m68k_feature(env, M68K_FEATURE_M68040)) {
+env->mmu.mmusr = val;
+return;
+}
+break;
 /* MC680[46]0 */
 case M68K_CR_SRP:
-env->mmu.srp = val;
-return;
-case M68K_CR_URP:
-env->mmu.urp = val;
-return;
+if (m68k_feature(env, M68K_FEATURE_M68040)
+ || m68k_feature(env, M68K_FEATURE_M68060)) {
+env->mmu.srp = val;
+return;
+}
+break;
 /* MC680[46]0 */
+case M68K_CR_URP:
+if (m68k_feature(env, M68K_FEATURE_M68040)
+ || m68k_feature(env, M68K_FEATURE_M68060)) {
+env->mmu.urp = val;
+return;
+}
+break;
+/* MC680[12346]0 */
 case M68K_CR_USP:
 env->sp[M68K_USP] = val;
 return;
 /* MC680[234]0 */
 case M68K_CR_MSP:
-env->sp[M68K_SSP] = val;
-return;
+if (m68k_feature(env, M68K_FEATURE_M68020)
+ || m68k_feature(env, M68K_FEATURE_M68030)
+ || m68k_feature(env, M68K_FEATURE_M68040)) {
+env->sp[M68K_SSP] = val;
+return;
+}
+break;
 /* MC680[234]0 */
 case M68K_CR_ISP:
-env->sp[M68K_ISP] = val;
-return;
+if (m68k_feature(env, M68K_FEATURE_M68020)
+ || m68k_feature(env, M68K_FEATURE_M68030)
+ || m68k_feature(env, M68K_FEATURE_M68040)) {
+env->sp[M68K_ISP] = val;
+return;
+}
+break;
 /* MC68040/MC68LC040 */
-case M68K_CR_ITT0:
-env->mmu.ttr[M68K_ITTR0] = val;
-return;
+case M68K_CR_ITT0: /* MC68EC040 only: M68K_CR_IACR0 */
+if (m68k_feature(env, M68K_FEATURE_M68040)) {
+env->mmu.ttr[M68K_ITTR0] = val;
+return;
+}
+break;
 /* MC68040/MC68LC040 */
-case M68K_CR_ITT1:
- env->mmu.ttr[M68K_ITTR1] = val;
-return;
+case M68K_CR_ITT1: /* MC68EC040 only: M68K_CR_IACR1 */
+if (m68k_feature(env, M68K_FEATURE_M68040)) {
+env->mmu.ttr[M68K_ITTR1] = val;
+return;
+}
+break;
 /* MC68040/MC68LC040 */
-case M68K_CR_DTT0:
-env->mmu.ttr[M68K_DTTR0] = val;
-return;
+case M68K_CR_DTT0: /* MC68EC040 only: 

[PATCH 4/6] m68k: add missing BUSCR/PCR CR defines, and BUSCR/PCR/CAAR CR to m68k_move_to/from

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

The BUSCR/PCR CR defines were missing for 68060, and the move_to/from helper
functions were also missing a decode for the 68060 M68K_CR_CAAR CR register.

Added missing defines, and respective decodes for all three CR registers to
the helpers.

Although this patch defines them, the implementation is empty in this patch
and these registers will result in a cpu abort - which is the default prior
to this patch.

This patch aims to reach full coverage of all CR registers within the helpers.

Signed-off-by: Lucien Murray-Pitts 
Reviewed-by: Laurent Vivier 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/cpu.h|  4 
 target/m68k/helper.c | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 2b1cdf241b..ae34c94615 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -393,6 +393,10 @@ typedef enum {
 #define M68K_CR_DACR00x006
 #define M68K_CR_DACR10x007
 
+/* MC68060 */
+#define M68K_CR_BUSCR0x008
+#define M68K_CR_PCR  0x808
+
 #define M68K_FPIAR_SHIFT  0
 #define M68K_FPIAR(1 << M68K_FPIAR_SHIFT)
 #define M68K_FPSR_SHIFT   1
diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index 9e81ee53ad..69acdc3b35 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -255,6 +255,11 @@ void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t 
reg, uint32_t val)
 case M68K_CR_DTT1:
 env->mmu.ttr[M68K_DTTR1] = val;
 return;
+/* Unimplemented Registers */
+case M68K_CR_CAAR:
+case M68K_CR_PCR:
+case M68K_CR_BUSCR:
+break;
 }
 cpu_abort(env_cpu(env),
   "Unimplemented control register write 0x%x = 0x%x\n",
@@ -309,6 +314,11 @@ uint32_t HELPER(m68k_movec_from)(CPUM68KState *env, 
uint32_t reg)
 /* MC68040/MC68LC040 */
 case M68K_CR_DTT1: /* MC68EC040 only: M68K_CR_DACR1 */
 return env->mmu.ttr[M68K_DTTR1];
+/* Unimplemented Registers */
+case M68K_CR_CAAR:
+case M68K_CR_PCR:
+case M68K_CR_BUSCR:
+break;
 }
 cpu_abort(env_cpu(env), "Unimplemented control register read 0x%x\n",
   reg);
-- 
2.21.3




[PATCH 1/6] m68k: improve cpu instantiation comments

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

Improvement in comments for the instantiation functions.
This is to highlight what each cpu class, in the 68000 series, contains
in terms of instructions/features.

Signed-off-by: Lucien Murray-Pitts 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/cpu.c | 44 ++
 target/m68k/cpu.h | 49 ---
 2 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index b811a0bdde..ccf1c490c0 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -103,6 +103,7 @@ static void m5206_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_CF_ISA_A);
 }
 
+/* Base feature set, including isns. for m68k family */
 static void m68000_cpu_initfn(Object *obj)
 {
 M68kCPU *cpu = M68K_CPU(obj);
@@ -135,6 +136,13 @@ static void m680x0_cpu_common(CPUM68KState *env)
 m68k_set_feature(env, M68K_FEATURE_MOVEP);
 }
 
+/*
+ * Adds BFCHG, BFCLR, BFEXTS, BFEXTU, BFFFO, BFINS, BFSET, BFTST, CAS, CAS2,
+ *  CHK2, CMP2, DIVSL, DIVUL, EXTB, PACK, TRAPcc, UNPK.
+ *
+ * 68020/30 only:
+ *  CALLM, cpBcc, cpDBcc, cpGEN, cpRESTORE, cpSAVE, cpScc, cpTRAPcc
+ */
 static void m68020_cpu_initfn(Object *obj)
 {
 M68kCPU *cpu = M68K_CPU(obj);
@@ -144,6 +152,14 @@ static void m68020_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_M68020);
 }
 
+/*
+ * Adds: PFLUSH (*5)
+ * 68030 Only: PFLUSHA (*5), PLOAD (*5), PMOVE
+ * 68030/40 Only: PTEST
+ *
+ * NOTES:
+ *  5. Not valid on MC68EC030
+ */
 static void m68030_cpu_initfn(Object *obj)
 {
 M68kCPU *cpu = M68K_CPU(obj);
@@ -153,6 +169,23 @@ static void m68030_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_M68030);
 }
 
+/*
+ * Adds: CINV, CPUSH
+ * Adds all with Note *2: FABS, FSABS, FDABS, FADD, FSADD, FDADD, FBcc, FCMP,
+ *FDBcc, FDIV, FSDIV, FDDIV, FMOVE, FSMOVE, FDMOVE,
+ *FMOVEM, FMUL, FSMUL, FDMUL, FNEG, FSNEG, FDNEG, FNOP,
+ *FRESTORE, FSAVE, FScc, FSQRT, FSSQRT, FDSQRT, FSUB,
+ *FSSUB, FDSUB, FTRAPcc, FTST
+ *
+ * Adds with Notes *2, and *3: FACOS, FASIN, FATAN, FATANH, FCOS, FCOSH, FETOX,
+ * FETOXM, FGETEXP, FGETMAN, FINT, FINTRZ, FLOG10,
+ * FLOG2, FLOGN, FLOGNP1, FMOD, FMOVECR, FREM,
+ * FSCALE, FSGLDIV, FSGLMUL, FSIN, FSINCOS, FSINH,
+ * FTAN, FTANH, FTENTOX, FTWOTOX
+ * NOTES:
+ * 2. Not applicable to the MC68EC040, MC68LC040, MC68EC060, and MC68LC060.
+ * 3. These are software-supported instructions on the MC68040 and MC68060.
+ */
 static void m68040_cpu_initfn(Object *obj)
 {
 M68kCPU *cpu = M68K_CPU(obj);
@@ -162,6 +195,17 @@ static void m68040_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_M68040);
 }
 
+/*
+ * Adds: PLPA
+ * Adds all with Note *2: CAS, CAS2, MULS, MULU, CHK2, CMP2, DIVS, DIVU
+ * All F instructions are as per m68040 with exception to; FMOVEM NOTE3
+ *
+ * Does NOT implement MOVEP
+ *
+ * NOTES:
+ * 2. Not applicable to the MC68EC040, MC68LC040, MC68EC060, and MC68LC060.
+ * 3. These are software-supported instructions on the MC68040 and MC68060.
+ */
 static void m68060_cpu_initfn(Object *obj)
 {
 M68kCPU *cpu = M68K_CPU(obj);
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index de5b9875fe..1d59cbb3f4 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -450,39 +450,48 @@ void m68k_switch_sp(CPUM68KState *env);
 void do_m68k_semihosting(CPUM68KState *env, int nr);
 
 /*
+ * The 68000 family is defined in six main CPU classes, the 680[012346]0.
+ * Generally each successive CPU adds enhanced data/stack/instructions.
+ * However, some features are only common to one, or a few classes.
+ * The features covers those subsets of instructons.
+ *
+ * CPU32/32+ are basically 680010 compatible with some 68020 class instructons,
+ * and some additional CPU32 instructions. Mostly Supervisor state differences.
+ *
+ * The ColdFire core ISA is a RISC-style reduction of the 68000 series cpu.
  * There are 4 ColdFire core ISA revisions: A, A+, B and C.
  * Each feature covers the subset of instructions common to the
  * ISA revisions mentioned.
  */
 
 enum m68k_features {
-M68K_FEATURE_M68000,
+M68K_FEATURE_M68000,   /* Base m68k instruction set */
 M68K_FEATURE_M68020,
 M68K_FEATURE_M68030,
 M68K_FEATURE_M68040,
 M68K_FEATURE_M68060,
-M68K_FEATURE_CF_ISA_A,
-M68K_FEATURE_CF_ISA_B, /* (ISA B or C).  */
-M68K_FEATURE_CF_ISA_APLUSC, /* BIT/BITREV, FF1, STRLDSR (ISA A+ or C).  */
-M68K_FEATURE_BRAL, /* Long unconditional branch.  (ISA A+ or B).  */
+M68K_FEATURE_CF_ISA_A, /* Base Coldfire set Rev A. */
+M68K_FEATURE_CF_ISA_B, /* (ISA B or C). */
+M68K_FEATURE_CF_ISA_APLUSC, /* BIT/BITREV, FF1, STRLDSR (ISA A+ or C). */
+M68K_FEATURE_BRAL, /* BRA with Long branch. 

[PATCH 3/6] m68k: improve comments on m68k_move_to/from helpers

2021-01-31 Thread BALATON Zoltan
From: Lucien Murray-Pitts 

Add more detailed comments to each case of m68k_move_to/from helpers to list
the supported CPUs for that CR as they were wrong in some cases, and
missing some cpu classes in other cases.

Signed-off-by: Lucien Murray-Pitts 
Signed-off-by: BALATON Zoltan 
---
 target/m68k/helper.c | 39 ++-
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/target/m68k/helper.c b/target/m68k/helper.c
index 3ff5765795..9e81ee53ad 100644
--- a/target/m68k/helper.c
+++ b/target/m68k/helper.c
@@ -187,13 +187,15 @@ void HELPER(cf_movec_to)(CPUM68KState *env, uint32_t reg, 
uint32_t val)
 void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t reg, uint32_t val)
 {
 switch (reg) {
-/* MC680[1234]0 */
+/* MC680[12346]0 */
 case M68K_CR_SFC:
 env->sfc = val & 7;
 return;
+/* MC680[12346]0 */
 case M68K_CR_DFC:
 env->dfc = val & 7;
 return;
+/* MC680[12346]0 */
 case M68K_CR_VBR:
 env->vbr = val;
 return;
@@ -210,25 +212,30 @@ void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t 
reg, uint32_t val)
 }
 m68k_switch_sp(env);
 return;
-/* MC680[34]0 */
+/* MC680[46]0 */
 case M68K_CR_TC:
 env->mmu.tcr = val;
 return;
+/* MC68040 */
 case M68K_CR_MMUSR:
 env->mmu.mmusr = val;
 return;
+/* MC680[46]0 */
 case M68K_CR_SRP:
 env->mmu.srp = val;
 return;
 case M68K_CR_URP:
 env->mmu.urp = val;
 return;
+/* MC680[46]0 */
 case M68K_CR_USP:
 env->sp[M68K_USP] = val;
 return;
+/* MC680[234]0 */
 case M68K_CR_MSP:
 env->sp[M68K_SSP] = val;
 return;
+/* MC680[234]0 */
 case M68K_CR_ISP:
 env->sp[M68K_ISP] = val;
 return;
@@ -236,12 +243,15 @@ void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t 
reg, uint32_t val)
 case M68K_CR_ITT0:
 env->mmu.ttr[M68K_ITTR0] = val;
 return;
+/* MC68040/MC68LC040 */
 case M68K_CR_ITT1:
  env->mmu.ttr[M68K_ITTR1] = val;
 return;
+/* MC68040/MC68LC040 */
 case M68K_CR_DTT0:
 env->mmu.ttr[M68K_DTTR0] = val;
 return;
+/* MC68040/MC68LC040 */
 case M68K_CR_DTT1:
 env->mmu.ttr[M68K_DTTR1] = val;
 return;
@@ -254,39 +264,50 @@ void HELPER(m68k_movec_to)(CPUM68KState *env, uint32_t 
reg, uint32_t val)
 uint32_t HELPER(m68k_movec_from)(CPUM68KState *env, uint32_t reg)
 {
 switch (reg) {
-/* MC680[1234]0 */
+/* MC680[12346]0 */
 case M68K_CR_SFC:
 return env->sfc;
+/* MC680[12346]0 */
 case M68K_CR_DFC:
 return env->dfc;
+/* MC680[12346]0 */
 case M68K_CR_VBR:
 return env->vbr;
-/* MC680[234]0 */
+/* MC680[2346]0 */
 case M68K_CR_CACR:
 return env->cacr;
-/* MC680[34]0 */
+/* MC680[46]0 */
 case M68K_CR_TC:
 return env->mmu.tcr;
+/* MC68040 */
 case M68K_CR_MMUSR:
 return env->mmu.mmusr;
+/* MC680[46]0 */
 case M68K_CR_SRP:
 return env->mmu.srp;
+/* MC680[46]0 */
 case M68K_CR_USP:
 return env->sp[M68K_USP];
+/* MC680[234]0 */
 case M68K_CR_MSP:
 return env->sp[M68K_SSP];
+/* MC680[234]0 */
 case M68K_CR_ISP:
 return env->sp[M68K_ISP];
 /* MC68040/MC68LC040 */
 case M68K_CR_URP:
 return env->mmu.urp;
-case M68K_CR_ITT0:
+/* MC68040/MC68LC040 */
+case M68K_CR_ITT0: /* MC68EC040 only: M68K_CR_IACR0 */
 return env->mmu.ttr[M68K_ITTR0];
-case M68K_CR_ITT1:
+/* MC68040/MC68LC040 */
+case M68K_CR_ITT1: /* MC68EC040 only: M68K_CR_IACR1 */
 return env->mmu.ttr[M68K_ITTR1];
-case M68K_CR_DTT0:
+/* MC68040/MC68LC040 */
+case M68K_CR_DTT0: /* MC68EC040 only: M68K_CR_DACR0 */
 return env->mmu.ttr[M68K_DTTR0];
-case M68K_CR_DTT1:
+/* MC68040/MC68LC040 */
+case M68K_CR_DTT1: /* MC68EC040 only: M68K_CR_DACR1 */
 return env->mmu.ttr[M68K_DTTR1];
 }
 cpu_abort(env_cpu(env), "Unimplemented control register read 0x%x\n",
-- 
2.21.3




[PATCH 0/6] m68k: Overhaul of MOVEC instruction to support exception/MSP

2021-01-31 Thread BALATON Zoltan
Hello,

This is Lucien's m68k series rebased on and fixed up to work with
current master as per previous discussion:
https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg02840.html

I've left previous Reviewed-by tags for reference but these should
probably be reviewed again. I've only lightly tested it so I don't
know if everything is correct but it does seem to fix the problem my
original patch tried to fix at least. More testing, review and help to
finish this so it can be merged at last is welcome.

Regards,
BALATON Zoltan

Lucien Murray-Pitts (6):
  m68k: improve cpu instantiation comments
  m68k: cascade m68k_features by m680xx_cpu_initfn() to improve
readability
  m68k: improve comments on m68k_move_to/from helpers
  m68k: add missing BUSCR/PCR CR defines, and BUSCR/PCR/CAAR CR to
m68k_move_to/from
  m68k: MOVEC insn. should generate exception if wrong CR is accessed
  m68k: add MSP detection support for stack pointer swap helpers

 target/m68k/cpu.c   | 116 ++--
 target/m68k/cpu.h   |  64 +++
 target/m68k/helper.c| 234 +++-
 target/m68k/translate.c |   2 +-
 4 files changed, 309 insertions(+), 107 deletions(-)

-- 
2.21.3




Re: [PATCH 4/7] ppc/pnv: Simplify pnv_bmc_create()

2021-01-31 Thread Andrew Jeffery



On Fri, 29 Jan 2021, at 19:09, Cédric Le Goater wrote:
> On 1/28/21 11:40 PM, David Gibson wrote:
> > On Thu, Jan 28, 2021 at 08:46:01AM +0100, Cédric Le Goater wrote:
> >> On 1/28/21 1:46 AM, Joel Stanley wrote:
> >>> On Tue, 26 Jan 2021 at 17:14, Cédric Le Goater  wrote:
> 
>  and reuse pnv_bmc_set_pnor() to share the setting of the PNOR.
> 
>  Signed-off-by: Cédric Le Goater 
>  ---
>   hw/ppc/pnv_bmc.c | 7 +--
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
>  diff --git a/hw/ppc/pnv_bmc.c b/hw/ppc/pnv_bmc.c
>  index 67ebb16c4d5f..86d16b493539 100644
>  --- a/hw/ppc/pnv_bmc.c
>  +++ b/hw/ppc/pnv_bmc.c
>  @@ -260,13 +260,8 @@ IPMIBmc *pnv_bmc_create(PnvPnor *pnor)
>   Object *obj;
> 
>   obj = object_new(TYPE_IPMI_BMC_SIMULATOR);
>  -object_ref(OBJECT(pnor));
>  -object_property_add_const_link(obj, "pnor", OBJECT(pnor));
> >>>
> >>> I assume it's ok to move the link set to after the realise of the BMC 
> >>> object?
> >>  
> >>
> >> When 2 objects need to be linked, one has to be realized first. 
> >> I suppose this is why it is allowed but I am not expert in that area. 
> >>
> >> Greg  ?
> >>
> >> That was the case already when defining a "ipmi-bmc-sim" device on the 
> >> command line.
> > 
> > Well, the other thing here is that the IPMI_BMC_SIMULATOR isn't a
> > POWER specific object, and doesn't actually know anything about pnor,
> > so it never looks at that property.  Do we even need it?
> 
> It does through hiomap_cmd() which handles HIOMAP commands related 
> to the PNOR. The link was introduced to remove a reference to the 
> global machine (qdev_get_machine()). The PNOR device is instantiated 
> at the machine level but conceptually, this is incorrect. 
> 
> The PNOR is a device controlled by the BMC and accessed by the host 
> through a mapping on the LPC FW address space. It used to be controlled 
> from the host also, through the iLPC2AHB device and mboxes, but these 
> "doors" were closed sometime ago.

Right, so rehashing what Cédric said about the context for the PNOR and IPMI:

On PowerNV platforms, the host firmware accesses the data in the PNOR by 
sending commands over IPMI to the BMC to change the mappings in the LPC FW 
space. HIOMAP (Host I/O Map)[1] is the name of the little spec/protocol that 
defines the layout of data in the FW space and the commands and ABI for 
manipulating the mappings.

[1] https://github.com/openbmc/hiomapd/blob/master/Documentation/protocol.md

It's all terrible, but IPMI was the most well-trodden path I had at my disposal 
for improving the security of the (Aspeed) BMCs' hardware configuration for 
Power platform designs. From BMC reset the host has unrestricted access to the 
BMC's AHB via bridges on the LPC and PCIe buses until the BMC firmware disables 
them. Leaving the bridges enabled is not great for security or stability of the 
BMC firmware, so this meant cooking up some magic to allow the host to write 
back to the PNOR (owned by the BMC as Cédric mentions above) without exposing 
the BMC in unacceptable ways.

Andrew



Re: [QUESTION] tcg: Is concurrent storing and code translation of the same code page considered as racing in MTTCG?

2021-01-31 Thread Richard Henderson
On 1/31/21 1:38 AM, Liren Wei wrote:
> However, similar to the situation described in:
> https://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg02529.html
> 
> When we have 2 vCPUs with one of them writing to the code page while
> the other just translated some code within that same page, the following
> situation might happen:
> 
>    vCPU thread 1 - writing  vCPU thread 2 - translating
>    ---  ---
>    TLB check -> slow path
>  notdirty_write()
>    set dirty flag
>  write to RAM
>     tb_gen_code()
>   tb_page_add()
>     tlb_protect_code()
> 
>    TLB check -> fast path
>   set TLB_NOTDIRTY
>  write to RAM
> executing unmodified code for this time
>     and maybe also for the next time, never
>                                 re-translate modified TBs.
> 
> 
> My question is:
>   Should the situation described above be considered as a bug or,
>   an intended behavior for QEMU (, so it's the programmer's fault
>   for not flushing the icache after modifying shared code page)?

Yes, this is a bug, because we are trying to support e.g. x86 which does not
require an icache flush.

I think the page lock, the TLB_NOTDIRTY setting, and a possible sync on the
setting, needs to happen before the bytes are read during translation.
Otherwise we don't catch the case above, nor do we catch

CPU1CPU2
--  --
TLB check -> fast
tb_gen_code() -> all of it
  write to ram

Also because of x86 (and other architectures in which a single instruction can
span a page boundary), I think this lock+set+sync sequence needs to happen on
demand in something called from the function set defined in
include/exec/translator.h

That also means that any target/cpu/ which has not been converted to use that
interface remains broken, and should be converted or deprecated.

Are you planning to work on this?


r~



[Bug 1913969] [NEW] unable to migrate non shared storage when TLS is used

2021-01-31 Thread Vjaceslavs Klimovs
Public bug reported:

Operating system: Gentoo
Architecture: x86_64
kernel version: 5.4.72, 5.10.11
libvirt version: at least 6.9.0, 6.10.0, 7.0.0
Hypervisor and version: qemu 5.1.0, 5.2.0

With software versions described above and following configurations:
libvirt:
key_file = "/etc/ssl/libvirt/server.lan.key"
cert_file = "/etc/ssl/libvirt/server.lan.crt"
ca_file = "/etc/ssl/libvirt/ca.crt"
log_filters="3:remote 4:event 3:util.json 3:rpc 1:*"
log_outputs="1:file:/var/log/libvirt/libvirtd.log"
qemu:
default_tls_x509_cert_dir = "/etc/ssl/qemu"
default_tls_x509_verify = 1
migration with tls:
virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource 
--copy-storage-all --verbose --tls
never succeeds. Progress stops typically at high progress amounts (95%-98%), 
and network traffic drastically drops as well (from 1 gbps+ to nothing). 
domjobinfo progress also stops. Without --tls migrations succeed without issues 
without any other changes to hosts or configurations.

Note: I reported this originally as libvirt bug:
https://gitlab.com/libvirt/libvirt/-/issues/108.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  unable to migrate non shared storage when TLS is used

Status in QEMU:
  New

Bug description:
  Operating system: Gentoo
  Architecture: x86_64
  kernel version: 5.4.72, 5.10.11
  libvirt version: at least 6.9.0, 6.10.0, 7.0.0
  Hypervisor and version: qemu 5.1.0, 5.2.0

  With software versions described above and following configurations:
  libvirt:
  key_file = "/etc/ssl/libvirt/server.lan.key"
  cert_file = "/etc/ssl/libvirt/server.lan.crt"
  ca_file = "/etc/ssl/libvirt/ca.crt"
  log_filters="3:remote 4:event 3:util.json 3:rpc 1:*"
  log_outputs="1:file:/var/log/libvirt/libvirtd.log"
  qemu:
  default_tls_x509_cert_dir = "/etc/ssl/qemu"
  default_tls_x509_verify = 1
  migration with tls:
  virsh # migrate vm1 qemu+tls://server2.lan/system --persistent 
--undefinesource --copy-storage-all --verbose --tls
  never succeeds. Progress stops typically at high progress amounts (95%-98%), 
and network traffic drastically drops as well (from 1 gbps+ to nothing). 
domjobinfo progress also stops. Without --tls migrations succeed without issues 
without any other changes to hosts or configurations.

  Note: I reported this originally as libvirt bug:
  https://gitlab.com/libvirt/libvirt/-/issues/108.

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



Re: [PATCH v3 6/6] hw/arm: Display CPU type in machine description

2021-01-31 Thread Niek Linnenbank
For Orange Pi PC:

Reviewed-by: Niek Linnenbank 

Op zo 31 jan. 2021 19:45 schreef Philippe Mathieu-Daudé :

> Most of ARM machines display their CPU when QEMU list the available
> machines (-M help). Some machines do not. Fix to unify the help
> output.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/arm/digic_boards.c  | 2 +-
>  hw/arm/microbit.c  | 2 +-
>  hw/arm/netduino2.c | 2 +-
>  hw/arm/netduinoplus2.c | 2 +-
>  hw/arm/orangepi.c  | 2 +-
>  hw/arm/stellaris.c | 4 ++--
>  6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c
> index be12873673b..6cdc1d83fca 100644
> --- a/hw/arm/digic_boards.c
> +++ b/hw/arm/digic_boards.c
> @@ -142,7 +142,7 @@ static void canon_a1100_init(MachineState *machine)
>
>  static void canon_a1100_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Canon PowerShot A1100 IS";
> +mc->desc = "Canon PowerShot A1100 IS (ARM946)";
>  mc->init = _a1100_init;
>  mc->ignore_memory_transaction_failures = true;
>  mc->default_ram_size = 64 * MiB;
> diff --git a/hw/arm/microbit.c b/hw/arm/microbit.c
> index 0947491cb97..e9494334ce7 100644
> --- a/hw/arm/microbit.c
> +++ b/hw/arm/microbit.c
> @@ -64,7 +64,7 @@ static void microbit_machine_class_init(ObjectClass *oc,
> void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
>
> -mc->desc = "BBC micro:bit";
> +mc->desc = "BBC micro:bit (Cortex-M0)";
>  mc->init = microbit_init;
>  mc->max_cpus = 1;
>  }
> diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
> index 8f103341443..1733b71507c 100644
> --- a/hw/arm/netduino2.c
> +++ b/hw/arm/netduino2.c
> @@ -54,7 +54,7 @@ static void netduino2_init(MachineState *machine)
>
>  static void netduino2_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Netduino 2 Machine";
> +mc->desc = "Netduino 2 Machine (Cortex-M3)";
>  mc->init = netduino2_init;
>  mc->ignore_memory_transaction_failures = true;
>  }
> diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c
> index 68abd3ec69d..d3ad7a2b675 100644
> --- a/hw/arm/netduinoplus2.c
> +++ b/hw/arm/netduinoplus2.c
> @@ -55,7 +55,7 @@ static void netduinoplus2_init(MachineState *machine)
>
>  static void netduinoplus2_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Netduino Plus 2 Machine";
> +mc->desc = "Netduino Plus 2 Machine (Cortex-M4)";
>  mc->init = netduinoplus2_init;
>  }
>
> diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c
> index d6306dfddae..40cdb5c6d2c 100644
> --- a/hw/arm/orangepi.c
> +++ b/hw/arm/orangepi.c
> @@ -113,7 +113,7 @@ static void orangepi_init(MachineState *machine)
>
>  static void orangepi_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Orange Pi PC";
> +mc->desc = "Orange Pi PC (Cortex-A7)";
>  mc->init = orangepi_init;
>  mc->block_default_type = IF_SD;
>  mc->units_per_default_bus = 1;
> diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
> index ad72c0959f1..27292ec4113 100644
> --- a/hw/arm/stellaris.c
> +++ b/hw/arm/stellaris.c
> @@ -1538,7 +1538,7 @@ static void lm3s811evb_class_init(ObjectClass *oc,
> void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
>
> -mc->desc = "Stellaris LM3S811EVB";
> +mc->desc = "Stellaris LM3S811EVB (Cortex-M3)";
>  mc->init = lm3s811evb_init;
>  mc->ignore_memory_transaction_failures = true;
>  mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
> @@ -1554,7 +1554,7 @@ static void lm3s6965evb_class_init(ObjectClass *oc,
> void *data)
>  {
>  MachineClass *mc = MACHINE_CLASS(oc);
>
> -mc->desc = "Stellaris LM3S6965EVB";
> +mc->desc = "Stellaris LM3S6965EVB (Cortex-M3)";
>  mc->init = lm3s6965evb_init;
>  mc->ignore_memory_transaction_failures = true;
>  mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
> --
> 2.26.2
>
>


Re: [PATCH v3 13/24] tcg/sparc: Split out target constraints to tcg-target-con-str.h

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/29/21 9:10 PM, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 
> ---
>  tcg/sparc/tcg-target-con-str.h | 23 ++
>  tcg/sparc/tcg-target.h |  5 +--
>  tcg/sparc/tcg-target.c.inc | 81 +-
>  3 files changed, 55 insertions(+), 54 deletions(-)
>  create mode 100644 tcg/sparc/tcg-target-con-str.h

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH] simpletrace: build() missing 2 required positional arguments

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 6:34 PM, Volker Rümelin wrote:
> Commit 4e66c9ef64 "tracetool: add input filename and line number to
> Event" forgot to add a line number and a filename argument at one
> build method call site.
> 
> Traceback (most recent call last):
>   File "./scripts/simpletrace.py", line 261, in 
> run(Formatter())
>   File "./scripts/simpletrace.py", line 236, in run
> process(events, sys.argv[2], analyzer, read_header=read_header)
>   File "./scripts/simpletrace.py", line 177, in process
> dropped_event =
>   Event.build("Dropped_Event(uint64_t num_events_dropped)")
> TypeError: build() missing 2 required positional arguments:
>   'lineno' and 'filename'

Oops

Reviewed-by: Philippe Mathieu-Daudé 

> 
> Add the missing arguments.
> 
> Signed-off-by: Volker Rümelin 
> ---
>  scripts/simpletrace.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/simpletrace.py b/scripts/simpletrace.py
> index 20f0026066..d61fb0bd87 100755
> --- a/scripts/simpletrace.py
> +++ b/scripts/simpletrace.py
> @@ -174,7 +174,9 @@ def process(events, log, analyzer, read_header=True):
>  if read_header:
>  read_trace_header(log)
>  
> -dropped_event = Event.build("Dropped_Event(uint64_t num_events_dropped)")
> +frameinfo = inspect.getframeinfo(inspect.currentframe())
> +dropped_event = Event.build("Dropped_Event(uint64_t num_events_dropped)",
> +frameinfo.lineno + 1, frameinfo.filename)
>  edict = {"dropped": dropped_event}
>  idtoname = {dropped_event_id: "dropped"}
>  
> 




[Bug 1913913] Re: i386-linux-user returns -1 in sigcontext->trapno

2021-01-31 Thread Dirk A Niggemann
I have identified the core issue:

Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a 
return value from cpu_exec().
cpu_exec() resets exception_index to -1 in  cpu_handle_exception()

This means that queue_signal() (called from gen_signal() in the cpu
loop) does not store the actual  CPU trap value anywhere.

If we abuse env->exception_nr to store the trapnr, and retrieve it from
there in setup_sigcontext() in linux-user/i386/signal.c instead of using
exception_index (which will be set to -1 for all synchronous excptions).

The main issue is if this breaks asynchronous signals, and under what
conditions exception_nr should be set to -1.

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

Title:
  i386-linux-user returns -1 in sigcontext->trapno

Status in QEMU:
  New

Bug description:
  QEMU development version, git commit
  74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in
  5.2.0 generally.

  Certain 16-bit windows programs crash WINE under QEMU linux-user with:

  0084:err:seh:segv_handler Got unexpected trap -1
  wine: Unhandled illegal instruction at address 6D65 (thread 0084), 
starting debugger...

  They run correctly on native i386.

  Upon further inspection,it becomes clear these programs are failing at
  addresses where they are making DOS calls (int 21h ie CD 21 for
  instance).

  It is also clear that WINE is expecting an exception/signal at this
  point, to patch in the actual int21h handling code inside WINE.

  However, wine uses sigcontext output extensively to do its structured
  exception handling. sigcontext->trapno being set to -1 seems to
  confuse it, causing it to treat the exception as an actual unhandled
  error.

  I do not know if exception_index is being left at -1 due to the case
  of privileged instructions being executed in 16-bit ldts not being
  handled specifically, or if there is some other illegal instruction
  case causing this.

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



Re: [PATCH v2 1/4] meson: Do not build Xen x86_64-softmmu on Aarch64

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 3:45 PM, andrew.cooper3--- via wrote:
> On 31/01/2021 14:18, Philippe Mathieu-Daudé wrote:
>> The Xen on ARM documentation only mentions the i386-softmmu
>> target. As the x86_64-softmmu doesn't seem used, remove it
>> to avoid wasting cpu cycles building it.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
> 
> As far as I understand, it only gets used at all on ARM for the
> blkback=>qcow path, and has nothing to do with I440FX or other boards. 
> i.e. it is a paravirt disk and nothing else.

Yeah the PIIX3 part is messy, this is easier to select I440FX which
provides all the required dependencies. TBH I'd rather invest my
time in other tasks, and the Xen folks don't seem interested in getting
this improved. I only did that series to reply to Paolo and pass over
to Alex Bennée.

> xenpv should not be tied to i386-softmmu in the first place, and would
> remove a very-WTF-worthy current state of things.  That said, I have no
> idea how much effort that might be.

Here the problem isn't much Xen but the rest of x86 machines in QEMU.

Regards,

Phil.



[PATCH v3 6/6] hw/arm: Display CPU type in machine description

2021-01-31 Thread Philippe Mathieu-Daudé
Most of ARM machines display their CPU when QEMU list the available
machines (-M help). Some machines do not. Fix to unify the help
output.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/digic_boards.c  | 2 +-
 hw/arm/microbit.c  | 2 +-
 hw/arm/netduino2.c | 2 +-
 hw/arm/netduinoplus2.c | 2 +-
 hw/arm/orangepi.c  | 2 +-
 hw/arm/stellaris.c | 4 ++--
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c
index be12873673b..6cdc1d83fca 100644
--- a/hw/arm/digic_boards.c
+++ b/hw/arm/digic_boards.c
@@ -142,7 +142,7 @@ static void canon_a1100_init(MachineState *machine)
 
 static void canon_a1100_machine_init(MachineClass *mc)
 {
-mc->desc = "Canon PowerShot A1100 IS";
+mc->desc = "Canon PowerShot A1100 IS (ARM946)";
 mc->init = _a1100_init;
 mc->ignore_memory_transaction_failures = true;
 mc->default_ram_size = 64 * MiB;
diff --git a/hw/arm/microbit.c b/hw/arm/microbit.c
index 0947491cb97..e9494334ce7 100644
--- a/hw/arm/microbit.c
+++ b/hw/arm/microbit.c
@@ -64,7 +64,7 @@ static void microbit_machine_class_init(ObjectClass *oc, void 
*data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
 
-mc->desc = "BBC micro:bit";
+mc->desc = "BBC micro:bit (Cortex-M0)";
 mc->init = microbit_init;
 mc->max_cpus = 1;
 }
diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
index 8f103341443..1733b71507c 100644
--- a/hw/arm/netduino2.c
+++ b/hw/arm/netduino2.c
@@ -54,7 +54,7 @@ static void netduino2_init(MachineState *machine)
 
 static void netduino2_machine_init(MachineClass *mc)
 {
-mc->desc = "Netduino 2 Machine";
+mc->desc = "Netduino 2 Machine (Cortex-M3)";
 mc->init = netduino2_init;
 mc->ignore_memory_transaction_failures = true;
 }
diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c
index 68abd3ec69d..d3ad7a2b675 100644
--- a/hw/arm/netduinoplus2.c
+++ b/hw/arm/netduinoplus2.c
@@ -55,7 +55,7 @@ static void netduinoplus2_init(MachineState *machine)
 
 static void netduinoplus2_machine_init(MachineClass *mc)
 {
-mc->desc = "Netduino Plus 2 Machine";
+mc->desc = "Netduino Plus 2 Machine (Cortex-M4)";
 mc->init = netduinoplus2_init;
 }
 
diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c
index d6306dfddae..40cdb5c6d2c 100644
--- a/hw/arm/orangepi.c
+++ b/hw/arm/orangepi.c
@@ -113,7 +113,7 @@ static void orangepi_init(MachineState *machine)
 
 static void orangepi_machine_init(MachineClass *mc)
 {
-mc->desc = "Orange Pi PC";
+mc->desc = "Orange Pi PC (Cortex-A7)";
 mc->init = orangepi_init;
 mc->block_default_type = IF_SD;
 mc->units_per_default_bus = 1;
diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
index ad72c0959f1..27292ec4113 100644
--- a/hw/arm/stellaris.c
+++ b/hw/arm/stellaris.c
@@ -1538,7 +1538,7 @@ static void lm3s811evb_class_init(ObjectClass *oc, void 
*data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
 
-mc->desc = "Stellaris LM3S811EVB";
+mc->desc = "Stellaris LM3S811EVB (Cortex-M3)";
 mc->init = lm3s811evb_init;
 mc->ignore_memory_transaction_failures = true;
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
@@ -1554,7 +1554,7 @@ static void lm3s6965evb_class_init(ObjectClass *oc, void 
*data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
 
-mc->desc = "Stellaris LM3S6965EVB";
+mc->desc = "Stellaris LM3S6965EVB (Cortex-M3)";
 mc->init = lm3s6965evb_init;
 mc->ignore_memory_transaction_failures = true;
 mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
-- 
2.26.2




[PATCH v3 4/6] hw/arm/xlnx-versal: Versal SoC requires ZynqMP peripherals

2021-01-31 Thread Philippe Mathieu-Daudé
The Versal SoC instantiates the TYPE_XLNX_ZYNQMP_RTC object in
versal_create_rtc()(). Select CONFIG_XLNX_ZYNQMP to fix:

  $ make check-qtest-aarch64
  ...
  Running test qtest-aarch64/qom-test
  qemu-system-aarch64: missing object type 'xlnx-zynmp.rtc'
  Broken pipe

Signed-off-by: Philippe Mathieu-Daudé 
---
Cc: Alistair Francis 
Cc: "Edgar E. Iglesias" 
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 09298881f2f..be017b997ab 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -364,6 +364,7 @@ config XLNX_VERSAL
 select VIRTIO_MMIO
 select UNIMP
 select XLNX_ZDMA
+select XLNX_ZYNQMP
 
 config NPCM7XX
 bool
-- 
2.26.2




[PATCH v3 5/6] hw/net/can: ZynqMP CAN device requires PTIMER

2021-01-31 Thread Philippe Mathieu-Daudé
Add a dependency XLNX_ZYNQMP -> PTIMER to fix:

  /usr/bin/ld:
  libcommon.fa.p/hw_net_can_xlnx-zynqmp-can.c.o: in function 
`xlnx_zynqmp_can_realize':
  hw/net/can/xlnx-zynqmp-can.c:1082: undefined reference to `ptimer_init'
  hw/net/can/xlnx-zynqmp-can.c:1085: undefined reference to 
`ptimer_transaction_begin'
  hw/net/can/xlnx-zynqmp-can.c:1087: undefined reference to `ptimer_set_freq'
  hw/net/can/xlnx-zynqmp-can.c:1088: undefined reference to `ptimer_set_limit'
  hw/net/can/xlnx-zynqmp-can.c:1089: undefined reference to `ptimer_run'
  hw/net/can/xlnx-zynqmp-can.c:1090: undefined reference to 
`ptimer_transaction_commit'
  libcommon.fa.p/hw_net_can_xlnx-zynqmp-can.c.o:(.data.rel+0x2c8): undefined 
reference to `vmstate_ptimer'

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/Kconfig b/hw/Kconfig
index 5ad3c6b5a4b..d4cec9e476c 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -81,3 +81,4 @@ config XLNX_ZYNQMP
 bool
 select REGISTER
 select CAN_BUS
+select PTIMER
-- 
2.26.2




[PATCH v3 3/6] hw/arm/xlnx-versal: Versal SoC requires ZDMA

2021-01-31 Thread Philippe Mathieu-Daudé
The Versal SoC instantiates the TYPE_XLNX_ZDMA object in
versal_create_admas(). Introduce the XLNX_ZDMA configuration
and select it to fix:

  $ qemu-system-aarch64 -M xlnx-versal-virt ...
  qemu-system-aarch64: missing object type 'xlnx.zdma'

Signed-off-by: Philippe Mathieu-Daudé 
---
Cc: Alistair Francis 
Cc: "Edgar E. Iglesias" 
---
 hw/arm/Kconfig | 2 ++
 hw/dma/Kconfig | 3 +++
 hw/dma/meson.build | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 223016bb4e8..09298881f2f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -354,6 +354,7 @@ config XLNX_ZYNQMP_ARM
 select XILINX_AXI
 select XILINX_SPIPS
 select XLNX_ZYNQMP
+select XLNX_ZDMA
 
 config XLNX_VERSAL
 bool
@@ -362,6 +363,7 @@ config XLNX_VERSAL
 select CADENCE
 select VIRTIO_MMIO
 select UNIMP
+select XLNX_ZDMA
 
 config NPCM7XX
 bool
diff --git a/hw/dma/Kconfig b/hw/dma/Kconfig
index d67492d36c1..5d6be1a7a7a 100644
--- a/hw/dma/Kconfig
+++ b/hw/dma/Kconfig
@@ -18,6 +18,9 @@ config ZYNQ_DEVCFG
 bool
 select REGISTER
 
+config XLNX_ZDMA
+bool
+
 config STP2000
 bool
 
diff --git a/hw/dma/meson.build b/hw/dma/meson.build
index b991d7698c7..47b4a7cb47b 100644
--- a/hw/dma/meson.build
+++ b/hw/dma/meson.build
@@ -9,7 +9,7 @@
 softmmu_ss.add(when: 'CONFIG_ETRAXFS', if_true: files('etraxfs_dma.c'))
 softmmu_ss.add(when: 'CONFIG_STP2000', if_true: files('sparc32_dma.c'))
 softmmu_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx_dpdma.c'))
-softmmu_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zdma.c'))
+softmmu_ss.add(when: 'CONFIG_XLNX_ZDMA', if_true: files('xlnx-zdma.c'))
 softmmu_ss.add(when: 'CONFIG_OMAP', if_true: files('omap_dma.c', 'soc_dma.c'))
 softmmu_ss.add(when: 'CONFIG_PXA2XX', if_true: files('pxa2xx_dma.c'))
 softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_dma.c'))
-- 
2.26.2




[PATCH v3 1/6] hw/arm/stm32f405_soc: Add missing dependency on OR_IRQ

2021-01-31 Thread Philippe Mathieu-Daudé
The STM32F405 SoC uses an OR gate on its ADC IRQs.

Fixes: 529fc5fd3e1 ("hw/arm: Add the STM32F4xx SoC")
Signed-off-by: Philippe Mathieu-Daudé 
---
Cc: alist...@alistair23.me
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 13cc42dcc84..a320a124855 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -336,6 +336,7 @@ config STM32F205_SOC
 config STM32F405_SOC
 bool
 select ARM_V7M
+select OR_IRQ
 select STM32F4XX_SYSCFG
 select STM32F4XX_EXTI
 
-- 
2.26.2




[PATCH v3 2/6] hw/arm/exynos4210: Add missing dependency on OR_IRQ

2021-01-31 Thread Philippe Mathieu-Daudé
The Exynos4210 SoC uses an OR gate on the PL330 IRQ lines.

Fixes: dab15fbe2ab ("hw/arm/exynos4210: Fix DMA initialization")
Signed-off-by: Philippe Mathieu-Daudé 
---
Cc: Igor Mitsyanko 
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index a320a124855..223016bb4e8 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -52,6 +52,7 @@ config EXYNOS4
 select PTIMER
 select SDHCI
 select USB_EHCI_SYSBUS
+select OR_IRQ
 
 config HIGHBANK
 bool
-- 
2.26.2




[PATCH v3 0/6] hw/arm: Misc trivial fixes/cleanups

2021-01-31 Thread Philippe Mathieu-Daudé
Trivial bugfixes and cleanup patches noticed while rebasing
my "Support disabling TCG on ARM (part 2)" series.

Since v2:
- removed incorrect patches added in v2 =)
- more fixes for Versal board (CAN, RTC)

Since v1:
- added patches to remove 64-bit specific features on 32-bit build.

Philippe Mathieu-Daudé (6):
  hw/arm/stm32f405_soc: Add missing dependency on OR_IRQ
  hw/arm/exynos4210: Add missing dependency on OR_IRQ
  hw/arm/xlnx-versal: Versal SoC requires ZDMA
  hw/arm/xlnx-versal: Versal SoC requires ZynqMP peripherals
  hw/net/can: ZynqMP CAN device requires PTIMER
  hw/arm: Display CPU type in machine description

 hw/arm/digic_boards.c  | 2 +-
 hw/arm/microbit.c  | 2 +-
 hw/arm/netduino2.c | 2 +-
 hw/arm/netduinoplus2.c | 2 +-
 hw/arm/orangepi.c  | 2 +-
 hw/arm/stellaris.c | 4 ++--
 hw/Kconfig | 1 +
 hw/arm/Kconfig | 5 +
 hw/dma/Kconfig | 3 +++
 hw/dma/meson.build | 2 +-
 10 files changed, 17 insertions(+), 8 deletions(-)

-- 
2.26.2




Re: [PATCH 2/5] hw/arm: Restrict ARMv7 A-profile cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 5:44 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> The following machines are no more built when TCG is disabled:
> 
>   - cubieboard   cubietech cubieboard (Cortex-A8)
>   - mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex A7)
>   - mcimx7d-sabreFreescale i.MX7 DUAL SABRE (Cortex A7)
>   - npcm750-evb  Nuvoton NPCM750 Evaluation Board (Cortex A9)
>   - nuri Samsung NURI board (Exynos4210)
>   - orangepi-pc  Orange Pi PC (Cortex-A7)
>   - quanta-gsj   Quanta GSJ (Cortex A9)
>   - realview-pb-a8   ARM RealView Platform Baseboard for Cortex-A8
>   - realview-pbx-a9  ARM RealView Platform Baseboard Explore for Cortex-A9
>   - sabreliteFreescale i.MX6 Quad SABRE Lite Board (Cortex A9)
>   - smdkc210 Samsung SMDKC210 board (Exynos4210)
>   - vexpress-a15 ARM Versatile Express for Cortex-A15
>   - vexpress-a9  ARM Versatile Express for Cortex-A9
>   - xilinx-zynq-a9   Xilinx Zynq Platform Baseboard for Cortex-A9
> 
> Reported-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/arm-softmmu.mak | 10 --
>  hw/arm/Kconfig  | 11 +++
>  2 files changed, 11 insertions(+), 10 deletions(-)
...

>  
>  config REALVIEW
>  bool
> +default y if TCG && ARM
>  imply PCI_DEVICES
>  imply PCI_TESTDEV
>  select SMC91C111
> @@ -241,6 +244,7 @@ config SBSA_REF
>  
>  config SABRELITE
>  bool
> +default y if TCG && ARM
>  select FSL_IMX6
>  select SSI_M25P80
>  
> @@ -292,6 +296,7 @@ config VERSATILE
>  
>  config VEXPRESS
>  bool
> +default y if TCG && ARM
>  select A9MPCORE
>  select A15MPCORE
>  select ARM_MPTIMER
> @@ -307,6 +312,7 @@ config VEXPRESS
>  
>  config ZYNQ
>  bool
> +default y if TCG && ARM
>  select A9MPCORE
>  select CADENCE # UART
>  select PFLASH_CFI02

Missing:
-- >8 --
diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
index cb0409c5a11..c1746284ee2 100644
--- a/tests/qtest/cdrom-test.c
+++ b/tests/qtest/cdrom-test.c
@@ -225,10 +225,11 @@ int main(int argc, char **argv)
 #ifdef CONFIG_TCG
 "realview-eb",
 "realview-eb-mpcore",
-#endif /* CONFIG_TCG */
 "realview-pb-a8",
 "realview-pbx-a9", "versatileab", "versatilepb",
"vexpress-a15",
-"vexpress-a9", "virt", NULL
+"vexpress-a9",
+#endif /* CONFIG_TCG */
+"virt", NULL
 };
 add_cdrom_param_tests(armmachines);
 } else {
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index c83bc211b6a..d8ebd5bf98e 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -159,10 +159,10 @@
   (cpu != 'arm' ? ['bios-tables-test'] : []) +
 \
   (config_all_devices.has_key('CONFIG_TPM_TIS_SYSBUS') ?
['tpm-tis-device-test'] : []) +\
   (config_all_devices.has_key('CONFIG_TPM_TIS_SYSBUS') ?
['tpm-tis-device-swtpm-test'] : []) +  \
+  (config_all.has_key('CONFIG_TCG') ? ['xlnx-can-test'] : []) +  \
   ['arm-cpu-features',
'numa-test',
'boot-serial-test',
-   'xlnx-can-test',
'migration-test']

 qtests_s390x = \
---





9pfs developers docs

2021-01-31 Thread Christian Schoenebeck
Hi,

I started setting up some developer documentation for 9pfs:

https://wiki.qemu.org/Documentation/9p

Still quite a bunch that should be added (e.g. there should be a section about 
threads and coroutines), but at least it's a start ...

Best regards,
Christian Schoenebeck







[PATCH] simpletrace: build() missing 2 required positional arguments

2021-01-31 Thread Volker Rümelin
Commit 4e66c9ef64 "tracetool: add input filename and line number to
Event" forgot to add a line number and a filename argument at one
build method call site.

Traceback (most recent call last):
  File "./scripts/simpletrace.py", line 261, in 
run(Formatter())
  File "./scripts/simpletrace.py", line 236, in run
process(events, sys.argv[2], analyzer, read_header=read_header)
  File "./scripts/simpletrace.py", line 177, in process
dropped_event =
  Event.build("Dropped_Event(uint64_t num_events_dropped)")
TypeError: build() missing 2 required positional arguments:
  'lineno' and 'filename'

Add the missing arguments.

Signed-off-by: Volker Rümelin 
---
 scripts/simpletrace.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/simpletrace.py b/scripts/simpletrace.py
index 20f0026066..d61fb0bd87 100755
--- a/scripts/simpletrace.py
+++ b/scripts/simpletrace.py
@@ -174,7 +174,9 @@ def process(events, log, analyzer, read_header=True):
 if read_header:
 read_trace_header(log)
 
-dropped_event = Event.build("Dropped_Event(uint64_t num_events_dropped)")
+frameinfo = inspect.getframeinfo(inspect.currentframe())
+dropped_event = Event.build("Dropped_Event(uint64_t num_events_dropped)",
+frameinfo.lineno + 1, frameinfo.filename)
 edict = {"dropped": dropped_event}
 idtoname = {dropped_event_id: "dropped"}
 
-- 
2.26.2




Re: [PATCH 03/23] sdlaudio: add -audiodev sdl, out.buffer-count option

2021-01-31 Thread Volker Rümelin

   Hi,


-hw->samples = obt.samples;
+hw->samples = (spdo->has_buffer_count ? spdo->buffer_count : 4) *
+obt.samples;
+# @buffer-count: number of buffers (default 4)

Any specific reason for this default?

In my testing I've needed much higher values.
8 still got me crackling sound, 16 worked ok.


Hi Gerd,

this was an attempt to come up with SDL audio settings which work for 
all SDL audio drivers. Unfortunately, the different SDL audio drivers 
have different timings and there are no default settings that work for 
all of them. Here are two examples where buffer-count=4 works.


On my Linux system I use

export SDL_AUDIODRIVER=pulse
and start qemu with -device intel-hda -device hda-duplex,audiodev=audio0 
-machine pcspk-audiodev=audio0 -audiodev 
sdl,id=audio0,out.buffer-length=3750


Due to the mix-up of samples and frames in audio/sdlaudio.c the callback 
buffer has a size of 2 * 3.75ms = 7.5ms and SDL calls the callback 
function every 7.5ms. With out.buffer-count=4 that's a 4 * 7.5ms = 30ms 
buffer on the qemu side. This is larger than the minimum size of 
timer-period.


On Windows the timing is different. The time between SDL callback calls 
is a multiple of 10ms. I have to use


export SDL_AUDIODRIVER=directsound
and start qemu with -device intel-hda -device hda-duplex,audiodev=audio0 
-machine pcspk-audiodev=audio0 -audiodev 
sdl,id=audio0,timer-period=1000,out.buffer-length=5500


With the above settings the playback stream sometimes will see 2*10ms + 
1ms stalls. The qemu hda codec can barely handle this. On average it 
will drop playback data after 23.22ms.


With best regards,
Volker


take care,
   Gerd






Re: [PATCH] pc-bios/descriptors: fix paths in json files

2021-01-31 Thread Jannik Glückert
> Jannik, can you send a Signed-off-by line so we can accept
> your patch? See:
> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line

Sure! I hope this is right, I'm not exactly experienced with mailing
list development.

Signed-off-by: Jannik Glückert 
>
> Reviewed-by: Philippe Mathieu-Daudé 
>
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  pc-bios/descriptors/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/pc-bios/descriptors/meson.build 
> > b/pc-bios/descriptors/meson.build
> > index ac6ec66b00..29efa16d99 100644
> > --- a/pc-bios/descriptors/meson.build
> > +++ b/pc-bios/descriptors/meson.build
> > @@ -9,7 +9,7 @@ if install_edk2_blobs
> >]
> >  configure_file(input: files(f),
> > output: f,
> > -   configuration: {'DATADIR': qemu_datadir},
> > +   configuration: {'DATADIR': get_option('prefix') / 
> > qemu_datadir},
> > install: get_option('install_blobs'),
> > install_dir: qemu_datadir / 'firmware')
> >endforeach
> >


Am So., 31. Jan. 2021 um 15:56 Uhr schrieb Philippe Mathieu-Daudé
:
>
> On 1/31/21 3:34 PM, Sergei Trofimovich wrote:
> > Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
> > contained the relative path:
> > "filename": "share/qemu/edk2-x86_64-secure-code.fd",
> > "filename": "share/qemu/edk2-i386-vars.fd",
> >
> > After then change the paths are absolute:
> > "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
> > "filename": "/usr/share/qemu/edk2-i386-vars.fd",
> >
> > The regression appeared in qemu-5.2.0 (seems to be related
> > to meson port).
> >
> > CC: Paolo Bonzini 
> > CC: "Marc-André Lureau" 
> > CC: "Philippe Mathieu-Daudé" 
> > Bug: https://bugs.gentoo.org/766743
> > Bug: https://bugs.launchpad.net/qemu/+bug/1913012
> > Patch-by: Jannik Glückert
>
> Thanks Jannik and Sergei to fix this issue, I noticed
> the LP#1913012 and planned to look at it tomorrow :)
>
> Jannik, can you send a Signed-off-by line so we can accept
> your patch? See:
> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
>
> Otherwise:
> Reviewed-by: Philippe Mathieu-Daudé 
>
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  pc-bios/descriptors/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/pc-bios/descriptors/meson.build 
> > b/pc-bios/descriptors/meson.build
> > index ac6ec66b00..29efa16d99 100644
> > --- a/pc-bios/descriptors/meson.build
> > +++ b/pc-bios/descriptors/meson.build
> > @@ -9,7 +9,7 @@ if install_edk2_blobs
> >]
> >  configure_file(input: files(f),
> > output: f,
> > -   configuration: {'DATADIR': qemu_datadir},
> > +   configuration: {'DATADIR': get_option('prefix') / 
> > qemu_datadir},
> > install: get_option('install_blobs'),
> > install_dir: qemu_datadir / 'firmware')
> >endforeach
> >
>



Re: [PATCH 02/23] audio: fix bit-rotted code

2021-01-31 Thread Volker Rümelin

  #ifdef DEBUG
-alsa_dump_info(req, obt, obtfmt, pdo);
+alsa_dump_info(req, obt, obtfmt, apdo);
  #endif

"if (DEBUG) {  }" is a nice way to have this checked by the
compiler.  With "#define DEBUG 0" the compiler will optimize away
the dead code, so it isn't much different to #ifdef'ed code.


Hi,

I will amend this in my next patch series.

With best regards,
Volker


take care,
   Gerd





[PATCH 4/5] target/arm/cpu: Update coding style to make checkpatch.pl happy

2021-01-31 Thread Philippe Mathieu-Daudé
We will move this code in the next commit. Clean it up
first to avoid checkpatch.pl errors.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index d0853fae5ae..2d8312267f7 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1956,7 +1956,8 @@ static void cortex_a8_initfn(Object *obj)
 }
 
 static const ARMCPRegInfo cortexa9_cp_reginfo[] = {
-/* power_control should be set to maximum latency. Again,
+/*
+ * power_control should be set to maximum latency. Again,
  * default to 0 and set by private hook
  */
 { .name = "A9_PWRCTL", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 0,
@@ -1993,7 +1994,8 @@ static void cortex_a9_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_NEON);
 set_feature(>env, ARM_FEATURE_THUMB2EE);
 set_feature(>env, ARM_FEATURE_EL3);
-/* Note that A9 supports the MP extensions even for
+/*
+ * Note that A9 supports the MP extensions even for
  * A9UP and single-core A9MP (which are both different
  * and valid configurations; we don't model A9UP).
  */
@@ -2030,7 +2032,8 @@ static uint64_t a15_l2ctlr_read(CPUARMState *env, const 
ARMCPRegInfo *ri)
 {
 MachineState *ms = MACHINE(qdev_get_machine());
 
-/* Linux wants the number of processors from here.
+/*
+ * Linux wants the number of processors from here.
  * Might as well set the interrupt-controller bit too.
  */
 return ((ms->smp.cpus - 1) << 24) | (1 << 23);
@@ -2077,7 +2080,8 @@ static void cortex_a7_initfn(Object *obj)
 cpu->isar.id_mmfr1 = 0x4000;
 cpu->isar.id_mmfr2 = 0x0124;
 cpu->isar.id_mmfr3 = 0x02102211;
-/* a7_mpcore_r0p5_trm, page 4-4 gives 0x01101110; but
+/*
+ * a7_mpcore_r0p5_trm, page 4-4 gives 0x01101110; but
  * table 4-41 gives 0x02101110, which includes the arm div insns.
  */
 cpu->isar.id_isar0 = 0x02101110;
-- 
2.26.2




[PATCH 3/5] target/arm: Restrict v8M IDAU to TCG

2021-01-31 Thread Philippe Mathieu-Daudé
IDAU is specific to M-profile. KVM only supports A-profile.
Restrict this interface to TCG, as it is pointless (and
confusing) on a KVM-only build.

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 7 ---
 target/arm/cpu_tcg.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 40142ac141e..d0853fae5ae 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2352,12 +2352,6 @@ static const TypeInfo arm_cpu_type_info = {
 .class_init = arm_cpu_class_init,
 };
 
-static const TypeInfo idau_interface_type_info = {
-.name = TYPE_IDAU_INTERFACE,
-.parent = TYPE_INTERFACE,
-.class_size = sizeof(IDAUInterfaceClass),
-};
-
 static void arm_cpu_register_types(void)
 {
 const size_t cpu_count = ARRAY_SIZE(arm_cpus);
@@ -2371,7 +2365,6 @@ static void arm_cpu_register_types(void)
 if (cpu_count) {
 size_t i;
 
-type_register_static(_interface_type_info);
 for (i = 0; i < cpu_count; ++i) {
 arm_cpu_register(_cpus[i]);
 }
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 3e1c9b40353..bddfbf5e3a9 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -11,6 +11,7 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "internals.h"
+#include "target/arm/idau.h"
 
 /* CPU models. These are not needed for the AArch64 linux-user build. */
 #if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
@@ -719,10 +720,17 @@ static const ARMCPUInfo arm_tcg_cpus[] = {
 { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
 };
 
+static const TypeInfo idau_interface_type_info = {
+.name = TYPE_IDAU_INTERFACE,
+.parent = TYPE_INTERFACE,
+.class_size = sizeof(IDAUInterfaceClass),
+};
+
 static void arm_tcg_cpu_register_types(void)
 {
 size_t i;
 
+type_register_static(_interface_type_info);
 for (i = 0; i < ARRAY_SIZE(arm_tcg_cpus); ++i) {
 arm_cpu_register(_tcg_cpus[i]);
 }
-- 
2.26.2




[PATCH 5/5] target/arm: Restrict v7A TCG cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

A KVM-only build won't be able to run TCG cpus, move the
v7A CPU definitions to cpu_tcg.c.

Reported-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.c | 327 ---
 target/arm/cpu_tcg.c | 310 
 2 files changed, 310 insertions(+), 327 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 2d8312267f7..3f10614778b 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1906,323 +1906,6 @@ static ObjectClass *arm_cpu_class_by_name(const char 
*cpu_model)
 return oc;
 }
 
-/* CPU models. These are not needed for the AArch64 linux-user build. */
-#if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
-
-static const ARMCPRegInfo cortexa8_cp_reginfo[] = {
-{ .name = "L2LOCKDOWN", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 0,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-{ .name = "L2AUXCR", .cp = 15, .crn = 9, .crm = 0, .opc1 = 1, .opc2 = 2,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
-REGINFO_SENTINEL
-};
-
-static void cortex_a8_initfn(Object *obj)
-{
-ARMCPU *cpu = ARM_CPU(obj);
-
-cpu->dtb_compatible = "arm,cortex-a8";
-set_feature(>env, ARM_FEATURE_V7);
-set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
-set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
-set_feature(>env, ARM_FEATURE_EL3);
-cpu->midr = 0x410fc080;
-cpu->reset_fpsid = 0x410330c0;
-cpu->isar.mvfr0 = 0x0222;
-cpu->isar.mvfr1 = 0x0001;
-cpu->ctr = 0x82048004;
-cpu->reset_sctlr = 0x00c50078;
-cpu->isar.id_pfr0 = 0x1031;
-cpu->isar.id_pfr1 = 0x11;
-cpu->isar.id_dfr0 = 0x400;
-cpu->id_afr0 = 0;
-cpu->isar.id_mmfr0 = 0x3113;
-cpu->isar.id_mmfr1 = 0x2000;
-cpu->isar.id_mmfr2 = 0x01202000;
-cpu->isar.id_mmfr3 = 0x11;
-cpu->isar.id_isar0 = 0x0010;
-cpu->isar.id_isar1 = 0x12112111;
-cpu->isar.id_isar2 = 0x21232031;
-cpu->isar.id_isar3 = 0x2131;
-cpu->isar.id_isar4 = 0x0042;
-cpu->isar.dbgdidr = 0x15141000;
-cpu->clidr = (1 << 27) | (2 << 24) | 3;
-cpu->ccsidr[0] = 0xe007e01a; /* 16k L1 dcache. */
-cpu->ccsidr[1] = 0x2007e01a; /* 16k L1 icache. */
-cpu->ccsidr[2] = 0xf000; /* No L2 icache. */
-cpu->reset_auxcr = 2;
-define_arm_cp_regs(cpu, cortexa8_cp_reginfo);
-}
-
-static const ARMCPRegInfo cortexa9_cp_reginfo[] = {
-/*
- * power_control should be set to maximum latency. Again,
- * default to 0 and set by private hook
- */
-{ .name = "A9_PWRCTL", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 0,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_power_control) },
-{ .name = "A9_DIAG", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 1,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_diagnostic) },
-{ .name = "A9_PWRDIAG", .cp = 15, .crn = 15, .crm = 0, .opc1 = 0, .opc2 = 
2,
-  .access = PL1_RW, .resetvalue = 0,
-  .fieldoffset = offsetof(CPUARMState, cp15.c15_power_diagnostic) },
-{ .name = "NEONBUSY", .cp = 15, .crn = 15, .crm = 1, .opc1 = 0, .opc2 = 0,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-/* TLB lockdown control */
-{ .name = "TLB_LOCKR", .cp = 15, .crn = 15, .crm = 4, .opc1 = 5, .opc2 = 2,
-  .access = PL1_W, .resetvalue = 0, .type = ARM_CP_NOP },
-{ .name = "TLB_LOCKW", .cp = 15, .crn = 15, .crm = 4, .opc1 = 5, .opc2 = 4,
-  .access = PL1_W, .resetvalue = 0, .type = ARM_CP_NOP },
-{ .name = "TLB_VA", .cp = 15, .crn = 15, .crm = 5, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-{ .name = "TLB_PA", .cp = 15, .crn = 15, .crm = 6, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-{ .name = "TLB_ATTR", .cp = 15, .crn = 15, .crm = 7, .opc1 = 5, .opc2 = 2,
-  .access = PL1_RW, .resetvalue = 0, .type = ARM_CP_CONST },
-REGINFO_SENTINEL
-};
-
-static void cortex_a9_initfn(Object *obj)
-{
-ARMCPU *cpu = ARM_CPU(obj);
-
-cpu->dtb_compatible = "arm,cortex-a9";
-set_feature(>env, ARM_FEATURE_V7);
-set_feature(>env, ARM_FEATURE_NEON);
-set_feature(>env, ARM_FEATURE_THUMB2EE);
-set_feature(>env, ARM_FEATURE_EL3);
-/*
- * Note that A9 supports the MP extensions even for
- * A9UP and single-core A9MP (which are both different
- * and valid configurations; we don't model A9UP).
- */
-set_feature(>env, ARM_FEATURE_V7MP);
-set_feature(>env, ARM_FEATURE_CBAR);
-cpu->midr = 0x410fc090;
-cpu->reset_fpsid = 0x41033090;
-cpu->isar.mvfr0 = 0x0222;
-cpu->isar.mvfr1 = 

[PATCH 2/5] hw/arm: Restrict ARMv7 A-profile cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

The following machines are no more built when TCG is disabled:

  - cubieboard   cubietech cubieboard (Cortex-A8)
  - mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex A7)
  - mcimx7d-sabreFreescale i.MX7 DUAL SABRE (Cortex A7)
  - npcm750-evb  Nuvoton NPCM750 Evaluation Board (Cortex A9)
  - nuri Samsung NURI board (Exynos4210)
  - orangepi-pc  Orange Pi PC (Cortex-A7)
  - quanta-gsj   Quanta GSJ (Cortex A9)
  - realview-pb-a8   ARM RealView Platform Baseboard for Cortex-A8
  - realview-pbx-a9  ARM RealView Platform Baseboard Explore for Cortex-A9
  - sabreliteFreescale i.MX6 Quad SABRE Lite Board (Cortex A9)
  - smdkc210 Samsung SMDKC210 board (Exynos4210)
  - vexpress-a15 ARM Versatile Express for Cortex-A15
  - vexpress-a9  ARM Versatile Express for Cortex-A9
  - xilinx-zynq-a9   Xilinx Zynq Platform Baseboard for Cortex-A9

Reported-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/arm-softmmu.mak | 10 --
 hw/arm/Kconfig  | 11 +++
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 7d55c156bab..1ffa3dbe4bf 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -3,13 +3,3 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-CONFIG_CUBIEBOARD=y
-CONFIG_EXYNOS4=y
-CONFIG_REALVIEW=y
-CONFIG_VEXPRESS=y
-CONFIG_ZYNQ=y
-CONFIG_NPCM7XX=y
-CONFIG_SABRELITE=y
-CONFIG_FSL_IMX7=y
-CONFIG_FSL_IMX6UL=y
-CONFIG_ALLWINNER_H3=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 043710be3df..263f22a80c1 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -39,6 +39,7 @@ config CHEETAH
 
 config CUBIEBOARD
 bool
+default y if TCG && ARM
 select ALLWINNER_A10
 
 config DIGIC
@@ -50,6 +51,7 @@ config DIGIC
 
 config EXYNOS4
 bool
+default y if TCG && ARM
 select A9MPCORE
 select I2C
 select LAN9118
@@ -198,6 +200,7 @@ config Z2
 
 config REALVIEW
 bool
+default y if TCG && ARM
 imply PCI_DEVICES
 imply PCI_TESTDEV
 select SMC91C111
@@ -241,6 +244,7 @@ config SBSA_REF
 
 config SABRELITE
 bool
+default y if TCG && ARM
 select FSL_IMX6
 select SSI_M25P80
 
@@ -292,6 +296,7 @@ config VERSATILE
 
 config VEXPRESS
 bool
+default y if TCG && ARM
 select A9MPCORE
 select A15MPCORE
 select ARM_MPTIMER
@@ -307,6 +312,7 @@ config VEXPRESS
 
 config ZYNQ
 bool
+default y if TCG && ARM
 select A9MPCORE
 select CADENCE # UART
 select PFLASH_CFI02
@@ -331,6 +337,7 @@ config ALLWINNER_A10
 
 config ALLWINNER_H3
 bool
+default y if TCG && ARM
 select ALLWINNER_A10_PIT
 select ALLWINNER_SUN8I_EMAC
 select SERIAL
@@ -395,6 +402,7 @@ config XLNX_VERSAL
 
 config NPCM7XX
 bool
+default y if TCG && ARM
 select A9MPCORE
 select ARM_GIC
 select PL310  # cache controller
@@ -424,6 +432,7 @@ config FSL_IMX31
 
 config FSL_IMX6
 bool
+default y if TCG && ARM
 select A9MPCORE
 select IMX
 select IMX_FEC
@@ -467,6 +476,7 @@ config MPS2
 
 config FSL_IMX7
 bool
+default y if TCG && ARM
 imply PCI_DEVICES
 imply TEST_DEVICES
 select A15MPCORE
@@ -484,6 +494,7 @@ config ARM_SMMUV3
 
 config FSL_IMX6UL
 bool
+default y if TCG && ARM
 select A15MPCORE
 select IMX
 select IMX_FEC
-- 
2.26.2




[PATCH 1/5] hw/arm: Use Kconfig 'default y' syntax instead of default-configs

2021-01-31 Thread Philippe Mathieu-Daudé
Machines can be automatically selected using the Kconfig
'default y' syntax. This change allow deselecting these
machines without having to modify default-configs/ files.

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/aarch64-softmmu.mak | 3 ---
 default-configs/devices/arm-softmmu.mak | 2 --
 hw/arm/Kconfig  | 4 
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/default-configs/devices/aarch64-softmmu.mak 
b/default-configs/devices/aarch64-softmmu.mak
index a4202f56817..a94c7786919 100644
--- a/default-configs/devices/aarch64-softmmu.mak
+++ b/default-configs/devices/aarch64-softmmu.mak
@@ -2,6 +2,3 @@
 
 # We support all the 32 bit boards so need all their config
 include arm-softmmu.mak
-
-CONFIG_XLNX_VERSAL=y
-CONFIG_SBSA_REF=y
diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0fc80d7d6df..7d55c156bab 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -3,14 +3,12 @@
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
-CONFIG_ARM_VIRT=y
 CONFIG_CUBIEBOARD=y
 CONFIG_EXYNOS4=y
 CONFIG_REALVIEW=y
 CONFIG_VEXPRESS=y
 CONFIG_ZYNQ=y
 CONFIG_NPCM7XX=y
-CONFIG_RASPI=y
 CONFIG_SABRELITE=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 768830cc28c..043710be3df 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -1,5 +1,6 @@
 config ARM_VIRT
 bool
+default y if ARM
 imply PCI_DEVICES
 imply TEST_DEVICES
 imply VFIO_AMD_XGBE
@@ -224,6 +225,7 @@ config REALVIEW
 
 config SBSA_REF
 bool
+default y if AARCH64
 imply PCI_DEVICES
 select AHCI
 select ARM_SMMUV3
@@ -341,6 +343,7 @@ config ALLWINNER_H3
 
 config RASPI
 bool
+default y if ARM
 select FRAMEBUFFER
 select PL011 # UART
 select SDHCI
@@ -382,6 +385,7 @@ config XLNX_ZYNQMP_ARM
 
 config XLNX_VERSAL
 bool
+default y if AARCH64
 select ARM_GIC
 select PL011
 select CADENCE
-- 
2.26.2




[PATCH 0/5] target/arm: Restrict v7A TCG cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture.

Restrict the last ARMv7 CPUs (A-profile) to TCG.

(This is where I realize no need to split the v7 A/R/M profiles
anymore... I could have use a single ARM_V7, although it is useful
to have the M-profile separated).

Based-on: <20210131115022.242570-1-f4...@amsat.org>

Philippe Mathieu-Daudé (5):
  hw/arm: Use Kconfig 'default y' syntax instead of default-configs
  hw/arm: Restrict ARMv7 A-profile cpus to TCG accel
  target/arm: Restrict v8M IDAU to TCG
  target/arm/cpu: Update coding style to make checkpatch.pl happy
  target/arm: Restrict v7A TCG cpus to TCG accel

 default-configs/devices/aarch64-softmmu.mak |   3 -
 default-configs/devices/arm-softmmu.mak |  12 -
 target/arm/cpu.c| 330 
 target/arm/cpu_tcg.c| 318 +++
 hw/arm/Kconfig  |  15 +
 5 files changed, 333 insertions(+), 345 deletions(-)

-- 
2.26.2




Re: [PATCH] pc-bios/descriptors: fix paths in json files

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 4:22 PM, Jannik Glückert wrote:
>> Jannik, can you send a Signed-off-by line so we can accept
>> your patch? See:
>> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
> 
> Sure! I hope this is right, I'm not exactly experienced with mailing
> list development.
> 
> Signed-off-by: Jannik Glückert 

Yes, perfect :)

>>
>> Reviewed-by: Philippe Mathieu-Daudé 
>>
>>> Signed-off-by: Sergei Trofimovich 
>>> ---
>>>  pc-bios/descriptors/meson.build | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/pc-bios/descriptors/meson.build 
>>> b/pc-bios/descriptors/meson.build
>>> index ac6ec66b00..29efa16d99 100644
>>> --- a/pc-bios/descriptors/meson.build
>>> +++ b/pc-bios/descriptors/meson.build
>>> @@ -9,7 +9,7 @@ if install_edk2_blobs
>>>]
>>>  configure_file(input: files(f),
>>> output: f,
>>> -   configuration: {'DATADIR': qemu_datadir},
>>> +   configuration: {'DATADIR': get_option('prefix') / 
>>> qemu_datadir},
>>> install: get_option('install_blobs'),
>>> install_dir: qemu_datadir / 'firmware')
>>>endforeach
>>>
> 
> 
> Am So., 31. Jan. 2021 um 15:56 Uhr schrieb Philippe Mathieu-Daudé
> :
>>
>> On 1/31/21 3:34 PM, Sergei Trofimovich wrote:
>>> Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
>>> contained the relative path:
>>> "filename": "share/qemu/edk2-x86_64-secure-code.fd",
>>> "filename": "share/qemu/edk2-i386-vars.fd",
>>>
>>> After then change the paths are absolute:
>>> "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
>>> "filename": "/usr/share/qemu/edk2-i386-vars.fd",
>>>
>>> The regression appeared in qemu-5.2.0 (seems to be related
>>> to meson port).

Cc: qemu-sta...@nongnu.org

Cc'ing qemu-trivial@ now (I can respin with all tags sorted
if it is easier).

>>> CC: Paolo Bonzini 
>>> CC: "Marc-André Lureau" 
>>> CC: "Philippe Mathieu-Daudé" 
>>> Bug: https://bugs.gentoo.org/766743
>>> Bug: https://bugs.launchpad.net/qemu/+bug/1913012
>>> Patch-by: Jannik Glückert
>>
>> Thanks Jannik and Sergei to fix this issue, I noticed
>> the LP#1913012 and planned to look at it tomorrow :)
>>
>> Jannik, can you send a Signed-off-by line so we can accept
>> your patch? See:
>> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
>>
>> Otherwise:
>> Reviewed-by: Philippe Mathieu-Daudé 
>>
>>> Signed-off-by: Sergei Trofimovich 
>>> ---
>>>  pc-bios/descriptors/meson.build | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/pc-bios/descriptors/meson.build 
>>> b/pc-bios/descriptors/meson.build
>>> index ac6ec66b00..29efa16d99 100644
>>> --- a/pc-bios/descriptors/meson.build
>>> +++ b/pc-bios/descriptors/meson.build
>>> @@ -9,7 +9,7 @@ if install_edk2_blobs
>>>]
>>>  configure_file(input: files(f),
>>> output: f,
>>> -   configuration: {'DATADIR': qemu_datadir},
>>> +   configuration: {'DATADIR': get_option('prefix') / 
>>> qemu_datadir},
>>> install: get_option('install_blobs'),
>>> install_dir: qemu_datadir / 'firmware')
>>>endforeach
>>>
>>
> 




Re: [PATCH v2] hw/arm/smmuv3: Fix addr_mask for range-based invalidation

2021-01-31 Thread Auger Eric
Hi Zenghui,

On 1/30/21 5:32 AM, Zenghui Yu wrote:
> When handling guest range-based IOTLB invalidation, we should decode the TG
> field into the corresponding translation granule size so that we can pass
> the correct invalidation range to backend. Set @granule to (tg * 2 + 10) to
> properly emulate the architecture.
> 
> Fixes: d52915616c05 ("hw/arm/smmuv3: Get prepared for range invalidation")
> Signed-off-by: Zenghui Yu 
> ---
> * From v1:
>   - Fix the compilation error
> 
>  hw/arm/smmuv3.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index bbca0e9f20..98b99d4fe8 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -801,7 +801,7 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr,
>  {
>  SMMUDevice *sdev = container_of(mr, SMMUDevice, iommu);
>  IOMMUTLBEvent event;
> -uint8_t granule = tg;
> +uint8_t granule;
>  
>  if (!tg) {
>  SMMUEventInfo event = {.inval_ste_allowed = true};
> @@ -821,6 +821,8 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr,
>  return;
>  }
>  granule = tt->granule_sz;
> +} else {
> +granule = tg * 2 + 10;
>  }
>  
>  event.type = IOMMU_NOTIFIER_UNMAP;
> 
Acked-by: Eric Auger 

Thanks

Eric




Re: [PATCH v5 03/11] target/arm: Restrict ARMv4 cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/30/21 7:54 PM, Peter Maydell wrote:
> On Sat, 30 Jan 2021 at 18:36, Philippe Mathieu-Daudé  wrote:
>>
>> Hi Peter,
>>
>> On 1/30/21 4:37 PM, Peter Maydell wrote:
>>> On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé  
>>> wrote:

 KVM requires a cpu based on (at least) the ARMv7 architecture.
>>>
>>> These days it requires ARMv8, because we dropped 32-bit host
>>> support, and all 64-bit host CPUs are v8.
>>
>> Oh, this comment is about the target, to justify it is pointless to
>> include pre-v7 target cpus/machines in a KVM-only binary.
>>
>> I'll update as:
>>
>> "KVM requires the target cpu based on (at least) the ARMv7
>> architecture."
> 
> KVM requires the target CPU to be at least ARMv8, because
> we only support the "host" cpu type, and all KVM host CPUs
> are v8, which means you can't pass a v7 CPU as the target CPU.
> (This used to not be true when we still supported running
> KVM on a v7 CPU like the Cortex-A15, in which case you could
> pass it to the guest.)

Indeed:

$ qemu-system-aarch64 -M xilinx-zynq-a9
qemu-system-aarch64: KVM is not supported for this guest CPU type
qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0):
Invalid argument



Re: [PATCH 05/10] meson: Introduce target-specific Kconfig

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 1:36 PM, Philippe Mathieu-Daudé wrote:
> On 1/31/21 12:13 PM, Philippe Mathieu-Daudé wrote:
>> Add a target-specific Kconfig.
>>
>> Target foo now has CONFIG_FOO defined.
>>
>> Two architecture have a particularity, ARM and MIPS:
>> their 64-bit version include the 32-bit subset.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
> ...
> 
>> diff --git a/meson.build b/meson.build
>> index f00b7754fd4..a2dda0ce95e 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -1322,7 +1322,8 @@
>>command: [minikconf,
>>  get_option('default_devices') ? '--defconfig' : 
>> '--allnoconfig',
>>  config_devices_mak, '@DEPFILE@', '@INPUT@',
>> -host_kconfig, accel_kconfig])
>> +host_kconfig, accel_kconfig,
>> +'CONFIG_' + config_target['TARGET_ARCH'].to_upper() + '=y'])
>>  
>>  config_devices_data = configuration_data()
>>  config_devices = keyval.load(config_devices_mak)
>> diff --git a/Kconfig b/Kconfig
>> index bf694c42afe..c01e261e4e9 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -1,4 +1,5 @@
>>  source Kconfig.host
>>  source backends/Kconfig
>>  source accel/Kconfig
>> +source target/Kconfig
>>  source hw/Kconfig
>> diff --git a/target/Kconfig b/target/Kconfig
>> new file mode 100644
>> index 000..a6f719f223a
>> --- /dev/null
>> +++ b/target/Kconfig
>> @@ -0,0 +1,23 @@
>> +source alpha/Kconfig
>> +source arm/Kconfig
>> +source avr/Kconfig
>> +source cris/Kconfig
>> +source hppa/Kconfig
>> +source i386/Kconfig
>> +source lm32/Kconfig
>> +source m68k/Kconfig
>> +source microblaze/Kconfig
>> +source mips/Kconfig
>> +source moxie/Kconfig
>> +source nios2/Kconfig
>> +source openrisc/Kconfig
>> +source ppc/Kconfig
>> +source riscv/Kconfig
>> +source rx/Kconfig
>> +source s390x/Kconfig
>> +source sh4/Kconfig
>> +source sparc/Kconfig
>> +source tilegx/Kconfig
>> +source tricore/Kconfig
>> +source unicore32/Kconfig
>> +source xtensa/Kconfig
>> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
>> new file mode 100644
>> index 000..3f3394a22b2
>> --- /dev/null
>> +++ b/target/arm/Kconfig
>> @@ -0,0 +1,6 @@
>> +config ARM
>> +bool
>> +
>> +config AARCH64
>> +bool
>> +select ARM
> 
> This isn't correct yet, as Kconfig is primarly designed for devices,
> and per docs/devel/kconfig.rst:
> 
>   "devices are usually ``default y`` if and only if they have at
>least one ``depends on``;"
> 
> So having one machine "depends on AARCH64" selects AARCH64 on ARM :/
> I'll see if explicit each arch as 'default n' helps...

Taking this comment back, the approach works but is fragile, as
an incorrect dependency can select the wrong arch and it is hard
to detect.



Re: [PATCH v2 5/7] hw/arm/sbsa-ref: Restrict SBSA-ref board to 64-bit build

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 1:31 PM, Philippe Mathieu-Daudé wrote:
> On 1/31/21 11:59 AM, Philippe Mathieu-Daudé wrote:
>> The SBSA-ref board only use CPUs available in the 64-bit build,
>> it is pointless to have it available in the 32-bit build.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> Cc: Radoslaw Biernacki 
>> Cc: Leif Lindholm 
>> ---
>>  hw/arm/meson.build | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/meson.build b/hw/arm/meson.build
>> index be39117b9b6..059ff7382f2 100644
>> --- a/hw/arm/meson.build
>> +++ b/hw/arm/meson.build
>> @@ -22,7 +22,7 @@
>>  arm_ss.add(when: 'CONFIG_TOSA', if_true: files('tosa.c'))
>>  arm_ss.add(when: 'CONFIG_Z2', if_true: files('z2.c'))
>>  arm_ss.add(when: 'CONFIG_REALVIEW', if_true: files('realview.c'))
>> -arm_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa-ref.c'))
>> +arm_ss.add(when: ['CONFIG_SBSA_REF', 'TARGET_AARCH64'], if_true: 
>> files('sbsa-ref.c'))
> 
> Please disregard this patch, it shows that my other patch
> "meson: Introduce target-specific Kconfig" is incorrect:
> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07989.html
> Probably because per docs/devel/kconfig.rst "devices are usually
> ``default y`` if and only if they have at least one ``depends on``".

The problem is the XLNX_ZYNQMP_ARM was incorrectly selected,
enabling AARCH64, pulling in CONFIG_SBSA_REF on 32-bit.
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg08014.html

With this change there is no problem (and this patch is not necessary):

 config XLNX_ZYNQMP_ARM
 bool
-default y if TCG && ARM
+default y if TCG && AARCH64

Regards,

Phil.



Re: [PATCH v2 6/7] hw/arm/xlnx-zcu102: Restrict ZynqMP ZCU102 board to 64-bit build

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 1:31 PM, Philippe Mathieu-Daudé wrote:
> On 1/31/21 11:59 AM, Philippe Mathieu-Daudé wrote:
>> The ZynqMP ZCU102 board only use the Cortex-A53 CPU, which
>> is only available in the 64-bit build. It is pointless to
>> have this board present in the 32-bit build where this CPU
>> is not available.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> Cc: Alistair Francis 
>> Cc: "Edgar E. Iglesias" 
>> ---
>>  hw/arm/meson.build | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/meson.build b/hw/arm/meson.build
>> index 059ff7382f2..345099f5a1b 100644
>> --- a/hw/arm/meson.build
>> +++ b/hw/arm/meson.build
>> @@ -41,7 +41,7 @@
>>  arm_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_peripherals.c', 
>> 'bcm2836.c', 'raspi.c'))
>>  arm_ss.add(when: 'CONFIG_STM32F205_SOC', if_true: files('stm32f205_soc.c'))
>>  arm_ss.add(when: 'CONFIG_STM32F405_SOC', if_true: files('stm32f405_soc.c'))
>> -arm_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zynqmp.c', 
>> 'xlnx-zcu102.c'))
>> +arm_ss.add(when: ['CONFIG_XLNX_ZYNQMP_ARM', 'TARGET_AARCH64'], if_true: 
>> files('xlnx-zynqmp.c', 'xlnx-zcu102.c'))
> 
> Please disregard this patch, it shows that my other patch
> "meson: Introduce target-specific Kconfig" is incorrect:
> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07989.html
> Probably because per docs/devel/kconfig.rst "devices are usually
> ``default y`` if and only if they have at least one ``depends on``".

The problem is the XLNX_ZYNQMP_ARM was incorrectly selected,
enabling AARCH64.
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg08014.html

With this change there is no problem (and this patch is not necessary):

 config XLNX_ZYNQMP_ARM
 bool
-default y if TCG && ARM
+default y if TCG && AARCH64

Regards,

Phil.



Re: [PATCH v6 01/11] sysemu/tcg: Introduce tcg_builtin() helper

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 3:18 PM, Claudio Fontana wrote:
> On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
>> Modules are registered early with type_register_static().
>>
>> We would like to call tcg_enabled() when registering QOM types,
> 
> 
> Hi Philippe,
> 
> could this not be controlled by meson at this stage?
> On X86, I register the tcg-specific types in tcg/* in modules that are only 
> built for TCG.
> 
> Maybe tcg_builtin() is useful anyway, thinking long term at loadable modules,
> but there we are interested in whether tcg code is available or not, 
> regardless of whether it's builtin,
> or needs to be loaded via a .so plugin..
> 
> maybe tcg_available()?

The alternatives I found:

- reorder things in vl.c?

- use ugly #ifdef'ry, see this patch:
  https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg08037.html

- this earlier approach I previously discarded:

-- >8 --
diff --git a/include/qom/object.h b/include/qom/object.h
index d378f13a116..30590c6fac3 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -403,9 +403,12 @@ struct Object
  *   parent class initialization has occurred, but before the class itself
  *   is initialized.  This is the function to use to undo the effects of
  *   memcpy from the parent class to the descendants.
- * @class_data: Data to pass to the @class_init,
+ * @class_data: Data to pass to the @class_registerable, @class_init,
  *   @class_base_init. This can be useful when building dynamic
  *   classes.
+ * @registerable: This function is called when modules are registered,
+ *   prior to any class initialization. When present and returning %false,
+ *   the type is not registered, the class is not present (not usable).
  * @interfaces: The list of interfaces associated with this type.  This
  *   should point to a static array that's terminated with a zero filled
  *   element.
@@ -428,6 +431,7 @@ struct TypeInfo
 void (*class_base_init)(ObjectClass *klass, void *data);
 void *class_data;

+bool (*registerable)(void *data);
 InterfaceInfo *interfaces;
 };

diff --git a/qom/object.c b/qom/object.c
index 2fa0119647c..0febaffa12e 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -138,6 +138,10 @@ static TypeImpl *type_new(const TypeInfo *info)
 static TypeImpl *type_register_internal(const TypeInfo *info)
 {
 TypeImpl *ti;
+
+if (info->registerable && !info->registerable(info->class_data)) {
+return NULL;
+}
 ti = type_new(info);

 type_table_add(ti);

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 990509d3852..1a2b1889da4 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -24,6 +24,7 @@
 #include "hw/loader.h"
 #include "hw/arm/boot.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/tcg.h"
 #include "qom/object.h"

 #define SMPBOOT_ADDR0x300 /* this should leave enough space for
ATAGS */
@@ -368,18 +369,26 @@ static void raspi3b_machine_class_init(ObjectClass
*oc, void *data)
 };
 #endif /* TARGET_AARCH64 */

+static bool raspi_machine_requiring_tcg_accel(void *data)
+{
+return tcg_builtin();
+}
+
 static const TypeInfo raspi_machine_types[] = {
 {
 .name   = MACHINE_TYPE_NAME("raspi0"),
 .parent = TYPE_RASPI_MACHINE,
+.registerable   = raspi_machine_requiring_tcg_accel,
 .class_init = raspi0_machine_class_init,
 }, {
 .name   = MACHINE_TYPE_NAME("raspi1ap"),
 .parent = TYPE_RASPI_MACHINE,
+.registerable   = raspi_machine_requiring_tcg_accel,
 .class_init = raspi1ap_machine_class_init,
 }, {
 .name   = MACHINE_TYPE_NAME("raspi2b"),
 .parent = TYPE_RASPI_MACHINE,
+.registerable   = raspi_machine_requiring_tcg_accel,
 .class_init = raspi2b_machine_class_init,
 #ifdef TARGET_AARCH64
 }, {
---

> 
> Ciao,
> 
> Claudio
> 
>> but tcg_enabled() returns tcg_allowed which is a runtime property
>> initialized later (See commit 2f181fbd5a9 which introduced the
>> MachineInitPhase in "hw/qdev-core.h" representing the different
>> phases of machine initialization and commit 0427b6257e2 which
>> document the initialization order).
>>
>> As we are only interested if the TCG accelerator is builtin,
>> regardless of being enabled, introduce the tcg_builtin() helper.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> Cc: Markus Armbruster 
>> ---
>>  include/sysemu/tcg.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/include/sysemu/tcg.h b/include/sysemu/tcg.h
>> index 00349fb18a7..6ac5c2ca89d 100644
>> --- a/include/sysemu/tcg.h
>> +++ b/include/sysemu/tcg.h
>> @@ -13,8 +13,10 @@ void tcg_exec_init(unsigned long tb_size, int splitwx);
>>  #ifdef CONFIG_TCG
>>  extern bool tcg_allowed;
>>  #define tcg_enabled() (tcg_allowed)
>> +#define tcg_builtin() 1
>>  #else
>>  #define tcg_enabled() 0
>> +#define tcg_builtin() 0
>>  #endif
>>  
>>  #endif
>>
> 



Re: [PATCH v6 00/11] Support disabling TCG on ARM (part 2)

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 3:40 PM, Claudio Fontana wrote:
> On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
>> Cover from Samuel Ortiz from (part 1) [1]:
>>
>>   This patchset allows for building and running ARM targets with TCG
>>   disabled. [...]
>>
>>   The rationale behind this work comes from the NEMU project where
>>   we're trying to only support x86 and ARM 64-bit architectures,
>>   without including the TCG code base. We can only do so if we can
>>   build and run ARM binaries with TCG disabled.
>>
>> Peter mentioned in v5 [6] that since 32-bit host has been removed,
>> we have to remove v7 targets. This is not done in this series, as
>> linking succeeds, and there is enough material to review (no need
>> to spend time on that extra patch if the current approach is not
>> accepted).
>>
>> CI: https://gitlab.com/philmd/qemu/-/pipelines/249272441
>>
>> v6:
>> - rebased on "target/arm/Kconfig" series
>> - introduce/use tcg_builtin() for realview machines
>>
>> v5:
>> - addressed Paolo/Richard/Thomas review comments from v4 [5].
>>
>> v4 almost 2 years later... [2]:
>> - Rebased on Meson
>> - Addressed Richard review comments
>> - Addressed Claudio review comments
>>
>> v3 almost 18 months later [3]:
>> - Rebased
>> - Addressed Thomas review comments
>> - Added Travis-CI job to keep building --disable-tcg on ARM
>>
>> v2 [4]:
>> - Addressed review comments from Richard and Thomas from v1 [1]
>>
>> Regards,
>>
>> Phil.
>>
>> [1]: https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02451.html
>> [2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg689168.html
>> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg641796.html
>> [4]: https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg05003.html
>> [5]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg746041.html
>> [6]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg777669.html
>>
>> Based-on: <2021013316.232778-1-f4...@amsat.org>
>>   "target: Provide target-specific Kconfig"
>>
>> Philippe Mathieu-Daudé (9):
>>   sysemu/tcg: Introduce tcg_builtin() helper
>>   exec: Restrict TCG specific headers
>>   target/arm: Restrict ARMv4 cpus to TCG accel
>>   target/arm: Restrict ARMv5 cpus to TCG accel
>>   target/arm: Restrict ARMv6 cpus to TCG accel
>>   target/arm: Restrict ARMv7 R-profile cpus to TCG accel
>>   target/arm: Restrict ARMv7 M-profile cpus to TCG accel
>>   target/arm: Reorder meson.build rules
>>   .travis.yml: Add a KVM-only Aarch64 job
>>
>> Samuel Ortiz (1):
>>   target/arm: Do not build TCG objects when TCG is off
>>
>> Thomas Huth (1):
>>   target/arm: Make m_helper.c optional via CONFIG_ARM_V7M
>>
>>  default-configs/devices/aarch64-softmmu.mak |  1 -
>>  default-configs/devices/arm-softmmu.mak | 27 
>>  include/exec/helper-proto.h |  2 +
>>  include/sysemu/tcg.h|  2 +
>>  target/arm/cpu.h| 12 
>>  hw/arm/realview.c   |  7 +-
>>  target/arm/cpu_tcg.c|  4 +-
>>  target/arm/helper.c |  7 --
>>  target/arm/m_helper-stub.c  | 73 +
>>  tests/qtest/cdrom-test.c|  6 +-
>>  .travis.yml | 32 +
>>  hw/arm/Kconfig  | 38 +++
>>  target/arm/Kconfig  | 17 +
>>  target/arm/meson.build  | 28 +---
>>  14 files changed, 196 insertions(+), 60 deletions(-)
>>  create mode 100644 target/arm/m_helper-stub.c
>>
> 
> Looking at this series, just my 2 cents on how I would suggest to go forward:
> I could again split my series in two parts, with only the TCG Ops in the 
> first part.
> 
> Then this series could be merged, enabling --disable-tcg for ARM,
> 
> then I could extend the second part of my series to include ARM as well.
> 
> Wdyt? (Probably Richard?)

¯\_(ツ)_/¯

I respun because Richard unqueue your series, and it looks
there is no big clashing.

Anyhow meanwhile peer review is useful, and thanks for yours ;)

> 
> Thanks,
> 
> Claudio
> 
> 
> 
> 



[RFC PATCH 2/2] hw/arm/raspi: Restrict BCM2835 / BCM2836 SoC to TCG

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

>From the various SoC used by the Raspberry Pi machines, only
the BCM2837 is an ARMv8 (Cortex-A53).

Restrict the BCM2835 (ARM1176) and BCM2836 (Cortex-A7) to TCG.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2836.c | 6 ++
 hw/arm/raspi.c   | 4 
 2 files changed, 10 insertions(+)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index fd16ed87c40..3051764f2dc 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -89,6 +89,7 @@ static bool bcm283x_common_realize(DeviceState *dev, Error 
**errp)
 return true;
 }
 
+#ifdef CONFIG_TCG
 static void bcm2835_realize(DeviceState *dev, Error **errp)
 {
 BCM283XState *s = BCM283X(dev);
@@ -107,6 +108,7 @@ static void bcm2835_realize(DeviceState *dev, Error **errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(>peripherals), 1,
 qdev_get_gpio_in(DEVICE(>cpu[0].core), ARM_CPU_FIQ));
 }
+#endif /* CONFIG_TCG */
 
 static void bcm2836_realize(DeviceState *dev, Error **errp)
 {
@@ -178,6 +180,7 @@ static void bcm283x_class_init(ObjectClass *oc, void *data)
 dc->user_creatable = false;
 }
 
+#ifdef CONFIG_TCG
 static void bcm2835_class_init(ObjectClass *oc, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(oc);
@@ -201,6 +204,7 @@ static void bcm2836_class_init(ObjectClass *oc, void *data)
 bc->clusterid = 0xf;
 dc->realize = bcm2836_realize;
 };
+#endif /* CONFIG_TCG */
 
 #ifdef TARGET_AARCH64
 static void bcm2837_class_init(ObjectClass *oc, void *data)
@@ -227,6 +231,7 @@ static const TypeInfo bcm283x_types[] = {
 .class_init = bcm283x_class_init,
 .abstract   = true,
 },
+#ifdef CONFIG_TCG
 {
 .name   = TYPE_BCM2835,
 .parent = TYPE_BCM283X,
@@ -236,6 +241,7 @@ static const TypeInfo bcm283x_types[] = {
 .parent = TYPE_BCM283X,
 .class_init = bcm2836_class_init,
 },
+#endif /* CONFIG_TCG */
 #ifdef TARGET_AARCH64
 {
 .name   = TYPE_BCM2837,
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index dce966a4dd8..cfa15504d9c 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -319,6 +319,7 @@ static void raspi_machine_class_common_init(MachineClass 
*mc,
 mc->default_ram_id = "ram";
 };
 
+#ifdef CONFIG_TCG
 static void raspi0_machine_class_init(ObjectClass *oc, void *data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
@@ -346,6 +347,7 @@ static void raspi2b_machine_class_init(ObjectClass *oc, 
void *data)
 rmc->board_rev = 0xa21041;
 raspi_machine_class_common_init(mc, rmc->board_rev);
 };
+#endif /* CONFIG_TCG */
 
 #ifdef TARGET_AARCH64
 static void raspi3ap_machine_class_init(ObjectClass *oc, void *data)
@@ -376,6 +378,7 @@ static const TypeInfo raspi_machine_types[] = {
 .class_size = sizeof(RaspiMachineClass),
 .abstract   = true,
 },
+#ifdef CONFIG_TCG
 {
 .name   = MACHINE_TYPE_NAME("raspi0"),
 .parent = TYPE_RASPI_MACHINE,
@@ -389,6 +392,7 @@ static const TypeInfo raspi_machine_types[] = {
 .parent = TYPE_RASPI_MACHINE,
 .class_init = raspi2b_machine_class_init,
 },
+#endif /* CONFIG_TCG */
 #ifdef TARGET_AARCH64
 {
 .name   = MACHINE_TYPE_NAME("raspi3ap"),
-- 
2.26.2




[RFC PATCH 1/2] hw/arm/raspi: Trivial code movement

2021-01-31 Thread Philippe Mathieu-Daudé
Move the abstract TYPE_BCM283X and TYPE_RASPI_MACHINE declarations
earlier to make the next commit easier to review.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/arm/bcm2836.c | 32 +---
 hw/arm/raspi.c   | 18 ++
 2 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index de7ade2878e..fd16ed87c40 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -219,20 +219,6 @@ static void bcm2837_class_init(ObjectClass *oc, void *data)
 
 static const TypeInfo bcm283x_types[] = {
 {
-.name   = TYPE_BCM2835,
-.parent = TYPE_BCM283X,
-.class_init = bcm2835_class_init,
-}, {
-.name   = TYPE_BCM2836,
-.parent = TYPE_BCM283X,
-.class_init = bcm2836_class_init,
-#ifdef TARGET_AARCH64
-}, {
-.name   = TYPE_BCM2837,
-.parent = TYPE_BCM283X,
-.class_init = bcm2837_class_init,
-#endif
-}, {
 .name   = TYPE_BCM283X,
 .parent = TYPE_DEVICE,
 .instance_size  = sizeof(BCM283XState),
@@ -240,7 +226,23 @@ static const TypeInfo bcm283x_types[] = {
 .class_size = sizeof(BCM283XClass),
 .class_init = bcm283x_class_init,
 .abstract   = true,
-}
+},
+{
+.name   = TYPE_BCM2835,
+.parent = TYPE_BCM283X,
+.class_init = bcm2835_class_init,
+}, {
+.name   = TYPE_BCM2836,
+.parent = TYPE_BCM283X,
+.class_init = bcm2836_class_init,
+},
+#ifdef TARGET_AARCH64
+{
+.name   = TYPE_BCM2837,
+.parent = TYPE_BCM283X,
+.class_init = bcm2837_class_init,
+},
+#endif
 };
 
 DEFINE_TYPES(bcm283x_types)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 990509d3852..dce966a4dd8 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -369,6 +369,13 @@ static void raspi3b_machine_class_init(ObjectClass *oc, 
void *data)
 #endif /* TARGET_AARCH64 */
 
 static const TypeInfo raspi_machine_types[] = {
+{
+.name   = TYPE_RASPI_MACHINE,
+.parent = TYPE_MACHINE,
+.instance_size  = sizeof(RaspiMachineState),
+.class_size = sizeof(RaspiMachineClass),
+.abstract   = true,
+},
 {
 .name   = MACHINE_TYPE_NAME("raspi0"),
 .parent = TYPE_RASPI_MACHINE,
@@ -381,8 +388,9 @@ static const TypeInfo raspi_machine_types[] = {
 .name   = MACHINE_TYPE_NAME("raspi2b"),
 .parent = TYPE_RASPI_MACHINE,
 .class_init = raspi2b_machine_class_init,
+},
 #ifdef TARGET_AARCH64
-}, {
+{
 .name   = MACHINE_TYPE_NAME("raspi3ap"),
 .parent = TYPE_RASPI_MACHINE,
 .class_init = raspi3ap_machine_class_init,
@@ -390,14 +398,8 @@ static const TypeInfo raspi_machine_types[] = {
 .name   = MACHINE_TYPE_NAME("raspi3b"),
 .parent = TYPE_RASPI_MACHINE,
 .class_init = raspi3b_machine_class_init,
+},
 #endif
-}, {
-.name   = TYPE_RASPI_MACHINE,
-.parent = TYPE_MACHINE,
-.instance_size  = sizeof(RaspiMachineState),
-.class_size = sizeof(RaspiMachineClass),
-.abstract   = true,
-}
 };
 
 DEFINE_TYPES(raspi_machine_types)
-- 
2.26.2




[RFC PATCH 0/2] hw/arm/raspi: Restrict BCM2835 / BCM2836 SoC to TCG

2021-01-31 Thread Philippe Mathieu-Daudé
Peter mentioned [*] KVM only support ARMv8 targets. Restrict the
non-ARMv8 machines to TCG.

While this is still not enough to boot a raspi3 image using KVM:

  $ qemu-system-aarch64 -M raspi3b -enable-kvm ...
  qemu-system-aarch64: ../../softmmu/physmem.c:745: cpu_address_space_init: A=
ssertion `asidx =3D=3D 0 || !kvm_enabled()' failed.
  Aborted (core dumped)

This increases the odds to have a KVM-only build pass qtests.

[*]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg777669.html

Philippe Mathieu-Daud=C3=A9 (2):
  hw/arm/raspi: Trivial code movement
  hw/arm/raspi: Restrict BCM2835 / BCM2836 SoC to TCG

 hw/arm/bcm2836.c | 38 +++---
 hw/arm/raspi.c   | 22 ++
 2 files changed, 37 insertions(+), 23 deletions(-)

--=20
2.26.2




Re: [PATCH] pc-bios/descriptors: fix paths in json files

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 3:34 PM, Sergei Trofimovich wrote:
> Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
> contained the relative path:
> "filename": "share/qemu/edk2-x86_64-secure-code.fd",
> "filename": "share/qemu/edk2-i386-vars.fd",
> 
> After then change the paths are absolute:
> "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
> "filename": "/usr/share/qemu/edk2-i386-vars.fd",
> 
> The regression appeared in qemu-5.2.0 (seems to be related
> to meson port).
> 
> CC: Paolo Bonzini 
> CC: "Marc-André Lureau" 
> CC: "Philippe Mathieu-Daudé" 
> Bug: https://bugs.gentoo.org/766743
> Bug: https://bugs.launchpad.net/qemu/+bug/1913012
> Patch-by: Jannik Glückert

Thanks Jannik and Sergei to fix this issue, I noticed
the LP#1913012 and planned to look at it tomorrow :)

Jannik, can you send a Signed-off-by line so we can accept
your patch? See:
https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line

Otherwise:
Reviewed-by: Philippe Mathieu-Daudé 

> Signed-off-by: Sergei Trofimovich 
> ---
>  pc-bios/descriptors/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/pc-bios/descriptors/meson.build b/pc-bios/descriptors/meson.build
> index ac6ec66b00..29efa16d99 100644
> --- a/pc-bios/descriptors/meson.build
> +++ b/pc-bios/descriptors/meson.build
> @@ -9,7 +9,7 @@ if install_edk2_blobs
>]
>  configure_file(input: files(f),
> output: f,
> -   configuration: {'DATADIR': qemu_datadir},
> +   configuration: {'DATADIR': get_option('prefix') / 
> qemu_datadir},
> install: get_option('install_blobs'),
> install_dir: qemu_datadir / 'firmware')
>endforeach
> 




Re: [PATCH v2 1/4] meson: Do not build Xen x86_64-softmmu on Aarch64

2021-01-31 Thread andrew . cooper3--- via
On 31/01/2021 14:18, Philippe Mathieu-Daudé wrote:
> The Xen on ARM documentation only mentions the i386-softmmu
> target. As the x86_64-softmmu doesn't seem used, remove it
> to avoid wasting cpu cycles building it.
>
> Signed-off-by: Philippe Mathieu-Daudé 

As far as I understand, it only gets used at all on ARM for the
blkback=>qcow path, and has nothing to do with I440FX or other boards. 
i.e. it is a paravirt disk and nothing else.

xenpv should not be tied to i386-softmmu in the first place, and would
remove a very-WTF-worthy current state of things.  That said, I have no
idea how much effort that might be.

~Andrew



Re: [PATCH v6 00/11] Support disabling TCG on ARM (part 2)

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> Cover from Samuel Ortiz from (part 1) [1]:
> 
>   This patchset allows for building and running ARM targets with TCG
>   disabled. [...]
> 
>   The rationale behind this work comes from the NEMU project where
>   we're trying to only support x86 and ARM 64-bit architectures,
>   without including the TCG code base. We can only do so if we can
>   build and run ARM binaries with TCG disabled.
> 
> Peter mentioned in v5 [6] that since 32-bit host has been removed,
> we have to remove v7 targets. This is not done in this series, as
> linking succeeds, and there is enough material to review (no need
> to spend time on that extra patch if the current approach is not
> accepted).
> 
> CI: https://gitlab.com/philmd/qemu/-/pipelines/249272441
> 
> v6:
> - rebased on "target/arm/Kconfig" series
> - introduce/use tcg_builtin() for realview machines
> 
> v5:
> - addressed Paolo/Richard/Thomas review comments from v4 [5].
> 
> v4 almost 2 years later... [2]:
> - Rebased on Meson
> - Addressed Richard review comments
> - Addressed Claudio review comments
> 
> v3 almost 18 months later [3]:
> - Rebased
> - Addressed Thomas review comments
> - Added Travis-CI job to keep building --disable-tcg on ARM
> 
> v2 [4]:
> - Addressed review comments from Richard and Thomas from v1 [1]
> 
> Regards,
> 
> Phil.
> 
> [1]: https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02451.html
> [2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg689168.html
> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg641796.html
> [4]: https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg05003.html
> [5]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg746041.html
> [6]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg777669.html
> 
> Based-on: <2021013316.232778-1-f4...@amsat.org>
>   "target: Provide target-specific Kconfig"
> 
> Philippe Mathieu-Daudé (9):
>   sysemu/tcg: Introduce tcg_builtin() helper
>   exec: Restrict TCG specific headers
>   target/arm: Restrict ARMv4 cpus to TCG accel
>   target/arm: Restrict ARMv5 cpus to TCG accel
>   target/arm: Restrict ARMv6 cpus to TCG accel
>   target/arm: Restrict ARMv7 R-profile cpus to TCG accel
>   target/arm: Restrict ARMv7 M-profile cpus to TCG accel
>   target/arm: Reorder meson.build rules
>   .travis.yml: Add a KVM-only Aarch64 job
> 
> Samuel Ortiz (1):
>   target/arm: Do not build TCG objects when TCG is off
> 
> Thomas Huth (1):
>   target/arm: Make m_helper.c optional via CONFIG_ARM_V7M
> 
>  default-configs/devices/aarch64-softmmu.mak |  1 -
>  default-configs/devices/arm-softmmu.mak | 27 
>  include/exec/helper-proto.h |  2 +
>  include/sysemu/tcg.h|  2 +
>  target/arm/cpu.h| 12 
>  hw/arm/realview.c   |  7 +-
>  target/arm/cpu_tcg.c|  4 +-
>  target/arm/helper.c |  7 --
>  target/arm/m_helper-stub.c  | 73 +
>  tests/qtest/cdrom-test.c|  6 +-
>  .travis.yml | 32 +
>  hw/arm/Kconfig  | 38 +++
>  target/arm/Kconfig  | 17 +
>  target/arm/meson.build  | 28 +---
>  14 files changed, 196 insertions(+), 60 deletions(-)
>  create mode 100644 target/arm/m_helper-stub.c
> 

Looking at this series, just my 2 cents on how I would suggest to go forward:
I could again split my series in two parts, with only the TCG Ops in the first 
part.

Then this series could be merged, enabling --disable-tcg for ARM,

then I could extend the second part of my series to include ARM as well.

Wdyt? (Probably Richard?)

Thanks,

Claudio







[PATCH] pc-bios/descriptors: fix paths in json files

2021-01-31 Thread Sergei Trofimovich
Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json
contained the relative path:
"filename": "share/qemu/edk2-x86_64-secure-code.fd",
"filename": "share/qemu/edk2-i386-vars.fd",

After then change the paths are absolute:
"filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
"filename": "/usr/share/qemu/edk2-i386-vars.fd",

The regression appeared in qemu-5.2.0 (seems to be related
to meson port).

CC: Paolo Bonzini 
CC: "Marc-André Lureau" 
CC: "Philippe Mathieu-Daudé" 
Bug: https://bugs.gentoo.org/766743
Bug: https://bugs.launchpad.net/qemu/+bug/1913012
Patch-by: Jannik Glückert
Signed-off-by: Sergei Trofimovich 
---
 pc-bios/descriptors/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pc-bios/descriptors/meson.build b/pc-bios/descriptors/meson.build
index ac6ec66b00..29efa16d99 100644
--- a/pc-bios/descriptors/meson.build
+++ b/pc-bios/descriptors/meson.build
@@ -9,7 +9,7 @@ if install_edk2_blobs
   ]
 configure_file(input: files(f),
output: f,
-   configuration: {'DATADIR': qemu_datadir},
+   configuration: {'DATADIR': get_option('prefix') / 
qemu_datadir},
install: get_option('install_blobs'),
install_dir: qemu_datadir / 'firmware')
   endforeach
-- 
2.30.0




Re: [PATCH v6 06/11] target/arm: Restrict ARMv7 R-profile cpus to TCG accel

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Beside, KVM only supports A-profile, thus won't be able to run
> R-profile cpus.
> 
> Only enable the following ARMv7 R-Profile CPUs when TCG is available:
> 
>   - Cortex-R5
>   - Cortex-R5F
> 
> The following machine is no more built when TCG is disabled:
> 
>   - xlnx-zcu102  Xilinx ZynqMP ZCU102 board with 4xA53s and 2xR5Fs
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/aarch64-softmmu.mak | 1 -
>  hw/arm/Kconfig  | 2 ++
>  target/arm/Kconfig  | 4 
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/default-configs/devices/aarch64-softmmu.mak 
> b/default-configs/devices/aarch64-softmmu.mak
> index 958b1e08e40..a4202f56817 100644
> --- a/default-configs/devices/aarch64-softmmu.mak
> +++ b/default-configs/devices/aarch64-softmmu.mak
> @@ -3,6 +3,5 @@
>  # We support all the 32 bit boards so need all their config
>  include arm-softmmu.mak
>  
> -CONFIG_XLNX_ZYNQMP_ARM=y
>  CONFIG_XLNX_VERSAL=y
>  CONFIG_SBSA_REF=y
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 6c4bce4d637..4baf1f97694 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -360,8 +360,10 @@ config STM32F405_SOC
>  
>  config XLNX_ZYNQMP_ARM
>  bool
> +default y if TCG && ARM
>  select AHCI
>  select ARM_GIC
> +select ARM_V7R
>  select CADENCE
>  select DDC
>  select DPCD
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> index fbb7bba9018..4dc96c46520 100644
> --- a/target/arm/Kconfig
> +++ b/target/arm/Kconfig
> @@ -18,6 +18,10 @@ config ARM_V6
>  bool
>  depends on TCG && ARM
>  
> +config ARM_V7R
> +bool
> +depends on TCG && ARM
> +
>  config ARM_V7M
>  bool
>  select PTIMER
> 

Acked-by: Claudio Fontana 



Re: [PATCH v6 07/11] target/arm: Restrict ARMv7 M-profile cpus to TCG accel

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Beside, KVM only supports A-profile, thus won't be able to run
> M-profile cpus.
> 
> Only enable the following ARMv7 M-Profile CPUs when TCG is available:
> 
>   - Cortex-M0
>   - Cortex-M3
>   - Cortex-M4
>   - Cortex-M33
> 
> The following machines are no more built when TCG is disabled:
> 
>   - emcraft-sf2  SmartFusion2 SOM kit from Emcraft (M2S010)
>   - highbank Calxeda Highbank (ECX-1000)
>   - lm3s6965evb  Stellaris LM3S6965EVB (Cortex-M3)
>   - lm3s811evb   Stellaris LM3S811EVB (Cortex-M3)
>   - midway   Calxeda Midway (ECX-2000)
>   - mps2-an385   ARM MPS2 with AN385 FPGA image for Cortex-M3
>   - mps2-an386   ARM MPS2 with AN386 FPGA image for Cortex-M4
>   - mps2-an500   ARM MPS2 with AN500 FPGA image for Cortex-M7
>   - mps2-an505   ARM MPS2 with AN505 FPGA image for Cortex-M33
>   - mps2-an511   ARM MPS2 with AN511 DesignStart FPGA image for 
> Cortex-M3
>   - mps2-an521   ARM MPS2 with AN521 FPGA image for dual Cortex-M33
>   - musca-a  ARM Musca-A board (dual Cortex-M33)
>   - musca-b1 ARM Musca-B1 board (dual Cortex-M33)
>   - netduino2Netduino 2 Machine (Cortex-M3)
>   - netduinoplus2Netduino Plus 2 Machine(Cortex-M4)
> 
> We don't need to enforce CONFIG_ARM_V7M in default-configs anymore.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/arm-softmmu.mak | 11 ---
>  hw/arm/Kconfig  |  7 +++
>  target/arm/Kconfig  |  1 +
>  3 files changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/default-configs/devices/arm-softmmu.mak 
> b/default-configs/devices/arm-softmmu.mak
> index 175530595ce..0fc80d7d6df 100644
> --- a/default-configs/devices/arm-softmmu.mak
> +++ b/default-configs/devices/arm-softmmu.mak
> @@ -1,28 +1,17 @@
>  # Default configuration for arm-softmmu
>  
> -# TODO: ARM_V7M is currently always required - make this more flexible!
> -CONFIG_ARM_V7M=y
> -
>  # CONFIG_PCI_DEVICES=n
>  # CONFIG_TEST_DEVICES=n
>  
>  CONFIG_ARM_VIRT=y
>  CONFIG_CUBIEBOARD=y
>  CONFIG_EXYNOS4=y
> -CONFIG_HIGHBANK=y
> -CONFIG_MUSCA=y
> -CONFIG_STELLARIS=y
>  CONFIG_REALVIEW=y
>  CONFIG_VEXPRESS=y
>  CONFIG_ZYNQ=y
>  CONFIG_NPCM7XX=y
> -CONFIG_NETDUINO2=y
> -CONFIG_NETDUINOPLUS2=y
> -CONFIG_MPS2=y
>  CONFIG_RASPI=y
>  CONFIG_SABRELITE=y
> -CONFIG_EMCRAFT_SF2=y
> -CONFIG_MICROBIT=y
>  CONFIG_FSL_IMX7=y
>  CONFIG_FSL_IMX6UL=y
>  CONFIG_ALLWINNER_H3=y
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 4baf1f97694..62f8b0d24e7 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -60,6 +60,7 @@ config EXYNOS4
>  
>  config HIGHBANK
>  bool
> +default y if TCG && ARM
>  select A9MPCORE
>  select A15MPCORE
>  select AHCI
> @@ -95,6 +96,7 @@ config MAINSTONE
>  
>  config MUSCA
>  bool
> +default y if TCG && ARM
>  select ARMSSE
>  select PL011
>  select PL031
> @@ -115,10 +117,12 @@ config MUSICPAL
>  
>  config NETDUINO2
>  bool
> +default y if TCG && ARM
>  select STM32F205_SOC
>  
>  config NETDUINOPLUS2
>  bool
> +default y if TCG && ARM
>  select STM32F405_SOC
>  
>  config NSERIES
> @@ -240,6 +244,7 @@ config SABRELITE
>  
>  config STELLARIS
>  bool
> +default y if TCG && ARM
>  select ARM_V7M
>  select CMSDK_APB_WATCHDOG
>  select I2C
> @@ -443,6 +448,7 @@ config ASPEED_SOC
>  
>  config MPS2
>  bool
> +default y if TCG && ARM
>  select ARMSSE
>  select LAN9118
>  select MPS2_FPGAIO
> @@ -496,6 +502,7 @@ config NRF51_SOC
>  
>  config EMCRAFT_SF2
>  bool
> +default y if TCG && ARM
>  select MSF2
>  select SSI_M25P80
>  
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> index 4dc96c46520..07a2fad7a2b 100644
> --- a/target/arm/Kconfig
> +++ b/target/arm/Kconfig
> @@ -24,4 +24,5 @@ config ARM_V7R
>  
>  config ARM_V7M
>  bool
> +depends on TCG && ARM
>  select PTIMER
> 

Acked-by: Claudio Fontana 



Re: [PATCH v6 05/11] target/arm: Restrict ARMv6 cpus to TCG accel

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Only enable the following ARMv6 CPUs when TCG is available:
> 
>   - ARM1136
>   - ARM1176
>   - ARM11MPCore
>   - Cortex-M0
> 
> The following machines are no more built when TCG is disabled:
> 
>   - kzm  ARM KZM Emulation Baseboard (ARM1136)
>   - microbit BBC micro:bit (Cortex-M0)
>   - n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
>   - n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
>   - realview-eb-mpcore   ARM RealView Emulation Baseboard (ARM11MPCore)
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/arm-softmmu.mak | 2 --
>  hw/arm/realview.c   | 2 +-
>  tests/qtest/cdrom-test.c| 2 +-
>  hw/arm/Kconfig  | 6 ++
>  target/arm/Kconfig  | 4 
>  5 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/default-configs/devices/arm-softmmu.mak 
> b/default-configs/devices/arm-softmmu.mak
> index 0aad35da0c4..175530595ce 100644
> --- a/default-configs/devices/arm-softmmu.mak
> +++ b/default-configs/devices/arm-softmmu.mak
> @@ -10,9 +10,7 @@ CONFIG_ARM_VIRT=y
>  CONFIG_CUBIEBOARD=y
>  CONFIG_EXYNOS4=y
>  CONFIG_HIGHBANK=y
> -CONFIG_FSL_IMX31=y
>  CONFIG_MUSCA=y
> -CONFIG_NSERIES=y
>  CONFIG_STELLARIS=y
>  CONFIG_REALVIEW=y
>  CONFIG_VEXPRESS=y
> diff --git a/hw/arm/realview.c b/hw/arm/realview.c
> index 2dcf0a4c23e..0606d22da14 100644
> --- a/hw/arm/realview.c
> +++ b/hw/arm/realview.c
> @@ -463,8 +463,8 @@ static void realview_machine_init(void)
>  {
>  if (tcg_builtin()) {
>  type_register_static(_eb_type);
> +type_register_static(_eb_mpcore_type);
>  }
> -type_register_static(_eb_mpcore_type);
>  type_register_static(_pb_a8_type);
>  type_register_static(_pbx_a9_type);
>  }
> diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
> index 1f1bc26fa7a..cb0409c5a11 100644
> --- a/tests/qtest/cdrom-test.c
> +++ b/tests/qtest/cdrom-test.c
> @@ -224,8 +224,8 @@ int main(int argc, char **argv)
>  const char *armmachines[] = {
>  #ifdef CONFIG_TCG
>  "realview-eb",
> -#endif /* CONFIG_TCG */
>  "realview-eb-mpcore",
> +#endif /* CONFIG_TCG */
>  "realview-pb-a8",
>  "realview-pbx-a9", "versatileab", "versatilepb", "vexpress-a15",
>  "vexpress-a9", "virt", NULL
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 560442bfc5c..6c4bce4d637 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -123,6 +123,8 @@ config NETDUINOPLUS2
>  
>  config NSERIES
>  bool
> +default y if TCG && ARM
> +select ARM_V6
>  select OMAP
>  select TMP105   # tempature sensor
>  select BLIZZARD # LCD/TV controller
> @@ -401,6 +403,8 @@ config FSL_IMX25
>  
>  config FSL_IMX31
>  bool
> +default y if TCG && ARM
> +select ARM_V6
>  select SERIAL
>  select IMX
>  select IMX_I2C
> @@ -478,11 +482,13 @@ config FSL_IMX6UL
>  
>  config MICROBIT
>  bool
> +default y if TCG && ARM
>  select NRF51_SOC
>  
>  config NRF51_SOC
>  bool
>  select I2C
> +select ARM_V6
>  select ARM_V7M
>  select UNIMP
>  
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> index 9b3635617dc..fbb7bba9018 100644
> --- a/target/arm/Kconfig
> +++ b/target/arm/Kconfig
> @@ -14,6 +14,10 @@ config ARM_V5
>  bool
>  depends on TCG && ARM
>  
> +config ARM_V6
> +bool
> +depends on TCG && ARM
> +
>  config ARM_V7M
>  bool
>  select PTIMER
> 

Added Cc: Eduardo,

Looks good to me in general,

Acked-by: Claudio Fontana 

I am just wondering about that if (tcg_builtin()) / (or _available() as I 
suggest elsewhere), 
should we instead use the build system already at this stage, so no such check 
is necessary?

It could be a successive change, but then tcg_builtin() would be introduced, 
only to become useless after the proper refactoring is done,
and the build system is used to select the right modules to compile, which 
would do the registration.

Ciao,

Claudio




Re: [PATCH v6 04/11] target/arm: Restrict ARMv5 cpus to TCG accel

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Only enable the following ARMv5 CPUs when TCG is available:
> 
>   - ARM926
>   - ARM946
>   - ARM1026
>   - XScale (PXA250/255/260/261/262/270)
> 
> The following machines are no more built when TCG is disabled:
> 
>   - akitaSharp SL-C1000 (Akita) PDA (PXA270)
>   - ast2500-evb  Aspeed AST2500 EVB (ARM1176)
>   - ast2600-evb  Aspeed AST2600 EVB (Cortex A7)
>   - borzoi   Sharp SL-C3100 (Borzoi) PDA (PXA270)
>   - canon-a1100  Canon PowerShot A1100 IS (ARM946)
>   - collie   Sharp SL-5500 (Collie) PDA (SA-1110)
>   - connex   Gumstix Connex (PXA255)
>   - g220a-bmcBytedance G220A BMC (ARM1176)
>   - imx25-pdkARM i.MX25 PDK board (ARM926)
>   - integratorcp ARM Integrator/CP (ARM926EJ-S)
>   - mainstoneMainstone II (PXA27x)
>   - musicpal Marvell 88w8618 / MusicPal (ARM926EJ-S)
>   - palmetto-bmc OpenPOWER Palmetto BMC (ARM926EJ-S)
>   - realview-eb  ARM RealView Emulation Baseboard (ARM926EJ-S)
>   - romulus-bmc  OpenPOWER Romulus BMC (ARM1176)
>   - sonorapass-bmc   OCP SonoraPass BMC (ARM1176)
>   - spitzSharp SL-C3000 (Spitz) PDA (PXA270)
>   - supermicrox11-bmcSupermicro X11 BMC (ARM926EJ-S)
>   - swift-bmcOpenPOWER Swift BMC (ARM1176)
>   - tacoma-bmc   OpenPOWER Tacoma BMC (Cortex A7)
>   - terrier  Sharp SL-C3200 (Terrier) PDA (PXA270)
>   - tosa Sharp SL-6000 (Tosa) PDA (PXA255)
>   - verdex   Gumstix Verdex (PXA270)
>   - versatileab  ARM Versatile/AB (ARM926EJ-S)
>   - versatilepb  ARM Versatile/PB (ARM926EJ-S)
>   - witherspoon-bmc  OpenPOWER Witherspoon BMC (ARM1176)
>   - z2   Zipit Z2 (PXA27x)
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/arm-softmmu.mak | 12 
>  hw/arm/realview.c   |  5 -
>  tests/qtest/cdrom-test.c|  6 +-
>  hw/arm/Kconfig  | 19 +++
>  target/arm/Kconfig  |  4 
>  5 files changed, 32 insertions(+), 14 deletions(-)
> 
> diff --git a/default-configs/devices/arm-softmmu.mak 
> b/default-configs/devices/arm-softmmu.mak
> index 6ae964c14fd..0aad35da0c4 100644
> --- a/default-configs/devices/arm-softmmu.mak
> +++ b/default-configs/devices/arm-softmmu.mak
> @@ -10,33 +10,21 @@ CONFIG_ARM_VIRT=y
>  CONFIG_CUBIEBOARD=y
>  CONFIG_EXYNOS4=y
>  CONFIG_HIGHBANK=y
> -CONFIG_INTEGRATOR=y
>  CONFIG_FSL_IMX31=y
> -CONFIG_MUSICPAL=y
>  CONFIG_MUSCA=y
>  CONFIG_NSERIES=y
>  CONFIG_STELLARIS=y
>  CONFIG_REALVIEW=y
> -CONFIG_VERSATILE=y
>  CONFIG_VEXPRESS=y
>  CONFIG_ZYNQ=y
> -CONFIG_MAINSTONE=y
> -CONFIG_GUMSTIX=y
> -CONFIG_SPITZ=y
> -CONFIG_TOSA=y
> -CONFIG_Z2=y
>  CONFIG_NPCM7XX=y
> -CONFIG_COLLIE=y
> -CONFIG_ASPEED_SOC=y
>  CONFIG_NETDUINO2=y
>  CONFIG_NETDUINOPLUS2=y
>  CONFIG_MPS2=y
>  CONFIG_RASPI=y
> -CONFIG_DIGIC=y
>  CONFIG_SABRELITE=y
>  CONFIG_EMCRAFT_SF2=y
>  CONFIG_MICROBIT=y
> -CONFIG_FSL_IMX25=y
>  CONFIG_FSL_IMX7=y
>  CONFIG_FSL_IMX6UL=y
>  CONFIG_ALLWINNER_H3=y
> diff --git a/hw/arm/realview.c b/hw/arm/realview.c
> index 0831159d158..2dcf0a4c23e 100644
> --- a/hw/arm/realview.c
> +++ b/hw/arm/realview.c
> @@ -18,6 +18,7 @@
>  #include "hw/pci/pci.h"
>  #include "net/net.h"
>  #include "sysemu/sysemu.h"
> +#include "sysemu/tcg.h"
>  #include "hw/boards.h"
>  #include "hw/i2c/i2c.h"
>  #include "exec/address-spaces.h"
> @@ -460,7 +461,9 @@ static const TypeInfo realview_pbx_a9_type = {
>  
>  static void realview_machine_init(void)
>  {
> -type_register_static(_eb_type);
> +if (tcg_builtin()) {
> +type_register_static(_eb_type);
> +}
>  type_register_static(_eb_mpcore_type);
>  type_register_static(_pb_a8_type);
>  type_register_static(_pbx_a9_type);
> diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
> index 5af944a5fb7..1f1bc26fa7a 100644
> --- a/tests/qtest/cdrom-test.c
> +++ b/tests/qtest/cdrom-test.c
> @@ -222,7 +222,11 @@ int main(int argc, char **argv)
>  add_cdrom_param_tests(mips64machines);
>  } else if (g_str_equal(arch, "arm") || g_str_equal(arch, "aarch64")) {
>  const char *armmachines[] = {
> -"realview-eb", "realview-eb-mpcore", "realview-pb-a8",
> +#ifdef CONFIG_TCG
> +"realview-eb",
> +#endif /* CONFIG_TCG */
> +"realview-eb-mpcore",
> +"realview-pb-a8",
>  "realview-pbx-a9", "versatileab", "versatilepb", "vexpress-a15",
>  "vexpress-a9", "virt", NULL
>  };
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index f2957b33bee..560442bfc5c 100644
> --- 

Re: [PATCH v6 03/11] target/arm: Restrict ARMv4 cpus to TCG accel

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Only enable the following ARMv4 CPUs when TCG is available:
> 
>   - StrongARM (SA1100/1110)
>   - OMAP1510 (TI925T)
> 
> The following machines are no more built when TCG is disabled:
> 
>   - cheetah  Palm Tungsten|E aka. Cheetah PDA (OMAP310)
>   - sx1  Siemens SX1 (OMAP310) V2
>   - sx1-v1   Siemens SX1 (OMAP310) V1
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/arm-softmmu.mak | 2 --
>  hw/arm/Kconfig  | 4 
>  target/arm/Kconfig  | 4 
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/default-configs/devices/arm-softmmu.mak 
> b/default-configs/devices/arm-softmmu.mak
> index 0824e9be795..6ae964c14fd 100644
> --- a/default-configs/devices/arm-softmmu.mak
> +++ b/default-configs/devices/arm-softmmu.mak
> @@ -14,8 +14,6 @@ CONFIG_INTEGRATOR=y
>  CONFIG_FSL_IMX31=y
>  CONFIG_MUSICPAL=y
>  CONFIG_MUSCA=y
> -CONFIG_CHEETAH=y
> -CONFIG_SX1=y
>  CONFIG_NSERIES=y
>  CONFIG_STELLARIS=y
>  CONFIG_REALVIEW=y
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index f3ecb73a3d8..f2957b33bee 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -31,6 +31,8 @@ config ARM_VIRT
>  
>  config CHEETAH
>  bool
> +default y if TCG && ARM
> +select ARM_V4
>  select OMAP
>  select TSC210X
>  
> @@ -249,6 +251,8 @@ config COLLIE
>  
>  config SX1
>  bool
> +default y if TCG && ARM
> +select ARM_V4
>  select OMAP
>  
>  config VERSATILE
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> index ae89d05c7e5..811e1e81652 100644
> --- a/target/arm/Kconfig
> +++ b/target/arm/Kconfig
> @@ -6,6 +6,10 @@ config AARCH64
>  bool
>  select ARM
>  
> +config ARM_V4
> +bool
> +depends on TCG && ARM
> +
>  config ARM_V7M
>  bool
>  select PTIMER
> 

Looks good to me

Acked-by: Claudio Fontana 




[PATCH v2 3/4] hw/xen/Kconfig: Introduce XEN_PV config

2021-01-31 Thread Philippe Mathieu-Daudé
xenpv machine requires USB, IDE_PIIX and PCI:

  /usr/bin/ld:
  libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function 
`xen_be_register_common':
  hw/xen/xen-legacy-backend.c:757: undefined reference to `xen_usb_ops'
  libqemu-i386-softmmu.fa.p/hw_i386_xen_xen_platform.c.o: in function 
`unplug_disks':
  hw/i386/xen/xen_platform.c:153: undefined reference to 
`pci_piix3_xen_ide_unplug'
  libqemu-i386-softmmu.fa.p/hw_i386_xen_xen_platform.c.o: in function 
`pci_unplug_nics':
  hw/i386/xen/xen_platform.c:137: undefined reference to `pci_for_each_device'
  libqemu-i386-softmmu.fa.p/hw_i386_xen_xen_platform.c.o: in function 
`xen_platform_realize':
  hw/i386/xen/xen_platform.c:483: undefined reference to `pci_register_bar'

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/Kconfig | 1 +
 hw/xen/Kconfig | 7 +++
 2 files changed, 8 insertions(+)
 create mode 100644 hw/xen/Kconfig

diff --git a/hw/Kconfig b/hw/Kconfig
index 5ad3c6b5a4b..f2a95591d94 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -39,6 +39,7 @@ source usb/Kconfig
 source virtio/Kconfig
 source vfio/Kconfig
 source watchdog/Kconfig
+source xen/Kconfig
 
 # arch Kconfig
 source arm/Kconfig
diff --git a/hw/xen/Kconfig b/hw/xen/Kconfig
new file mode 100644
index 000..0b8427d6bd1
--- /dev/null
+++ b/hw/xen/Kconfig
@@ -0,0 +1,7 @@
+config XEN_PV
+bool
+default y if XEN
+depends on XEN
+select PCI
+select USB
+select IDE_PIIX
-- 
2.26.2




Re: [PATCH v6 02/11] exec: Restrict TCG specific headers

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> Fixes when building with --disable-tcg on ARM:
> 
>   In file included from target/arm/helper.c:16:
>   include/exec/helper-proto.h:42:10: fatal error: tcg-runtime.h: No such file 
> or directory
>  42 | #include "tcg-runtime.h"
> |  ^~~
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/exec/helper-proto.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/exec/helper-proto.h b/include/exec/helper-proto.h
> index 659f9298e8f..740bff3bb4d 100644
> --- a/include/exec/helper-proto.h
> +++ b/include/exec/helper-proto.h
> @@ -39,8 +39,10 @@ dh_ctype(ret) HELPER(name) (dh_ctype(t1), dh_ctype(t2), 
> dh_ctype(t3), \
>  
>  #include "helper.h"
>  #include "trace/generated-helpers.h"
> +#ifdef CONFIG_TCG
>  #include "tcg-runtime.h"
>  #include "plugin-helpers.h"
> +#endif /* CONFIG_TCG */
>  
>  #undef IN_HELPER_PROTO
>  
> 

Ok, this would go away when applying the refactoring to ARM though right?

Ie the file should not need including at all later on right?

Anyway:

Reviewed-by: Claudio Fontana 



[PATCH v2 4/4] hw/xen: Have Xen machines select 9pfs

2021-01-31 Thread Philippe Mathieu-Daudé
9pfs is not an accelerator feature but a machine one,
move the selection on the machine Kconfig (in hw/).

Signed-off-by: Philippe Mathieu-Daudé 
---
 accel/Kconfig   | 1 -
 hw/i386/xen/Kconfig | 1 +
 hw/xen/Kconfig  | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/accel/Kconfig b/accel/Kconfig
index 461104c7715..b9e9a2d35b0 100644
--- a/accel/Kconfig
+++ b/accel/Kconfig
@@ -15,4 +15,3 @@ config KVM
 
 config XEN
 bool
-select FSDEV_9P if VIRTFS
diff --git a/hw/i386/xen/Kconfig b/hw/i386/xen/Kconfig
index ad9d774b9ea..4affd842f28 100644
--- a/hw/i386/xen/Kconfig
+++ b/hw/i386/xen/Kconfig
@@ -3,3 +3,4 @@ config XEN_FV
 default y if XEN
 depends on XEN
 select I440FX
+select FSDEV_9P if VIRTFS
diff --git a/hw/xen/Kconfig b/hw/xen/Kconfig
index 0b8427d6bd1..825277969fa 100644
--- a/hw/xen/Kconfig
+++ b/hw/xen/Kconfig
@@ -5,3 +5,4 @@ config XEN_PV
 select PCI
 select USB
 select IDE_PIIX
+select FSDEV_9P if VIRTFS
-- 
2.26.2




[PATCH v2 1/4] meson: Do not build Xen x86_64-softmmu on Aarch64

2021-01-31 Thread Philippe Mathieu-Daudé
The Xen on ARM documentation only mentions the i386-softmmu
target. As the x86_64-softmmu doesn't seem used, remove it
to avoid wasting cpu cycles building it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 meson.build | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index f00b7754fd4..97a577a7743 100644
--- a/meson.build
+++ b/meson.build
@@ -74,10 +74,10 @@
 endif
 
 accelerator_targets = { 'CONFIG_KVM': kvm_targets }
-if cpu in ['x86', 'x86_64', 'arm', 'aarch64']
+if cpu in ['arm', 'aarch64']
   # i368 emulator provides xenpv machine type for multiple architectures
   accelerator_targets += {
-'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
+'CONFIG_XEN': ['i386-softmmu'],
   }
 endif
 if cpu in ['x86', 'x86_64']
@@ -85,6 +85,7 @@
 'CONFIG_HAX': ['i386-softmmu', 'x86_64-softmmu'],
 'CONFIG_HVF': ['x86_64-softmmu'],
 'CONFIG_WHPX': ['i386-softmmu', 'x86_64-softmmu'],
+'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
   }
 endif
 
-- 
2.26.2




[PATCH v2 2/4] hw/i386/xen: Introduce XEN_FV Kconfig

2021-01-31 Thread Philippe Mathieu-Daudé
Introduce XEN_FV to differency the machine from the accelerator.

Suggested-by: Paolo Bonzini 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/i386/Kconfig | 2 ++
 hw/i386/xen/Kconfig | 5 +
 hw/i386/xen/meson.build | 2 +-
 3 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 hw/i386/xen/Kconfig

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 7f91f30877f..b4c8aa5c242 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -1,3 +1,5 @@
+source xen/Kconfig
+
 config SEV
 bool
 depends on KVM
diff --git a/hw/i386/xen/Kconfig b/hw/i386/xen/Kconfig
new file mode 100644
index 000..ad9d774b9ea
--- /dev/null
+++ b/hw/i386/xen/Kconfig
@@ -0,0 +1,5 @@
+config XEN_FV
+bool
+default y if XEN
+depends on XEN
+select I440FX
diff --git a/hw/i386/xen/meson.build b/hw/i386/xen/meson.build
index be84130300c..082d0f02cf3 100644
--- a/hw/i386/xen/meson.build
+++ b/hw/i386/xen/meson.build
@@ -1,4 +1,4 @@
-i386_ss.add(when: 'CONFIG_XEN', if_true: files(
+i386_ss.add(when: 'CONFIG_XEN_FV', if_true: files(
   'xen-hvm.c',
   'xen-mapcache.c',
   'xen_apic.c',
-- 
2.26.2




Re: [PATCH v6 01/11] sysemu/tcg: Introduce tcg_builtin() helper

2021-01-31 Thread Claudio Fontana
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> Modules are registered early with type_register_static().
> 
> We would like to call tcg_enabled() when registering QOM types,


Hi Philippe,

could this not be controlled by meson at this stage?
On X86, I register the tcg-specific types in tcg/* in modules that are only 
built for TCG.

Maybe tcg_builtin() is useful anyway, thinking long term at loadable modules,
but there we are interested in whether tcg code is available or not, regardless 
of whether it's builtin,
or needs to be loaded via a .so plugin..

maybe tcg_available()?

Ciao,

Claudio

> but tcg_enabled() returns tcg_allowed which is a runtime property
> initialized later (See commit 2f181fbd5a9 which introduced the
> MachineInitPhase in "hw/qdev-core.h" representing the different
> phases of machine initialization and commit 0427b6257e2 which
> document the initialization order).
> 
> As we are only interested if the TCG accelerator is builtin,
> regardless of being enabled, introduce the tcg_builtin() helper.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Cc: Markus Armbruster 
> ---
>  include/sysemu/tcg.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/sysemu/tcg.h b/include/sysemu/tcg.h
> index 00349fb18a7..6ac5c2ca89d 100644
> --- a/include/sysemu/tcg.h
> +++ b/include/sysemu/tcg.h
> @@ -13,8 +13,10 @@ void tcg_exec_init(unsigned long tb_size, int splitwx);
>  #ifdef CONFIG_TCG
>  extern bool tcg_allowed;
>  #define tcg_enabled() (tcg_allowed)
> +#define tcg_builtin() 1
>  #else
>  #define tcg_enabled() 0
> +#define tcg_builtin() 0
>  #endif
>  
>  #endif
> 




[PATCH v2 0/4] hw/xen: Introduce XEN_FV/XEN_PV Kconfig

2021-01-31 Thread Philippe Mathieu-Daudé
Sort the Xen buildsys glue a bit.

v2: Considered Paolo's comments from v1

Supersedes: <20210129194415.3925153-1-f4...@amsat.org>

Philippe Mathieu-Daudé (4):
  meson: Do not build Xen x86_64-softmmu on Aarch64
  hw/i386/xen: Introduce XEN_FV Kconfig
  hw/xen/Kconfig: Introduce XEN_PV config
  hw/xen: Have Xen machines select 9pfs

 meson.build | 5 +++--
 accel/Kconfig   | 1 -
 hw/Kconfig  | 1 +
 hw/i386/Kconfig | 2 ++
 hw/i386/xen/Kconfig | 6 ++
 hw/i386/xen/meson.build | 2 +-
 hw/xen/Kconfig  | 8 
 7 files changed, 21 insertions(+), 4 deletions(-)
 create mode 100644 hw/i386/xen/Kconfig
 create mode 100644 hw/xen/Kconfig

-- 
2.26.2




[Bug 1913012] Re: Installed firmware descriptor files contain (invalid) relative paths

2021-01-31 Thread Sergei Trofimovich
Gentoo also noticed the bug: https://bugs.gentoo.org/766743

Jannik Glückert proposed a fix:

```
--- a/pc-bios/descriptors/meson.build
+++ b/pc-bios/descriptors/meson.build
@@ -8,7 +8,7 @@ foreach f: [
 ]
   configure_file(input: files(f),
  output: f,
- configuration: {'DATADIR': qemu_datadir},
+ configuration: {'DATADIR': get_option('prefix') / 
qemu_datadir},
  install: get_option('install_blobs'),
  install_dir: qemu_datadir / 'firmware')
 endforeach
```

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

Title:
  Installed firmware descriptor files contain (invalid) relative paths

Status in QEMU:
  New

Bug description:
  After building and installing QEMU, the resulting installed firmware
  descriptor files contain relative paths for their `mapping.filename`
  properties. These relative paths are causing errors when using tools
  based on `libvirt` like `virt-install`, resulting in the inability to
  configure new VMs which reference these firmware descriptors.

  # QEMU version
  $ qemu-system-x86_64 -version
  QEMU emulator version 5.2.0

  (I've also reproduced the issue with QEMU built from Git master @
  v5.2.0-1300-g0e32462630, see next comment.)

  # OS version
  Void Linux x86_64 (glibc)

  Steps to reproduce (with results on my system):

  # Verify the symptom

  $ virt-install --boot firmware=efi --disk none --memory 2048
  Using default --name vm4
  WARNING  No operating system detected, VM performance may suffer. Specify an 
OS with --os-variant for optimal results.

  Starting install...
  ERRORFailed to open file 'share/qemu/edk2-i386-vars.fd': No such file or 
directory
  Domain installation does not appear to have been successful.
  If it was, you can restart your domain by running:
    virsh --connect qemu:///session start vm4
  otherwise, please restart your installation.

  # Verify that the file does exist on the system and is accessible

  $ ls -l /usr/share/qemu/edk2-i386-vars.fd
  -rw-r--r-- 1 root root 540672 12 dec 18:47 /usr/share/qemu/edk2-i386-vars.fd

  # Verify most likely cause

  $ grep filename /usr/share/qemu/firmware/*i386*.json
  /usr/share/qemu/firmware/50-edk2-i386-secure.json:"filename": 
"share/qemu/edk2-i386-secure-code.fd",
  /usr/share/qemu/firmware/50-edk2-i386-secure.json:"filename": 
"share/qemu/edk2-i386-vars.fd",
  /usr/share/qemu/firmware/60-edk2-i386.json:"filename": 
"share/qemu/edk2-i386-code.fd",
  /usr/share/qemu/firmware/60-edk2-i386.json:"filename": 
"share/qemu/edk2-i386-vars.fd",

  Note that all the paths are relative and are missing , i.e.
  `/usr`.

  # Workaround

  Manually editing the firmware descriptor files in
  `/usr/share/qemu/firmware` to contain full absolute paths to the
  firmware blobs resolves the issue:

  $ sudo sed -i.bak -e 's,"share/qemu/,"/usr/share/qemu/,' 
/usr/share/qemu/firmware/*.json
  $ virt-install --boot firmware=efi --disk none --memory 2048
  [...VM boots normally...]

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



Re: [RFC PATCH 1/4] hw/ide/Kconfig: IDE_ISA requires ISA_BUS

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/29/21 8:59 PM, Paolo Bonzini wrote:
> On 29/01/21 20:44, Philippe Mathieu-Daudé wrote:
>> hw/ide/ioport.c has a strong dependency on hw/isa/isa-bus.c:
>>
>>    /usr/bin/ld: libcommon.fa.p/hw_ide_ioport.c.o: in function
>> `ide_init_ioport':
>>    /usr/bin/ld: hw/ide/ioport.c:61: undefined reference to
>> `isa_register_portio_list'
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   hw/ide/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
>> index 5d9106b1ac2..41cdd9cbe03 100644
>> --- a/hw/ide/Kconfig
>> +++ b/hw/ide/Kconfig
>> @@ -12,7 +12,7 @@ config IDE_PCI
>>     config IDE_ISA
>>   bool
>> -    depends on ISA_BUS
>> +    select ISA_BUS
>>   select IDE_QDEV
>>     config IDE_PIIX
> 
> This is incorrect.  Buses are "depended on", not selected, and this is
> documented in docs/devel/kconfig.rst.

This is a kludge to deal with the current state of hw/i386/Kconfig.

I tried to clean it twice (mostly because unused things are pulled
in the MIPS targets), but I eventually gave up after accepting the
PC machines are Frankenstein ones built for virtualization, and I've
been told "if it ain't broke, don't fix it".



Re: [PATCH] hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register

2021-01-31 Thread Philippe Mathieu-Daudé
Forwarding to qemu-security@ to see if this issue is worth a CVE.

On 1/31/21 12:57 PM, P J P wrote:
> +-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
> | On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
> | > Per the ARM Generic Interrupt Controller Architecture specification
> | > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
> | > not 10:
> | > 
> | > - Table 4-21 GICD_SGIR bit assignments
> | > 
> | > The Interrupt ID of the SGI to forward to the specified CPU
> | > interfaces. The value of this field is the Interrupt ID, in
> | > the range 0-15, for example a value of 0b0011 specifies
> | > Interrupt ID 3.
> | > 
> | > diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
> | > index af41e2fb448..75316329516 100644
> | > --- a/hw/intc/arm_gic.c
> | > +++ b/hw/intc/arm_gic.c
> | > @@ -1476,7 +1476,7 @@ static void gic_dist_writel(void *opaque, hwaddr 
> offset,
> | >  int target_cpu;
> | >  
> | >  cpu = gic_get_current_cpu(s);
> | > -irq = value & 0x3ff;
> | > +irq = value & 0xf;
> | >  switch ((value >> 24) & 3) {
> | >  case 0:
> | >  mask = (value >> 16) & ALL_CPU_MASK;
> | > 
> 
> * Looks okay.
> 
> 
> | > Correct the irq mask to fix an undefined behavior (which eventually
> | > lead to a heap-buffer-overflow, see [Buglink]):
> | > 
> | >$ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M 
> virt,accel=qtest -qtest stdio
> | >[I 1612088147.116987] OPENED
> | >   [R +0.278293] writel 0x8000f00 0xff4affb0
> | >   ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds 
> for type 'uint8_t [16][8]'
> | >   SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> ../hw/intc/arm_gic.c:1498:13
> | > 
> | > Cc: qemu-sta...@nongnu.org
> | > Fixes: 9ee6e8bb853 ("ARMv7 support.")
> | > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
> | > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
> | 
> | > ---
> | > Isnt it worth a CVE to help distributions track backports?
> | > ---
> 
> * Please send such report(s) to 'qemu-security' list to be triaged as 
>   potential security ones.
> 
> 
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
> 



Re: [PATCH 01/10] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_PERIPHERALS

2021-01-31 Thread BALATON Zoltan

On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote:

We want to be able to use the 'SH4' config for architecture
specific features. As CONFIG_SH4 is only used to select
peripherals, rename it CONFIG_SH4_PERIPHERALS.


PERIPHERALS is a bit long and hard to write correctly. How about 
CONFIG_SH4_DEVICES (also in other patches you do the same).


Regards,
BALATON Zoltan


Signed-off-by: Philippe Mathieu-Daudé 
---
hw/block/meson.build | 2 +-
hw/char/meson.build  | 2 +-
hw/intc/meson.build  | 2 +-
hw/sh4/Kconfig   | 6 +++---
hw/timer/meson.build | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/block/meson.build b/hw/block/meson.build
index 602ca6c8541..7f24b42c283 100644
--- a/hw/block/meson.build
+++ b/hw/block/meson.build
@@ -12,7 +12,7 @@
softmmu_ss.add(when: 'CONFIG_SSI_M25P80', if_true: files('m25p80.c'))
softmmu_ss.add(when: 'CONFIG_SWIM', if_true: files('swim.c'))
softmmu_ss.add(when: 'CONFIG_XEN', if_true: files('xen-block.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('tc58128.c'))
+softmmu_ss.add(when: 'CONFIG_SH4_PERIPHERALS', if_true: files('tc58128.c'))
softmmu_ss.add(when: 'CONFIG_NVME_PCI', if_true: files('nvme.c', 'nvme-ns.c'))

specific_ss.add(when: 'CONFIG_VIRTIO_BLK', if_true: files('virtio-blk.c'))
diff --git a/hw/char/meson.build b/hw/char/meson.build
index 196ac91fa29..3b8cb6a2f5b 100644
--- a/hw/char/meson.build
+++ b/hw/char/meson.build
@@ -31,7 +31,7 @@
softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_aux.c'))
softmmu_ss.add(when: 'CONFIG_RENESAS_SCI', if_true: files('renesas_sci.c'))
softmmu_ss.add(when: 'CONFIG_SIFIVE_UART', if_true: files('sifive_uart.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_serial.c'))
+softmmu_ss.add(when: 'CONFIG_SH4_PERIPHERALS', if_true: files('sh_serial.c'))
softmmu_ss.add(when: 'CONFIG_STM32F2XX_USART', if_true: 
files('stm32f2xx_usart.c'))
softmmu_ss.add(when: 'CONFIG_MCHP_PFSOC_MMUART', if_true: 
files('mchp_pfsoc_mmuart.c'))

diff --git a/hw/intc/meson.build b/hw/intc/meson.build
index 53cba115690..b05bab2f4b6 100644
--- a/hw/intc/meson.build
+++ b/hw/intc/meson.build
@@ -47,7 +47,7 @@
specific_ss.add(when: 'CONFIG_RX_ICU', if_true: files('rx_icu.c'))
specific_ss.add(when: 'CONFIG_S390_FLIC', if_true: files('s390_flic.c'))
specific_ss.add(when: 'CONFIG_S390_FLIC_KVM', if_true: files('s390_flic_kvm.c'))
-specific_ss.add(when: 'CONFIG_SH4', if_true: files('sh_intc.c'))
+specific_ss.add(when: 'CONFIG_SH4_PERIPHERALS', if_true: files('sh_intc.c'))
specific_ss.add(when: 'CONFIG_SIFIVE_CLINT', if_true: files('sifive_clint.c'))
specific_ss.add(when: 'CONFIG_SIFIVE_PLIC', if_true: files('sifive_plic.c'))
specific_ss.add(when: 'CONFIG_XICS', if_true: files('xics.c'))
diff --git a/hw/sh4/Kconfig b/hw/sh4/Kconfig
index 4cbce3a0ed5..fbac8c09152 100644
--- a/hw/sh4/Kconfig
+++ b/hw/sh4/Kconfig
@@ -9,16 +9,16 @@ config R2D
select USB_OHCI_PCI
select PCI
select SM501
-select SH4
+select SH4_PERIPHERALS

config SHIX
bool
select SH7750
-select SH4
+select SH4_PERIPHERALS

config SH7750
bool

-config SH4
+config SH4_PERIPHERALS
bool
select PTIMER
diff --git a/hw/timer/meson.build b/hw/timer/meson.build
index be343f68fed..d3f53dce400 100644
--- a/hw/timer/meson.build
+++ b/hw/timer/meson.build
@@ -30,7 +30,7 @@
softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_ost.c'))
softmmu_ss.add(when: 'CONFIG_PXA2XX', if_true: files('pxa2xx_timer.c'))
softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_systmr.c'))
-softmmu_ss.add(when: 'CONFIG_SH4', if_true: files('sh_timer.c'))
+softmmu_ss.add(when: 'CONFIG_SH4_PERIPHERALS', if_true: files('sh_timer.c'))
softmmu_ss.add(when: 'CONFIG_SLAVIO', if_true: files('slavio_timer.c'))
softmmu_ss.add(when: 'CONFIG_STM32F2XX_TIMER', if_true: 
files('stm32f2xx_timer.c'))
softmmu_ss.add(when: 'CONFIG_XILINX', if_true: files('xilinx_timer.c'))


Re: [PATCH v6 06/11] target/arm: Restrict ARMv7 R-profile cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 12:50 PM, Philippe Mathieu-Daudé wrote:
> KVM requires the target cpu to be at least ARMv8 architecture
> (support on ARMv7 has been dropped in commit 82bf7ae84ce:
> "target/arm: Remove KVM support for 32-bit Arm hosts").
> 
> Beside, KVM only supports A-profile, thus won't be able to run
> R-profile cpus.
> 
> Only enable the following ARMv7 R-Profile CPUs when TCG is available:
> 
>   - Cortex-R5
>   - Cortex-R5F
> 
> The following machine is no more built when TCG is disabled:
> 
>   - xlnx-zcu102  Xilinx ZynqMP ZCU102 board with 4xA53s and 2xR5Fs
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  default-configs/devices/aarch64-softmmu.mak | 1 -
>  hw/arm/Kconfig  | 2 ++
>  target/arm/Kconfig  | 4 
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/default-configs/devices/aarch64-softmmu.mak 
> b/default-configs/devices/aarch64-softmmu.mak
> index 958b1e08e40..a4202f56817 100644
> --- a/default-configs/devices/aarch64-softmmu.mak
> +++ b/default-configs/devices/aarch64-softmmu.mak
> @@ -3,6 +3,5 @@
>  # We support all the 32 bit boards so need all their config
>  include arm-softmmu.mak
>  
> -CONFIG_XLNX_ZYNQMP_ARM=y
>  CONFIG_XLNX_VERSAL=y
>  CONFIG_SBSA_REF=y
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 6c4bce4d637..4baf1f97694 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -360,8 +360,10 @@ config STM32F405_SOC
>  
>  config XLNX_ZYNQMP_ARM
>  bool
> +default y if TCG && ARM

The correct line is:

  "default y if TCG && AARCH64"

>  select AHCI
>  select ARM_GIC
> +select ARM_V7R
>  select CADENCE
>  select DDC
>  select DPCD
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> index fbb7bba9018..4dc96c46520 100644
> --- a/target/arm/Kconfig
> +++ b/target/arm/Kconfig
> @@ -18,6 +18,10 @@ config ARM_V6
>  bool
>  depends on TCG && ARM
>  
> +config ARM_V7R
> +bool
> +depends on TCG && ARM
> +
>  config ARM_V7M
>  bool
>  select PTIMER
> 




Re: [PATCH 05/10] meson: Introduce target-specific Kconfig

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 12:13 PM, Philippe Mathieu-Daudé wrote:
> Add a target-specific Kconfig.
> 
> Target foo now has CONFIG_FOO defined.
> 
> Two architecture have a particularity, ARM and MIPS:
> their 64-bit version include the 32-bit subset.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
...

> diff --git a/meson.build b/meson.build
> index f00b7754fd4..a2dda0ce95e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1322,7 +1322,8 @@
>command: [minikconf,
>  get_option('default_devices') ? '--defconfig' : 
> '--allnoconfig',
>  config_devices_mak, '@DEPFILE@', '@INPUT@',
> -host_kconfig, accel_kconfig])
> +host_kconfig, accel_kconfig,
> +'CONFIG_' + config_target['TARGET_ARCH'].to_upper() + '=y'])
>  
>  config_devices_data = configuration_data()
>  config_devices = keyval.load(config_devices_mak)
> diff --git a/Kconfig b/Kconfig
> index bf694c42afe..c01e261e4e9 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -1,4 +1,5 @@
>  source Kconfig.host
>  source backends/Kconfig
>  source accel/Kconfig
> +source target/Kconfig
>  source hw/Kconfig
> diff --git a/target/Kconfig b/target/Kconfig
> new file mode 100644
> index 000..a6f719f223a
> --- /dev/null
> +++ b/target/Kconfig
> @@ -0,0 +1,23 @@
> +source alpha/Kconfig
> +source arm/Kconfig
> +source avr/Kconfig
> +source cris/Kconfig
> +source hppa/Kconfig
> +source i386/Kconfig
> +source lm32/Kconfig
> +source m68k/Kconfig
> +source microblaze/Kconfig
> +source mips/Kconfig
> +source moxie/Kconfig
> +source nios2/Kconfig
> +source openrisc/Kconfig
> +source ppc/Kconfig
> +source riscv/Kconfig
> +source rx/Kconfig
> +source s390x/Kconfig
> +source sh4/Kconfig
> +source sparc/Kconfig
> +source tilegx/Kconfig
> +source tricore/Kconfig
> +source unicore32/Kconfig
> +source xtensa/Kconfig
> diff --git a/target/arm/Kconfig b/target/arm/Kconfig
> new file mode 100644
> index 000..3f3394a22b2
> --- /dev/null
> +++ b/target/arm/Kconfig
> @@ -0,0 +1,6 @@
> +config ARM
> +bool
> +
> +config AARCH64
> +bool
> +select ARM

This isn't correct yet, as Kconfig is primarly designed for devices,
and per docs/devel/kconfig.rst:

  "devices are usually ``default y`` if and only if they have at
   least one ``depends on``;"

So having one machine "depends on AARCH64" selects AARCH64 on ARM :/
I'll see if explicit each arch as 'default n' helps...



Re: [PATCH v2 6/7] hw/arm/xlnx-zcu102: Restrict ZynqMP ZCU102 board to 64-bit build

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 11:59 AM, Philippe Mathieu-Daudé wrote:
> The ZynqMP ZCU102 board only use the Cortex-A53 CPU, which
> is only available in the 64-bit build. It is pointless to
> have this board present in the 32-bit build where this CPU
> is not available.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Cc: Alistair Francis 
> Cc: "Edgar E. Iglesias" 
> ---
>  hw/arm/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/meson.build b/hw/arm/meson.build
> index 059ff7382f2..345099f5a1b 100644
> --- a/hw/arm/meson.build
> +++ b/hw/arm/meson.build
> @@ -41,7 +41,7 @@
>  arm_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_peripherals.c', 
> 'bcm2836.c', 'raspi.c'))
>  arm_ss.add(when: 'CONFIG_STM32F205_SOC', if_true: files('stm32f205_soc.c'))
>  arm_ss.add(when: 'CONFIG_STM32F405_SOC', if_true: files('stm32f405_soc.c'))
> -arm_ss.add(when: 'CONFIG_XLNX_ZYNQMP_ARM', if_true: files('xlnx-zynqmp.c', 
> 'xlnx-zcu102.c'))
> +arm_ss.add(when: ['CONFIG_XLNX_ZYNQMP_ARM', 'TARGET_AARCH64'], if_true: 
> files('xlnx-zynqmp.c', 'xlnx-zcu102.c'))

Please disregard this patch, it shows that my other patch
"meson: Introduce target-specific Kconfig" is incorrect:
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07989.html
Probably because per docs/devel/kconfig.rst "devices are usually
``default y`` if and only if they have at least one ``depends on``".

I'll try another approach such:

-- >8 --
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -389,6 +391,8 @@ config XLNX_ZYNQMP_ARM

 config XLNX_VERSAL
 bool
+default y
+depends on AARCH64
 select ARM_GIC
 select PL011
 select CADENCE
---



Re: [PATCH v2 5/7] hw/arm/sbsa-ref: Restrict SBSA-ref board to 64-bit build

2021-01-31 Thread Philippe Mathieu-Daudé
On 1/31/21 11:59 AM, Philippe Mathieu-Daudé wrote:
> The SBSA-ref board only use CPUs available in the 64-bit build,
> it is pointless to have it available in the 32-bit build.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Cc: Radoslaw Biernacki 
> Cc: Leif Lindholm 
> ---
>  hw/arm/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/meson.build b/hw/arm/meson.build
> index be39117b9b6..059ff7382f2 100644
> --- a/hw/arm/meson.build
> +++ b/hw/arm/meson.build
> @@ -22,7 +22,7 @@
>  arm_ss.add(when: 'CONFIG_TOSA', if_true: files('tosa.c'))
>  arm_ss.add(when: 'CONFIG_Z2', if_true: files('z2.c'))
>  arm_ss.add(when: 'CONFIG_REALVIEW', if_true: files('realview.c'))
> -arm_ss.add(when: 'CONFIG_SBSA_REF', if_true: files('sbsa-ref.c'))
> +arm_ss.add(when: ['CONFIG_SBSA_REF', 'TARGET_AARCH64'], if_true: 
> files('sbsa-ref.c'))

Please disregard this patch, it shows that my other patch
"meson: Introduce target-specific Kconfig" is incorrect:
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07989.html
Probably because per docs/devel/kconfig.rst "devices are usually
``default y`` if and only if they have at least one ``depends on``".

I'll try another approach such:

-- >8 --
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -227,6 +227,8 @@ config REALVIEW

 config SBSA_REF
 bool
+default y
+depends on AARCH64
 imply PCI_DEVICES
 select AHCI
 select ARM_SMMUV3
---



Re: [PATCH] hw/intc/arm_gic: Fix interrupt ID in GICD_SGIR register

2021-01-31 Thread P J P
+-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
| > Per the ARM Generic Interrupt Controller Architecture specification
| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
| > not 10:
| > 
| > - Table 4-21 GICD_SGIR bit assignments
| > 
| > The Interrupt ID of the SGI to forward to the specified CPU
| > interfaces. The value of this field is the Interrupt ID, in
| > the range 0-15, for example a value of 0b0011 specifies
| > Interrupt ID 3.
| > 
| > diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
| > index af41e2fb448..75316329516 100644
| > --- a/hw/intc/arm_gic.c
| > +++ b/hw/intc/arm_gic.c
| > @@ -1476,7 +1476,7 @@ static void gic_dist_writel(void *opaque, hwaddr 
offset,
| >  int target_cpu;
| >  
| >  cpu = gic_get_current_cpu(s);
| > -irq = value & 0x3ff;
| > +irq = value & 0xf;
| >  switch ((value >> 24) & 3) {
| >  case 0:
| >  mask = (value >> 16) & ALL_CPU_MASK;
| > 

* Looks okay.


| > Correct the irq mask to fix an undefined behavior (which eventually
| > lead to a heap-buffer-overflow, see [Buglink]):
| > 
| >$ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M 
virt,accel=qtest -qtest stdio
| >[I 1612088147.116987] OPENED
| >   [R +0.278293] writel 0x8000f00 0xff4affb0
| >   ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for 
type 'uint8_t [16][8]'
| >   SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
../hw/intc/arm_gic.c:1498:13
| > 
| > Cc: qemu-sta...@nongnu.org
| > Fixes: 9ee6e8bb853 ("ARMv7 support.")
| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
| 
| > ---
| > Isnt it worth a CVE to help distributions track backports?
| > ---

* Please send such report(s) to 'qemu-security' list to be triaged as 
  potential security ones.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

[PATCH v6 11/11] .travis.yml: Add a KVM-only Aarch64 job

2021-01-31 Thread Philippe Mathieu-Daudé
From: Philippe Mathieu-Daudé 

Add a job to build QEMU on Aarch64 with TCG disabled, so
this configuration won't bitrot over time.

We explicitly modify default-configs/aarch64-softmmu.mak to
only select the 'virt' and 'SBSA-REF' machines.

Signed-off-by: Philippe Mathieu-Daudé 
---
Job ran for 7 min 30 sec
https://travis-ci.org/github/philmd/qemu/jobs/731428859
---
 .travis.yml | 32 
 1 file changed, 32 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 5f1dea873ec..4f1d662b5fc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -264,6 +264,38 @@ jobs:
 - CONFIG="--disable-containers --target-list=${MAIN_SOFTMMU_TARGETS}"
 - UNRELIABLE=true
 
+- name: "[aarch64] GCC (disable-tcg)"
+  arch: arm64
+  dist: focal
+  addons:
+apt_packages:
+  - libaio-dev
+  - libattr1-dev
+  - libbrlapi-dev
+  - libcap-ng-dev
+  - libgcrypt20-dev
+  - libgnutls28-dev
+  - libgtk-3-dev
+  - libiscsi-dev
+  - liblttng-ust-dev
+  - libncurses5-dev
+  - libnfs-dev
+  - libnss3-dev
+  - libpixman-1-dev
+  - libpng-dev
+  - librados-dev
+  - libsdl2-dev
+  - libseccomp-dev
+  - liburcu-dev
+  - libusb-1.0-0-dev
+  - libvdeplug-dev
+  - libvte-2.91-dev
+  - ninja-build
+  env:
+- CONFIG="--disable-containers --disable-tcg --enable-kvm 
--disable-xen --disable-tools --disable-docs"
+- TEST_CMD="make check-unit"
+- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-aarch64"
+
 - name: "[ppc64] GCC check-tcg"
   arch: ppc64le
   dist: focal
-- 
2.26.2




[PATCH v6 10/11] target/arm: Do not build TCG objects when TCG is off

2021-01-31 Thread Philippe Mathieu-Daudé
From: Samuel Ortiz 

We can now safely turn all TCG dependent build off when CONFIG_TCG is
off. This allows building ARM binaries with --disable-tcg.

Signed-off-by: Samuel Ortiz 
[PMD: Heavily rebased during more than 2 years then finally rewritten]
Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/meson.build | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target/arm/meson.build b/target/arm/meson.build
index aac9a383a61..11b7c0e18fe 100644
--- a/target/arm/meson.build
+++ b/target/arm/meson.build
@@ -27,7 +27,8 @@
   'gdbstub64.c',
 ))
 
-arm_ss.add(files(
+arm_tcg_ss = ss.source_set()
+arm_tcg_ss.add(files(
   'crypto_helper.c',
   'debug_helper.c',
   'iwmmxt_helper.c',
@@ -38,12 +39,12 @@
   'vec_helper.c',
   'cpu_tcg.c',
 ))
-arm_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('m_helper.c'), if_false: 
files('m_helper-stub.c'))
+arm_tcg_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('m_helper.c'), if_false: 
files('m_helper-stub.c'))
 arm_ss.add(when: 'CONFIG_TCG', if_false: files('m_helper-stub.c'))
 
 arm_ss.add(when: 'CONFIG_KVM', if_true: files('kvm.c', 'kvm64.c'), if_false: 
files('kvm-stub.c'))
 
-arm_ss.add(when: 'TARGET_AARCH64', if_true: files(
+arm_tcg_ss.add(when: 'TARGET_AARCH64', if_true: files(
   'helper-a64.c',
   'mte_helper.c',
   'pauth_helper.c',
@@ -52,14 +53,16 @@
   'translate-sve.c',
 ))
 
+arm_ss.add_all(when: 'CONFIG_TCG', if_true: arm_tcg_ss)
+
 arm_softmmu_ss = ss.source_set()
 arm_softmmu_ss.add(files(
   'arch_dump.c',
   'arm-powerctl.c',
   'machine.c',
   'monitor.c',
-  'psci.c',
 ))
+arm_softmmu_ss.add(when: 'CONFIG_TCG', if_true: files('psci.c'))
 
 target_arch += {'arm': arm_ss}
 target_softmmu_arch += {'arm': arm_softmmu_ss}
-- 
2.26.2




Re: [PATCH v6 11/11] .travis.yml: Add a KVM-only Aarch64 job

2021-01-31 Thread Philippe Mathieu-Daudé
On Sun, Jan 31, 2021 at 12:51 PM Philippe Mathieu-Daudé  wrote:
>
> From: Philippe Mathieu-Daudé 
>
> Add a job to build QEMU on Aarch64 with TCG disabled, so
> this configuration won't bitrot over time.
>
> We explicitly modify default-configs/aarch64-softmmu.mak to
> only select the 'virt' and 'SBSA-REF' machines.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Job ran for 7 min 30 sec
> https://travis-ci.org/github/philmd/qemu/jobs/731428859

BTW I added this patch for completeness but I couldn't test it again
as I don't have anymore Travis-CI credit. I however tested it on a similar
Ubuntu Aarch64 host.



[PATCH v6 05/11] target/arm: Restrict ARMv6 cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

Only enable the following ARMv6 CPUs when TCG is available:

  - ARM1136
  - ARM1176
  - ARM11MPCore
  - Cortex-M0

The following machines are no more built when TCG is disabled:

  - kzm  ARM KZM Emulation Baseboard (ARM1136)
  - microbit BBC micro:bit (Cortex-M0)
  - n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
  - n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
  - realview-eb-mpcore   ARM RealView Emulation Baseboard (ARM11MPCore)

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/arm-softmmu.mak | 2 --
 hw/arm/realview.c   | 2 +-
 tests/qtest/cdrom-test.c| 2 +-
 hw/arm/Kconfig  | 6 ++
 target/arm/Kconfig  | 4 
 5 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0aad35da0c4..175530595ce 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -10,9 +10,7 @@ CONFIG_ARM_VIRT=y
 CONFIG_CUBIEBOARD=y
 CONFIG_EXYNOS4=y
 CONFIG_HIGHBANK=y
-CONFIG_FSL_IMX31=y
 CONFIG_MUSCA=y
-CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
 CONFIG_VEXPRESS=y
diff --git a/hw/arm/realview.c b/hw/arm/realview.c
index 2dcf0a4c23e..0606d22da14 100644
--- a/hw/arm/realview.c
+++ b/hw/arm/realview.c
@@ -463,8 +463,8 @@ static void realview_machine_init(void)
 {
 if (tcg_builtin()) {
 type_register_static(_eb_type);
+type_register_static(_eb_mpcore_type);
 }
-type_register_static(_eb_mpcore_type);
 type_register_static(_pb_a8_type);
 type_register_static(_pbx_a9_type);
 }
diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
index 1f1bc26fa7a..cb0409c5a11 100644
--- a/tests/qtest/cdrom-test.c
+++ b/tests/qtest/cdrom-test.c
@@ -224,8 +224,8 @@ int main(int argc, char **argv)
 const char *armmachines[] = {
 #ifdef CONFIG_TCG
 "realview-eb",
-#endif /* CONFIG_TCG */
 "realview-eb-mpcore",
+#endif /* CONFIG_TCG */
 "realview-pb-a8",
 "realview-pbx-a9", "versatileab", "versatilepb", "vexpress-a15",
 "vexpress-a9", "virt", NULL
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 560442bfc5c..6c4bce4d637 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -123,6 +123,8 @@ config NETDUINOPLUS2
 
 config NSERIES
 bool
+default y if TCG && ARM
+select ARM_V6
 select OMAP
 select TMP105   # tempature sensor
 select BLIZZARD # LCD/TV controller
@@ -401,6 +403,8 @@ config FSL_IMX25
 
 config FSL_IMX31
 bool
+default y if TCG && ARM
+select ARM_V6
 select SERIAL
 select IMX
 select IMX_I2C
@@ -478,11 +482,13 @@ config FSL_IMX6UL
 
 config MICROBIT
 bool
+default y if TCG && ARM
 select NRF51_SOC
 
 config NRF51_SOC
 bool
 select I2C
+select ARM_V6
 select ARM_V7M
 select UNIMP
 
diff --git a/target/arm/Kconfig b/target/arm/Kconfig
index 9b3635617dc..fbb7bba9018 100644
--- a/target/arm/Kconfig
+++ b/target/arm/Kconfig
@@ -14,6 +14,10 @@ config ARM_V5
 bool
 depends on TCG && ARM
 
+config ARM_V6
+bool
+depends on TCG && ARM
+
 config ARM_V7M
 bool
 select PTIMER
-- 
2.26.2




[PATCH v6 09/11] target/arm: Reorder meson.build rules

2021-01-31 Thread Philippe Mathieu-Daudé
From: Philippe Mathieu-Daudé 

Reorder the rules to make this file easier to modify.
No logical change introduced in this commit.

Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/meson.build | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/target/arm/meson.build b/target/arm/meson.build
index 6c6081966cd..aac9a383a61 100644
--- a/target/arm/meson.build
+++ b/target/arm/meson.build
@@ -14,31 +14,36 @@
 
 arm_ss = ss.source_set()
 arm_ss.add(gen)
+arm_ss.add(zlib)
 arm_ss.add(files(
   'cpu.c',
-  'crypto_helper.c',
-  'debug_helper.c',
   'gdbstub.c',
   'helper.c',
+  'vfp_helper.c',
+))
+
+arm_ss.add(when: 'TARGET_AARCH64', if_true: files(
+  'cpu64.c',
+  'gdbstub64.c',
+))
+
+arm_ss.add(files(
+  'crypto_helper.c',
+  'debug_helper.c',
   'iwmmxt_helper.c',
   'neon_helper.c',
   'op_helper.c',
   'tlb_helper.c',
   'translate.c',
   'vec_helper.c',
-  'vfp_helper.c',
   'cpu_tcg.c',
 ))
-arm_ss.add(zlib)
-
 arm_ss.add(when: 'CONFIG_ARM_V7M', if_true: files('m_helper.c'), if_false: 
files('m_helper-stub.c'))
 arm_ss.add(when: 'CONFIG_TCG', if_false: files('m_helper-stub.c'))
 
 arm_ss.add(when: 'CONFIG_KVM', if_true: files('kvm.c', 'kvm64.c'), if_false: 
files('kvm-stub.c'))
 
 arm_ss.add(when: 'TARGET_AARCH64', if_true: files(
-  'cpu64.c',
-  'gdbstub64.c',
   'helper-a64.c',
   'mte_helper.c',
   'pauth_helper.c',
-- 
2.26.2




[PATCH v6 08/11] target/arm: Make m_helper.c optional via CONFIG_ARM_V7M

2021-01-31 Thread Philippe Mathieu-Daudé
From: Thomas Huth 

We've already got the CONFIG_ARM_V7M switch, but it currently can
not be disabled yet. The m_helper.c code should not be compiled
into the binary if the switch is not enabled. We also have to
provide some stubs in a separate file to make sure that we still
can link the other code without CONFIG_ARM_V7M.

Signed-off-by: Thomas Huth 
Message-Id: <20190903154810.27365-4-th...@redhat.com>
[PMD: Keep m_helper-stub.c but extend it, rewrite the rest]
Signed-off-by: Philippe Mathieu-Daudé 
---
Rewrite since v3, therefore removed Richard R-b tag.
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/arm/cpu.h   | 12 ---
 target/arm/cpu_tcg.c   |  4 ++-
 target/arm/helper.c|  7 
 target/arm/m_helper-stub.c | 73 ++
 target/arm/meson.build |  4 ++-
 5 files changed, 79 insertions(+), 21 deletions(-)
 create mode 100644 target/arm/m_helper-stub.c

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index d080239863c..0bd0e51e498 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2281,12 +2281,6 @@ uint32_t arm_phys_excp_target_el(CPUState *cs, uint32_t 
excp_idx,
 /* Interface between CPU and Interrupt controller.  */
 #ifndef CONFIG_USER_ONLY
 bool armv7m_nvic_can_take_pending_exception(void *opaque);
-#else
-static inline bool armv7m_nvic_can_take_pending_exception(void *opaque)
-{
-return true;
-}
-#endif
 /**
  * armv7m_nvic_set_pending: mark the specified exception as pending
  * @opaque: the NVIC
@@ -2392,13 +2386,7 @@ int armv7m_nvic_raw_execution_priority(void *opaque);
  * @secure: the security state to test
  * This corresponds to the pseudocode IsReqExecPriNeg().
  */
-#ifndef CONFIG_USER_ONLY
 bool armv7m_nvic_neg_prio_requested(void *opaque, bool secure);
-#else
-static inline bool armv7m_nvic_neg_prio_requested(void *opaque, bool secure)
-{
-return false;
-}
 #endif
 
 /* Interface for defining coprocessor registers.
diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
index 98544db2df3..3e1c9b40353 100644
--- a/target/arm/cpu_tcg.c
+++ b/target/arm/cpu_tcg.c
@@ -15,6 +15,7 @@
 /* CPU models. These are not needed for the AArch64 linux-user build. */
 #if !defined(CONFIG_USER_ONLY) || !defined(TARGET_AARCH64)
 
+#ifndef CONFIG_USER_ONLY
 static bool arm_v7m_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
 {
 CPUClass *cc = CPU_GET_CLASS(cs);
@@ -38,6 +39,7 @@ static bool arm_v7m_cpu_exec_interrupt(CPUState *cs, int 
interrupt_request)
 }
 return ret;
 }
+#endif /* CONFIG_USER_ONLY */
 
 static void arm926_initfn(Object *obj)
 {
@@ -666,9 +668,9 @@ static void arm_v7m_class_init(ObjectClass *oc, void *data)
 acc->info = data;
 #ifndef CONFIG_USER_ONLY
 cc->do_interrupt = arm_v7m_cpu_do_interrupt;
+cc->cpu_exec_interrupt = arm_v7m_cpu_exec_interrupt;
 #endif
 
-cc->cpu_exec_interrupt = arm_v7m_cpu_exec_interrupt;
 cc->gdb_core_xml_file = "arm-m-profile.xml";
 }
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 47e266d7e64..fe3d0291f9c 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -12825,13 +12825,6 @@ int arm_mmu_idx_to_el(ARMMMUIdx mmu_idx)
 }
 }
 
-#ifndef CONFIG_TCG
-ARMMMUIdx arm_v7m_mmu_idx_for_secstate(CPUARMState *env, bool secstate)
-{
-g_assert_not_reached();
-}
-#endif
-
 ARMMMUIdx arm_mmu_idx_el(CPUARMState *env, int el)
 {
 ARMMMUIdx idx;
diff --git a/target/arm/m_helper-stub.c b/target/arm/m_helper-stub.c
new file mode 100644
index 000..6d751424e86
--- /dev/null
+++ b/target/arm/m_helper-stub.c
@@ -0,0 +1,73 @@
+/*
+ * ARM V7M related stubs.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "exec/helper-proto.h"
+#include "internals.h"
+
+void HELPER(v7m_bxns)(CPUARMState *env, uint32_t dest)
+{
+g_assert_not_reached();
+}
+
+void HELPER(v7m_blxns)(CPUARMState *env, uint32_t dest)
+{
+g_assert_not_reached();
+}
+
+uint32_t HELPER(v7m_mrs)(CPUARMState *env, uint32_t reg)
+{
+g_assert_not_reached();
+}
+
+void HELPER(v7m_msr)(CPUARMState *env, uint32_t maskreg, uint32_t val)
+{
+g_assert_not_reached();
+}
+
+uint32_t HELPER(v7m_tt)(CPUARMState *env, uint32_t addr, uint32_t op)
+{
+g_assert_not_reached();
+}
+
+void HELPER(v7m_preserve_fp_state)(CPUARMState *env)
+{
+g_assert_not_reached();
+}
+
+void write_v7m_exception(CPUARMState *env, uint32_t new_exc)
+{
+g_assert_not_reached();
+}
+
+void HELPER(v7m_vlldm)(CPUARMState *env, uint32_t fptr)
+{
+g_assert_not_reached();
+}
+
+void HELPER(v7m_vlstm)(CPUARMState *env, uint32_t fptr)
+{
+g_assert_not_reached();
+}
+
+ARMMMUIdx arm_v7m_mmu_idx_for_secstate(CPUARMState *env, bool secstate)
+{
+g_assert_not_reached();
+}
+
+#ifndef CONFIG_USER_ONLY
+
+bool armv7m_nvic_can_take_pending_exception(void *opaque)
+{
+g_assert_not_reached();
+}
+
+void arm_v7m_cpu_do_interrupt(CPUState *cs)
+{
+g_assert_not_reached();
+}
+
+#endif /* CONFIG_USER_ONLY */
diff --git 

[PATCH v6 03/11] target/arm: Restrict ARMv4 cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

Only enable the following ARMv4 CPUs when TCG is available:

  - StrongARM (SA1100/1110)
  - OMAP1510 (TI925T)

The following machines are no more built when TCG is disabled:

  - cheetah  Palm Tungsten|E aka. Cheetah PDA (OMAP310)
  - sx1  Siemens SX1 (OMAP310) V2
  - sx1-v1   Siemens SX1 (OMAP310) V1

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/arm-softmmu.mak | 2 --
 hw/arm/Kconfig  | 4 
 target/arm/Kconfig  | 4 
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 0824e9be795..6ae964c14fd 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -14,8 +14,6 @@ CONFIG_INTEGRATOR=y
 CONFIG_FSL_IMX31=y
 CONFIG_MUSICPAL=y
 CONFIG_MUSCA=y
-CONFIG_CHEETAH=y
-CONFIG_SX1=y
 CONFIG_NSERIES=y
 CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index f3ecb73a3d8..f2957b33bee 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -31,6 +31,8 @@ config ARM_VIRT
 
 config CHEETAH
 bool
+default y if TCG && ARM
+select ARM_V4
 select OMAP
 select TSC210X
 
@@ -249,6 +251,8 @@ config COLLIE
 
 config SX1
 bool
+default y if TCG && ARM
+select ARM_V4
 select OMAP
 
 config VERSATILE
diff --git a/target/arm/Kconfig b/target/arm/Kconfig
index ae89d05c7e5..811e1e81652 100644
--- a/target/arm/Kconfig
+++ b/target/arm/Kconfig
@@ -6,6 +6,10 @@ config AARCH64
 bool
 select ARM
 
+config ARM_V4
+bool
+depends on TCG && ARM
+
 config ARM_V7M
 bool
 select PTIMER
-- 
2.26.2




[PATCH v6 07/11] target/arm: Restrict ARMv7 M-profile cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

Beside, KVM only supports A-profile, thus won't be able to run
M-profile cpus.

Only enable the following ARMv7 M-Profile CPUs when TCG is available:

  - Cortex-M0
  - Cortex-M3
  - Cortex-M4
  - Cortex-M33

The following machines are no more built when TCG is disabled:

  - emcraft-sf2  SmartFusion2 SOM kit from Emcraft (M2S010)
  - highbank Calxeda Highbank (ECX-1000)
  - lm3s6965evb  Stellaris LM3S6965EVB (Cortex-M3)
  - lm3s811evb   Stellaris LM3S811EVB (Cortex-M3)
  - midway   Calxeda Midway (ECX-2000)
  - mps2-an385   ARM MPS2 with AN385 FPGA image for Cortex-M3
  - mps2-an386   ARM MPS2 with AN386 FPGA image for Cortex-M4
  - mps2-an500   ARM MPS2 with AN500 FPGA image for Cortex-M7
  - mps2-an505   ARM MPS2 with AN505 FPGA image for Cortex-M33
  - mps2-an511   ARM MPS2 with AN511 DesignStart FPGA image for 
Cortex-M3
  - mps2-an521   ARM MPS2 with AN521 FPGA image for dual Cortex-M33
  - musca-a  ARM Musca-A board (dual Cortex-M33)
  - musca-b1 ARM Musca-B1 board (dual Cortex-M33)
  - netduino2Netduino 2 Machine (Cortex-M3)
  - netduinoplus2Netduino Plus 2 Machine(Cortex-M4)

We don't need to enforce CONFIG_ARM_V7M in default-configs anymore.

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/arm-softmmu.mak | 11 ---
 hw/arm/Kconfig  |  7 +++
 target/arm/Kconfig  |  1 +
 3 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/default-configs/devices/arm-softmmu.mak 
b/default-configs/devices/arm-softmmu.mak
index 175530595ce..0fc80d7d6df 100644
--- a/default-configs/devices/arm-softmmu.mak
+++ b/default-configs/devices/arm-softmmu.mak
@@ -1,28 +1,17 @@
 # Default configuration for arm-softmmu
 
-# TODO: ARM_V7M is currently always required - make this more flexible!
-CONFIG_ARM_V7M=y
-
 # CONFIG_PCI_DEVICES=n
 # CONFIG_TEST_DEVICES=n
 
 CONFIG_ARM_VIRT=y
 CONFIG_CUBIEBOARD=y
 CONFIG_EXYNOS4=y
-CONFIG_HIGHBANK=y
-CONFIG_MUSCA=y
-CONFIG_STELLARIS=y
 CONFIG_REALVIEW=y
 CONFIG_VEXPRESS=y
 CONFIG_ZYNQ=y
 CONFIG_NPCM7XX=y
-CONFIG_NETDUINO2=y
-CONFIG_NETDUINOPLUS2=y
-CONFIG_MPS2=y
 CONFIG_RASPI=y
 CONFIG_SABRELITE=y
-CONFIG_EMCRAFT_SF2=y
-CONFIG_MICROBIT=y
 CONFIG_FSL_IMX7=y
 CONFIG_FSL_IMX6UL=y
 CONFIG_ALLWINNER_H3=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 4baf1f97694..62f8b0d24e7 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -60,6 +60,7 @@ config EXYNOS4
 
 config HIGHBANK
 bool
+default y if TCG && ARM
 select A9MPCORE
 select A15MPCORE
 select AHCI
@@ -95,6 +96,7 @@ config MAINSTONE
 
 config MUSCA
 bool
+default y if TCG && ARM
 select ARMSSE
 select PL011
 select PL031
@@ -115,10 +117,12 @@ config MUSICPAL
 
 config NETDUINO2
 bool
+default y if TCG && ARM
 select STM32F205_SOC
 
 config NETDUINOPLUS2
 bool
+default y if TCG && ARM
 select STM32F405_SOC
 
 config NSERIES
@@ -240,6 +244,7 @@ config SABRELITE
 
 config STELLARIS
 bool
+default y if TCG && ARM
 select ARM_V7M
 select CMSDK_APB_WATCHDOG
 select I2C
@@ -443,6 +448,7 @@ config ASPEED_SOC
 
 config MPS2
 bool
+default y if TCG && ARM
 select ARMSSE
 select LAN9118
 select MPS2_FPGAIO
@@ -496,6 +502,7 @@ config NRF51_SOC
 
 config EMCRAFT_SF2
 bool
+default y if TCG && ARM
 select MSF2
 select SSI_M25P80
 
diff --git a/target/arm/Kconfig b/target/arm/Kconfig
index 4dc96c46520..07a2fad7a2b 100644
--- a/target/arm/Kconfig
+++ b/target/arm/Kconfig
@@ -24,4 +24,5 @@ config ARM_V7R
 
 config ARM_V7M
 bool
+depends on TCG && ARM
 select PTIMER
-- 
2.26.2




[PATCH v6 06/11] target/arm: Restrict ARMv7 R-profile cpus to TCG accel

2021-01-31 Thread Philippe Mathieu-Daudé
KVM requires the target cpu to be at least ARMv8 architecture
(support on ARMv7 has been dropped in commit 82bf7ae84ce:
"target/arm: Remove KVM support for 32-bit Arm hosts").

Beside, KVM only supports A-profile, thus won't be able to run
R-profile cpus.

Only enable the following ARMv7 R-Profile CPUs when TCG is available:

  - Cortex-R5
  - Cortex-R5F

The following machine is no more built when TCG is disabled:

  - xlnx-zcu102  Xilinx ZynqMP ZCU102 board with 4xA53s and 2xR5Fs

Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/devices/aarch64-softmmu.mak | 1 -
 hw/arm/Kconfig  | 2 ++
 target/arm/Kconfig  | 4 
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/default-configs/devices/aarch64-softmmu.mak 
b/default-configs/devices/aarch64-softmmu.mak
index 958b1e08e40..a4202f56817 100644
--- a/default-configs/devices/aarch64-softmmu.mak
+++ b/default-configs/devices/aarch64-softmmu.mak
@@ -3,6 +3,5 @@
 # We support all the 32 bit boards so need all their config
 include arm-softmmu.mak
 
-CONFIG_XLNX_ZYNQMP_ARM=y
 CONFIG_XLNX_VERSAL=y
 CONFIG_SBSA_REF=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 6c4bce4d637..4baf1f97694 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -360,8 +360,10 @@ config STM32F405_SOC
 
 config XLNX_ZYNQMP_ARM
 bool
+default y if TCG && ARM
 select AHCI
 select ARM_GIC
+select ARM_V7R
 select CADENCE
 select DDC
 select DPCD
diff --git a/target/arm/Kconfig b/target/arm/Kconfig
index fbb7bba9018..4dc96c46520 100644
--- a/target/arm/Kconfig
+++ b/target/arm/Kconfig
@@ -18,6 +18,10 @@ config ARM_V6
 bool
 depends on TCG && ARM
 
+config ARM_V7R
+bool
+depends on TCG && ARM
+
 config ARM_V7M
 bool
 select PTIMER
-- 
2.26.2




[PATCH v6 02/11] exec: Restrict TCG specific headers

2021-01-31 Thread Philippe Mathieu-Daudé
Fixes when building with --disable-tcg on ARM:

  In file included from target/arm/helper.c:16:
  include/exec/helper-proto.h:42:10: fatal error: tcg-runtime.h: No such file 
or directory
 42 | #include "tcg-runtime.h"
|  ^~~

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/exec/helper-proto.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/exec/helper-proto.h b/include/exec/helper-proto.h
index 659f9298e8f..740bff3bb4d 100644
--- a/include/exec/helper-proto.h
+++ b/include/exec/helper-proto.h
@@ -39,8 +39,10 @@ dh_ctype(ret) HELPER(name) (dh_ctype(t1), dh_ctype(t2), 
dh_ctype(t3), \
 
 #include "helper.h"
 #include "trace/generated-helpers.h"
+#ifdef CONFIG_TCG
 #include "tcg-runtime.h"
 #include "plugin-helpers.h"
+#endif /* CONFIG_TCG */
 
 #undef IN_HELPER_PROTO
 
-- 
2.26.2




  1   2   >