Re: [PULL 0/2] VFIO fixes 2022-02-03

[Thomas Huth <thuth@redhat.com>]

On 07/02/2022 16.50, Alex Williamson wrote:
> On Sat, 5 Feb 2022 10:49:35 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> On Thu, 3 Feb 2022 at 22:38, Alex Williamson <alex.williamson@redhat.com> wrote:
>>>
>>> The following changes since commit 8f3e5ce773c62bb5c4a847f3a9a5c98bbb3b359f:
>>>
>>>    Merge remote-tracking branch 'remotes/hdeller/tags/hppa-updates-pull-request' into staging (2022-02-02 19:54:30 +0000)
>>>
>>> are available in the Git repository at:
>>>
>>>    git://github.com/awilliam/qemu-vfio.git tags/vfio-fixes-20220203.0
>>>
>>> for you to fetch changes up to 36fe5d5836c8d5d928ef6d34e999d6991a2f732e:
>>>
>>>    hw/vfio/common: Silence ram device offset alignment error traces (2022-02-03 15:05:05 -0700)
>>>
>>> ----------------------------------------------------------------
>>> VFIO fixes 2022-02-03
>>>
>>>   * Fix alignment warnings when using TPM CRB with vfio-pci devices
>>>     (Eric Auger & Philippe Mathieu-Daudé)
>>
>> Hi; this has a format-string issue that means it doesn't build
>> on 32-bit systems:
>>
>> https://gitlab.com/qemu-project/qemu/-/jobs/2057116569
>>
>> ../hw/vfio/common.c: In function 'vfio_listener_region_add':
>> ../hw/vfio/common.c:893:26: error: format '%llx' expects argument of
>> type 'long long unsigned int', but argument 6 has type 'intptr_t' {aka
>> 'int'} [-Werror=format=]
>> error_report("%s received unaligned region %s iova=0x%"PRIx64
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ../hw/vfio/common.c:899:26:
>> qemu_real_host_page_mask);
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> For intptr_t you want PRIxPTR.
> 
> Darn.  Well, let me use this opportunity to ask, how are folks doing
> 32-bit cross builds on Fedora?  I used to keep an i686 PAE VM for this
> purpose, but I was eventually no longer able to maintain the build
> dependencies.  Looks like this failed on a mipsel cross build, but I
> don't see such a cross compiler in Fedora.  I do mingw32/64 cross
> builds, but they leave a lot to be desired for code coverage.  Thanks,

The easiest way for getting more test coverage is likely to move your qemu 
repository from github to gitlab - then you get most of the CI for free, 
which should catch such issues before sending pull requests.

  Thomas