This patch converts the OpenPIC device to qdev. Along the way it
renames the "openpic" target to "raven" and the "mpic" target to
"fsl_mpic_20", to better reflect the actual models they implement.
This way we have a generic OpenPIC device now that can handle
different flavors of the OpenPIC specification.
Signed-off-by: Alexander Graf <agraf@suse.de>
The current openpic emulation contains half-ready code for bypass mode.
Remove it, so that when someone wants to finish it they can start from a
clean state.
Signed-off-by: Alexander Graf <agraf@suse.de>
MPIC interrupt numbers in Linux (device tree) and in QEMU are different,
because QEMU takes the sparseness of the IRQ number space into account.
Remove that cleverness and instead assume a flat number space. This makes
the code easier to understand, because we are actually aligned with Linux
on the view of our worlds.
Signed-off-by: Alexander Graf <agraf@suse.de>
PCI Root complex have TYPE-1 configuration header while PCI endpoint
have type-0 configuration header. The type-1 configuration header have
a BAR (BAR0). In Freescale PCI controller BAR0 is used for mapping pci
address space to CCSR address space. This can used for 2 purposes: 1)
for MSI interrupt generation 2) Allow CCSR registers access when configured
as PCI endpoint, which I am not sure is a use case with QEMU-KVM guest.
What I observed is that when guest read the size of BAR0 of host controller
configuration header (TYPE1 header) then it always reads it as 0. When
looking into the QEMU hw/ppce500_pci.c, I do not find the PCI controller
device registering BAR0. I do not find any other controller also doing so
may they do not use BAR0.
There are two issues when BAR0 is not there (which I can think of):
1) There should be BAR0 emulated for PCI Root complex (TYPE1 header) and
when reading the size of BAR0, it should give size as per real h/w.
2) Do we need this BAR0 inbound address translation?
When BAR0 is of non-zero size then it will be configured for PCI
address space to local address(CCSR) space translation on inbound access.
The primary use case is for MSI interrupt generation. The device is
configured with an address offsets in PCI address space, which will be
translated to MSI interrupt generation MPIC registers. Currently I do
not understand the MSI interrupt generation mechanism in QEMU and also
IIRC we do not use QEMU MSI interrupt mechanism on e500 guest machines.
But this BAR0 will be used when using MSI on e500.
I can see one more issue, There are ATMUs emulated in hw/ppce500_pci.c,
but i do not see these being used for address translation.
So far that works because pci address space and local address space are 1:1
mapped. BAR0 inbound translation + ATMU translation will complete the address
translation of inbound traffic.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
[agraf: fix double variable assignment w/o read]
Signed-off-by: Alexander Graf <agraf@suse.de>
All devices are also placed under CCSR memory region.
The CCSR memory region is exported to pci device. The MSI interrupt
generation is the main reason to export the CCSR region to PCI device.
This put the requirement to move mpic under CCSR region, but logically
all devices should be under CCSR. So this patch places all emulated
devices under ccsr region.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The PAPR specification requires a certain amount of NVRAM, accessed via
RTAS, which we don't currently implement in qemu. This patch addresses
this deficiency, implementing the NVRAM as a VIO device, with some glue to
instantiate it automatically based on a machine option.
The machine option specifies a drive id, which is used to back the NVRAM,
making it persistent. If nothing is specified, the driver instead simply
allocates space for the NVRAM, which will not be persistent
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
accessible via MMIO. Do this mapping explicitly by mapping the PIO space
of our PCI bus into a memory region that lives in memory space.
Signed-off-by: Alexander Graf <agraf@suse.de>
At present, using 'system_powerdown' from the monitor or otherwise
instructing qemu to (cleanly) shut down a pseries guest will not work,
because we did not have a method of signalling the shutdown request to the
guest.
PAPR does include a usable mechanism for this, though it is rather more
involved than the equivalent on x86. This involves sending an EPOW
(Environmental and POwer Warning) event through the PAPR event and error
logging mechanism, which also has a number of other functions.
This patch implements just enough of the event/error logging functionality
to be able to send a shutdown event to the guest. At least with modern
guest kernels and a userspace that is up and running, this means that
system_powerdown from the qemu monitor should now work correctly on pseries
guests.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
it was wrongly using serial_hds[0] instead of serial_hds[1]
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific). Replace it with a finger-friendly,
standards conformant hwaddr.
Outstanding patchsets can be fixed up with the command
git rebase -i --exec 'find -name "*.[ch]"
| xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Split serial.c into serial.c, serial.h and serial-isa.c. While being at
creating a serial.h header file move the serial prototypes from pc.h to
the new serial.h. The latter leads to s/pc.h/serial.h/ in tons of
boards which just want the serial bits from pc.h
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should help us to:
- More easily add or remove machine initialization arguments without
having to change every single machine init function;
- More easily make mechanical changes involving the machine init
functions in the future;
- Let machine initialization forward the init arguments to other
functions more easily.
This change was half-mechanical process: first the struct was added with
the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
variable initialization to all functions. Then the compiler helped me
locate the local variables that are unused, so they could be removed.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
When booting our e500 machine, we automatically generate a big TLB entry
in TLB1 that covers all of the code we need to run in there until the guest
can handle its TLB on its own.
However, e500v2 can only handle MAS1.0 sizes. However, we keep our TLB
information in MAS2.0 layout, which means we have twice as many TLB sizes
to choose from. That also means we can run into a situation where we try
to add a TLB size that could not fit into the MAS1.0 size bits.
Fix it by making sure we always have the lower bit set to 0. That way we
are always guaranteed to have MAS1.0 compatible TLB size information.
Signed-off-by: Alexander Graf <agraf@suse.de>
While investigating dtb pad issues, I noticed that initrd_base wasn't taking
loadaddr into account the way dt_base was. This seems wrong.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
An allowance of 5 MiB for BSS is not enough for Linux kernels with certain
debug options enabled (not sure exactly which one caused it, but I'd guess
lockdep). The kernel I ran into this with had a BSS of around 6.4 MB.
Unfortunately, uImage does not give us enough information to determine the
actual BSS size. Increase the allowance to 18 MiB to give us plenty of
room. Eventually this should be more intelligent, possibly packing
initrd+dtb at the end of guest RAM.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This reverts commit 518c7fb44f. It breaks
new Linux guests with SMP, because IPIs get mapped to large vectors which
our MPIC emulation does not implement.
Conflicts:
hw/ppc/e500.c
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU, just to be able to
run KVM on new CPUs.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: conditionalize on CONFIG_FDT]
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently the only mpc8544ds-ism that is factored out is
toplevel compatible and model. In the future the generic e500
code is expected to become more generic.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: conditionalize on CONFIG_FDT]
Signed-off-by: Alexander Graf <agraf@suse.de>
No functional changes -- machine is still outwardly mpc8544ds.
The references that are not changed contain mpc8544 hardware details that
need to be parameterized if/when a different e500 platform wants to
change them.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Rename the file (with no changes other than fixing up the header paths)
in preparation for refactoring into a generic e500 platform. Also move
it into the newly created ppc/ directory.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
[agraf: conditionalize on CONFIG_FDT]
Signed-off-by: Alexander Graf <agraf@suse.de>
The pseries platform already contains an IOMMU implementation, since it is
essential for the platform's paravirtualized VIO devices. This IOMMU
support is currently built into the implementation of the VIO "bus" and
the various VIO devices.
This patch converts this code to make use of the new common IOMMU
infrastructure.
We don't yet handle synchronization of map/unmap callbacks vs. invalidations,
this will require some complex interaction with the kernel and is not a
major concern at this stage.
Cc: Alex Graf <agraf@suse.de>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now that we're moving all of the device tree generation from an external
pre-execution generated blob to runtime generation using libfdt, we absolutely
must have libfdt around.
This requirement was there before already, as the only way to not require libfdt
with e500 was to not use -kernel, which was the only way to boot the mpc8544ds
machine. This patch only manifests said requirement in the build system.
Signed-off-by: Alexander Graf <agraf@suse.de>
Speeds up the build.
xilinx_ethlite uses tswap32() and is thus target-dependent.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
The file is located in target-ppc/, not hw/.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
