Re: USB port claiming / set configuration problems

[Ben Leslie]

On Fri, 5 Mar 2021 at 11:50, Ben Leslie  wrote:

> On Fri, 5 Mar 2021 at 01:31, Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > Would adding support to host-libusb to use these
>> > ioctl to claim the port be beneficial?
>>
>> I don't feel like side-stepping libusb.  That is asking for trouble
>> because usbdevfs might behave differently then and confuse libusb.
>>
>> So, if anything, libusb would need support that, then qemu can use it.
>>
>> > Based on a simple test program and
>> > hardware USB traces for a device connected to a 'claimed' port the
>> kernel
>> > does indeed leave the device in an unconfigured state. (Although it
>> still
>> > performs some basic control transfers to gather descriptor, and
>> strangely
>> > seems to in this case make an explicit SET CONFIGURATION transfer, but
>> sets
>> > configuration to zero, rather than an actual configuration, which, at
>> least
>> > for the devices I was able to test with, avoided the problems of calling
>> > SET CONFIGURATION (1) twice).
>>
>> We could try that too (set config to zero first, then set the config we
>> actually want) and see if that works better.
>>
>
> This approach seems to work well, and let's me just use libusb, which is a
> plus.
>
> It seems I had actually misdiagnosed (or only partially diagnosed) the
> issue
> with my 'problem devices'. It turned out that setting *any* valid
> configuration
> twice in a row causes problems for the device! So, for example, if the
> current
> configuration was set to 1, and then set configuration 2 was called that
> would
> also cause problems. I guess that drivers on other systems ensured that
> such a sequence never occurred.
>
> I reverted bfe44898848614cfcb3a269bc965afbe1f0f331c and made this change:
>
> --- a/hw/usb/host-libusb.c
> +++ b/hw/usb/host-libusb.c
> @@ -955,6 +955,11 @@ static int usb_host_open(USBHostDevice *s,
> libusb_device *dev, int hostfd)
>
>  usb_host_detach_kernel(s);
>
> +rc = libusb_set_configuration(s->dh, 0);
> +if (rc != 0) {
> +goto fail;
> +}
> +
>  libusb_get_device_descriptor(dev, >ddesc);
>  usb_host_get_port(s->dev, s->port, sizeof(s->port));
>
> This appears to work for my use cases. (Although I still have more testing
> to do).
>
> In terms of the transaction on the wire, this is not quite as good as the
> 'claim port'
> approach. Specifically, with the claim port after setting address and
> getting some
> basic descriptors the kernel will explicitly set configuration to zero and
> not perform
> any more transactions. Without the 'claim port' the kernel appears to
> configure to
> the first configuration and then read a few more descriptors. For my test
> cases
> at least this doesn't appear to be problematic, but I thought it was worth
> calling
> out the differences. Of course the great benefit of this approach is that
> it uses
> existing libusb functionality.
>
>
For the archives, unfortunately this approach did not work for my use case.
I was able to get something working using the claim port approach, but that
meant going behind the back of libusb, which is obviously not suitable to be
merged, and ends up as a reasonably sizable patch.

I'll see if there is any appetite for adding claim port functionality to
libusb
before raising it again here.

Thanks for the feedback and assistance.

Cheers,

Ben

Re: What is the intended behaviour of usb_host_get_port for root hubs?

[Ben Leslie]

On Tue, 9 Mar 2021 at 18:24, Gerd Hoffmann  wrote:

> On Tue, Mar 09, 2021 at 10:54:15AM +1100, Ben Leslie wrote:
> > When usb_host_get_port is called for a root-hub device what string should
> > be output in the port parameter?
>
> Just the port number, as string.
>
> (and in case this isn't a root port the hub port number(s) are appended,
> separated by a dot).
>
> > The current behaviour writes a string with whatever stack value happened
> to
> > be in the paths stack array.
>
> Huh?  Isn't paths updated by the libusb_get_port_numbers() call?
>

libusb_get_port_numbers() can return zero (for the root hub); or at least
it does
on the Linux systems I tried. If that happens path[0] won't be changed by
libusb_get_port_numbers. The rest of the function assumes that the path is
at least 1 item long and unconditionally access path[0], which isn't true
if a root-hub
device is passed to the function.

Of course, reading the current code more carefully, usb_host_get_port is
never
actually called with a hub device (let alone a root hub), so I guess it is
a valid
assumption that libusb_get_port_numbers will always return at least 1 in
the non-error
path. I hit the problem as I was trying to reuse the function with a hub
device, so my
bad.

Thanks,

Ben

[Bug 1918084] Re: Build fails on macOS 11.2.2

[Thomas Huth]

That looks weird, like a bug in the toolchain ... no clue how to fix
that right now, but as a work-around, you could try to disable just the
related part of the code by running configure with "--target-list-
exclude=aarch64-softmmu,aarch64_be-linux-user,aarch64-linux-user"

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

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

Title:
  Build fails on macOS 11.2.2

Status in QEMU:
  Triaged

Bug description:
  Hi,

  I got the latest version from git. I have pre-compiled the dependency
  libraries. All good. configure creates the necessary files. When I
  build I got the following error:

  [1368/6454] Compiling C object 
libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o
  ninja: build stopped: subcommand failed.
  make[1]: *** [run-ninja] Error 1
  make: *** [all] Error 2

  I've ran make as make -j 8

  original config:

  
PKG_CONFIG_PATH="$SERVERPLUS_DIR/dependencies/glib/lib/pkgconfig:$SERVERPLUS_DIR/dependencies/pixman/lib/pkgconfig:$SERVERPLUS_DIR/dependencies
  /cyrus-sasl/lib/pkgconfig" ./configure --prefix="$SERVERPLUS_DIR"
  --enable-hvf --enable-cocoa --enable-vnc-sasl --enable-auth-pam
  --ninja=/opt/build/build/stage/tools/ninja/ninja
  --python="$SERVERPLUS_DIR/dependencies/python/bin/python3" --enable-
  bsd-user

  if I build with --target-list=x86_64-softmmu then it will build but I
  will get only the x86_64 QEMU built. With 5.0 I could build all
  emulators.

  $SERVERPLUS_DIR is my target dir.

  Thanks,

  Eddy

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

[RFC 0/1] target/riscv: add RNMI support

[frank . chang]

From: Frank Chang 

This patchset add suport of Resumable NMI (RNMI) in RISC-V.

There are four new CSRs and one new instruction added to allow NMI to be
resumable in RISC-V, which are:

=
  * mnscratch (0x350)
  * mnepc (0x351)
  * mncause   (0x352)
  * mnstatus  (0x353)
=
  * mnret: To return from RNMI interrupt/exception handler.
=

RNMI also has higher priority than any other interrupts or exceptions
and cannot be disable by software.

RNMI may be used to route to other devices such as Bus Error Unit or
Watchdog Timer in the future.

The interrupt/exception trap handler addresses of RNMI are
implementation defined.

The technical proposal of RNMI can be found:
https://lists.riscv.org/g/tech-privileged/message/421

The port is available here:
https://github.com/sifive/qemu/tree/nmi-upstream-v1

To enable RNMI feature, add cpu argument: 'rnmi=true' and specify
RNMI interrupt/exception handler addresses with 'rnmi_irqvec' and
'rnmi_excpvec' arguments, e.g.
-cpu rv64,rnmi=true,rnmi_irqvec=0x2000,rnmi_excpvec=0x3000

Frank Chang (1):
  target/riscv: add support of RNMI

 target/riscv/cpu.c| 40 +
 target/riscv/cpu.h| 16 -
 target/riscv/cpu_bits.h   | 19 ++
 target/riscv/cpu_helper.c | 47 +--
 target/riscv/csr.c| 59 +++
 target/riscv/helper.h |  1 +
 target/riscv/insn32.decode|  3 +
 .../riscv/insn_trans/trans_privileged.c.inc   | 13 
 target/riscv/op_helper.c  | 31 ++
 9 files changed, 224 insertions(+), 5 deletions(-)

--
2.17.1

[RFC 1/1] target/riscv: add support of RNMI

[frank . chang]

From: Frank Chang 

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c| 40 +
 target/riscv/cpu.h| 16 -
 target/riscv/cpu_bits.h   | 19 ++
 target/riscv/cpu_helper.c | 47 +--
 target/riscv/csr.c| 59 +++
 target/riscv/helper.h |  1 +
 target/riscv/insn32.decode|  3 +
 .../riscv/insn_trans/trans_privileged.c.inc   | 13 
 target/riscv/op_helper.c  | 31 ++
 9 files changed, 224 insertions(+), 5 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index ddea8fbeeb3..07ea2105200 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -137,6 +137,14 @@ static void set_feature(CPURISCVState *env, int feature)
 env->features |= (1ULL << feature);
 }
 
+static void set_rnmi_vectors(CPURISCVState *env, int irqvec, int excpvec)
+{
+#ifndef CONFIG_USER_ONLY
+env->rnmi_irqvec = irqvec;
+env->rnmi_excpvec = excpvec;
+#endif
+}
+
 static void set_resetvec(CPURISCVState *env, int resetvec)
 {
 #ifndef CONFIG_USER_ONLY
@@ -372,6 +380,23 @@ static void riscv_cpu_disas_set_info(CPUState *s, 
disassemble_info *info)
 }
 }
 
