aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)Author
2023-03-01hw/xen: Support HVM_PARAM_CALLBACK_TYPE_PCI_INTX callbackDavid Woodhouse
The guest is permitted to specify an arbitrary domain/bus/device/function and INTX pin from which the callback IRQ shall appear to have come. In QEMU we can only easily do this for devices that actually exist, and even that requires us "knowing" that it's a PCMachine in order to find the PCI root bus — although that's OK really because it's always true. We also don't get to get notified of INTX routing changes, because we can't do that as a passive observer; if we try to register a notifier it will overwrite any existing notifier callback on the device. But in practice, guests using PCI_INTX will only ever use pin A on the Xen platform device, and won't swizzle the INTX routing after they set it up. So this is just fine. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callbackDavid Woodhouse
The GSI callback (and later PCI_INTX) is a level triggered interrupt. It is asserted when an event channel is delivered to vCPU0, and is supposed to be cleared when the vcpu_info->evtchn_upcall_pending field for vCPU0 is cleared again. Thankfully, Xen does *not* assert the GSI if the guest sets its own evtchn_upcall_pending field; we only need to assert the GSI when we have delivered an event for ourselves. So that's the easy part, kind of. There's a slight complexity in that we need to hold the BQL before we can call qemu_set_irq(), and we definitely can't do that while holding our own port_lock (because we'll need to take that from the qemu-side functions that the PV backend drivers will call). So if we end up wanting to set the IRQ in a context where we *don't* already hold the BQL, defer to a BH. However, we *do* need to poll for the evtchn_upcall_pending flag being cleared. In an ideal world we would poll that when the EOI happens on the PIC/IOAPIC. That's how it works in the kernel with the VFIO eventfd pairs — one is used to trigger the interrupt, and the other works in the other direction to 'resample' on EOI, and trigger the first eventfd again if the line is still active. However, QEMU doesn't seem to do that. Even VFIO level interrupts seem to be supported by temporarily unmapping the device's BARs from the guest when an interrupt happens, then trapping *all* MMIO to the device and sending the 'resample' event on *every* MMIO access until the IRQ is cleared! Maybe in future we'll plumb the 'resample' concept through QEMU's irq framework but for now we'll do what Xen itself does: just check the flag on every vmexit if the upcall GSI is known to be asserted. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_resetDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_bind_vcpuDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_bind_interdomainDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_alloc_unboundDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_sendDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_bind_ipiDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_bind_virqDavid Woodhouse
Add the array of virq ports to each vCPU so that we can deliver timers, debug ports, etc. Global virqs are allocated against vCPU 0 initially, but can be migrated to other vCPUs (when we implement that). The kernel needs to know about VIRQ_TIMER in order to accelerate timers, so tell it via KVM_XEN_VCPU_ATTR_TYPE_TIMER. Also save/restore the value of the singleshot timer across migration, as the kernel will handle the hypercalls automatically now. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_unmaskDavid Woodhouse
This finally comes with a mechanism for actually injecting events into the guest vCPU, with all the atomic-test-and-set that's involved in setting the bit in the shinfo, then the index in the vcpu_info, and injecting either the lapic vector as MSI, or letting KVM inject the bare vector. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_closeDavid Woodhouse
It calls an internal close_port() helper which will also be used from EVTCHNOP_reset and will actually do the work to disconnect/unbind a port once any of that is actually implemented in the first place. That in turn calls a free_port() internal function which will be in error paths after allocation. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Implement EVTCHNOP_statusDavid Woodhouse
This adds the basic structure for maintaining the port table and reporting the status of ports therein. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: Add support for Xen event channel delivery to vCPUDavid Woodhouse
The kvm_xen_inject_vcpu_callback_vector() function will either deliver the per-vCPU local APIC vector (as an MSI), or just kick the vCPU out of the kernel to trigger KVM's automatic delivery of the global vector. Support for asserting the GSI/PCI_INTX callbacks will come later. Also add kvm_xen_get_vcpu_info_hva() which returns the vcpu_info of a given vCPU. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01hw/xen: Add xen_evtchn device for event channel emulationDavid Woodhouse
Include basic support for setting HVM_PARAM_CALLBACK_IRQ to the global vector method HVM_PARAM_CALLBACK_TYPE_VECTOR, which is handled in-kernel by raising the vector whenever the vCPU's vcpu_info->evtchn_upcall_pending flag is set. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HVMOP_set_paramAnkur Arora
This is the hook for adding the HVM_PARAM_CALLBACK_IRQ parameter in a subsequent commit. Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Split out from another commit] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HVMOP_set_evtchn_upcall_vectorAnkur Arora
The HVMOP_set_evtchn_upcall_vector hypercall sets the per-vCPU upcall vector, to be delivered to the local APIC just like an MSI (with an EOI). This takes precedence over the system-wide delivery method set by the HVMOP_set_param hypercall with HVM_PARAM_CALLBACK_IRQ. It's used by Windows and Xen (PV shim) guests but normally not by Linux. Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Rework for upstream kernel changes and split from HVMOP_set_param] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_event_channel_opJoao Martins
Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Ditch event_channel_op_compat which was never available to HVM guests] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: handle VCPUOP_register_runstate_memory_areaJoao Martins
Allow guest to setup the vcpu runstates which is used as steal clock. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: handle VCPUOP_register_vcpu_time_infoJoao Martins
In order to support Linux vdso in Xen. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: handle VCPUOP_register_vcpu_infoJoao Martins
Handle the hypercall to set a per vcpu info, and also wire up the default vcpu_info in the shared_info page for the first 32 vCPUs. To avoid deadlock within KVM a vCPU thread must set its *own* vcpu_info rather than it being set from the context in which the hypercall is invoked. Add the vcpu_info (and default) GPA to the vmstate_x86_cpu for migration, and restore it in kvm_arch_put_registers() appropriately. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_vcpu_opJoao Martins
This is simply when guest tries to register a vcpu_info and since vcpu_info placement is optional in the minimum ABI therefore we can just fail with -ENOSYS Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_hvm_opJoao Martins
This is when guest queries for support for HVMOP_pagetable_dying. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement XENMEM_add_to_physmap_batchDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_memory_opJoao Martins
Specifically XENMEM_add_to_physmap with space XENMAPSPACE_shared_info to allow the guest to set its shared_info page. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Use the xen_overlay device, add compat support] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: manage and save/restore Xen guest long_mode settingDavid Woodhouse
Xen will "latch" the guest's 32-bit or 64-bit ("long mode") setting when the guest writes the MSR to fill in the hypercall page, or when the guest sets the event channel callback in HVM_PARAM_CALLBACK_IRQ. KVM handles the former and sets the kernel's long_mode flag accordingly. The latter will be handled in userspace. Keep them in sync by noticing when a hypercall is made in a mode that doesn't match qemu's idea of the guest mode, and resyncing from the kernel. Do that same sync right before serialization too, in case the guest has set the hypercall page but hasn't yet made a system call. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: Implement SCHEDOP_poll and SCHEDOP_yieldDavid Woodhouse
They both do the same thing and just call sched_yield. This is enough to stop the Linux guest panicking when running on a host kernel which doesn't intercept SCHEDOP_poll and lets it reach userspace. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_sched_op, SCHEDOP_shutdownJoao Martins
It allows to shutdown itself via hypercall with any of the 3 reasons: 1) self-reboot 2) shutdown 3) crash Implementing SCHEDOP_shutdown sub op let us handle crashes gracefully rather than leading to triple faults if it remains unimplemented. In addition, the SHUTDOWN_soft_reset reason is used for kexec, to reset Xen shared pages and other enlightenments and leave a clean slate for the new kernel without the hypervisor helpfully writing information at unexpected addresses. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Ditch sched_op_compat which was never available for HVM guests, Add SCHEDOP_soft_reset] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: implement HYPERVISOR_xen_versionJoao Martins
This is just meant to serve as an example on how we can implement hypercalls. xen_version specifically since Qemu does all kind of feature controllability. So handling that here seems appropriate. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Implement kvm_gva_rw() safely] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/xen: handle guest hypercallsJoao Martins
This means handling the new exit reason for Xen but still crashing on purpose. As we implement each of the hypercalls we will then return the right return code. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Add CPL to hypercall tracing, disallow hypercalls from CPL > 0] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/kvm: Set Xen vCPU ID in KVMDavid Woodhouse
There are (at least) three different vCPU ID number spaces. One is the internal KVM vCPU index, based purely on which vCPU was chronologically created in the kernel first. If userspace threads are all spawned and create their KVM vCPUs in essentially random order, then the KVM indices are basically random too. The second number space is the APIC ID space, which is consistent and useful for referencing vCPUs. MSIs will specify the target vCPU using the APIC ID, for example, and the KVM Xen APIs also take an APIC ID from userspace whenever a vCPU needs to be specified (as opposed to just using the appropriate vCPU fd). The third number space is not normally relevant to the kernel, and is the ACPI/MADT/Xen CPU number which corresponds to cs->cpu_index. But Xen timer hypercalls use it, and Xen timer hypercalls *really* want to be accelerated in the kernel rather than handled in userspace, so the kernel needs to be told. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/kvm: handle Xen HVM cpuid leavesJoao Martins
Introduce support for emulating CPUID for Xen HVM guests. It doesn't make sense to advertise the KVM leaves to a Xen guest, so do Xen unconditionally when the xen-version machine property is set. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> [dwmw2: Obtain xen_version from KVM property, make it automatic] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-03-01i386/kvm: Add xen-version KVM accelerator property and init KVM Xen supportDavid Woodhouse
This just initializes the basic Xen support in KVM for now. Only permitted on TYPE_PC_MACHINE because that's where the sysbus devices for Xen heap overlay, event channel, grant tables and other stuff will exist. There's no point having the basic hypercall support if nothing else works. Provide sysemu/kvm_xen.h and a kvm_xen_get_caps() which will be used later by support devices. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
2023-02-28accel/tcg: Add 'size' param to probe_access_fullRichard Henderson
Change to match the recent change to probe_access_flags. All existing callers updated to supply 0, so no change in behaviour. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-02-28accel/tcg: Add 'size' param to probe_access_flags()Daniel Henrique Barboza
probe_access_flags() as it is today uses probe_access_full(), which in turn uses probe_access_internal() with size = 0. probe_access_internal() then uses the size to call the tlb_fill() callback for the given CPU. This size param ('fault_size' as probe_access_internal() calls it) is ignored by most existing .tlb_fill callback implementations, e.g. arm_cpu_tlb_fill(), ppc_cpu_tlb_fill(), x86_cpu_tlb_fill() and mips_cpu_tlb_fill() to name a few. But RISC-V riscv_cpu_tlb_fill() actually uses it. The 'size' parameter is used to check for PMP (Physical Memory Protection) access. This is necessary because PMP does not make any guarantees about all the bytes of the same page having the same permissions, i.e. the same page can have different PMP properties, so we're forced to make sub-page range checks. To allow RISC-V emulation to do a probe_acess_flags() that covers PMP, we need to either add a 'size' param to the existing probe_acess_flags() or create a new interface (e.g. probe_access_range_flags). There are quite a few probe_* APIs already, so let's add a 'size' param to probe_access_flags() and re-use this API. This is done by open coding what probe_access_full() does inside probe_acess_flags() and passing the 'size' param to probe_acess_internal(). Existing probe_access_flags() callers use size = 0 to not change their current API usage. 'size' is asserted to enforce single page access like probe_access() already does. No behavioral changes intended. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230223234427.521114-2-dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-02-28Merge tag 'buildsys-qom-qdev-ui-20230227' of https://github.com/philmd/qemu ↵Peter Maydell
into staging - buildsys - Various header cleaned up (removing pointless headers) - Mark various files/code user/system specific - Make various objects target-independent - Remove tswapN() calls from dump.o - Suggest g_assert_not_reached() instead of assert(0) - qdev / qom - Replace various container_of() by QOM cast macros - Declare some QOM macros using OBJECT_DECLARE_TYPE() - Embed OHCI QOM child in SM501 chipset - hw (ISA & IDE) - add some documentation, improve function names - un-inline, open-code few functions - have ISA API accessing IRQ/DMA prefer ISABus over ISADevice - Demote IDE subsystem maintenance to "Odd Fixes" - ui: Improve Ctrl+Alt hint on Darwin Cocoa # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmP9IeAACgkQ4+MsLN6t # wN7bdQ//SxJYJuQvqTT6s+O0LmP6NbqvhxCXX7YAwK2jCTM+zTgcqqRZCcisLQol # 3ENu2UhnZmiLKHSOxatOVozbws08/u8Vl+WkW4UTMUb1yo5KPaPtq808Y95RdAJB # 7D7B5juDGnFRAHXZz38zVk9uIuEkm+Po/pD0JQa+upBtAAgOJTqGavDNSR5+T0Yl # VjGdwK0b10skPqiF6OABYoy/4IFHVJJFIbARZh+a7hrF0llsbzUts5JiYsOxEEHQ # t3woUItdMnS1m0+Ty4AQ8m0Yv9y4HZOIzixvsZ+vChj5ariwUhL9/7wC/s/UCYEg # gKVA5X8R6n/ME6DScK99a+CyR/MXkz70b/rOUZxoutXhV3xdh4X1stL4WN9W/m3z # D4i4ZrUsDUcKCGWlj49of/dKbOPwk1+e/mT0oDZD6JzG0ODjfdVxvJ/JEV2iHgS3 # WqHuSKzX/20H9j7/MgfbQ0HjBFOQ8tl781vQzhD+y+cF/IiTsHhrE6esIWho4bob # kfSdVydUWWRnBsnyGoRZXoEMX9tn+pu0nKxEDm2Bo2+jajsa0aZZPokgjxaz4MnD # Hx+/p1E+8IuOn05JgzQSgTJmKFdSbya203tXIsTo1kL2aJTJ6QfMvgEPP/fkn+lS # oQyVBFZmb1JDdTM1MxOncnlWLg74rp/CWEc+u5pSdbxMO/M/uac= # =AV/+ # -----END PGP SIGNATURE----- # gpg: Signature made Mon 27 Feb 2023 21:34:24 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown] # 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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * tag 'buildsys-qom-qdev-ui-20230227' of https://github.com/philmd/qemu: (125 commits) ui/cocoa: user friendly characters for release mouse dump: Add create_win_dump() stub for non-x86 targets dump: Simplify compiling win_dump.o by introducing win_dump_available() dump: Clean included headers dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size() dump: Replace tswapN() -> cpu_to_dumpN() hw/ide/pci: Add PCIIDEState::isa_irq[] hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS hw/ide/piix: Refactor pci_piix_init_ports as pci_piix_init_bus per bus hw/ide/piix: Pass Error* to pci_piix_init_ports() for better error msg hw/ide/piix: Remove unused includes hw/ide/pci: Unexport bmdma_active_if() hw/ide/ioport: Remove unnecessary includes hw/ide: Declare ide_get_[geometry/bios_chs_trans] in 'hw/ide/internal.h' hw/ide: Rename idebus_active_if() -> ide_bus_active_if() hw/ide: Rename ide_init2() -> ide_bus_init_output_irq() hw/ide: Rename ide_exec_cmd() -> ide_bus_exec_cmd() hw/ide: Rename ide_register_restart_cb -> ide_bus_register_restart_cb hw/ide: Rename ide_create_drive() -> ide_bus_create_drive() hw/ide: Rename ide_set_irq() -> ide_bus_set_irq() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-02-27hw: Move ioapic*.h to intc/Bernhard Beschow
The ioapic sources reside in hw/intc already. Move the headers there as well. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230213173033.98762-11-shentey@gmail.com> [PMD: Keep ioapic_internal.h in hw/intc/, not under include/] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-02-27target/tricore: Remove unused fields from CPUTriCoreStatePhilippe Mathieu-Daudé
Remove dead code: - unused fields in CPUTriCoreState - (unexisting) tricore_def_t structure - forward declaration of tricore_boot_info structure (declared in "hw/tricore/tricore.h", used once in hw/tricore/tricore_testboard.c). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Message-Id: <20230117184217.83305-1-philmd@linaro.org>
2023-02-27target/xtensa/cpu: Include missing "memory.h" headerPhilippe Mathieu-Daudé
Under system emulation, xtensa_cpu_initfn() calls memory_region_init_io(), itself declared in "exec/memory.h". Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221217172907.8364-10-philmd@linaro.org>
2023-02-27target/sparc/sysemu: Remove pointless CONFIG_USER_ONLY guardPhilippe Mathieu-Daudé
Commit caac44a52a ("target/sparc: Make sparc_cpu_tlb_fill sysemu only") restricted mmu_helper.c to system emulation. Checking whether CONFIG_USER_ONLY is defined is now pointless. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221217172907.8364-9-philmd@linaro.org>
2023-02-27target/riscv/cpu: Move Floating-Point fields closerPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221217172907.8364-7-philmd@linaro.org>
2023-02-27target/ppc: Fix warning with clang-15Pierrick Bouvier
When compiling for windows-arm64 using clang-15, it reports a sometimes uninitialized variable. This seems to be a false positive, as a default case guards switch expressions, preventing to return an uninitialized value, but clang seems unhappy with assert(0) definition. Change code to g_assert_not_reached() fix the warning. Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230221153006.20300-5-pierrick.bouvier@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-02-27target/ppc/kvm: Remove unused "sysbus.h" headerPhilippe Mathieu-Daudé
Nothing requires SysBus declarations here. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221217172907.8364-6-philmd@linaro.org>
2023-02-27target/ppc/internal: Restrict MMU declarations to sysemuPhilippe Mathieu-Daudé
The 'hwaddr' type is only available / meaningful on system emulation. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221217172907.8364-5-philmd@linaro.org>
2023-02-27target/loongarch/cpu: Restrict "memory.h" header to sysemuPhilippe Mathieu-Daudé
Missed in 0093b9a5ee ("target/loongarch: Adjust functions and structure to support user-mode") while cleaning commit f84a2aacf5 ("target/loongarch: Add LoongArch IOCSR instruction"). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221217172907.8364-4-philmd@linaro.org>
2023-02-27target/loongarch/cpu: Remove unused "sysbus.h" headerBernhard Beschow
The cpu is used in both user and system emulation context while sysbus.h is system-only. Remove it since it's not needed anyway. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221217172907.8364-3-philmd@linaro.org>
2023-02-27target/alpha: Remove obsolete STATUS documentPhilippe Mathieu-Daudé
Likely out of sync: last update is from 2008 (commit d1412eb240), 12 years ago. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221217172907.8364-2-philmd@linaro.org>
2023-02-27target/hppa: Extract system helpers to sys_helper.cPhilippe Mathieu-Daudé
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221217173219.8715-3-philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-02-27target/hppa: Extract FPU helpers to fpu_helper.cPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221217173219.8715-2-philmd@linaro.org>
2023-02-27target/i386: Remove x86_cpu_dump_local_apic_state() dead stubPhilippe Mathieu-Daudé
x86_cpu_dump_local_apic_state() is called from monitor.c which is only compiled for system emulation since commit bf95728400 ("monitor: remove target-specific code from monitor.c"). Interestingly this stub was added few weeks later in commit 1f871d49e3 ("hmp: added local apic dump state") and was not necessary by that time. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221216220158.6317-5-philmd@linaro.org>
2023-02-27target/i386/cpu: Remove dead helper_lock() declarationPhilippe Mathieu-Daudé
Missed in commit 37b995f6e7 ("target-i386: remove helper_lock()"). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20221216220158.6317-3-philmd@linaro.org>