1. 06 1月, 2014 1 次提交
    • 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
  2. 31 7月, 2012 1 次提交
  3. 26 2月, 2011 1 次提交
  4. 14 2月, 2009 1 次提交
  5. 16 7月, 2008 2 次提交
  6. 24 6月, 2008 1 次提交
  7. 20 6月, 2008 2 次提交
  8. 02 6月, 2008 1 次提交
  9. 23 5月, 2008 1 次提交
  10. 30 1月, 2008 1 次提交
    • S
      xen: fix section usage in xen-head.S and setup.c · 08b6d290
      Sam Ravnborg 提交于
      additional section for .init.text appending a number.
      
      A side effect of this was a section mismatch warning because modpost did
      not recognize a .init.text section named .init.text.1: WARNING:
      vmlinux.o(.text.head+0x247): Section mismatch: reference to
      .init.text.1:start_kernel (between 'is386' and 'check_x87')
      
      Fix this by hardcoding the "ax" in the pushsection.  Thanks to Torlaf for
      reporting this.
      
      Alan Modra provided the hint that made me able to locate the root cause of
      this warning.  And Mike Frysinger told me how to properly fix it using
      __INIT/__FINIT.
      
      Fix following Section mismatch warning in addition:
      WARNING: vmlinux.o(.text+0x14c8): Section mismatch: reference to .init.data:vsyscall_int80_start (between 'fiddle_vdso' and 'xen_setup_features')
      
      fiddle_vdso was only used from a __init function - so declare it __init.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Toralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      08b6d290
  11. 11 10月, 2007 1 次提交
  12. 23 8月, 2007 1 次提交
  13. 23 7月, 2007 1 次提交
  14. 18 7月, 2007 1 次提交
    • J
      xen: Core Xen implementation · 5ead97c8
      Jeremy Fitzhardinge 提交于
      This patch is a rollup of all the core pieces of the Xen
      implementation, including:
       - booting and setup
       - pagetable setup
       - privileged instructions
       - segmentation
       - interrupt flags
       - upcalls
       - multicall batching
      
      BOOTING AND SETUP
      
      The vmlinux image is decorated with ELF notes which tell the Xen
      domain builder what the kernel's requirements are; the domain builder
      then constructs the address space accordingly and starts the kernel.
      
      Xen has its own entrypoint for the kernel (contained in an ELF note).
      The ELF notes are set up by xen-head.S, which is included into head.S.
      In principle it could be linked separately, but it seems to provoke
      lots of binutils bugs.
      
      Because the domain builder starts the kernel in a fairly sane state
      (32-bit protected mode, paging enabled, flat segments set up), there's
      not a lot of setup needed before starting the kernel proper.  The main
      steps are:
        1. Install the Xen paravirt_ops, which is simply a matter of a
           structure assignment.
        2. Set init_mm to use the Xen-supplied pagetables (analogous to the
           head.S generated pagetables in a native boot).
        3. Reserve address space for Xen, since it takes a chunk at the top
           of the address space for its own use.
        4. Call start_kernel()
      
      PAGETABLE SETUP
      
      Once we hit the main kernel boot sequence, it will end up calling back
      via paravirt_ops to set up various pieces of Xen specific state.  One
      of the critical things which requires a bit of extra care is the
      construction of the initial init_mm pagetable.  Because Xen places
      tight constraints on pagetables (an active pagetable must always be
      valid, and must always be mapped read-only to the guest domain), we
      need to be careful when constructing the new pagetable to keep these
      constraints in mind.  It turns out that the easiest way to do this is
      use the initial Xen-provided pagetable as a template, and then just
      insert new mappings for memory where a mapping doesn't already exist.
      
      This means that during pagetable setup, it uses a special version of
      xen_set_pte which ignores any attempt to remap a read-only page as
      read-write (since Xen will map its own initial pagetable as RO), but
      lets other changes to the ptes happen, so that things like NX are set
      properly.
      
      PRIVILEGED INSTRUCTIONS AND SEGMENTATION
      
      When the kernel runs under Xen, it runs in ring 1 rather than ring 0.
      This means that it is more privileged than user-mode in ring 3, but it
      still can't run privileged instructions directly.  Non-performance
      critical instructions are dealt with by taking a privilege exception
      and trapping into the hypervisor and emulating the instruction, but
      more performance-critical instructions have their own specific
      paravirt_ops.  In many cases we can avoid having to do any hypercalls
      for these instructions, or the Xen implementation is quite different
      from the normal native version.
      
      The privileged instructions fall into the broad classes of:
        Segmentation: setting up the GDT and the GDT entries, LDT,
           TLS and so on.  Xen doesn't allow the GDT to be directly
           modified; all GDT updates are done via hypercalls where the new
           entries can be validated.  This is important because Xen uses
           segment limits to prevent the guest kernel from damaging the
           hypervisor itself.
        Traps and exceptions: Xen uses a special format for trap entrypoints,
           so when the kernel wants to set an IDT entry, it needs to be
           converted to the form Xen expects.  Xen sets int 0x80 up specially
           so that the trap goes straight from userspace into the guest kernel
           without going via the hypervisor.  sysenter isn't supported.
        Kernel stack: The esp0 entry is extracted from the tss and provided to
           Xen.
        TLB operations: the various TLB calls are mapped into corresponding
           Xen hypercalls.
        Control registers: all the control registers are privileged.  The most
           important is cr3, which points to the base of the current pagetable,
           and we handle it specially.
      
      Another instruction we treat specially is CPUID, even though its not
      privileged.  We want to control what CPU features are visible to the
      rest of the kernel, and so CPUID ends up going into a paravirt_op.
      Xen implements this mainly to disable the ACPI and APIC subsystems.
      
      INTERRUPT FLAGS
      
      Xen maintains its own separate flag for masking events, which is
      contained within the per-cpu vcpu_info structure.  Because the guest
      kernel runs in ring 1 and not 0, the IF flag in EFLAGS is completely
      ignored (and must be, because even if a guest domain disables
      interrupts for itself, it can't disable them overall).
      
      (A note on terminology: "events" and interrupts are effectively
      synonymous.  However, rather than using an "enable flag", Xen uses a
      "mask flag", which blocks event delivery when it is non-zero.)
      
      There are paravirt_ops for each of cli/sti/save_fl/restore_fl, which
      are implemented to manage the Xen event mask state.  The only thing
      worth noting is that when events are unmasked, we need to explicitly
      see if there's a pending event and call into the hypervisor to make
      sure it gets delivered.
      
      UPCALLS
      
      Xen needs a couple of upcall (or callback) functions to be implemented
      by each guest.  One is the event upcalls, which is how events
      (interrupts, effectively) are delivered to the guests.  The other is
      the failsafe callback, which is used to report errors in either
      reloading a segment register, or caused by iret.  These are
      implemented in i386/kernel/entry.S so they can jump into the normal
      iret_exc path when necessary.
      
      MULTICALL BATCHING
      
      Xen provides a multicall mechanism, which allows multiple hypercalls
      to be issued at once in order to mitigate the cost of trapping into
      the hypervisor.  This is particularly useful for context switches,
      since the 4-5 hypercalls they would normally need (reload cr3, update
      TLS, maybe update LDT) can be reduced to one.  This patch implements a
      generic batching mechanism for hypercalls, which gets used in many
      places in the Xen code.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Cc: Ian Pratt <ian.pratt@xensource.com>
      Cc: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
      Cc: Adrian Bunk <bunk@stusta.de>
      5ead97c8