Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 27 6月, 2014 1 次提交
    • A
      spapr_iommu: Make in-kernel TCE table optional · 9bb62a07
      由 Alexey Kardashevskiy 提交于 
      POWER KVM supports an KVM_CAP_SPAPR_TCE capability which allows allocating
TCE tables in the host kernel memory and handle H_PUT_TCE requests
targeted to specific LIOBN (logical bus number) right in the host without
switching to QEMU. At the moment this is used for emulated devices only
and the handler only puts TCE to the table. If the in-kernel H_PUT_TCE
handler finds a LIOBN and corresponding table, it will put a TCE to
the table and complete hypercall execution. The user space will not be
notified.

Upcoming VFIO support is going to use the same sPAPRTCETable device class
so KVM_CAP_SPAPR_TCE is going to be used as well. That means that TCE
tables for VFIO are going to be allocated in the host as well.
However VFIO operates with real IOMMU tables and simple copying of
a TCE to the real hardware TCE table will not work as guest physical
to host physical address translation is requited.

So until the host kernel gets VFIO support for H_PUT_TCE, we better not
to register VFIO's TCE in the host.

This adds a place holder for KVM_CAP_SPAPR_TCE_VFIO capability. It is not
in upstream yet and being discussed so now it is always false which means
that in-kernel VFIO acceleration is not supported.

This adds a bool @vfio_accel flag to the sPAPRTCETable device telling
that sPAPRTCETable should not try allocating TCE table in the host kernel
for VFIO. The flag is false now as at the moment there is no VFIO.

This adds an vfio_accel parameter to spapr_tce_new_table(), the semantic
is the same. Since there is only emulated PCI and VIO now, the flag is set
to false. Upcoming VFIO support will set it to true.

This is a preparation patch so no change in behaviour is expected
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      9bb62a07
  3. 16 6月, 2014 9 次提交
    • A
      PPC: KVM: Make pv hcall endian agnostic · d13fc32e
      由 Alexander Graf 提交于 
      There were a few revisions of the Linux kernel that incorrectly swapped
the hcall instructions when they saw ePAPR compliant hypercalls.

We already have fixups for those in place when running with PR KVM, but
HV KVM and systems that don't implement hypercalls at all are still broken
because they fall back to the QEMU implementation of fallback hypercalls.

So let's make the fallback hypercall instruction path endian agnostic. This
only really works well for 64bit guests, but I don't think there are any 32bit
systems left that don't implement real pv hcall support, so we'll never get
into this code path.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      d13fc32e
    • A
      KVM: target-ppc: Enable TM state migration · 80b3f79b
      由 Alexey Kardashevskiy 提交于 
      This adds migration support for registers saved before Transactional
Memory (TM) transaction started.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      80b3f79b
    • A
      KVM: PPC: Expose fixup hcall capability · 87a91de6
      由 Alexander Graf 提交于 
      New kvm versions expose a PPC_FIXUP_HCALL capability. Make it visible to
machine code so we can take decisions based on it.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      87a91de6
    • A
      spapr_iommu: Get rid of window_size in sPAPRTCETable · 523e7b8a
      由 Alexey Kardashevskiy 提交于 
      This removes window_size as it is basically a copy of nb_table
shifted by SPAPR_TCE_PAGE_SHIFT. As new dynamic DMA windows are
going to support windows as big as the entire RAM and this number
will be bigger that 32 capacity, we will have to do something
about @window_size anyway and removal seems to be the right way to go.

This removes dma_window_start/dma_window_size from sPAPRPHBState as
they are no longer used.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      523e7b8a
    • A
      spapr_iommu: Enable multiple TCE requests · da95324e
      由 Alexey Kardashevskiy 提交于 
      Currently only single TCE entry per request is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
kernel via ioctls, support of these calls can accelerate IOMMU operations.

This implements H_STUFF_TCE and H_PUT_TCE_INDIRECT.

This advertises "multi-tce" capability to the guest if the host kernel
supports it (KVM_CAP_SPAPR_MULTITCE) or guest is running in TCG mode.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      da95324e
    • A
      KVM: PPC: Enable compatibility mode · 6db5bb0f
      由 Alexey Kardashevskiy 提交于 
      The host kernel implements a KVM_REG_PPC_ARCH_COMPAT register which
this uses to enable a compatibility mode if any chosen.

This sets the KVM_REG_PPC_ARCH_COMPAT register in KVM. ppc_set_compat()
signals the caller if the mode cannot be enabled by the host kernel.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix TCG compat setting]
Signed-off-by: NAlexander Graf <agraf@suse.de>
      6db5bb0f
    • A
      spapr: Add support for time base offset migration · 98a8b524
      由 Alexey Kardashevskiy 提交于 
      This allows guests to have a different timebase origin from the host.

