aboutsummaryrefslogtreecommitdiff
path: root/hw/i386
AgeCommit message (Collapse)Author
2023-08-23hw: Add compat machines for 8.2Cornelia Huck
Add 8.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20230718142235.135319-1-cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Laurent Vivier <laurent@vivier.eu> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-08-07hw/i386/vmmouse:add relative packet flag for button statusZongmin Zhou
The buttons value use macros instead of direct numbers. If request relative mode, have to add this for guest vmmouse driver to judge this is a relative packet. otherwise,vmmouse driver will not match the condition 'status & VMMOUSE_RELATIVE_PACKET', and can't report events on the correct(relative) input device, result to relative mode unuseful. Signed-off-by: Zongmin Zhou<zhouzongmin@kylinos.cn> Message-ID: <20230413081526.2229916-1-zhouzongmin@kylinos.cn> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2023-08-03hw/i386/x86-iommu: Fix endianness issue in x86_iommu_irq_to_msi_message()Thomas Huth
The values in "msg" are assembled in host endian byte order (the other field are also not swapped), so we must not swap the __addr_head here. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-6-thuth@redhat.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> Reviewed-by: Peter Xu <peterx@redhat.com>
2023-08-03hw/i386/intel_iommu: Fix index calculation in vtd_interrupt_remap_msi()Thomas Huth
The values in "addr" are populated locally in this function in host endian byte order, so we must not swap the index_l field here. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-5-thuth@redhat.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> Reviewed-by: Peter Xu <peterx@redhat.com>
2023-08-03hw/i386/intel_iommu: Fix struct VTDInvDescIEC on big endian hostsThomas Huth
On big endian hosts, we need to reverse the bitfield order in the struct VTDInvDescIEC, just like it is already done for the other bitfields in the various structs of the intel-iommu device. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-4-thuth@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-08-03hw/i386/intel_iommu: Fix endianness problems related to VTD_IR_TableEntryThomas Huth
The code already tries to do some endianness handling here, but currently fails badly: - While it already swaps the data when logging errors / tracing, it fails to byteswap the value before e.g. accessing entry->irte.present - entry->irte.source_id is swapped with le32_to_cpu(), though this is a 16-bit value - The whole union is apparently supposed to be swapped via the 64-bit data[2] array, but the struct is a mixture between 32 bit values (the first 8 bytes) and 64 bit values (the second 8 bytes), so this cannot work as expected. Fix it by converting the struct to two proper 64-bit bitfields, and by swapping the values only once for everybody right after reading the data from memory. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-3-thuth@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-08-03hw/i386/intel_iommu: Fix trivial endianness problemsThomas Huth
After reading the guest memory with dma_memory_read(), we have to make sure that we byteswap the little endian data to the host's byte order. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-2-thuth@redhat.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> Reviewed-by: Peter Xu <peterx@redhat.com>
2023-08-03acpi: x86: remove _ADR on host bridgesIgor Mammedov
ACPI spec (since 2.0a) says " A device object must contain either an _HID object or an _ADR object, but can contain both. " _ADR is used when device is attached to an ennumerable bus, however hostbridge is not and uses dedicated _HID for discovery, drop _ADR field. It doesn't seem that having _ADR has a negative effects OSes manage to tolerate that, but there is no point of having it there. (only pc/q35 has it hostbridge description, while others (microvm/arm) don't) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230720133858.1974024-6-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-08-03x86: acpi: workaround Windows not handling name references in Package properlyIgor Mammedov
it seems that Windows is unable to handle variable references making it choke up when accessing ASUN during _DSM call when device is hotplugged (it lists package elements as DataAlias but despite that later on it misbehaves) with following error shown up in AMLI debugger (WS2012r2): Store(ShiftLeft(One,Arg1="ASUN",) AMLI_ERROR(c0140008): Unexpected argument type ValidateArgTypes: expected Arg1 to be type Integer (Type=String) Similar outcome with WS2022. Issue is not fatal but as result acpi-index/"PCI Label ID" property is either not shown in device details page or shows incorrect value. Fix it by doing assignment of BSEL/ASUN values to package elements manually after package declaration. Fix was tested with: WS2012r2, WS2022, RHEL9 Fixes: 467d099a2985 (x86: acpi: _DSM: use Package to pass parameters) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230720133858.1974024-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-08-02Merge tag 'misc-fixes-20230801' of https://github.com/philmd/qemu into stagingRichard Henderson
Misc patches queue xen: Fix issues reported by fuzzer / Coverity misc: Fix some typos in documentation and comments ui/dbus: Build fixes for Clang/win32/!opengl linux-user: Semihosting fixes on m68k/nios2 tests/migration: Disable stack protector when linking without stdlib # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmTJfrQACgkQ4+MsLN6t # wN4Nqw/+NjoW2jdy9LNAgx7IeH2w+HfvvULpBOTDRRNahuXbGpzl6L57cS92r5a8 # UFJGfxbL2nlxrJbUdAWGONIweCvUb9jnpbT2id1dBp4wp+8aKFvPj1Al34OENNVS # 1lQT0G6mKx9itcXP9lVSBPhEbWIB9ZMaDG0R872bA6Ec3G7PWny+AOhMvJecieol # 2Qyv84ioA3N0xkYUB64KBVDmJOG0Tx+LYZfsXUybLKwfvBDLeVkHuHKtb94kh0G9 # MUsM/p9sHvfrC1bO+DQ9P1bzRI9zw2I2f4xMIs4QCMGPbJUrhv7edOc2PSO5XQoG # izcV9NSL0tl6LbXZvkE7sJw0tDuR6R9sQ9KJWoltJCGRGOWlC5CeSTUfLbH9HkFc # CXapKWth6cmOboGZNTlidn41oH7xE/kW6Em1XAD0M0eLUCUMzVjaSs1sIwKnbF7i # sz7HcgAAuAVhmR0n4zOkphJkek72J7atLNpqU0AdYH46LR92zSdh6YoD5YDBPwY8 # hoy7VFauSkF8+5Wi7CTTjtq+edkuFRcuNMCR0Fd2iolE8KKYvxHnwEGH/5T4s2m7 # 8f40AEyQRk0nFn44tqeyb14O8c2lZL3jmDEh+LYT/PPp/rCc/X7Ugplpau+bNZsx # OOZd0AxujbrK+Xn80Agc+3/vn4/2eAvz7OdGc/SmKuYLyseBQfo= # =5ZLa # -----END PGP SIGNATURE----- # gpg: Signature made Tue 01 Aug 2023 02:52:52 PM PDT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] * tag 'misc-fixes-20230801' of https://github.com/philmd/qemu: target/m68k: Fix semihost lseek offset computation target/nios2: Fix semihost lseek offset computation target/nios2: Pass semihosting arg to exit tests/migration: Add -fno-stack-protector misc: Fix some typos in documentation and comments ui/dbus: fix clang compilation issue ui/dbus: fix win32 compilation when !opengl hw/xen: prevent guest from binding loopback event channel to itself i386/xen: consistent locking around Xen singleshot timers hw/xen: fix off-by-one in xen_evtchn_set_gsi() Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-08-01hw/xen: prevent guest from binding loopback event channel to itselfDavid Woodhouse
Fuzzing showed that a guest could bind an interdomain port to itself, by guessing the next port to be allocated and putting that as the 'remote' port number. By chance, that works because the newly-allocated port has type EVTCHNSTAT_unbound. It shouldn't. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230801175747.145906-4-dwmw2@infradead.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-08-01hw/xen: fix off-by-one in xen_evtchn_set_gsi()David Woodhouse
Coverity points out (CID 1508128) a bounds checking error. We need to check for gsi >= IOAPIC_NUM_PINS, not just greater-than. Also fix up an assert() that has the same problem, that Coverity didn't see. Fixes: 4f81baa33ed6 ("hw/xen: Support GSI mapping to PIRQ") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230801175747.145906-2-dwmw2@infradead.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-08-01xen-platform: do full PCI reset during unplug of IDE devicesOlaf Hering
The IDE unplug function needs to reset the entire PCI device, to make sure all state is initialized to defaults. This is done by calling pci_device_reset, which resets not only the chip specific registers, but also all PCI state. This fixes "unplug" in a Xen HVM domU with the modular legacy xenlinux PV drivers. Commit ee358e919e38 ("hw/ide/piix: Convert reset handler to DeviceReset") changed the way how the the disks are unplugged. Prior this commit the PCI device remained unchanged. After this change, piix_ide_reset is exercised after the "unplug" command, which was not the case prior that commit. This function resets the command register. As a result the ata_piix driver inside the domU will see a disabled PCI device. The generic PCI code will reenable the PCI device. On the qemu side, this runs pci_default_write_config/pci_update_mappings. Here a changed address is returned by pci_bar_address, this is the address which was truncated in piix_ide_reset. In case of a Xen HVM domU, the address changes from 0xc120 to 0xc100. This truncation was a bug in piix_ide_reset, which was fixed in commit 230dfd9257 ("hw/ide/piix: properly initialize the BMIBA register"). If pci_xen_ide_unplug had used pci_device_reset, the PCI registers would have been properly reset, and commit ee358e919e38 would have not introduced a regression for this specific domU environment. While the unplug is supposed to hide the IDE disks, the changed BMIBA address broke the UHCI device. In case the domU has an USB tablet configured, to recive absolute pointer coordinates for the GUI, it will cause a hang during device discovery of the partly discovered USB hid device. Reading the USBSTS word size register will fail. The access ends up in the QEMU piix-bmdma device, instead of the expected uhci device. Here a byte size request is expected, and a value of ~0 is returned. As a result the UCHI driver sees an error state in the register, and turns off the UHCI controller. Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230720072950.20198-1-olaf@aepfle.de> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-08-01xen: Don't pass MemoryListener around by valuePeter Maydell
Coverity points out (CID 1513106, 1513107) that MemoryListener is a 192 byte struct which we are passing around by value. Switch to passing a const pointer into xen_register_ioreq() and then to xen_do_ioreq_register(). We can also make the file-scope MemoryListener variables const, since nothing changes them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230718101057.1110979-1-peter.maydell@linaro.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-08-01hw/xen: Clarify (lack of) error handling in transaction_commit()David Woodhouse
Coverity was unhappy (CID 1508359) because we didn't check the return of init_walk_op() in transaction_commit(), despite doing so at every other call site. Strictly speaking, this is a false positive since it can never fail. It only fails for invalid user input (transaction ID or path), and both of those are hard-coded to known sane values in this invocation. But Coverity doesn't know that, and neither does the casual reader of the code. Returning an error here would be weird, since the transaction *is* committed by this point; all the walk_op is doing is firing watches on the newly-committed changed nodes. So make it a g_assert(!ret), since it really should never happen. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20076888f6bdf06a65aafc5cf954260965d45b97.camel@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-07-12pc: Factor out (un)plug handling of virtio-md-pci devicesDavid Hildenbrand
Let's factor out (un)plug handling, to be reused from arm/virt code. Provide stubs for the case that CONFIG_VIRTIO_MD is not selected because neither virtio-mem nor virtio-pmem is enabled. While this cannot currently happen for x86, it will be possible for arm/virt. Message-ID: <20230711153445.514112-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12hw/i386/pc: Remove PC_MACHINE_DEVMEM_REGION_SIZEDavid Hildenbrand
There are no remaining users in the tree. Libvirt never used that property and a quick internet search revealed no other users. Further, we renamed that property already in commit f2ffbe2b7dd0 ("pc: rename "hotplug memory" terminology to "device memory"") without anybody complaining. So let's just get rid of it. 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-9-david@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12hw/i386/acpi-build: Rely on machine->device_memory when building SRATDavid Hildenbrand
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 Hildenbrand
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Yamahata
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 Duan
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 Duan
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 Duan
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 Suthikulpanit
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 Suthikulpanit
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 Suthikulpanit
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é
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 Stabellini
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 Stabellini
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 Garhwal
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 Garhwal
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 Beschow
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é
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 Beschow
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 Beschow
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 Beschow
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 Beschow
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 Woodhouse
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 Woodhouse
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>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-04 13:43:06 +0000