Re: [PULL 00/56] virtio,acpi,pci: features, fixes, cleanups, tests

[Peter Maydell]

On Wed, 10 Jun 2020 at 05:26, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> The following changes since commit 49ee11555262a256afec592dfed7c5902d5eefd2:
>/tmp/par8snSu.par

>   Merge remote-tracking branch 
> 'remotes/vivier2/tags/linux-user-for-5.1-pull-request' into staging 
> (2020-06-08 11:04:57 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to 23fe04b63b412276c7c2f67c550961af9d0b4e1e:
>
>   Fix parameter type in vhost migration log path (2020-06-09 14:18:04 -0400)
>
> ----------------------------------------------------------------
> virtio,acpi,pci: features, fixes, cleanups, tests
>
> Max slots negotiation for vhost-user.
> Free page reporting for balloon.
> Partial TPM2 ACPI support for ARM.
> Support for NVDIMMs having their own proximity domains.
> New vhost-user-vsock device.
>
> Fixes, cleanups in ACPI, PCI, virtio.
> New tests for TPM ACPI.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Hi; I'm afraid this has format string issues:

/Users/pm215/src/qemu-for-merges/hw/virtio/vhost-user.c:759:51: error:
format specifies type 'unsigned long' but the argument has type
'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
                                 "%lX", __func__, reply_gpa,
                                                  ^~~~~~~~~
/Users/pm215/src/qemu-for-merges/hw/virtio/vhost-user.c:760:34: error:
format specifies type 'unsigned long' but the argument has type
'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
                                 dev->mem->regions[reg_idx].guest_phys_addr);
                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/pm215/src/qemu-for-merges/hw/virtio/vhost-user.c:1876:67:
error: format specifies type 'unsigned long' but the argument has type
'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
                             "This limit should never decrease.", ram_slots,
                                                                  ^~~~~~~~~

(repros on OSX, OpenBSD, and 32-bit hosts)

thanks
-- PMM