| a5546222 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
apb: replace OBIO interrupt numbers in pci_pbmA_map_irq() with constants
Following on from the previous commit, we can also do the same with
with legacy OBIO interrupts in pci_pbmA_map_irq().
Signe
apb: replace OBIO interrupt numbers in pci_pbmA_map_irq() with constants
Following on from the previous commit, we can also do the same with
with legacy OBIO interrupts in pci_pbmA_map_irq().
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
| 4b10c8d7 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
ebus: wire up OBIO interrupts to APB pbm via qdev GPIOs
This enables us to remove the static array mapping in the ISA IRQ
handler (and the embedded reference to the APB device) by formalising
the in
ebus: wire up OBIO interrupts to APB pbm via qdev GPIOs
This enables us to remove the static array mapping in the ISA IRQ
handler (and the embedded reference to the APB device) by formalising
the interrupt wiring via the qdev GPIO API.
For more clarity we replace the APB OBIO interrupt numbers with constants
designating the interrupt source, and rename isa_irq_handler() to
ebus_isa_irq_handler().
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
| 33c5eb02 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
apb: remove busA property from PBMPCIBridge state
Since the previous commit the only remaining use of the qdev busA property is
to configure the PCI bridge in front of the onboard ebus devices diffe
apb: remove busA property from PBMPCIBridge state
Since the previous commit the only remaining use of the qdev busA property is
to configure the PCI bridge in front of the onboard ebus devices differently
to allow early OpenBIOS serial console access.
Instead we can now manually update the PCI configuration for bridge A in
pci_pbm_reset() and thus completely remove the busA property from the
PBMPCIBridge state.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
show more ...
|
| cacd0580 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
apb: remove pci_apb_init() and instantiate APB device using qdev
By making the special_base and mem_base values qdev properties, we can move
the remaining parts of pci_apb_init() into the pbm init()
apb: remove pci_apb_init() and instantiate APB device using qdev
By making the special_base and mem_base values qdev properties, we can move
the remaining parts of pci_apb_init() into the pbm init() and realize()
functions.
This finally allows us to instantiate the APB directly using standard qdev
create/init functions in sun4u.c.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
| 4272ad40 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
apb: move the two secondary PCI bridges objects into APBState
This enables us to remove these parameters from pci_apb_init().
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewe
apb: move the two secondary PCI bridges objects into APBState
This enables us to remove these parameters from pci_apb_init().
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
| 588978c0 | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
apb: return APBState from pci_apb_init() rather than PCIBus
This is a first step towards removing pci_apb_init() completely.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed
apb: return APBState from pci_apb_init() rather than PCIBus
This is a first step towards removing pci_apb_init() completely.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
show more ...
|
| c796edda | 21-Dec-2017 |
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
sun4u: remove pci_ebus_init() function
This is initialisation that should really take place in the ebus realize
function. As part of this we also rework the ebus IRQ mapping so that
instead of havin
sun4u: remove pci_ebus_init() function
This is initialisation that should really take place in the ebus realize
function. As part of this we also rework the ebus IRQ mapping so that
instead of having to pass in the array of pbm_irqs, we obtain a reference
to them by looking up the APB device during ebus realize.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
show more ...
|
| 357d1e3b | 15-Oct-2016 |
David Gibson <david@gibson.dropbear.id.au> |
spapr: Improved placement of PCI host bridges in guest memory map
Currently, the MMIO space for accessing PCI on pseries guests begins at
1 TiB in guest address space. Each PCI host bridge (PHB) ha
spapr: Improved placement of PCI host bridges in guest memory map
Currently, the MMIO space for accessing PCI on pseries guests begins at
1 TiB in guest address space. Each PCI host bridge (PHB) has a 64 GiB
chunk of address space in which it places its outbound PIO and 32-bit and
64-bit MMIO windows.
This scheme as several problems:
- It limits guest RAM to 1 TiB (though we have a limited fix for this
now)
- It limits the total MMIO window to 64 GiB. This is not always enough
for some of the large nVidia GPGPU cards
- Putting all the windows into a single 64 GiB area means that naturally
aligning things within there will waste more address space.
In addition there was a miscalculation in some of the defaults, which meant
that the MMIO windows for each PHB actually slightly overran the 64 GiB
region for that PHB. We got away without nasty consequences because
the overrun fit within an unused area at the beginning of the next PHB's
region, but it's not pretty.
This patch implements a new scheme which addresses those problems, and is
also closer to what bare metal hardware and pHyp guests generally use.
Because some guest versions (including most current distro kernels) can't
access PCI MMIO above 64 TiB, we put all the PCI windows between 32 TiB and
64 TiB. This is broken into 1 TiB chunks. The first 1 TiB contains the
PIO (64 kiB) and 32-bit MMIO (2 GiB) windows for all of the PHBs. Each
subsequent TiB chunk contains a naturally aligned 64-bit MMIO window for
one PHB each.
This reduces the number of allowed PHBs (without full manual configuration
of all the windows) from 256 to 31, but this should still be plenty in
practice.
We also change some of the default window sizes for manually configured
PHBs to saner values.
Finally we adjust some tests and libqos so that it correctly uses the new
default locations. Ideally it would parse the device tree given to the
guest, but that's a more complex problem for another time.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
show more ...
|
| daa23699 | 10-Oct-2016 |
David Gibson <david@gibson.dropbear.id.au> |
spapr_pci: Add a 64-bit MMIO window
On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to P
spapr_pci: Add a 64-bit MMIO window
On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to PCI memory space:
- A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
- A 64-bit window which maps onto a large region somewhere high in PCI
address space (traditionally this used an identity mapping from guest
physical address to PCI address, but that's not always the case)
The qemu implementation in spapr-pci-host-bridge, however, only supports a
single outbound MMIO window, however. At least some Linux versions expect
the two windows however, so we arranged this window to map onto the PCI
memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
windows, the "32-bit" window from 2G..4G and the "64-bit" window from
4G..~64G.
This approach means, however, that the 64G window is not naturally aligned.
In turn this limits the size of the largest BAR we can map (which does have
to be naturally aligned) to roughly half of the total window. With some
large nVidia GPGPU cards which have huge memory BARs, this is starting to
be a problem.
This patch adds true support for separate 32-bit and 64-bit outbound MMIO
windows to the spapr-pci-host-bridge implementation, each of which can
be independently configured. The 32-bit window always maps to 2G.. in PCI
space, but the PCI address of the 64-bit window can be configured (it
defaults to the same as the guest physical address).
So as not to break possible existing configurations, as long as a 64-bit
window is not specified, a large single window can be specified. This
will appear the same way to the guest as the old approach, although it's
now implemented by two contiguous memory regions rather than a single one.
For now, this only adds the possibility of 64-bit windows. The default
configuration still uses the legacy mode.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
show more ...
|