+#ifndef CONFIG_USER_ONLY
+static void riscv_cpu_set_rnmi(void *opaque, int irq, int level)
+{
+RISCVCPU *cpu = opaque;
+CPURISCVState *env = >env;
+CPUState *cs = CPU(cpu);
+
+if (level) {
+env->nmip |= 1 << irq;
+cpu_interrupt(cs, CPU_INTERRUPT_RNMI);
+} else {
+env->nmip &= ~(1 << irq);
+cpu_reset_interrupt(cs, CPU_INTERRUPT_RNMI);
+}
+}
+#endif
+
 static void riscv_cpu_realize(DeviceState *dev, Error **errp)
 {
 CPUState *cs = CPU(dev);
@@ -415,6 +440,16 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 
 set_resetvec(env, cpu->cfg.resetvec);
 
+if (cpu->cfg.rnmi) {
+set_feature(env, RISCV_FEATURE_RNMI);
+set_rnmi_vectors(env, cpu->cfg.rnmi_irqvec, cpu->cfg.rnmi_excpvec);
+#ifndef CONFIG_USER_ONLY
+env->nmie = true;
+qdev_init_gpio_in_named(DEVICE(cpu), riscv_cpu_set_rnmi,
+"rnmi", TARGET_LONG_BITS);
+#endif
+}
+
 /* If only XLEN is set for misa, then set misa from properties */
 if (env->misa == RV32 || env->misa == RV64) {
 /* Do some ISA extension error checking */
@@ -554,6 +589,11 @@ static Property riscv_cpu_properties[] = {
 DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
 DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
 DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
+DEFINE_PROP_BOOL("rnmi", RISCVCPU, cfg.rnmi, false),
+DEFINE_PROP_UINT64("rnmi_irqvec", RISCVCPU, cfg.rnmi_irqvec,
+   DEFAULT_RNMI_IRQVEC),
+DEFINE_PROP_UINT64("rnmi_excpvec", RISCVCPU, cfg.rnmi_excpvec,
+   DEFAULT_RNMI_EXCPVEC),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0edb2826a27..b9aa403dfec 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -80,7 +80,8 @@
 enum {
 RISCV_FEATURE_MMU,
 RISCV_FEATURE_PMP,
-RISCV_FEATURE_MISA
+RISCV_FEATURE_MISA,
+RISCV_FEATURE_RNMI,
 };
 
 #define PRIV_VERSION_1_10_0 0x00011000
@@ -178,6 +179,16 @@ struct CPURISCVState {
 target_ulong mcause;
 target_ulong mtval;  /* since: priv-1.10.0 */
 
+/* NMI */
+target_ulong mnscratch;
+target_ulong mnepc;
+target_ulong mncause; /* mncause without bit XLEN-1 set to 1 */
+target_ulong mnstatus;
+bool nmie;
+target_ulong nmip;
+target_ulong rnmi_irqvec;
+target_ulong rnmi_excpvec;
+
 /* Hypervisor CSRs */
 target_ulong hstatus;
 target_ulong hedeleg;
@@ -300,6 +311,9 @@ struct RISCVCPU {
 bool mmu;
 bool pmp;
 uint64_t resetvec;
+bool rnmi;
+uint64_t rnmi_irqvec;
+uint64_t rnmi_excpvec;
 } cfg;
 };
 
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index caf45992070..94ab76c66b8 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -166,6 +166,12 @@
 #define CSR_MTVAL   0x343
 #define CSR_MIP 0x344
 
+/* NMI */
+#define CSR_MNSCRATCH   0x350
+#define CSR_MNEPC   0x351
+#define CSR_MNCAUSE 0x352
+#define CSR_MNSTATUS0x353
+
 /* Legacy Machine Trap Handling (priv v1.9.1) */
 #define CSR_MBADADDR0x343
 
@@ -526,6 +532,12 @@
 /* Default Reset Vector adress */
 #define DEFAULT_RSTVEC  0x1000
 
+/* Default RNMI Interrupt Vector address */
+#define DEFAULT_RNMI_IRQVEC 0x1000
+
+/* Default RNMI Exception Vector address */
+#define DEFAULT_RNMI_EXCPVEC0x1000
+
 /* Exception causes */
 #define EXCP_NONE-1 /* sentinel value */
 #define RISCV_EXCP_INST_ADDR_MIS 0x0
@@ -552,6 +564,9 @@
 #define 

Re: [PATCH qemu v14] spapr: Implement Open Firmware client interface

[Alexey Kardashevskiy]

On 09/03/2021 16:29, David Gibson wrote:



+struct ClientArchitectureSupportClass {
+InterfaceClass parent;
+target_ulong (*cas)(CPUState *cs, target_ulong vec);
+void (*quiesce)(void);


Is there actually any real connection of quiesce behaviour to cas
behaviour?  Basically, I'm wondering if this is not so much about
client-architecture-support fundamentally as just about
machine-specific parts of the VOF behaviour.  Which would be fine, but
suggests a different name for the interface.


The most canonical way would be having 2 interfaces.


Why?  I don't see any reason these shouldn't be a single interface, it
just has a bad name.


I renamed it to SpaprVofInterface for now.



[snip]

+typedef int size_t;
+typedef void client(void);
+
+/* globals */
+extern void _prom_entry(void); /* OF CI entry point (i.e. this firmware) */
+
+void do_boot(unsigned long addr, unsigned long r3, unsigned long r4);
+
+/* libc */
+int strlen(const char *s);
+int strcmp(const char *s1, const char *s2);
+void *memcpy(void *dest, const void *src, size_t n);
+int memcmp(const void *ptr1, const void *ptr2, size_t n);
+void *memmove(void *dest, const void *src, size_t n);
+void *memset(void *dest, int c, size_t size);
+
+/* Prom */
+typedef unsigned long prom_arg_t;
+int call_prom(const char *service, int nargs, int nret, ...);


AIUI this isn't so much about calling the PROM, since this *is* the
PROM code, but rather about calling the parts that are implemented on
the qemu side.  Different names might clarify that.


"call_ci"?


Works for me.


call_ci() it is then.

About builtins such as memcmp() - turns out these are not really 
builtins as they are not inlined and gcc/ld still want to link against 
libc which is trickier for such firmware (not quite sure how to do this 
and keep it small and not pull other libc stuff in), gcc just knows 
about them a bit more. This is different from, for example, 
__builtin_ctz which is inlined. So I am keeping my libc.o for now.




--
Alexey

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

[Shenming Lu]

On 2021/3/3 5:26, Alex Williamson wrote:
> 
> MST/Marcel,
> 
> Do you have an Ack or objection to exporting msix_masked() as below?

Or could we use msix_function_masked instead as below? :-)

if (!pdev->msix_function_masked) {
for (nr = 0; nr < msix_nr_vectors_allocated(pdev); nr++) {
if (!msix_is_masked(pdev, nr)) {
max_vec = nr;
}
}
}

Thanks,
Shenming

> Thanks,
> 
> Alex
> 
> On Tue, 23 Feb 2021 10:22:25 +0800
> Shenming Lu  wrote:
> 
>> In VFIO migration resume phase and some guest startups, there are
>> already unmasked vectors in the vector table when calling
>> vfio_msix_enable(). So in order to avoid inefficiently disabling
>> and 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 |  2 +-
>>  hw/vfio/pci.c | 20 +---
>>  include/hw/pci/msix.h |  1 +
>>  3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/pci/msix.c b/hw/pci/msix.c
>> index ae9331cd0b..e057958fcd 100644
>> --- a/hw/pci/msix.c
>> +++ b/hw/pci/msix.c
>> @@ -131,7 +131,7 @@ static void msix_handle_mask_update(PCIDevice *dev, int 
>> vector, bool was_masked)
>>  }
>>  }
>>  
>> -static bool msix_masked(PCIDevice *dev)
>> +bool msix_masked(PCIDevice *dev)
>>  {
>>  return dev->config[dev->msix_cap + MSIX_CONTROL_OFFSET] & 
>> MSIX_MASKALL_MASK;
>>  }
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index f74be78209..088fd41926 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -569,6 +569,9 @@ static void vfio_msix_vector_release(PCIDevice *pdev, 
>> unsigned int nr)
>>  
>>  static void vfio_msix_enable(VFIOPCIDevice *vdev)
>>  {
>> +PCIDevice *pdev = >pdev;
>> +unsigned int nr, max_vec = 0;
>> +
>>  vfio_disable_interrupts(vdev);
>>  
>>  vdev->msi_vectors = g_new0(VFIOMSIVector, vdev->msix->entries);
>> @@ -587,11 +590,22 @@ 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 already unmasked vectors (in migration resume phase and
>> + * some guest startups) which will be enabled soon, we can allocate all
>> + * of them here to avoid inefficiently disabling and enabling vectors
>> + * repeatedly later.
>>   */
>> -vfio_msix_vector_do_use(>pdev, 0, NULL, NULL);
>> -vfio_msix_vector_release(>pdev, 0);
>> +if (!msix_masked(pdev)) {
>> +for (nr = 0; nr < msix_nr_vectors_allocated(pdev); nr++) {
>> +if (!msix_is_masked(pdev, nr)) {
>> +max_vec = nr;
>> +}
>> +}
>> +}
>> +vfio_msix_vector_do_use(pdev, max_vec, NULL, NULL);
>> +vfio_msix_vector_release(pdev, max_vec);
>>  
>> -if (msix_set_vector_notifiers(>pdev, vfio_msix_vector_use,
>> +if (msix_set_vector_notifiers(pdev, vfio_msix_vector_use,
>>vfio_msix_vector_release, NULL)) {
>>  error_report("vfio: msix_set_vector_notifiers failed");
>>  }
>> diff --git a/include/hw/pci/msix.h b/include/hw/pci/msix.h
>> index 4c4a60c739..b3cd88e262 100644
>> --- a/include/hw/pci/msix.h
>> +++ b/include/hw/pci/msix.h
>> @@ -28,6 +28,7 @@ void msix_load(PCIDevice *dev, QEMUFile *f);
>>  
>>  int msix_enabled(PCIDevice *dev);
>>  int msix_present(PCIDevice *dev);
>> +bool msix_masked(PCIDevice *dev);
>>  
>>  bool msix_is_masked(PCIDevice *dev, unsigned vector);
>>  void msix_set_pending(PCIDevice *dev, unsigned vector);
> 
> .
> 

Re: [PATCH] hw/char: disable ibex uart receive if the buffer is full

[Alexander Wagner]

On 08.03.21 14:47, Alistair Francis wrote:

  hw/char/ibex_uart.c | 20 +++-
  include/hw/char/ibex_uart.h |  4 
  2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/char/ibex_uart.c b/hw/char/ibex_uart.c
index 89f1182c9b..dac09d53d6 100644
--- a/hw/char/ibex_uart.c
+++ b/hw/char/ibex_uart.c
@@ -66,7 +66,8 @@ static int ibex_uart_can_receive(void *opaque)
  {
  IbexUartState *s = opaque;

-if (s->uart_ctrl & R_CTRL_RX_ENABLE_MASK) {
+if ((s->uart_ctrl & R_CTRL_RX_ENABLE_MASK)
+   && !(s->uart_status & R_STATUS_RXFULL_MASK)) {
  return 1;
  }

@@ -83,6 +84,8 @@ static void ibex_uart_receive(void *opaque, const uint8_t 
*buf, int size)

  s->uart_status &= ~R_STATUS_RXIDLE_MASK;
  s->uart_status &= ~R_STATUS_RXEMPTY_MASK;
+s->uart_status |= R_STATUS_RXFULL_MASK;

Doesn't this mean we set RXFULL on every receive? Shouldn't this check
the rx_level first?

Alistair


Thank you for having a look! :)

Yes, this is correct. The RXFULL is currently set on every receive. The 
RXFULL is used to indicate to QEMU that the device cannot receive any 
further bytes.


As the FIFO buffers are currently not yet implemented I thought it would 
make sense to behave like the OT UART could only receive one byte at a time.


Alex

Re: [PATCH v6 0/5] m68k: add Virtual M68k Machine

[Laurent Vivier]

Le 08/03/2021 à 23:47, Philippe Mathieu-Daudé a écrit :
> Hi Laurent,
>
> On 3/8/21 10:24 PM, Laurent Vivier wrote:
>> The Quadra 800 machine is very limited to run linux, it manages
>> only 1 GiB of memory and only some specific interfaces.
>>
>> The Virtual M68k Machine is based on Goldfish interfaces defined by Google
>> for Android simulator. It uses Goldfish-rtc (timer and RTC),
>> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
>>
>> https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFIS=
>> H-VIRTUAL-HARDWARE.TXT
>>
>> The machine is created with 128 virtio-mmio busses, and they can
>> be used to add serial console, GPU, disk, NIC, HID, ...
>>
>> This series re-use the goldfish-rtc implemented for RISCV, and
>> adds the two others based on the goldfish specs, the kernel driver
>> and android simulator ones.
>>
>> The machine can manage up to 3.2 GiB of memory, not because of an hardware
>> limitation but because the kernel crashes after this value.
>>
>> Simply configure qemu with:
>>
>> .../configure --target-list=3Dm68k-softmmu
>>
>> To run the machine you need a modified kernel you can find here:
>>
>> https://github.com/vivier/linux/tree/m68k-virt
>>
>> You need to compile the kernel with:
>>
>> make virt_defconfig
>> make vmlinux
>>
>> The disk must be installed using the q800 machine because the debian 
>> installer
>> doesn't want to be used with a kernel that is not the one on the ISO.
>>
>> And then you can run the machine with something like:
>>
>> qemu-system-m68k -M virt \
>>   -m 3399672K \
>>   -chardev stdio,signal=3Doff,mux=3Don,id=3Dchar0 \
>>   -mon chardev=3Dchar0,mode=3Dreadline \
>>   -kernel vmlinux \
>>   -append "console=3Dhvc0 root=3D/dev/vda2" \
>>   -blockdev node-name=3Dsystem,driver=3Dfile,filename=3Ddebian-10.0.qcow2 \
>>   -blockdev node-name=3Ddrive0,driver=3Dqcow2,file=3Dsystem \
>>   -device virtio-blk-device,drive=3Ddrive0 \
>>   -serial chardev:char0 \
>>   -device virtio-net-device,netdev=3Dhostnet0 \
>>   -netdev bridge,id=3Dhostnet0,br=3Dvirbr0 \
>>   -device virtio-rng-device \
>>   -device virtio-serial-device \
>>   -device virtio-gpu-device \
>>   -device virtconsole,chardev=3Dchar0 \
>>   -device virtio-keyboard-device \
>>   -device virtio-mouse-device
>>
>> if you want to use Goldfish-tty for the console rather than virtconsole, you
>> can add "console=3DttyGF".
>>
>> To start the debian-installer, you can try by adding:
>>
>>   -device virtio-scsi-device \
>>   -blockdev 
>> node-name=3Ddebian10,driver=3Dfile,filename=3Ddebian-10.0.0-m68k-=
>> NETINST-1.iso \
>>   -blockdev node-name=3Dcdrom0,driver=3Draw,file=3Ddebian10 \
>>   -device scsi-cd,drive=3Dcdrom0 \
>>   -initrd installer-m68k/20200315/images/cdrom/initrd.gz
>>
>> ISO:
>> https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-12/debian-=
>> 10.0.0-m68k-NETINST-1.iso
>> initrd: 
>> https://cdimage.debian.org/cdimage/ports/debian-installer/2020-10-12/=
>> m68k/debian-installer-images_20200315_m68k.tar.gz
>>
>> v6:
>>   m68k-virt-ctrl:
>>   Renamed to virt-ctrl to be generic
>>   Add a simple specs document
>
> Thanks for this document! Series LGTM.
>
> I tested doing:
>
> qemu$ docker run -it --rm -v $PWD:$PWD -w $PWD -v /tmp:/tmp -u 0
> --network host registry.gitlab.com/qemu-project/qemu/qemu/debian-m68k-cross
> # apt-get update
> # apt-get install flex bison libssl-dev
> # git clone https://github.com/vivier/linux.git
> # cd linux
> # git checkout m68k-virt
> # make O=build ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- virt_defconfig
> # make O=build ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- vmlinux -j8
>
> [0.00] Linux version 5.11.0-rc5-2-g8a00b8b1edb (root@x1w)
> (m68k-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
> Debian) 2.31.1) #1 Mon Mar 8 22:27:19 UTC 2021
>
> I also tested the Goldfish-tty:
>
> [1.39] printk: console [ttyGF0] enabled
> [1.39] printk: console [ttyGF0] enabled
> [1.39] printk: bootconsole [early_gf_tty0] disabled
> [1.39] printk: bootconsole [early_gf_tty0] disabled
>
> So:
> Tested-by: Philippe Mathieu-Daudé 

Thank you Philippe.

> Don't you want to share a preinstalled qcow2 image like Aurelien?
>
> https://people.debian.org/~aurel32/qemu/

For the moment, my next move is to have the kernel changes merged.

But I have a qcow2 available here: http://vivier.eu/debian-10.0.qcow2

>
> Also, do you plan to add functional testing later?

Yes, except if someone else does it before me :)

Thanks,
Laurent

Re: What is the intended behaviour of usb_host_get_port for root hubs?

[Gerd Hoffmann]

On Tue, Mar 09, 2021 at 10:54:15AM +1100, Ben Leslie wrote:
> When usb_host_get_port is called for a root-hub device what string should
> be output in the port parameter?

Just the port number, as string.

(and in case this isn't a root port the hub port number(s) are appended,
separated by a dot).

> The current behaviour writes a string with whatever stack value happened to
> be in the paths stack array.

Huh?  Isn't paths updated by the libusb_get_port_numbers() call?

take care,
  Gerd

Re: [PATCH] virtio-gpu: Add spaces around operator

[Gerd Hoffmann]

On Tue, Mar 09, 2021 at 11:57:02AM +0800, 李皆俊 wrote:
> From 0512d1cbe5c01844b4aca260024006e058dc1b6c Mon Sep 17 00:00:00 2001
> 
> From: lijiejun 
> 
> Date: Tue, 9 Mar 2021 11:17:59 +0800
> 
> Subject: [PATCH] virtio-gpu: Add spaces around operator

Patch is mangled by your mailer.
Please use 'git send-email' to submit patches.

thanks,
  Gerd

Re: [RFC] adding a generic QAPI event for failed device hotunplug

[Markus Armbruster]

Cc: Paolo and Julia in addition to Igor, because the thread is wandering
towards DeviceState member pending_deleted_event.

Cc: Laine for libvirt expertise.  Laine, if you're not the right person,
please loop in the right person.

David Gibson  writes:

> On Mon, Mar 08, 2021 at 03:01:53PM -0300, Daniel Henrique Barboza wrote:
>> 
>> 
>> On 3/8/21 2:04 PM, Markus Armbruster wrote:
>> > Daniel Henrique Barboza  writes:
>> > 
>> > > On 3/6/21 3:57 AM, Markus Armbruster wrote:
[...]
>> > > > We should document the event's reliability.  Are there unplug 
>> > > > operations
>> > > > where we can't detect failure?  Are there unplug operations where we
>> > > > could, but haven't implemented the event?
>> > > 
>> > > The current version of the PowerPC spec that the pseries machine 
>> > > implements
>> > > (LOPAR) does not predict a way for the virtual machine to report a 
>> > > hotunplug
>> > > error back to the hypervisor. If something fails, the hypervisor is left
>> > > in the dark.
>> > > 
>> > > What happened in the 6.0.0 dev cycle is that we faced a reliable way of
>> > 
>> > Do you mean "unreliable way"?
>> 
>> I guess a better word would be 'reproducible', as in we discovered a 
>> reproducible
>> way of getting the guest kernel to refuse the CPU hotunplug.
>
> Right.  It's worth noting here that in the PAPR model, there are no
> "forced" unplugs.  Unplugs always consist of a request to the guest,
> which is then resposible for offlining the device and signalling back
> to the hypervisor that it's done with it.
>
>> > > making CPU hotunplug fail in the guest (trying to hotunplug the last 
>> > > online
>> > > CPU) and the pseries machine was unprepared for dealing with it. We 
>> > > ended up
>> > > implementing a hotunplug timeout and, if the timeout kicks in, we're 
>> > > assuming
>> > > that the CPU hotunplug failed in the guest. This is the first scenario 
>> > > we have
>> > > today where we want to send a QAPI event informing the CPU hotunplug 
>> > > error,
>> > > but this event does not exist in QEMU ATM.
>> > 
>> > When the timeout kicks in, how can you know the operation failed?  You
>> > better be sure when you send an error event.  In other words: what
>> > prevents the scenario where the operation is much slower than you
>> > expect, the timeout expires, the error event is sent, and then the
>> > operation completes successfully?
>> 
>> A CPU hotunplug in a pseries guest takes no more than a couple of seconds, 
>> even
>> if the guest is under heavy load. The timeout is set to 15 seconds.
>
> Right.  We're well aware that a timeout is an ugly hack, since it's
> not really possible to distinguish it from a guest that's just being
> really slow.

As long as unplug failure cannot be detected reliably, we need a timeout
*somewhere*.  I vaguely recall libvirt has one.  Laine?

Putting the timeout in QEMU might be better.  QEMU might be in a better
position to pick a suitable timeout.

> It was the best thing we could come up with in the short term though.
> Without the changes we're suggesting here, the guest can positively
> assert the unplug is complete, but it has no way to signal failure.
> So, without a timeout qemu is stuck waiting indefinitely (or at least
> until the next machine reset) on the guest for an unplug that might
> never complete.
>
> It's particularly nasty if the guest does really fail the hotplug
> internally, but then conditions change so that the same unplug could
> now succeed.  The unplug request is just a message - there's no guest
> visible persistent state saying we want the device unplugged, so if
> conditions change the guest won't then re-attempt the unplug.
> Meanwhile the user can't re-attempt the device_del, because on the
> qemu side it's still stuck in a pending unplug waiting on the guest.

"Can't re-attempt" feels like a bug.  Let me explain.

Depending on the device, device_del can complete the unplug, or merely
initiate it.  Documentation:

# Notes: When this command completes, the device may not be removed from the
#guest.  Hot removal is an operation that requires guest cooperation.
#This command merely requests that the guest begin the hot removal
#process.  Completion of the device removal process is signaled with a
#DEVICE_DELETED event. Guest reset will automatically complete removal
#for all devices.

This is not as accurate as it could be.  Behavior depends on the device.

For some kinds of devices, the command completes the unplug before it
sends its reply.  Example: USB devices.  Fine print: the DEVICE_DELETED
event gets send with a slight delay because device cleanup uses RCU.

For others, notably PCI devices, the command only pokes the guest to do
its bit.  QEMU reacts to the guest's actions, which eventually leads to
the actual unplug.  DEVICE_DELETED gets sent then.  If the guest doesn't
play ball to the end, the event doesn't get send.

The "can't retry unplug" behavior is new.  Another device_del 

Re: [PATCH v2 2/2] tests/acceptance: Test ast2600 machine

[Joel Stanley]

On Fri, 5 Mar 2021 at 20:46, Wainer dos Santos Moschetta
 wrote:
>
> Hi,
>
> On 3/4/21 9:39 AM, Joel Stanley wrote:
> > This tests a Debian multi-soc arm32 Linux kernel on the AST2600 based
> > Tacoma BMC machine.
> >
> > There is no root file system so the test terminates when boot reaches
> > the stage where it attempts and fails to mount something.
> >
> > Signed-off-by: Joel Stanley 
> > ---
> > v2: Update expected strings so test passes
> > ---
> >   tests/acceptance/boot_linux_console.py | 26 ++
> >   1 file changed, 26 insertions(+)
> >
> > diff --git a/tests/acceptance/boot_linux_console.py 
> > b/tests/acceptance/boot_linux_console.py
> > index 2f46a08fdc10..4f1df69bc75c 100644
> > --- a/tests/acceptance/boot_linux_console.py
> > +++ b/tests/acceptance/boot_linux_console.py
> > @@ -1094,6 +1094,32 @@ def do_test_arm_aspeed(self, image):
> >   # self.wait_for_console_pattern("login:")
> >   self.vm.shutdown()
> >
> > +def test_arm_ast2600_debian(self):
> > +"""
> > +:avocado: tags=arch:arm
> > +:avocado: tags=machine:tacoma-bmc
> > +"""
> > +deb_url = ('http://snapshot.debian.org/archive/debian/'
> > +   '20210302T203551Z/'
> > +   'pool/main/l/linux/'
> > +   'linux-image-5.10.0-3-armmp_5.10.13-1_armhf.deb')
> > +deb_hash = 
> > 'db40d32fe39255d05482bea48d72467b67d6225bb2a2a4d6f618cb8976f1e09e'
> > +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash,
> > +algorithm='sha256')
> > +kernel_path = self.extract_from_deb(deb_path, 
> > '/boot/vmlinuz-5.10.0-3-armmp')
> > +dtb_path = self.extract_from_deb(deb_path,
> > +
> > '/usr/lib/linux-image-5.10.0-3-armmp/aspeed-bmc-opp-tacoma.dtb')
> > +
> > +self.vm.set_console()
> > +self.vm.add_args('-kernel', kernel_path,
> > + '-dtb', dtb_path,
> > + '-net', 'nic')
> > +self.vm.launch()
> > +self.wait_for_console_pattern("Booting Linux on physical CPU 
> > 0xf00")
> > +self.wait_for_console_pattern("SMP: Total of 2 processors 
> > activated")
>
> Above check isn't reliable. Here the VM started with smp 1, therefore
> the test failed as:

We should reliably pass that check once this fix has been merged:

 https://lore.kernel.org/qemu-devel/20210303010505.635621-1-j...@jms.id.au/T/

Having that line included is helpful, as it tests the smp boot stub
functionality in our emulated machine.

>
> FAIL: Failure message found in console: Kernel panic - not syncing
>
> > +self.wait_for_console_pattern("No filesystem could mount root")
> > +self.vm.shutdown()
>
> You don't need to shutdown the VM as the test's tearDown() does that for
> you.

Thanks, I'll send a v2 with those removed.


>
> Thanks!
>
> - Wainer
>
> > +
> >   def test_m68k_mcf5208evb(self):
> >   """
> >   :avocado: tags=arch:m68k
>

Re: [PATCH qemu v14] spapr: Implement Open Firmware client interface

[David Gibson]

On Tue, Mar 02, 2021 at 06:21:51PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 02/03/2021 14:35, David Gibson wrote:
> > On Wed, Feb 24, 2021 at 04:41:30PM +1100, Alexey Kardashevskiy wrote:
> > > The PAPR platform which describes an OS environment that's presented by
> > > a combination of a hypervisor and firmware. The features it specifies
> > > require collaboration between the firmware and the hypervisor.
> > > 
> > > Since the beginning, the runtime component of the firmware (RTAS) has
> > > been implemented as a 20 byte shim which simply forwards it to
> > > a hypercall implemented in qemu. The boot time firmware component is
> > > SLOF - but a build that's specific to qemu, and has always needed to be
> > > updated in sync with it. Even though we've managed to limit the amount
> > > of runtime communication we need between qemu and SLOF, there's some,
> > > and it has become increasingly awkward to handle as we've implemented
> > > new features.
> > > 
> > > This implements a boot time OF client interface (CI) which is
> > > enabled by a new "x-vof" pseries machine option (stands for "Virtual Open
> > > Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall
> > > which implements Open Firmware Client Interface (OF CI). This allows
> > > using a smaller stateless firmware which does not have to manage
> > > the device tree.
> > > 
> > > The new "vof.bin" firmware image is included with source code under
> > > pc-bios/. It also includes RTAS blob.
> > > 
> > > This implements a handful of CI methods just to get -kernel/-initrd
> > > working. In particular, this implements the device tree fetching and
> > > simple memory allocator - "claim" (an OF CI memory allocator) and updates
> > > "/memory@0/available" to report the client about available memory.
> > > 
> > > This implements changing some device tree properties which we know how
> > > to deal with, the rest is ignored. To allow changes, this skips
> > > fdt_pack() when x-vof=on as not packing the blob leaves some room for
> > > appending.
> > > 
> > > In absence of SLOF, this assigns phandles to device tree nodes to make
> > > device tree traversing work.
> > > 
> > > When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree.
> > > 
> > > This adds basic instances support which are managed by a hash map
> > > ihandle -> [phandle].
> > > 
> > > Before the guest started, the used memory is:
> > > 0..4000 - the initial firmware
> > > 1..18 - stack
> > > 
> > > This OF CI does not implement "interpret".
> > > 
> > > Unlike SLOF, this does not format uninitialized nvram. Instead, this
> > > includes a disk image with pre-formatted nvram.
> > 
> > I think we'll need to improve this, but that can be a later patch.
> > 
> > > With this basic support, this can only boot into kernel directly.
> > > However this is just enough for the petitboot kernel and initradmdisk to
> > > boot from any possible source. Note this requires reasonably recent guest
> > > kernel with:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735
> > > 
> > > The immediate benefit is much faster booting time which especially
> > > crucial with fully emulated early CPU bring up environments. Also this
> > > may come handy when/if GRUB-in-the-userspace sees light of the day.
> > > 
> > > This separates VOF and sPAPR in a hope that VOF bits may be reused by
> > > other POWERPC boards which do not support pSeries.
> > > 
> > > This is coded in assumption that later on we might be adding support for
> > > booting from QEMU backends (blockdev is the first candidate) without
> > > devices/drivers in between as OF1275 does not require that and
> > > it is quite easy to so.
> > > 
> > > Signed-off-by: Alexey Kardashevskiy 
> > > ---
> > > 
> > > The example command line is:
> > > 
> > > /home/aik/pbuild/qemu-killslof-localhost-ppc64/qemu-system-ppc64 \
> > > -nodefaults \
> > > -chardev stdio,id=STDIO0,signal=off,mux=on \
> > > -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> > > -mon id=MON0,chardev=STDIO0,mode=readline \
> > > -nographic \
> > > -vga none \
> > > -enable-kvm \
> > > -m 2G \
> > > -machine 
> > > pseries,x-vof=on,cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,cap-ccf-assist=off
> > >  \
> > > -kernel pbuild/kernel-le-guest/vmlinux \
> > > -initrd pb/rootfs.cpio.xz \
> > > -drive 
> > > id=DRIVE0,if=none,file=./p/qemu-killslof/pc-bios/vof/nvram.bin,format=raw 
> > > \
> > > -global spapr-nvram.drive=DRIVE0 \
> > > -snapshot \
> > > -smp 8,threads=8 \
> > > -L /home/aik/t/qemu-ppc64-bios/ \
> > > -trace events=qemu_trace_events \
> > > -d guest_errors \
> > > -chardev socket,id=SOCKET0,server,nowait,path=qemu.mon.tmux26 \
> > > -mon chardev=SOCKET0,mode=control
> > > 
> > > ---
> > > Changes:
> > > v14:
> > > * check for truncates in readstr()
> > > * ditched a separate vof_reset()
> > > * spapr->vof is a pointer now, dropped the "on" field
> > > * removed rtas_base from vof and 

Re: [PATCH qemu v14] spapr: Implement Open Firmware client interface

[David Gibson]

On Tue, Mar 02, 2021 at 10:37:59AM +0100, BALATON Zoltan wrote:
> On Tue, 2 Mar 2021, Alexey Kardashevskiy wrote:
> > On 02/03/2021 14:35, David Gibson wrote:
> > > Alexey or Zoltan, any thoughts on how non-PAPR versions of this would
> > > call into qemu to get the non-guest parts of VOF to execute?
> > 
> > Non-PAPR could do it as we do it for soft breakpoints in KVM - some
> > predefined illegal instruction which KVM knows that it is used for soft
> > breakpoints.
> 
> So far I've thought I'd need to implement TYPE_PPC_VIRTUAL_HYPERVISOR
> interface in the machine for the code in target/ppc/excp_helper.c to forward
> client syscalls to QEMU where I could handle the VOF related calls but not
> sure this is the best way.

I'm not sure that will work on its own.  VIRTUAL_HYPERVISOR just traps
the "sc 1" (hypecall instruction).  If that's an illegal instruction
for CPU, we can theoretically still use it, but I suspect TCG will
flag it as an illegal instruction and trap before we even get to the
VIRTUAL_HYPERVISOR dispatch point.  You'll need to investigate.

> This could be OK for the initial boot when
> nothing else should use syscalls yet but with RTAS this may not work as the
> guest OS could also use syscalls so to avoid conflicts we may need to shut
> down the virtual hypervisor on quiesce

Uh.. no.  VIRTUAL_HYPERVISOR doesn't intercept normal system calls,
only "level 1" system calls which are explicitly designated for
hypercalls.

> which means I may need a minimal
> guest only rtas for pegasos2 (which would be OK as I think it's only used
> for shutdown/reboot anyway). Also may need some changes to allow empty
> callbacks in vhyp to be ignored when I only want to implement hypercall
> method but that's just adding checks to only call non-NULL callbacks in
> PPCVirtualHypervisorClass.
> 
> There's also an old patch from Benjamin Herrenschmidt to add MOL OSI which
> is a similar hypercall interface:
> https://github.com/ozbenh/qemu/commit/6dc8803641e323030ffd01ad8ce0dcf081896698
> This might also be useful later to use MOL paravirtual drivers to speed up
> MacOSX emulation. but I haven't looked at the details yet.
> 
> Any other ideas?
> 
> Regards,
> BALATON Zoltan
> 

-- 
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: [PATCH 1/1] i386/cpu: Expose AVX_VNNI instruction to guset

[Yang Zhong]

Paolo, please help review this patch when you are not busy. 
The related kernel patch has been merged by you last time, thanks!

Regards,

Yang


On Mon, Mar 01, 2021 at 01:15:52PM +0800, Yang Zhong wrote:
> Expose AVX (VEX-encoded) versions of the Vector Neural Network
> Instructions to guest.
> 
> The bit definition:
> CPUID.(EAX=7,ECX=1):EAX[bit 4] AVX_VNNI
> 
> The following instructions are available when this feature is
> present in the guest.
>   1. VPDPBUS: Multiply and Add Unsigned and Signed Bytes
>   2. VPDPBUSDS: Multiply and Add Unsigned and Signed Bytes with Saturation
>   3. VPDPWSSD: Multiply and Add Signed Word Integers
>   4. VPDPWSSDS: Multiply and Add Signed Integers with Saturation
> 
> The release document ref below link:
> https://software.intel.com/content/www/us/en/develop/download/\
> intel-architecture-instruction-set-extensions-programming-reference.html
> 
> Signed-off-by: Yang Zhong 
> ---
>  target/i386/cpu.c | 4 ++--
>  target/i386/cpu.h | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6a53446e6a..55545d8692 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -996,7 +996,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
> {
>  .type = CPUID_FEATURE_WORD,
>  .feat_names = {
>  NULL, NULL, NULL, NULL,
> -NULL, "avx512-bf16", NULL, NULL,
> +"avx-vnni", "avx512-bf16", NULL, NULL,
>  NULL, NULL, NULL, NULL,
>  NULL, NULL, NULL, NULL,
>  NULL, NULL, NULL, NULL,
> @@ -3273,7 +3273,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  MSR_ARCH_CAP_SKIP_L1DFL_VMENTRY | MSR_ARCH_CAP_MDS_NO |
>  MSR_ARCH_CAP_PSCHANGE_MC_NO | MSR_ARCH_CAP_TAA_NO,
>  .features[FEAT_7_1_EAX] =
> -CPUID_7_1_EAX_AVX512_BF16,
> +CPUID_7_1_EAX_AVX_VNNI | CPUID_7_1_EAX_AVX512_BF16,
>  /*
>   * Missing: XSAVES (not supported by some Linux versions,
>   * including v4.1 to v4.12).
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 8be39cfb62..ef5f145626 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -803,6 +803,8 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
>  /* Speculative Store Bypass Disable */
>  #define CPUID_7_0_EDX_SPEC_CTRL_SSBD(1U << 31)
>  
> +/* AVX VNNI Instruction */
> +#define CPUID_7_1_EAX_AVX_VNNI  (1U << 4)
>  /* AVX512 BFloat16 Instruction */
>  #define CPUID_7_1_EAX_AVX512_BF16   (1U << 5)
>  
> -- 
> 2.29.2.334.gfaefdd61ec

Re: [PATCH v2] FreeBSD: Upgrade to 12.2 release

[Thomas Huth]

On 08/03/2021 20.57, Warner Losh wrote:



On Mon, Mar 8, 2021 at 12:51 PM Warner Losh > wrote:




On Mon, Mar 8, 2021 at 8:46 AM Roman Bolshakov mailto:r.bolsha...@yadro.com>> wrote:


 > 8 марта 2021 г., в 18:41, Thomas Huth mailto:th...@redhat.com>> написал(а):
 >
 > On 08/03/2021 16.26, Warner Losh wrote:
 >> On Mon, Mar 8, 2021 at 6:30 AM Thomas Huth mailto:th...@redhat.com> >> wrote:
 >>    On 07/03/2021 16.56, Warner Losh wrote:
 >>     > FreeBSD 12.1 has reached end of life. Use 12.2 instead so
that FreeBSD's
 >>     > project's packages will work.  Update which timezone to
pick. Work
 >>    around a QEMU
 >>     > bug that incorrectly raises an exception on a CRC32
instruction with
 >>    the FPU
 >>     > disabled.  The qemu bug is described here:
 >>     >
https://www.mail-archive.com/qemu-devel@nongnu.org/msg784158.html

 >>   
>
 >>     >
 >>     > Signed-off-by: Warner Losh mailto:i...@bsdimp.com> >>
 >>     >
 >>     > ---
 >>     >   tests/vm/freebsd | 14 +-
 >>     >   1 file changed, 9 insertions(+), 5 deletions(-)
 >>    I gave this a try, but it's currently failing in the unit tests:
 >>    Running test test-crypto-tlscredsx509
 >>    ** (tests/test-crypto-tlscredsx509:): CRITICAL **:
12:56:35.157: Failed
 >>    to sign certificate ASN1 parser: Value is not valid.
 >>    ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL:
Failed to sign
 >>    certificate ASN1 parser: Value is not valid.
 >>    gmake: *** [Makefile.mtest:576: run-test-70] Error 1
 >>    gmake: *** Waiting for unfinished jobs
 >>    Running test test-crypto-tlssession
 >>    ** (tests/test-crypto-tlssession:10002): CRITICAL **:
12:56:35.288: Failed
 >>    to sign certificate ASN1 parser: Value is not valid.
 >>    ERROR test-crypto-tlssession - Bail out! FATAL-CRITICAL:
Failed to sign
 >>    certificate ASN1 parser: Value is not valid.
 >> That's totally unrelated to my change. Was it failing before?
What environment was it failing in because it all seemed to work for
me...
 >
 > It's been a while since I last ran "make vm-build-freebsd", so I
can't really tell whether the problem was already there before ...
when I now try to run it without your patch, it fails for me, too,
but rather due to FreeBSD 12.1 being out of service instead.
 >
 >>    I guess it's the same problem as:
 >>
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06750.html

 >>   
>
 >>    ... so this would require a bug fix in the libtasn of FreeBSD
first? See:
 >> https://gitlab.com/gnutls/libtasn1/-/merge_requests/71

 >>    >
 >>  Is this on the host that built qemu, or inside the VM or where
exactly?
 >
 > It's inside the VM ... I assume the libtasn there has the same
bug as the one on macOS?
 >

The gnutls failures on macOS and FreeBSD (with clang as main
compiler) won’t happen only if libtasn1 from master is used.
Otherwise libtasn1 has to be compiled with -O1/-O0.


Forgive my ignorance...

Does this come from a submodule? From something I've built and installed
on my FreeBSD host? Or something that's installed into the FreeBSD guest


ah, it's inside the guest.


Yes, IIUC it's the pre-installed libtasn1 in the guest, and the problem 
likely occurs just now since the clang that has been used to compile the 
library has been updated, too?


Anyway, can you reproduce the issue? If so, could you please file a bug 
ticket against libtasn1 there, so that it gets fixed? (sorry, I don't have 
any clue about the FreeBSD process here)


 Thomas

Re: [PATCH v2] block/file-posix: Optimize for macOS

[Akihiko Odaki]

2021年3月9日(火) 0:37 Akihiko Odaki :
>
> 2021年3月9日(火) 0:17 Stefan Hajnoczi :
> >
> > The live migration compatibility issue is still present. Migrating to
> > another host might not work if the block limits are different.
> >
> > Here is an idea for solving it:
> >
> > Modify include/hw/block/block.h:DEFINE_BLOCK_PROPERTIES_BASE() to
> > support a new value called "host". The default behavior remains
> > unchanged for live migration compatibility but now you can use "host" if
> > you know it's okay but don't care about migration compatibility.
> >
> > The downside to this approach is that users must explicitly say
> > something like --drive ...,opt_io_size=host. But it's still better than
> > the situation we have today where user must manually enter values for
> > their disk.
> >
> > Does this sound okay to everyone?
> >
> > Stefan
>
> I wonder how that change affects other block drivers implementing
> bdrv_probe_blocksizes. As far as I know, the values they report are
> already used by default, which is contrary to the default not being
> "host".
>
> Regards,
> Akihiko Odaki

Let me suggest a variant of Stefan's approach:

Modify include/hw/block/block.h:DEFINE_BLOCK_PROPERTIES_BASE() to
support a new value called "host". The default values for block size
properties may be "host" or not, but they should be consistent. If
they are "host" by default, add global properties which sets
discard_granularity and opt_io_size to the old default to
hw_compat_5_2 in hw/core/machine.c. Otherwise, add global properties
which sets logical_block_size and physical_block_size to "host".

Does it sound good? I'd also like to know others opinions for the
default value ("host" or something else). I prefer "host" as the
default a little because those who need live migration should be
careful enough to set proper configurations for each device. We may
also assist users who need live migration by adding a property which
defaults all block size properties to something else "host".

Regards,
Akihiko Odaki

[PATCH] virtio-gpu: Add spaces around operator

[李皆俊]

From 0512d1cbe5c01844b4aca260024006e058dc1b6c Mon Sep 17 00:00:00 2001

From: lijiejun 

Date: Tue, 9 Mar 2021 11:17:59 +0800

Subject: [PATCH] virtio-gpu: Add spaces around operator




Fix code style. Operator needs spaces forend sides.




Signed-off-by: lijiejun 

---

 hw/display/virtio-gpu-3d.c | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)




diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c

index 9eb4890..fb11e5f 100644

--- a/hw/display/virtio-gpu-3d.c

+++ b/hw/display/virtio-gpu-3d.c

@@ -438,7 +438,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,

 break;

 case VIRTIO_GPU_CMD_RESOURCE_FLUSH:

 virgl_cmd_resource_flush(g, cmd);

-   break;

+break;

 case VIRTIO_GPU_CMD_RESOURCE_UNREF:

 virgl_cmd_resource_unref(g, cmd);

 break;

--

1.8.3.1

[Bug 1908266] Re: spice unnecessary forces nographic

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

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

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

Title:
  spice unnecessary forces nographic

Status in QEMU:
  Expired

Bug description:
  When spice is enabled, qemu does not give the graphical window. It
  should not imply -nographic but only -display none.

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

Re: [PATCH] virtio-net: calculating proper msix vectors on init

[Jason Wang]

On 2021/3/8 6:06 下午, Philippe Mathieu-Daudé wrote:

Hi Jason,

On 3/8/21 6:30 AM, Jason Wang wrote:

Currently, the default msix vectors for virtio-net-pci is 3 which is
obvious not suitable for multiqueue guest, so we depends on the user
or management tools to pass a correct vectors parameter. In fact, we
can simplifying this by calculating the number of vectors on realize.

Consider we have N queues, the number of vectors needed is 2*N + 2
(#queue pais + plus one config interrupt and control vq). We didn't

Typo "pairs".


check whether or not host support control vq because it was added
unconditionally by qemu to avoid breaking legacy guests such as Minix.

Signed-off-by: Jason Wang 
---
  hw/core/machine.c  | 1 +
  hw/virtio/virtio-net-pci.c | 8 +++-
  2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 4386f57b5c..979133f8b7 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,6 +39,7 @@
  GlobalProperty hw_compat_5_2[] = {
  { "ICH9-LPC", "smm-compat", "on"},
  { "PIIX4_PM", "smm-compat", "on"},
+{ "virtio-net-pci", "vectors", "3"},
  };
  const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
  
diff --git a/hw/virtio/virtio-net-pci.c b/hw/virtio/virtio-net-pci.c

index 292d13d278..2894c46b66 100644
--- a/hw/virtio/virtio-net-pci.c
+++ b/hw/virtio/virtio-net-pci.c
@@ -41,7 +41,8 @@ struct VirtIONetPCI {
  static Property virtio_net_properties[] = {
  DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
  VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
+DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
+   DEV_NVECTORS_UNSPECIFIED),
  DEFINE_PROP_END_OF_LIST(),
  };
  
@@ -50,6 +51,11 @@ static void virtio_net_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)

  DeviceState *qdev = DEVICE(vpci_dev);
  VirtIONetPCI *dev = VIRTIO_NET_PCI(vpci_dev);
  DeviceState *vdev = DEVICE(>vdev);
+VirtIONet *net = VIRTIO_NET(vdev);
+
+if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
+vpci_dev->nvectors = 2 * MAX(net->nic_conf.peers.queues, 1) + 2;

Please either document that magic '2':

vpci_dev->nvectors = 2 * MAX(net->nic_conf.peers.queues, 1)
 + 1 /* Config interrupt */
 + 1 /* Control vq */;

Or add self-explicit definitions and use them in place.



Ok, V2 is sent.

Thanks





+}
  
  virtio_net_set_netclient_name(>vdev, qdev->id,

object_get_typename(OBJECT(qdev)));

[PATCH V2] virtio-net: calculating proper msix vectors on init

[Jason Wang]

Currently, the default msix vectors for virtio-net-pci is 3 which is
obvious not suitable for multiqueue guest, so we depends on the user
or management tools to pass a correct vectors parameter. In fact, we
can simplifying this by calculating the number of vectors on realize.

Consider we have N queues, the number of vectors needed is 2*N + 2
(#queue pairs + plus one config interrupt and control vq). We didn't
check whether or not host support control vq because it was added
unconditionally by qemu to avoid breaking legacy guests such as Minix.

Signed-off-by: Jason Wang 
---
Changes since v1:
- Fix typo in the commit log
- Explain the magic number during vectors calculation
---
 hw/core/machine.c  |  1 +
 hw/virtio/virtio-net-pci.c | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 4386f57b5c..979133f8b7 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,6 +39,7 @@
 GlobalProperty hw_compat_5_2[] = {
 { "ICH9-LPC", "smm-compat", "on"},
 { "PIIX4_PM", "smm-compat", "on"},
+{ "virtio-net-pci", "vectors", "3"},
 };
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
 
diff --git a/hw/virtio/virtio-net-pci.c b/hw/virtio/virtio-net-pci.c
index 292d13d278..aa0b3caecb 100644
--- a/hw/virtio/virtio-net-pci.c
+++ b/hw/virtio/virtio-net-pci.c
@@ -41,7 +41,8 @@ struct VirtIONetPCI {
 static Property virtio_net_properties[] = {
 DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
+DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
+   DEV_NVECTORS_UNSPECIFIED),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -50,6 +51,13 @@ static void virtio_net_pci_realize(VirtIOPCIProxy *vpci_dev, 
Error **errp)
 DeviceState *qdev = DEVICE(vpci_dev);
 VirtIONetPCI *dev = VIRTIO_NET_PCI(vpci_dev);
 DeviceState *vdev = DEVICE(>vdev);
+VirtIONet *net = VIRTIO_NET(vdev);
+
+if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
+vpci_dev->nvectors = 2 * MAX(net->nic_conf.peers.queues, 1)
++ 1 /* Config interrupt */
++ 1 /* Control vq */;
+}
 
 virtio_net_set_netclient_name(>vdev, qdev->id,
   object_get_typename(OBJECT(qdev)));
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] ui/gtk: fix NULL pointer dereference

[Akihiko Odaki]

2021年3月8日(月) 23:58 Christian Schoenebeck :
>
> Yes, but the optimizer part could be disabled with
> -fno-delete-null-pointer-checks which would render it a pure diagnostic
> feature:
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute
>
> Is there an example where the compiler failed to detect a NULL user case?
>
> Best regards,
> Christian Schoenebeck
>
>

-fno-delete-null-pointer-checks also prevents the compiler to infer
that a pointer is never NULL with the fact it is dereferenced
somewhere else. It also disables
-fisolate-erroneous-paths-dereference, which turns code paths with
NULL pointer dereferences into traps. I suspect these side effects are
too important to ignore.

Perhaps we may define QEMU_NONNULL as once it was, and document that
it affects runtime behaviors and should not be blindly added to
functions that already exist. We may also be able to enable
-fisolate-erroneous-paths-attribute, which turns code paths with NULL
pointer passing to such functions into traps, if we explicitly state
that it has runtime effects.

Regards,
Akihiko Odaki

[PATCH] coroutine: add libucontext as external library

[Joelle van Dyne]

iOS does not support ucontext natively for aarch64 and the sigaltstack is
also unsupported (even worse, it fails silently, see:
https://openradar.appspot.com/13002712 )

As a workaround we include a library implementation of ucontext and add it
as a build option.

Signed-off-by: Joelle van Dyne 
---
 configure | 21 ++---
 meson.build   | 12 +++-
 util/coroutine-ucontext.c |  9 +
 .gitmodules   |  3 +++
 MAINTAINERS   |  6 ++
 meson_options.txt |  2 ++
 subprojects/libucontext   |  1 +
 7 files changed, 50 insertions(+), 4 deletions(-)
 create mode 16 subprojects/libucontext

diff --git a/configure b/configure
index 34fccaa2ba..5f225894a9 100755
--- a/configure
+++ b/configure
@@ -1773,7 +1773,7 @@ Advanced options (experts only):
   --oss-libpath to OSS library
   --cpu=CPUBuild for host CPU [$cpu]
   --with-coroutine=BACKEND coroutine backend. Supported options:
-   ucontext, sigaltstack, windows
+   ucontext, libucontext, sigaltstack, windows
   --enable-gcovenable test coverage analysis with gcov
   --disable-blobs  disable installing provided firmware blobs
   --with-vss-sdk=SDK-path  enable Windows VSS support in QEMU Guest Agent
@@ -4517,12 +4517,27 @@ else
   error_exit "only the 'windows' coroutine backend is valid for Windows"
 fi
 ;;
+  libucontext)
+  ;;
   *)
 error_exit "unknown coroutine backend $coroutine"
 ;;
   esac
 fi
 
+case $coroutine in
+libucontext)
+  git_submodules="${git_submodules} subprojects/libucontext"
+  mkdir -p libucontext
+  coroutine_impl=ucontext
+  libucontext="enabled"
+  ;;
+*)
+  coroutine_impl=$coroutine
+  libucontext="disabled"
+  ;;
+esac
+
 if test "$coroutine_pool" = ""; then
   coroutine_pool=yes
 fi
@@ -5858,7 +5873,7 @@ if test "$qom_cast_debug" = "yes" ; then
   echo "CONFIG_QOM_CAST_DEBUG=y" >> $config_host_mak
 fi
 
-echo "CONFIG_COROUTINE_BACKEND=$coroutine" >> $config_host_mak
+echo "CONFIG_COROUTINE_BACKEND=$coroutine_impl" >> $config_host_mak
 if test "$coroutine_pool" = "yes" ; then
   echo "CONFIG_COROUTINE_POOL=1" >> $config_host_mak
 else
@@ -6421,7 +6436,7 @@ NINJA=$ninja $meson setup \
 -Dlibnfs=$libnfs -Diconv=$iconv -Dcurses=$curses -Dlibudev=$libudev\
 -Drbd=$rbd -Dlzo=$lzo -Dsnappy=$snappy -Dlzfse=$lzfse \
 -Dzstd=$zstd -Dseccomp=$seccomp -Dvirtfs=$virtfs -Dcap_ng=$cap_ng \
--Dattr=$attr -Ddefault_devices=$default_devices \
+-Dattr=$attr -Ddefault_devices=$default_devices 
-Ducontext=$libucontext \
 -Ddocs=$docs -Dsphinx_build=$sphinx_build -Dinstall_blobs=$blobs \
 -Dvhost_user_blk_server=$vhost_user_blk_server 
-Dmultiprocess=$multiprocess \
 -Dfuse=$fuse -Dfuse_lseek=$fuse_lseek 
-Dguest_agent_msi=$guest_agent_msi \
diff --git a/meson.build b/meson.build
index adeec153d9..2440d90734 100644
--- a/meson.build
+++ b/meson.build
@@ -1633,9 +1633,18 @@ if not fdt.found() and fdt_required.length() > 0
   error('fdt not available but required by targets ' + ', '.join(fdt_required))
 endif
 
+ucontext = dependency('libucontext', kwargs: static_kwargs, required : false)
+if not ucontext.found() and get_option('ucontext').enabled()
+  libucontext_proj = subproject('libucontext',
+default_options: ['default_library=static',
+  'freestanding=true'])
+  ucontext = libucontext_proj.get_variable('libucontext_dep')
+endif
+
 config_host_data.set('CONFIG_CAPSTONE', capstone.found())
 config_host_data.set('CONFIG_FDT', fdt.found())
 config_host_data.set('CONFIG_SLIRP', slirp.found())
+config_host_data.set('CONFIG_LIBUCONTEXT', ucontext.found())
 
 #
 # Generated sources #
@@ -1883,7 +1892,7 @@ util_ss.add_all(trace_ss)
 util_ss = util_ss.apply(config_all, strict: false)
 libqemuutil = static_library('qemuutil',
  sources: util_ss.sources() + stub_ss.sources() + 
genh,
- dependencies: [util_ss.dependencies(), m, glib, 
socket, malloc])
+ dependencies: [util_ss.dependencies(), m, glib, 
socket, malloc, ucontext])
 qemuutil = declare_dependency(link_with: libqemuutil,
   sources: genh + version_res)
 
@@ -2579,6 +2588,7 @@ summary(summary_info, bool_yn: true, section: 'Targets 
and accelerators')
 
 # Block layer
 summary_info = {}
+summary_info += {'libucontext support': ucontext.found()}
 summary_info += {'coroutine backend': config_host['CONFIG_COROUTINE_BACKEND']}
 summary_info += {'coroutine pool':config_host['CONFIG_COROUTINE_POOL'] == 
'1'}
 if have_block
diff --git a/util/coroutine-ucontext.c b/util/coroutine-ucontext.c
index 904b375192..220c57a743 100644
--- a/util/coroutine-ucontext.c
+++ b/util/coroutine-ucontext.c
@@ -23,7 +23,16 @@
 #undef 

Re: [RFC] adding a generic QAPI event for failed device hotunplug

[David Gibson]

On Mon, Mar 08, 2021 at 03:01:53PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 3/8/21 2:04 PM, Markus Armbruster wrote:
> > Daniel Henrique Barboza  writes:
> > 
> > > On 3/6/21 3:57 AM, Markus Armbruster wrote:
> > > > Cc: ACPI maintainers for additional expertise.
> > > > 
> > > > Daniel Henrique Barboza  writes:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > Recent changes in pseries code (not yet pushed, available at David's
> > > > > ppc-for-6.0) are using the QAPI event MEM_UNPLUG_ERROR to report 
> > > > > memory
> > > > > hotunplug errors in the pseries machine.
> > > > > 
> > > > > The pseries machine is also using a timeout to cancel CPU hotunplugs 
> > > > > that
> > > > > takes too long to finish (in which we're assuming a guest side error) 
> > > > > and
> > > > > it would be desirable to also send a QAPI event for this case as well.
> > > > > 
> > > > > At this moment, there is no "CPU_UNPLUG_ERROR" in QAPI (guess ACPI 
> > > > > doesn't
> > > > > need it).
> > > > 
> > > > I see two interpretations of "ACPI doesn't need":
> > > > 
> > > > 1. Unplug can't fail, or QEMU can't detect failure.  Michael, Igor?
> > > > 
> > > > 2. Management applications haven't needed to know badly enough to
> > > > implement an event.
> > > > 
> > > > > Before sending patches to implement this new event I had 
> > > > > a talk
> > > > > with David Gibson and he suggested that, instead of adding a new 
> > > > > CPU_UNPLUG_ERROR
> > > > > event, we could add a generic event (e.g. DEVICE_UNPLUG_ERROR) that 
> > > > > can be
> > > > > used by the pseries machine in both error scenarios (MEM and CPU).
> > > > 
> > > > Good point.  One general event is better than two special ones that
> > > > could easily grow siblings.
> > > > 
> > > > > This could also be used by x86 as well, although I believe the use of
> > > > > MEM_UNPLUG_ERROR would need to be kept for awhile to avoid breaking 
> > > > > ABI.
> > > > 
> > > > Yes.  Our rules for interface deprecation apply.
> > > > 
> > > > > Any suggestions/comments?
> > > > 
> > > > We should document the event's reliability.  Are there unplug operations
> > > > where we can't detect failure?  Are there unplug operations where we
> > > > could, but haven't implemented the event?
> > > 
> > > The current version of the PowerPC spec that the pseries machine 
> > > implements
> > > (LOPAR) does not predict a way for the virtual machine to report a 
> > > hotunplug
> > > error back to the hypervisor. If something fails, the hypervisor is left
> > > in the dark.
> > > 
> > > What happened in the 6.0.0 dev cycle is that we faced a reliable way of
> > 
> > Do you mean "unreliable way"?
> 
> I guess a better word would be 'reproducible', as in we discovered a 
> reproducible
> way of getting the guest kernel to refuse the CPU hotunplug.

Right.  It's worth noting here that in the PAPR model, there are no
"forced" unplugs.  Unplugs always consist of a request to the guest,
which is then resposible for offlining the device and signalling back
to the hypervisor that it's done with it.

> > > making CPU hotunplug fail in the guest (trying to hotunplug the last 
> > > online
> > > CPU) and the pseries machine was unprepared for dealing with it. We ended 
> > > up
> > > implementing a hotunplug timeout and, if the timeout kicks in, we're 
> > > assuming
> > > that the CPU hotunplug failed in the guest. This is the first scenario we 
> > > have
> > > today where we want to send a QAPI event informing the CPU hotunplug 
> > > error,
> > > but this event does not exist in QEMU ATM.
> > 
> > When the timeout kicks in, how can you know the operation failed?  You
> > better be sure when you send an error event.  In other words: what
> > prevents the scenario where the operation is much slower than you
> > expect, the timeout expires, the error event is sent, and then the
> > operation completes successfully?
> 
> A CPU hotunplug in a pseries guest takes no more than a couple of seconds, 
> even
> if the guest is under heavy load. The timeout is set to 15 seconds.

Right.  We're well aware that a timeout is an ugly hack, since it's
not really possible to distinguish it from a guest that's just being
really slow.

It was the best thing we could come up with in the short term though.
Without the changes we're suggesting here, the guest can positively
assert the unplug is complete, but it has no way to signal failure.
So, without a timeout qemu is stuck waiting indefinitely (or at least
until the next machine reset) on the guest for an unplug that might
never complete.

It's particularly nasty if the guest does really fail the hotplug
internally, but then conditions change so that the same unplug could
now succeed.  The unplug request is just a message - there's no guest
visible persistent state saying we want the device unplugged, so if
conditions change the guest won't then re-attempt the unplug.
Meanwhile the user can't re-attempt the device_del, because on the
qemu side it's 

[PATCH v2] vfio/migrate: Move switch of dirty tracking into vfio_memory_listener

[Keqian Zhu]

For now the switch of vfio dirty page tracking is integrated into
@vfio_save_handler. The reason is that some PCI vendor driver may
start to track dirty base on _SAVING state of device, so if dirty
tracking is started before setting device state, vfio will report
full-dirty to QEMU.

However, the dirty bmap of all ramblocks are fully set when setup
ram saving, so it's not matter whether the device is in _SAVING
state when start vfio dirty tracking.

Moreover, this logic causes some problems [1]. The object of dirty
tracking is guest memory, but the object of @vfio_save_handler is
device state, which produces unnecessary coupling and conflicts:

1. Coupling: Their saving granule is different (perVM vs perDevice).
   vfio will enable dirty_page_tracking for each devices, actually
   once is enough.

2. Conflicts: The ram_save_setup() traverses all memory_listeners
   to execute their log_start() and log_sync() hooks to get the
   first round dirty bitmap, which is used by the bulk stage of
   ram saving. However, as vfio dirty tracking is not yet started,
   it can't get dirty bitmap from vfio. Then we give up the chance
   to handle vfio dirty page at bulk stage.

Move the switch of vfio dirty_page_tracking into vfio_memory_listener
can solve above problems. Besides, Do not require devices in SAVING
state for vfio_sync_dirty_bitmap().

[1] https://www.spinics.net/lists/kvm/msg229967.html

Reported-by: Zenghui Yu 
Signed-off-by: Keqian Zhu 
Suggested-by: Paolo Bonzini 
---

changelog:

v2:
 - use log_global_(start|stop) to switch vfio dirty tracking. (Paolo)
 - add the initial design idea.

---
 hw/vfio/common.c| 49 -
 hw/vfio/migration.c | 35 
 2 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 6ff1daa763..a27aa9dda8 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -311,7 +311,7 @@ bool vfio_mig_active(void)
 return true;
 }
 
-static bool vfio_devices_all_saving(VFIOContainer *container)
+static bool vfio_devices_all_dirty_tracking(VFIOContainer *container)
 {
 VFIOGroup *group;
 VFIODevice *vbasedev;
@@ -329,13 +329,8 @@ static bool vfio_devices_all_saving(VFIOContainer 
*container)
 return false;
 }
 
-if (migration->device_state & VFIO_DEVICE_STATE_SAVING) {
-if ((vbasedev->pre_copy_dirty_page_tracking == ON_OFF_AUTO_OFF)
-&& (migration->device_state & VFIO_DEVICE_STATE_RUNNING)) {
-return false;
-}
-continue;
-} else {
+if ((vbasedev->pre_copy_dirty_page_tracking == ON_OFF_AUTO_OFF)
+&& (migration->device_state & VFIO_DEVICE_STATE_RUNNING)) {
 return false;
 }
 }
@@ -987,6 +982,40 @@ static void vfio_listener_region_del(MemoryListener 
*listener,
 }
 }
 
+static void vfio_set_dirty_page_tracking(VFIOContainer *container, bool start)
+{
+int ret;
+struct vfio_iommu_type1_dirty_bitmap dirty = {
+.argsz = sizeof(dirty),
+};
+
+if (start) {
+dirty.flags = VFIO_IOMMU_DIRTY_PAGES_FLAG_START;
+} else {
+dirty.flags = VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP;
+}
+
+ret = ioctl(container->fd, VFIO_IOMMU_DIRTY_PAGES, );
+if (ret) {
+error_report("Failed to set dirty tracking flag 0x%x errno: %d",
+ dirty.flags, errno);
+}
+}
+
+static void vfio_listener_log_global_start(MemoryListener *listener)
+{
+VFIOContainer *container = container_of(listener, VFIOContainer, listener);
+
+vfio_set_dirty_page_tracking(container, true);
+}
+
+static void vfio_listener_log_global_stop(MemoryListener *listener)
+{
+VFIOContainer *container = container_of(listener, VFIOContainer, listener);
+
+vfio_set_dirty_page_tracking(container, false);
+}
+
 static int vfio_get_dirty_bitmap(VFIOContainer *container, uint64_t iova,
  uint64_t size, ram_addr_t ram_addr)
 {
@@ -1128,7 +1157,7 @@ static void vfio_listerner_log_sync(MemoryListener 
*listener,
 return;
 }
 
-if (vfio_devices_all_saving(container)) {
+if (vfio_devices_all_dirty_tracking(container)) {
 vfio_sync_dirty_bitmap(container, section);
 }
 }
@@ -1136,6 +1165,8 @@ static void vfio_listerner_log_sync(MemoryListener 
*listener,
 static const MemoryListener vfio_memory_listener = {
 .region_add = vfio_listener_region_add,
 .region_del = vfio_listener_region_del,
+.log_global_start = vfio_listener_log_global_start,
+.log_global_stop = vfio_listener_log_global_stop,
 .log_sync = vfio_listerner_log_sync,
 };
 
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index 00daa50ed8..c0f646823a 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -395,40 +395,10 @@ static int vfio_load_device_config_state(QEMUFile *f, 
void *opaque)
  

Re: [PATCH v3 2/2] tests: Add functional test for out-of-process device emulation

[Cleber Rosa]

On Wed, Mar 03, 2021 at 05:53:20PM -0300, Willian Rampazzo wrote:
> From: Jagannathan Raman 
> 
> Runs the Avocado acceptance test to check if a
> remote lsi53c895a device gets identified by the guest.
> 
> Signed-off-by: Elena Ufimtseva 
> Signed-off-by: John G Johnson 
> Signed-off-by: Jagannathan Raman 
> Reviewed-by: Wainer dos Santos Moschetta 
> Reviewed-by: Marc-André Lureau 
> [WR: Refactored code]
> Signed-off-by: Willian Rampazzo 
> Tested-by: Wainer dos Santos Moschetta 
> ---
>  tests/acceptance/multiprocess.py | 95 
>  1 file changed, 95 insertions(+)
>  create mode 100644 tests/acceptance/multiprocess.py
>

Because of KVM requirement, tested on x86_64 host:

   ./tests/venv/bin/avocado run -t arch:x86_64 tests/acceptance/multiprocess.py 
   JOB ID : bde34ca2168ce031f3fbdbb5091889fb9bc4b977
   JOB LOG: 
/home/cleber/avocado/job-results/job-2021-03-08T20.16-bde34ca/job.log
(1/1) 
tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_x86_64: PASS 
(5.80 s)
   RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
CANCEL 0
   JOB TIME   : 6.23 s

And on aarch64 host:

   $ ./tests/venv/bin/avocado run -t arch:aarch64 
tests/acceptance/multiprocess.py 
   JOB ID : a101a47887322981aae722b9c8e7cb6e6350eed9
   JOB LOG: 
/home/cleber/avocado/job-results/job-2021-03-08T20.17-a101a47/job.log
(1/1) 
tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_aarch64: PASS 
(9.55 s)
   RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
CANCEL 0
   JOB TIME   : 10.17 s

Reviewed-by: Cleber Rosa 
Tested-by: Cleber Rosa 


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] avocado_qemu: add exec_command function

[Cleber Rosa]

On Wed, Mar 03, 2021 at 05:53:19PM -0300, Willian Rampazzo wrote:
> Sometimes a test needs to send a command to a console without waiting
> for a pattern as a result, or the command issued do not produce any kind
> of output, like, for example, a `mount` command.
> 
> This introduces the `exec_command` function to the avocado_qemu,
> allowing the test to send a command to the console without the need to
> match a pattern produced as a result.
> 
> Signed-off-by: Willian Rampazzo 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Wainer dos Santos Moschetta 
> ---
>  tests/acceptance/avocado_qemu/__init__.py | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 

Reviewed-by: Cleber Rosa 


signature.asc
Description: PGP signature

Re: [PATCH 2/2] aspeed: Integrate HACE

[Andrew Jeffery]

On Wed, 3 Mar 2021, at 17:33, Joel Stanley wrote:
> Add the hash and crypto engine model to the aspeed socs.
> 
> Signed-off-by: Joel Stanley 
> [ clg: documentation update ]
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Andrew Jeffery 

Re: [PATCH 1/2] hw: Model ASPEED's Hash and Crypto Engine

[Andrew Jeffery]

On Wed, 3 Mar 2021, at 17:33, Joel Stanley wrote:
> The HACE (Hash and Crpyto Engine) is a device that offloads MD5, SHA1,
> SHA2, RSA and other cryptographic algorithms.
> 
> This initial model implements a subset of the device's functionality;
> currently only direct access (non-scatter gather) hashing.
> 
> Signed-off-by: Joel Stanley 
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/misc/aspeed_hace.h |  33 
>  hw/misc/aspeed_hace.c | 302 ++
>  hw/misc/meson.build   |   2 +-
>  3 files changed, 336 insertions(+), 1 deletion(-)
>  create mode 100644 include/hw/misc/aspeed_hace.h
>  create mode 100644 hw/misc/aspeed_hace.c
> 
> diff --git a/include/hw/misc/aspeed_hace.h 
> b/include/hw/misc/aspeed_hace.h
> new file mode 100644
> index ..e1fce670ef9e
> --- /dev/null
> +++ b/include/hw/misc/aspeed_hace.h
> @@ -0,0 +1,33 @@
> +/*
> + * ASPEED Hash and Crypto Engine
> + *
> + * Copyright (C) 2021 IBM Corp.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef ASPEED_HACE_H
> +#define ASPEED_HACE_H
> +
> +#include "hw/sysbus.h"
> +
> +#define TYPE_ASPEED_HACE "aspeed.hace"
> +#define ASPEED_HACE(obj) OBJECT_CHECK(AspeedHACEState, (obj), 
> TYPE_ASPEED_HACE)
> +
> +#define ASPEED_HACE_NR_REGS (0x64 >> 2)

0x64 is the offset of the last defined register, so this should be (0x68 >> 2)

> +
> +typedef struct AspeedHACEState {
> +/*  */
> +SysBusDevice parent;
> +
> +/*< public >*/
> +MemoryRegion iomem;
> +qemu_irq irq;
> +
> +uint32_t regs[ASPEED_HACE_NR_REGS];
> +
> +MemoryRegion *dram_mr;
> +AddressSpace dram_as;
> +} AspeedHACEState;
> +
> +#endif /* _ASPEED_HACE_H_ */
> diff --git a/hw/misc/aspeed_hace.c b/hw/misc/aspeed_hace.c
> new file mode 100644
> index ..0e402a0adea9
> --- /dev/null
> +++ b/hw/misc/aspeed_hace.c
> @@ -0,0 +1,302 @@
> +/*
> + * ASPEED Hash and Crypto Engine
> + *
> + * Copyright (C) 2021 IBM Corp.
> + *
> + * Joel Stanley 
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/log.h"
> +#include "qemu/error-report.h"
> +#include "hw/misc/aspeed_hace.h"
> +#include "qapi/error.h"
> +#include "migration/vmstate.h"
> +#include "crypto/hash.h"
> +#include "hw/qdev-properties.h"
> +#include "hw/irq.h"
> +
> +#define R_STATUS(0x1c / 4)
> +#define HASH_IRQBIT(9)
> +#define CRYPT_IRQ   BIT(12)
> +#define TAG_IRQ BIT(15)
> +
> +#define R_HASH_CMD  (0x30 / 4)
> +/* Hash algorithim selection */
> +#define  HASH_ALGO_MASK (BIT(4) | BIT(5) | BIT(6))

Hmm, feels GENMASK()-y, but looks like the tree is in a bit of a weird 
state in that respect:

$ git grep GENMASK
include/hw/usb/dwc2-regs.h:#define GSNPSID_ID_MASK  
GENMASK(31, 16)
include/standard-headers/asm-x86/kvm_para.h:#define KVM_ASYNC_PF_VEC_MASK   
GENMASK(7, 0)
$

> +#define  HASH_ALGO_MD5  0
> +#define  HASH_ALGO_SHA1 BIT(5)
> +#define  HASH_ALGO_SHA224   BIT(6)
> +#define  HASH_ALGO_SHA256   (BIT(4) | BIT(6))

Not something you need to fix necessarily, but it would feel more 
intuitive to me to order these MSB to LSB, so e.g. (BIT(6) | BIT(4)). 
That way I can "see" the value without having to reverse the bits.

> +#define  HASH_ALGO_SHA512_SERIES(BIT(5) | BIT(6))
> +/* SHA512 algorithim selection */
> +#define  SHA512_HASH_ALGO_MASK  (BIT(10) | BIT(11) | BIT(12))
> +#define  HASH_ALGO_SHA512_SHA5120
> +#define  HASH_ALGO_SHA512_SHA384BIT(10)
> +#define  HASH_ALGO_SHA512_SHA256BIT(11)
> +#define  HASH_ALGO_SHA512_SHA224(BIT(10) | BIT(11))
> +/* HMAC modes */
> +#define  HASH_HMAC_MASK (BIT(7) | BIT(8))
> +#define  HASH_DIGEST0
> +#define  HASH_DIGEST_HMAC   BIT(7)
> +#define  HASH_DIGEST_ACCUM  BIT(8)
> +#define  HASH_HMAC_KEY  (BIT(7) | BIT(8))
> +/* Cascscaed operation modes */
> +#define  HASH_ONLY  0
> +#define  HASH_ONLY2 BIT(0)
> +#define  HASH_CRYPT_THEN_HASH   BIT(1)
> +#define  HASH_HASH_THEN_CRYPT   (BIT(0) | BIT(1))
> +/* Other cmd bits */
> +#define  HASH_IRQ_ENBIT(9)
> +#define  HASH_SG_EN BIT(18)
> +
> +#define R_CRYPT_CMD (0x10 / 4)
> +
> +#define R_HASH_SRC  (0x20 / 4)
> +#define R_HASH_DEST (0x24 / 4)
> +#define R_HASH_SRC_LEN  (0x2c / 4)

In general, ordering the registers and fields in datasheet-order is 
helpful to me as a reviewer...

> +
> +static int do_hash_operation(AspeedHACEState *s, int algo)
> +{
> +hwaddr src, len, dest;
> +uint8_t *digest_buf = NULL;
> +size_t digest_len = 0;
> +char *src_buf;
> +int rc;
> +
> +src = s->regs[R_HASH_SRC];
> +len = s->regs[R_HASH_SRC_LEN];
> +dest = 

[PATCH v2 2/4] block: check for sys/disk.h

[Joelle van Dyne]

Some BSD platforms do not have this header.

Signed-off-by: Joelle van Dyne 
---
 meson.build | 1 +
 block.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 0e53876f69..ba0db9fa1f 100644
--- a/meson.build
+++ b/meson.build
@@ -1153,6 +1153,7 @@ config_host_data.set('HAVE_SYS_IOCCOM_H', 
cc.has_header('sys/ioccom.h'))
 config_host_data.set('HAVE_SYS_KCOV_H', cc.has_header('sys/kcov.h'))
 config_host_data.set('HAVE_SYSTEM_FUNCTION', cc.has_function('system', prefix: 
'#include '))
 config_host_data.set('HAVE_HOST_BLOCK_DEVICE', have_host_block_device)
+config_host_data.set('HAVE_SYS_DISK_H', cc.has_header('sys/disk.h'))
 
 config_host_data.set('CONFIG_PREADV', cc.has_function('preadv', prefix: 
'#include '))
 
diff --git a/block.c b/block.c
index a1f3cecd75..b2705ad225 100644
--- a/block.c
+++ b/block.c
@@ -54,7 +54,7 @@
 #ifdef CONFIG_BSD
 #include 
 #include 
-#ifndef __DragonFly__
+#if defined(HAVE_SYS_DISK_H)
 #include 
 #endif
 #endif
-- 
2.28.0

[PATCH v2 3/4] block: detect DKIOCGETBLOCKCOUNT/SIZE before use

[Joelle van Dyne]

iOS hosts do not have these defined so we fallback to the
default behaviour.

Co-authored-by: Warner Losh 
Signed-off-by: Joelle van Dyne 
---
 block/file-posix.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index d1ab3180ff..9b6d7ddda3 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -2326,8 +2326,10 @@ static int64_t raw_getlength(BlockDriverState *bs)
 again:
 #endif
 if (!fstat(fd, ) && (S_IFCHR & sb.st_mode)) {
+size = 0;
 #ifdef DIOCGMEDIASIZE
 if (ioctl(fd, DIOCGMEDIASIZE, (off_t *)))
+size = 0;
 #elif defined(DIOCGPART)
 {
 struct partinfo pi;
@@ -2336,9 +2338,7 @@ again:
 else
 size = 0;
 }
-if (size == 0)
-#endif
-#if defined(__APPLE__) && defined(__MACH__)
+#elif defined(DKIOCGETBLOCKCOUNT) && defined(DKIOCGETBLOCKSIZE)
 {
 uint64_t sectors = 0;
 uint32_t sector_size = 0;
@@ -2346,19 +2346,15 @@ again:
 if (ioctl(fd, DKIOCGETBLOCKCOUNT, ) == 0
&& ioctl(fd, DKIOCGETBLOCKSIZE, _size) == 0) {
 size = sectors * sector_size;
-} else {
-size = lseek(fd, 0LL, SEEK_END);
-if (size < 0) {
-return -errno;
-}
 }
 }
-#else
-size = lseek(fd, 0LL, SEEK_END);
+#endif
+if (size == 0) {
+size = lseek(fd, 0LL, SEEK_END);
+}
 if (size < 0) {
 return -errno;
 }
-#endif
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 switch(s->type) {
 case FTYPE_CD:
-- 
2.28.0

[PATCH v2 4/4] slirp: feature detection for smbd

[Joelle van Dyne]

Replace Windows specific macro with a more generic feature detection
macro. Allows slirp smb feature to be disabled manually as well.

Signed-off-by: Joelle van Dyne 
---
 configure   | 26 +++---
 meson.build |  2 +-
 net/slirp.c | 16 
 3 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/configure b/configure
index 34fccaa2ba..8335a3e6a0 100755
--- a/configure
+++ b/configure
@@ -465,6 +465,7 @@ fuse_lseek="auto"
 multiprocess="auto"
 
 malloc_trim="auto"
+slirp_smbd="auto"
 
 # parse CC options second
 for opt do
@@ -834,8 +835,6 @@ do
 fi
 done
 
-: ${smbd=${SMBD-/usr/sbin/smbd}}
-
 # Default objcc to clang if available, otherwise use CC
 if has clang; then
   objcc=clang
@@ -1560,6 +1559,10 @@ for opt do
   ;;
   --disable-multiprocess) multiprocess="disabled"
   ;;
+  --enable-slirp-smbd) slirp_smbd=yes
+  ;;
+  --disable-slirp-smbd) slirp_smbd=no
+  ;;
   *)
   echo "ERROR: unknown option $opt"
   echo "Try '$0 --help' for more information"
@@ -1913,6 +1916,7 @@ disabled with --disable-FEATURE, default is enabled if 
available
   fuseFUSE block device export
   fuse-lseek  SEEK_HOLE/SEEK_DATA support for FUSE exports
   multiprocessOut of process device emulation support
+  slirp-smbd  use smbd (at path --smbd=*) in slirp networking
 
 NOTE: The object files are built at the place where configure is launched
 EOF
@@ -5252,6 +5256,19 @@ case "$slirp" in
 ;;
 esac
 
+# Check for slirp smbd dupport
+: ${smbd=${SMBD-/usr/sbin/smbd}}
+if test "$slirp_smbd" != "no" ; then
+  if test "$mingw32" = "yes" ; then
+if test "$slirp_smbd" = "yes" ; then
+  error_exit "Host smbd not supported on this platform."
+fi
+slirp_smbd=no
+  else
+slirp_smbd=yes
+  fi
+fi
+
 ##
 # check for usable __NR_keyctl syscall
 
@@ -5527,7 +5544,10 @@ fi
 if test "$guest_agent" = "yes" ; then
   echo "CONFIG_GUEST_AGENT=y" >> $config_host_mak
 fi
-echo "CONFIG_SMBD_COMMAND=\"$smbd\"" >> $config_host_mak
+if test "$slirp_smbd" = "yes" ; then
+  echo "CONFIG_SLIRP_SMBD=y" >> $config_host_mak
+  echo "CONFIG_SMBD_COMMAND=\"$smbd\"" >> $config_host_mak
+fi
 if test "$vde" = "yes" ; then
   echo "CONFIG_VDE=y" >> $config_host_mak
   echo "VDE_LIBS=$vde_libs" >> $config_host_mak
diff --git a/meson.build b/meson.build
index ba0db9fa1f..cad70a8fc5 100644
--- a/meson.build
+++ b/meson.build
@@ -2424,7 +2424,7 @@ summary_info += {'genisoimage':   
config_host['GENISOIMAGE']}
 if targetos == 'windows' and config_host.has_key('CONFIG_GUEST_AGENT')
   summary_info += {'wixl':wixl.found() ? wixl.full_path() : false}
 endif
-if slirp_opt != 'disabled'
+if slirp_opt != 'disabled' and 'CONFIG_SLIRP_SMBD' in config_host
   summary_info += {'smbd':config_host['CONFIG_SMBD_COMMAND']}
 endif
 summary(summary_info, bool_yn: true, section: 'Host binaries')
diff --git a/net/slirp.c b/net/slirp.c
index be914c0be0..b3ded2aac1 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -27,7 +27,7 @@
 #include "net/slirp.h"
 
 
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 #include 
 #include 
 #endif
@@ -90,7 +90,7 @@ typedef struct SlirpState {
 Slirp *slirp;
 Notifier poll_notifier;
 Notifier exit_notifier;
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 gchar *smb_dir;
 #endif
 GSList *fwd;
@@ -103,7 +103,7 @@ static QTAILQ_HEAD(, SlirpState) slirp_stacks =
 static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp);
 static int slirp_guestfwd(SlirpState *s, const char *config_str, Error **errp);
 
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 static int slirp_smb(SlirpState *s, const char *exported_dir,
  struct in_addr vserver_addr, Error **errp);
 static void slirp_smb_cleanup(SlirpState *s);
@@ -367,7 +367,7 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
 struct in6_addr ip6_prefix;
 struct in6_addr ip6_host;
 struct in6_addr ip6_dns;
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 struct in_addr smbsrv = { .s_addr = 0 };
 #endif
 NetClientState *nc;
@@ -477,7 +477,7 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
 return -1;
 }
 
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 if (vsmbserver && !inet_aton(vsmbserver, )) {
 error_setg(errp, "Failed to parse SMB address");
 return -1;
@@ -592,7 +592,7 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
 }
 }
 }
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 if (smb_export) {
 if (slirp_smb(s, smb_export, smbsrv, errp) < 0) {
 goto error;
@@ -784,7 +784,7 @@ void hmp_hostfwd_add(Monitor *mon, const QDict *qdict)
 
 }
 
-#ifndef _WIN32
+#if defined(CONFIG_SLIRP_SMBD)
 
 /* automatic user mode samba server configuration */
 static void slirp_smb_cleanup(SlirpState *s)
@@ -899,7 +899,7 @@ static int 

[PATCH v2 1/4] block: feature detection for host block support

[Joelle van Dyne]

On Darwin (iOS), there are no system level APIs for directly accessing
host block devices. We detect this at configure time.

Signed-off-by: Joelle van Dyne 
---
 meson.build  |  6 +-
 qapi/block-core.json | 10 +++---
 block/file-posix.c   | 33 ++---
 3 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/meson.build b/meson.build
index 81d760d6e8..0e53876f69 100644
--- a/meson.build
+++ b/meson.build
@@ -181,7 +181,7 @@ if targetos == 'windows'
   include_directories: 
include_directories('.'))
 elif targetos == 'darwin'
   coref = dependency('appleframeworks', modules: 'CoreFoundation')
-  iokit = dependency('appleframeworks', modules: 'IOKit')
+  iokit = dependency('appleframeworks', modules: 'IOKit', required: false)
 elif targetos == 'sunos'
   socket = [cc.find_library('socket'),
 cc.find_library('nsl'),
@@ -1056,6 +1056,9 @@ if get_option('cfi')
   add_global_link_arguments(cfi_flags, native: false, language: ['c', 'cpp', 
'objc'])
 endif
 
+have_host_block_device = (targetos != 'darwin' or
+cc.has_header('IOKit/storage/IOMedia.h'))
+
 #
 # config-host.h #
 #
@@ -1149,6 +1152,7 @@ config_host_data.set('HAVE_PTY_H', cc.has_header('pty.h'))
 config_host_data.set('HAVE_SYS_IOCCOM_H', cc.has_header('sys/ioccom.h'))
 config_host_data.set('HAVE_SYS_KCOV_H', cc.has_header('sys/kcov.h'))
 config_host_data.set('HAVE_SYSTEM_FUNCTION', cc.has_function('system', prefix: 
'#include '))
+config_host_data.set('HAVE_HOST_BLOCK_DEVICE', have_host_block_device)
 
 config_host_data.set('CONFIG_PREADV', cc.has_function('preadv', prefix: 
'#include '))
 
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 9f555d5c1d..0c2cd9e689 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -959,7 +959,8 @@
   'discriminator': 'driver',
   'data': {
   'file': 'BlockStatsSpecificFile',
-  'host_device': 'BlockStatsSpecificFile',
+  'host_device': { 'type': 'BlockStatsSpecificFile',
+   'if': 'defined(HAVE_HOST_BLOCK_DEVICE)' },
   'nvme': 'BlockStatsSpecificNvme' } }
 
 ##
@@ -2863,7 +2864,9 @@
 { 'enum': 'BlockdevDriver',
   'data': [ 'blkdebug', 'blklogwrites', 'blkreplay', 'blkverify', 'bochs',
 'cloop', 'compress', 'copy-on-read', 'dmg', 'file', 'ftp', 'ftps',
-'gluster', 'host_cdrom', 'host_device', 'http', 'https', 'iscsi',
+'gluster', 'host_cdrom',
+{'name': 'host_device', 'if': 'defined(HAVE_HOST_BLOCK_DEVICE)' },
+'http', 'https', 'iscsi',
 'luks', 'nbd', 'nfs', 'null-aio', 'null-co', 'nvme', 'parallels',
 'preallocate', 'qcow', 'qcow2', 'qed', 'quorum', 'raw', 'rbd',
 { 'name': 'replication', 'if': 'defined(CONFIG_REPLICATION)' },
@@ -4066,7 +4069,8 @@
   'ftps':   'BlockdevOptionsCurlFtps',
   'gluster':'BlockdevOptionsGluster',
   'host_cdrom': 'BlockdevOptionsFile',
-  'host_device':'BlockdevOptionsFile',
+  'host_device': { 'type': 'BlockdevOptionsFile',
+   'if': 'defined(HAVE_HOST_BLOCK_DEVICE)' },
   'http':   'BlockdevOptionsCurlHttp',
   'https':  'BlockdevOptionsCurlHttps',
   'iscsi':  'BlockdevOptionsIscsi',
diff --git a/block/file-posix.c b/block/file-posix.c
index 05079b40ca..d1ab3180ff 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -42,6 +42,8 @@
 #include "scsi/constants.h"
 
 #if defined(__APPLE__) && (__MACH__)
+#include 
+#if defined(HAVE_HOST_BLOCK_DEVICE)
 #include 
 #include 
 #include 
@@ -52,6 +54,7 @@
 //#include 
 #include 
 #include 
+#endif /* defined(HAVE_HOST_BLOCK_DEVICE) */
 #endif
 
 #ifdef __sun__
@@ -181,7 +184,17 @@ typedef struct BDRVRawReopenState {
 bool check_cache_dropped;
 } BDRVRawReopenState;
 
-static int fd_open(BlockDriverState *bs);
+static int fd_open(BlockDriverState *bs)
+{
+BDRVRawState *s = bs->opaque;
+
+/* this is just to ensure s->fd is sane (its called by io ops) */
+if (s->fd >= 0) {
+return 0;
+}
+return -EIO;
+}
+
 static int64_t raw_getlength(BlockDriverState *bs);
 
 typedef struct RawPosixAIOData {
@@ -3032,6 +3045,7 @@ static BlockStatsSpecific 
*raw_get_specific_stats(BlockDriverState *bs)
 return stats;
 }
 
+#if defined(HAVE_HOST_BLOCK_DEVICE)
 static BlockStatsSpecific *hdev_get_specific_stats(BlockDriverState *bs)
 {
 BlockStatsSpecific *stats = g_new(BlockStatsSpecific, 1);
@@ -3041,6 +3055,7 @@ static BlockStatsSpecific 
*hdev_get_specific_stats(BlockDriverState *bs)
 
 return stats;
 }
+#endif /* HAVE_HOST_BLOCK_DEVICE */
 
 static QemuOptsList raw_create_opts = {
 .name = "raw-create-opts",
@@ -3265,6 +3280,8 @@ BlockDriver bdrv_file = {
 /***/
 /* host device */
 
+#if defined(HAVE_HOST_BLOCK_DEVICE)
+
 #if defined(__APPLE__) && defined(__MACH__)
 static kern_return_t 

[PATCH v2 0/4] Disable unsupported features on iOS hosts

[Joelle van Dyne]

These patches disables code that cannot be compiled or run on iOS by adding
feature/header detection at configure time.

v2:

* Broken merge where config_host['CONFIG_SMBD_COMMAND'] was duplicated.

-j

Joelle van Dyne (4):
  block: feature detection for host block support
  block: check for sys/disk.h
  block: detect DKIOCGETBLOCKCOUNT/SIZE before use
  slirp: feature detection for smbd

 configure| 26 +++---
 meson.build  |  9 ++--
 qapi/block-core.json | 10 ++---
 block.c  |  2 +-
 block/file-posix.c   | 51 +---
 net/slirp.c  | 16 +++---
 6 files changed, 75 insertions(+), 39 deletions(-)

-- 
2.28.0

What is the intended behaviour of usb_host_get_port for root hubs?

[Ben Leslie]

When usb_host_get_port is called for a root-hub device what string should
be output in the port parameter?

The current behaviour writes a string with whatever stack value happened to
be in the paths stack array.

Possible behaviours that I can see being useful are:

1: Don't modify the port parameter.
2: Write an empty string.

My preference would be for #2, but possibly #1 is intended. I can provide a
patch if someone can let me know the intended behaviour. If #1 is intended,
then I think the usage in hmp_info_usbhost might need changing as well. The
other usage in usb_host_auto_check where the provided port parameter is set
to "-" prior to calling the function; it's not clear what the intent of
that is. Finally, the function returns zero on error and string length on
success (which actually makes #2 a problem), however none of the callers
check the return value, so perhaps it can be made a void function? Or
possibly it should return -1 on error, rather than zero.

Regards,

Ben

Re: [PATCH 2/3] memory: Provide 'base address' argument to mtree_print_mr()

[Peter Xu]

Phil,

On Sat, Mar 06, 2021 at 12:54:13AM +0100, Philippe Mathieu-Daudé wrote:
> @@ -3188,14 +3188,15 @@ void mtree_info(bool flatview, bool dispatch_tree, 
> bool owner, bool disabled)
>  
>  QTAILQ_FOREACH(as, _spaces, address_spaces_link) {
>  qemu_printf("address-space: %s\n", as->name);
> -mtree_print_mr(as->root, 1, 0, _head, owner, disabled);
> +mtree_print_mr(as->root, 1, 0, as->root->addr,

Root MR of any address space should have mr->addr==0, right?

I'm slightly confused on what this patch wanted to do if so, since then "base"
will always be zero..  Or am I wrong?

Thanks,

> +   _head, owner, disabled);
>  qemu_printf("\n");
>  }
>  
>  /* print aliased regions */
>  QTAILQ_FOREACH(ml, _head, mrqueue) {
>  qemu_printf("memory-region: %s\n", memory_region_name(ml->mr));
> -mtree_print_mr(ml->mr, 1, 0, _head, owner, disabled);
> +mtree_print_mr(ml->mr, 1, 0, 0, _head, owner, disabled);
>  qemu_printf("\n");
>  }
>  
> -- 
> 2.26.2
> 

-- 
Peter Xu

[PATCH v2 3/3] target/arm: set ID_AA64ISAR0.TLB to 2 for max AARCH64 CPU type

[Rebecca Cran]

Indicate support for FEAT_TLBIOS and FEAT_TLBIRANGE by setting
ID_AA64ISAR0.TLB to 2 for the max AARCH64 CPU type.

Signed-off-by: Rebecca Cran 
---
 target/arm/cpu64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index c255f1bcc393..e1003fd96138 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -651,6 +651,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);
 t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1);
 t = FIELD_DP64(t, ID_AA64ISAR0, TS, 2); /* v8.5-CondM */
+t = FIELD_DP64(t, ID_AA64ISAR0, TLB, 2);
 t = FIELD_DP64(t, ID_AA64ISAR0, RNDR, 1);
 cpu->isar.id_aa64isar0 = t;
 
-- 
2.26.2

[PATCH v2 2/3] target/arm: Add support for FEAT_TLBIOS

[Rebecca Cran]

ARMv8.4 adds the mandatory FEAT_TLBIOS. It provides TLBI
maintenance instructions that extend to the Outer Shareable domain.

Signed-off-by: Rebecca Cran 
---
 target/arm/cpu.h|  6 ++
 target/arm/helper.c | 75 
 2 files changed, 81 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 782a77c7ca3b..1cab297f0fa6 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -4035,6 +4035,12 @@ static inline bool isar_feature_aa64_tlbirange(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) == 2;
 }
 
+static inline bool isar_feature_aa64_tlbios(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) == 1 ||
+   FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) == 2;
+}
+
 static inline bool isar_feature_aa64_sb(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, SB) != 0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 2505afe5f65c..64d97dfa254d 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7147,6 +7147,78 @@ static const ARMCPRegInfo tlbirange_reginfo[] = {
 REGINFO_SENTINEL
 };
 
+static const ARMCPRegInfo tlbios_reginfo[] = {
+{ .name = "TLBI_VMALLE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vmalle1is_write },
+{ .name = "TLBI_ASIDE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 1, .opc2 = 2,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vmalle1is_write },
+{ .name = "TLBI_RVAE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_RVAAE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 3,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+   { .name = "TLBI_RVALE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_RVAALE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 7,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_ALLE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle2is_write },
+   { .name = "TLBI_ALLE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_VMALLS12E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 6,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_IPAS2E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 0,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_RIPAS2E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 3,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_IPAS2LE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_RIPAS2LE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 7,
+  .access = PL2_W, .type = ARM_CP_NOP },
+   { .name = "TLBI_RVAE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae2is_write },
+   { .name = "TLBI_RVALE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae2is_write },
+{ .name = "TLBI_ALLE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle3is_write },
+   { .name = "TLBI_RVAE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae3is_write },
+   { .name = "TLBI_RVALE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae3is_write },
+REGINFO_SENTINEL
+};
+
 static uint64_t rndr_readfn(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 Error *err = NULL;
@@ -8516,6 

[PATCH v2 1/3] target/arm: Add support for FEAT_TLBIRANGE

[Rebecca Cran]

ARMv8.4 adds the mandatory FEAT_TLBIRANGE. It provides TLBI
maintenance instructions that apply to a range of input addresses.

Signed-off-by: Rebecca Cran 
---
 accel/tcg/cputlb.c  |  67 ++
 include/exec/exec-all.h |  41 
 target/arm/cpu.h|   5 +
 target/arm/helper.c | 248 
 4 files changed, 361 insertions(+)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 8a7b779270a4..ebf91cc4757f 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -590,6 +590,24 @@ static void tlb_flush_page_by_mmuidx_async_2(CPUState *cpu,
 g_free(d);
 }
 
+typedef struct {
+target_ulong addr;
+unsigned int num_pages;
+uint16_t idxmap;
+} TLBFlushPageRangeByMMUIdxData;
+
+static void tlb_flush_page_range_by_mmuidx_async_0(CPUState *cpu,
+   run_on_cpu_data data)
+{
+TLBFlushPageRangeByMMUIdxData *d = data.host_ptr;
+
+tlb_flush_page_range_by_mmuidx(cpu,
+   d->addr,
+   d->num_pages,
+   d->idxmap);
+g_free(d);
+}
+
 void tlb_flush_page_by_mmuidx(CPUState *cpu, target_ulong addr, uint16_t 
idxmap)
 {
 tlb_debug("addr: "TARGET_FMT_lx" mmu_idx:%" PRIx16 "\n", addr, idxmap);
@@ -623,6 +641,55 @@ void tlb_flush_page(CPUState *cpu, target_ulong addr)
 tlb_flush_page_by_mmuidx(cpu, addr, ALL_MMUIDX_BITS);
 }
 
+void tlb_flush_page_range_by_mmuidx(CPUState *cpu, target_ulong addr,
+unsigned int num_pages, uint16_t idxmap)
+{
+int i;
+int mmu_idx;
+target_ulong p;
+CPUArchState *env = cpu->env_ptr;
+
+/* This should already be page aligned */
+addr &= TARGET_PAGE_MASK;
+
+assert_cpu_is_self(cpu);
+
+tlb_debug("page addr:" TARGET_FMT_lx " mmu_map:0x%x\n", addr, idxmap);
+
+qemu_spin_lock(_tlb(env)->c.lock);
+for (i = 0; i < num_pages; i++) {
+for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
+if ((idxmap >> mmu_idx) & 1) {
+p = addr + (i * TARGET_PAGE_SIZE);
+tlb_flush_page_locked(env, mmu_idx, p);
+tb_flush_jmp_cache(cpu, addr);
+}
+}
+}
+qemu_spin_unlock(_tlb(env)->c.lock);
+}
+
+void tlb_flush_page_range_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
+target_ulong addr,
+unsigned int num_pages,
+uint16_t idxmap)
+{
+CPUState *dst_cpu;
+TLBFlushPageRangeByMMUIdxData *d;
+
+CPU_FOREACH(dst_cpu) {
+d = g_new(TLBFlushPageRangeByMMUIdxData, 1);
+
+d->addr = addr;
+d->num_pages = num_pages;
+d->idxmap = idxmap;
+
+async_run_on_cpu(dst_cpu,
+ tlb_flush_page_range_by_mmuidx_async_0,
+ RUN_ON_CPU_HOST_PTR(d));
+}
+}
+
 void tlb_flush_page_by_mmuidx_all_cpus(CPUState *src_cpu, target_ulong addr,
uint16_t idxmap)
 {
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index b7b3c0ef12d9..dcbf11b890b6 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -212,6 +212,35 @@ void tlb_flush_page_by_mmuidx_all_cpus(CPUState *cpu, 
target_ulong addr,
  */
 void tlb_flush_page_by_mmuidx_all_cpus_synced(CPUState *cpu, target_ulong addr,
   uint16_t idxmap);
+/**
+ * tlb_flush_page_range_by_mmuidx:
+ * @cpu: CPU whose TLB should be flushed
+ * @addr: virtual address of start of page range to be flushed
+ * @num_pages: the number of pages to be flushed
+ * @idxmap: bitmap of MMU indexes to flush
+ *
+ * Flush a range of pages from the TLB of the specified CPU, for the specified
+ * MMU indexes.
+ */
+void tlb_flush_page_range_by_mmuidx(CPUState *cpu, target_ulong addr,
+unsigned int num_pages, uint16_t idxmap);
+/**
+ * tlb_flush_page_range_by_mmuidx_all_cpus_synced:
+ * @cpu: Originating CPU of the flush
+ * @addr: virtual address of start of page range to be flushed
+ * @num_pages: the number of pages to be flushed
+ * @idxmap: bitmap of MMU indexes to flush
+ *
+ * Flush a range of pages from the TLB of all CPUs, for the specified MMU
+ * indexes like tlb_flush_page_by_mmuidx_all_cpus except the source
+ * vCPUs work is scheduled as safe work meaning all flushes will be
+ * complete once the source vCPUs safe work is complete. This will
+ * depend on when the guests translation ends the TB.
+ */
+void tlb_flush_page_range_by_mmuidx_all_cpus_synced(CPUState *cpu,
+target_ulong addr,
+unsigned int num_pages,
+uint16_t idxmap);
 /**
  * tlb_flush_by_mmuidx:
  * @cpu: CPU whose TLB should be flushed

[PATCH v2 0/3] target/arm: Add support for FEAT_TLBIOS and FEAT_TLBIRANGE

[Rebecca Cran]

ARMv8.4 adds the mandatory FEAT_TLBIOS and FEAT_TLBIRANGE. 
They provides TLBI maintenance instructions that extend to the Outer
Shareable domain and that apply to a range of input addresses.

Changes from v1 to v2:

o Split new instructions into different ARMCPRegInfo sections, and only
  add them if ID_AA64ISAR0.TLB indicates they're supported.
o Improve the performance of the new code in cputlb.c.

Testing:
  o Ran scripts/checkpatch.pl: functions in exec-all.h fail,
but I think that's acceptable?
  o Built all targets
  o Ran test code that executed the new instructions
  o Ran "make test": a qtest-sparc repeatedly timed out,
but that's unlikely to be due to my changes.

Rebecca Cran (3):
  target/arm: Add support for FEAT_TLBIRANGE
  target/arm: Add support for FEAT_TLBIOS
  target/arm: set ID_AA64ISAR0.TLB to 2 for max AARCH64 CPU type

 accel/tcg/cputlb.c  |  67 
 include/exec/exec-all.h |  41 +++
 target/arm/cpu.h|  11 +
 target/arm/cpu64.c  |   1 +
 target/arm/helper.c | 323 
 5 files changed, 443 insertions(+)

-- 
2.26.2

Re: [PATCH v1 1/1] vfio: Make migration support non experimental by default.

[Alex Williamson]

On Mon, 8 Mar 2021 16:36:34 +
Daniel P. Berrangé  wrote:

> On Mon, Mar 08, 2021 at 09:39:49PM +0530, Tarun Gupta wrote:
> > VFIO migration support in QEMU is experimental as of now, which was done to
> > provide soak time and resolve concerns regarding bit-stream.
> > But, with the patches discussed in
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg784931.html , we have
> > corrected ordering of saving PCI config space and bit-stream.
> > 
> > So, this patch proposes to make vfio migration support in QEMU to be enabled
> > by default. Tested by successfully migrating mdev device.
> > 
> > Signed-off-by: Tarun Gupta 
> > Signed-off-by: Kirti Wankhede 
> > ---
> >  hw/vfio/pci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index f74be78209..15e26f460b 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -3199,7 +3199,7 @@ static Property vfio_pci_dev_properties[] = {
> >  DEFINE_PROP_BIT("x-igd-opregion", VFIOPCIDevice, features,
> >  VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT, false),
> >  DEFINE_PROP_BOOL("x-enable-migration", VFIOPCIDevice,
> > - vbasedev.enable_migration, false),
> > + vbasedev.enable_migration, true),  
> 
> If it isn't experimental then why do we even need an experimental 'x-'
> property at all ?
> 
> IOW, rather than changing this to "true", shouldn't we just be deleting
> the x-enable-migration property entirely and have the code just do the
> right thing.

I don't think it's necessarily invalid to have experimental disables
for supported features.  We actually have quite a few of those already.
Most of them are generally aimed at debugging, for example disabling
direct mappings or acceleration paths that might mask an access when
trying to trace the behavior of a device.  We might want to consider
changing the polarity of the option to avoid user confusion, ie.
x-disable-migration.  I'm not fully convinced that there might not be
valid non-experimental use cases for such an option, but it seems like
that should be supported at a base device class level rather than per
driver, so best to be left experimental here.  Thanks,

Alex

Re: [PATCH v1 1/1] vfio: Make migration support non experimental by default.

[Alex Williamson]

[Cc +Intel]

On Mon, 8 Mar 2021 21:39:49 +0530
Tarun Gupta  wrote:

> VFIO migration support in QEMU is experimental as of now, which was done to
> provide soak time and resolve concerns regarding bit-stream.
> But, with the patches discussed in
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg784931.html , we have
> corrected ordering of saving PCI config space and bit-stream.
> 
> So, this patch proposes to make vfio migration support in QEMU to be enabled
> by default. Tested by successfully migrating mdev device.
> 
> Signed-off-by: Tarun Gupta 
> Signed-off-by: Kirti Wankhede 
> ---
>  hw/vfio/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index f74be78209..15e26f460b 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -3199,7 +3199,7 @@ static Property vfio_pci_dev_properties[] = {
>  DEFINE_PROP_BIT("x-igd-opregion", VFIOPCIDevice, features,
>  VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT, false),
>  DEFINE_PROP_BOOL("x-enable-migration", VFIOPCIDevice,
> - vbasedev.enable_migration, false),
> + vbasedev.enable_migration, true),
>  DEFINE_PROP_BOOL("x-no-mmap", VFIOPCIDevice, vbasedev.no_mmap, false),
>  DEFINE_PROP_BOOL("x-balloon-allowed", VFIOPCIDevice,
>   vbasedev.ram_block_discard_allowed, false),

Looking back at the commit where this was added:

commit cf254988a50d4164c86a356c80b8d3ae0ccaa005
Author: Alex Williamson 
Date:   Mon Nov 9 11:56:02 2020 -0700

vfio: Make migration support experimental

Support for migration of vfio devices is still in flux.  Developers
are attempting to add support for new devices and new architectures,
but none are yet readily available for validation.  We have concerns
whether we're transferring device resources at the right point in the
migration, whether we're guaranteeing that updates during pre-copy are
migrated, and whether we can provide bit-stream compatibility should
any of this change.  Even the question of whether devices should
participate in dirty page tracking during pre-copy seems contentious.
In short, migration support has not had enough soak time and it feels
premature to mark it as supported.

Create an experimental option such that we can continue to develop.

[Retaining previous acks/reviews for a previously identical code
 change with different specifics in the commit log.]

Reviewed-by: Dr. David Alan Gilbert 
Acked-by: Cornelia Huck 
Signed-off-by: Alex Williamson 


What has tangibly changed since then?  I think we have patches on-list
to address the known issue of PCI config space (MSI) ordering, which
related to enabling migration on ARM platforms.  Do we have
significantly more confidence in our ability to make compatible
enhancement to the migration bitstream?  This was a particularly
troublesome point for me if we have any hope of calling this
supportable.  As far as I know, there are still no open source vendor
drivers supporting migration for community testing.  We're also still
missing the documentation that was promised previously, as Connie noted.

Huawei and Intel, what's your confidence level and what can you share
regarding support for this implementation?  Thanks,

Alex

Re: [PATCH v6 0/5] m68k: add Virtual M68k Machine

[Philippe Mathieu-Daudé]

Hi Laurent,

On 3/8/21 10:24 PM, Laurent Vivier wrote:
> The Quadra 800 machine is very limited to run linux, it manages
> only 1 GiB of memory and only some specific interfaces.
> 
> The Virtual M68k Machine is based on Goldfish interfaces defined by Google
> for Android simulator. It uses Goldfish-rtc (timer and RTC),
> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
> 
> https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFIS=
> H-VIRTUAL-HARDWARE.TXT
> 
> The machine is created with 128 virtio-mmio busses, and they can
> be used to add serial console, GPU, disk, NIC, HID, ...
> 
> This series re-use the goldfish-rtc implemented for RISCV, and
> adds the two others based on the goldfish specs, the kernel driver
> and android simulator ones.
> 
> The machine can manage up to 3.2 GiB of memory, not because of an hardware
> limitation but because the kernel crashes after this value.
> 
> Simply configure qemu with:
> 
> .../configure --target-list=3Dm68k-softmmu
> 
> To run the machine you need a modified kernel you can find here:
> 
> https://github.com/vivier/linux/tree/m68k-virt
> 
> You need to compile the kernel with:
> 
> make virt_defconfig
> make vmlinux
> 
> The disk must be installed using the q800 machine because the debian installer
> doesn't want to be used with a kernel that is not the one on the ISO.
> 
> And then you can run the machine with something like:
> 
> qemu-system-m68k -M virt \
>   -m 3399672K \
>   -chardev stdio,signal=3Doff,mux=3Don,id=3Dchar0 \
>   -mon chardev=3Dchar0,mode=3Dreadline \
>   -kernel vmlinux \
>   -append "console=3Dhvc0 root=3D/dev/vda2" \
>   -blockdev node-name=3Dsystem,driver=3Dfile,filename=3Ddebian-10.0.qcow2 \
>   -blockdev node-name=3Ddrive0,driver=3Dqcow2,file=3Dsystem \
>   -device virtio-blk-device,drive=3Ddrive0 \
>   -serial chardev:char0 \
>   -device virtio-net-device,netdev=3Dhostnet0 \
>   -netdev bridge,id=3Dhostnet0,br=3Dvirbr0 \
>   -device virtio-rng-device \
>   -device virtio-serial-device \
>   -device virtio-gpu-device \
>   -device virtconsole,chardev=3Dchar0 \
>   -device virtio-keyboard-device \
>   -device virtio-mouse-device
> 
> if you want to use Goldfish-tty for the console rather than virtconsole, you
> can add "console=3DttyGF".
> 
> To start the debian-installer, you can try by adding:
> 
>   -device virtio-scsi-device \
>   -blockdev node-name=3Ddebian10,driver=3Dfile,filename=3Ddebian-10.0.0-m68k-=
> NETINST-1.iso \
>   -blockdev node-name=3Dcdrom0,driver=3Draw,file=3Ddebian10 \
>   -device scsi-cd,drive=3Dcdrom0 \
>   -initrd installer-m68k/20200315/images/cdrom/initrd.gz
> 
> ISO:https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-12/debian-=
> 10.0.0-m68k-NETINST-1.iso
> initrd: https://cdimage.debian.org/cdimage/ports/debian-installer/2020-10-12/=
> m68k/debian-installer-images_20200315_m68k.tar.gz
> 
> v6:
>   m68k-virt-ctrl:
>   Renamed to virt-ctrl to be generic
>   Add a simple specs document

Thanks for this document! Series LGTM.

I tested doing:

qemu$ docker run -it --rm -v $PWD:$PWD -w $PWD -v /tmp:/tmp -u 0
--network host registry.gitlab.com/qemu-project/qemu/qemu/debian-m68k-cross
# apt-get update
# apt-get install flex bison libssl-dev
# git clone https://github.com/vivier/linux.git
# cd linux
# git checkout m68k-virt
# make O=build ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- virt_defconfig
# make O=build ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- vmlinux -j8

[0.00] Linux version 5.11.0-rc5-2-g8a00b8b1edb (root@x1w)
(m68k-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for
Debian) 2.31.1) #1 Mon Mar 8 22:27:19 UTC 2021

I also tested the Goldfish-tty:

[1.39] printk: console [ttyGF0] enabled
[1.39] printk: console [ttyGF0] enabled
[1.39] printk: bootconsole [early_gf_tty0] disabled
[1.39] printk: bootconsole [early_gf_tty0] disabled

So:
Tested-by: Philippe Mathieu-Daudé 

Don't you want to share a preinstalled qcow2 image like Aurelien?

https://people.debian.org/~aurel32/qemu/

Also, do you plan to add functional testing later?

Regards,

Phil.

[PATCH v2 2/2] hw/arm: versal: Add support for the XRAMs

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Connect the support for the Versal Accelerator RAMs (XRAMs).

Reviewed-by: Luc Michel 
Acked-by: Alistair Francis 
Signed-off-by: Edgar E. Iglesias 
---
 docs/system/arm/xlnx-versal-virt.rst |  1 +
 include/hw/arm/xlnx-versal.h | 13 ++
 hw/arm/xlnx-versal.c | 36 
 3 files changed, 50 insertions(+)

diff --git a/docs/system/arm/xlnx-versal-virt.rst 
b/docs/system/arm/xlnx-versal-virt.rst
index 2602d0f995..27f73500d9 100644
--- a/docs/system/arm/xlnx-versal-virt.rst
+++ b/docs/system/arm/xlnx-versal-virt.rst
@@ -30,6 +30,7 @@ Implemented devices:
 - 8 ADMA (Xilinx zDMA) channels
 - 2 SD Controllers
 - OCM (256KB of On Chip Memory)
+- XRAM (4MB of on chip Accelerator RAM)
 - DDR memory
 
 QEMU does not yet model any other devices, including the PL and the AI Engine.
diff --git a/include/hw/arm/xlnx-versal.h b/include/hw/arm/xlnx-versal.h
index 2b76885afd..22a8fa5d11 100644
--- a/include/hw/arm/xlnx-versal.h
+++ b/include/hw/arm/xlnx-versal.h
@@ -14,6 +14,7 @@
 
 #include "hw/sysbus.h"
 #include "hw/arm/boot.h"
+#include "hw/or-irq.h"
 #include "hw/sd/sdhci.h"
 #include "hw/intc/arm_gicv3.h"
 #include "hw/char/pl011.h"
@@ -22,6 +23,7 @@
 #include "hw/rtc/xlnx-zynqmp-rtc.h"
 #include "qom/object.h"
 #include "hw/usb/xlnx-usb-subsystem.h"
+#include "hw/misc/xlnx-versal-xramc.h"
 
 #define TYPE_XLNX_VERSAL "xlnx-versal"
 OBJECT_DECLARE_SIMPLE_TYPE(Versal, XLNX_VERSAL)
@@ -31,6 +33,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(Versal, XLNX_VERSAL)
 #define XLNX_VERSAL_NR_GEMS2
 #define XLNX_VERSAL_NR_ADMAS   8
 #define XLNX_VERSAL_NR_SDS 2
+#define XLNX_VERSAL_NR_XRAM4
 #define XLNX_VERSAL_NR_IRQS192
 
 struct Versal {
@@ -62,6 +65,11 @@ struct Versal {
 XlnxZDMA adma[XLNX_VERSAL_NR_ADMAS];
 VersalUsb2 usb;
 } iou;
+
+struct {
+qemu_or_irq irq_orgate;
+XlnxXramCtrl ctrl[XLNX_VERSAL_NR_XRAM];
+} xram;
 } lpd;
 
 /* The Platform Management Controller subsystem.  */
@@ -96,6 +104,7 @@ struct Versal {
 #define VERSAL_GEM1_IRQ_0  58
 #define VERSAL_GEM1_WAKE_IRQ_0 59
 #define VERSAL_ADMA_IRQ_0  60
+#define VERSAL_XRAM_IRQ_0  79
 #define VERSAL_RTC_APB_ERR_IRQ 121
 #define VERSAL_SD0_IRQ_0   126
 #define VERSAL_RTC_ALARM_IRQ   142
@@ -128,6 +137,10 @@ struct Versal {
 #define MM_OCM  0xfffcU
 #define MM_OCM_SIZE 0x4
 
+#define MM_XRAM 0xfe80
+#define MM_XRAMC0xff8e
+#define MM_XRAMC_SIZE   0x1
+
 #define MM_USB2_CTRL_REGS   0xFF9D
 #define MM_USB2_CTRL_REGS_SIZE  0x1
 
diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
index 628e77ef66..79609692e4 100644
--- a/hw/arm/xlnx-versal.c
+++ b/hw/arm/xlnx-versal.c
@@ -10,6 +10,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qapi/error.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -278,6 +279,40 @@ static void versal_create_rtc(Versal *s, qemu_irq *pic)
 sysbus_connect_irq(sbd, 1, pic[VERSAL_RTC_APB_ERR_IRQ]);
 }
 
+static void versal_create_xrams(Versal *s, qemu_irq *pic)
+{
+int nr_xrams = ARRAY_SIZE(s->lpd.xram.ctrl);
+DeviceState *orgate;
+int i;
+
+/* XRAM IRQs get ORed into a single line.  */
+object_initialize_child(OBJECT(s), "xram-irq-orgate",
+>lpd.xram.irq_orgate, TYPE_OR_IRQ);
+orgate = DEVICE(>lpd.xram.irq_orgate);
+object_property_set_int(OBJECT(orgate),
+"num-lines", nr_xrams, _fatal);
+qdev_realize(orgate, NULL, _fatal);
+qdev_connect_gpio_out(orgate, 0, pic[VERSAL_XRAM_IRQ_0]);
+
+for (i = 0; i < ARRAY_SIZE(s->lpd.xram.ctrl); i++) {
+SysBusDevice *sbd;
+MemoryRegion *mr;
+
+object_initialize_child(OBJECT(s), "xram[*]", >lpd.xram.ctrl[i],
+TYPE_XLNX_XRAM_CTRL);
+sbd = SYS_BUS_DEVICE(>lpd.xram.ctrl[i]);
+sysbus_realize(sbd, _fatal);
+
+mr = sysbus_mmio_get_region(sbd, 0);
+memory_region_add_subregion(>mr_ps,
+MM_XRAMC + i * MM_XRAMC_SIZE, mr);
+mr = sysbus_mmio_get_region(sbd, 1);
+memory_region_add_subregion(>mr_ps, MM_XRAM + i * MiB, mr);
+
+sysbus_connect_irq(sbd, 0, qdev_get_gpio_in(orgate, i));
+}
+}
+
 /* This takes the board allocated linear DDR memory and creates aliases
  * for each split DDR range/aperture on the Versal address map.
  */
@@ -363,6 +398,7 @@ static void versal_realize(DeviceState *dev, Error **errp)
 versal_create_admas(s, pic);
 versal_create_sds(s, pic);
 versal_create_rtc(s, pic);
+versal_create_xrams(s, pic);
 versal_map_ddr(s);
 versal_unimp(s);
 
-- 
2.25.1

[PATCH v2 1/2] hw/misc: versal: Add a model of the XRAM controller

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add a model of the Xilinx Versal Accelerator RAM (XRAM).
This is mainly a stub to make firmware happy. The size of
the RAMs can be probed. The interrupt mask logic is
modelled but none of the interrups will ever be raised
unless injected.

Signed-off-by: Edgar E. Iglesias 
---
 include/hw/misc/xlnx-versal-xramc.h |  97 +++
 hw/misc/xlnx-versal-xramc.c | 253 
 hw/misc/meson.build |   1 +
 3 files changed, 351 insertions(+)
 create mode 100644 include/hw/misc/xlnx-versal-xramc.h
 create mode 100644 hw/misc/xlnx-versal-xramc.c

diff --git a/include/hw/misc/xlnx-versal-xramc.h 
b/include/hw/misc/xlnx-versal-xramc.h
new file mode 100644
index 00..d3d1862676
--- /dev/null
+++ b/include/hw/misc/xlnx-versal-xramc.h
@@ -0,0 +1,97 @@
+/*
+ * QEMU model of the Xilinx XRAM Controller.
+ *
+ * Copyright (c) 2021 Xilinx Inc.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ * Written by Edgar E. Iglesias 
+ */
+
+#ifndef XLNX_VERSAL_XRAMC_H
+#define XLNX_VERSAL_XRAMC_H
+
+#include "hw/sysbus.h"
+#include "hw/register.h"
+
+#define TYPE_XLNX_XRAM_CTRL "xlnx.versal-xramc"
+
+#define XLNX_XRAM_CTRL(obj) \
+ OBJECT_CHECK(XlnxXramCtrl, (obj), TYPE_XLNX_XRAM_CTRL)
+
+REG32(XRAM_ERR_CTRL, 0x0)
+FIELD(XRAM_ERR_CTRL, UE_RES, 3, 1)
+FIELD(XRAM_ERR_CTRL, PWR_ERR_RES, 2, 1)
+FIELD(XRAM_ERR_CTRL, PZ_ERR_RES, 1, 1)
+FIELD(XRAM_ERR_CTRL, APB_ERR_RES, 0, 1)
+REG32(XRAM_ISR, 0x4)
+FIELD(XRAM_ISR, INV_APB, 0, 1)
+REG32(XRAM_IMR, 0x8)
+FIELD(XRAM_IMR, INV_APB, 0, 1)
+REG32(XRAM_IEN, 0xc)
+FIELD(XRAM_IEN, INV_APB, 0, 1)
+REG32(XRAM_IDS, 0x10)
+FIELD(XRAM_IDS, INV_APB, 0, 1)
+REG32(XRAM_ECC_CNTL, 0x14)
+FIELD(XRAM_ECC_CNTL, FI_MODE, 2, 1)
+FIELD(XRAM_ECC_CNTL, DET_ONLY, 1, 1)
+FIELD(XRAM_ECC_CNTL, ECC_ON_OFF, 0, 1)
+REG32(XRAM_CLR_EXE, 0x18)
+FIELD(XRAM_CLR_EXE, MON_7, 7, 1)
+FIELD(XRAM_CLR_EXE, MON_6, 6, 1)
+FIELD(XRAM_CLR_EXE, MON_5, 5, 1)
+FIELD(XRAM_CLR_EXE, MON_4, 4, 1)
+FIELD(XRAM_CLR_EXE, MON_3, 3, 1)
+FIELD(XRAM_CLR_EXE, MON_2, 2, 1)
+FIELD(XRAM_CLR_EXE, MON_1, 1, 1)
+FIELD(XRAM_CLR_EXE, MON_0, 0, 1)
+REG32(XRAM_CE_FFA, 0x1c)
+FIELD(XRAM_CE_FFA, ADDR, 0, 20)
+REG32(XRAM_CE_FFD0, 0x20)
+REG32(XRAM_CE_FFD1, 0x24)
+REG32(XRAM_CE_FFD2, 0x28)
+REG32(XRAM_CE_FFD3, 0x2c)
+REG32(XRAM_CE_FFE, 0x30)
+FIELD(XRAM_CE_FFE, SYNDROME, 0, 16)
+REG32(XRAM_UE_FFA, 0x34)
+FIELD(XRAM_UE_FFA, ADDR, 0, 20)
+REG32(XRAM_UE_FFD0, 0x38)
+REG32(XRAM_UE_FFD1, 0x3c)
+REG32(XRAM_UE_FFD2, 0x40)
+REG32(XRAM_UE_FFD3, 0x44)
+REG32(XRAM_UE_FFE, 0x48)
+FIELD(XRAM_UE_FFE, SYNDROME, 0, 16)
+REG32(XRAM_FI_D0, 0x4c)
+REG32(XRAM_FI_D1, 0x50)
+REG32(XRAM_FI_D2, 0x54)
+REG32(XRAM_FI_D3, 0x58)
+REG32(XRAM_FI_SY, 0x5c)
+FIELD(XRAM_FI_SY, DATA, 0, 16)
+REG32(XRAM_RMW_UE_FFA, 0x70)
+FIELD(XRAM_RMW_UE_FFA, ADDR, 0, 20)
+REG32(XRAM_FI_CNTR, 0x74)
+FIELD(XRAM_FI_CNTR, COUNT, 0, 24)
+REG32(XRAM_IMP, 0x80)
+FIELD(XRAM_IMP, SIZE, 0, 4)
+REG32(XRAM_PRDY_DBG, 0x84)
+FIELD(XRAM_PRDY_DBG, ISLAND3, 12, 4)
+FIELD(XRAM_PRDY_DBG, ISLAND2, 8, 4)
+FIELD(XRAM_PRDY_DBG, ISLAND1, 4, 4)
+FIELD(XRAM_PRDY_DBG, ISLAND0, 0, 4)
+REG32(XRAM_SAFETY_CHK, 0xff8)
+
+#define XRAM_CTRL_R_MAX (R_XRAM_SAFETY_CHK + 1)
+
+typedef struct XlnxXramCtrl {
+SysBusDevice parent_obj;
+MemoryRegion ram;
+qemu_irq irq;
+
+struct {
+uint64_t size;
+unsigned int encoded_size;
+} cfg;
+
+RegisterInfoArray *reg_array;
+uint32_t regs[XRAM_CTRL_R_MAX];
+RegisterInfo regs_info[XRAM_CTRL_R_MAX];
+} XlnxXramCtrl;
+#endif
diff --git a/hw/misc/xlnx-versal-xramc.c b/hw/misc/xlnx-versal-xramc.c
new file mode 100644
index 00..e5b719a0ed
--- /dev/null
+++ b/hw/misc/xlnx-versal-xramc.c
@@ -0,0 +1,253 @@
+/*
+ * QEMU model of the Xilinx XRAM Controller.
+ *
+ * Copyright (c) 2021 Xilinx Inc.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ * Written by Edgar E. Iglesias 
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "migration/vmstate.h"
+#include "hw/sysbus.h"
+#include "hw/register.h"
+#include "hw/qdev-properties.h"
+#include "hw/irq.h"
+#include "hw/misc/xlnx-versal-xramc.h"
+
+#ifndef XLNX_XRAM_CTRL_ERR_DEBUG
+#define XLNX_XRAM_CTRL_ERR_DEBUG 0
+#endif
+
+static void xram_update_irq(XlnxXramCtrl *s)
+{
+bool pending = s->regs[R_XRAM_ISR] & ~s->regs[R_XRAM_IMR];
+qemu_set_irq(s->irq, pending);
+}
+
+static void xram_isr_postw(RegisterInfo *reg, uint64_t val64)
+{
+XlnxXramCtrl *s = XLNX_XRAM_CTRL(reg->opaque);
+xram_update_irq(s);
+}
+
+static uint64_t xram_ien_prew(RegisterInfo *reg, uint64_t val64)
+{
+XlnxXramCtrl *s = XLNX_XRAM_CTRL(reg->opaque);
+uint32_t val = val64;
+
+s->regs[R_XRAM_IMR] &= ~val;
+xram_update_irq(s);
+return 0;
+}
+
+static uint64_t xram_ids_prew(RegisterInfo *reg, uint64_t val64)
+{
+XlnxXramCtrl *s = XLNX_XRAM_CTRL(reg->opaque);
+uint32_t val = 

[PATCH v2 0/2] hw/arm: versal: Add support for the XRAMs

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

This series adds support for the 4x1MB Versal Accelerator RAMs (XRAMs).
Most of the controller is dummy, but it's got enough to make firmware
and some of our test SW happy.

Cheers,
Edgar

ChangeLog:

v1 -> v2:
* Reduce list of included files in both .h and .c.
* Remove unnecessary MR container around regarray.
* Don't leak regarray.


Edgar E. Iglesias (2):
  hw/misc: versal: Add a model of the XRAM controller
  hw/arm: versal: Add support for the XRAMs

 docs/system/arm/xlnx-versal-virt.rst |   1 +
 include/hw/arm/xlnx-versal.h |  13 ++
 include/hw/misc/xlnx-versal-xramc.h  |  97 ++
 hw/arm/xlnx-versal.c |  36 
 hw/misc/xlnx-versal-xramc.c  | 253 +++
 hw/misc/meson.build  |   1 +
 6 files changed, 401 insertions(+)
 create mode 100644 include/hw/misc/xlnx-versal-xramc.h
 create mode 100644 hw/misc/xlnx-versal-xramc.c

-- 
2.25.1

[PATCH v3] bsd-user: Add new maintainers

[Warner Losh]

The FreeBSD project has a number of enhancements to bsd-user. These changes have
evolved over the past 10 year, and aren't currently updated to the latest
version of qemu due to fluxuations in staffing causing us to fall behind in the
past. We're working on porting all the changes forward and contributing all the
changes back to qemu. Add myself as maintainer and Kyle Evans as a reviewer for
changes. In addition, add a pointer to our github repo in the interim while this
work is ongoing.

Signed-off-by: Warner Losh 
Reviewed-by: Thomas Huth 
---
 MAINTAINERS | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 26c9454823..ec0e935038 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2896,9 +2896,12 @@ F: thunk.c
 F: accel/tcg/user-exec*.c
 
 BSD user
-S: Orphan
+M: Warner Losh 
+R: Kyle Evans 
+S: Maintained
 F: bsd-user/
 F: default-configs/targets/*-bsd-user.mak
+T: git https://github.com/qemu-bsd-user/qemu-bsd-user bsd-user-rebase-3.1
 
 Linux user
 M: Laurent Vivier 
-- 
2.30.0

Re: [PATCH v1 1/2] hw/misc: versal: Add a model of the XRAM controller

[Edgar E. Iglesias]

On Mon, Mar 08, 2021 at 04:54:26PM +, Peter Maydell wrote:
> On Tue, 2 Mar 2021 at 11:09, Edgar E. Iglesias  
> wrote:
> >
> > From: "Edgar E. Iglesias" 
> >
> > Add a model of the Xilinx Versal Accelerator RAM (XRAM).
> > This is mainly a stub to make firmware happy. The size of
> > the RAMs can be probed. The interrupt mask logic is
> > modelled but none of the interrups will ever be raised
> > unless injected.
> >
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >  include/hw/misc/xlnx-versal-xramc.h | 102 +++
> >  hw/misc/xlnx-versal-xramc.c | 253 
> >  hw/misc/meson.build |   1 +
> >  3 files changed, 356 insertions(+)
> >  create mode 100644 include/hw/misc/xlnx-versal-xramc.h
> >  create mode 100644 hw/misc/xlnx-versal-xramc.c
> >
> > diff --git a/include/hw/misc/xlnx-versal-xramc.h 
> > b/include/hw/misc/xlnx-versal-xramc.h
> > new file mode 100644
> > index 00..68163cf330
> > --- /dev/null
> > +++ b/include/hw/misc/xlnx-versal-xramc.h
> > @@ -0,0 +1,102 @@
> > +/*
> > + * QEMU model of the Xilinx XRAM Controller.
> > + *
> > + * Copyright (c) 2021 Xilinx Inc.
> > + * SPDX-License-Identifier: GPL-2.0-or-later
> > + * Written by Edgar E. Iglesias 
> > + */
> > +
> > +#ifndef XLNX_VERSAL_XRAMC_H
> > +#define XLNX_VERSAL_XRAMC_H
> > +
> > +#include "qemu/osdep.h"
> 
> Headers must never include osdep.h.
> 
> > +#include "hw/sysbus.h"
> > +#include "hw/register.h"
> > +#include "qemu/bitops.h"
> > +#include "qemu/log.h"
> > +#include "migration/vmstate.h"
> > +#include "hw/irq.h"
> 
> I bet you don't really need all of these includes in the header file;
> some of them belong in the .c file.

Yep, I'll cleanup the header files in v2.


> 
> > +static void xram_ctrl_init(Object *obj)
> > +{
> > +XlnxXramCtrl *s = XLNX_XRAM_CTRL(obj);
> > +SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
> > +RegisterInfoArray *reg_array;
> > +
> > +memory_region_init(>iomem, obj, TYPE_XLNX_XRAM_CTRL,
> > +   XRAM_CTRL_R_MAX * 4);
> > +reg_array =
> > +register_init_block32(DEVICE(obj), xram_ctrl_regs_info,
> > +  ARRAY_SIZE(xram_ctrl_regs_info),
> > +  s->regs_info, s->regs,
> > +  _ctrl_ops,
> > +  XLNX_XRAM_CTRL_ERR_DEBUG,
> > +  XRAM_CTRL_R_MAX * 4);
> > +memory_region_add_subregion(>iomem,
> > +0x0,
> > +_array->mem);
> 
> Isn't this just creating a container region that contains
> exactly one subregion that is the same size as it? Do we
> need to do this so that the reg_array is disposed of via
> refcounting or something ?

TBH I was just copying a pattern here. It looks to me like if
reg_array gets leaked and we're using an unnecesarry container MR.
I'll fix this in v2 (if I understood the life-cycle
of these regs correctly).

Cheers,
Edgar

Re: [PATCH v6 5/5] m68k: add Virtual M68k Machine

[Philippe Mathieu-Daudé]

On 3/8/21 10:25 PM, Laurent Vivier wrote:
> The machine is based on Goldfish interfaces defined by Google
> for Android simulator. It uses Goldfish-rtc (timer and RTC),
> Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).
> 
> The machine is created with 128 virtio-mmio bus, and they can
> be used to use serial console, GPU, disk, NIC, HID, ...
> 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Richard Henderson 
> ---
>  default-configs/devices/m68k-softmmu.mak  |   1 +
>  .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
>  hw/m68k/virt.c| 313 ++
>  MAINTAINERS   |  13 +
>  hw/m68k/Kconfig   |  10 +
>  hw/m68k/meson.build   |   1 +
>  6 files changed, 356 insertions(+)
>  create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
>  create mode 100644 hw/m68k/virt.c

> +config M68K_VIRT
> +bool
> +select M68K_IRQC
> +select VIRT_CTRL
> +select GOLDFISH_PIC
> +select GOLDFISH_TTY
> +select GOLDFISH_RTC
> +select VIRTIO

You don't seem to use VIRTIO directly but via VIRTIO_MMIO
which already selects VIRTIO, so you could remove this
line (keeping the next one). Just nitpicking...

> +select VIRTIO_MMIO

Re: [PATCH v6 4/5] m68k: add a system controller

[Philippe Mathieu-Daudé]

On 3/8/21 10:25 PM, Laurent Vivier wrote:
> Add a system controller for the m68k-virt machine.
> This controller allows the kernel to power off or reset the machine.
> 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Richard Henderson 
> ---
>  docs/specs/virt-ctlr.txt|  26 +++
>  include/hw/misc/virt_ctrl.h |  22 ++
>  hw/misc/virt_ctrl.c | 151 
>  hw/misc/Kconfig |   3 +
>  hw/misc/meson.build |   3 +
>  hw/misc/trace-events|   7 ++
>  6 files changed, 212 insertions(+)
>  create mode 100644 docs/specs/virt-ctlr.txt
>  create mode 100644 include/hw/misc/virt_ctrl.h
>  create mode 100644 hw/misc/virt_ctrl.c

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v3 3/3] migration/ram: Optimize ram_save_host_page()

[Peter Xu]

On Mon, Mar 08, 2021 at 09:58:02PM +0800, Kunkun Jiang wrote:
> Hi,
> 
> On 2021/3/5 22:30, Peter Xu wrote:
> > On Fri, Mar 05, 2021 at 03:50:35PM +0800, Kunkun Jiang wrote:
> > > Starting from pss->page, ram_save_host_page() will check every page
> > > and send the dirty pages up to the end of the current host page or
> > > the boundary of used_length of the block. If the host page size is
> > > a huge page, the step "check" will take a lot of time.
> > > 
> > > This will improve performance to use migration_bitmap_find_dirty().
> > Is there any measurement done?
> I tested it on Kunpeng 920.  VM params: 1U 4G( page size 1G).
> The time of ram_save_host_page() in the last round of ram saving:
> before optimize: 9250us   after optimize: 34us

Looks like an idle VM, but still this is a great improvement.  Would you mind
add this into the commit message too?

> > This looks like an optimization, but to me it seems to have changed a lot
> > context that it doesn't need to... Do you think it'll also work to just 
> > look up
> > dirty again and update pss->page properly if migration_bitmap_clear_dirty()
> > returned zero?
> > 
> > Thanks,
> This just inverted the body of the loop, suggested by @David Edmondson.
> Here is the v2[1]. Do you mean to change it like this?
> 
> [1]: 
> http://patchwork.ozlabs.org/project/qemu-devel/patch/20210301082132.1107-4-jiangkun...@huawei.com/

I see, then it's okay - But indeed I still prefer your previous version. :)

Thanks,

-- 
Peter Xu

[PATCH v6 4/5] m68k: add a system controller

[Laurent Vivier]

Add a system controller for the m68k-virt machine.
This controller allows the kernel to power off or reset the machine.

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
---
 docs/specs/virt-ctlr.txt|  26 +++
 include/hw/misc/virt_ctrl.h |  22 ++
 hw/misc/virt_ctrl.c | 151 
 hw/misc/Kconfig |   3 +
 hw/misc/meson.build |   3 +
 hw/misc/trace-events|   7 ++
 6 files changed, 212 insertions(+)
 create mode 100644 docs/specs/virt-ctlr.txt
 create mode 100644 include/hw/misc/virt_ctrl.h
 create mode 100644 hw/misc/virt_ctrl.c

diff --git a/docs/specs/virt-ctlr.txt b/docs/specs/virt-ctlr.txt
new file mode 100644
index ..24d38084f7fd
--- /dev/null
+++ b/docs/specs/virt-ctlr.txt
@@ -0,0 +1,26 @@
+Virtual System Controller
+=
+
+This device is a simple interface defined for the pure virtual machine with no
+hardware reference implementation to allow the guest kernel to send command
+to the host hypervisor.
+
+The specification can evolve, the current state is defined as below.
+
+This is a MMIO mapped device using 256 bytes.
+
+Two 32bit registers are defined:
+
+1- the features register (read-only, address 0x00)
+
+   This register allows the device to report features supported by the
+   controller.
+   The only feature supported for the moment is power control (0x01).
+
+2- the command register (write-only, address 0x04)
+
+   This register allows the kernel to send the commands to the hypervisor.
+   The implemented commands are part of the power control feature and
+   are reset (1), halt (2) and panic (3).
+   A basic command, no-op (0), is always present and can be used to test the
+   register access. This command has no effect.
diff --git a/include/hw/misc/virt_ctrl.h b/include/hw/misc/virt_ctrl.h
new file mode 100644
index ..edfadc469505
--- /dev/null
+++ b/include/hw/misc/virt_ctrl.h
@@ -0,0 +1,22 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Virt system Controller
+ */
+
+#ifndef VIRT_CTRL_H
+#define VIRT_CTRL_H
+
+#define TYPE_VIRT_CTRL "virt-ctrl"
+OBJECT_DECLARE_SIMPLE_TYPE(VirtCtrlState, VIRT_CTRL)
+
+struct VirtCtrlState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+qemu_irq irq;
+
+uint32_t irq_enabled;
+};
+
+#endif
diff --git a/hw/misc/virt_ctrl.c b/hw/misc/virt_ctrl.c
new file mode 100644
index ..2ea01bd7a1f0
--- /dev/null
+++ b/hw/misc/virt_ctrl.c
@@ -0,0 +1,151 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Virt system Controller
+ */
+
+#include "qemu/osdep.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "sysemu/runstate.h"
+#include "hw/misc/virt_ctrl.h"
+
+enum {
+REG_FEATURES = 0x00,
+REG_CMD  = 0x04,
+};
+
+#define FEAT_POWER_CTRL 0x0001
+
+enum {
+CMD_NOOP,
+CMD_RESET,
+CMD_HALT,
+CMD_PANIC,
+};
+
+static uint64_t virt_ctrl_read(void *opaque, hwaddr addr, unsigned size)
+{
+VirtCtrlState *s = opaque;
+uint64_t value = 0;
+
+switch (addr) {
+case REG_FEATURES:
+value = FEAT_POWER_CTRL;
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: unimplemented register read 0x%02"HWADDR_PRIx"\n",
+  __func__, addr);
+break;
+}
+
+trace_virt_ctrl_write(s, addr, size, value);
+
+return value;
+}
+
+static void virt_ctrl_write(void *opaque, hwaddr addr, uint64_t value,
+unsigned size)
+{
+VirtCtrlState *s = opaque;
+
+trace_virt_ctrl_write(s, addr, size, value);
+
+switch (addr) {
+case REG_CMD:
+switch (value) {
+case CMD_NOOP:
+break;
+case CMD_RESET:
+qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+break;
+case CMD_HALT:
+qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
+break;
+case CMD_PANIC:
+qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_PANIC);
+break;
+}
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: unimplemented register write 0x%02"HWADDR_PRIx"\n",
+  __func__, addr);
+break;
+}
+}
+
+static const MemoryRegionOps virt_ctrl_ops = {
+.read = virt_ctrl_read,
+.write = virt_ctrl_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid.max_access_size = 4,
+.impl.max_access_size = 4,
+};
+
+static void virt_ctrl_reset(DeviceState *dev)
+{
+VirtCtrlState *s = VIRT_CTRL(dev);
+
+trace_virt_ctrl_reset(s);
+}
+
+static void virt_ctrl_realize(DeviceState *dev, Error **errp)
+{
+VirtCtrlState *s = VIRT_CTRL(dev);
+
+trace_virt_ctrl_instance_init(s);
+
+memory_region_init_io(>iomem, OBJECT(s), _ctrl_ops, s,
+  

[PATCH v6 2/5] intc: add goldfish-pic

[Laurent Vivier]

Implement the goldfish pic device as defined in

https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/intc/goldfish_pic.h |  33 +
 hw/intc/goldfish_pic.c | 219 +
 hw/intc/Kconfig|   3 +
 hw/intc/meson.build|   1 +
 hw/intc/trace-events   |   8 ++
 5 files changed, 264 insertions(+)
 create mode 100644 include/hw/intc/goldfish_pic.h
 create mode 100644 hw/intc/goldfish_pic.c

diff --git a/include/hw/intc/goldfish_pic.h b/include/hw/intc/goldfish_pic.h
new file mode 100644
index ..ad13ab37fc3e
--- /dev/null
+++ b/include/hw/intc/goldfish_pic.h
@@ -0,0 +1,33 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Goldfish PIC
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#ifndef HW_INTC_GOLDFISH_PIC_H
+#define HW_INTC_GOLDFISH_PIC_H
+
+#define TYPE_GOLDFISH_PIC "goldfish_pic"
+OBJECT_DECLARE_SIMPLE_TYPE(GoldfishPICState, GOLDFISH_PIC)
+
+#define GOLDFISH_PIC_IRQ_NB 32
+
+struct GoldfishPICState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+qemu_irq irq;
+
+uint32_t pending;
+uint32_t enabled;
+
+/* statistics */
+uint64_t stats_irq_count[32];
+/* for tracing */
+uint8_t idx;
+};
+
+#endif
diff --git a/hw/intc/goldfish_pic.c b/hw/intc/goldfish_pic.c
new file mode 100644
index ..e3b43a69f163
--- /dev/null
+++ b/hw/intc/goldfish_pic.c
@@ -0,0 +1,219 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Goldfish PIC
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "monitor/monitor.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "hw/intc/intc.h"
+#include "hw/intc/goldfish_pic.h"
+
+/* registers */
+
+enum {
+REG_STATUS  = 0x00,
+REG_IRQ_PENDING = 0x04,
+REG_IRQ_DISABLE_ALL = 0x08,
+REG_DISABLE = 0x0c,
+REG_ENABLE  = 0x10,
+};
+
+static bool goldfish_pic_get_statistics(InterruptStatsProvider *obj,
+uint64_t **irq_counts,
+unsigned int *nb_irqs)
+{
+GoldfishPICState *s = GOLDFISH_PIC(obj);
+
+*irq_counts = s->stats_irq_count;
+*nb_irqs = ARRAY_SIZE(s->stats_irq_count);
+return true;
+}
+
+static void goldfish_pic_print_info(InterruptStatsProvider *obj, Monitor *mon)
+{
+GoldfishPICState *s = GOLDFISH_PIC(obj);
+monitor_printf(mon, "goldfish-pic.%d: pending=0x%08x enabled=0x%08x\n",
+   s->idx, s->pending, s->enabled);
+}
+
+static void goldfish_pic_update(GoldfishPICState *s)
+{
+if (s->pending & s->enabled) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static void goldfish_irq_request(void *opaque, int irq, int level)
+{
+GoldfishPICState *s = opaque;
+
+trace_goldfish_irq_request(s, s->idx, irq, level);
+
+if (level) {
+s->pending |= 1 << irq;
+s->stats_irq_count[irq]++;
+} else {
+s->pending &= ~(1 << irq);
+}
+goldfish_pic_update(s);
+}
+
+static uint64_t goldfish_pic_read(void *opaque, hwaddr addr,
+  unsigned size)
+{
+GoldfishPICState *s = opaque;
+uint64_t value = 0;
+
+switch (addr) {
+case REG_STATUS:
+/* The number of pending interrupts (0 to 32) */
+value = ctpop32(s->pending & s->enabled);
+break;
+case REG_IRQ_PENDING:
+/* The pending interrupt mask */
+value = s->pending & s->enabled;
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: unimplemented register read 0x%02"HWADDR_PRIx"\n",
+  __func__, addr);
+break;
+}
+
+trace_goldfish_pic_read(s, s->idx, addr, size, value);
+
+return value;
+}
+
+static void goldfish_pic_write(void *opaque, hwaddr addr,
+   uint64_t value, unsigned size)
+{
+GoldfishPICState *s = opaque;
+
+trace_goldfish_pic_write(s, s->idx, addr, size, value);
+
+switch (addr) {
+case REG_IRQ_DISABLE_ALL:
+s->enabled = 0;
+s->pending = 0;
+break;
+case REG_DISABLE:
+s->enabled &= ~value;
+break;
+case REG_ENABLE:
+s->enabled |= value;
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: unimplemented register write 0x%02"HWADDR_PRIx"\n",
+  __func__, addr);
+break;
+}
+goldfish_pic_update(s);
+}
+
+static const MemoryRegionOps goldfish_pic_ops = {
+.read = goldfish_pic_read,
+.write = goldfish_pic_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid.max_access_size = 4,
+.impl.min_access_size = 4,
+   

[PATCH v6 5/5] m68k: add Virtual M68k Machine

[Laurent Vivier]

The machine is based on Goldfish interfaces defined by Google
for Android simulator. It uses Goldfish-rtc (timer and RTC),
Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).

The machine is created with 128 virtio-mmio bus, and they can
be used to use serial console, GPU, disk, NIC, HID, ...

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
---
 default-configs/devices/m68k-softmmu.mak  |   1 +
 .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
 hw/m68k/virt.c| 313 ++
 MAINTAINERS   |  13 +
 hw/m68k/Kconfig   |  10 +
 hw/m68k/meson.build   |   1 +
 6 files changed, 356 insertions(+)
 create mode 100644 include/standard-headers/asm-m68k/bootinfo-virt.h
 create mode 100644 hw/m68k/virt.c

diff --git a/default-configs/devices/m68k-softmmu.mak 
b/default-configs/devices/m68k-softmmu.mak
index 6629fd2aa330..7f8619e42786 100644
--- a/default-configs/devices/m68k-softmmu.mak
+++ b/default-configs/devices/m68k-softmmu.mak
@@ -8,3 +8,4 @@ CONFIG_AN5206=y
 CONFIG_MCF5208=y
 CONFIG_NEXTCUBE=y
 CONFIG_Q800=y
+CONFIG_M68K_VIRT=y
diff --git a/include/standard-headers/asm-m68k/bootinfo-virt.h 
b/include/standard-headers/asm-m68k/bootinfo-virt.h
new file mode 100644
index ..81be1e092497
--- /dev/null
+++ b/include/standard-headers/asm-m68k/bootinfo-virt.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+** asm/bootinfo-virt.h -- Virtual-m68k-specific boot information definitions
+*/
+
+#ifndef _UAPI_ASM_M68K_BOOTINFO_VIRT_H
+#define _UAPI_ASM_M68K_BOOTINFO_VIRT_H
+
+#define BI_VIRT_QEMU_VERSION   0x8000
+#define BI_VIRT_GF_PIC_BASE0x8001
+#define BI_VIRT_GF_RTC_BASE0x8002
+#define BI_VIRT_GF_TTY_BASE0x8003
+#define BI_VIRT_VIRTIO_BASE0x8004
+#define BI_VIRT_CTRL_BASE  0x8005
+
+#define VIRT_BOOTI_VERSION MK_BI_VERSION(2, 0)
+
+#endif /* _UAPI_ASM_M68K_BOOTINFO_MAC_H */
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
new file mode 100644
index ..e9a5d4c69b97
--- /dev/null
+++ b/hw/m68k/virt.c
@@ -0,0 +1,313 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * QEMU Vitual M68K Machine
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qemu-common.h"
+#include "sysemu/sysemu.h"
+#include "cpu.h"
+#include "hw/hw.h"
+#include "hw/boards.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "elf.h"
+#include "hw/loader.h"
+#include "ui/console.h"
+#include "exec/address-spaces.h"
+#include "hw/sysbus.h"
+#include "standard-headers/asm-m68k/bootinfo.h"
+#include "standard-headers/asm-m68k/bootinfo-virt.h"
+#include "bootinfo.h"
+#include "net/net.h"
+#include "qapi/error.h"
+#include "sysemu/qtest.h"
+#include "sysemu/runstate.h"
+#include "sysemu/reset.h"
+
+#include "hw/intc/m68k_irqc.h"
+#include "hw/misc/virt_ctrl.h"
+#include "hw/char/goldfish_tty.h"
+#include "hw/rtc/goldfish_rtc.h"
+#include "hw/intc/goldfish_pic.h"
+#include "hw/virtio/virtio-mmio.h"
+#include "hw/virtio/virtio-blk.h"
+
+/*
+ * 6 goldfish-pic for CPU IRQ #1 to IRQ #6
+ * CPU IRQ #1 -> PIC #1
+ *   IRQ #1 to IRQ #31 -> unused
+ *   IRQ #32 -> goldfish-tty
+ * CPU IRQ #2 -> PIC #2
+ *   IRQ #1 to IRQ #32 -> virtio-mmio from 1 to 32
+ * CPU IRQ #3 -> PIC #3
+ *   IRQ #1 to IRQ #32 -> virtio-mmio from 33 to 64
+ * CPU IRQ #4 -> PIC #4
+ *   IRQ #1 to IRQ #32 -> virtio-mmio from 65 to 96
+ * CPU IRQ #5 -> PIC #5
+ *   IRQ #1 to IRQ #32 -> virtio-mmio from 97 to 128
+ * CPU IRQ #6 -> PIC #6
+ *   IRQ #1 -> goldfish-rtc
+ *   IRQ #2 to IRQ #32 -> unused
+ * CPU IRQ #7 -> NMI
+ */
+
+#define PIC_IRQ_BASE(num) (8 + (num - 1) * 32)
+#define PIC_IRQ(num, irq) (PIC_IRQ_BASE(num) + irq - 1)
+#define PIC_GPIO(pic_irq) (qdev_get_gpio_in(pic_dev[(pic_irq - 8) / 32], \
+(pic_irq - 8) % 32))
+
+#define VIRT_GF_PIC_MMIO_BASE 0xff00 /* MMIO: 0xff00 - 0xff005fff 
*/
+#define VIRT_GF_PIC_IRQ_BASE  1  /* IRQ: #1 -> #6 */
+#define VIRT_GF_PIC_NB6
+
+/* 2 goldfish-rtc (and timer) */
+#define VIRT_GF_RTC_MMIO_BASE 0xff006000 /* MMIO: 0xff006000 - 0xff007fff 
*/
+#define VIRT_GF_RTC_IRQ_BASE  PIC_IRQ(6, 1)  /* PIC: #6, IRQ: #1 */
+#define VIRT_GF_RTC_NB2
+
+/* 1 goldfish-tty */
+#define VIRT_GF_TTY_MMIO_BASE 0xff008000 /* MMIO: 0xff008000 - 0xff008fff 
*/
+#define VIRT_GF_TTY_IRQ_BASE  PIC_IRQ(1, 32) /* PIC: #1, IRQ: #32 */
+
+/* 1 virt-ctrl */
+#define VIRT_CTRL_MMIO_BASE 0xff009000/* MMIO: 0xff009000 - 0xff009fff */
+#define VIRT_CTRL_IRQ_BASE  PIC_IRQ(1, 1) /* PIC: #1, IRQ: #1 */
+
+/*
+ * virtio-mmio size is 0x200 bytes
+ * we use 4 goldfish-pic to attach them,
+ * we can attach 32 virtio devices / goldfish-pic
+ * -> we can manage 32 * 4 = 128 

[PATCH v6 3/5] m68k: add an interrupt controller

[Laurent Vivier]

A (generic) copy of the GLUE device we already have for q800 to use with
the m68k-virt machine.
The q800 one would disappear in the future as q800 uses actually the djMEMC
controller.

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/intc/m68k_irqc.h |  41 +
 hw/intc/m68k_irqc.c | 119 
 hw/intc/Kconfig |   3 +
 hw/intc/meson.build |   1 +
 4 files changed, 164 insertions(+)
 create mode 100644 include/hw/intc/m68k_irqc.h
 create mode 100644 hw/intc/m68k_irqc.c

diff --git a/include/hw/intc/m68k_irqc.h b/include/hw/intc/m68k_irqc.h
new file mode 100644
index ..dbcfcfc2e000
--- /dev/null
+++ b/include/hw/intc/m68k_irqc.h
@@ -0,0 +1,41 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * QEMU Motorola 680x0 IRQ Controller
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#ifndef M68K_IRQC_H
+#define M68K_IRQC_H
+
+#include "hw/sysbus.h"
+
+#define TYPE_M68K_IRQC "m68k-irq-controller"
+#define M68K_IRQC(obj) OBJECT_CHECK(M68KIRQCState, (obj), \
+TYPE_M68K_IRQC)
+
+#define M68K_IRQC_AUTOVECTOR_BASE 25
+
+enum {
+M68K_IRQC_LEVEL_1 = 0,
+M68K_IRQC_LEVEL_2,
+M68K_IRQC_LEVEL_3,
+M68K_IRQC_LEVEL_4,
+M68K_IRQC_LEVEL_5,
+M68K_IRQC_LEVEL_6,
+M68K_IRQC_LEVEL_7,
+};
+#define M68K_IRQC_LEVEL_NUM (M68K_IRQC_LEVEL_7 - M68K_IRQC_LEVEL_1 + 1)
+
+typedef struct M68KIRQCState {
+SysBusDevice parent_obj;
+
+uint8_t ipr;
+
+/* statistics */
+uint64_t stats_irq_count[M68K_IRQC_LEVEL_NUM];
+} M68KIRQCState;
+
+#endif
diff --git a/hw/intc/m68k_irqc.c b/hw/intc/m68k_irqc.c
new file mode 100644
index ..2133d2a698ab
--- /dev/null
+++ b/hw/intc/m68k_irqc.c
@@ -0,0 +1,119 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * QEMU Motorola 680x0 IRQ Controller
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "migration/vmstate.h"
+#include "monitor/monitor.h"
+#include "hw/nmi.h"
+#include "hw/intc/intc.h"
+#include "hw/intc/m68k_irqc.h"
+
+
+static bool m68k_irqc_get_statistics(InterruptStatsProvider *obj,
+ uint64_t **irq_counts, unsigned int 
*nb_irqs)
+{
+M68KIRQCState *s = M68K_IRQC(obj);
+
+*irq_counts = s->stats_irq_count;
+*nb_irqs = ARRAY_SIZE(s->stats_irq_count);
+return true;
+}
+
+static void m68k_irqc_print_info(InterruptStatsProvider *obj, Monitor *mon)
+{
+M68KIRQCState *s = M68K_IRQC(obj);
+monitor_printf(mon, "m68k-irqc: ipr=0x%x\n", s->ipr);
+}
+
+static void m68k_set_irq(void *opaque, int irq, int level)
+{
+M68KIRQCState *s = opaque;
+M68kCPU *cpu = M68K_CPU(first_cpu);
+int i;
+
+if (level) {
+s->ipr |= 1 << irq;
+s->stats_irq_count[irq]++;
+} else {
+s->ipr &= ~(1 << irq);
+}
+
+for (i = M68K_IRQC_LEVEL_7; i >= M68K_IRQC_LEVEL_1; i--) {
+if ((s->ipr >> i) & 1) {
+m68k_set_irq_level(cpu, i + 1, i + M68K_IRQC_AUTOVECTOR_BASE);
+return;
+}
+}
+m68k_set_irq_level(cpu, 0, 0);
+}
+
+static void m68k_irqc_reset(DeviceState *d)
+{
+M68KIRQCState *s = M68K_IRQC(d);
+int i;
+
+s->ipr = 0;
+for (i = 0; i < ARRAY_SIZE(s->stats_irq_count); i++) {
+s->stats_irq_count[i] = 0;
+}
+}
+
+static void m68k_irqc_instance_init(Object *obj)
+{
+qdev_init_gpio_in(DEVICE(obj), m68k_set_irq, M68K_IRQC_LEVEL_NUM);
+}
+
+static void m68k_nmi(NMIState *n, int cpu_index, Error **errp)
+{
+m68k_set_irq(n, M68K_IRQC_LEVEL_7, 1);
+}
+
+static const VMStateDescription vmstate_m68k_irqc = {
+.name = "m68k-irqc",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(ipr, M68KIRQCState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void m68k_irqc_class_init(ObjectClass *oc, void *data)
+ {
+DeviceClass *dc = DEVICE_CLASS(oc);
+NMIClass *nc = NMI_CLASS(oc);
+InterruptStatsProviderClass *ic = INTERRUPT_STATS_PROVIDER_CLASS(oc);
+
+nc->nmi_monitor_handler = m68k_nmi;
+dc->reset = m68k_irqc_reset;
+dc->vmsd = _m68k_irqc;
+ic->get_statistics = m68k_irqc_get_statistics;
+ic->print_info = m68k_irqc_print_info;
+}
+
+static const TypeInfo m68k_irqc_type_info = {
+.name = TYPE_M68K_IRQC,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(M68KIRQCState),
+.instance_init = m68k_irqc_instance_init,
+.class_init = m68k_irqc_class_init,
+.interfaces = (InterfaceInfo[]) {
+ { TYPE_NMI },
+ { TYPE_INTERRUPT_STATS_PROVIDER },
+ { }
+},
+};
+
+static void q800_irq_register_types(void)
+{
+type_register_static(_irqc_type_info);
+}
+
+type_init(q800_irq_register_types);
diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
index c4f8642dae8e..fdb4a30b98e8 100644
--- a/hw/intc/Kconfig
+++ b/hw/intc/Kconfig
@@ -67,3 +67,6 @@ config 

[PATCH v6 1/5] char: add goldfish-tty

[Laurent Vivier]

Implement the goldfish tty device as defined in

https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT

and based on the kernel driver code:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/goldfish.c

Signed-off-by: Laurent Vivier 
Reviewed-by: Philippe Mathieu-Daudé 
---
 include/hw/char/goldfish_tty.h |  35 
 hw/char/goldfish_tty.c | 283 +
 hw/char/Kconfig|   3 +
 hw/char/meson.build|   2 +
 hw/char/trace-events   |  10 ++
 5 files changed, 333 insertions(+)
 create mode 100644 include/hw/char/goldfish_tty.h
 create mode 100644 hw/char/goldfish_tty.c

diff --git a/include/hw/char/goldfish_tty.h b/include/hw/char/goldfish_tty.h
new file mode 100644
index ..b9dd67362a68
--- /dev/null
+++ b/include/hw/char/goldfish_tty.h
@@ -0,0 +1,35 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Goldfish TTY
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#ifndef HW_CHAR_GOLDFISH_TTY_H
+#define HW_CHAR_GOLDFISH_TTY_H
+
+#include "qemu/fifo8.h"
+#include "chardev/char-fe.h"
+
+#define TYPE_GOLDFISH_TTY "goldfish_tty"
+OBJECT_DECLARE_SIMPLE_TYPE(GoldfishTTYState, GOLDFISH_TTY)
+
+#define GOLFISH_TTY_BUFFER_SIZE 128
+
+struct GoldfishTTYState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+qemu_irq irq;
+CharBackend chr;
+
+uint32_t data_len;
+uint64_t data_ptr;
+bool int_enabled;
+
+Fifo8 rx_fifo;
+};
+
+#endif
diff --git a/hw/char/goldfish_tty.c b/hw/char/goldfish_tty.c
new file mode 100644
index ..9f705f8653cc
--- /dev/null
+++ b/hw/char/goldfish_tty.c
@@ -0,0 +1,283 @@
+/*
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ *
+ * Goldfish TTY
+ *
+ * (c) 2020 Laurent Vivier 
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties-system.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "chardev/char-fe.h"
+#include "qemu/log.h"
+#include "trace.h"
+#include "exec/address-spaces.h"
+#include "hw/char/goldfish_tty.h"
+
+/* registers */
+
+enum {
+REG_PUT_CHAR  = 0x00,
+REG_BYTES_READY   = 0x04,
+REG_CMD   = 0x08,
+REG_DATA_PTR  = 0x10,
+REG_DATA_LEN  = 0x14,
+REG_DATA_PTR_HIGH = 0x18,
+REG_VERSION   = 0x20,
+};
+
+/* commands */
+
+enum {
+CMD_INT_DISABLE   = 0x00,
+CMD_INT_ENABLE= 0x01,
+CMD_WRITE_BUFFER  = 0x02,
+CMD_READ_BUFFER   = 0x03,
+};
+
+static uint64_t goldfish_tty_read(void *opaque, hwaddr addr,
+  unsigned size)
+{
+GoldfishTTYState *s = opaque;
+uint64_t value = 0;
+
+switch (addr) {
+case REG_BYTES_READY:
+value = fifo8_num_used(>rx_fifo);
+break;
+case REG_VERSION:
+value = 0;
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: unimplemented register read 0x%02"HWADDR_PRIx"\n",
+  __func__, addr);
+break;
+}
+
+trace_goldfish_tty_read(s, addr, size, value);
+
+return value;
+}
+
+static void goldfish_tty_cmd(GoldfishTTYState *s, uint32_t cmd)
+{
+uint32_t to_copy;
+uint8_t *buf;
+uint8_t data_out[GOLFISH_TTY_BUFFER_SIZE];
+int len;
+uint64_t ptr;
+
+switch (cmd) {
+case CMD_INT_DISABLE:
+if (s->int_enabled) {
+if (!fifo8_is_empty(>rx_fifo)) {
+qemu_set_irq(s->irq, 0);
+}
+s->int_enabled = false;
+}
+break;
+case CMD_INT_ENABLE:
+if (!s->int_enabled) {
+if (!fifo8_is_empty(>rx_fifo)) {
+qemu_set_irq(s->irq, 1);
+}
+s->int_enabled = true;
+}
+break;
+case CMD_WRITE_BUFFER:
+len = s->data_len;
+ptr = s->data_ptr;
+while (len) {
+to_copy = MIN(GOLFISH_TTY_BUFFER_SIZE, len);
+
+address_space_rw(_space_memory, ptr,
+ MEMTXATTRS_UNSPECIFIED, data_out, to_copy, 0);
+qemu_chr_fe_write_all(>chr, data_out, to_copy);
+
+len -= to_copy;
+ptr += to_copy;
+}
+break;
+case CMD_READ_BUFFER:
+len = s->data_len;
+ptr = s->data_ptr;
+while (len && !fifo8_is_empty(>rx_fifo)) {
+buf = (uint8_t *)fifo8_pop_buf(>rx_fifo, len, _copy);
+address_space_rw(_space_memory, ptr,
+MEMTXATTRS_UNSPECIFIED, buf, to_copy, 1);
+
+len -= to_copy;
+ptr += to_copy;
+}
+if (s->int_enabled && fifo8_is_empty(>rx_fifo)) {
+qemu_set_irq(s->irq, 0);
+}
+break;
+}
+}
+
+static void goldfish_tty_write(void *opaque, hwaddr addr,
+   uint64_t value, unsigned size)
+{
+GoldfishTTYState *s = opaque;
+unsigned char c;
+
+trace_goldfish_tty_write(s, addr, size, 

[PATCH v6 0/5] m68k: add Virtual M68k Machine

[Laurent Vivier]

The Quadra 800 machine is very limited to run linux, it manages
only 1 GiB of memory and only some specific interfaces.

The Virtual M68k Machine is based on Goldfish interfaces defined by Google
for Android simulator. It uses Goldfish-rtc (timer and RTC),
Goldfish-pic (PIC) and Goldfish-tty (for serial port and early tty).

https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFIS=
H-VIRTUAL-HARDWARE.TXT

The machine is created with 128 virtio-mmio busses, and they can
be used to add serial console, GPU, disk, NIC, HID, ...

This series re-use the goldfish-rtc implemented for RISCV, and
adds the two others based on the goldfish specs, the kernel driver
and android simulator ones.

The machine can manage up to 3.2 GiB of memory, not because of an hardware
limitation but because the kernel crashes after this value.

Simply configure qemu with:

.../configure --target-list=3Dm68k-softmmu

To run the machine you need a modified kernel you can find here:

https://github.com/vivier/linux/tree/m68k-virt

You need to compile the kernel with:

make virt_defconfig
make vmlinux

The disk must be installed using the q800 machine because the debian installer
doesn't want to be used with a kernel that is not the one on the ISO.

And then you can run the machine with something like:

qemu-system-m68k -M virt \
  -m 3399672K \
  -chardev stdio,signal=3Doff,mux=3Don,id=3Dchar0 \
  -mon chardev=3Dchar0,mode=3Dreadline \
  -kernel vmlinux \
  -append "console=3Dhvc0 root=3D/dev/vda2" \
  -blockdev node-name=3Dsystem,driver=3Dfile,filename=3Ddebian-10.0.qcow2 \
  -blockdev node-name=3Ddrive0,driver=3Dqcow2,file=3Dsystem \
  -device virtio-blk-device,drive=3Ddrive0 \
  -serial chardev:char0 \
  -device virtio-net-device,netdev=3Dhostnet0 \
  -netdev bridge,id=3Dhostnet0,br=3Dvirbr0 \
  -device virtio-rng-device \
  -device virtio-serial-device \
  -device virtio-gpu-device \
  -device virtconsole,chardev=3Dchar0 \
  -device virtio-keyboard-device \
  -device virtio-mouse-device

if you want to use Goldfish-tty for the console rather than virtconsole, you
can add "console=3DttyGF".

To start the debian-installer, you can try by adding:

  -device virtio-scsi-device \
  -blockdev node-name=3Ddebian10,driver=3Dfile,filename=3Ddebian-10.0.0-m68k-=
NETINST-1.iso \
  -blockdev node-name=3Dcdrom0,driver=3Draw,file=3Ddebian10 \
  -device scsi-cd,drive=3Dcdrom0 \
  -initrd installer-m68k/20200315/images/cdrom/initrd.gz

ISO:https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-12/debian-=
10.0.0-m68k-NETINST-1.iso
initrd: https://cdimage.debian.org/cdimage/ports/debian-installer/2020-10-12/=
m68k/debian-installer-images_20200315_m68k.tar.gz

v6:
  m68k-virt-ctrl:
  Renamed to virt-ctrl to be generic
  Add a simple specs document

v5:
  goldfish-tty:
  Use deposit64()
  Add .impl.min_access_size
  Fix CMD_WRITE_BUFFER/CMD_READ_BUFFER

v4:
  goldfish-tty:
  Use fifo8 for the data_in buffer
  Remove the data_out buffer from the struct and put it directly in
  the function. We don't need to use the fifo8 type because we
  can't bufferize the data as we can't stop the tx queue when the buffer
  is full. We rely on qemu_chr_fe_write_all() that blocks the thread for
  that.
  goldfish-pic:
  Add DEFINE_PROP_UINT8() for the index
  Add .impl.min_access_size

v3:
  Add some #define for the interrupt controller (and fix the number of IRQs)
  Add some comments
  Update MAINTAINERS
  Remove "goldfish_rtc: re-arm the alarm after migration" that will be
  merged via the RISC-V branch.

v2:
  Add an interrupt controller to replace the Q800 GLUE
  Add a system controller to shutdown the machine
  Add a fix for goldfish_rtc (already sent alone)
  Add statistics in goldfish-pic
  Add versionned machine type
  Use two goldfish-rtc rather than only one (for timer and RTC)

Laurent Vivier (5):
  char: add goldfish-tty
  intc: add goldfish-pic
  m68k: add an interrupt controller
  m68k: add a system controller
  m68k: add Virtual M68k Machine

 docs/specs/virt-ctlr.txt  |  26 ++
 default-configs/devices/m68k-softmmu.mak  |   1 +
 include/hw/char/goldfish_tty.h|  35 ++
 include/hw/intc/goldfish_pic.h|  33 ++
 include/hw/intc/m68k_irqc.h   |  41 +++
 include/hw/misc/virt_ctrl.h   |  22 ++
 .../standard-headers/asm-m68k/bootinfo-virt.h |  18 +
 hw/char/goldfish_tty.c| 283 
 hw/intc/goldfish_pic.c| 219 
 hw/intc/m68k_irqc.c   | 119 +++
 hw/m68k/virt.c| 313 ++
 hw/misc/virt_ctrl.c   | 151 +
 MAINTAINERS   |  13 +
 hw/char/Kconfig   |   3 +
 hw/char/meson.build   |   2 +
 hw/char/trace-events  

Re: [PATCH v3 1/1] hw/s390x: modularize virtio-gpu-ccw

[Halil Pasic]

On Fri, 5 Mar 2021 16:46:03 -0500
Eduardo Habkost  wrote:

> On Tue, Mar 02, 2021 at 06:35:44PM +0100, Halil Pasic wrote:
> > Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> > module, which provides the type virtio-gpu-device, packaging the
> > hw-display-virtio-gpu module as a separate package that may or may not
> > be installed along with the qemu package leads to problems. Namely if
> > the hw-display-virtio-gpu is absent, qemu continues to advertise
> > virtio-gpu-ccw, but it aborts not only when one attempts using
> > virtio-gpu-ccw, but also when libvirtd's capability probing tries
> > to instantiate the type to introspect it.
> > 
> > Let us thus introduce a module named hw-s390x-virtio-gpu-ccw that
> > is going to provide the virtio-gpu-ccw device. The hw-s390x prefix
> > was chosen because it is not a portable device. Because registering
> > virtio-gpu-ccw would make non-s390x emulator fail due to a missing
> > parent type, if built as a module, before registering it, we check
> > if the ancestor types are already registered.  
> 
> I don't understand what makes it necessary to make the
> type_register() call conditional.  Calling type_register() before
> the parent types are registered is perfectly valid.
> 

Registering a type that ain't going to become a complete type in time
is in my understanding invalid. Why? Because the unsuspecting
client code is about to trigger an abort when it attempts to use
the registered, thus advertised type. That is the state of the art
today. Of course we can morph that, adn make zombie TypeImpl's perfectly
valid.

> I don't think we should prevent type_register() from being
> called.  We just need to prevent type_initialize() from being
> called unless the type definition is complete.  

Yes, but for that we need to catch when type_initialize() is about to be
called, and preferably we should also know if we are dealing with a
modularized type, which is allowed to fail this way, or are we dealing
with a good old built in type, where trying to initialize an incomplete
type is still a result of a programming mistake.

So we would have to catch all the client code, which might be actually
manageable (contrary to my first intuition).

I did a little prototyping. I will post a patch on top of this
patch with the results.

I'm not confident about what I did in that prototype code since for
instance *object_class_by_name gets called about 80 places:
$ git grep -e object_class_by_name|wc -l
82

And to make things even harder to reason about type_initialize() can be 
called through following public interfaces:
object_class_by_name()
object_class_get_parent()
object_initialize()
object_class_foreach()
object_new_with_class()
object_new()
object_new_with_propv()
and here I stopped looking.

If we decide to sacrifice the assertions, and make incomplete types
first class citizens regardless their origin (registered form a module
or form core qemu), we would still have to take care of some 8
invocations of type_initialize(). (Sacrificing the assertions
may be a good idea if we have appropriate test coverage which
would complain about the functionality that we silently discarded.)

Another option to preserve the old behavior for the vast majority of
types would be to mark "special" TypeImpl's as 'have to be careful
before calling type_initialize()', but that doesn't sound very beutiful
either. 

I can try myself at any of these, but I don't mind if somebody who has
a better understanding of object.c takes over.

The reason why I choose to propose making virtio-gpu-ccw call
type_register() conditionally if built as a module, is because
it was easy to reason about the impact of that: it impacts
virtio-gpu-ccw and that is it. Yes, it smells like technical
debt.

> This way there
> won't be any tricky module loading order requirements.
> 

While I don't fully understand the situation when types are registered
from modules in an up and running qemu, I do see a significant
benefit in modules being able to register a type without having all
dependencies met with respect to loading order requirements. 

[..]
> I suggest splitting the QOM core changes and s390x-specific
> changes into separate patches, so they can be reviewed and
> included separately.

No problem, I can do that.

---8<--
From: Halil Pasic 
Date: Mon, 8 Mar 2021 21:34:00 +0100
Subject: [PATCH 1/1] WIP: prevent type_initialize() with incomplete type

Eduardo suggested that instead of checking if the type is going to be a
complete one, before registering it form the virtio-gpu-ccw module we
should actually prevent a type_initialize() from being called unless
the type is complete.

Now if we do that for each and every type we may end up hiding bugs.

Signed-off-by: Halil Pasic 
---
 hw/s390x/virtio-ccw-gpu.c |  5 -
 qom/object.c  | 22 +-
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git 

Re: [PATCH v3 2/3] migration/ram: Reduce unnecessary rate limiting

[Peter Xu]

On Mon, Mar 08, 2021 at 06:34:58PM +0800, Kunkun Jiang wrote:
> Hi,
> 
> On 2021/3/5 22:22, Peter Xu wrote:
> > Kunkun,
> > 
> > On Fri, Mar 05, 2021 at 03:50:34PM +0800, Kunkun Jiang wrote:
> > > When the host page is a huge page and something is sent in the
> > > current iteration, the migration_rate_limit() should be executed.
> > > If not, this function can be omitted to save time.
> > > 
> > > Rename tmppages to pages_this_iteration to express its meaning
> > > more clearly.
> > > 
> > > Signed-off-by: Keqian Zhu 
> > > Signed-off-by: Kunkun Jiang 
> > > ---
> > >   migration/ram.c | 21 ++---
> > >   1 file changed, 14 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index a168da5cdd..9fc5b2997c 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -1988,7 +1988,7 @@ static int ram_save_target_page(RAMState *rs, 
> > > PageSearchStatus *pss,
> > >   static int ram_save_host_page(RAMState *rs, PageSearchStatus *pss,
> > > bool last_stage)
> > >   {
> > > -int tmppages, pages = 0;
> > > +int pages = 0;
> > >   size_t pagesize_bits =
> > >   qemu_ram_pagesize(pss->block) >> TARGET_PAGE_BITS;
> > >   unsigned long start_page = pss->page;
> > > @@ -2000,21 +2000,28 @@ static int ram_save_host_page(RAMState *rs, 
> > > PageSearchStatus *pss,
> > >   }
> > >   do {
> > > +int pages_this_iteration = 0;
> > > +
> > >   /* Check if the page is dirty and send it if it is */
> > >   if (!migration_bitmap_clear_dirty(rs, pss->block, pss->page)) {
> > >   pss->page++;
> > >   continue;
> > >   }
> > > -tmppages = ram_save_target_page(rs, pss, last_stage);
> > > -if (tmppages < 0) {
> > > -return tmppages;
> > > +pages_this_iteration = ram_save_target_page(rs, pss, last_stage);
> > > +if (pages_this_iteration < 0) {
> > > +return pages_this_iteration;
> > >   }
> > > -pages += tmppages;
> > > +pages += pages_this_iteration;
> > To me, both names are okay, it's just that the new name doesn't really 
> > provide
> > a lot more new information, while it's even longer...
> > 
> > Since you seem to prefer cleaning up tmppages, I'm actually thinking whether
> > it should be called as "pages" at all since ram_save_target_page() majorly 
> > only
> > returns either 1 if succeeded or <0 if error.  There's only one very corner
> > case of xbzrle where it can return 0 in save_xbzrle_page():
> > 
> >  if (encoded_len == 0) {
> >  trace_save_xbzrle_page_skipping();
> >  return 0;
> >  }
> > 
> > I think it means the page didn't change at all, then I'm also wondering 
> > maybe
> > it can also return 1 showing one page migrated (though actually skipped!) 
> > which
> > should still be fine for the callers, e.g., ram_find_and_save_block() who 
> > will
> > finally check this "pages" value.
> > 
> > So I think _maybe_ that's a nicer cleanup to change that "return 0" to 
> > "return
> > 1", then another patch to make the return value to be (1) return 0 if page
> > saved, or (2) return <0 if error.  Then here in ram_save_host_page() 
> > tmppages
> > can be renamed to "ret" or "succeed".
> Thanks for your advice.
> change "return 0" to "return 1" would have a slight effect on
> 'rs->target_page_count += pages'
> in ram_save_iterate(). This may lead to consider more complex situations.
> What do you think of
> this?

I don't think we should change the meaning of ram_save_host_page()'s return
value, but only ram_save_target_page(); ram_save_host_page() could return >1
for huge pages.  Thanks,

-- 
Peter Xu

Re: [PATCH v3 1/3] migration/ram: Modify the code comment of ram_save_host_page()

[Peter Xu]

On Mon, Mar 08, 2021 at 06:33:56PM +0800, Kunkun Jiang wrote:
> Hi, Peter
> 
> On 2021/3/5 21:59, Peter Xu wrote:
> > On Fri, Mar 05, 2021 at 03:50:33PM +0800, Kunkun Jiang wrote:
> > > The ram_save_host_page() has been modified several times
> > > since its birth. But the comment hasn't been modified as it should
> > > be. It'd better to modify the comment to explain ram_save_host_page()
> > > more clearly.
> > > 
> > > Signed-off-by: Kunkun Jiang 
> > > ---
> > >   migration/ram.c | 16 +++-
> > >   1 file changed, 7 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index 72143da0ac..a168da5cdd 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -1970,15 +1970,13 @@ static int ram_save_target_page(RAMState *rs, 
> > > PageSearchStatus *pss,
> > >   }
> > >   /**
> > > - * ram_save_host_page: save a whole host page
> > > + * ram_save_host_page: save a whole host page or the rest of a RAMBlock
> > >*
> > > - * Starting at *offset send pages up to the end of the current host
> > > - * page. It's valid for the initial offset to point into the middle of
> > > - * a host page in which case the remainder of the hostpage is sent.
> > > - * Only dirty target pages are sent. Note that the host page size may
> > > - * be a huge page for this block.

> > > - * The saving stops at the boundary of the used_length of the block
> > > - * if the RAMBlock isn't a multiple of the host page size.

[1]

> > > + * Send dirty pages between pss->page and either the end of that page
> > > + * or the used_length of the RAMBlock, whichever is smaller.
> > > + *
> > > + * Note that if the host page is a huge page, pss->page may be in the
> > > + * middle of that page.
> > It reads more like a shorter version of original comment..  Could you point 
> > out
> > what's the major difference?  Since the original comment looks still good 
> > to me.
> Sorry for late reply.
> The reason I want to modify the comment is that I think some parts of the
> comment
> don't match the code. (1) The brief description of ram_save_host_page()
> missed a
> situation that ram_save_host_page() will send dirty pages between pass->page
> and
> the used_length of the block, if the RAMBlock isn't a multiple of the host
> page
> size.

It seems it mentioned at [1] above.

> (2) '*offset' should be replaced with pss->page.

This one looks right as you mentioned.

> 
> So taking the chance of optimizing ram_save_host_page(), I modified the
> comment.
> This version comment is suggested by @David Edmondson. Compared with the
> original
> comment, I think it looks concise.

I think changing incorrect comments is nice; it's just that we should still
avoid rewritting comments with similar contents.

> > >*
> > >* Returns the number of pages written or negative on error
> > >*
> > > @@ -2002,7 +2000,7 @@ static int ram_save_host_page(RAMState *rs, 
> > > PageSearchStatus *pss,
> > >   }
> > >   do {
> > > -/* Check the pages is dirty and if it is send it */
> > > +/* Check if the page is dirty and send it if it is */
> > This line fixes some English issues, it seems.  Looks okay, but normally I
> > won't change it unless the wording was too weird, so as to keep the git 
> > record
> > or the original lines.  Here the original looks still okay, no strong 
> > opinion.
> > 
> > Thanks,
> Yes, the original reads weird to me. Same reason as above, I modified this
> line.
> 
> If you think there is no need to modify the original commit, I do not insist
> on
> changing it.

As I mentioned I don't really have a strong preference, so feel free to keep
your own will. :) I would only to suggest avoid rewritting chunk of similar
meanings.

Thanks,

-- 
Peter Xu

Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine

[Willian Rampazzo]

On Mon, Mar 8, 2021 at 5:41 PM Willian Rampazzo  wrote:
>
> On Mon, Mar 8, 2021 at 5:32 PM Niek Linnenbank  
> wrote:
> >
> > Hi Philippe, Willian,
> >
> > On Mon, Mar 8, 2021 at 8:52 AM Philippe Mathieu-Daudé  
> > wrote:
> >>
> >> On 3/5/21 4:16 PM, Willian Rampazzo wrote:
> >> > On Thu, Mar 4, 2021 at 5:44 PM Niek Linnenbank 
> >> >  wrote:
> >> >>
> >> >> The image for Armbian 19.11.3 bionic has been removed from the armbian 
> >> >> server.
> >> >> Without the image as input the test arm_orangepi_bionic_19_11 cannot 
> >> >> run.
> >> >>
> >> >> This commit removes the test completely and merges the code of the 
> >> >> generic function
> >> >> do_test_arm_orangepi_uboot_armbian back with the 20.08 test.
> >> >>
> >> >> Signed-off-by: Niek Linnenbank 
> >> >> ---
> >> >>  tests/acceptance/boot_linux_console.py | 72 --
> >> >>  1 file changed, 23 insertions(+), 49 deletions(-)
> >> >>
> >> >> diff --git a/tests/acceptance/boot_linux_console.py 
> >> >> b/tests/acceptance/boot_linux_console.py
> >> >> index eb01286799..9fadea9958 100644
> >> >> --- a/tests/acceptance/boot_linux_console.py
> >> >> +++ b/tests/acceptance/boot_linux_console.py
> >> >> @@ -802,7 +802,29 @@ def test_arm_orangepi_sd(self):
> >> >>  # Wait for VM to shut down gracefully
> >> >>  self.vm.wait()
> >> >>
> >> >> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> >> >> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> >> >> +'Test artifacts fetched from unreliable 
> >> >> apt.armbian.com')
> >> >> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage 
> >> >> limited')
> >> >> +def test_arm_orangepi_bionic_20_08(self):
> >> >> +"""
> >> >> +:avocado: tags=arch:arm
> >> >> +:avocado: tags=machine:orangepi-pc
> >> >> +:avocado: tags=device:sd
> >> >> +"""
> >> >> +
> >> >> +# This test download a 275 MiB compressed image and expand it
> >> >> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> >> >> +# As we expand it to 2 GiB we are safe.
> >> >> +
> >> >> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> >> >> + 
> >> >> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> >> >
> >> > The Armbian 20 is not available on this link anymore. I can browse just 
> >> > 21.
> >>
> >> Cat-and-mouse game *sigh*.
> >>
> >
> > Just to clarify here: in this patch I wanted to only make the change to 
> > remove the test for the 19.11.3 image.
> > And in the 3rd patch (tests/acceptance/boot_linux_console: change URL for 
> > test_arm_orangepi_bionic_20_08)
> > do the update for to correct the 20.08 link. So each patch fixes one 
> > problem at a time.
> >
> > Does that make sense, or do you prefer that I combine them in a single 
> > patch instead?
>
> Ops, I forgot about the 3rd patch in this series. That makes sense to
> me, sorry for the mess.
>

And, in this case,

Reviewed-by: Willian Rampazzo 

> >
> > Regards,
> > Niek
> >
> > --
> > Niek Linnenbank
> >

Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine

[Willian Rampazzo]

On Mon, Mar 8, 2021 at 5:32 PM Niek Linnenbank  wrote:
>
> Hi Philippe, Willian,
>
> On Mon, Mar 8, 2021 at 8:52 AM Philippe Mathieu-Daudé  
> wrote:
>>
>> On 3/5/21 4:16 PM, Willian Rampazzo wrote:
>> > On Thu, Mar 4, 2021 at 5:44 PM Niek Linnenbank  
>> > wrote:
>> >>
>> >> The image for Armbian 19.11.3 bionic has been removed from the armbian 
>> >> server.
>> >> Without the image as input the test arm_orangepi_bionic_19_11 cannot run.
>> >>
>> >> This commit removes the test completely and merges the code of the 
>> >> generic function
>> >> do_test_arm_orangepi_uboot_armbian back with the 20.08 test.
>> >>
>> >> Signed-off-by: Niek Linnenbank 
>> >> ---
>> >>  tests/acceptance/boot_linux_console.py | 72 --
>> >>  1 file changed, 23 insertions(+), 49 deletions(-)
>> >>
>> >> diff --git a/tests/acceptance/boot_linux_console.py 
>> >> b/tests/acceptance/boot_linux_console.py
>> >> index eb01286799..9fadea9958 100644
>> >> --- a/tests/acceptance/boot_linux_console.py
>> >> +++ b/tests/acceptance/boot_linux_console.py
>> >> @@ -802,7 +802,29 @@ def test_arm_orangepi_sd(self):
>> >>  # Wait for VM to shut down gracefully
>> >>  self.vm.wait()
>> >>
>> >> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
>> >> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
>> >> +'Test artifacts fetched from unreliable apt.armbian.com')
>> >> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage 
>> >> limited')
>> >> +def test_arm_orangepi_bionic_20_08(self):
>> >> +"""
>> >> +:avocado: tags=arch:arm
>> >> +:avocado: tags=machine:orangepi-pc
>> >> +:avocado: tags=device:sd
>> >> +"""
>> >> +
>> >> +# This test download a 275 MiB compressed image and expand it
>> >> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
>> >> +# As we expand it to 2 GiB we are safe.
>> >> +
>> >> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
>> >> + 
>> >> 'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
>> >
>> > The Armbian 20 is not available on this link anymore. I can browse just 21.
>>
>> Cat-and-mouse game *sigh*.
>>
>
> Just to clarify here: in this patch I wanted to only make the change to 
> remove the test for the 19.11.3 image.
> And in the 3rd patch (tests/acceptance/boot_linux_console: change URL for 
> test_arm_orangepi_bionic_20_08)
> do the update for to correct the 20.08 link. So each patch fixes one problem 
> at a time.
>
> Does that make sense, or do you prefer that I combine them in a single patch 
> instead?

Ops, I forgot about the 3rd patch in this series. That makes sense to
me, sorry for the mess.

>
> Regards,
> Niek
>
> --
> Niek Linnenbank
>

Re: [PATCH] plugins: Expose physical addresses instead of device offsets

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20210308201406.1240023-1-aa...@os.amperecomputing.com/



Hi,

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

Type: series
Message-id: 20210308201406.1240023-1-aa...@os.amperecomputing.com
Subject: [PATCH] plugins: Expose physical addresses instead of device offsets

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
   0436c55..229a834  master -> master
 - [tag update]  
patchew/20210308121155.2476-1-mark.cave-ayl...@ilande.co.uk -> 
patchew/20210308121155.2476-1-mark.cave-ayl...@ilande.co.uk
 - [tag update]  patchew/20210308173244.20710-1-peter.mayd...@linaro.org -> 
patchew/20210308173244.20710-1-peter.mayd...@linaro.org
 * [new tag] 
patchew/20210308201406.1240023-1-aa...@os.amperecomputing.com -> 
patchew/20210308201406.1240023-1-aa...@os.amperecomputing.com
Switched to a new branch 'test'
fdddbf1 plugins: Expose physical addresses instead of device offsets

=== OUTPUT BEGIN ===
ERROR: line over 90 characters
#96: FILE: plugins/api.c:310:
+block = qemu_ram_block_from_host((void *) haddr->v.ram.hostaddr, 
false, );

total: 1 errors, 0 warnings, 68 lines checked

Commit fdddbf18a9ac (plugins: Expose physical addresses instead of device 
offsets) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210308201406.1240023-1-aa...@os.amperecomputing.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v3 2/5] tests/acceptance/boot_linux_console: remove Armbian 19.11.3 bionic test for orangepi-pc machine

[Niek Linnenbank]

Hi Philippe, Willian,

On Mon, Mar 8, 2021 at 8:52 AM Philippe Mathieu-Daudé 
wrote:

> On 3/5/21 4:16 PM, Willian Rampazzo wrote:
> > On Thu, Mar 4, 2021 at 5:44 PM Niek Linnenbank 
> wrote:
> >>
> >> The image for Armbian 19.11.3 bionic has been removed from the armbian
> server.
> >> Without the image as input the test arm_orangepi_bionic_19_11 cannot
> run.
> >>
> >> This commit removes the test completely and merges the code of the
> generic function
> >> do_test_arm_orangepi_uboot_armbian back with the 20.08 test.
> >>
> >> Signed-off-by: Niek Linnenbank 
> >> ---
> >>  tests/acceptance/boot_linux_console.py | 72 --
> >>  1 file changed, 23 insertions(+), 49 deletions(-)
> >>
> >> diff --git a/tests/acceptance/boot_linux_console.py
> b/tests/acceptance/boot_linux_console.py
> >> index eb01286799..9fadea9958 100644
> >> --- a/tests/acceptance/boot_linux_console.py
> >> +++ b/tests/acceptance/boot_linux_console.py
> >> @@ -802,7 +802,29 @@ def test_arm_orangepi_sd(self):
> >>  # Wait for VM to shut down gracefully
> >>  self.vm.wait()
> >>
> >> -def do_test_arm_orangepi_uboot_armbian(self, image_path):
> >> +@skipUnless(os.getenv('ARMBIAN_ARTIFACTS_CACHED'),
> >> +'Test artifacts fetched from unreliable
> apt.armbian.com')
> >> +@skipUnless(os.getenv('AVOCADO_ALLOW_LARGE_STORAGE'), 'storage
> limited')
> >> +def test_arm_orangepi_bionic_20_08(self):
> >> +"""
> >> +:avocado: tags=arch:arm
> >> +:avocado: tags=machine:orangepi-pc
> >> +:avocado: tags=device:sd
> >> +"""
> >> +
> >> +# This test download a 275 MiB compressed image and expand it
> >> +# to 1036 MiB, but the underlying filesystem is 1552 MiB...
> >> +# As we expand it to 2 GiB we are safe.
> >> +
> >> +image_url = ('https://dl.armbian.com/orangepipc/archive/'
> >> +
>  'Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz')
> >
> > The Armbian 20 is not available on this link anymore. I can browse just
> 21.
>
> Cat-and-mouse game *sigh*.
>
>
Just to clarify here: in this patch I wanted to only make the change to
remove the test for the 19.11.3 image.
And in the 3rd patch (tests/acceptance/boot_linux_console: change URL for
test_arm_orangepi_bionic_20_08)
do the update for to correct the 20.08 link. So each patch fixes one
problem at a time.

Does that make sense, or do you prefer that I combine them in a single
patch instead?

Regards,
Niek

-- 
Niek Linnenbank

[PATCH] plugins: Expose physical addresses instead of device offsets

[Aaron Lindsay]

This allows plugins to query for full virtual-to-physical address
translation for a given `qemu_plugin_hwaddr` and stops exposing the
offset within the device itself. As this change breaks the API,
QEMU_PLUGIN_VERSION is incremented.

Signed-off-by: Aaron Lindsay 
---
 contrib/plugins/hotpages.c  |  2 +-
 contrib/plugins/hwprofile.c |  2 +-
 include/qemu/qemu-plugin.h  |  4 ++--
 plugins/api.c   | 16 +++-
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/contrib/plugins/hotpages.c b/contrib/plugins/hotpages.c
index eacc678eac..bf53267532 100644
--- a/contrib/plugins/hotpages.c
+++ b/contrib/plugins/hotpages.c
@@ -122,7 +122,7 @@ static void vcpu_haddr(unsigned int cpu_index, 
qemu_plugin_meminfo_t meminfo,
 }
 } else {
 if (hwaddr && !qemu_plugin_hwaddr_is_io(hwaddr)) {
-page = (uint64_t) qemu_plugin_hwaddr_device_offset(hwaddr);
+page = (uint64_t) qemu_plugin_hwaddr_phys_addr(hwaddr);
 } else {
 page = vaddr;
 }
diff --git a/contrib/plugins/hwprofile.c b/contrib/plugins/hwprofile.c
index 6dac1d5f85..faf216ac00 100644
--- a/contrib/plugins/hwprofile.c
+++ b/contrib/plugins/hwprofile.c
@@ -201,7 +201,7 @@ static void vcpu_haddr(unsigned int cpu_index, 
qemu_plugin_meminfo_t meminfo,
 return;
 } else {
 const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
-uint64_t off = qemu_plugin_hwaddr_device_offset(hwaddr);
+uint64_t off = qemu_plugin_hwaddr_phys_addr(hwaddr);
 bool is_write = qemu_plugin_mem_is_store(meminfo);
 DeviceCounts *counts;
 
diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index c66507fe8f..2252ecf2f0 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
 
 extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
 
-#define QEMU_PLUGIN_VERSION 0
+#define QEMU_PLUGIN_VERSION 1
 
 typedef struct {
 /* string describing architecture */
@@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr 
*qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
  * offset will be into the appropriate block of RAM.
  */
 bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
-uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr 
*haddr);
+uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);
 
 /*
  * Returns a string representing the device. The string is valid for
diff --git a/plugins/api.c b/plugins/api.c
index 0b04380d57..e7352df3e3 100644
--- a/plugins/api.c
+++ b/plugins/api.c
@@ -40,6 +40,7 @@
 #include "sysemu/sysemu.h"
 #include "tcg/tcg.h"
 #include "exec/exec-all.h"
+#include "exec/ram_addr.h"
 #include "disas/disas.h"
 #include "plugin.h"
 #ifndef CONFIG_USER_ONLY
@@ -298,19 +299,24 @@ bool qemu_plugin_hwaddr_is_io(const struct 
qemu_plugin_hwaddr *haddr)
 #endif
 }
 
-uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr 
*haddr)
+uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr)
 {
 #ifdef CONFIG_SOFTMMU
 if (haddr) {
 if (!haddr->is_io) {
-ram_addr_t ram_addr = qemu_ram_addr_from_host((void *) 
haddr->v.ram.hostaddr);
-if (ram_addr == RAM_ADDR_INVALID) {
+RAMBlock *block;
+ram_addr_t offset;
+
+block = qemu_ram_block_from_host((void *) haddr->v.ram.hostaddr, 
false, );
+if (!block) {
 error_report("Bad ram pointer %"PRIx64"", 
haddr->v.ram.hostaddr);
 abort();
 }
-return ram_addr;
+
+return block->offset + offset + block->mr->addr;
 } else {
-return haddr->v.io.offset;
+MemoryRegionSection *mrs = haddr->v.io.section;
+return haddr->v.io.offset + mrs->mr->addr;
 }
 }
 #endif
-- 
2.17.1

Re: [PATCH v3 4/5] tests/acceptance: update sunxi kernel from armbian to 5.10.16

[Niek Linnenbank]

Hi Philippe, Willian,

Thanks for reviewing!

On Mon, Mar 8, 2021 at 8:50 AM Philippe Mathieu-Daudé 
wrote:

> On 3/5/21 4:04 PM, Willian Rampazzo wrote:
> > On Thu, Mar 4, 2021 at 5:45 PM Niek Linnenbank 
> wrote:
> >>
> >> The linux kernel 4.20.7 binary for sunxi has been removed from
> apt.armbian.com:
> >>
> >>   $ ARMBIAN_ARTIFACTS_CACHED=yes AVOCADO_ALLOW_LARGE_STORAGE=yes
> avocado --show=app,console run -t machine:orangepi-pc
> tests/acceptance/boot_linux_console.py
> >>   Fetching asset from
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi
> >>   ...
> >>   (1/6)
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi:
> >> CANCEL: Missing asset
> https://apt.armbian.com/pool/main/l/linux-4.20.7-sunxi/linux-image-dev-sunxi_5.75_armhf.deb
> (0.55 s)
> >>
> >> This commit updates the sunxi kernel to 5.10.16 for the acceptance
> >> tests of the orangepi-pc and cubieboard machines.
> >>
> >> Signed-off-by: Niek Linnenbank 
> >> ---
> >>  tests/acceptance/boot_linux_console.py | 40 +-
> >>  tests/acceptance/replay_kernel.py  |  8 +++---
> >>  2 files changed, 24 insertions(+), 24 deletions(-)
> >>
> >
> > I think some devs will not like it,
> Maybe you refer to my previous NACKs regarding similar changes in
> integration tests. Niek is the author of the test and the maintainer
> of the machine, so if he is OK to stop testing the 4.20.7 kernels
> and test the 5.10.16 from now on, I won't object.
>

For me the 4.20.7 kernel would have been OK if it was still available. With
that version removed,
I looked at what is now available on https://apt.armbian.com/pool/main/l/.
There are quite a lot of packaged kernels there
and 5.10.16 seemed to me a good balance of running newer kernel code with a
version that will hopefully stay around for a while.


>
> > but, for me, it is fine as we
> > don't have the old kernel available anymore:
> >
> > Reviewed-by: Willian Rampazzo 
> >
>
> Thanks, will add your reviewed-by tag.

Regards,
Niek

-- 
Niek Linnenbank

Re: [PATCH] plugins: Expose physical addresses instead of device offsets

[Aaron Lindsay]

Alex,

I've now tested this change, and it is giving what appear to be valid
and correct physical addresses for both RAM and IO accesses in all the
cases I've thrown at it. My main concern with this patch at this point
is that I am concerned I may be breaking your new plugin here:

> +++ b/contrib/plugins/hwprofile.c
> @@ -201,7 +201,7 @@ static void vcpu_haddr(unsigned int cpu_index, 
> qemu_plugin_meminfo_t meminfo,
>  return;
>  } else {
>  const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
> -uint64_t off = qemu_plugin_hwaddr_device_offset(hwaddr);
> +uint64_t off = qemu_plugin_hwaddr_phys_addr(hwaddr);

How angry is the plugin going to be that these are now physical
addresses instead of offsets?

-Aaron

Re: [PULL 00/14] Renesas patches for 2021-03-06

[Peter Maydell]

On Sat, 6 Mar 2021 at 15:38, Philippe Mathieu-Daudé  wrote:
>
> Hi Peter,
>
> As SH-4 is not very active, I'm here covering up with this trivial patch 
> queue.
>
> The following changes since commit 91e92cad67caca3bc4b8e920ddb5c8ca64aac9e1:
>
>   Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210305' 
> into staging (2021-03-05 19:04:47 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/philmd/qemu.git tags/renesas-20210306
>
> for you to fetch changes up to ef95ca038295bdf6749cbce426b281c21a08971e:
>
>   hw/sh4/sh7750_regs: Replace link to license by its full content (2021-03-06 
> 16:19:03 +0100)
>
> 
> Renesas patches queue
>
> - MMU prototype cleanups
> - Clarify licenses
> - Fine-grained Kconfig entries for SH-4 devices


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM

Re: RESEND [PATCH v2] bsd-user: Add new maintainers

[Warner Losh]

On Mon, Mar 8, 2021 at 8:28 AM Daniel P. Berrangé 
wrote:

> On Mon, Mar 08, 2021 at 08:21:34AM -0700, Warner Losh wrote:
> > On Mon, Mar 8, 2021 at 6:14 AM Philippe Mathieu-Daudé  >
> > wrote:
> >
> > > On 3/8/21 1:14 PM, Daniel P. Berrangé wrote:
> > > > On Mon, Mar 08, 2021 at 12:55:10PM +0100, Thomas Huth wrote:
> > > >> On 08/03/2021 12.16, Philippe Mathieu-Daudé wrote:
> > > >>> Hi Peter,
> > > >>>
> > > >>> +Markus/Paolo/Laurent/Richard
> > > >>>
> > > >>> On 3/8/21 11:24 AM, Peter Maydell wrote:
> > >  On Mon, 8 Mar 2021 at 10:09, Thomas Huth 
> wrote:
> > > >
> > > > On 07/03/2021 16.56, Warner Losh wrote:
> > > >> 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 
> > > >> Signed-off-by: Kyle Evans 
> > > >> Reviewed-by: Thomas Huth 
> > > >> ---
> > > >>MAINTAINERS | 5 -
> > > >>1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/MAINTAINERS b/MAINTAINERS
> > > >> index 26c9454823..ec0e935038 100644
> > > >> --- a/MAINTAINERS
> > > >> +++ b/MAINTAINERS
> > > >> @@ -2896,9 +2896,12 @@ F: thunk.c
> > > >>F: accel/tcg/user-exec*.c
> > > >>
> > > >>BSD user
> > > >> -S: Orphan
> > > >> +M: Warner Losh 
> > > >> +R: Kyle Evans 
> > > >> +S: Maintained
> > > >>F: bsd-user/
> > > >>F: default-configs/targets/*-bsd-user.mak
> > > >> +T: git https://github.com/qemu-bsd-user/qemu-bsd-user
> > > bsd-user-rebase-3.1
> > > >
> > > > BSD is not really my home turf, but since nobody else picked
> this up
> > > and I
> > > > plan to send a pull request for a bunch of patches anyway this
> week,
> > > I can
> > > > also put it into my queue.
> > > 
> > >  Fine with me. (The v1 was in my to-review queue, but I'm currently
> > >  running somewhat behind on processing patches.)
> > > >>>
> > > >>> This is a patch for mainstream QEMU, I'm having hard time
> > > >>> understanding the point of it. This is some official way
> > > >>> to say that BSD-user is not maintained in mainstream but
> > > >>> has to be used in the referred fork which is way different
> > > >>> that mainstream...
> > > >>>
> > > >>> I'd rather wait for more mainstream contributions from Warner
> > > >>> and Kyle, or blow the current orphan/dead code and import
> > > >>> bsd-user-rebase-3.1 adding the maintainer entries along, but
> > > >>> certainly not mark this dead code as maintained.
> > > >>>
> > > >>> Please convince me why I'm wrong, because I'd prefer NAck this
> > > >>> patch...
> > > >>
> > > >> The idea has been discussed here:
> > > >>
> > > >> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01399.html
> > > >>
> > > >> So this is not about declaring that bsd-user is maintained in a
> > > different
> > > >> repository, but about giving Warner et al. a chance to finally
> upstream
> > > >> their work.
> > > >
> > > > Yep, I think this change in MAINTAINERS file is primarily about
> > > signalling
> > > > intent for future
> > >
> >
> >  Yes. Just so. We have the older fork that we're trying to port forward.
> If
> > people have changes as we do that, it sure would be nice to have them go
> > through us rather than create more conflict with the main tree. I don't
> > need to have a new set of conflicts with main because someone thought
> that
> > it would be a good idea to move the space before or after the '(' or
> after
> > in a bunch of files. It's just extra work if I have to do it as part of
> the
> > merging. Better that goes into the top of our queue so it's managed and
> > easy and a click on github than another half hour I have to spend sorting
> > that out when I'd rather be sorting out the substantial change that go on
> > upstream in other areas that legitimately do make things much better.
> >
> > We talked about all this in the above thread, I thought, and I thought it
> > was all settled, so I was rather surprised to wake up to this thread this
> > morning.
>
> From my POV, nothing has changed - I think the MAINTAINERS change is
> reasonable.
>
>
> > > > Marking the subsystem as maintained isn't saying the current code is
> > > great,
> > > > just that there is someone committed to improving it hereafter.
> > >
> > > OK, thank Thomas / Daniel for explaining and referring to the "BSD-user
> > > plans" (which I didn't notice earlier).
> > >
> > > Warner, what about mentioning your plans here in this patch?
> > >
> >
> > Where is there room in the MAINTAINERS file for that? How would you like
> me
> > to do that?
>
> I think he was just referring to mentioning the intention in the
> commit message.  The MAINTAINERS file isn't a suitable place for
> describing plans.
>

Ah, that makes sense... I can do that and resend.


> > > > If we want to warn people that the 

Re: [PATCH v2] FreeBSD: Upgrade to 12.2 release

[Warner Losh]

On Mon, Mar 8, 2021 at 12:51 PM Warner Losh  wrote:

>
>
> On Mon, Mar 8, 2021 at 8:46 AM Roman Bolshakov 
> wrote:
>
>>
>> > 8 марта 2021 г., в 18:41, Thomas Huth  написал(а):
>> >
>> > On 08/03/2021 16.26, Warner Losh wrote:
>> >> On Mon, Mar 8, 2021 at 6:30 AM Thomas Huth > th...@redhat.com>> wrote:
>> >>On 07/03/2021 16.56, Warner Losh wrote:
>> >> > FreeBSD 12.1 has reached end of life. Use 12.2 instead so that
>> FreeBSD's
>> >> > project's packages will work.  Update which timezone to pick.
>> Work
>> >>around a QEMU
>> >> > bug that incorrectly raises an exception on a CRC32 instruction
>> with
>> >>the FPU
>> >> > disabled.  The qemu bug is described here:
>> >> >
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg784158.html
>> >>
>> >> >
>> >> > Signed-off-by: Warner Losh > i...@bsdimp.com>>
>> >> >
>> >> > ---
>> >> >   tests/vm/freebsd | 14 +-
>> >> >   1 file changed, 9 insertions(+), 5 deletions(-)
>> >>I gave this a try, but it's currently failing in the unit tests:
>> >>Running test test-crypto-tlscredsx509
>> >>** (tests/test-crypto-tlscredsx509:): CRITICAL **:
>> 12:56:35.157: Failed
>> >>to sign certificate ASN1 parser: Value is not valid.
>> >>ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed
>> to sign
>> >>certificate ASN1 parser: Value is not valid.
>> >>gmake: *** [Makefile.mtest:576: run-test-70] Error 1
>> >>gmake: *** Waiting for unfinished jobs
>> >>Running test test-crypto-tlssession
>> >>** (tests/test-crypto-tlssession:10002): CRITICAL **: 12:56:35.288:
>> Failed
>> >>to sign certificate ASN1 parser: Value is not valid.
>> >>ERROR test-crypto-tlssession - Bail out! FATAL-CRITICAL: Failed to
>> sign
>> >>certificate ASN1 parser: Value is not valid.
>> >> That's totally unrelated to my change. Was it failing before? What
>> environment was it failing in because it all seemed to work for me...
>> >
>> > It's been a while since I last ran "make vm-build-freebsd", so I can't
>> really tell whether the problem was already there before ... when I now try
>> to run it without your patch, it fails for me, too, but rather due to
>> FreeBSD 12.1 being out of service instead.
>> >
>> >>I guess it's the same problem as:
>> >>https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06750.html
>> >><
>> https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06750.html>
>> >>... so this would require a bug fix in the libtasn of FreeBSD
>> first? See:
>> >>https://gitlab.com/gnutls/libtasn1/-/merge_requests/71
>> >>
>> >>  Is this on the host that built qemu, or inside the VM or where
>> exactly?
>> >
>> > It's inside the VM ... I assume the libtasn there has the same bug as
>> the one on macOS?
>> >
>>
>> The gnutls failures on macOS and FreeBSD (with clang as main compiler)
>> won’t happen only if libtasn1 from master is used. Otherwise libtasn1 has
>> to be compiled with -O1/-O0.
>>
>
> Forgive my ignorance...
>
> Does this come from a submodule? From something I've built and installed
> on my FreeBSD host? Or something that's installed into the FreeBSD guest
>

ah, it's inside the guest.

Warner

Re: [PATCH] scsi: Silence gcc warning

[Eric Blake]

Adding qemu-trivial in cc.

On 2/9/21 9:44 AM, Philippe Mathieu-Daudé wrote:
> On 2/9/21 4:23 PM, Eric Blake wrote:
>> On Fedora 33, gcc 10.2.1 notes that scsi_cdb_length(buf) can set
>> len==-1, which in turn overflows g_malloc():
>>
>> [5/5] Linking target qemu-system-x86_64
>> In function ‘scsi_disk_new_request_dump’,
>> inlined from ‘scsi_new_request’ at ../hw/scsi/scsi-disk.c:2608:9:
>> ../hw/scsi/scsi-disk.c:2582:19: warning: argument 1 value 
>> ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 
>> [-Walloc-size-larger-than=]
>>  2582 | line_buffer = g_malloc(len * 5 + 1);
>>   |   ^
>>
>> Silence it with a decent assertion, since we only convert a buffer to
>> bytes when we have a valid cdb length.
>>
>> Signed-off-by: Eric Blake 
>> ---
>>  hw/scsi/scsi-disk.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
>> index ed52fcd49ff0..b3311a5657b7 100644
>> --- a/hw/scsi/scsi-disk.c
>> +++ b/hw/scsi/scsi-disk.c
>> @@ -2579,6 +2579,7 @@ static void scsi_disk_new_request_dump(uint32_t lun, 
>> uint32_t tag, uint8_t *buf)
>>  int len = scsi_cdb_length(buf);
>>  char *line_buffer, *p;
>>
>> +assert(len > 0 && len <= 16);
>>  line_buffer = g_malloc(len * 5 + 1);
>>
>>  for (i = 0, p = line_buffer; i < len; i++) {
>>
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> 

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

Re: [PATCH v2] FreeBSD: Upgrade to 12.2 release

[Warner Losh]

On Mon, Mar 8, 2021 at 8:46 AM Roman Bolshakov 
wrote:

>
> > 8 марта 2021 г., в 18:41, Thomas Huth  написал(а):
> >
> > On 08/03/2021 16.26, Warner Losh wrote:
> >> On Mon, Mar 8, 2021 at 6:30 AM Thomas Huth  th...@redhat.com>> wrote:
> >>On 07/03/2021 16.56, Warner Losh wrote:
> >> > FreeBSD 12.1 has reached end of life. Use 12.2 instead so that
> FreeBSD's
> >> > project's packages will work.  Update which timezone to pick. Work
> >>around a QEMU
> >> > bug that incorrectly raises an exception on a CRC32 instruction
> with
> >>the FPU
> >> > disabled.  The qemu bug is described here:
> >> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg784158.html
> >>
> >> >
> >> > Signed-off-by: Warner Losh mailto:i...@bsdimp.com
> >>
> >> >
> >> > ---
> >> >   tests/vm/freebsd | 14 +-
> >> >   1 file changed, 9 insertions(+), 5 deletions(-)
> >>I gave this a try, but it's currently failing in the unit tests:
> >>Running test test-crypto-tlscredsx509
> >>** (tests/test-crypto-tlscredsx509:): CRITICAL **: 12:56:35.157:
> Failed
> >>to sign certificate ASN1 parser: Value is not valid.
> >>ERROR test-crypto-tlscredsx509 - Bail out! FATAL-CRITICAL: Failed to
> sign
> >>certificate ASN1 parser: Value is not valid.
> >>gmake: *** [Makefile.mtest:576: run-test-70] Error 1
> >>gmake: *** Waiting for unfinished jobs
> >>Running test test-crypto-tlssession
> >>** (tests/test-crypto-tlssession:10002): CRITICAL **: 12:56:35.288:
> Failed
> >>to sign certificate ASN1 parser: Value is not valid.
> >>ERROR test-crypto-tlssession - Bail out! FATAL-CRITICAL: Failed to
> sign
> >>certificate ASN1 parser: Value is not valid.
> >> That's totally unrelated to my change. Was it failing before? What
> environment was it failing in because it all seemed to work for me...
> >
> > It's been a while since I last ran "make vm-build-freebsd", so I can't
> really tell whether the problem was already there before ... when I now try
> to run it without your patch, it fails for me, too, but rather due to
> FreeBSD 12.1 being out of service instead.
> >
> >>I guess it's the same problem as:
> >>https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06750.html
> >> >
> >>... so this would require a bug fix in the libtasn of FreeBSD first?
> See:
> >>https://gitlab.com/gnutls/libtasn1/-/merge_requests/71
> >>
> >>  Is this on the host that built qemu, or inside the VM or where exactly?
> >
> > It's inside the VM ... I assume the libtasn there has the same bug as
> the one on macOS?
> >
>
> The gnutls failures on macOS and FreeBSD (with clang as main compiler)
> won’t happen only if libtasn1 from master is used. Otherwise libtasn1 has
> to be compiled with -O1/-O0.
>

Forgive my ignorance...

Does this come from a submodule? From something I've built and installed on
my FreeBSD host? Or something that's installed into the FreeBSD guest?

Warner


> Отправлено с iPhone
>
> > Thomas
> >
>

Re: [PATCH v3 29/30] vl: QAPIfy -object

[Eric Blake]

On 3/8/21 10:54 AM, Kevin Wolf wrote:
> This switches the system emulator from a QemuOpts-based parser for
> -object to user_creatable_parse_str() which uses a keyval parser and
> enforces the QAPI schema.
> 
> Apart from being a cleanup, this makes non-scalar properties accessible.
> 
> This adopts a similar model as -blockdev uses: When parsing the option,
> create the ObjectOptions and queue them. At the later point where we
> used to create objects for the collected QemuOpts, the ObjectOptions
> queue is processed instead.
> 
> A complication compared to -blockdev is that object definitions are
> supported in -readconfig and -writeconfig.
> 
> After this patch, -readconfig still works, though it still goes through
> the QemuOpts parser, which means that improvements like non-scalar
> properties are still not available in config files.
> 
> -writeconfig stops working for -object. Tough luck. It has never
> supported all options (not even the common ones), so supporting one less
> isn't the end of the world. As object definitions from -readconfig still
> go through QemuOpts, they are still included in -writeconfig output,
> which at least prevents destroying your existing configuration when you
> just wanted to add another option.

Maybe worth a tweak to this paragraph now that b979c931 has landed
formally deprecating -writeconfig (all the more reason we don't care
about it).

> 
> Signed-off-by: Kevin Wolf 
> Acked-by: Peter Krempa 
> Reviewed-by: Eric Blake 

R-b stands either way.

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

Re: [PATCH v3 26/30] qemu-img: Use user_creatable_process_cmdline() for --object

[Eric Blake]

On 3/8/21 10:54 AM, Kevin Wolf wrote:
> This switches qemu-img from a QemuOpts-based parser for --object to
> user_creatable_process_cmdline() which uses a keyval parser and enforces
> the QAPI schema.
> 
> Apart from being a cleanup, this makes non-scalar properties accessible.
> 
> Signed-off-by: Kevin Wolf 
> Acked-by: Peter Krempa 
> ---
>  qemu-img.c | 251 ++---
>  1 file changed, 45 insertions(+), 206 deletions(-)
> 

> @@ -1353,7 +1303,7 @@ static int check_empty_sectors(BlockBackend *blk, 
> int64_t offset,
>  /*
>   * Compares two images. Exit codes:
>   *
> - * 0 - Images are identical
> + * 0 - Images are identical or the requested help was printed

Nice, but does the user-facing documentation need updating to match?

>   * 1 - Images differ
>   * >1 - Error occurred
>   */
> @@ -1423,15 +1373,21 @@ static int img_compare(int argc, char **argv)
>  case 'U':
>  force_share = true;
>  break;
> -case OPTION_OBJECT: {
> -QemuOpts *opts;
> -opts = qemu_opts_parse_noisily(_object_opts,
> -   optarg, true);
> -if (!opts) {
> -ret = 2;
> -goto out4;
> +case OPTION_OBJECT:
> +{
> +Error *local_err = NULL;
> +
> +if (!user_creatable_add_from_str(optarg, _err)) {
> +if (local_err) {
> +error_report_err(local_err);
> +exit(2);
> +} else {
> +/* Help was printed */
> +exit(EXIT_SUCCESS);
> +}

The commit message needs to be updated to call out that this bug fix was
intentional, preferably mentioning the commit where we broke it
(334c43e2c3).

The code is fine, though, so with an improved commit message (and maybe
some matching doc tweaks),

Reviewed-by: Eric Blake 

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

Re: [PATCH v2] MAINTAINERS: Merge the Gitlab-CI section into the generic CI section

[Philippe Mathieu-Daudé]

On 3/8/21 6:49 PM, Willian Rampazzo wrote:
> On Mon, Mar 8, 2021 at 12:46 PM Thomas Huth  wrote:
>>
>> The status of the gitlab-CI files is currently somewhat confusing, and
>> it is often not quite clear whether a patch should go via my tree or
>> via the testing tree of Alex. That situation has grown historically...
>> Initially, I was the only one using the gitlab-CI, just for my private
>> repository there. But in the course of time, the gitlab-CI switched to
>> use the containers from tests/docker/ (which is not part of the gitlab-CI
>> section in the MAINTAINERS file), and QEMU now even switched to gitlab.com
>> completely for the repository and will soon use it as its gating CI, too,
>> so it makes way more sense if the gitlab-ci.yml files belong to the people
>> who are owning the qemu-project on gitlab.com and take care of the gitlab
>> CI there. Thus let's merge the gitlab-ci section into the common "test and
>> build automation" section.
> 
> Makes sense to me.
> 
> Acked-by: Willian Rampazzo 
> 
>>
>> While we're at it, I'm also removing the line with Fam there for now,
>> since he was hardly active during the last years in this area anymore.
>> If he ever gets more time for this part again in the future, we surely
>> can add the line back again.
>>
>> Now to avoid that Alex is listed here alone, Philippe and I agreed to
>> help as backup maintainers here, too.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  v2: Keep Philippe and myself as maintainer instead of reviewer
>>
>>  MAINTAINERS | 21 +++--
>>  1 file changed, 7 insertions(+), 14 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 26c9454823..5c4c179abb 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3262,17 +3262,21 @@ F: include/hw/remote/iohub.h
>>
>>  Build and test automation
>>  -
>> -Build and test automation
>> +Build and test automation, Linux Continuous Integration
>>  M: Alex Bennée 
>> -M: Fam Zheng 
>> -R: Philippe Mathieu-Daudé 
>> +M: Philippe Mathieu-Daudé 
>> +M: Thomas Huth 
>> +R: Wainer dos Santos Moschetta 
> 
> Feel free to add me as a Reviewer: Willian Rampazzo 

Thank you Willian! :)

Re: [PATCH v3 06/30] qapi/qom: Add ObjectOptions for memory-backend-*

[Eric Blake]

On 3/8/21 10:54 AM, Kevin Wolf wrote:
> This adds a QAPI schema for the properties of the memory-backend-*
> objects.
> 
> HostMemPolicy has to be moved to an include file that can be used by the
> storage daemon, too, because ObjectOptions must be the same in all
> binaries if we don't want to compile the whole code multiple times.
> 
> Signed-off-by: Kevin Wolf 
> Acked-by: Peter Krempa 
> ---
>  qapi/common.json  |  20 
>  qapi/machine.json |  22 +
>  qapi/qom.json | 121 +-
>  3 files changed, 141 insertions(+), 22 deletions(-)
> 

> @@ -287,7 +397,10 @@
>  'cryptodev-backend-builtin',
>  'cryptodev-vhost-user',
>  'dbus-vmstate',
> -'iothread'
> +'iothread',
> +'memory-backend-file',
> +'memory-backend-memfd',
> +'memory-backend-ram'

Another leaked enum value...

>] }
>  
>  ##
> @@ -315,7 +428,11 @@
>'cryptodev-vhost-user':   { 'type': 'CryptodevVhostUserProperties',
>'if': 'defined(CONFIG_VIRTIO_CRYPTO) 
> && defined(CONFIG_VHOST_CRYPTO)' },
>'dbus-vmstate':   'DBusVMStateProperties',
> -  'iothread':   'IothreadProperties'
> +  'iothread':   'IothreadProperties',
> +  'memory-backend-file':'MemoryBackendFileProperties',
> +  'memory-backend-memfd':   { 'type': 'MemoryBackendMemfdProperties',
> +  'if': 'defined(CONFIG_LINUX)' },
> +  'memory-backend-ram': 'MemoryBackendProperties'
>} }

...when compared to the union branches.

Once fixed,
Reviewed-by: Eric Blake 

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

Re: [PATCH v3 04/30] qapi/qom: Add ObjectOptions for cryptodev-*

[Eric Blake]

On 3/8/21 10:54 AM, Kevin Wolf wrote:
> This adds a QAPI schema for the properties of the cryptodev-* objects.
> 
> These interfaces have some questionable aspects (cryptodev-backend is
> really an abstract base class without function, and the queues option
> only makes sense for cryptodev-vhost-user), but as the goal is to
> represent the existing interface in QAPI, leave these things in place.
> 
> Signed-off-by: Kevin Wolf 
> Acked-by: Peter Krempa 
> ---
>  qapi/qom.json | 35 +++
>  1 file changed, 35 insertions(+)
> 

> @@ -239,6 +267,9 @@
>  'authz-listfile',
>  'authz-pam',
>  'authz-simple',
> +'cryptodev-backend',
> +'cryptodev-backend-builtin',
> +'cryptodev-vhost-user',

Shouldn't the enum value be conditional...

>  'iothread'
>] }
>  
> @@ -262,6 +293,10 @@
>'authz-listfile': 'AuthZListFileProperties',
>'authz-pam':  'AuthZPAMProperties',
>'authz-simple':   'AuthZSimpleProperties',
> +  'cryptodev-backend':  'CryptodevBackendProperties',
> +  'cryptodev-backend-builtin':  'CryptodevBackendProperties',
> +  'cryptodev-vhost-user':   { 'type': 'CryptodevVhostUserProperties',
> +  'if': 'defined(CONFIG_VIRTIO_CRYPTO) 
> && defined(CONFIG_VHOST_CRYPTO)' },

...if the union branch is likewise?

>'iothread':   'IothreadProperties'
>} }
>  
> 

With that fixed,

Reviewed-by: Eric Blake 

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

Re: [PULL 01/38] hw/block/nvme: introduce nvme-subsys device

[Klaus Jensen]

On Mar  8 18:53, Peter Maydell wrote:
> On Mon, 8 Mar 2021 at 18:46, Klaus Jensen  wrote:
> >
> > On Mar  8 19:32, Paolo Bonzini wrote:
> > > On 08/03/21 13:22, Klaus Jensen wrote:
> > > >
> > > > This patch introduced a simple nvme-subsys device model.  The subsystem
> > > > will be prepared with subsystem NQN with  provided in
> > > > nvme-subsys device:
> > > >
> > > >ex) -device nvme-subsys,id=subsys0: nqn.2019-08.org.qemu:subsys0
> > >
> > > Hi Klaus, sorry for not spotting this before.  In the SCSI subsystem we
> > > moved away from using id as guest-visible data.  Keeping it as a default 
> > > is
> > > fine I guess, but would it be possible to add an nqn property to 
> > > nvme-subsys
> > > and use it if it is present instead of the id?
> > >
> > > Thanks,
> > >
> > > Paolo
> > >
> >
> > Hi Paolo,
> >
> > Thanks for pointing this out! Absolutely - we have no specific reason to
> > use 'id', so we can just change it completely to use 'nqn'.
> >
> > Peter, you want this in a v2 or did you already start integration of
> > this PR?
> 
> I haven't yet started working on this PR so if the change is trivial
> feel free to roll a v2.
> 

Thanks, I'll do that!



signature.asc
Description: PGP signature

Re: [PULL 00/54] target-arm queue

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20210308173244.20710-1-peter.mayd...@linaro.org/



Hi,

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

Type: series
Message-id: 20210308173244.20710-1-peter.mayd...@linaro.org
Subject: [PULL 00/54] target-arm queue

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20210225091435.644762-1-eric.au...@redhat.com -> 
patchew/20210225091435.644762-1-eric.au...@redhat.com
 - [tag update]  patchew/20210303195339.gb3...@redhat.com -> 
patchew/20210303195339.gb3...@redhat.com
 - [tag update]  patchew/20210308154633.158915-1-th...@redhat.com -> 
patchew/20210308154633.158915-1-th...@redhat.com
 * [new tag] patchew/20210308173244.20710-1-peter.mayd...@linaro.org -> 
patchew/20210308173244.20710-1-peter.mayd...@linaro.org
Switched to a new branch 'test'
07374e1 hw/timer/renesas_tmr: Fix use of uninitialized data in read_tcnt()
fea8e80 hw/timer/renesas_tmr: Prefix constants for CSS values with CSS_
b9f3dfd hw/ssi: xilinx_spips: Remove DMA related dead codes from zynqmp_spips
9e3a610 hw/ssi: xilinx_spips: Clean up coding convention issues
bfdae5f hw/arm: xlnx-zynqmp: Connect a Xilinx CSU DMA module for QSPI
d95d2c2 hw/arm: xlnx-zynqmp: Clean up coding convention issues
b52474c hw/dma: Implement a Xilinx CSU DMA model
f8734d1 target/arm: Restrict v7A TCG cpus to TCG accel
97246f4 tests/qtest/sse-timer-test: Test counter scaling changes
bc7ce41 tests/qtest/sse-timer-test: Test the system timer
1ae3cd2 tests/qtest/sse-timer-test: Add simple test of the SSE counter
3c89ac9 docs/system/arm/mps2.rst: Document the new mps3-an547 board
b2cb63d hw/arm/mps2-tz: Add new mps3-an547 board
feee059 hw/arm/mps2-tz: Make initsvtor0 setting board-specific
654d5b5 hw/arm/mps2-tz: Support running APB peripherals on different clock
84a76c5 hw/misc/mps2-scc: Implement changes for AN547
8225557 hw/misc/mps2-fpgaio: Support AN547 DBGCTRL register
16fac9b hw/misc/mps2-fpgaio: Fold counters subsection into main vmstate
34606d7 hw/arm/mps2-tz: Make UART overflow IRQ board-specific
19c7e52 hw/arm/armsse: Add SSE-300 support
f6003ee hw/arm/armsse: Support variants with ARMSSE_CPU_PWRCTRL block
c6f883c hw/arm/armsse: Add support for TYPE_SSE_TIMER in ARMSSEDeviceInfo
73393b5 hw/arm/armsse: Add support for SSE variants with a system counter
45df240 hw/arm/armsse: Indirect irq_is_common[] through ARMSSEInfo
9fff473 hw/arm/armsse: Add missing SSE-200 SYS_PPU
7222997 hw/arm/armsse: Move PPUs into data-driven framework
2ef7ec8 hw/arm/armsse: Move sysctl register block into data-driven framework
18a85f7 hw/arm/armsse: Move sysinfo register block into data-driven framework
e4ee1e7 hw/arm/armsse: Move s32ktimer into data-driven framework
8655f07 hw/arm/armsse: Move watchdogs into data-driven framework
f827989 hw/arm/armsse: Move dual-timer device into data-driven framework
79b53b8 hw/arm/armsse: Add framework for data-driven device placement
516eaef hw/arm/armsse: Add a define for number of IRQs used by the SSE itself
517dfb6 hw/arm/armsse: Use an array for apb_ppc fields in the state structure
3d20d2e hw/misc/sse-cpu-pwrctrl: Implement SSE-300 CPU_PWRCTRL register block
e6df0f6 hw/arm/Kconfig: Move ARMSSE_CPUID and ARMSSE_MHU stanzas to hw/misc
9049fd0 hw/misc/iotkit-sysctl: Implement SSE-200 and SSE-300 PID register values
2908277 hw/misc/iotkit-sysctl: Handle SSE-300 changes to PDCM_PD_*_SENSE 
registers
2c929f1 hw/misc/iotkit-sysctl: Implement dummy version of SSE-300 PWRCTRL 
register
5132688 hw/misc/iotkit-sysctl: Handle INITSVTOR* for SSE-300
8055482 hw/misc/iotkit-sysctl: Handle CPU_WAIT, NMI_ENABLE for SSE-300
4d1f059 hw/misc/iotkit-sysctl: Add SSE-300 cases which match SSE-200 behaviour
3e2ac76 hw/timer/sse-timer: Model the SSE Subsystem System Timer
907d495 hw/timer/sse-counter: Model the SSE Subsystem System Counter
a496eee hw/misc/iotkit-sysinfo.c: Implement SYS_CONFIG1 and IIDR
093c68d hw/arm/armsse.c: Use correct SYS_CONFIG0 register value for SSE-300
d75dd6e hw/misc/iotkit-sysinfo.c: Implement SSE-300 PID register values
122ac7a hw/misc/iotkit-secctl.c: Implement SSE-300 PID register values
44fafc0 hw/misc/iotkit-sysctl: Remove is_sse200 flag
a7dd089 hw/arm/armsse: Introduce SSE subsystem version property
9b76681 hw/timer/npcm7xx_timer: Use new clock_ns_to_ticks()
7d51138 clock: Add clock_ns_to_ticks() function
cc6d5be clock: Add ClockPreUpdate callback event type
8a5be7d clock: Add ClockEvent parameter to callbacks

=== OUTPUT BEGIN ===
1/54 Checking commit 8a5be7df4d6d (clock: Add ClockEvent parameter to callbacks)
WARNING: line over 80 characters
#554: FILE: hw/misc/zynq_slcr.c:580:
+

Re: [PULL 01/38] hw/block/nvme: introduce nvme-subsys device

[Klaus Jensen]

On Mar  8 19:32, Paolo Bonzini wrote:
> On 08/03/21 13:22, Klaus Jensen wrote:
> > 
> > This patch introduced a simple nvme-subsys device model.  The subsystem
> > will be prepared with subsystem NQN with  provided in
> > nvme-subsys device:
> > 
> >ex) -device nvme-subsys,id=subsys0: nqn.2019-08.org.qemu:subsys0
> 
> Hi Klaus, sorry for not spotting this before.  In the SCSI subsystem we
> moved away from using id as guest-visible data.  Keeping it as a default is
> fine I guess, but would it be possible to add an nqn property to nvme-subsys
> and use it if it is present instead of the id?
> 
> Thanks,
> 
> Paolo
> 

Hi Paolo,

Thanks for pointing this out! Absolutely - we have no specific reason to
use 'id', so we can just change it completely to use 'nqn'.

Peter, you want this in a v2 or did you already start integration of
this PR?


signature.asc
Description: PGP signature

Re: [RFC PATCH 17/42] target/mips/tx79: Introduce PEXTUW (Parallel Extend Upper from Word)

[Philippe Mathieu-Daudé]

On 2/15/21 5:44 PM, Richard Henderson wrote:
> On 2/14/21 9:58 AM, Philippe Mathieu-Daudé wrote:
>> +tcg_gen_deposit_i64(cpu_gpr[a->rd], bx, ax, 32, 32);
>> +tcg_gen_shri_i64(bx, bx, 32);
>> +tcg_gen_deposit_i64(cpu_gpr_hi[a->rd], ax, bx, 0, 32);
> 
> I think you should pull this out as a helper:
> 
> void gen_pextw(TCGv_i64 dl, TCGv_i64 dh, TCGv_i64 a, TCGv_i64 b);
> 
> since you'll re-use this for PEXTLW.

Indeed, thanks :)

Re: [PULL 01/38] hw/block/nvme: introduce nvme-subsys device

[Paolo Bonzini]

On 08/03/21 13:22, Klaus Jensen wrote:


This patch introduced a simple nvme-subsys device model.  The subsystem
will be prepared with subsystem NQN with  provided in
nvme-subsys device:

   ex) -device nvme-subsys,id=subsys0: nqn.2019-08.org.qemu:subsys0


Hi Klaus, sorry for not spotting this before.  In the SCSI subsystem we 
moved away from using id as guest-visible data.  Keeping it as a default 
is fine I guess, but would it be possible to add an nqn property to 
nvme-subsys and use it if it is present instead of the id?


Thanks,

Paolo

Re: [PATCH] xen-block: Fix removal of backend instance via xenstore

[Paolo Bonzini]

On 08/03/21 19:14, Anthony PERARD wrote:

On Mon, Mar 08, 2021 at 06:37:38PM +0100, Paolo Bonzini wrote:

On 08/03/21 18:29, Anthony PERARD wrote:

If nothing else works then I guess it's okay, but why can't you do the
xen_block_drive_destroy from e.g. an unrealize callback?


I'm not sure if that's possible.

xen_block_device_create/xen_block_device_destroy() is supposed to be
equivalent to do those qmp commands:
  blockdev-add node-name=xvdz-qcow2 driver=qcow2 
file={"driver":"file","filename":"disk.qcow2","locking":"off"}
  device_add id=xvdz driver=xen-disk vdev=xvdz drive=xvdz-qcow2

But I tried to add a call xen_block_drive_destroy from
xen_block_unrealize, but that still is called too early, it's called
before object_property_del_all() which would delete "drive" and call
release_drive() which would free the node.


Can you use blockdev_mark_auto_del?  Then you don't have to call
xen_block_drive_destroy at all.


There is no legacy_dinfo, so blockdev_mark_auto_del doesn't work.


Then I guess it's okay.  Perhaps you can rename the function to 
xen_block_blockdev_destroy so that it's clear it's a blockdev and no 
drive.  Thanks,


Paolo

[Bug 1918084] Re: Build fails on macOS 11.2.2

[Eddy Hahn]

[87/5089] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o
FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o 
c++ -Ilibcommon.fa.p -I. -I.. -I../capstone/include/capstone -I../slirp 
-I../slirp/src -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader 
-I/opt/serverplus/dependencies/glib/include/glib-2.0 
-I/opt/serverplus/dependencies/glib/lib/glib-2.0/include 
-I/opt/serverplus/dependencies/glib/include/gio-unix-2.0/ 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include
 -I/opt/serverplus/dependencies/pixman/include/pixman-1 -Xclang 
-fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 
-O2 -g -iquote . -iquote /opt/build/build/stage/qemu -iquote 
/opt/build/build/stage/qemu/include -iquote 
/opt/build/build/stage/qemu/disas/libvixl -iquote 
/opt/build/build/stage/qemu/tcg/i386 -iquote 
/opt/build/build/stage/qemu/accel/tcg -Wno-unused-function 
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -m64 
-mcx16 -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common 
-fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined 
-Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value 
-Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-tautological-type-limit-compare -fstack-protector-strong 
-DSTRUCT_IOVEC_DEFINED -D_REENTRANT -MD -MQ 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o 
libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc
In file included from ../disas/libvixl/vixl/utils.cc:27:
In file included from /opt/build/build/stage/qemu/disas/libvixl/vixl/utils.h:30:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/string.h:61:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/_types.h:27:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/sys/cdefs.h:236:5:
 warning: '__STDC_VERSION__' is not defined, evaluates to 0 [-Wundef]
#if __STDC_VERSION__ < 199901
^
In file included from ../disas/libvixl/vixl/utils.cc:27:
In file included from /opt/build/build/stage/qemu/disas/libvixl/vixl/utils.h:31:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:317:9:
 error: no member named 'signbit' in the global namespace
using ::signbit;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:318:9:
 error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:319:9:
 error: no member named 'isfinite' in the global namespace; did you mean 
'finite'?
using ::isfinite;
  ~~^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/math.h:752:12:
 note: 'finite' declared here
extern int finite(double)
   ^
In file included from ../disas/libvixl/vixl/utils.cc:27:
In file included from /opt/build/build/stage/qemu/disas/libvixl/vixl/utils.h:31:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:320:9:
 error: no member named 'isinf' in the global namespace
using ::isinf;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:321:9:
 error: no member named 'isnan' in the global namespace
using ::isnan;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:322:9:
 error: no member named 'isnormal' in the global namespace
using ::isnormal;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:323:9:
 error: no member named 'isgreater' in the global namespace
using ::isgreater;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:324:9:
 error: no member named 'isgreaterequal' in the global namespace
using ::isgreaterequal;
  ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:325:9:
 error: no member named 'isless' in the global namespace
using ::isless;
  ~~^

Re: [PATCH] xen-block: Fix removal of backend instance via xenstore

[Anthony PERARD via]

On Mon, Mar 08, 2021 at 06:37:38PM +0100, Paolo Bonzini wrote:
> On 08/03/21 18:29, Anthony PERARD wrote:
> > > If nothing else works then I guess it's okay, but why can't you do the
> > > xen_block_drive_destroy from e.g. an unrealize callback?
> > 
> > I'm not sure if that's possible.
> > 
> > xen_block_device_create/xen_block_device_destroy() is supposed to be
> > equivalent to do those qmp commands:
> >  blockdev-add node-name=xvdz-qcow2 driver=qcow2 
> > file={"driver":"file","filename":"disk.qcow2","locking":"off"}
> >  device_add id=xvdz driver=xen-disk vdev=xvdz drive=xvdz-qcow2
> > 
> > But I tried to add a call xen_block_drive_destroy from
> > xen_block_unrealize, but that still is called too early, it's called
> > before object_property_del_all() which would delete "drive" and call
> > release_drive() which would free the node.
> 
> Can you use blockdev_mark_auto_del?  Then you don't have to call
> xen_block_drive_destroy at all.

There is no legacy_dinfo, so blockdev_mark_auto_del doesn't work.

-- 
Anthony PERARD

Re: [RFC] adding a generic QAPI event for failed device hotunplug

[Daniel Henrique Barboza]

On 3/8/21 2:04 PM, Markus Armbruster wrote:

Daniel Henrique Barboza  writes:


On 3/6/21 3:57 AM, Markus Armbruster wrote:

Cc: ACPI maintainers for additional expertise.

Daniel Henrique Barboza  writes:


Hi,

Recent changes in pseries code (not yet pushed, available at David's
ppc-for-6.0) are using the QAPI event MEM_UNPLUG_ERROR to report memory
hotunplug errors in the pseries machine.

The pseries machine is also using a timeout to cancel CPU hotunplugs that
takes too long to finish (in which we're assuming a guest side error) and
it would be desirable to also send a QAPI event for this case as well.

At this moment, there is no "CPU_UNPLUG_ERROR" in QAPI (guess ACPI doesn't
need it).


I see two interpretations of "ACPI doesn't need":

1. Unplug can't fail, or QEMU can't detect failure.  Michael, Igor?

2. Management applications haven't needed to know badly enough to
implement an event.


Before sending patches to implement this new event I had a talk
with David Gibson and he suggested that, instead of adding a new 
CPU_UNPLUG_ERROR
event, we could add a generic event (e.g. DEVICE_UNPLUG_ERROR) that can be
used by the pseries machine in both error scenarios (MEM and CPU).


Good point.  One general event is better than two special ones that
could easily grow siblings.


This could also be used by x86 as well, although I believe the use of
MEM_UNPLUG_ERROR would need to be kept for awhile to avoid breaking ABI.


Yes.  Our rules for interface deprecation apply.


Any suggestions/comments?


We should document the event's reliability.  Are there unplug operations
where we can't detect failure?  Are there unplug operations where we
could, but haven't implemented the event?


The current version of the PowerPC spec that the pseries machine implements
(LOPAR) does not predict a way for the virtual machine to report a hotunplug
error back to the hypervisor. If something fails, the hypervisor is left
in the dark.

What happened in the 6.0.0 dev cycle is that we faced a reliable way of


Do you mean "unreliable way"?


I guess a better word would be 'reproducible', as in we discovered a 
reproducible
way of getting the guest kernel to refuse the CPU hotunplug.




making CPU hotunplug fail in the guest (trying to hotunplug the last online
CPU) and the pseries machine was unprepared for dealing with it. We ended up
implementing a hotunplug timeout and, if the timeout kicks in, we're assuming
that the CPU hotunplug failed in the guest. This is the first scenario we have
today where we want to send a QAPI event informing the CPU hotunplug error,
but this event does not exist in QEMU ATM.


When the timeout kicks in, how can you know the operation failed?  You
better be sure when you send an error event.  In other words: what
prevents the scenario where the operation is much slower than you
expect, the timeout expires, the error event is sent, and then the
operation completes successfully?


A CPU hotunplug in a pseries guest takes no more than a couple of seconds, even
if the guest is under heavy load. The timeout is set to 15 seconds.

I'm aware that there's always that special use case, that we haven't seen yet,
where this assumption is no longer valid. The plan is to change the spec and the
guest kernel to signal the CPU hotunplug error back to QEMU before the dragon
lands. For now, timing out the CPU hotunplug process when we're almost certain
(but not 100%) that it failed in the guest is the best can do.

For both cases I want to use DEVICE_UNPLUG_ERROR right from the start, avoiding
guest visible changes when we change how we're detecting the unplug errors.




The second scenario is a memory hotunplug error. I found out that the pseries
guest kernel does a reconfiguration step when re-attaching the DIMM right
after refusing the hotunplug, and this reconfiguration is visible to QEMU.
I proceeded to make the pseries machine detect this error case, rollback the
unplug operation and fire up the MEM_UNPLUG_ERROR. This case is already covered
by QAPI, but if we add a DEVICE_UNPLUG_ERROR event I would use it in this case 
as
well instead of the MEM specific one.

This investigation and work in the mem hotunplug error path triggered a
discussion in qemu-ppc, where we're considering whether we should do the same
signalling the kernel does for the DIMM hotunplug error for all other device
hotunplug errors, given that the reconfiguration per se is not forbidden by 
LOPAR
and it's currently a no-op. We would make a LOPAR spec change to make this an
official hotunplug error report mechanism, and all pseries hotunplug operations,
for all devices, would report DEVICE_UNPLUG_ERROR QAPI events in the error path.

Granted, the spec change + Kernel change is not something that we will be able
to nail down in the 6.0.0 cycle, but having the DEVICE_UNPLUG_ERROR QAPI event
already in place would make it easier for the future as well.


I have a doc draft of these changes/infos that I forgot to post. I 

Re: [PULL 01/38] hw/block/nvme: introduce nvme-subsys device

[Peter Maydell]

On Mon, 8 Mar 2021 at 18:46, Klaus Jensen  wrote:
>
> On Mar  8 19:32, Paolo Bonzini wrote:
> > On 08/03/21 13:22, Klaus Jensen wrote:
> > >
> > > This patch introduced a simple nvme-subsys device model.  The subsystem
> > > will be prepared with subsystem NQN with  provided in
> > > nvme-subsys device:
> > >
> > >ex) -device nvme-subsys,id=subsys0: nqn.2019-08.org.qemu:subsys0
> >
> > Hi Klaus, sorry for not spotting this before.  In the SCSI subsystem we
> > moved away from using id as guest-visible data.  Keeping it as a default is
> > fine I guess, but would it be possible to add an nqn property to nvme-subsys
> > and use it if it is present instead of the id?
> >
> > Thanks,
> >
> > Paolo
> >
>
> Hi Paolo,
>
> Thanks for pointing this out! Absolutely - we have no specific reason to
> use 'id', so we can just change it completely to use 'nqn'.
>
> Peter, you want this in a v2 or did you already start integration of
> this PR?

I haven't yet started working on this PR so if the change is trivial
feel free to roll a v2.

-- PMM

Re: [PATCH v2] MAINTAINERS: Merge the Gitlab-CI section into the generic CI section

[Philippe Mathieu-Daudé]

On 3/8/21 6:01 PM, Thomas Huth wrote:
> On 08/03/2021 17.35, Philippe Mathieu-Daudé wrote:
>> On 3/8/21 4:46 PM, Thomas Huth wrote:
>>> The status of the gitlab-CI files is currently somewhat confusing, and
>>> it is often not quite clear whether a patch should go via my tree or
>>> via the testing tree of Alex. That situation has grown historically...
>>> Initially, I was the only one using the gitlab-CI, just for my private
>>> repository there. But in the course of time, the gitlab-CI switched to
>>> use the containers from tests/docker/ (which is not part of the
>>> gitlab-CI
>>> section in the MAINTAINERS file), and QEMU now even switched to
>>> gitlab.com
>>> completely for the repository and will soon use it as its gating CI,
>>> too,
>>> so it makes way more sense if the gitlab-ci.yml files belong to the
>>> people
>>> who are owning the qemu-project on gitlab.com and take care of the
>>> gitlab
>>> CI there. Thus let's merge the gitlab-ci section into the common
>>> "test and
>>> build automation" section.
>>>
>>> While we're at it, I'm also removing the line with Fam there for now,
>>> since he was hardly active during the last years in this area anymore.
>>> If he ever gets more time for this part again in the future, we surely
>>> can add the line back again.
>>>
>>> Now to avoid that Alex is listed here alone, Philippe and I agreed to
>>> help as backup maintainers here, too.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>   v2: Keep Philippe and myself as maintainer instead of reviewer
>>>
>>>   MAINTAINERS | 21 +++--
>>>   1 file changed, 7 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 26c9454823..5c4c179abb 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -3262,17 +3262,21 @@ F: include/hw/remote/iohub.h
>>>     Build and test automation
>>>   -
>>> -Build and test automation
>>> +Build and test automation, Linux Continuous Integration
>>
>> I'd rather not limit it to Linux hosts...
>>
>>>   M: Alex Bennée 
>>> -M: Fam Zheng 
>>
>> I'm not sure about Fam removal, he is the one maintaining patchew
>> (see [*] below)... Maybe we need an Ack from Paolo?
> 
> We could split the Patchew part into a separate section... OTOH, there
> are no patchew related files in the main git repo anyway that we track
> in the MAINTAINERS file, so maybe it makes more sense to simply remove
> that line? (Patchew admins are already mentioned here:
> https://wiki.qemu.org/AdminContacts )

Also here:
https://wiki.qemu.org/Testing/CI

So it makes sense to me to remove the patchew line.

Re: [RFC PATCH 16/42] target/mips/tx79: Introduce PSUB* opcodes (Parallel Subtract)

[Philippe Mathieu-Daudé]

On 2/15/21 5:38 PM, Richard Henderson wrote:
> On 2/14/21 9:58 AM, Philippe Mathieu-Daudé wrote:
>> +/* Parallel Subtract Byte */
>> +static bool trans_PSUBB(DisasContext *ctx, arg_rtype *a)
>> +{
>> +return trans_parallel_substract(ctx, a, 8);
>> +}
>> +
>> +/* Parallel Subtract Halfword */
>> +static bool trans_PSUBH(DisasContext *ctx, arg_rtype *a)
>> +{
>> +return trans_parallel_substract(ctx, a, 16);
>> +}
>> +
>> +/* Parallel Subtract Word */
>> +static bool trans_PSUBW(DisasContext *ctx, arg_rtype *a)
>> +{
>> +return trans_parallel_substract(ctx, a, 32);
>> +}
> 
> We already have helpers for these operations.  Use your trans_parallel_logic
> with tcg_gen_vec_sub{8,16,32}_i64.

Very nice :>

Re: [PATCH v2 2/3] target/m68k: reformat m68k_features enum

[Laurent Vivier]

Le 08/03/2021 à 13:11, Mark Cave-Ayland a écrit :
> Move the feature comment from after the feature name to the preceding line to
> allow for longer feature names and descriptions without hitting the 80
> character line limit.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  target/m68k/cpu.h | 66 +++
>  1 file changed, 44 insertions(+), 22 deletions(-)
> 
> diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> index 7c3feeaf8a..ce558e9b03 100644
> --- a/target/m68k/cpu.h
> +++ b/target/m68k/cpu.h
> @@ -475,36 +475,58 @@ void do_m68k_semihosting(CPUM68KState *env, int nr);
>   */
>  
>  enum m68k_features {
> -M68K_FEATURE_M68000,   /* Base m68k instruction set */
> +/* Base m68k instruction set */
> +M68K_FEATURE_M68000,
>  M68K_FEATURE_M68010,
>  M68K_FEATURE_M68020,
>  M68K_FEATURE_M68030,
>  M68K_FEATURE_M68040,
>  M68K_FEATURE_M68060,
> -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. (680[2346]0, ISA A+ or B). */
> +/* Base Coldfire set Rev A. */
> +M68K_FEATURE_CF_ISA_A,
> +/* (ISA B or C). */
> +M68K_FEATURE_CF_ISA_B,
> +/* BIT/BITREV, FF1, STRLDSR (ISA A+ or C). */
> +M68K_FEATURE_CF_ISA_APLUSC,
> +/* BRA with Long branch. (680[2346]0, ISA A+ or B). */
> +M68K_FEATURE_BRAL,
>  M68K_FEATURE_CF_FPU,
>  M68K_FEATURE_CF_MAC,
>  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. */
> -M68K_FEATURE_LONG_MULDIV, /* 32 bit mul/div. (680[2346]0, and CPU32) */
> -M68K_FEATURE_QUAD_MULDIV, /* 64 bit mul/div. (680[2346]0, and CPU32) */
> -M68K_FEATURE_BCCL,  /* Bcc with Long branches. (680[2346]0, and CPU32) */
> -M68K_FEATURE_BITFIELD, /* BFxxx Bit field insns. (680[2346]0) */
> -M68K_FEATURE_FPU,   /* fpu insn. (680[46]0) */
> -M68K_FEATURE_CAS,   /* CAS/CAS2[WL] insns. (680[2346]0) */
> -M68K_FEATURE_BKPT,  /* BKPT insn. (680[12346]0, and CPU32) */
> -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) */
> +/* Revision B EMAC (dual accumulate). */
> +M68K_FEATURE_CF_EMAC_B,
> +/* User Stack Pointer. (680[012346]0, ISA A+, B or C). */
> +M68K_FEATURE_USP,
> +/* Master Stack Pointer. (680[234]0) */
> +M68K_FEATURE_MSP,
> +/* 68020+ full extension word. */
> +M68K_FEATURE_EXT_FULL,
> +/* word sized address index registers. */
> +M68K_FEATURE_WORD_INDEX,
> +/* scaled address index registers. */
> +M68K_FEATURE_SCALED_INDEX,
> +/* 32 bit mul/div. (680[2346]0, and CPU32) */
> +M68K_FEATURE_LONG_MULDIV,
> +/* 64 bit mul/div. (680[2346]0, and CPU32) */
> +M68K_FEATURE_QUAD_MULDIV,
> +/* Bcc with Long branches. (680[2346]0, and CPU32) */
> +M68K_FEATURE_BCCL,
> +/* BFxxx Bit field insns. (680[2346]0) */
> +M68K_FEATURE_BITFIELD,
> +/* fpu insn. (680[46]0) */
> +M68K_FEATURE_FPU,
> +/* CAS/CAS2[WL] insns. (680[2346]0) */
> +M68K_FEATURE_CAS,
> +/* BKPT insn. (680[12346]0, and CPU32) */
> +M68K_FEATURE_BKPT,
> +/* RTD insn. (680[12346]0, and CPU32) */
> +M68K_FEATURE_RTD,
> +/* CHK2 insn. (680[2346]0, and CPU32) */
> +M68K_FEATURE_CHK2,
> +/* MOVEP insn. (680[01234]0, and CPU32) */
> +M68K_FEATURE_MOVEP,
> +/* MOVEC insn. (from 68010) */
> +M68K_FEATURE_MOVEC,
>  };
>  
>  static inline int m68k_feature(CPUM68KState *env, int feature)
> 

Reviewed-by: Laurent Vivier 

Re: [RFC PATCH v2] meson: Only generate trace files for selected targets

[Philippe Mathieu-Daudé]

On 3/8/21 5:46 PM, Stefan Hajnoczi wrote:
> On Wed, Feb 24, 2021 at 10:35:15PM +0100, Philippe Mathieu-Daudé wrote:
>> We don't need to generate trace files for targets we
>> are not building. Restrict the the ones selected.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  meson.build | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/meson.build b/meson.build
>> index 05a67c20d93..8503aa1b628 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -1826,16 +1826,16 @@
>>trace_events_subdirs += [
>>  'accel/tcg',
>>  'hw/core',
>> -'target/arm',
>> -'target/hppa',
>> -'target/i386',
>>  'target/i386/kvm',
> 
> Please add a comment explaining why an exception is needed here and the
> rest of the target directories are handled by the loop below when you
> send a non-RFC patch.

Better would be a recursive function that adds the directory if
necessary. But I'm happy adding a simple comment =)

> 
> That will help people who add sub-directories in the future.

Yes. Anyhow I expect this to clash with Claudio's work in progress
(which split target/ and add multiple subdirectories).

[PULL 54/54] hw/timer/renesas_tmr: Fix use of uninitialized data in read_tcnt()

[Peter Maydell]

The read_tcnt() function calculates the TCNT register values for the
two channels of the timer module; it sets these up in the local
tcnt[] array, and eventually returns either one or both of them,
depending on whether the access is 8 or 16 bits.  However, not all of
the code paths through this function set both elements of this array:
if the guest has programmed the TCCR.CSS register fields to values
which are either documented as not to be used or which QEMU does not
implement, then the function will return uninitialized data.  (This
was spotted by Coverity.)

Add the missing CSS cases to this code, so that we return a
consistent value instead of uninitialized data, and so the code
structure indicates what's happening.

Fixes: CID 1429976
Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20210219223241.16344-3-peter.mayd...@linaro.org
---
 hw/timer/renesas_tmr.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/hw/timer/renesas_tmr.c b/hw/timer/renesas_tmr.c
index 22260aaaba5..eed39917fec 100644
--- a/hw/timer/renesas_tmr.c
+++ b/hw/timer/renesas_tmr.c
@@ -46,7 +46,9 @@ REG8(TCCR, 10)
   FIELD(TCCR, CSS,   3, 2)
   FIELD(TCCR, TMRIS, 7, 1)
 
+#define CSS_EXTERNAL  0x00
 #define CSS_INTERNAL  0x01
+#define CSS_INVALID   0x02
 #define CSS_CASCADING 0x03
 #define CCLR_A0x01
 #define CCLR_B0x02
@@ -130,13 +132,20 @@ static uint16_t read_tcnt(RTMRState *tmr, unsigned size, 
int ch)
 if (delta > 0) {
 tmr->tick = now;
 
-if (FIELD_EX8(tmr->tccr[1], TCCR, CSS) == CSS_INTERNAL) {
+switch (FIELD_EX8(tmr->tccr[1], TCCR, CSS)) {
+case CSS_INTERNAL:
 /* timer1 count update */
 elapsed = elapsed_time(tmr, 1, delta);
 if (elapsed >= 0x100) {
 ovf = elapsed >> 8;
 }
 tcnt[1] = tmr->tcnt[1] + (elapsed & 0xff);
+break;
+case CSS_INVALID: /* guest error to have set this */
+case CSS_EXTERNAL: /* QEMU doesn't implement these */
+case CSS_CASCADING:
+tcnt[1] = tmr->tcnt[1];
+break;
 }
 switch (FIELD_EX8(tmr->tccr[0], TCCR, CSS)) {
 case CSS_INTERNAL:
@@ -144,9 +153,11 @@ static uint16_t read_tcnt(RTMRState *tmr, unsigned size, 
int ch)
 tcnt[0] = tmr->tcnt[0] + elapsed;
 break;
 case CSS_CASCADING:
-if (ovf > 0) {
-tcnt[0] = tmr->tcnt[0] + ovf;
-}
+tcnt[0] = tmr->tcnt[0] + ovf;
+break;
+case CSS_INVALID: /* guest error to have set this */
+case CSS_EXTERNAL: /* QEMU doesn't implement this */
+tcnt[0] = tmr->tcnt[0];
 break;
 }
 } else {
-- 
2.20.1

Re: [PATCH 43/44] docs/system/arm/mps2.rst: Document the new mps3-an547 board

[Peter Maydell]

On Fri, 5 Mar 2021 at 10:22, Peter Maydell  wrote:
>
> On Fri, 5 Mar 2021 at 01:28, Richard Henderson
>  wrote:
> >
> > On 2/19/21 6:46 AM, Peter Maydell wrote:
> > > @@ -1,5 +1,5 @@
> > > -Arm MPS2 and MPS3 boards (``mps2-an385``, ``mps2-an386``, 
> > > ``mps2-an500``, ``mps2-an505``, ``mps2-an511``, ``mps2-an521``, 
> > > ``mps3-an524``)
> > > -=
> > > +Arm MPS2 and MPS3 boards (``mps2-an385``, ``mps2-an386``, 
> > > ``mps2-an500``, ``mps2-an505``, ``mps2-an511``, ``mps2-an521``, 
> > > ``mps3-an524``, ``mps3-an547``)'
> > I think you should drop the list here, as it has gotten *way* too long.
> >
> > > @@ -27,6 +27,8 @@ QEMU models the following FPGA images:
> > > Dual Cortex-M33 as documented in Arm Application Note AN521
> > >   ``mps3-an524``
> > > Dual Cortex-M33 on an MPS3, as documented in Arm Application Note 
> > > AN524
> > > +``mps3-an547``
> > > +  Cortex-M55 on an MPS3, as documented in Arm Application Note AN547
> >
> > The list is down here, anyway.
>
> The title is what generates the text for the table of contents in the
> next page up:
>
> https://qemu-project.gitlab.io/qemu/system/target-arm.html#board-specific-documentation
>
> I like having every board model listed explicitly in that ToC. (Though we
> have broken this rule for the Aspeed boards with "*-bmc"...)

I put this patch into the pullreq as-is, because the series is otherwise
ready to go and this was a minor thing; happy to send a followup patch
tweaking the title text if we conclude that we want to do that.

thanks
-- PMM

[PULL 45/54] tests/qtest/sse-timer-test: Test the system timer

[Peter Maydell]

Add a test which tests various parts of the functionality of the
SSE system timer.

Signed-off-by: Peter Maydell 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Philippe Mathieu-Daudé 
---
 tests/qtest/sse-timer-test.c | 91 
 1 file changed, 91 insertions(+)

diff --git a/tests/qtest/sse-timer-test.c b/tests/qtest/sse-timer-test.c
index 5b86ef6dbbf..f4f6704b308 100644
--- a/tests/qtest/sse-timer-test.c
+++ b/tests/qtest/sse-timer-test.c
@@ -99,6 +99,96 @@ static void test_counter(void)
 g_assert_cmpuint(readl(COUNTER_BASE + CNTCV_HI), ==, 0);
 }
 
+static void test_timer(void)
+{
+/* Basic timer functionality test */
+
+reset_counter_and_timer();
+/*
+ * The timer is behind a Peripheral Protection Controller, and
+ * qtest accesses are always non-secure (no memory attributes),
+ * so we must program the PPC to accept NS transactions.  TIMER0
+ * is on port 0 of PPC0, controlled by bit 0 of this register.
+ */
+writel(PERIPHNSPPC0, 1);
+/* We must enable the System Counter or the timer won't run. */
+writel(COUNTER_BASE + CNTCR, 1);
+
+/* Timer starts disabled and with a counter of 0 */
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 0);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_LO), ==, 0);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_HI), ==, 0);
+
+/* Turn it on */
+writel(TIMER_BASE + CNTP_CTL, 1);
+
+/* Is the timer ticking? */
+clock_step_ticks(100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_LO), ==, 100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_HI), ==, 0);
+
+/* Set the CompareValue to 4000 ticks */
+writel(TIMER_BASE + CNTP_CVAL_LO, 4000);
+writel(TIMER_BASE + CNTP_CVAL_HI, 0);
+
+/* Check TVAL view of the counter */
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_TVAL), ==, 3900);
+
+/* Advance to the CompareValue mark and check ISTATUS is set */
+clock_step_ticks(3900);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_TVAL), ==, 0);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 5);
+
+/* Now exercise the auto-reload part of the timer */
+writel(TIMER_BASE + CNTP_AIVAL_RELOAD, 200);
+writel(TIMER_BASE + CNTP_AIVAL_CTL, 1);
+
+/* Check AIVAL was reloaded and that ISTATUS is now clear */
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_LO), ==, 4200);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_HI), ==, 0);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+
+/*
+ * Check that when we advance forward to the reload time the interrupt
+ * fires and the value reloads
+ */
+clock_step_ticks(100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+clock_step_ticks(100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 5);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_LO), ==, 4400);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_HI), ==, 0);
+
+clock_step_ticks(100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 5);
+/* Check that writing 0 to CLR clears the interrupt */
+writel(TIMER_BASE + CNTP_AIVAL_CTL, 1);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+/* Check that when we move forward to the reload time it fires again */
+clock_step_ticks(100);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 5);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_LO), ==, 4600);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_HI), ==, 0);
+
+/*
+ * Step the clock far enough that we overflow the low half of the
+ * CNTPCT and AIVAL registers, and check that their high halves
+ * give the right values. We do the forward movement in
+ * non-autoinc mode because otherwise it takes forever as the
+ * timer has to emulate all the 'reload at t + N, t + 2N, etc'
+ * steps.
+ */
+writel(TIMER_BASE + CNTP_AIVAL_CTL, 0);
+clock_step_ticks(0x42ULL << 32);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_LO), ==, 4400);
+g_assert_cmpuint(readl(TIMER_BASE + CNTPCT_HI), ==, 0x42);
+
+/* Turn on the autoinc again to check AIVAL_HI */
+writel(TIMER_BASE + CNTP_AIVAL_CTL, 1);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_LO), ==, 4600);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_HI), ==, 0x42);
+}
+
 int main(int argc, char **argv)
 {
 int r;
@@ -108,6 +198,7 @@ int main(int argc, char **argv)
 qtest_start("-machine mps3-an547");
 
 qtest_add_func("/sse-timer/counter", test_counter);
+qtest_add_func("/sse-timer/timer", test_timer);
 
 r = g_test_run();
 
-- 
2.20.1

[PULL 37/54] hw/misc/mps2-fpgaio: Fold counters subsection into main vmstate

[Peter Maydell]

We've already broken migration compatibility for all the MPS
boards, so we might as well take advantage of this to simplify
the vmstate for the FPGAIO device by folding the counters
subsection into the main vmstate description.

Signed-off-by: Peter Maydell 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-id: 20210219144617.4782-38-peter.mayd...@linaro.org
---
 hw/misc/mps2-fpgaio.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/hw/misc/mps2-fpgaio.c b/hw/misc/mps2-fpgaio.c
index f3db88ddcc8..72598c8a3d2 100644
--- a/hw/misc/mps2-fpgaio.c
+++ b/hw/misc/mps2-fpgaio.c
@@ -285,41 +285,21 @@ static void mps2_fpgaio_realize(DeviceState *dev, Error 
**errp)
 }
 }
 
-static bool mps2_fpgaio_counters_needed(void *opaque)
-{
-/* Currently vmstate.c insists all subsections have a 'needed' function */
-return true;
-}
-
-static const VMStateDescription mps2_fpgaio_counters_vmstate = {
-.name = "mps2-fpgaio/counters",
+static const VMStateDescription mps2_fpgaio_vmstate = {
+.name = "mps2-fpgaio",
 .version_id = 2,
 .minimum_version_id = 2,
-.needed = mps2_fpgaio_counters_needed,
 .fields = (VMStateField[]) {
+VMSTATE_UINT32(led0, MPS2FPGAIO),
+VMSTATE_UINT32(prescale, MPS2FPGAIO),
+VMSTATE_UINT32(misc, MPS2FPGAIO),
 VMSTATE_INT64(clk1hz_tick_offset, MPS2FPGAIO),
 VMSTATE_INT64(clk100hz_tick_offset, MPS2FPGAIO),
 VMSTATE_UINT32(counter, MPS2FPGAIO),
 VMSTATE_UINT32(pscntr, MPS2FPGAIO),
 VMSTATE_INT64(pscntr_sync_ticks, MPS2FPGAIO),
 VMSTATE_END_OF_LIST()
-}
-};
-
-static const VMStateDescription mps2_fpgaio_vmstate = {
-.name = "mps2-fpgaio",
-.version_id = 1,
-.minimum_version_id = 1,
-.fields = (VMStateField[]) {
-VMSTATE_UINT32(led0, MPS2FPGAIO),
-VMSTATE_UINT32(prescale, MPS2FPGAIO),
-VMSTATE_UINT32(misc, MPS2FPGAIO),
-VMSTATE_END_OF_LIST()
 },
-.subsections = (const VMStateDescription*[]) {
-_fpgaio_counters_vmstate,
-NULL
-}
 };
 
 static Property mps2_fpgaio_properties[] = {
-- 
2.20.1

[PULL 48/54] hw/dma: Implement a Xilinx CSU DMA model

[Peter Maydell]

From: Xuzhou Cheng 

ZynqMP QSPI supports SPI transfer using DMA mode, but currently this
is unimplemented. When QSPI is programmed to use DMA mode, QEMU will
crash. This is observed when testing VxWorks 7.

This adds a Xilinx CSU DMA model and the implementation is based on
https://github.com/Xilinx/qemu/blob/master/hw/dma/csu_stream_dma.c.
The DST part of the model is verified along with ZynqMP GQSPI model.

Signed-off-by: Xuzhou Cheng 
Signed-off-by: Bin Meng 
Tested-by: Edgar E. Iglesias 
Reviewed-by: Edgar E. Iglesias 
Message-id: 20210303135254.3970-2-bmeng...@gmail.com
Signed-off-by: Peter Maydell 
---
 include/hw/dma/xlnx_csu_dma.h |  52 +++
 hw/dma/xlnx_csu_dma.c | 745 ++
 hw/dma/Kconfig|   4 +
 hw/dma/meson.build|   1 +
 4 files changed, 802 insertions(+)
 create mode 100644 include/hw/dma/xlnx_csu_dma.h
 create mode 100644 hw/dma/xlnx_csu_dma.c

diff --git a/include/hw/dma/xlnx_csu_dma.h b/include/hw/dma/xlnx_csu_dma.h
new file mode 100644
index 000..204d94c6737
--- /dev/null
+++ b/include/hw/dma/xlnx_csu_dma.h
@@ -0,0 +1,52 @@
+/*
+ * Xilinx Platform CSU Stream DMA emulation
+ *
+ * This implementation is based on
+ * https://github.com/Xilinx/qemu/blob/master/hw/dma/csu_stream_dma.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#ifndef XLNX_CSU_DMA_H
+#define XLNX_CSU_DMA_H
+
+#define TYPE_XLNX_CSU_DMA "xlnx.csu_dma"
+
+#define XLNX_CSU_DMA_R_MAX (0x2c / 4)
+
+typedef struct XlnxCSUDMA {
+SysBusDevice busdev;
+MemoryRegion iomem;
+MemTxAttrs attr;
+MemoryRegion *dma_mr;
+AddressSpace *dma_as;
+qemu_irq irq;
+StreamSink *tx_dev; /* Used as generic StreamSink */
+ptimer_state *src_timer;
+
+uint16_t width;
+bool is_dst;
+bool r_size_last_word;
+
+StreamCanPushNotifyFn notify;
+void *notify_opaque;
+
+uint32_t regs[XLNX_CSU_DMA_R_MAX];
+RegisterInfo regs_info[XLNX_CSU_DMA_R_MAX];
+} XlnxCSUDMA;
+
+#define XLNX_CSU_DMA(obj) \
+OBJECT_CHECK(XlnxCSUDMA, (obj), TYPE_XLNX_CSU_DMA)
+
+#endif
diff --git a/hw/dma/xlnx_csu_dma.c b/hw/dma/xlnx_csu_dma.c
new file mode 100644
index 000..50709a3909b
--- /dev/null
+++ b/hw/dma/xlnx_csu_dma.c
@@ -0,0 +1,745 @@
+/*
+ * Xilinx Platform CSU Stream DMA emulation
+ *
+ * This implementation is based on
+ * https://github.com/Xilinx/qemu/blob/master/hw/dma/csu_stream_dma.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "sysemu/dma.h"
+#include "hw/ptimer.h"
+#include "hw/stream.h"
+#include "hw/register.h"
+#include "hw/dma/xlnx_csu_dma.h"
+
+/*
+ * Ref: UG1087 (v1.7) February 8, 2019
+ * 
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
+ * CSUDMA Module section
+ */
+REG32(ADDR, 0x0)
+FIELD(ADDR, ADDR, 2, 30) /* wo */
+REG32(SIZE, 0x4)
+FIELD(SIZE, SIZE, 2, 27) /* wo */
+FIELD(SIZE, LAST_WORD, 0, 1) /* rw, only exists in SRC */
+REG32(STATUS, 0x8)
+FIELD(STATUS, DONE_CNT, 13, 3) /* wtc */
+FIELD(STATUS, FIFO_LEVEL, 5, 8) /* ro */
+FIELD(STATUS, OUTSTANDING, 1, 4) /* ro */
+FIELD(STATUS, BUSY, 0, 1) /* ro */
+REG32(CTRL, 0xc)
+FIELD(CTRL, FIFOTHRESH, 25, 7) /* rw, only exists in DST, reset 0x40 */
+FIELD(CTRL, APB_ERR_RESP, 24, 1) /* rw */
+FIELD(CTRL, ENDIANNESS, 23, 1) /* rw */
+FIELD(CTRL, AXI_BRST_TYPE, 22, 1) /* rw */
+FIELD(CTRL, TIMEOUT_VAL, 10, 12) /* rw, reset: 0xFFE */
+FIELD(CTRL, FIFO_THRESH, 2, 8) /* rw, reset: 0x80 */
+FIELD(CTRL, PAUSE_STRM, 1, 1) /* rw */
+FIELD(CTRL, PAUSE_MEM, 0, 1) /* rw */

[PULL 46/54] tests/qtest/sse-timer-test: Test counter scaling changes

[Peter Maydell]

Test that when we change the scaling of the system counter that the
system timer responds appropriately.

Signed-off-by: Peter Maydell 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Philippe Mathieu-Daudé 
---
 tests/qtest/sse-timer-test.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/tests/qtest/sse-timer-test.c b/tests/qtest/sse-timer-test.c
index f4f6704b308..a65d7542d51 100644
--- a/tests/qtest/sse-timer-test.c
+++ b/tests/qtest/sse-timer-test.c
@@ -189,6 +189,37 @@ static void test_timer(void)
 g_assert_cmpuint(readl(TIMER_BASE + CNTP_AIVAL_HI), ==, 0x42);
 }
 
+static void test_timer_scale_change(void)
+{
+/*
+ * Test that the timer responds correctly to counter
+ * scaling changes while it has an active timer.
+ */
+reset_counter_and_timer();
+/* Give ourselves access to the timer, and enable the counter and timer */
+writel(PERIPHNSPPC0, 1);
+writel(COUNTER_BASE + CNTCR, 1);
+writel(TIMER_BASE + CNTP_CTL, 1);
+/* Set the CompareValue to 4000 ticks */
+writel(TIMER_BASE + CNTP_CVAL_LO, 4000);
+writel(TIMER_BASE + CNTP_CVAL_HI, 0);
+/* Advance halfway and check ISTATUS is not set */
+clock_step_ticks(2000);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+/* Reprogram the counter to run at 1/16th speed */
+writel(COUNTER_BASE + CNTCR, 0);
+writel(COUNTER_BASE + CNTSCR, 0x0010); /* 1/16th normal speed */
+writel(COUNTER_BASE + CNTCR, 5); /* EN, SCEN */
+/* Advance to where the timer would have fired and check it has not */
+clock_step_ticks(2000);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+/* Advance to where the timer must fire at the new clock rate */
+clock_step_ticks(29996);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 1);
+clock_step_ticks(4);
+g_assert_cmpuint(readl(TIMER_BASE + CNTP_CTL), ==, 5);
+}
+
 int main(int argc, char **argv)
 {
 int r;
@@ -199,6 +230,7 @@ int main(int argc, char **argv)
 
 qtest_add_func("/sse-timer/counter", test_counter);
 qtest_add_func("/sse-timer/timer", test_timer);
+qtest_add_func("/sse-timer/timer-scale-change", test_timer_scale_change);
 
 r = g_test_run();
 
-- 
2.20.1

Re: [PATCH v2] MAINTAINERS: Merge the Gitlab-CI section into the generic CI section

[Willian Rampazzo]

On Mon, Mar 8, 2021 at 12:46 PM Thomas Huth  wrote:
>
> The status of the gitlab-CI files is currently somewhat confusing, and
> it is often not quite clear whether a patch should go via my tree or
> via the testing tree of Alex. That situation has grown historically...
> Initially, I was the only one using the gitlab-CI, just for my private
> repository there. But in the course of time, the gitlab-CI switched to
> use the containers from tests/docker/ (which is not part of the gitlab-CI
> section in the MAINTAINERS file), and QEMU now even switched to gitlab.com
> completely for the repository and will soon use it as its gating CI, too,
> so it makes way more sense if the gitlab-ci.yml files belong to the people
> who are owning the qemu-project on gitlab.com and take care of the gitlab
> CI there. Thus let's merge the gitlab-ci section into the common "test and
> build automation" section.

Makes sense to me.

Acked-by: Willian Rampazzo 

>
> While we're at it, I'm also removing the line with Fam there for now,
> since he was hardly active during the last years in this area anymore.
> If he ever gets more time for this part again in the future, we surely
> can add the line back again.
>
> Now to avoid that Alex is listed here alone, Philippe and I agreed to
> help as backup maintainers here, too.
>
> Signed-off-by: Thomas Huth 
> ---
>  v2: Keep Philippe and myself as maintainer instead of reviewer
>
>  MAINTAINERS | 21 +++--
>  1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26c9454823..5c4c179abb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3262,17 +3262,21 @@ F: include/hw/remote/iohub.h
>
>  Build and test automation
>  -
> -Build and test automation
> +Build and test automation, Linux Continuous Integration
>  M: Alex Bennée 
> -M: Fam Zheng 
> -R: Philippe Mathieu-Daudé 
> +M: Philippe Mathieu-Daudé 
> +M: Thomas Huth 
> +R: Wainer dos Santos Moschetta 

Feel free to add me as a Reviewer: Willian Rampazzo 

>  S: Maintained
>  F: .github/lockdown.yml
> +F: .gitlab-ci.yml
> +F: .gitlab-ci.d/
>  F: .travis.yml
>  F: scripts/ci/
>  F: tests/docker/
>  F: tests/vm/
>  F: scripts/archive-source.sh
> +W: https://gitlab.com/qemu-project/qemu/pipelines
>  W: https://travis-ci.org/qemu/qemu
>  W: http://patchew.org/QEMU/
>
> @@ -3289,17 +3293,6 @@ S: Maintained
>  F: .cirrus.yml
>  W: https://cirrus-ci.com/github/qemu/qemu
>
> -GitLab Continuous Integration
> -M: Thomas Huth 
> -M: Philippe Mathieu-Daudé 
> -M: Alex Bennée 
> -R: Wainer dos Santos Moschetta 
> -S: Maintained
> -F: .gitlab-ci.yml
> -F: .gitlab-ci.d/crossbuilds.yml
> -F: .gitlab-ci.d/*py
> -F: scripts/ci/gitlab-pipeline-status
> -
>  Guest Test Compilation Support
>  M: Alex Bennée 
>  R: Philippe Mathieu-Daudé 
> --
> 2.27.0
>

[PULL 49/54] hw/arm: xlnx-zynqmp: Clean up coding convention issues

[Peter Maydell]

From: Xuzhou Cheng 

There are some coding convention warnings in xlnx-zynqmp.c and
xlnx-zynqmp.h, as reported by:

  $ ./scripts/checkpatch.pl include/hw/arm/xlnx-zynqmp.h
  $ ./scripts/checkpatch.pl hw/arm/xlnx-zynqmp.c

Let's clean them up.

Signed-off-by: Xuzhou Cheng 
Signed-off-by: Bin Meng 
Reviewed-by: Edgar E. Iglesias 
Message-id: 20210303135254.3970-3-bmeng...@gmail.com
Signed-off-by: Peter Maydell 
---
 include/hw/arm/xlnx-zynqmp.h | 3 ++-
 hw/arm/xlnx-zynqmp.c | 9 ++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
index 0678b419a23..c83ef23e92d 100644
--- a/include/hw/arm/xlnx-zynqmp.h
+++ b/include/hw/arm/xlnx-zynqmp.h
@@ -60,7 +60,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(XlnxZynqMPState, XLNX_ZYNQMP)
 
 #define XLNX_ZYNQMP_GIC_REGIONS 6
 
-/* ZynqMP maps the ARM GIC regions (GICC, GICD ...) at consecutive 64k offsets
+/*
+ * ZynqMP maps the ARM GIC regions (GICC, GICD ...) at consecutive 64k offsets
  * and under-decodes the 64k region. This mirrors the 4k regions to every 4k
  * aligned address in the 64k region. To implement each GIC region needs a
  * number of memory region aliases.
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 46030c1ef81..e2056a764e2 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -301,11 +301,13 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
 
 ram_size = memory_region_size(s->ddr_ram);
 
-/* Create the DDR Memory Regions. User friendly checks should happen at
+/*
+ * Create the DDR Memory Regions. User friendly checks should happen at
  * the board level
  */
 if (ram_size > XLNX_ZYNQMP_MAX_LOW_RAM_SIZE) {
-/* The RAM size is above the maximum available for the low DDR.
+/*
+ * The RAM size is above the maximum available for the low DDR.
  * Create the high DDR memory region as well.
  */
 assert(ram_size <= XLNX_ZYNQMP_MAX_RAM_SIZE);
@@ -521,7 +523,8 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
 SysBusDevice *sbd = SYS_BUS_DEVICE(>sdhci[i]);
 Object *sdhci = OBJECT(>sdhci[i]);
 
-/* Compatible with:
+/*
+ * Compatible with:
  * - SD Host Controller Specification Version 3.00
  * - SDIO Specification Version 3.0
  * - eMMC Specification Version 4.51
-- 
2.20.1