riscv/qemu - qemu - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Marc-André Lureau	907b5105f1	tests: move libqtest.h back under qtest/ Since commit `a2ce7dbd91` ("meson: convert tests/qtest to meson"), libqtest.h is under libqos/ directory, while libqtest.c is still in qtest/. Move back to its original location to avoid mixing with libqos/. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>	4 years ago
Paolo Bonzini	a2ce7dbd91	meson: convert tests/qtest to meson Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	6 years ago
Thomas Huth	1cf4323ecd	tests/libqos: Move the libqos files under tests/qtest/ The qos stuff belongs to qtest, so move it into that directory, too. Message-Id: <20191218103059.11729-8-thuth@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	7 years ago
Markus Armbruster	0b8fa32f55	Include qemu/module.h where needed, drop it from qemu-common.h Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]	7 years ago
Jafar Abdi	c098aac7dc	tests/libqos: fix usage of bool in pci-spapr.c Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. FALSE and TRUE (with capital letters) are the constants defined by glib for being used with the "gboolean" type of glib. But some parts of the code also use TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). Signed-off-by: Jafar Abdi <cafer.abdi@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1553351197-14581-4-git-send-email-cafer.abdi@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	7 years ago
Emanuele Giuseppe Esposito	92bbafc718	tests/libqos: has_buggy_msi flag The Qgraph framework makes any test using pci bus run the same function using pci-pci and pci-spapr bus. However, some tests are not ready to use the spapr bus, due to a MSI bug. Until it does not get fixed, this flag allows them to skip the test Signed-off-by: Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	8 years ago
Emanuele Giuseppe Esposito	b8782d2a47	tests/libqos: pci-spapr driver and interface nodes Add pci-bus-spapr node, that produces pci-bus. Move QPCIBusSPAPR struct declaration in its header (since it will be needed by other drivers) and introduce a setter method for drivers that do not need to allocate but have to initialize QPCIBusSPAPR. Signed-off-by: Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	8 years ago
Emanuele Giuseppe Esposito	143e6db6fa	tests/libqos: rename qpci_init_pc and qpci_init_spapr functions Rename qpci_init_pc in qpci_pc_new and qpci_init_spapr in qpci_spapr_new, since these function actually allocate a new pci struct and initialize it (compare to object_new and object_initialize). Changed QOSOps field name from qpci_init to qpci_new. Signed-off-by: Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	8 years ago
Thomas Huth	d786f78252	tests/libqos/pci: Make PCI access functions independent of global_qtest QPCIBus already tracks QTestState, so use that state instead of an implicit reliance on global_qtest. Based on an earlier patch ("libqos: Use explicit QTestState for pci operations") from Eric Blake. Signed-off-by: Thomas Huth <thuth@redhat.com>	8 years ago
Eric Blake	9b67af76db	libqos: Use explicit QTestState for rtas operations Drop one more client of global_qtest by teaching all rtas test functionality to pass in an explicit QTestState, adjusting all callers. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Use nicer indentation in rtas.h] Signed-off-by: Thomas Huth <thuth@redhat.com>	9 years ago
Eric Blake	e5d1730d1e	libqos: Track QTestState with QPCIBus When initializing a QPCIBus, track which QTestState the bus is associated with (so that a later patch can then explicitly use that test state for all communication on the bus, rather than blindly relying on global_qtest). Update the initialization functions to take another parameter, and update all callers to pass in state (for now, most callers get away with passing the current global_qtest as the current state, although this required fixing the order of initialization to ensure qtest_start() is called before qpci_init*() in rtl8139-test, and provided an opportunity to pass in the allocator in e1000e-test). Touch up some allocations to use g_new0() rather than g_malloc() while in the area, and simplify some code (all implementations of QOSOps provide a .init_allocator() that never fails). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Removed hunk from vhost-user-test.c that is not required anymore, fixed conflict in qtest_vboot() and adjusted qpci_init_pc() in sdhci-test] Signed-off-by: Thomas Huth <thuth@redhat.com>	9 years ago
Laurent Vivier	b84541693b	libqos: fix spapr qpci_map() Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>	9 years ago
David Gibson	f775f45ab8	libqos: Add 64-bit PCI IO accessors Currently the libqos PCI layer includes accessor helpers for 8, 16 and 32 bit reads and writes. It's likely that we'll want 64-bit accesses in the future (plenty of modern peripherals will have 64-bit reigsters). This adds them. For PIO (not MMIO) accesses on the PC backend, this is implemented as two 32-bit ins or outs. That's not ideal but AFAICT x86 doesn't have 64-bit versions of in and out. This patch also converts the single current user of 64-bit accesses - virtio-pci.c to use the new mechanism, rather than a sequence of 8 byte reads. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>	10 years ago
David Gibson	352d664cce	libqos: Implement mmio accessors in terms of mem{read,write} In the libqos PCI code we now have accessors both for registers (byte significance preserving) and for streaming data (byte address order preserving). These exist in both the interface for qtest drivers and in the machine specific backends. However, the register-style accessors aren't actually necessary in the backend. They can be implemented in terms of the byte address order preserving accessors by the libqos wrappers. This works because PCI is always little endian. This does assume that the back end byte address order preserving accessors will perform the equivalent of a single bus transaction for short lengths. This is the case, and in fact they currently end up using the same cpu_physical_memory_rw() implementation within the qtest accelerator. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>	10 years ago
David Gibson	9a84f88947	libqos: Add streaming accessors for PCI MMIO Currently PCI memory (aka MMIO) space is accessed via a set of readb/writeb style accessors. This is what we want for accessing discrete registers of a certain size. However, there are a few cases where we instead need a "bag of bytes" style streaming interface to PCI MMIO space. This can be either for streaming data style registers or when there's actual memory rather than registers in PCI space, for example frame buffers or ivshmem. This patch adds backend callbacks, and libqos wrappers for this type of byte address order preserving accesses. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>	10 years ago
David Gibson	b8cc4d0231	libqos: Move BAR assignment to common code The PCI backends in libqos each supply an iomap() and iounmap() function which is used to set up a specified PCI BAR. But PCI BAR allocation takes place entirely within PCI space, so doesn't really need per-backend versions. For example, Linux includes generic BAR allocation code used on platforms where that isn't done by firmware. This patch merges the BAR allocation from the two existing backends into a single simplified copy. The back ends just need to set up some parameters describing the window of PCI IO and PCI memory addresses which are available for allocation. Like both the existing versions the new one uses a simple bump allocator. Note that (again like the existing versions) this doesn't really handle 64-bit memory BARs properly. It is actually used for such a BAR by the ivshmem test, and apparently the 32-bit MMIO BAR logic is close enough to work, as long as the BAR isn't too big. Fixing that to properly handle 64-bit BAR allocation is a problem for another time. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>	10 years ago
David Gibson	a795fc08f2	libqos: Handle PCI IO de-multiplexing in common code The PCI IO space (aka PIO, aka legacy IO) and PCI memory space (aka MMIO) are distinct address spaces by the PCI spec (although parts of one might be aliased to parts of the other in some cases). However, qpci_io_read() and qpci_io_write() can perform accesses to either space depending on parameter. That's convenient for test case drivers, since there are a fair few devices which can be controlled via either a PIO or MMIO BAR but with an otherwise identical driver. This is implemented by having addresses below 64kiB treated as PIO, and those above treated as MMIO. This works because low addresses in memory space are generally reserved for DMA rather than MMIO. At the moment, this demultiplexing must be handled by each PCI backend (pc and spapr, so far). There's no real reason for this - the current encoding is likely to work for all platforms, and even if it doesn't we can still use a more complex common encoding since the value returned from iomap are semi-opaque. This patch moves the demultiplexing into the common part of the libqos PCI code, with the backends having simpler, separate accessors for PIO and MMIO space. This also means we have a way of explicitly accessing either space if it's necessary for some special case. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>	10 years ago
David Gibson	357d1e3bc7	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>	10 years ago
David Gibson	8360544a6d	libqos: Limit spapr-pci to 32-bit MMIO for now Currently the functions in pci-spapr.c (like pci-pc.c on which it's based) don't distinguish between 32-bit and 64-bit PCI MMIO. At the moment, the qemu side implementation is a bit weird and has a single MMIO window straddling 32-bit and 64-bit regions, but we're likely to change that in future. In any case, pci-pc.c - and therefore the testcases using PCI - only handle 32-bit MMIOs for now. For spapr despite whatever changes might happen with the MMIO windows, the 32-bit window is likely to remain at 2..4 GiB in PCI space. So, explicitly limit pci-spapr.c to 32-bit MMIOs for now, we can add 64-bit MMIO support back in when and if we need it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>	10 years ago
David Gibson	c711369087	libqos: Correct error in PCI hole sizing for spapr In pci-spapr.c (as in pci-pc.c from which it was derived), the pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1] essentially define the region of PCI (not CPU) addresses in which MMIO or PIO BARs respectively will be allocated. The size value is relative to the start value. But in pci-spapr.c it is set to the entire size of the window supported by the (emulated) hardware, but the start values are not at the beginning of the emulated windows. That means if you tried to map enough PCI BARs, we'd messily overrun the IO windows, instead of failing in iomap as we should. This patch corrects this by calculating the hole sizes from the location of the window in PCI space and the hole start. [1] Those are bad names, but that's a problem for another time. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>	10 years ago
David Gibson	cd1b354ec0	libqos: Isolate knowledge of spapr memory map to qpci_init_spapr() The libqos code for accessing PCI on the spapr machine type uses IOBASE() and MMIOBASE() macros to determine the address in the CPU memory map of the windows to PCI address space. This is a detail of the implementation of PCI in the machine type, it's not specified by the PAPR standard. Real guests would get the addresses of the PCI windows from the device tree. Finding the device tree in libqos would be awkward, but we can at least localize this knowledge of the implementation to the init function, saving it in the QPCIBusSPAPR structure for use by the accessors. That leaves only one place to fix if we alter the location of the PCI windows, as we're planning to do. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>	10 years ago
Laurent Vivier	cf716b31cb	libqos: add PPC64 PCI support Signed-off-by: Laurent Vivier <lvivier@redhat.com> [dwg: Fixed build problem on 32-bit hosts] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>	10 years ago

3 Commits (907b5105f1b9e1af1abbdbb4f2039c7ab105c001)