Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 1月, 2013 2 次提交
  3. 27 1月, 2013 1 次提交
  5. 24 1月, 2013 17 次提交
  7. 22 1月, 2013 3 次提交
  9. 17 1月, 2013 1 次提交
  11. 14 1月, 2013 7 次提交
  13. 11 1月, 2013 2 次提交
    • X
      KVM: MMU: fix infinite fault access retry · 7751babd
      由 Xiao Guangrong 提交于 
      We have two issues in current code:
- if target gfn is used as its page table, guest will refault then kvm will use
  small page size to map it. We need two #PF to fix its shadow page table

- sometimes, say a exception is triggered during vm-exit caused by #PF
  (see handle_exception() in vmx.c), we remove all the shadow pages shadowed
  by the target gfn before go into page fault path, it will cause infinite
  loop:
  delete shadow pages shadowed by the gfn -> try to use large page size to map
  the gfn -> retry the access ->...

To fix these, we can adjust page size early if the target gfn is used as page
table
Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      7751babd
    • X
      KVM: MMU: fix Dirty bit missed if CR0.WP = 0 · c2288505
      由 Xiao Guangrong 提交于 
      If the write-fault access is from supervisor and CR0.WP is not set on the
vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
and clears U bit. This is the chance that kvm can change pte access from
readonly to writable

Unfortunately, the pte access is the access of 'direct' shadow page table,
means direct sp.role.access = pte_access, then we will create a writable
spte entry on the readonly shadow page table. It will cause Dirty bit is
not tracked when two guest ptes point to the same large page. Note, it
does not have other impact except Dirty bit since cr0.wp is encoded into
sp.role

It can be fixed by adjusting pte access before establishing shadow page
table. Also, after that, no mmu specified code exists in the common function
and drop two parameters in set_spte
Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      c2288505
  15. 10 1月, 2013 7 次提交
    • A
      KVM: PPC: BookE: Add EPR ONE_REG sync · 324b3e63
      由 Alexander Graf 提交于 
      We need to be able to read and write the contents of the EPR register
from user space.

This patch implements that logic through the ONE_REG API and declares
its (never implemented) SREGS counterpart as deprecated.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      324b3e63
    • A
      KVM: PPC: BookE: Implement EPR exit · 1c810636
      由 Alexander Graf 提交于 
      The External Proxy Facility in FSL BookE chips allows the interrupt
controller to automatically acknowledge an interrupt as soon as a
core gets its pending external interrupt delivered.

Today, user space implements the interrupt controller, so we need to
check on it during such a cycle.

This patch implements logic for user space to enable EPR exiting,
disable EPR exiting and EPR exiting itself, so that user space can
acknowledge an interrupt when an external interrupt has successfully
been delivered into the guest vcpu.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      1c810636
    • A
      KVM: PPC: BookE: Emulate mfspr on EPR · 37ecb257
      由 Alexander Graf 提交于 
      The EPR register is potentially valid for PR KVM as well, so we need
to emulate accesses to it. It's only defined for reading, so only
handle the mfspr case.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      37ecb257
    • A
      KVM: PPC: BookE: Allow irq deliveries to inject requests · b8c649a9
      由 Alexander Graf 提交于 
      When injecting an interrupt into guest context, we usually don't need
to check for requests anymore. At least not until today.

With the introduction of EPR, we will have to create a request when the
guest has successfully accepted an external interrupt though.

So we need to prepare the interrupt delivery to abort guest entry
gracefully. Otherwise we'd delay the EPR request.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      b8c649a9
    • M
      KVM: PPC: Fix mfspr/mtspr MMUCFG emulation · f2be6550
      由 Mihai Caraman 提交于 
      On mfspr/mtspr emulation path Book3E's MMUCFG SPR with value 1015 clashes
with G4's MSSSR0 SPR. Move MSSSR0 emulation from generic part to Books3S.
MSSSR0 also clashes with Book3S's DABRX SPR. DABRX was not explicitly
handled so Book3S execution flow will behave as before.
Signed-off-by: NMihai Caraman <mihai.caraman@freescale.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      f2be6550
    • A
      KVM: PPC: Book3S: PR: Enable alternative instruction for SC 1 · 50c7bb80
      由 Alexander Graf 提交于 
      When running on top of pHyp, the hypercall instruction "sc 1" goes
straight into pHyp without trapping in supervisor mode.

So if we want to support PAPR guest in this configuration we need to
add a second way of accessing PAPR hypercalls, preferably with the
exact same semantics except for the instruction.

So let's overlay an officially reserved instruction and emulate PAPR
hypercalls whenever we hit that one.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      50c7bb80
    • A
      KVM: PPC: Only WARN on invalid emulation · 5a33169e
      由 Alexander Graf 提交于 
      When we hit an emulation result that we didn't expect, that is an error,
but it's nothing that warrants a BUG(), because it can be guest triggered.

So instead, let's only WARN() the user that this happened.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      5a33169e