1. 19 5月, 2018 3 次提交
  2. 18 5月, 2018 1 次提交
  3. 16 5月, 2018 2 次提交
  4. 14 5月, 2018 7 次提交
  5. 13 5月, 2018 5 次提交
  6. 12 5月, 2018 2 次提交
  7. 09 5月, 2018 2 次提交
  8. 08 5月, 2018 3 次提交
    • U
      arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan · 9a62dcf4
      Uwe Kleine-König 提交于
      Commit d50f4630 ("arm: dts: Remove p1010-flexcan compatible from imx
      series dts") removed the fallback compatible "fsl,p1010-flexcan" from
      the imx device trees. As the flexcan cores on i.MX25, i.MX35 and i.MX53
      are identical, introduce the first as fallback for the two latter ones.
      
      Fixes: d50f4630 ("arm: dts: Remove p1010-flexcan compatible from imx series dts")
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      9a62dcf4
    • M
      powerpc/pseries: Fix CONFIG_NUMA=n build · 6c0a8f6b
      Michael Ellerman 提交于
      The build is failing with CONFIG_NUMA=n and some compiler versions:
      
        arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu':
        hotplug-cpu.c:(.text+0x12c): undefined reference to `timed_topology_update'
        arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_cpu_remove':
        hotplug-cpu.c:(.text+0x400): undefined reference to `timed_topology_update'
      
      Fix it by moving the empty version of timed_topology_update() into the
      existing #ifdef block, which has the right guard of SPLPAR && NUMA.
      
      Fixes: cee5405d ("powerpc/hotplug: Improve responsiveness of hotplug change")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6c0a8f6b
    • V
      x86/xen: Reset VCPU0 info pointer after shared_info remap · d1ecfa9d
      van der Linden, Frank 提交于
      This patch fixes crashes during boot for HVM guests on older (pre HVM
      vector callback) Xen versions. Without this, current kernels will always
      fail to boot on those Xen versions.
      
      Sample stack trace:
      
         BUG: unable to handle kernel paging request at ffffffffff200000
         IP: __xen_evtchn_do_upcall+0x1e/0x80
         PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0
          Oops: 0002 [#1] SMP PTI
         Modules linked in:
         CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1
         Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016
         task: ffff88002531d700 task.stack: ffffc90000480000
         RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80
         RSP: 0000:ffff880025403ef0 EFLAGS: 00010046
         RAX: ffffffff813cc760 RBX: ffffffffff200000 RCX: ffffc90000483ef0
         RDX: ffff880020540a00 RSI: ffff880023c78000 RDI: 000000000000001c
         RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
         R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
         R13: ffff880025403f5c R14: 0000000000000000 R15: 0000000000000000
         FS:  0000000000000000(0000) GS:ffff880025400000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: ffffffffff200000 CR3: 0000000001e0a000 CR4: 00000000000006f0
          Call Trace:
         <IRQ>
         do_hvm_evtchn_intr+0xa/0x10
         __handle_irq_event_percpu+0x43/0x1a0
         handle_irq_event_percpu+0x20/0x50
         handle_irq_event+0x39/0x60
         handle_fasteoi_irq+0x80/0x140
         handle_irq+0xaf/0x120
         do_IRQ+0x41/0xd0
         common_interrupt+0x7d/0x7d
         </IRQ>
      
      During boot, the HYPERVISOR_shared_info page gets remapped to make it work
      with KASLR. This means that any pointer derived from it needs to be
      adjusted.
      
      The only value that this applies to is the vcpu_info pointer for VCPU 0.
      For PV and HVM with the callback vector feature, this gets done via the
      smp_ops prepare_boot_cpu callback. Older Xen versions do not support the
      HVM callback vector, so there is no Xen-specific smp_ops set up in that
      scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper
      value, and the first reference of it will be bad. Fix this by resetting it
      immediately after the remap.
      Signed-off-by: NFrank van der Linden <fllinden@amazon.com>
      Reviewed-by: NEduardo Valentin <eduval@amazon.com>
      Reviewed-by: NAlakesh Haloi <alakeshh@amazon.com>
      Reviewed-by: NVallish Vaidyeshwara <vallish@amazon.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      d1ecfa9d
  9. 07 5月, 2018 3 次提交
  10. 06 5月, 2018 9 次提交
  11. 04 5月, 2018 2 次提交
    • J
      arm64: vgic-v2: Fix proxying of cpuif access · b220244d
      James Morse 提交于
      Proxying the cpuif accesses at EL2 makes use of vcpu_data_guest_to_host
      and co, which check the endianness, which call into vcpu_read_sys_reg...
      which isn't mapped at EL2 (it was inlined before, and got moved OoL
      with the VHE optimizations).
      
      The result is of course a nice panic. Let's add some specialized
      cruft to keep the broken platforms that require this hack alive.
      
      But, this code used vcpu_data_guest_to_host(), which expected us to
      write the value to host memory, instead we have trapped the guest's
      read or write to an mmio-device, and are about to replay it using the
      host's readl()/writel() which also perform swabbing based on the host
      endianness. This goes wrong when both host and guest are big-endian,
      as readl()/writel() will undo the guest's swabbing, causing the
      big-endian value to be written to device-memory.
      
      What needs doing?
      A big-endian guest will have pre-swabbed data before storing, undo this.
      If its necessary for the host, writel() will re-swab it.
      
      For a read a big-endian guest expects to swab the data after the load.
      The hosts's readl() will correct for host endianness, giving us the
      device-memory's value in the register. For a big-endian guest, swab it
      as if we'd only done the load.
      
      For a little-endian guest, nothing needs doing as readl()/writel() leave
      the correct device-memory value in registers.
      
      Tested on Juno with that rarest of things: a big-endian 64K host.
      Based on a patch from Marc Zyngier.
      Reported-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Fixes: bf8feb39 ("arm64: KVM: vgic-v2: Add GICV access from HYP")
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      b220244d
    • J
      KVM: arm64: Fix order of vcpu_write_sys_reg() arguments · 1975fa56
      James Morse 提交于
      A typo in kvm_vcpu_set_be()'s call:
      | vcpu_write_sys_reg(vcpu, SCTLR_EL1, sctlr)
      causes us to use the 32bit register value as an index into the sys_reg[]
      array, and sail off the end of the linear map when we try to bring up
      big-endian secondaries.
      
      | Unable to handle kernel paging request at virtual address ffff80098b982c00
      | Mem abort info:
      |  ESR = 0x96000045
      |  Exception class = DABT (current EL), IL = 32 bits
      |   SET = 0, FnV = 0
      |   EA = 0, S1PTW = 0
      | Data abort info:
      |   ISV = 0, ISS = 0x00000045
      |   CM = 0, WnR = 1
      | swapper pgtable: 4k pages, 48-bit VAs, pgdp = 000000002ea0571a
      | [ffff80098b982c00] pgd=00000009ffff8803, pud=0000000000000000
      | Internal error: Oops: 96000045 [#1] PREEMPT SMP
      | Modules linked in:
      | CPU: 2 PID: 1561 Comm: kvm-vcpu-0 Not tainted 4.17.0-rc3-00001-ga912e2261ca6-dirty #1323
      | Hardware name: ARM Juno development board (r1) (DT)
      | pstate: 60000005 (nZCv daif -PAN -UAO)
      | pc : vcpu_write_sys_reg+0x50/0x134
      | lr : vcpu_write_sys_reg+0x50/0x134
      
      | Process kvm-vcpu-0 (pid: 1561, stack limit = 0x000000006df4728b)
      | Call trace:
      |  vcpu_write_sys_reg+0x50/0x134
      |  kvm_psci_vcpu_on+0x14c/0x150
      |  kvm_psci_0_2_call+0x244/0x2a4
      |  kvm_hvc_call_handler+0x1cc/0x258
      |  handle_hvc+0x20/0x3c
      |  handle_exit+0x130/0x1ec
      |  kvm_arch_vcpu_ioctl_run+0x340/0x614
      |  kvm_vcpu_ioctl+0x4d0/0x840
      |  do_vfs_ioctl+0xc8/0x8d0
      |  ksys_ioctl+0x78/0xa8
      |  sys_ioctl+0xc/0x18
      |  el0_svc_naked+0x30/0x34
      | Code: 73620291 604d00b0 00201891 1ab10194 (957a33f8)
      |---[ end trace 4b4a4f9628596602 ]---
      
      Fix the order of the arguments.
      
      Fixes: 8d404c4c ("KVM: arm64: Rewrite system register accessors to read/write functions")
      CC: Christoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      1975fa56
  12. 03 5月, 2018 1 次提交
    • H
      parisc: Fix section mismatches · 8d73b180
      Helge Deller 提交于
      Fix three section mismatches:
      1) Section mismatch in reference from the function ioread8() to the
         function .init.text:pcibios_init_bridge()
      2) Section mismatch in reference from the function free_initmem() to the
         function .init.text:map_pages()
      3) Section mismatch in reference from the function ccio_ioc_init() to
         the function .init.text:count_parisc_driver()
      Signed-off-by: NHelge Deller <deller@gmx.de>
      8d73b180
新手
引导
客服 返回
顶部