1. 29 4月, 2013 2 次提交
  2. 07 3月, 2013 11 次提交
  3. 25 2月, 2013 1 次提交
  4. 24 1月, 2013 5 次提交
    • C
      KVM: ARM: Handle I/O aborts · 45e96ea6
      Christoffer Dall 提交于
      When the guest accesses I/O memory this will create data abort
      exceptions and they are handled by decoding the HSR information
      (physical address, read/write, length, register) and forwarding reads
      and writes to QEMU which performs the device emulation.
      
      Certain classes of load/store operations do not support the syndrome
      information provided in the HSR.  We don't support decoding these (patches
      are available elsewhere), so we report an error to user space in this case.
      
      This requires changing the general flow somewhat since new calls to run
      the VCPU must check if there's a pending MMIO load and perform the write
      after userspace has made the data available.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      45e96ea6
    • C
      KVM: ARM: Handle guest faults in KVM · 94f8e641
      Christoffer Dall 提交于
      Handles the guest faults in KVM by mapping in corresponding user pages
      in the 2nd stage page tables.
      
      We invalidate the instruction cache by MVA whenever we map a page to the
      guest (no, we cannot only do it when we have an iabt because the guest
      may happily read/write a page before hitting the icache) if the hardware
      uses VIPT or PIPT.  In the latter case, we can invalidate only that
      physical page.  In the first case, all bets are off and we simply must
      invalidate the whole affair.  Not that VIVT icaches are tagged with
      vmids, and we are out of the woods on that one.  Alexander Graf was nice
      enough to remind us of this massive pain.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      94f8e641
    • C
      KVM: ARM: Memory virtualization setup · d5d8184d
      Christoffer Dall 提交于
      This commit introduces the framework for guest memory management
      through the use of 2nd stage translation. Each VM has a pointer
      to a level-1 table (the pgd field in struct kvm_arch) which is
      used for the 2nd stage translations. Entries are added when handling
      guest faults (later patch) and the table itself can be allocated and
      freed through the following functions implemented in
      arch/arm/kvm/arm_mmu.c:
       - kvm_alloc_stage2_pgd(struct kvm *kvm);
       - kvm_free_stage2_pgd(struct kvm *kvm);
      
      Each entry in TLBs and caches are tagged with a VMID identifier in
      addition to ASIDs. The VMIDs are assigned consecutively to VMs in the
      order that VMs are executed, and caches and tlbs are invalidated when
      the VMID space has been used to allow for more than 255 simultaenously
      running guests.
      
      The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
      freed in kvm_arch_destroy_vm(). Both functions are called from the main
      KVM code.
      
      We pre-allocate page table memory to be able to synchronize using a
      spinlock and be called under rcu_read_lock from the MMU notifiers.  We
      steal the mmu_memory_cache implementation from x86 and adapt for our
      specific usage.
      
      We support MMU notifiers (thanks to Marc Zyngier) through
      kvm_unmap_hva and kvm_set_spte_hva.
      
      Finally, define kvm_phys_addr_ioremap() to map a device at a guest IPA,
      which is used by VGIC support to map the virtual CPU interface registers
      to the guest. This support is added by Marc Zyngier.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      d5d8184d
    • C
      KVM: ARM: Hypervisor initialization · 342cd0ab
      Christoffer Dall 提交于
      Sets up KVM code to handle all exceptions taken to Hyp mode.
      
      When the kernel is booted in Hyp mode, calling an hvc instruction with r0
      pointing to the new vectors, the HVBAR is changed to the the vector pointers.
      This allows subsystems (like KVM here) to execute code in Hyp-mode with the
      MMU disabled.
      
      We initialize other Hyp-mode registers and enables the MMU for Hyp-mode from
      the id-mapped hyp initialization code. Afterwards, the HVBAR is changed to
      point to KVM Hyp vectors used to catch guest faults and to switch to Hyp mode
      to perform a world-switch into a KVM guest.
      
      Also provides memory mapping code to map required code pages, data structures,
      and I/O regions  accessed in Hyp mode at the same virtual address as the host
      kernel virtual addresses, but which conforms to the architectural requirements
      for translations in Hyp mode. This interface is added in arch/arm/kvm/arm_mmu.c
      and comprises:
       - create_hyp_mappings(from, to);
       - create_hyp_io_mappings(from, to, phys_addr);
       - free_hyp_pmds();
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      342cd0ab
    • C
      KVM: ARM: Initial skeleton to compile KVM support · 749cf76c
      Christoffer Dall 提交于
      Targets KVM support for Cortex A-15 processors.
      
      Contains all the framework components, make files, header files, some
      tracing functionality, and basic user space API.
      
      Only supported core is Cortex-A15 for now.
      
      Most functionality is in arch/arm/kvm/* or arch/arm/include/asm/kvm_*.h.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
      749cf76c
  5. 06 12月, 2012 1 次提交
    • P
      KVM: PPC: Book3S PR: Fix VSX handling · 28c483b6
      Paul Mackerras 提交于
      This fixes various issues in how we were handling the VSX registers
      that exist on POWER7 machines.  First, we were running off the end
      of the current->thread.fpr[] array.  Ultimately this was because the
      vcpu->arch.vsr[] array is sized to be able to store both the FP
      registers and the extra VSX registers (i.e. 64 entries), but PR KVM
      only uses it for the extra VSX registers (i.e. 32 entries).
      
      Secondly, calling load_up_vsx() from C code is a really bad idea,
      because it jumps to fast_exception_return at the end, rather than
      returning with a blr instruction.  This was causing it to jump off
      to a random location with random register contents, since it was using
      the largely uninitialized stack frame created by kvmppc_load_up_vsx.
      
      In fact, it isn't necessary to call either __giveup_vsx or load_up_vsx,
      since giveup_fpu and load_up_fpu handle the extra VSX registers as well
      as the standard FP registers on machines with VSX.  Also, since VSX
      instructions can access the VMX registers and the FP registers as well
      as the extra VSX registers, we have to load up the FP and VMX registers
      before we can turn on the MSR_VSX bit for the guest.  Conversely, if
      we save away any of the VSX or FP registers, we have to turn off MSR_VSX
      for the guest.
      
      To handle all this, it is more convenient for a single call to
      kvmppc_giveup_ext() to handle all the state saving that needs to be done,
      so we make it take a set of MSR bits rather than just one, and the switch
      statement becomes a series of if statements.  Similarly kvmppc_handle_ext
      needs to be able to load up more than one set of registers.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      28c483b6
  6. 01 11月, 2011 1 次提交
  7. 26 9月, 2011 1 次提交
    • P
      KVM: PPC: book3s_pr: Simplify transitions between virtual and real mode · 02143947
      Paul Mackerras 提交于
      This simplifies the way that the book3s_pr makes the transition to
      real mode when entering the guest.  We now call kvmppc_entry_trampoline
      (renamed from kvmppc_rmcall) in the base kernel using a normal function
      call instead of doing an indirect call through a pointer in the vcpu.
      If kvm is a module, the module loader takes care of generating a
      trampoline as it does for other calls to functions outside the module.
      
      kvmppc_entry_trampoline then disables interrupts and jumps to
      kvmppc_handler_trampoline_enter in real mode using an rfi[d].
      That then uses the link register as the address to return to
      (potentially in module space) when the guest exits.
      
      This also simplifies the way that we call the Linux interrupt handler
      when we exit the guest due to an external, decrementer or performance
      monitor interrupt.  Instead of turning on the MMU, then deciding that
      we need to call the Linux handler and turning the MMU back off again,
      we now go straight to the handler at the point where we would turn the
      MMU on.  The handler will then return to the virtual-mode code
      (potentially in the module).
      
      Along the way, this moves the setting and clearing of the HID5 DCBZ32
      bit into real-mode interrupts-off code, and also makes sure that
      we clear the MSR[RI] bit before loading values into SRR0/1.
      
      The net result is that we no longer need any code addresses to be
      stored in vcpu->arch.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      02143947
  8. 12 7月, 2011 2 次提交
    • P
      KVM: PPC: Add support for Book3S processors in hypervisor mode · de56a948
      Paul Mackerras 提交于
      This adds support for KVM running on 64-bit Book 3S processors,
      specifically POWER7, in hypervisor mode.  Using hypervisor mode means
      that the guest can use the processor's supervisor mode.  That means
      that the guest can execute privileged instructions and access privileged
      registers itself without trapping to the host.  This gives excellent
      performance, but does mean that KVM cannot emulate a processor
      architecture other than the one that the hardware implements.
      
      This code assumes that the guest is running paravirtualized using the
      PAPR (Power Architecture Platform Requirements) interface, which is the
      interface that IBM's PowerVM hypervisor uses.  That means that existing
      Linux distributions that run on IBM pSeries machines will also run
      under KVM without modification.  In order to communicate the PAPR
      hypercalls to qemu, this adds a new KVM_EXIT_PAPR_HCALL exit code
      to include/linux/kvm.h.
      
      Currently the choice between book3s_hv support and book3s_pr support
      (i.e. the existing code, which runs the guest in user mode) has to be
      made at kernel configuration time, so a given kernel binary can only
      do one or the other.
      
      This new book3s_hv code doesn't support MMIO emulation at present.
      Since we are running paravirtualized guests, this isn't a serious
      restriction.
      
      With the guest running in supervisor mode, most exceptions go straight
      to the guest.  We will never get data or instruction storage or segment
      interrupts, alignment interrupts, decrementer interrupts, program
      interrupts, single-step interrupts, etc., coming to the hypervisor from
      the guest.  Therefore this introduces a new KVMTEST_NONHV macro for the
      exception entry path so that we don't have to do the KVM test on entry
      to those exception handlers.
      
      We do however get hypervisor decrementer, hypervisor data storage,
      hypervisor instruction storage, and hypervisor emulation assist
      interrupts, so we have to handle those.
      
      In hypervisor mode, real-mode accesses can access all of RAM, not just
      a limited amount.  Therefore we put all the guest state in the vcpu.arch
      and use the shadow_vcpu in the PACA only for temporary scratch space.
      We allocate the vcpu with kzalloc rather than vzalloc, and we don't use
      anything in the kvmppc_vcpu_book3s struct, so we don't allocate it.
      We don't have a shared page with the guest, but we still need a
      kvm_vcpu_arch_shared struct to store the values of various registers,
      so we include one in the vcpu_arch struct.
      
      The POWER7 processor has a restriction that all threads in a core have
      to be in the same partition.  MMU-on kernel code counts as a partition
      (partition 0), so we have to do a partition switch on every entry to and
      exit from the guest.  At present we require the host and guest to run
      in single-thread mode because of this hardware restriction.
      
      This code allocates a hashed page table for the guest and initializes
      it with HPTEs for the guest's Virtual Real Memory Area (VRMA).  We
      require that the guest memory is allocated using 16MB huge pages, in
      order to simplify the low-level memory management.  This also means that
      we can get away without tracking paging activity in the host for now,
      since huge pages can't be paged or swapped.
      
      This also adds a few new exports needed by the book3s_hv code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      de56a948
    • A
      KVM: PPC: Resolve real-mode handlers through function exports · a22a2dac
      Alexander Graf 提交于
      Up until now, Book3S KVM had variables stored in the kernel that a kernel module
      or the kvm code in the kernel could read from to figure out where some real mode
      helper functions are located.
      
      This is all unnecessary. The high bits of the EA get ignore in real mode, so we
      can just use the pointer as is. Also, it's a lot easier on relocations when we
      use the normal way of resolving the address to a function, instead of jumping
      through hoops.
      
      This patch fixes compilation with CONFIG_RELOCATABLE=y.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      a22a2dac
  9. 17 5月, 2010 1 次提交
  10. 01 3月, 2010 2 次提交
  11. 05 11月, 2009 1 次提交
  12. 04 8月, 2008 1 次提交
  13. 27 4月, 2008 1 次提交
  14. 04 10月, 2006 1 次提交
  15. 13 9月, 2006 1 次提交
  16. 23 6月, 2006 1 次提交
  17. 19 6月, 2006 2 次提交
  18. 10 1月, 2006 1 次提交
  19. 28 10月, 2005 1 次提交
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4