1. 03 2月, 2014 1 次提交
  2. 31 1月, 2014 2 次提交
    • D
      xen/pvh: Fix misplaced kfree from xlated_setup_gnttab_pages · f93576e1
      Dave Jones 提交于
      Passing a freed 'pages' to free_xenballooned_pages will end badly
      on kernels with slub debug enabled.
      
      This looks out of place between the rc assign and the check, but
      we do want to kfree pages regardless of which path we take.
      Signed-off-by: NDave Jones <davej@fedoraproject.org>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      f93576e1
    • Z
      xen/grant-table: Avoid m2p_override during mapping · 08ece5bb
      Zoltan Kiss 提交于
      The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
      for blkback and future netback patches it just cause a lock contention, as
      those pages never go to userspace. Therefore this series does the following:
      - the original functions were renamed to __gnttab_[un]map_refs, with a new
        parameter m2p_override
      - based on m2p_override either they follow the original behaviour, or just set
        the private flag and call set_phys_to_machine
      - gnttab_[un]map_refs are now a wrapper to call __gnttab_[un]map_refs with
        m2p_override false
      - a new function gnttab_[un]map_refs_userspace provides the old behaviour
      
      It also removes a stray space from page.h and change ret to 0 if
      XENFEAT_auto_translated_physmap, as that is the only possible return value
      there.
      
      v2:
      - move the storing of the old mfn in page->index to gnttab_map_refs
      - move the function header update to a separate patch
      
      v3:
      - a new approach to retain old behaviour where it needed
      - squash the patches into one
      
      v4:
      - move out the common bits from m2p* functions, and pass pfn/mfn as parameter
      - clear page->private before doing anything with the page, so m2p_find_override
        won't race with this
      
      v5:
      - change return value handling in __gnttab_[un]map_refs
      - remove a stray space in page.h
      - add detail why ret = 0 now at some places
      
      v6:
      - don't pass pfn to m2p* functions, just get it locally
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Suggested-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      08ece5bb
  3. 22 1月, 2014 1 次提交
    • R
      xen/pvh: Set X86_CR0_WP and others in CR0 (v2) · c9f6e997
      Roger Pau Monne 提交于
      otherwise we will get for some user-space applications
      that use 'clone' with CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
      end up hitting an assert in glibc manifested by:
      
      general protection ip:7f80720d364c sp:7fff98fd8a80 error:0 in
      libc-2.13.so[7f807209e000+180000]
      
      This is due to the nature of said operations which sets and clears
      the PID.  "In the successful one I can see that the page table of
      the parent process has been updated successfully to use a
      different physical page, so the write of the tid on
      that page only affects the child...
      
      On the other hand, in the failed case, the write seems to happen before
      the copy of the original page is done, so both the parent and the child
      end up with the same value (because the parent copies the page after
      the write of the child tid has already happened)."
      (Roger's analysis). The nature of this is due to the Xen's commit
      of 51e2cac257ec8b4080d89f0855c498cbbd76a5e5
      "x86/pvh: set only minimal cr0 and cr4 flags in order to use paging"
      the CR0_WP was removed so COW features of the Linux kernel were not
      operating properly.
      
      While doing that also update the rest of the CR0 flags to be inline
      with what a baremetal Linux kernel would set them to.
      
      In 'secondary_startup_64' (baremetal Linux) sets:
      
      X86_CR0_PE | X86_CR0_MP | X86_CR0_ET | X86_CR0_NE | X86_CR0_WP |
      X86_CR0_AM | X86_CR0_PG
      
      The hypervisor for HVM type guests (which PVH is a bit) sets:
      X86_CR0_PE | X86_CR0_ET | X86_CR0_TS
      For PVH it specifically sets:
      X86_CR0_PG
      
      Which means we need to set the rest: X86_CR0_MP | X86_CR0_NE  |
      X86_CR0_WP | X86_CR0_AM to have full parity.
      Signed-off-by: NRoger Pau Monne <roger.pau@citrix.com>
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v1: Took out the cr4 writes to be a seperate patch]
      [v2: 0-DAY kernel found xen_setup_gdt to be missing a static]
      c9f6e997
  4. 10 1月, 2014 1 次提交
  5. 07 1月, 2014 2 次提交
  6. 06 1月, 2014 17 次提交
    • M
      xen/pvh: Support ParaVirtualized Hardware extensions (v3). · 4e903a20
      Mukesh Rathor 提交于
      PVH allows PV linux guest to utilize hardware extended capabilities,
      such as running MMU updates in a HVM container.
      
      The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
      with modifications):
      
      "* the guest uses auto translate:
       - p2m is managed by Xen
       - pagetables are owned by the guest
       - mmu_update hypercall not available
      * it uses event callback and not vlapic emulation,
      * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
      
      For a full list of hcalls supported for PVH, see pvh_hypercall64_table
      in arch/x86/hvm/hvm.c in xen.  From the ABI prespective, it's mostly a
      PV guest with auto translate, although it does use hvm_op for setting
      callback vector."
      
      Use .ascii and .asciz to define xen feature string. Note, the PVH
      string must be in a single line (not multiple lines with \) to keep the
      assembler from putting null char after each string before \.
      This patch allows it to be configured and enabled.
      
      We also use introduce the 'XEN_ELFNOTE_SUPPORTED_FEATURES' ELF note to
      tell the hypervisor that 'hvm_callback_vector' is what the kernel
      needs. We can not put it in 'XEN_ELFNOTE_FEATURES' as older hypervisor
      parse fields they don't understand as errors and refuse to load
      the kernel. This work-around fixes the problem.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      4e903a20
    • K
      xen/pvh: Piggyback on PVHVM for grant driver (v4) · 6926f6d6
      Konrad Rzeszutek Wilk 提交于
      In PVH the shared grant frame is the PFN and not MFN,
      hence its mapped via the same code path as HVM.
      
      The allocation of the grant frame is done differently - we
      do not use the early platform-pci driver and have an
      ioremap area - instead we use balloon memory and stitch
      all of the non-contingous pages in a virtualized area.
      
      That means when we call the hypervisor to replace the GMFN
      with a XENMAPSPACE_grant_table type, we need to lookup the
      old PFN for every iteration instead of assuming a flat
      contingous PFN allocation.
      
      Lastly, we only use v1 for grants. This is because PVHVM
      is not able to use v2 due to no XENMEM_add_to_physmap
      calls on the error status page (see commit
      69e8f430
       xen/granttable: Disable grant v2 for HVM domains.)
      
      Until that is implemented this workaround has to
      be in place.
      
      Also per suggestions by Stefano utilize the PVHVM paths
      as they share common functionality.
      
      v2 of this patch moves most of the PVH code out in the
      arch/x86/xen/grant-table driver and touches only minimally
      the generic driver.
      
      v3, v4: fixes us some of the code due to earlier patches.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      6926f6d6
    • K
      xen/grant: Implement an grant frame array struct (v3). · efaf30a3
      Konrad Rzeszutek Wilk 提交于
      The 'xen_hvm_resume_frames' used to be an 'unsigned long'
      and contain the virtual address of the grants. That was OK
      for most architectures (PVHVM, ARM) were the grants are contiguous
      in memory. That however is not the case for PVH - in which case
      we will have to do a lookup for each virtual address for the PFN.
      
      Instead of doing that, lets make it a structure which will contain
      the array of PFNs, the virtual address and the count of said PFNs.
      
      Also provide a generic functions: gnttab_setup_auto_xlat_frames and
      gnttab_free_auto_xlat_frames to populate said structure with
      appropriate values for PVHVM and ARM.
      
      To round it off, change the name from 'xen_hvm_resume_frames' to
      a more descriptive one - 'xen_auto_xlat_grant_frames'.
      
      For PVH, in patch "xen/pvh: Piggyback on PVHVM for grant driver"
      we will populate the 'xen_auto_xlat_grant_frames' by ourselves.
      
      v2 moves the xen_remap in the gnttab_setup_auto_xlat_frames
      and also introduces xen_unmap for gnttab_free_auto_xlat_frames.
      Suggested-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v3: Based on top of 'asm/xen/page.h: remove redundant semicolon']
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      efaf30a3
    • M
      xen/pvh: Piggyback on PVHVM for event channels (v2) · 2771374d
      Mukesh Rathor 提交于
      PVH is a PV guest with a twist - there are certain things
      that work in it like HVM and some like PV. There is
      a similar mode - PVHVM where we run in HVM mode with
      PV code enabled - and this patch explores that.
      
      The most notable PV interfaces are the XenBus and event channels.
      
      We will piggyback on how the event channel mechanism is
      used in PVHVM - that is we want the normal native IRQ mechanism
      and we will install a vector (hvm callback) for which we
      will call the event channel mechanism.
      
      This means that from a pvops perspective, we can use
      native_irq_ops instead of the Xen PV specific. Albeit in the
      future we could support pirq_eoi_map. But that is
      a feature request that can be shared with PVHVM.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      2771374d
    • M
      xen/pvh: Update E820 to work with PVH (v2) · 9103bb0f
      Mukesh Rathor 提交于
      In xen_add_extra_mem() we can skip updating P2M as it's managed
      by Xen. PVH maps the entire IO space, but only RAM pages need
      to be repopulated.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      9103bb0f
    • M
      xen/pvh: Secondary VCPU bringup (non-bootup CPUs) · 5840c84b
      Mukesh Rathor 提交于
      The VCPU bringup protocol follows the PV with certain twists.
      From xen/include/public/arch-x86/xen.h:
      
      Also note that when calling DOMCTL_setvcpucontext and VCPU_initialise
      for HVM and PVH guests, not all information in this structure is updated:
      
       - For HVM guests, the structures read include: fpu_ctxt (if
       VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
      
       - PVH guests are the same as HVM guests, but additionally use ctrlreg[3] to
       set cr3. All other fields not used should be set to 0.
      
      This is what we do. We piggyback on the 'xen_setup_gdt' - but modify
      a bit - we need to call 'load_percpu_segment' so that 'switch_to_new_gdt'
      can load per-cpu data-structures. It has no effect on the VCPU0.
      
      We also piggyback on the %rdi register to pass in the CPU number - so
      that when we bootup a new CPU, the cpu_bringup_and_idle will have
      passed as the first parameter the CPU number (via %rdi for 64-bit).
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      5840c84b
    • M
      xen/pvh: Load GDT/GS in early PV bootup code for BSP. · 8d656bbe
      Mukesh Rathor 提交于
      During early bootup we start life using the Xen provided
      GDT, which means that we are running with %cs segment set
      to FLAT_KERNEL_CS (FLAT_RING3_CS64 0xe033, GDT index 261).
      
      But for PVH we want to be use HVM type mechanism for
      segment operations. As such we need to switch to the HVM
      one and also reload ourselves with the __KERNEL_CS:eip
      to run in the proper GDT and segment.
      
      For HVM this is usually done in 'secondary_startup_64' in
      (head_64.S) but since we are not taking that bootup
      path (we start in PV - xen_start_kernel) we need to do
      that in the early PV bootup paths.
      
      For good measure we also zero out the %fs, %ds, and %es
      (not strictly needed as Xen has already cleared them
      for us). The %gs is loaded by 'switch_to_new_gdt'.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      8d656bbe
    • M
      xen/pvh: Setup up shared_info. · 4dd322bc
      Mukesh Rathor 提交于
      For PVHVM the shared_info structure is provided via the same way
      as for normal PV guests (see include/xen/interface/xen.h).
      
      That is during bootup we get 'xen_start_info' via the %esi register
      in startup_xen. Then later we extract the 'shared_info' from said
      structure (in xen_setup_shared_info) and start using it.
      
      The 'xen_setup_shared_info' is all setup to work with auto-xlat
      guests, but there are two functions which it calls that are not:
      xen_setup_mfn_list_list and xen_setup_vcpu_info_placement.
      This patch modifies the P2M code (xen_setup_mfn_list_list)
      while the "Piggyback on PVHVM for event channels" modifies
      the xen_setup_vcpu_info_placement.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      4dd322bc
    • M
      xen/pvh/mmu: Use PV TLB instead of native. · 76bcceff
      Mukesh Rathor 提交于
      We also optimize one - the TLB flush. The native operation would
      needlessly IPI offline VCPUs causing extra wakeups. Using the
      Xen one avoids that and lets the hypervisor determine which
      VCPU needs the TLB flush.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      76bcceff
    • M
      xen/pvh: MMU changes for PVH (v2) · 4e44e44b
      Mukesh Rathor 提交于
      .. which are surprisingly small compared to the amount for PV code.
      
      PVH uses mostly native mmu ops, we leave the generic (native_*) for
      the majority and just overwrite the baremetal with the ones we need.
      
      At startup, we are running with pre-allocated page-tables
      courtesy of the tool-stack. But we still need to graft them
      in the Linux initial pagetables. However there is no need to
      unpin/pin and change them to R/O or R/W.
      
      Note that the xen_pagetable_init due to 7836fec9d0994cc9c9150c5a33f0eb0eb08a335a
      "xen/mmu/p2m: Refactor the xen_pagetable_init code." does not
      need any changes - we just need to make sure that xen_post_allocator_init
      does not alter the pvops from the default native one.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      4e44e44b
    • K
      xen/mmu: Cleanup xen_pagetable_p2m_copy a bit. · b621e157
      Konrad Rzeszutek Wilk 提交于
      Stefano noticed that the code runs only under 64-bit so
      the comments about 32-bit are pointless.
      
      Also we change the condition for xen_revector_p2m_tree
      returning the same value (because it could not allocate
      a swath of space to put the new P2M in) or it had been
      called once already. In such we return early from the
      function.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      b621e157
    • K
      xen/mmu/p2m: Refactor the xen_pagetable_init code (v2). · 32df75cd
      Konrad Rzeszutek Wilk 提交于
      The revectoring and copying of the P2M only happens when
      !auto-xlat and on 64-bit builds. It is not obvious from
      the code, so lets have seperate 32 and 64-bit functions.
      
      We also invert the check for auto-xlat to make the code
      flow simpler.
      Suggested-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      32df75cd
    • K
      xen/pvh: Don't setup P2M tree. · 696fd7c5
      Konrad Rzeszutek Wilk 提交于
      P2M is not available for PVH. Fortunatly for us the
      P2M code already has mostly the support for auto-xlat guest thanks to
      commit 3d24bbd7
      "grant-table: call set_phys_to_machine after mapping grant refs"
      which: "
      introduces set_phys_to_machine calls for auto_translated guests
      (even on x86) in gnttab_map_refs and gnttab_unmap_refs.
      translated by swiotlb-xen... " so we don't need to muck much.
      
      with above mentioned "commit you'll get set_phys_to_machine calls
      from gnttab_map_refs and gnttab_unmap_refs but PVH guests won't do
      anything with them " (Stefano Stabellini) which is OK - we want
      them to be NOPs.
      
      This is because we assume that an "IOMMU is always present on the
      plaform and Xen is going to make the appropriate IOMMU pagetable
      changes in the hypercall implementation of GNTTABOP_map_grant_ref
      and GNTTABOP_unmap_grant_ref, then eveything should be transparent
      from PVH priviligied point of view and DMA transfers involving
      foreign pages keep working with no issues[sp]
      
      Otherwise we would need a P2M (and an M2P) for PVH priviligied to
      track these foreign pages .. (see arch/arm/xen/p2m.c)."
      (Stefano Stabellini).
      
      We still have to inhibit the building of the P2M tree.
      That had been done in the past by not calling
      xen_build_dynamic_phys_to_machine (which setups the P2M tree
      and gives us virtual address to access them). But we are missing
      a check for xen_build_mfn_list_list - which was continuing to setup
      the P2M tree and would blow up at trying to get the virtual
      address of p2m_missing (which would have been setup by
      xen_build_dynamic_phys_to_machine).
      
      Hence a check is needed to not call xen_build_mfn_list_list when
      running in auto-xlat mode.
      
      Instead of replicating the check for auto-xlat in enlighten.c
      do it in the p2m.c code. The reason is that the xen_build_mfn_list_list
      is called also in xen_arch_post_suspend without any checks for
      auto-xlat. So for PVH or PV with auto-xlat - we would needlessly
      allocate space for an P2M tree.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      696fd7c5
    • M
      xen/pvh: Early bootup changes in PV code (v4). · d285d683
      Mukesh Rathor 提交于
      We don't use the filtering that 'xen_cpuid' is doing
      because the hypervisor treats 'XEN_EMULATE_PREFIX' as
      an invalid instruction. This means that all of the filtering
      will have to be done in the hypervisor/toolstack.
      
      Without the filtering we expose to the guest the:
      
       - cpu topology (sockets, cores, etc);
       - the APERF (which the generic scheduler likes to
          use), see  5e626254
          "xen/setup: filter APERFMPERF cpuid feature out"
       - and the inability to figure out whether MWAIT_LEAF
         should be exposed or not. See
         df88b2d9
         "xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded."
       - x2apic, see  4ea9b9ac
         "xen: mask x2APIC feature in PV"
      
      We also check for vector callback early on, as it is a required
      feature. PVH also runs at default kernel IOPL.
      
      Finally, pure PV settings are moved to a separate function that are
      only called for pure PV, ie, pv with pvmmu. They are also #ifdef
      with CONFIG_XEN_PVMMU.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      d285d683
    • M
      xen/pvh/x86: Define what an PVH guest is (v3). · ddc416cb
      Mukesh Rathor 提交于
      Which is a PV guest with auto page translation enabled
      and with vector callback. It is a cross between PVHVM and PV.
      
      The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
      with modifications):
      
      "* the guest uses auto translate:
       - p2m is managed by Xen
       - pagetables are owned by the guest
       - mmu_update hypercall not available
      * it uses event callback and not vlapic emulation,
      * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
      
      For a full list of hcalls supported for PVH, see pvh_hypercall64_table
      in arch/x86/hvm/hvm.c in xen.  From the ABI prespective, it's mostly a
      PV guest with auto translate, although it does use hvm_op for setting
      callback vector."
      
      Also we use the PV cpuid, albeit we can use the HVM (native) cpuid.
      However, we do have a fair bit of filtering in the xen_cpuid and
      we can piggyback on that until the hypervisor/toolstack filters
      the appropiate cpuids. Once that is done we can swap over to
      use the native one.
      
      We setup a Kconfig entry that is disabled by default and
      cannot be enabled.
      
      Note that on ARM the concept of PVH is non-existent. As Ian
      put it: "an ARM guest is neither PV nor HVM nor PVHVM.
      It's a bit like PVH but is different also (it's further towards
      the H end of the spectrum than even PVH).". As such these
      options (PVHVM, PVH) are never enabled nor seen on ARM
      compilations.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ddc416cb
    • M
      xen/p2m: Check for auto-xlat when doing mfn_to_local_pfn. · fc590efe
      Mukesh Rathor 提交于
      Most of the functions in page.h are prefaced with
      	if (xen_feature(XENFEAT_auto_translated_physmap))
      		return mfn;
      
      Except the mfn_to_local_pfn. At a first sight, the function
      should work without this patch - as the 'mfn_to_mfn' has
      a similar check. But there are no such check in the
      'get_phys_to_machine' function - so we would crash in there.
      
      This fixes it by following the convention of having the
      check for auto-xlat in these static functions.
      Signed-off-by: NMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      fc590efe
    • D
      xen/x86: set VIRQ_TIMER priority to maximum · 8785c676
      David Vrabel 提交于
      Commit bee980d9 (xen/events: Handle VIRQ_TIMER before any other hardirq
      in event loop) effectively made the VIRQ_TIMER the highest priority event
      when using the 2-level ABI.
      
      Set the VIRQ_TIMER priority to the highest so this behaviour is retained
      when using the FIFO-based ABI.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      8785c676
  7. 04 1月, 2014 2 次提交
    • K
      xen/pvhvm: Remove the xen_platform_pci int. · 6f6c15ef
      Konrad Rzeszutek Wilk 提交于
      Since we have  xen_has_pv_devices,xen_has_pv_disk_devices,
      xen_has_pv_nic_devices, and xen_has_pv_and_legacy_disk_devices
      to figure out the different 'unplug' behaviors - lets
      use those instead of this single int.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      6f6c15ef
    • K
      xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4). · 51c71a3b
      Konrad Rzeszutek Wilk 提交于
      The user has the option of disabling the platform driver:
      00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
      
      which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
      and allow the PV drivers to take over. If the user wishes
      to disable that they can set:
      
        xen_platform_pci=0
        (in the guest config file)
      
      or
        xen_emul_unplug=never
        (on the Linux command line)
      
      except it does not work properly. The PV drivers still try to
      load and since the Xen platform driver is not run - and it
      has not initialized the grant tables, most of the PV drivers
      stumble upon:
      
      input: Xen Virtual Keyboard as /devices/virtual/input/input5
      input: Xen Virtual Pointer as /devices/virtual/input/input6M
      ------------[ cut here ]------------
      kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
      CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
      Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
      RIP: 0010:[<ffffffff813ddc40>]  [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
      Call Trace:
       [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
       [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
       [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
       [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
       [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
       [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
       [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
       [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
       [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
       [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
       [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
       [<ffffffff8145e7d9>] driver_attach+0x19/0x20
       [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
       [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
       [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
       [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
       [<ffffffffa0015000>] ? 0xffffffffa0014fff
       [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
       [<ffffffff81002049>] do_one_initcall+0x49/0x170
      
      .. snip..
      
      which is hardly nice. This patch fixes this by having each
      PV driver check for:
       - if running in PV, then it is fine to execute (as that is their
         native environment).
       - if running in HVM, check if user wanted 'xen_emul_unplug=never',
         in which case bail out and don't load any PV drivers.
       - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
         does not exist, then bail out and not load PV drivers.
       - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
         then bail out for all PV devices _except_ the block one.
         Ditto for the network one ('nics').
       - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
         then load block PV driver, and also setup the legacy IDE paths.
         In (v3) make it actually load PV drivers.
      
      Reported-by: Sander Eikelenboom <linux@eikelenboom.it
      Reported-by: NAnthony PERARD <anthony.perard@citrix.com>
      Reported-and-Tested-by: NFabio Fantoni <fabio.fantoni@m2r.biz>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
      can be used per Ian and Stefano suggestion]
      [v3: Make the unnecessary case work properly]
      [v4: s/disks/ide-disks/ spotted by Fabio]
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> [for PCI parts]
      CC: stable@vger.kernel.org
      51c71a3b
  8. 20 12月, 2013 1 次提交
  9. 19 12月, 2013 2 次提交
    • R
      mm: fix TLB flush race between migration, and change_protection_range · 20841405
      Rik van Riel 提交于
      There are a few subtle races, between change_protection_range (used by
      mprotect and change_prot_numa) on one side, and NUMA page migration and
      compaction on the other side.
      
      The basic race is that there is a time window between when the PTE gets
      made non-present (PROT_NONE or NUMA), and the TLB is flushed.
      
      During that time, a CPU may continue writing to the page.
      
      This is fine most of the time, however compaction or the NUMA migration
      code may come in, and migrate the page away.
      
      When that happens, the CPU may continue writing, through the cached
      translation, to what is no longer the current memory location of the
      process.
      
      This only affects x86, which has a somewhat optimistic pte_accessible.
      All other architectures appear to be safe, and will either always flush,
      or flush whenever there is a valid mapping, even with no permissions
      (SPARC).
      
      The basic race looks like this:
      
      CPU A			CPU B			CPU C
      
      						load TLB entry
      make entry PTE/PMD_NUMA
      			fault on entry
      						read/write old page
      			start migrating page
      			change PTE/PMD to new page
      						read/write old page [*]
      flush TLB
      						reload TLB from new entry
      						read/write new page
      						lose data
      
      [*] the old page may belong to a new user at this point!
      
      The obvious fix is to flush remote TLB entries, by making sure that
      pte_accessible aware of the fact that PROT_NONE and PROT_NUMA memory may
      still be accessible if there is a TLB flush pending for the mm.
      
      This should fix both NUMA migration and compaction.
      
      [mgorman@suse.de: fix build]
      Signed-off-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20841405
    • M
      mm: numa: serialise parallel get_user_page against THP migration · 2b4847e7
      Mel Gorman 提交于
      Base pages are unmapped and flushed from cache and TLB during normal
      page migration and replaced with a migration entry that causes any
      parallel NUMA hinting fault or gup to block until migration completes.
      
      THP does not unmap pages due to a lack of support for migration entries
      at a PMD level.  This allows races with get_user_pages and
      get_user_pages_fast which commit 3f926ab9 ("mm: Close races between
      THP migration and PMD numa clearing") made worse by introducing a
      pmd_clear_flush().
      
      This patch forces get_user_page (fast and normal) on a pmd_numa page to
      go through the slow get_user_page path where it will serialise against
      THP migration and properly account for the NUMA hinting fault.  On the
      migration side the page table lock is taken for each PTE update.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b4847e7
  10. 13 12月, 2013 3 次提交
    • G
      KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376) · 17d68b76
      Gleb Natapov 提交于
      A guest can cause a BUG_ON() leading to a host kernel crash.
      When the guest writes to the ICR to request an IPI, while in x2apic
      mode the following things happen, the destination is read from
      ICR2, which is a register that the guest can control.
      
      kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
      cluster id.  A BUG_ON is triggered, which is a protection against
      accessing map->logical_map with an out-of-bounds access and manages
      to avoid that anything really unsafe occurs.
      
      The logic in the code is correct from real HW point of view. The problem
      is that KVM supports only one cluster with ID 0 in clustered mode, but
      the code that has the bug does not take this into account.
      Reported-by: NLars Bull <larsbull@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      17d68b76
    • A
      KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368) · fda4e2e8
      Andy Honig 提交于
      In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
      potential to corrupt kernel memory if userspace provides an address that
      is at the end of a page.  This patches concerts those functions to use
      kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
      vapic_address specified by userspace during ioctl processing and returns
      an error to userspace if the address is not a valid GPA.
      
      This is generally not guest triggerable, because the required write is
      done by firmware that runs before the guest.  Also, it only affects AMD
      processors and oldish Intel that do not have the FlexPriority feature
      (unless you disable FlexPriority, of course; then newer processors are
      also affected).
      
      Fixes: b93463aa ('KVM: Accelerated apic support')
      Reported-by: NAndrew Honig <ahonig@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fda4e2e8
    • A
      KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367) · b963a22e
      Andy Honig 提交于
      Under guest controllable circumstances apic_get_tmcct will execute a
      divide by zero and cause a crash.  If the guest cpuid support
      tsc deadline timers and performs the following sequence of requests
      the host will crash.
      - Set the mode to periodic
      - Set the TMICT to 0
      - Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
      - Set the TMICT to non-zero.
      Then the lapic_timer.period will be 0, but the TMICT will not be.  If the
      guest then reads from the TMCCT then the host will perform a divide by 0.
      
      This patch ensures that if the lapic_timer.period is 0, then the division
      does not occur.
      Reported-by: NAndrew Honig <ahonig@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b963a22e
  11. 11 12月, 2013 3 次提交
  12. 10 12月, 2013 2 次提交
  13. 05 12月, 2013 3 次提交