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