qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL v2 00/50] virtio, vhost, pci, pc: features, cleanups
Date: Tue, 20 Mar 2018 17:18:22 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]