Message ID | 20210616125129.26563-1-olaf@aepfle.de (mailing list archive) |
---|---|
Headers | show |
Series | leftover from 2020 | expand |
On 16/06/2021 13:50, Olaf Hering wrote:
> Various unreviewed changes, rebase to 4bcf6433ee.
General CI run:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/322032419
Some specific failures.
https://gitlab.com/xen-project/patchew/xen/-/jobs/1351977567 (32bit
toolstack build):
common.c: In function '_sr_bitmap_expand':
common.c:187:9: error: right shift count >= width of type [-Werror]
new_max |= new_max >> 32;
^
https://gitlab.com/xen-project/patchew/xen/-/jobs/1351977708 (arm64)
nomigrate.c:25:20: error: unknown type name 'xc_stream_type_t'
25 | xc_stream_type_t stream_type, int recv_fd)
| ^~~~~~~~~~~~~~~~
I haven't looked through all the failures in the general run, but be
aware that there might still be some clang fallout in dom0_build.c in
Xen, and PV32 fallout for the smoke tests, which won't be from your series.
~Andrew
Am Wed, 16 Jun 2021 15:50:24 +0100
schrieb Andrew Cooper <andrew.cooper3@citrix.com>:
> new_max |= new_max >> 32;
Lazy compiler? I hoped this is a compile-time constant, which evaluates to zero in 32bit builds.
if ( sizeof(unsigned long) > 4 )
I guess a #ifdef as it is done in old code must be done.
Olaf
Am Wed, 16 Jun 2021 15:50:24 +0100
schrieb Andrew Cooper <andrew.cooper3@citrix.com>:
> 32bit toolstack build
as in i386?
How is this used in practice?
I guess such build should be marked as CONFIG_MIGRATE=n in config/x86_32.mk?
Olaf
Hi Olaf, On 16/06/2021 17:02, Olaf Hering wrote: > Am Wed, 16 Jun 2021 15:50:24 +0100 > schrieb Andrew Cooper <andrew.cooper3@citrix.com>: > >> new_max |= new_max >> 32; > > Lazy compiler? I hoped this is a compile-time constant, which evaluates to zero in 32bit builds. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210, this seems to be a known issue on GCC. > > if ( sizeof(unsigned long) > 4 ) > > I guess a #ifdef as it is done in old code must be done. > > Olaf > Cheers,
On 16/06/2021 16:38, Olaf Hering wrote: > Am Wed, 16 Jun 2021 15:50:24 +0100 > schrieb Andrew Cooper <andrew.cooper3@citrix.com>: > >> 32bit toolstack build > as in i386? > How is this used in practice? Every OSSTest run. Also, arm32 is absolutely a thing (the only reason ARM can't migrate right now is because there is no logdirty support in Xen yet). > I guess such build should be marked as CONFIG_MIGRATE=n in config/x86_32.mk? Migration (v2) very definitely works for i386 toolstacks. Part of the testing process during development was migrating a VM between a 32bit and 64bit dom0's, specifically to check that we'd got rid of all of the bitness problems in the stream format. ~Andrew
Am Thu, 17 Jun 2021 12:24:22 +0100 schrieb Andrew Cooper <andrew.cooper3@citrix.com>: > On 16/06/2021 16:38, Olaf Hering wrote: > > Am Wed, 16 Jun 2021 15:50:24 +0100 > > schrieb Andrew Cooper <andrew.cooper3@citrix.com>: > > > >> 32bit toolstack build > > as in i386? > > How is this used in practice? > Every OSSTest run. This is not what I mean. I think there is a 32bit xen-tools, a 32bit dom0 kernel and a 64bit Xen? Is 32bit xen-tools, 64bit dom0 kernel and 64bit Xen expected to work? Olaf
On 17/06/2021 15:55, Olaf Hering wrote: > Am Thu, 17 Jun 2021 12:24:22 +0100 > schrieb Andrew Cooper <andrew.cooper3@citrix.com>: > >> On 16/06/2021 16:38, Olaf Hering wrote: >>> Am Wed, 16 Jun 2021 15:50:24 +0100 >>> schrieb Andrew Cooper <andrew.cooper3@citrix.com>: >>> >>>> 32bit toolstack build >>> as in i386? >>> How is this used in practice? >> Every OSSTest run. > This is not what I mean. > I think there is a 32bit xen-tools, a 32bit dom0 kernel and a 64bit Xen? Yes - this exists. > Is 32bit xen-tools, 64bit dom0 kernel and 64bit Xen expected to work? In an ideal world, yes. In reality, no. Lots of hypercalls have embedded pointers (every GUEST_HANDLE(), to a first approximation), and dom0's ABI with Xen is 64bit, which is not the ABI that 32bit userspace speaks. This is one of many errors in the hypercall design intending to be addressed by the ABIv2 plans. ~Andrew
Am Thu, 17 Jun 2021 13:02:39 +0200
schrieb Julien Grall <julien@xen.org>:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
Thanks, comments in this bug suggest a workaround like this:
new_max |= sizeof(unsigned long) > 4 ? new_max >> 32 : 0;
This triggers no warning.
Olaf