1. 17 11月, 2016 10 次提交
  2. 04 11月, 2016 3 次提交
  3. 03 11月, 2016 20 次提交
  4. 28 10月, 2016 2 次提交
  5. 27 10月, 2016 1 次提交
  6. 20 10月, 2016 2 次提交
    • J
      kvm: x86: memset whole irq_eoi · 8678654e
      Jiri Slaby 提交于
      gcc 7 warns:
      arch/x86/kvm/ioapic.c: In function 'kvm_ioapic_reset':
      arch/x86/kvm/ioapic.c:597:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
      
      And it is right. Memset whole array using sizeof operator.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: kvm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      [Added x86 subject tag]
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      8678654e
    • B
      kvm/x86: Fix unused variable warning in kvm_timer_init() · 758f588d
      Borislav Petkov 提交于
      When CONFIG_CPU_FREQ is not set, int cpu is unused and gcc rightfully
      warns about it:
      
        arch/x86/kvm/x86.c: In function ‘kvm_timer_init’:
        arch/x86/kvm/x86.c:5697:6: warning: unused variable ‘cpu’ [-Wunused-variable]
          int cpu;
              ^~~
      
      But since it is used only in the CONFIG_CPU_FREQ block, simply move it
      there, thus squashing the warning too.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      758f588d
  7. 12 10月, 2016 1 次提交
    • P
      kthread: kthread worker API cleanup · 3989144f
      Petr Mladek 提交于
      A good practice is to prefix the names of functions by the name
      of the subsystem.
      
      The kthread worker API is a mix of classic kthreads and workqueues.  Each
      worker has a dedicated kthread.  It runs a generic function that process
      queued works.  It is implemented as part of the kthread subsystem.
      
      This patch renames the existing kthread worker API to use
      the corresponding name from the workqueues API prefixed by
      kthread_:
      
      __init_kthread_worker()		-> __kthread_init_worker()
      init_kthread_worker()		-> kthread_init_worker()
      init_kthread_work()		-> kthread_init_work()
      insert_kthread_work()		-> kthread_insert_work()
      queue_kthread_work()		-> kthread_queue_work()
      flush_kthread_work()		-> kthread_flush_work()
      flush_kthread_worker()		-> kthread_flush_worker()
      
      Note that the names of DEFINE_KTHREAD_WORK*() macros stay
      as they are. It is common that the "DEFINE_" prefix has
      precedence over the subsystem names.
      
      Note that INIT() macros and init() functions use different
      naming scheme. There is no good solution. There are several
      reasons for this solution:
      
        + "init" in the function names stands for the verb "initialize"
          aka "initialize worker". While "INIT" in the macro names
          stands for the noun "INITIALIZER" aka "worker initializer".
      
        + INIT() macros are used only in DEFINE() macros
      
        + init() functions are used close to the other kthread()
          functions. It looks much better if all the functions
          use the same scheme.
      
        + There will be also kthread_destroy_worker() that will
          be used close to kthread_cancel_work(). It is related
          to the init() function. Again it looks better if all
          functions use the same naming scheme.
      
        + there are several precedents for such init() function
          names, e.g. amd_iommu_init_device(), free_area_init_node(),
          jump_label_init_type(),  regmap_init_mmio_clk(),
      
        + It is not an argument but it was inconsistent even before.
      
      [arnd@arndb.de: fix linux-next merge conflict]
       Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.comSuggested-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3989144f
  8. 23 9月, 2016 1 次提交
    • W
      KVM: nVMX: Fix the NMI IDT-vectoring handling · c5a6d5f7
      Wanpeng Li 提交于
      Run kvm-unit-tests/eventinj.flat in L1:
      
      Sending NMI to self
      After NMI to self
      FAIL: NMI
      
      This test scenario is to test whether VMM can handle NMI IDT-vectoring info correctly.
      
      At the beginning, L2 writes LAPIC to send a self NMI, the EPT page tables on both L1
      and L0 are empty so:
      
      - The L2 accesses memory can generate EPT violation which can be intercepted by L0.
      
        The EPT violation vmexit occurred during delivery of this NMI, and the NMI info is
        recorded in vmcs02's IDT-vectoring info.
      
      - L0 walks L1's EPT12 and L0 sees the mapping is invalid, it injects the EPT violation into L1.
      
        The vmcs02's IDT-vectoring info is reflected to vmcs12's IDT-vectoring info since
        it is a nested vmexit.
      
      - L1 receives the EPT violation, then fixes its EPT12.
      - L1 executes VMRESUME to resume L2 which generates vmexit and causes L1 exits to L0.
      - L0 emulates VMRESUME which is called from L1, then return to L2.
      
        L0 merges the requirement of vmcs12's IDT-vectoring info and injects it to L2 through
        vmcs02.
      
      - The L2 re-executes the fault instruction and cause EPT violation again.
      - Since the L1's EPT12 is valid, L0 can fix its EPT02
      - L0 resume L2
      
        The EPT violation vmexit occurred during delivery of this NMI again, and the NMI info
        is recorded in vmcs02's IDT-vectoring info. L0 should inject the NMI through vmentry
        event injection since it is caused by EPT02's EPT violation.
      
      However, vmx_inject_nmi() refuses to inject NMI from IDT-vectoring info if vCPU is in
      guest mode, this patch fix it by permitting to inject NMI from IDT-vectoring if it is
      the L0's responsibility to inject NMI from IDT-vectoring info to L2.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.com>
      Cc: Bandan Das <bsd@redhat.com>
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      c5a6d5f7