aboutsummaryrefslogtreecommitdiff
path: root/hw/i386
AgeCommit message (Collapse)AuthorFilesLines
2023-07-12hw/i386/acpi-build: Rely on machine->device_memory when building SRATDavid Hildenbrand1-6/+3
We're already looking at machine->device_memory when calling build_srat_memory(), so let's simply avoid going via PC_MACHINE_DEVMEM_REGION_SIZE to get the size and rely on machine->device_memory directly. Once machine->device_memory is set, we know that the size > 0. The code now looks much more similar the hw/arm/virt-acpi-build.c variant. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230623124553.400585-8-david@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12hw/i386/pc: Use machine_memory_devices_init()David Hildenbrand1-12/+5
Let's use our new helper and stop always allocating ms->device_memory. Once allcoated, we're sure that the size > 0 and that the base was initialized. Adjust the code in pc_memory_init() to check for machine->device_memory instead of pcmc->has_reserved_memory and machine->device_memory->base. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230623124553.400585-7-david@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-10hw/pci/pci: Remove multifunction parameter from pci_new_multifunction()Bernhard Beschow1-3/+3
There is also pci_new() which creates non-multifunction PCI devices. Accordingly the parameter is always set to true when a multi function PCI device is to be created. The reason for the parameter's existence seems to be that it is used in the internal PCI code as well which is the only location where it gets set to false. This one usage can be resolved by factoring out an internal helper function. Remove this redundant, error-prone parameter. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230304114043.121024-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci/pci: Remove multifunction parameter from ↵Bernhard Beschow2-4/+3
pci_create_simple_multifunction() There is also pci_create_simple() which creates non-multifunction PCI devices. Accordingly the parameter is always set to true when a multi function PCI device is to be created. The reason for the parameter's existence seems to be that it is used in the internal PCI code as well which is the only location where it gets set to false. This one usage can be replaced by trivial code. Remove this redundant, error-prone parameter. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230304114043.121024-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_piix: Move i440fx' realize near its qdev_new()Bernhard Beschow1-25/+26
I440FX realization is currently mixed with PIIX3 creation. Furthermore, it is common practice to only set properties between a device's qdev_new() and qdev_realize(). Clean up to resolve both issues. Since I440FX spawns a PCI bus let's also move the pci_bus initialization there. Note that when running `qemu-system-x86_64 -M pc -S` before and after this patch, `info mtree` in the QEMU console doesn't show any differences except that the ordering is different. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-18-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Resolve i440fx_init()Bernhard Beschow1-11/+21
i440fx_init() is a legacy init function. The previous patches worked towards TYPE_I440FX_PCI_HOST_BRIDGE to be instantiated the QOM way. Do this now by transforming the parameters passed to i440fx_init() into property assignments. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-17-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-07-10hw/pci-host/i440fx: Add PCI_HOST_{ABOVE, BELOW}_4G_MEM_SIZE propertiesBernhard Beschow1-1/+4
Introduce the properties in anticipation of QOM'ification; Q35 has the same properties. Note that we want to avoid a "ram size" property in the QOM interface since it seems redundant to both properties introduced in this change. Thus the removal of the ram_size parameter. We assume the invariant of both properties to sum up to "ram size" which is already asserted in pc_memory_init(). Under Xen the invariant seems to hold as well, so we now also check it there. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-15-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/i440fx: Add "i440fx" child property in board codeBernhard Beschow1-0/+2
The parent-child relation is usually established near a child's qdev_new(). For i440fx this allows for reusing the machine parameter, thus avoiding qdev_get_machine() which relies on a global variable. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-9-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_piix: Turn some local variables into initializersBernhard Beschow1-9/+4
Eliminates an else branch. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-8-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Make some property name macros reusable by i440fxBernhard Beschow1-4/+4
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230630073720.21297-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCI_HOST_BYPASS_IOMMU property from board codeBernhard Beschow1-0/+2
The Q35 PCI host already has a PCI_HOST_BYPASS_IOMMU property. However, the host initializes this property itself by accessing global machine state, thereby assuming it to be a PC machine. Avoid this by having board code set this property. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/pci-host/q35: Initialize PCMachineState::bus in board codeBernhard Beschow1-1/+3
The Q35 PCI host currently sets the PC machine's PCI bus attribute through global state, thereby assuming the machine to be a PC machine. The Q35 machine code already holds on to Q35's pci bus attribute, so can easily set its own property while preserving encapsulation. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/i386/pc_q35: Resolve redundant q35_host variableBernhard Beschow1-14/+13
The variable is redundant to "phb" and is never used by its real type. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630073720.21297-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-28exec/memory: Add symbolic value for memory listener priority for accelIsaku Yamahata1-1/+1
Add MEMORY_LISTNER_PRIORITY_ACCEL for the symbolic value for the memory listener to replace the hard-coded value 10 for accel. No functional change intended. Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <feebe423becc6e2aa375f59f6abce9a85bc15abb.1687279702.git.isaku.yamahata@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-06-26intel_iommu: Fix address space unmapZhenzhong Duan1-1/+1
During address space unmap, corresponding IOVA tree entries are also removed. But DMAMap is set beyond notifier's scope by 1, so in theory there is possibility to remove a continuous entry above the notifier's scope but falling in adjacent notifier's scope. There is no issue currently as no use cases allocate notifiers continuously, but let's be robust. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20230615032626.314476-4-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26intel_iommu: Fix flag check in replayZhenzhong Duan1-1/+1
Replay doesn't notify registered notifiers but the one passed to it. So it's meaningless to check the registered notifier's synthetic flag. There is no issue currently as all replay use cases have MAP flag set, but let's be robust. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20230615032626.314476-3-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26intel_iommu: Fix a potential issue in VFIO dirty page syncZhenzhong Duan1-6/+3
Peter Xu found a potential issue: "The other thing is when I am looking at the new code I found that we actually extended the replay() to be used also in dirty tracking of vfio, in vfio_sync_dirty_bitmap(). For that maybe it's already broken if unmap_all() because afaiu log_sync() can be called in migration thread anytime during DMA so I think it means the device is prone to DMA with the IOMMU pgtable quickly erased and rebuilt here, which means the DMA could fail unexpectedly. Copy Alex, Kirti and Neo." Fix it by replacing the unmap_all() to only evacuate the iova tree (keeping all host mappings untouched, IOW, don't notify UNMAP), and do a full resync in page walk which will notify all existing mappings as MAP. This way we don't interrupt with any existing mapping if there is (e.g. for the dirty sync case), meanwhile we keep sync too to latest (for moving a vfio device into an existing iommu group). Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20230615032626.314476-2-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26hw/i386/pc: Clean up pc_machine_initfnSuravee Suthikulpanit1-1/+1
To use the newly introduced PC machine class local variable. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Message-Id: <20230609164107.23404-1-suravee.suthikulpanit@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26pc: q35: Bump max_cpus to 1024Suravee Suthikulpanit1-1/+2
Since KVM_MAX_VCPUS is currently defined to 1024 for x86 as shown in arch/x86/include/asm/kvm_host.h, update QEMU limits to the same number. In case KVM could not support the specified number of vcpus, QEMU would return the following error message: qemu-system-x86_64: kvm_init_vcpu: kvm_get_vcpu failed (xxx): Invalid argument Also, keep max_cpus at 288 for machine version 8.0 and older. Cc: Igor Mammedov <imammedo@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Julia Suvorova <jusual@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Message-Id: <20230607205717.737749-3-suravee.suthikulpanit@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-06-26hw/i386/pc: Default to use SMBIOS 3.0 for newer machine modelsSuravee Suthikulpanit3-1/+13
Currently, pc-q35 and pc-i44fx machine models are default to use SMBIOS 2.8 (32-bit entry point). Since SMBIOS 3.0 (64-bit entry point) is now fully supported since QEMU 7.0, default to use SMBIOS 3.0 for newer machine models. This is necessary to avoid the following message when launching a VM with large number of vcpus. "SMBIOS 2.1 table length 66822 exceeds 65535" Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Message-Id: <20230607205717.737749-2-suravee.suthikulpanit@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2023-06-20meson: Replace CONFIG_SOFTMMU -> CONFIG_SYSTEM_ONLYPhilippe Mathieu-Daudé1-1/+1
Since we *might* have user emulation with softmmu, use the clearer 'CONFIG_SYSTEM_ONLY' key to check for system emulation. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230613133347.82210-9-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-06-15xen-hvm: reorganize xen-hvm and move common function to xen-hvm-commonStefano Stabellini2-967/+63
This patch does following: 1. creates arch_handle_ioreq() and arch_xen_set_memory(). This is done in preparation for moving most of xen-hvm code to an arch-neutral location, move the x86-specific portion of xen_set_memory to arch_xen_set_memory. Also, move handle_vmport_ioreq to arch_handle_ioreq. 2. Pure code movement: move common functions to hw/xen/xen-hvm-common.c Extract common functionalities from hw/i386/xen/xen-hvm.c and move them to hw/xen/xen-hvm-common.c. These common functions are useful for creating an IOREQ server. xen_hvm_init_pc() contains the architecture independent code for creating and mapping a IOREQ server, connecting memory and IO listeners, initializing a xen bus and registering backends. Moved this common xen code to a new function xen_register_ioreq() which can be used by both x86 and ARM machines. Following functions are moved to hw/xen/xen-hvm-common.c: xen_vcpu_eport(), xen_vcpu_ioreq(), xen_ram_alloc(), xen_set_memory(), xen_region_add(), xen_region_del(), xen_io_add(), xen_io_del(), xen_device_realize(), xen_device_unrealize(), cpu_get_ioreq_from_shared_memory(), cpu_get_ioreq(), do_inp(), do_outp(), rw_phys_req_item(), read_phys_req_item(), write_phys_req_item(), cpu_ioreq_pio(), cpu_ioreq_move(), cpu_ioreq_config(), handle_ioreq(), handle_buffered_iopage(), handle_buffered_io(), cpu_handle_ioreq(), xen_main_loop_prepare(), xen_hvm_change_state_handler(), xen_exit_notifier(), xen_map_ioreq_server(), destroy_hvm_domain() and xen_shutdown_fatal_error() 3. Removed static type from below functions: 1. xen_region_add() 2. xen_region_del() 3. xen_io_add() 4. xen_io_del() 5. xen_device_realize() 6. xen_device_unrealize() 7. xen_hvm_change_state_handler() 8. cpu_ioreq_pio() 9. xen_exit_notifier() 4. Replace TARGET_PAGE_SIZE with XC_PAGE_SIZE to match the page side with Xen. Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2023-06-15hw/i386/xen/xen-hvm: move x86-specific fields out of XenIOStateStefano Stabellini1-31/+27
In preparation to moving most of xen-hvm code to an arch-neutral location, move: - shared_vmport_page - log_for_dirtybit - dirty_bitmap - suspend - wakeup out of XenIOState struct as these are only used on x86, especially the ones related to dirty logging. Updated XenIOState can be used for both aarch64 and x86. Also, remove free_phys_offset as it was unused. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2023-06-15hw/i386/xen: rearrange xen_hvm_init_pcVikram Garhwal1-24/+25
In preparation to moving most of xen-hvm code to an arch-neutral location, move non IOREQ references to: - xen_get_vmport_regs_pfn - xen_suspend_notifier - xen_wakeup_notifier - xen_ram_init towards the end of the xen_hvm_init_pc() function. This is done to keep the common ioreq functions in one place which will be moved to new function in next patch in order to make it common to both x86 and aarch64 machines. Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Paul Durrant <paul@xen.org>
2023-06-15hw/i386/xen/: move xen-mapcache.c to hw/xen/Vikram Garhwal4-605/+1
xen-mapcache.c contains common functions which can be used for enabling Xen on aarch64 with IOREQ handling. Moving it out from hw/i386/xen to hw/xen to make it accessible for both aarch64 and x86. Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Paul Durrant <paul@xen.org>
2023-06-13hw/char/parallel-isa: Export struct ISAParallelStateBernhard Beschow2-2/+2
Allows the struct to be embedded directly into device models without additional allocation. Suggested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230612081238.1742-3-shentey@gmail.com> [PMD: Update MAINTAINERS entry and use SPDX license identifier] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-06-09hw/i386/microvm: Simplify using object_dynamic_cast()Philippe Mathieu-Daudé1-2/+1
Use object_dynamic_cast() to determine if 'dev' is a TYPE_VIRTIO_MMIO. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-06-07hw/isa/piix3: Resolve redundant TYPE_PIIX3_XEN_DEVICEBernhard Beschow1-3/+2
During the last patches, TYPE_PIIX3_XEN_DEVICE turned into a clone of TYPE_PIIX3_DEVICE. Remove this redundancy. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Chuck Zmudzinski <brchuckz@aol.com> Message-Id: <20230312120221.99183-7-shentey@gmail.com> Message-Id: <20230403074124.3925-8-shentey@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07hw/isa/piix3: Avoid Xen-specific variant of piix3_write_config()Bernhard Beschow1-0/+18
Subscribe to pci_bus_fire_intx_routing_notifier() instead which allows for having a common piix3_write_config() for the PIIX3 device models. While at it, move the subscription into machine code to facilitate resolving TYPE_PIIX3_XEN_DEVICE. In a possible future followup, pci_bus_fire_intx_routing_notifier() could be adjusted in such a way that subscribing to it doesn't require knowledge of the device firing it. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Chuck Zmudzinski <brchuckz@aol.com> Message-Id: <20230312120221.99183-5-shentey@gmail.com> Message-Id: <20230403074124.3925-6-shentey@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07hw/isa/piix3: Wire up Xen PCI IRQ handling outside of PIIX3Bernhard Beschow1-0/+13
xen_intx_set_irq() doesn't depend on PIIX3State. In order to resolve TYPE_PIIX3_XEN_DEVICE and in order to make Xen agnostic about the precise south bridge being used, set up Xen's PCI IRQ handling of PIIX3 in the board. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Chuck Zmudzinski <brchuckz@aol.com> Message-Id: <20230312120221.99183-4-shentey@gmail.com> Message-Id: <20230403074124.3925-5-shentey@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07include/hw/xen/xen: Rename xen_piix3_set_irq() to xen_intx_set_irq()Bernhard Beschow1-1/+1
xen_piix3_set_irq() isn't PIIX specific: PIIX is a single PCI device while xen_piix3_set_irq() maps multiple PCI devices to their respective IRQs, which is board-specific. Rename xen_piix3_set_irq() to communicate this. Also rename XEN_PIIX_NUM_PIRQS to XEN_IOAPIC_NUM_PIRQS since the Xen's IOAPIC rather than PIIX has this many interrupt routes. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Chuck Zmudzinski <brchuckz@aol.com> Message-Id: <20230312120221.99183-2-shentey@gmail.com> Message-Id: <20230403074124.3925-2-shentey@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07hw/xen: Fix broken check for invalid state in xs_be_open()David Woodhouse1-1/+1
Coverity points out that if (!s && !s->impl) isn't really what we intended to do here. CID 1508131. Fixes: 032475127225 ("hw/xen: Add emulated implementation of XenStore operations") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20230412185102.441523-6-dwmw2@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-07hw/xen: Simplify emulated Xen platform initDavid Woodhouse3-31/+25
I initially put the basic platform init (overlay pages, grant tables, event channels) into mc->kvm_type because that was the earliest place that could sensibly test for xen_mode==XEN_EMULATE. The intent was to do this early enough that we could then initialise the XenBus and other parts which would have depended on them, from a generic location for both Xen and KVM/Xen in the PC-specific code, as seen in https://lore.kernel.org/qemu-devel/20230116221919.1124201-16-dwmw2@infradead.org/ However, then the Xen on Arm patches came along, and *they* wanted to do the XenBus init from a 'generic' Xen-specific location instead: https://lore.kernel.org/qemu-devel/20230210222729.957168-4-sstabellini@kernel.org/ Since there's no generic location that covers all three, I conceded to do it for XEN_EMULATE mode in pc_basic_devices_init(). And now there's absolutely no point in having some of the platform init done from pc_machine_kvm_type(); we can move it all up to live in a single place in pc_basic_devices_init(). This has the added benefit that we can drop the separate xen_evtchn_connect_gsis() function completely, and pass just the system GSIs in directly to xen_evtchn_create(). While I'm at it, it does no harm to explicitly pass in the *number* of said GSIs, because it does make me twitch a bit to pass an array of impicit size. During the lifetime of the KVM/Xen patchset, that had already changed (albeit just cosmetically) from GSI_NUM_PINS to IOAPIC_NUM_PINS. And document a bit better that this is for the *output* GSI for raising CPU0's events when the per-CPU vector isn't available. The fact that we create a whole set of them and then only waggle the one we're told to, instead of having a single output and only *connecting* it to the GSI that it should be connected to, is still non-intuitive for me. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230412185102.441523-2-dwmw2@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-06-05hw/timer/i8254_common: Share "iobase" property via base classBernhard Beschow1-1/+0
Both TYPE_KVM_I8254 and TYPE_I8254 have their own but same implementation of the "iobase" property. The storage for the property already resides in PITCommonState, so also move the property definition there. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230523195608.125820-2-shentey@gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2023-05-30aio: remove aio_disable_external() APIStefan Hajnoczi1-1/+1
All callers now pass is_external=false to aio_set_fd_handler() and aio_set_event_notifier(). The aio_disable_external() API that temporarily disables fd handlers that were registered is_external=true is therefore dead code. Remove aio_disable_external(), aio_enable_external(), and the is_external arguments to aio_set_fd_handler() and aio_set_event_notifier(). The entire test-fdmon-epoll test is removed because its sole purpose was testing aio_disable_external(). Parts of this patch were generated using the following coccinelle (https://coccinelle.lip6.fr/) semantic patch: @@ expression ctx, fd, is_external, io_read, io_write, io_poll, io_poll_ready, opaque; @@ - aio_set_fd_handler(ctx, fd, is_external, io_read, io_write, io_poll, io_poll_ready, opaque) + aio_set_fd_handler(ctx, fd, io_read, io_write, io_poll, io_poll_ready, opaque) @@ expression ctx, notifier, is_external, io_read, io_poll, io_poll_ready; @@ - aio_set_event_notifier(ctx, notifier, is_external, io_read, io_poll, io_poll_ready) + aio_set_event_notifier(ctx, notifier, io_read, io_poll, io_poll_ready) Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230516190238.8401-21-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-05-30hw/xen: do not use aio_set_fd_handler(is_external=true) in xen_xenstoreStefan Hajnoczi1-1/+1
There is no need to suspend activity between aio_disable_external() and aio_enable_external(), which is mainly used for the block layer's drain operation. This is part of ongoing work to remove the aio_disable_external() API. Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230516190238.8401-9-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-05-22hw/i386: Ignore the default parallel port if it has not been compiled into QEMUThomas Huth2-0/+5
Don't try to instantiate the parallel port if it has not been enabled in the build configuration. Message-Id: <20230512124033.502654-10-thuth@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-22hw: Move the default NIC machine class setting from the x86 to the generic oneThomas Huth3-7/+6
We are going to re-use this setting for other targets, so let's move this to the main MachineClass. Message-Id: <20230512124033.502654-4-thuth@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-22hw/i386/Kconfig: ISAPC works fine without VGA_ISAThomas Huth1-1/+1
The "isapc" machine can also be run without VGA card, so there is no need for a hard requirement with a "select" here - "imply" is enough. Message-Id: <20230512124033.502654-2-thuth@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-19hw/i386/pc: No need for rtc_state to be an out-parameterBernhard Beschow3-8/+8
Now that the RTC is created as part of the southbridges it doesn't need to be an out-parameter any longer. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230519084734.220480-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/i386/pc: Create RTC controllers in south bridgesBernhard Beschow3-1/+21
Just like in the real hardware (and in PIIX4), create the RTC controllers in the south bridges. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230519084734.220480-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/i386/pc: Initialize ram_memory variable directlyBernhard Beschow3-8/+4
Going through pc_memory_init() seems quite complicated for a simple assignment. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230213162004.2797-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/i386/pc_{q35,piix}: Minimize usage of get_system_memory()Bernhard Beschow2-4/+5
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230213162004.2797-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/i386/pc_{q35,piix}: Reuse MachineClass::desc as SMB product nameBernhard Beschow2-2/+2
No need to repeat the descriptions. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230213162004.2797-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19hw/i386/pc_q35: Reuse machine parameterBernhard Beschow1-1/+1
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230213162004.2797-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-05-19virtio-mem: Default to "unplugged-inaccessible=on" with 8.1 on x86-64David Hildenbrand1-1/+3
Allowing guests to read unplugged memory simplified the bring-up of virtio-mem in Linux guests -- which was limited to x86-64 only. On arm64 (which was added later), we never had legacy guests and don't even allow to configure it, essentially always having "unplugged-inaccessible=on". At this point, all guests we care about should be supporting VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, so let's change the default for the 8.1 machine. This change implies that also memory that supports the shared zeropage (private anonymous memory) will now require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE in the driver in order to be usable by the guest -- as default, one can still manually set the unplugged-inaccessible property. Disallowing the guest to read unplugged memory will be important for some future features, such as memslot optimizations or protection of unplugged memory, whereby we'll actually no longer allow the guest to even read from unplugged memory. At some point, we might want to deprecate and remove that property. Cc: "Michael S. Tsirkin" <mst@redhat.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> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230503182352.792458-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19ACPI: i386: bump to MADT to revision 3Eric DeVolder1-1/+1
Currently i386 QEMU generates MADT revision 3, and reports MADT revision 1. Set .revision to 3 to match reality. Link: https://lore.kernel.org/linux-acpi/20230327191026.3454-1-eric.devolder@ora cle.com/T/#t Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20230517162545.2191-3-eric.devolder@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2023-04-24intel_iommu: refine iotlb hash calculationJason Wang2-7/+8
Commit 1b2b12376c8 ("intel-iommu: PASID support") takes PASID into account when calculating iotlb hash like: static guint vtd_iotlb_hash(gconstpointer v) { const struct vtd_iotlb_key *key = v; return key->gfn | ((key->sid) << VTD_IOTLB_SID_SHIFT) | (key->level) << VTD_IOTLB_LVL_SHIFT | (key->pasid) << VTD_IOTLB_PASID_SHIFT; } This turns out to be problematic since: - the shift will lose bits if not converting to uint64_t - level should be off by one in order to fit into 2 bits - VTD_IOTLB_PASID_SHIFT is 30 but PASID is 20 bits which will waste some bits - the hash result is uint64_t so we will lose bits when converting to guint So this patch fixes them by - converting the keys into uint64_t before doing the shift - off level by one to make it fit into two bits - change the sid, lvl and pasid shift to 26, 42 and 44 in order to take the full width of uint64_t - perform an XOR to the top 32bit with the bottom 32bit for the final result to fit guint Fixes: Coverity CID 1508100 Fixes: 1b2b12376c8 ("intel-iommu: PASID support") Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230412073510.7158-1-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2023-04-24hw/acpi: limit warning on acpi table size to pc machines older than version 2.3Ani Sinha3-2/+6
i440fx machine versions 2.3 and newer supports dynamic ram resizing. See commit a1666142db6233 ("acpi-build: make ROMs RAM blocks resizeable") . Currently supported all q35 machine types (versions 2.4 and newer) supports resizable RAM/ROM blocks.Therefore the warning generated when the ACPI table size exceeds a pre-defined value does not apply to those machine versions. Add a check limiting the warning message to only those machines that does not support expandable ram blocks (that is, i440fx machines with version 2.2 and older). Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20230329045726.14028-1-anisinha@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-04-21hw: Add compat machines for 8.1Cornelia Huck3-5/+28
Add 8.1 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20230314173009.152667-1-cohuck@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-07-13 04:03:34 +0000