Re: [Qemu-devel] [PULL v2 00/50] virtio, vhost, pci, pc: features, cleanups

[Michael S. Tsirkin]

On Tue, Mar 20, 2018 at 05:18:22PM +0000, Peter Maydell wrote:
> On 20 March 2018 at 16:02, Michael S. Tsirkin <address@hidden> 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