Skip to content
Snippets Groups Projects
Select Git revision
17 results
Search by author
  • Any Author
  • Angus Ainslie Angus Ainslie angus.ainslie
  • Eric Kuzmenko Eric Kuzmenko eric.kuzmenko
  • Evangelos Ribeiro Tzaras Evangelos Ribeiro Tzaras evangelos.tzaras
  • Francois Techene Francois Techene francois.techene
  • Guido Gunther Guido Gunther guido.gunther
  • JC Staudt JC Staudt jcstaudt
  • Jonathon Hall Jonathon Hall jonathon.hall
  • Julian Sparber Julian Sparber julian.sparber
  • Martin Kepplinger Martin Kepplinger martin.kepplinger
  • Mohammed Sadiq Mohammed Sadiq mohammed.sadiq
  • Richard Kolla Richard Kolla richard.kolla
  • Sam Hewitt Sam Hewitt sam.hewitt
  • Sebastian Krzyszkowiak Sebastian Krzyszkowiak sebastian.krzyszkowiak
13 authors
  1. Apr 26, 2016
  3. Apr 19, 2016
  5. Apr 15, 2016
  7. Apr 14, 2016
  9. Apr 13, 2016
  11. Apr 12, 2016
  13. Apr 11, 2016
    • Greg Ungerer's avatar
      m68k/gpio: remove arch specific sysfs bus device · 2763ee64
      Greg Ungerer authored 
      
The ColdFire architecture specific gpio support code registers a sysfs
bus device named "gpio". This clashes with the new generic API device
added in commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs").

The old ColdFire sysfs gpio device was never used for anything specific,
and no links or other nodes were created under it. The new API sysfs gpio
device has all the same default sysfs links (device, drivers, etc) and
they are properly populated.

Remove the old ColdFire sysfs gpio registration.

Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2763ee64
  15. Apr 10, 2016
    • Paolo Bonzini's avatar
      KVM: x86: mask CPUID(0xD,0x1).EAX against host value · 316314ca
      Paolo Bonzini authored 
      
This ensures that the guest doesn't see XSAVE extensions
(e.g. xgetbv1 or xsavec) that the host lacks.

Cc: stable@vger.kernel.org
Reviewed-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      316314ca
    • David Matlack's avatar
      kvm: x86: do not leak guest xcr0 into host interrupt handlers · fc5b7f3b
      David Matlack authored 
      
An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
 - the guest's xcr0 register is loaded on the cpu
 - the guest's fpu context is not loaded
 - the host is using eagerfpu

Note that the guest's xcr0 register and fpu context are not loaded as
part of the atomic world switch into "guest mode". They are loaded by
KVM while the cpu is still in "host mode".

Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
interrupt handler will look something like this:

if (irq_fpu_usable()) {
        kernel_fpu_begin();

        [... code that uses the fpu ...]

        kernel_fpu_end();
}

As long as the guest's fpu is not loaded and the host is using eager
fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
returns true). The interrupt handler proceeds to use the fpu with
the guest's xcr0 live.

kernel_fpu_begin() saves the current fpu context. If this uses
XSAVE[OPT], it may leave the xsave area in an undesirable state.
According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
xcr0[i] == 0 following an XSAVE.

kernel_fpu_end() restores the fpu context. Now if any bit i in
XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
fault is trapped and SIGSEGV is delivered to the current process.

Only pre-4.2 kernels appear to be vulnerable to this sequence of
events. Commit 653f52c3 ("kvm,x86: load guest FPU context more eagerly")
from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.

This patch fixes the bug by keeping the host's xcr0 loaded outside
of the interrupts-disabled region where KVM switches into guest mode.

Cc: stable@vger.kernel.org
Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
[Move load after goto cancel_injection. - Paolo]
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fc5b7f3b
    • Xiao Guangrong's avatar
      KVM: MMU: fix permission_fault() · 7a98205d
      Xiao Guangrong authored 
      
kvm-unit-tests complained about the PFEC is not set properly, e.g,:
test pte.rw pte.d pte.nx pde.p pde.rw pde.pse user fetch: FAIL: error code 15
expected 5
Dump mapping: address: 0x123400000000
------L4: 3e95007
------L3: 3e96007
------L2: 2000083

It's caused by the reason that PFEC returned to guest is copied from the
PFEC triggered by shadow page table

This patch fixes it and makes the logic of updating errcode more clean

Signed-off-by: default avatarXiao Guangrong <guangrong.xiao@linux.intel.com>
[Do not assume pfec.p=1. - Paolo]
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7a98205d
  17. Apr 08, 2016
  19. Apr 07, 2016
  21. Apr 06, 2016
    • Linus Torvalds's avatar
      x86: remove the kernel code/data/bss resources from /proc/iomem · c4004b02
      Linus Torvalds authored 
      