This is needed for migration, where a guest can migrate from one host
to another and the two hosts might have a different timebase origin.
However, the timebase seen by the guest must not go backwards, and
should go forwards only by a small amount corresponding to the time
taken for the migration.

This is only supported for recent POWER hardware which has the TBU40
(timebase upper 40 bits) register. That includes POWER6, 7, 8 but not
970.

This adds kvm_access_one_reg() to access a special register which is not
in env->spr. This requires kvm_set_one_reg/kvm_get_one_reg patch.

The feature must be present in the host kernel.

This bumps vmstate_spapr::version_id and enables new vmstate_ppc_timebase
only for it. Since the vmstate_spapr::minimum_version_id remains
unchanged, migration from older QEMU is supported but without
vmstate_ppc_timebase.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      98a8b524
    • A
      KVM: PPC: Don't secretly add 1T segment feature to CPU · 08215d8f
      由 Alexander Graf 提交于 
      When we select a CPU type that does not support 1TB segments, we should
not expose 1TB just because KVM supports 1TB segments. User configuration
always wins over feature availability.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      08215d8f
    • A
      target-ppc: Create versionless CPU class per family if KVM · 5b79b1ca
      由 Alexey Kardashevskiy 提交于 
      At the moment generic version-less CPUs are supported via hardcoded aliases.
For example, POWER7 is an alias for POWER7_v2.1. So when QEMU is started
with -cpu POWER7, the POWER7_v2.1 class instance is created.

This approach works for TCG and KVMs other than HV KVM. HV KVM cannot emulate
PVR value so the guest always sees the real PVR. HV KVM will not allow setting
PVR other that the host PVR because of that (the kernel patch for it is on
its way). So in most cases it is impossible to run QEMU with -cpu POWER7
unless the host PVR is exactly the same as the one from the alias (which
is now POWER7_v2.3). It was decided that under HV KVM QEMU should use
-cpu host.

Using "host" CPU type creates a problem for management tools such as libvirt
because they want to know in advance if the destination guest can possibly
run on the destination. Since the "host" type is really not a type and will
always work with any KVM, there is no way for libvirt to know if the migration
will success.

This registers additional CPU class derived from the host CPU family.
The name for it is taken from @desc field of the CPU family class.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      5b79b1ca
  5. 13 5月, 2014 1 次提交
    • P
      kvm: reset state from the CPU's reset method · 50a2c6e5
      由 Paolo Bonzini 提交于 
      Now that we have a CPU object with a reset method, it is better to
keep the KVM reset close to the CPU reset.  Using qemu_register_reset
as we do now keeps them far apart.

With this patch, PPC no longer calls the kvm_arch_ function, so
it can get removed there.  Other arches call it from their CPU
reset handler, and the function gets an ARMCPU/X86CPU/S390CPU.

Note that ARM- and s390-specific functions are called kvm_arm_*
and kvm_s390_*, while x86-specific functions are called kvm_arch_*.
That follows the convention used by the different architectures.
Changing that is the topic of a separate patch.
Reviewed-by: NGleb Natapov <gnatapov@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      50a2c6e5
  7. 30 4月, 2014 1 次提交
  9. 14 3月, 2014 2 次提交
  11. 05 3月, 2014 7 次提交
  13. 14 2月, 2014 1 次提交
  15. 20 12月, 2013 2 次提交
    • A
      powerpc: add PVR mask support · 3bc9ccc0
      由 Alexey Kardashevskiy 提交于 
      IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
a CPU version in lower 16 bits. Since there is no significant change
in behavior between versions, there is no point to add every single CPU
version in QEMU's CPU list. Also, new CPU versions of already supported
CPU won't break the existing code.

This adds PVR value/mask support for KVM, i.e. for -cpu host option.

As CPU family class name for POWER7 is "POWER7-family", there is no need
to touch aliases.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      3bc9ccc0
    • G
      target-ppc: add stubs for KVM breakpoints · c65f9a07
      由 Greg Kurz 提交于 
      The latest update to v3.13-rc3 (bf63839f) breaks the
ppc build with KVM:

kvm-all.o: In function `kvm_update_guest_debug':
kvm-all.c:1910: undefined reference to `kvm_arch_update_guest_debug'
kvm-all.o: In function `kvm_insert_breakpoint':
kvm-all.c:1937: undefined reference to `kvm_arch_insert_sw_breakpoint'
kvm-all.c:1945: undefined reference to `kvm_arch_insert_hw_breakpoint'
kvm-all.o: In function `kvm_remove_breakpoint':
kvm-all.c:1977: undefined reference to `kvm_arch_remove_sw_breakpoint'
kvm-all.c:1985: undefined reference to `kvm_arch_remove_hw_breakpoint'
kvm-all.o: In function `kvm_remove_all_breakpoints':
kvm-all.c:2009: undefined reference to `kvm_arch_remove_sw_breakpoint'
kvm-all.c:2006: undefined reference to `kvm_arch_remove_sw_breakpoint'
kvm-all.c:2017: undefined reference to `kvm_arch_remove_all_hw_breakpoints'

