aboutsummaryrefslogtreecommitdiff
path: root/hw/i386
AgeCommit message (Collapse)AuthorFilesLines
2022-09-27x86: use typedef for SetupData structJason A. Donenfeld1-7/+7
The preferred style is SetupData as a typedef, not setup_data as a plain struct. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20220921093134.2936487-2-Jason@zx2c4.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-27x86: return modified setup_data only if read as memory, not as fileJason A. Donenfeld1-10/+36
If setup_data is being read into a specific memory location, then generally the setup_data address parameter is read first, so that the caller knows where to read it into. In that case, we should return setup_data containing the absolute addresses that are hard coded and determined a priori. This is the case when kernels are loaded by BIOS, for example. In contrast, when setup_data is read as a file, then we shouldn't modify setup_data, since the absolute address will be wrong by definition. This is the case when OVMF loads the image. This allows setup_data to be used like normal, without crashing when EFI tries to use it. (As a small development note, strangely, fw_cfg_add_file_callback() was exported but fw_cfg_add_bytes_callback() wasn't, so this makes that consistent.) Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laurent Vivier <laurent@vivier.eu> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Richard Henderson <richard.henderson@linaro.org> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20220921093134.2936487-1-Jason@zx2c4.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22hw/i386/multiboot: Avoid dynamic stack allocationPhilippe Mathieu-Daudé1-3/+2
Use autofree heap allocation instead of variable-length array on the stack. Replace the snprintf() call by g_strdup_printf(). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20220819153931.3147384-9-peter.maydell@linaro.org
2022-09-02util: accept iova_tree_remove_parameter by valueEugenio Pérez1-3/+3
It's convenient to call iova_tree_remove from a map returned from iova_tree_find or iova_tree_find_iova. With the current code this is not possible, since we will free it, and then we will try to search for it again. Fix it making accepting the map by value, forcing a copy of the argument. Not applying a fixes tag, since there is no use like that at the moment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-08-25hw: Add compat machines for 7.2Cornelia Huck3-2/+28
Add 7.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20220727121755.395894-1-cohuck@redhat.com> [thuth: fixed conflict with pcmc->legacy_no_rng_seed] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-08-17x86: disable rng seeding via setup_dataGerd Hoffmann3-3/+3
Causes regressions when doing direct kernel boots with OVMF. At this point in the release cycle the only sensible action is to just disable this for 7.1 and sort it properly in the 7.2 devel cycle. Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220817083940.3174933-1-kraxel@redhat.com> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-07-26i386/pc: restrict AMD only enforcing of 1Tb hole to new machine typeJoao Martins3-2/+6
The added enforcing is only relevant in the case of AMD where the range right before the 1TB is restricted and cannot be DMA mapped by the kernel consequently leading to IOMMU INVALID_DEVICE_REQUEST or possibly other kinds of IOMMU events in the AMD IOMMU. Although, there's a case where it may make sense to disable the IOVA relocation/validation when migrating from a non-amd-1tb-aware qemu to one that supports it. Relocating RAM regions to after the 1Tb hole has consequences for guest ABI because we are changing the memory mapping, so make sure that only new machine enforce but not older ones. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-12-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: relocate 4g start to 1T where applicableJoao Martins1-0/+54
It is assumed that the whole GPA space is available to be DMA addressable, within a given address space limit, except for a tiny region before the 4G. Since Linux v5.4, VFIO validates whether the selected GPA is indeed valid i.e. not reserved by IOMMU on behalf of some specific devices or platform-defined restrictions, and thus failing the ioctl(VFIO_DMA_MAP) with -EINVAL. AMD systems with an IOMMU are examples of such platforms and particularly may only have these ranges as allowed: 0000000000000000 - 00000000fedfffff (0 .. 3.982G) 00000000fef00000 - 000000fcffffffff (3.983G .. 1011.9G) 0000010000000000 - ffffffffffffffff (1Tb .. 16Pb[*]) We already account for the 4G hole, albeit if the guest is big enough we will fail to allocate a guest with >1010G due to the ~12G hole at the 1Tb boundary, reserved for HyperTransport (HT). [*] there is another reserved region unrelated to HT that exists in the 256T boundary in Fam 17h according to Errata #1286, documeted also in "Open-Source Register Reference for AMD Family 17h Processors (PUB)" When creating the region above 4G, take into account that on AMD platforms the HyperTransport range is reserved and hence it cannot be used either as GPAs. On those cases rather than establishing the start of ram-above-4g to be 4G, relocate instead to 1Tb. See AMD IOMMU spec, section 2.1.2 "IOMMU Logical Topology", for more information on the underlying restriction of IOVAs. After accounting for the 1Tb hole on AMD hosts, mtree should look like: 0000000000000000-000000007fffffff (prio 0, i/o): alias ram-below-4g @pc.ram 0000000000000000-000000007fffffff 0000010000000000-000001ff7fffffff (prio 0, i/o): alias ram-above-4g @pc.ram 0000000080000000-000000ffffffffff If the relocation is done or the address space covers it, we also add the the reserved HT e820 range as reserved. Default phys-bits on Qemu is TCG_PHYS_ADDR_BITS (40) which is enough to address 1Tb (0xff ffff ffff). On AMD platforms, if a ram-above-4g relocation is attempted and the CPU wasn't configured with a big enough phys-bits, an error message will be printed due to the maxphysaddr vs maxusedaddr check previously added. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-11-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: bounds check phys-bits against max used GPAJoao Martins1-0/+27
Calculate max *used* GPA against the CPU maximum possible address and error out if the former surprasses the latter. This ensures max used GPA is reacheable by configured phys-bits. Default phys-bits on Qemu is TCG_PHYS_ADDR_BITS (40) which is enough for the CPU to address 1Tb (0xff ffff ffff) or 1010G (0xfc ffff ffff) in AMD hosts with IOMMU. This is preparation for AMD guests with >1010G, where it will want relocate ram-above-4g to be after 1Tb instead of 4G. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-10-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: factor out device_memory base/size to helperJoao Martins1-15/+31
Move obtaining hole64_start from device_memory memory region base/size into an helper alongside correspondent getters in pc_memory_init() when the hotplug range is unitialized. While doing that remove the memory region based logic from this newly added helper. This is the final step that allows pc_pci_hole64_start() to be callable at the beginning of pc_memory_init() before any memory regions are initialized. Cc: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-9-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: handle unitialized mr in pc_get_cxl_range_end()Joao Martins1-10/+8
Remove pc_get_cxl_range_end() dependency on the CXL memory region, and replace with one that does not require the CXL host_mr to determine the start of CXL start. This in preparation to allow pc_pci_hole64_start() to be called early in pc_memory_init(), handle CXL memory region end when its underlying memory region isn't yet initialized. Cc: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Message-Id: <20220719170014.27028-8-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com>
2022-07-26i386/pc: factor out cxl range start to helperJoao Martins1-7/+17
Factor out the calculation of the base address of the memory region. It will be used later on for the cxl range end counterpart calculation and as well in pc_memory_init() CXL memory region initialization, thus avoiding duplication. Cc: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-7-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: factor out cxl range end to helperJoao Martins1-10/+21
Move calculation of CXL memory region end to separate helper. This is in preparation to a future change that removes CXL range dependency on the CXL memory region, with the goal of allowing pc_pci_hole64_start() to be called before any memory region are initialized. Cc: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-6-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: factor out above-4g end to an helperJoao Martins1-15/+14
There's a couple of places that seem to duplicate this calculation of RAM size above the 4G boundary. Move all those to a helper function. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-5-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: pass pci_hole64_size to pc_memory_init()Joao Martins3-3/+17
Use the pre-initialized pci-host qdev and fetch the pci-hole64-size into pc_memory_init() newly added argument. Use PCI_HOST_PROP_PCI_HOLE64_SIZE pci-host property for fetching pci-hole64-size. This is in preparation to determine that host-phys-bits are enough and for pci-hole64-size to be considered to relocate ram-above-4g to be at 1T (on AMD platforms). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-4-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: create pci-host qdev prior to pc_memory_init()Joao Martins2-5/+8
At the start of pc_memory_init() we usually pass a range of 0..UINT64_MAX as pci_memory, when really its 2G (i440fx) or 32G (q35). To get the real user value, we need to get pci-host passed property for default pci_hole64_size. Thus to get that, create the qdev prior to memory init to better make estimations on max used/phys addr. This is in preparation to determine that host-phys-bits are enough and also for pci-hole64-size to be considered to relocate ram-above-4g to be at 1T (on AMD platforms). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-3-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26hw/i386: add 4g boundary start to X86MachineStateJoao Martins4-7/+9
Rather than hardcoding the 4G boundary everywhere, introduce a X86MachineState field @above_4g_mem_start and use it accordingly. This is in preparation for relocating ram-above-4g to be dynamically start at 1T on AMD platforms. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-2-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26hw/i386/pc: Always place CXL Memory Regions after device_memoryJonathan Cameron1-4/+2
Previously broken_reserved_end was taken into account, but Igor Mammedov identified that this could lead to a clash between potential RAM being mapped in the region and CXL usage. Hence always add the size of the device_memory memory region. This only affects the case where the broken_reserved_end flag was set. Fixes: 6e4e3ae936e6 ("hw/cxl/component: Implement host bridge MMIO (8.2.5, table 142)") Reported-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20220701132300.2264-3-Jonathan.Cameron@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-22hw/i386: pass RNG seed via setup_data entryJason A. Donenfeld5-7/+29
Tiny machines optimized for fast boot time generally don't use EFI, which means a random seed has to be supplied some other way. For this purpose, Linux (≥5.20) supports passing a seed in the setup_data table with SETUP_RNG_SEED, specially intended for hypervisors, kexec, and specialized bootloaders. The linked commit shows the upstream kernel implementation. At Paolo's request, we don't pass these to versioned machine types ≤7.0. Link: https://git.kernel.org/tip/tip/c/68b8e9713c8 Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20220721125636.446842-1-Jason@zx2c4.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-07-19microvm: turn off io reservations for pcie root portsGerd Hoffmann1-0/+11
The pcie host bridge has no io window on microvm, so io reservations will not work. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220701091516.43489-1-kraxel@redhat.com>
2022-06-29hw/i386/xen/xen-hvm: Inline xen_piix_pci_write_config_client() and remove itBernhard Beschow1-18/+0
xen_piix_pci_write_config_client() is implemented in the xen sub tree and uses PIIX constants internally, thus creating a direct dependency on PIIX. Now that xen_set_pci_link_route() is stubbable, the logic of xen_piix_pci_write_config_client() can be moved to PIIX which resolves the dependency. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20220626094656.15673-3-shentey@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-29hw/i386/xen/xen-hvm: Allow for stubbing xen_set_pci_link_route()Bernhard Beschow1-1/+6
The only user of xen_set_pci_link_route() is xen_piix_pci_write_config_client() which implements PIIX-specific logic in the xen namespace. This makes xen-hvm depend on PIIX which could be avoided if xen_piix_pci_write_config_client() was implemented in PIIX. In order to do this, xen_set_pci_link_route() needs to be stubbable which this patch addresses. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20220626094656.15673-2-shentey@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-28hw/pci-host/i440fx: Remove unused parameter from i440fx_init()Bernhard Beschow1-3/+0
pi440fx_state is an out-parameter which is never read by the caller. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220612192800.40813-1-shentey@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-11hw/i386/pc: Unexport functions used only internallyBernhard Beschow1-2/+2
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220520180109.8224-5-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/i386/pc: Unexport PC_CPU_MODEL_IDS macroBernhard Beschow1-0/+9
The macro seems to be used only internally, so remove it. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220520180109.8224-4-shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw: Reuse TYPE_I8042 defineBernhard Beschow1-2/+2
TYPE_I8042 is exported, so reuse it for consistency. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220520180109.8224-2-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/rtc/mc146818rtc: QOM'ify io_base offsetBernhard Beschow1-1/+1
Exposing the io_base offset as a QOM property not only allows it to be configurable but also to be displayed in HMP: Before: (qemu) info qtree ... dev: mc146818rtc, id "" gpio-out "" 1 base_year = 0 (0x0) irq = 8 (0x8) lost_tick_policy = "discard" After: dev: mc146818rtc, id "" gpio-out "" 1 base_year = 0 (0x0) iobase = 112 (0x70) irq = 8 (0x8) lost_tick_policy = "discard" Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220529184006.10712-4-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/i386/microvm-dt: Determine mc146818rtc's IRQ number from QOM propertyBernhard Beschow1-1/+1
Since commit 3b004a16540aa41f2aa6a1ceb0bf306716766914 'hw/rtc/ mc146818rtc: QOM'ify IRQ number' mc146818rtc's IRQ number is configurable. Fix microvm-dt to respect its value. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220529184006.10712-3-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/i386/microvm-dt: Force explicit failure if retrieving QOM property failsBernhard Beschow1-2/+3
New code will be added where this is best practice. So update existing code as well. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220529184006.10712-2-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/isa/piix3: Inline and remove piix3_create()Bernhard Beschow1-1/+5
During the previous changesets piix3_create() became a trivial wrapper around more generic functions. Modernize the code. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220603185045.143789-12-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/isa/piix3: Factor out ISABus retrieval from piix3_create()Bernhard Beschow1-1/+2
Modernizes the code. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220603185045.143789-11-shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/i386/pc_piix: create PIIX4_PM device directly instead of using ↵Mark Cave-Ayland1-3/+8
piix4_pm_initfn() Now that all external logic has been removed from piix4_pm_initfn() the PIIX4_PM device can be instantiated directly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-11-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: use qdev gpio to wire up smi_irqMark Cave-Ayland1-1/+2
Initialize the SMI IRQ in piix4_pm_init(). The smi_irq can now be wired up directly using a qdev gpio instead of having to set the IRQ externally in piix4_pm_initfn(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-10-mark.cave-ayland@ilande.co.uk> [PMD: Partially squash 20220528091934.15520-8-mark.cave-ayland@ilande.co.uk] Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: use qdev gpio to wire up sci_irqMark Cave-Ayland1-2/+2
Introduce piix4_pm_init() instance init function and use it to initialise the separate qdev gpio for the SCI IRQ. The sci_irq can now be wired up directly using a qdev gpio instead of having to set the IRQ externally in piix4_pm_initfn(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-9-mark.cave-ayland@ilande.co.uk> [PMD: Partially squash 20220528091934.15520-8-mark.cave-ayland@ilande.co.uk] Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: rename piix4_pm_init() to piix4_pm_initfn()Mark Cave-Ayland1-3/+3
When QOMifying a device it is typical to use _init() as the suffix for an instance_init function, however this name is already in use by the legacy piix4_pm_init() wrapper function. Eventually the wrapper function will be removed, but for now rename it to piix4_pm_initfn() to avoid a naming collision. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-7-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: alter piix4_pm_init() to return PIIX4PMStateMark Cave-Ayland1-5/+5
This exposes the PIIX4_PM device to the caller to allow any qdev gpios to be mapped outside of piix4_pm_init(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-6-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: move PIIX4PMState into separate piix4.h headerMark Cave-Ayland1-0/+1
This allows the QOM types in hw/acpi/piix4.c to be used elsewhere by simply including hw/acpi/piix4.h. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-5-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-10Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson4-151/+61
into staging virtio,pc,pci: fixes,cleanups,features more CXL patches VIOT Igor's huge AML rework fixes, cleanups all over the place Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmKj4YcPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRpkNcIAKTsMfUVueTjelC2RwIdegQkypycKhCweKzc # QxddaEr0w+N2164byT3IUy9h53hV3qAAmMuGE4d8B2r5rykf+SwDfIeNmHNqntnA # oLraXIxSSAf4/1cTsRCVL/BXo2E9P+WHI3huw37HClmPLdyMjQa1AtpTpKnIsbmO # sBZf7t5yHDJ2WGZwBQ1IbAxvsdGo1fa1TCt1jZ9g1dmnQSTteQG8DHkGoRnkwTi7 # 510jb0e8uQEgKytCdLTHqESHlfgjvoI73OFOAR2dzTKy6KelFmdLYSo2FtsIdtT5 # 1fZNaDjtl6zQ4b2iLBgPpHtikKch9BzzhDMbCsq7FpvasZ8u2FE= # =LXG0 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 10 Jun 2022 05:27:51 PM PDT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (53 commits) hw/vhost-user-scsi|blk: set `supports_config` flag correctly hw/virtio/vhost-user: don't use uninitialized variable tests/acpi: virt: update golden masters for VIOT hw/acpi/viot: sort VIOT ACPI table entries by PCI host bridge min_bus tests/acpi: virt: allow VIOT acpi table changes hw/acpi/viot: build array of PCI host bridges before generating VIOT ACPI table hw/acpi/viot: move the individual PCI host bridge entry generation to a new function hw/acpi/viot: rename build_pci_range_node() to enumerate_pci_host_bridges() hw/cxl: Fix missing write mask for HDM decoder target list registers pci: fix overflow in snprintf string formatting hw/machine: Drop cxl_supported flag as no longer useful hw/cxl: Move the CXLState from MachineState to machine type specific state. tests/acpi: Update q35/CEDT.cxl for new memory addresses. pci/pci_expander_bridge: For CXL HB delay the HB register memory region setup. tests/acpi: Allow modification of q35 CXL CEDT table. hw/cxl: Push linking of CXL targets into i386/pc rather than in machine.c hw/acpi/cxl: Pass in the CXLState directly rather than MachineState hw/cxl: Make the CXL fixed memory window setup a machine parameter. x86: acpi-build: do not include hw/isa/isa.h directly tests: acpi: update expected DSDT.tis.tpm2/DSDT.tis.tpm12 blobs ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-06-09hw/machine: Drop cxl_supported flag as no longer usefulJonathan Cameron1-1/+0
As all the CXL elements have moved to boards that support CXL, there is no need to maintain a top level flag. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Message-Id: <20220608145440.26106-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09hw/cxl: Move the CXLState from MachineState to machine type specific state.Jonathan Cameron2-20/+19
This removes the last of the CXL code from the MachineState where it is visible to all Machines to only those that support CXL (currently i386/pc) As i386/pc always support CXL now, stop allocating the state independently. Note the pxb register hookup code runs even if cxl=off in order to detect pxb_cxl host bridges and fail to start if any are present as they won't have the control registers available. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Message-Id: <20220608145440.26106-8-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09pci/pci_expander_bridge: For CXL HB delay the HB register memory region setup.Jonathan Cameron1-0/+3
As the CXLState will no long be accessible via MachineState at time of PXB_CXL realization, come back later from the machine specific code to fill in the missing memory region setup. Only at this stage is it possible to check if cxl=on, so that check is moved to this later point. Note that for multiple host bridges, the allocation order of the register spaces is changed. This will be reflected in ACPI CEDT. Stubs are added to handle case of CONFIG_PXB=n for machines that call these functions. The bus walking logic is common to all machines so add a utility function + stub to cxl-host*. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Message-Id: <20220608145440.26106-6-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09hw/cxl: Push linking of CXL targets into i386/pc rather than in machine.cJonathan Cameron1-0/+5
Whilst here take the oportunity to shorten the function name. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Message-Id: <20220608145440.26106-4-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09hw/acpi/cxl: Pass in the CXLState directly rather than MachineStateJonathan Cameron1-2/+2
Refactoring step on path to moving all CXL state out of MachineState. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Message-Id: <20220608145440.26106-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09hw/cxl: Make the CXL fixed memory window setup a machine parameter.Jonathan Cameron1-0/+3
Paolo Bonzini requested this change to simplify the ongoing effort to allow machine setup entirely via RPC. Includes shortening the command line form cxl-fixed-memory-window to cxl-fmw as the command lines are extremely long even with this change. The json change is needed to ensure that there is a CXLFixedMemoryWindowOptionsList even though the actual element in the json is never used. Similar to existing SgxEpcProperties. Update qemu-options.hx to reflect that this is now a -machine parameter. The bulk of -M / -machine parameters are documented under machine, so use that in preference to M. Update cxl-test and bios-tables-test to reflect new parameters. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Message-Id: <20220608145440.26106-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09x86: acpi-build: do not include hw/isa/isa.h directlyIgor Mammedov1-1/+0
the last remaining dependency on ISA in acpi-build.c is iapc_boot_arch_8042() which pulls in in isa.h in its own header hw/input/i8042.h. Clean up not longer needed direct inclusion of isa.h in acpi-build.c Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-36-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09acpi: tpm-tis: use AcpiDevAmlIfClass:build_dev_aml to provide device's AMLIgor Mammedov1-34/+0
.. and clean up not longer needed conditionals in DSTD build code tpm-tis AML will be fetched and included when ISA bridge will build its own AML code (including attached devices). Expected AML change: the device under separate _SB.PCI0.ISA scope is moved directly under Device(ISA) node. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-34-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09acpi: pc/q35: remove not needed 'if' condition on pci busIgor Mammedov1-8/+2
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-33-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09acpi: pc/q35: tpm-tis: fix TPM device scopeIgor Mammedov1-2/+1
tpm-tis 2.0, is not a PCI device but ISA one, move it under ISA scope to fix incorrect placement. Fixes: 24cf5413aa0 (acpi: Make TPM 2.0 with TIS available as MSFT0101) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-32-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09acpi: pvpanic-isa: use AcpiDevAmlIfClass:build_dev_aml to provide device's AMLIgor Mammedov1-37/+0
.. and clean up not longer needed conditionals in DSTD build code pvpanic-isa AML will be fetched and included when ISA bridge will build its own AML code (including attached devices). Expected AML change: the device under separate _SB.PCI0.ISA scope is moved directly under Device(ISA) node. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-29-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-09acpi: applesmc: use AcpiDevAmlIfClass:build_dev_aml to provide device's AMLIgor Mammedov1-22/+0
.. and clean up not longer needed conditionals in DSTD build code. applesmc AML will be fetched and included when ISA bridge will build its own AML code (incl. attached devices). Expected AML change: the device under separate _SB.PCI0.ISA scope is moved directly under Device(ISA) node. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20220608135340.3304695-25-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2025-01-01 15:40:40 +0000