On Tue, Mar 20, 2018 at 05:18:22PM +0000, Peter Maydell wrote:
> On 20 March 2018 at 16:02, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Mar 20, 2018 at 03:54:47PM +0000, Peter Maydell wrote:
> >> > Let's update headers for arm and mips then?
> >>
> >> Shouldn't that happen automatically?
>
> > And apparently it does for arm:
> > linux-headers/asm-arm/unistd-common.h has __NR_userfaultfd.
> >
> > What's the story for arm64 and mips?
>
> arm64 uses the generic syscall numbering (as should pretty
> much any new architecture port for Linux). That means its
> unistd.h just #includes the asm-generic one. QEMU's script
> update-linux-headers.sh isn't syncing asm-generic/unistd.h,
> though. That means that the #include in linux-headers/asm-arm64/unistd.h
> picks up whatever the host system's asm-generic/unistd.h
> is. In this instance the build system had a version of that
> header that predated __NR_userfaultfd.
>
> For mips, update-linux-headers.sh has it on a blacklist:
> # Blacklist architectures which have KVM headers but are actually dead
> if [ "$arch" = "ia64" -o "$arch" = "mips" ]; then
> continue
> fi
>
> and has done since 1842bdfdbac2ec46 when we started syncing
> unistd.h. That means that any updates to linux-headers/mips
> would need to be done manually, but in fact we have not done
> any of those, so we still have 2015's headers, which predate
> __NR_userfaultfd.
>
> So we should:
> (1) make update-headers.sh sync asm-generic/unistd.h
> -- looks like this will also require us to sync
> bitsperlong.h for all archs and the asm-generic copy
>
> (2) reinvestigate whatever the "extra header inclusion"
> issues are with mips so we can have the update script
> properly sync the mips headers too
>
> Incidentally we can drop the "blacklist ia64" code, because
> kernels these days don't have KVM headers for ia64 and
> so the generic "skip archs with no KVM support" code will
> make us skip ia64.
> PS: migration/postcopy-ram.c isn't KVM-specific, so it's
> a little odd of it to be relying on header files that we
> only copy for KVM-supporting host architectures. That
> means you need to cope with __NR_userfaultfd not being
> defined anyway, in case you're on a host which doesn't
> support KVM and we've ended up falling back to the system
> includes.
>
> thanks
> -- PMM
I sent some patches to try to clean all that up. I kept ia64
blacklisted from kvm for now as the patchset is already large,
but I limited the effect to kvm only. Would be
easy to drop that test as a patch on top.
--
MST