We need stubs until something gets implemented.
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      c65f9a07
  17. 26 10月, 2013 3 次提交
  19. 23 8月, 2013 1 次提交
  21. 30 7月, 2013 1 次提交
  23. 29 7月, 2013 2 次提交
  25. 10 7月, 2013 1 次提交
  27. 04 7月, 2013 1 次提交
  29. 01 7月, 2013 1 次提交
  31. 12 6月, 2013 1 次提交
    • S
      KVM: PPC: Add dummy kvm_arch_init_irq_routing() · 82169660
      由 Scott Wood 提交于 
      The common KVM code insists on calling kvm_arch_init_irq_routing()
as soon as it sees kernel header support for it (regardless of whether
QEMU supports it).  Provide a dummy function to satisfy this.

Unlike x86, PPC does not have one default irqchip, so there's no common
code that we'd stick here.  Even if you ignore the routes themselves,
which even on x86 are not set up in this function, the initial XICS
kernel implementation will not support IRQ routing, so it's best to
leave even the general feature flags up to the specific irqchip code.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      82169660
  33. 18 5月, 2013 1 次提交
  35. 27 4月, 2013 4 次提交
    • D
      target-ppc: Synchronize VPA state with KVM · 9b00ea49
      由 David Gibson 提交于 
      For PAPR guests, KVM tracks the various areas registered with the
H_REGISTER_VPA hypercall.  For full emulation, of course, these are tracked
within qemu.  At present these values are not synchronized.  This is a
problem for reset (qemu's reset of the VPA address is not pushed to KVM)
and will also be a problem for savevm / migration.

The kernel now supports accessing the VPA state via the ONE_REG interface,
this patch adds code to qemu to use that interface to keep the qemu and
KVM ideas of the VPA state synchronized.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      9b00ea49
    • D
      pseries: Fixes and enhancements to L1 cache properties · 0cbad81f
      由 David Gibson 提交于 
      PAPR requires that the device tree's CPU nodes have several properties
with information about the L1 cache.  We already create two of these
properties, but with incorrect names - "[id]cache-block-size" instead
of "[id]-cache-block-size" (note the extra hyphen).

We were also missing some of the required cache properties.  This
patch adds the [id]-cache-line-size properties (which have the same
values as the block size properties in all current cases).  We also
add the [id]-cache-size properties.

Adding the cache sizes requires some extra infrastructure in the
general target-ppc code to (optionally) set the cache sizes for
various CPUs.  The CPU family descriptions in translate_init.c can set
these sizes - this patch adds correct information for POWER7, I'm
leaving other CPU types to people who have a physical example to
verify against.  In addition, for -cpu host we take the values
advertised by the host (if available) and use those to override the
information based on PVR.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      0cbad81f
    • D
      pseries: Fix incorrect calculation of RMA size in certain configurations · f36951c1
      由 David Gibson 提交于 
      For the pseries machine, we need to advertise to the guest the size of its
RMA - that is the amount of memory it can access with the MMU off.  For HV
KVM, this is constrained by the hardware limitations on the virtual RMA of
one hash PTE per PTE group in the hash page table.  We already had code to
calculate this, but it was assuming the VRMA page size was the same as the
(host) backing page size for guest RAM.

In the case of a host kernel configured for 64k base page size, but running
on hardware (or firmware) which only allows 4k pages, the hose will do all
its allocations with a 64k page size, but still use 4k hardware pages for
actual mappings.  Usually that's transparent to things running under the
host, but in the case of the maximum VRMA size it's not.

This patch refines the RMA size calculation to instead use the largest
available hardware page size (as reported by the SMMU_INFO call) which is
less than or equal to the backing page size.  This now gives the correct
RMA size in all cases I've tested.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      f36951c1
    • B
      Enable kvm emulated watchdog · 31f2cb8f
      由 Bharat Bhushan 提交于 
      Enable the KVM emulated watchdog if KVM supports (use the
capability enablement in watchdog handler). Also watchdog exit
(KVM_EXIT_WATCHDOG) handling is added.
Watchdog state machine is cleared whenever VM state changes to running.
This is to handle the cases like return from debug halt etc.
Signed-off-by: NBharat Bhushan <bharat.bhushan@freescale.com>
[agraf: rebase to current code base, fix non-kvm cases]
Signed-off-by: NAlexander Graf <agraf@suse.de>
      31f2cb8f