Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 9月, 2014 16 次提交
  3. 25 8月, 2014 1 次提交
  5. 18 8月, 2014 1 次提交
  7. 15 8月, 2014 1 次提交
  9. 22 7月, 2014 1 次提交
    • H
      ppc: fix -mem-path failure · e206ad48
      由 Hu Tao 提交于 
      commit e938ba0c tried to enable -mem-path for ppc but breaked some ppc
boards.

The problems are:

1. it fails when allocating memory for rom, sram whose sizes are less
   than huge page size:

   ./ppc-softmmu/qemu-system-ppc  -m 512 -mem-path /hugepages/ \
   -kernel /home/hutao/Downloads/vmlinux-ppc -initrd \
   /home/hutao/Downloads/initrd-ppc.gz
   qemu-system-ppc: /mnt/data/projects/qemu/exec.c:1184: qemu_ram_set_idstr: Assertion `new_block' failed.

2. if there is a numa node backed by memory backend object, qemu fails
   with message:

   ./ppc-softmmu/qemu-system-ppc  -m 512 \
   -object memory-backend-file,size=512M,mem-path=/hugepages,id=f0 \
   -numa node,nodeid=0,memdev=f0 \
   -kernel /home/hutao/Downloads/vmlinux-ppc \
   -initrd /home/hutao/Downloads/initrd-ppc.gz
   qemu-system-ppc: memory backend f0 is used multiple times. Each -numa option must use a different memdev value.

This patch does following:

1. replaces memory_region_allocate_system_memory() with
   memory_region_init_ram() for rom, sram. Then only system memory
   is backed by hugepages when specifying mem-path.

2. for memory banks, allocates all ram with
   one memory_region_allocate_system_memory(), and use
   memory_region_init_alias() to initialize memory banks.

Tested machines: default(g3beige), mac99, taihu, bamboo, ref405ep.
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      e206ad48
  11. 15 7月, 2014 4 次提交
  13. 08 7月, 2014 2 次提交
  15. 07 7月, 2014 2 次提交
  17. 27 6月, 2014 12 次提交
    • A
      PPC: e500: Only create dt entries for existing serial ports · 79c0ff2c
      由 Alexander Graf 提交于 
      When the user specifies -nodefaults he can tell us that he doesn't want any
serial ports spawned by default. While we do honor that wish, we still create
device tree entries for those non-existent devices.

Make device tree generation depend on whether the device is actually available.
Signed-off-by: NAlexander Graf <agraf@suse.de>
      79c0ff2c
    • A
      spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB · 9a321e92
      由 Alexey Kardashevskiy 提交于 
      Currently SPAPR PHB keeps track of all allocated MSI (here and below
MSI stands for both MSI and MSIX) interrupt because
XICS used to be unable to reuse interrupts. This is a problem for
dynamic MSI reconfiguration which happens when guest reloads a driver
or performs PCI hotplug. Another problem is that the existing
implementation can enable MSI on 32 devices maximum
(SPAPR_MSIX_MAX_DEVS=32) and there is no good reason for that.

This makes use of new XICS ability to reuse interrupts.

This reorganizes MSI information storage in sPAPRPHBState. Instead of
static array of 32 descriptors (one per a PCI function), this patch adds
a GHashTable when @config_addr is a key and (first_irq, num) pair is
a value. GHashTable can dynamically grow and shrink so the initial limit
of 32 devices is gone.

This changes migration stream as @msi_table was a static array while new
@msi_devs is a dynamic hash table. This adds temporary array which is
used for migration, it is populated in "spapr_pci"::pre_save() callback
and expanded into the hash table in post_load() callback. Since
the destination side does not know the number of MSI-enabled devices
in advance and cannot pre-allocate the temporary array to receive
migration state, this makes use of new VMSTATE_STRUCT_VARRAY_ALLOC macro
which allocates the array automatically.

This resets the MSI configuration space when interrupts are released by
the ibm,change-msi RTAS call.

This fixed traces to be more informative.

This changes vmstate_spapr_pci_msi name from "...lsi" to "...msi" which
was incorrect by accident. As the internal representation changed,
thus bumps migration version number.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
[agraf: drop g_malloc_n usage]
Signed-off-by: NAlexander Graf <agraf@suse.de>
      9a321e92
    • A
      spapr: Remove @next_irq · ba0e5bf8
      由 Alexey Kardashevskiy 提交于 
      This removes @next_irq from sPAPREnvironment which was used in old
IRQ allocator as XICS is now responsible for IRQs and keeps track of
allocated IRQs.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      ba0e5bf8
    • A
      spapr: Move interrupt allocator to xics · bee763db
      由 Alexey Kardashevskiy 提交于 
      The current allocator returns IRQ numbers from a pool and does not
support IRQs reuse in any form as it did not keep track of what it
previously returned, it only keeps the last returned IRQ. Some use
cases such as PCI hot(un)plug may require IRQ release and reallocation.

This moves an allocator from SPAPR to XICS.

This switches IRQ users to use new API.

This uses LSI/MSI flags to know if interrupt is allocated.

The interrupt release function will be posted as a separate patch.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      bee763db
    • S
      spapr: Add RTAS sysparm SPLPAR Characteristics · 3b50d897
      由 Sam bobroff 提交于 
      Add support for the SPLPAR Characteristics parameter to the emulated
RTAS call ibm,get-system-parameter.

The support provides just enough information to allow "cat
/proc/powerpc/lparcfg" to succeed without generating a kernel error
message.

Without this patch the above command will produce the following kernel
message: arch/powerpc/platforms/pseries/lparcfg.c \
parse_system_parameter_string Error calling get-system-parameter \
(0xfffffffd)
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      3b50d897
    • S
      spapr: Add RTAS sysparm UUID · b907d7b0
      由 Sam bobroff 提交于 
      Add support for the UUID parameter to the emulated RTAS call
ibm,get-system-parameter.

Return the guest's UUID as the value for the RTAS UUID system
parameter, or null (a zero length result) if it is not set.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      b907d7b0
    • S
      spapr: Fix RTAS sysparm DIAGNOSTICS_RUN_MODE · 3052d951
      由 Sam bobroff 提交于 
      This allows the ibm,get-system-parameter RTAS call to succeed for the
DIAGNOSTICS_RUN_MODE system parameter.

The problem can be seen with "ppc64_cpu --run-mode" from the
powerpc-utils package which fails before this patch with "Machine does
not support diagnostic run mode".

This is corrected by using the rtas_st_buffer() function to write to
the buffer.

The RTAS constants are also moved out into a header file, some new
constants added and the surrounding code slightly simplified.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
[agraf: remove some commentary]
Signed-off-by: NAlexander Graf <agraf@suse.de>
      3052d951
    • A
      spapr: Define a 2.1 pseries machine · 6026db45
      由 Alexey Kardashevskiy 提交于 
      This adds a v2.1 machine to support backward compatibility
for newer macines in the case if they ever be implemented.

This adds a "pseries-2.1" machine as a child of the "pseries"
machine and only changes visible machine name.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      6026db45
    • A
      spapr: Fix code design style (s/SPAPRMachine/sPAPRMachineState) · 6ca1502e
      由 Alexey Kardashevskiy 提交于 
      Every single sPAPR QOM object has small first "s".
Most (not all yet) QOM objects have "State" suffix.

This replaces SPAPRMachine with sPAPRMachineState to conform with QEMU
code style and removes redundant empty line.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      6ca1502e
    • B
      mac99: Add motherboard devices before PCI cards · a0bb2a5f
      由 BALATON Zoltan 提交于 
      Change the order of creating devices for New World Mac emulation so
that devices on the motherboard are added first and PCI cards (VGA and
NIC) come later. As a side effect, this also causes OpenBIOS to map
the motherboard devices into the MMIO space to the same addresses as
on real hardware and allow clients that hardcode these addresses (e.g.
MorphOS) to find and use them until OpenBIOS is tought to map devices
to specific addresses. (On real hardware the graphics and network
cards are really on separate buses but we don't model that yet.) This
brings the memory map closer to what is found on PowerMac3,1.
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      a0bb2a5f
    • A
      spapr_pci_vfio: Add spapr-pci-vfio-host-bridge to support vfio · 9fc34ada
      由 Alexey Kardashevskiy 提交于 
      The patch adds a spapr-pci-vfio-host-bridge device type
which is a PCI Host Bridge with VFIO support. The new device
inherits from the spapr-pci-host-bridge device and adds an "iommu"
property which is an IOMMU id. This ID represents a minimal entity
for which IOMMU isolation can be guaranteed. In SPAPR architecture IOMMU
group is called a Partitionable Endpoint (PE).

Current implementation supports one IOMMU id per QEMU VFIO PHB. Since
SPAPR allows multiple PHB for no extra cost, this does not seem to
be a problem. This limitation may change in the future though.

Example of use:
Configure and Add 3 functions of a multifunctional device to QEMU:
(the NEC PCI USB card is used as an example here):
-device spapr-pci-vfio-host-bridge,id=USB,iommu=4,index=7 \
-device vfio-pci,host=4:0:1.0,addr=1.0,bus=USB,multifunction=true
-device vfio-pci,host=4:0:1.1,addr=1.1,bus=USB
-device vfio-pci,host=4:0:1.2,addr=1.2,bus=USB

where:
* index=7 is a QEMU PHB index (used as source for MMIO/MSI/IO windows
offset);
* iommu=4 is an IOMMU id which can be found in sysfs:
[aik@vpl2 ~]$ cd /sys/bus/pci/devices/0004:00:00.0/
[aik@vpl2 0004:00:00.0]$ ls -l iommu_group
lrwxrwxrwx 1 root root 0 Jun  5 12:49 iommu_group -> ../../../kernel/iommu_groups/4
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      9fc34ada
    • 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