1. 05 9月, 2017 14 次提交
  2. 28 8月, 2017 1 次提交
  3. 27 8月, 2017 1 次提交
  4. 20 8月, 2017 1 次提交
  5. 09 8月, 2017 1 次提交
  6. 08 8月, 2017 1 次提交
  7. 18 7月, 2017 3 次提交
  8. 17 7月, 2017 1 次提交
  9. 14 7月, 2017 1 次提交
    • R
      kvm: x86: hyperv: make VP_INDEX managed by userspace · d3457c87
      Roman Kagan 提交于
      Hyper-V identifies vCPUs by Virtual Processor Index, which can be
      queried via HV_X64_MSR_VP_INDEX msr.  It is defined by the spec as a
      sequential number which can't exceed the maximum number of vCPUs per VM.
      APIC ids can be sparse and thus aren't a valid replacement for VP
      indices.
      
      Current KVM uses its internal vcpu index as VP_INDEX.  However, to make
      it predictable and persistent across VM migrations, the userspace has to
      control the value of VP_INDEX.
      
      This patch achieves that, by storing vp_index explicitly on vcpu, and
      allowing HV_X64_MSR_VP_INDEX to be set from the host side.  For
      compatibility it's initialized to KVM vcpu index.  Also a few variables
      are renamed to make clear distinction betweed this Hyper-V vp_index and
      KVM vcpu_id (== APIC id).  Besides, a new capability,
      KVM_CAP_HYPERV_VP_INDEX, is added to allow the userspace to skip
      attempting msr writes where unsupported, to avoid spamming error logs.
      Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      d3457c87
  10. 13 7月, 2017 4 次提交
    • R
      kvm: x86: hyperv: add KVM_CAP_HYPERV_SYNIC2 · efc479e6
      Roman Kagan 提交于
      There is a flaw in the Hyper-V SynIC implementation in KVM: when message
      page or event flags page is enabled by setting the corresponding msr,
      KVM zeroes it out.  This is problematic because on migration the
      corresponding MSRs are loaded on the destination, so the content of
      those pages is lost.
      
      This went unnoticed so far because the only user of those pages was
      in-KVM hyperv synic timers, which could continue working despite that
      zeroing.
      
      Newer QEMU uses those pages for Hyper-V VMBus implementation, and
      zeroing them breaks the migration.
      
      Besides, in newer QEMU the content of those pages is fully managed by
      QEMU, so zeroing them is undesirable even when writing the MSRs from the
      guest side.
      
      To support this new scheme, introduce a new capability,
      KVM_CAP_HYPERV_SYNIC2, which, when enabled, makes sure that the synic
      pages aren't zeroed out in KVM.
      Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      efc479e6
    • M
      include/linux/sem.h: correctly document sem_ctime · 2cd648c1
      Manfred Spraul 提交于
      sem_ctime is initialized to the semget() time and then updated at every
      semctl() that changes the array.
      
      Thus it does not represent the time of the last change.
      
      Especially, semop() calls are only stored in sem_otime, not in
      sem_ctime.
      
      This is already described in ipc/sem.c, I just overlooked that there is
      a comment in include/linux/sem.h and man semctl(2) as well.
      
      So: Correct wrong comments.
      
      Link: http://lkml.kernel.org/r/20170515171912.6298-4-manfred@colorfullife.comSigned-off-by: NManfred Spraul <manfred@colorfullife.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: <1vier1@web.de>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Fabian Frederick <fabf@skynet.be>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2cd648c1
    • C
      kcmp: add KCMP_EPOLL_TFD mode to compare epoll target files · 0791e364
      Cyrill Gorcunov 提交于
      With current epoll architecture target files are addressed with
      file_struct and file descriptor number, where the last is not unique.
      Moreover files can be transferred from another process via unix socket,
      added into queue and closed then so we won't find this descriptor in the
      task fdinfo list.
      
      Thus to checkpoint and restore such processes CRIU needs to find out
      where exactly the target file is present to add it into epoll queue.
      For this sake one can use kcmp call where some particular target file
      from the queue is compared with arbitrary file passed as an argument.
      
      Because epoll target files can have same file descriptor number but
      different file_struct a caller should explicitly specify the offset
      within.
      
      To test if some particular file is matching entry inside epoll one have
      to
      
       - fill kcmp_epoll_slot structure with epoll file descriptor,
         target file number and target file offset (in case if only
         one target is present then it should be 0)
      
       - call kcmp as kcmp(pid1, pid2, KCMP_EPOLL_TFD, fd, &kcmp_epoll_slot)
          - the kernel fetch file pointer matching file descriptor @fd of pid1
          - lookups for file struct in epoll queue of pid2 and returns traditional
            0,1,2 result for sorting purpose
      
      Link: http://lkml.kernel.org/r/20170424154423.511592110@gmail.comSigned-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: NAndrey Vagin <avagin@openvz.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Pavel Emelyanov <xemul@virtuozzo.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Jason Baron <jbaron@akamai.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0791e364
    • G
      KVM: s390: Fix KVM_S390_GET_CMMA_BITS ioctl definition · 949c0336
      Gleb Fotengauer-Malinovskiy 提交于
      In case of KVM_S390_GET_CMMA_BITS, the kernel does not only read struct
      kvm_s390_cmma_log passed from userspace (which constitutes _IOC_WRITE),
      it also writes back a return value (which constitutes _IOC_READ) making
      this an _IOWR ioctl instead of _IOW.
      
      Fixes: 4036e387 ("KVM: s390: ioctls to get and set guest storage attributes")
      Signed-off-by: NGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      949c0336
  11. 11 7月, 2017 1 次提交
    • L
      Fix up over-eager 'wait_queue_t' renaming · 7cee9384
      Linus Torvalds 提交于
      Commit ac6424b9 ("sched/wait: Rename wait_queue_t =>
      wait_queue_entry_t") had scripted the renaming incorrectly, and didn't
      actually check that the 'wait_queue_t' was a full token.
      
      As a result, it also triggered on 'wait_queue_token', and renamed that
      to 'wait_queue_entry_token' entry in the autofs4 packet structure
      definition too.  That was entirely incorrect, and not intended.
      
      The end result built fine when building just the kernel - because
      everything had been renamed consistently there - but caused problems in
      user space because the "struct autofs_packet_missing" type is exported
      as part of the uapi.
      
      This scripts it all back again:
      
          git grep -lw wait_queue_entry_token |
              xargs sed -i 's/wait_queue_entry_token/wait_queue_token/g'
      
      and checks the end result.
      Reported-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Fixes: ac6424b9 ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7cee9384
  12. 08 7月, 2017 1 次提交
  13. 07 7月, 2017 6 次提交
  14. 03 7月, 2017 4 次提交