Let's see if anybody even notices.  I doubt anybody uses this, and it
does expose addresses that should be randomized, so let's just remove
the code.  It's old and traditional, and it used to be cute, but we
should have removed this long ago.

If it turns out anybody notices and this breaks something, we'll have to
revert this, and maybe we'll end up using other approaches instead
(using %pK or similar).  But removing unnecessary code is always the
preferred option.

Noted-by: default avatarEmrah Demir <ed@abdsec.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c4004b02
    • Sudeep Holla's avatar
      arm64: KVM: unregister notifiers in hyp mode teardown path · 06a71a24
      Sudeep Holla authored 
      
Commit 1e947bad ("arm64: KVM: Skip HYP setup when already running
in HYP") re-organized the hyp init code and ended up leaving the CPU
hotplug and PM notifier even if hyp mode initialization fails.

Since KVM is not yet supported with ACPI, the above mentioned commit
breaks CPU hotplug in ACPI boot.

This patch fixes teardown_hyp_mode to properly unregister both CPU
hotplug and PM notifiers in the teardown path.

Fixes: 1e947bad ("arm64: KVM: Skip HYP setup when already running in HYP")
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      06a71a24
    • Marc Zyngier's avatar
      arm64: KVM: Warn when PARange is less than 40 bits · 6141570c
      Marc Zyngier authored 
      
We always thought that 40bits of PA range would be the minimum people
would actually build. Anything less is terrifyingly small.

Turns out that we were both right and wrong. Nobody has ever built
such a system, but the ARM Foundation Model has a PARange set to 36bits.
Just because we can. Oh well. Now, the KVM API explicitely says that
we offer a 40bit PA space to the VM, so we shouldn't run KVM on
the Foundation Model at all.

That being said, this patch offers a less agressive alternative, and
loudly warns about the configuration being unsupported. You'll still
be able to run VMs (at your own risks, though).

This is just a workaround until we have a proper userspace API where
we report the PARange to userspace.

Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      6141570c
  23. Apr 05, 2016
    • Luiz Capitulino's avatar
      kvm: x86: make lapic hrtimer pinned · 61abdbe0
      Luiz Capitulino authored 
      
When a vCPU runs on a nohz_full core, the hrtimer used by
the lapic emulation code can be migrated to another core.
When this happens, it's possible to observe milisecond
latency when delivering timer IRQs to KVM guests.

The huge latency is mainly due to the fact that
apic_timer_fn() expects to run during a kvm exit. It
sets KVM_REQ_PENDING_TIMER and let it be handled on kvm
entry. However, if the timer fires on a different core,
we have to wait until the next kvm exit for the guest
to see KVM_REQ_PENDING_TIMER set.

This problem became visible after commit 9642d18e. This
commit changed the timer migration code to always attempt
to migrate timers away from nohz_full cores. While it's
discussable if this is correct/desirable (I don't think
it is), it's clear that the lapic emulation code has
a requirement on firing the hrtimer in the same core
where it was started. This is achieved by making the
hrtimer pinned.

Lastly, note that KVM has code to migrate timers when a
vCPU is scheduled to run in different core. However, this
forced migration may fail. When this happens, we can have
the same problem. If we want 100% correctness, we'll have
to modify apic_timer_fn() to cause a kvm exit when it runs
on a different core than the vCPU. Not sure if this is
possible.

Here's a reproducer for the issue being fixed:

 1. Set all cores but core0 to be nohz_full cores
 2. Start a guest with a single vCPU
 3. Trace apic_timer_fn() and kvm_inject_apic_timer_irqs()

You'll see that apic_timer_fn() will run in core0 while
kvm_inject_apic_timer_irqs() runs in a different core. If
you get both on core0, try running a program that takes 100%
of the CPU and pin it to core0 to force the vCPU out.

Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      61abdbe0
    • Christian Borntraeger's avatar
      s390/mm/kvm: fix mis-merge in gmap handling · 9c650d09
      Christian Borntraeger authored 
      
commit 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c") dropped
some changes from commit a3a92c31 ("KVM: s390: fix mismatch
between user and in-kernel guest limit") - this breaks KVM for some
memory sizes (kvm-s390: failed to commit memory region) like
exactly 2GB.

Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9c650d09
  25. Apr 04, 2016
  27. Apr 03, 2016
    • Paul Burton's avatar
      MIPS: Bail on unsupported module relocs · 04211a57
      Paul Burton authored 
      
When an unsupported reloc is encountered in a module, we currently
blindly branch to whatever would be at its entry in the reloc handler
function pointer arrays. This may be NULL, or if the unsupported reloc
has a type greater than that of the supported reloc with the highest
type then we'll dereference some value after the function pointer array
& branch to that. The result is at best a kernel oops.

Fix this by checking that the reloc type has an entry in the function
pointer array (ie. is less than the number of items in the array) and
that the handler is non-NULL, returning an error code to fail the module
load if no handler is found.

Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12432/


Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      04211a57