- 17 Nov, 2021 4 commits
-
-
Roger Pau Monné authored
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Roger Pau Monné authored
Set the grant table version for the created domains to use version 1, as such tests domains don't require the usage of the grant table at all. A TODO note is added to switch those dummy domains to not have a grant table at all when possible. Without setting the grant version the domains for the tests cannot be created. Fixes: 7379f9e1 ('gnttab: allow setting max version per-domain') Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Roger Pau Monné authored
Set the grant table version for the created domains to use version 1, as that's the used by the test cases. Without setting the grant version the domains for the tests cannot be created. Fixes: 7379f9e1 ('gnttab: allow setting max version per-domain') Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Roger Pau Monné authored
Such macro just clamps the passed version to fit in the designated bits of the domctl field. The main purpose is to make it clearer in the code when max grant version is being set in the grant_opts field. Existing users that where setting the version in the grant_opts field are switched to use the macro. No functional change intended. Requested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Acked-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 16 Nov, 2021 1 commit
-
-
Jan Beulich authored
With there being a way to disable v2 support, telling new guests to use v2 exclusively is not a good suggestion. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 12 Nov, 2021 3 commits
-
-
Jane Malalane authored
Previously, we checked that we could map 40 pages with nothing complaining. Now we're adding extra logic to check that those 40 frames are "correct". Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jane Malalane <jane.malalane@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
Roger Pau Monne authored
CPUID policies from guest being migrated shouldn't have the maximum leaves shrink, as that would be a guest visible change. The hypervisor has no knowledge on whether a guest has been migrated or is build from scratch, and hence it must not blindly shrink the CPUID policy in recalculate_cpuid_policy. Remove the x86_cpuid_policy_shrink_max_leaves call from recalculate_cpuid_policy. Removing such call could be seen as a partial revert of 540d911c. Instead let the toolstack shrink the policies for newly created guests, while keeping the previous values for guests that are migrated in. Note that guests migrated in without a CPUID policy won't get any kind of shrinking applied. Fixes: 540d911c ('x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Jan Beulich authored
With no upper bound (anymore) on the number of IOMMUs, a fixed-size 64-bit map may be insufficient (systems with 40 IOMMUs have already been observed). Fixes: 27713fa2 ("VT-d: improve save/restore of registers across S3") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 11 Nov, 2021 3 commits
-
-
Stefano Stabellini authored
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Acked-by: Bertrand Marquis <bertrand.marquis@arm.com> Acked-by: Julien Grall <jgrall@amazon.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Stefano Stabellini authored
allocate_bank_memory can be called with a tot_size of zero, as an example see the implementation of allocate_memory which can call allocate_bank_memory with a tot_size of zero for the second memory bank. If tot_size == 0, don't create an empty memory bank, just return immediately without error. Otherwise a zero-size memory bank will be added to the domain device tree. Note that Linux is known to be able to cope with zero-size memory banks, and Xen more recently gained the ability to do so as well (5a37207d "xen/arm: bootfdt: Ignore empty memory bank"). However, there might be other non-Linux OSes that are not able to cope with empty memory banks as well as Linux (and now Xen). It would be more robust to avoid zero-size memory banks unless required. Moreover, the code to find empty address regions in make_hypervisor_node in Xen is not able to cope with empty memory banks today and would result in a Xen crash. This is only a latent bug because make_hypervisor_node is only called for Dom0 at present and allocate_memory is only called for DomU at the moment. (But if make_hypervisor_node was to be called for a DomU, then the Xen crash would become manifest.) Fixes: f2931b42 ("xen/arm: introduce allocate_memory") Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Stefano Stabellini authored
DomUs static-mem ranges are added to the reserved_mem array for accounting, but they shouldn't be assigned to dom0 as the other regular reserved-memory ranges in device tree. In make_memory_nodes, fix the error by skipping banks with xen_domain set to true in the reserved-memory array. Also make sure to use the first valid (!xen_domain) start address for the memory node name. Fixes: 41c031ff ("xen/arm: introduce domain on Static Allocation") Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Penny Zheng <penny.zheng@arm.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 09 Nov, 2021 1 commit
-
-
Roger Pau Monne authored
iPXE is only used by QEMU traditional, so make it off by default unless QEMU traditional is enabled. Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Fixes: bcf77ce5 ('configure: modify default of building rombios') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Ian Jackson <iwj@xenproject.org>
-
- 08 Nov, 2021 2 commits
-
-
Roger Pau Monne authored
Introduce a new domain create field so that toolstack can specify the maximum grant table version usable by the domain. This is plumbed into xl and settable by the user as max_grant_version. Previously this was only settable on a per host basis using the gnttab command line option. Note the version is specified using 4 bits, which leaves room to specify up to grant table version 15. Given that we only have 2 grant table versions right now, and a new version is unlikely in the near future using 4 bits seems more than enough. xenstored stubdomains are limited to grant table v1 because the current MiniOS code used to build them only has support for grants v1. There are existing limits set for xenstored stubdomains at creation time that already match the defaults in MiniOS. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Reviewed-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Andrew Cooper <andr...
-
Andrew Cooper authored
In order to let the toolstack be able to set the gnttab version on a per-domain basis, it needs to know which ABIs Xen supports. Introduce XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the purpose, and plumb in down into userspace. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Reviewed-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Releae-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 05 Nov, 2021 1 commit
-
-
Luca Fancellu authored
The code introduced by commit a1743fc3 ("arm/efi: Use dom0less configuration when using EFI boot") is introducing a problem to boot Xen using Grub2 on ARM machine using EDK2. Despite UEFI specification, EDK2+Grub2 is returning a NULL DeviceHandle inside the interface given by the LOADED_IMAGE_PROTOCOL service, this handle is used later by efi_bs->HandleProtocol(...) inside get_parent_handle(...) when requesting the SIMPLE_FILE_SYSTEM_PROTOCOL interface, causing Xen to stop the boot because of an EFI_INVALID_PARAMETER error. Before the commit above, the function was never called because the logic was skipping the call when there were multiboot modules in the DT because the filesystem was never used and the bootloader had put in place all the right modules in memory and the addresses in the DT. To fix the problem the old logic is put back in place. Because the handle was given to the efi_check_dt_boot(...), but the revert put the handle out of scope, the signature of the function is changed to use an EFI_LOADED_IMAGE handle and request the EFI_FILE_HANDLE only when needed (module found using xen,uefi-binary). Another problem is found when the UEFI stub tries to check if Dom0 image or DomUs are present. The logic doesn't work when the UEFI stub is not responsible to load any modules, so the efi_check_dt_boot(...) return value is modified to return the number of multiboot module found and not only the number of module loaded by the stub. Taking the occasion to update the comment in handle_module_node(...) to explain why we return success even if xen,uefi-binary is not found. Fixes: a1743fc3 ("arm/efi: Use dom0less configuration when using EFI boot") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
-
- 04 Nov, 2021 6 commits
-
-
Juergen Gross authored
Using qemu-traditional as device model is deprecated for some time now. So change the default for building it to "disable". This will affect ioemu-stubdom, too, as there is a direct dependency between the two. Today it is possible to use a PVH/HVM Linux-based stubdom as device model. Additionally using ioemu-stubdom isn't really helping for security, as it requires to run a very old and potentially buggy qemu version in a PV domain. This is adding probably more security problems than it is removing by using a stubdom. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by: Ian Jackson <iwj@xenproject.org> Release-acked-by: Ian Jackson <iwj@xenproject.org>
-
Juergen Gross authored
The tools/configure script will default to build rombios if qemu traditional is enabled. If rombios is being built, ipxe will be built per default, too. This results in rombios and ipxe no longer being built by default when disabling qemu traditional. Fix that be rearranging the dependencies: - build ipxe by default - build rombios by default if either ipxe or qemu traditional are being built This modification prepares not building qemu traditional by default without affecting build of rombios and ipxe. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Ian Jackson <iwj@xenproject.org> Release-acked-by: Ian Jackson <iwj@xenproject.org>
-
Juergen Gross authored
Commit 1787cc16 ("libs/guest: Move the guest ABI check earlier into xc_dom_parse_image()") broke starting the xenstore stubdom. This is due to a rather special way the xenstore stubdom domain config is being initialized: in order to support both, PV and PVH stubdom, init-xenstore-domain is using xc_dom_parse_image() to find the correct domain type. Unfortunately above commit requires xc_dom_boot_xen_init() to have been called before using xc_dom_parse_image(). This requires the domid, which is known only after xc_domain_create(), which requires the domain type. In order to break this circular dependency, call xc_dom_boot_xen_init() with an arbitrary domid first, and then set dom->guest_domid later. Fixes: 1787cc16 ("libs/guest: Move the guest ABI check earlier into xc_dom_parse_image()") Signed-off-by: Juergen Gross <jgross@suse.com> Release-acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
Jan Beulich authored
The value it returns may change from true to false in case iommu_enable_x2apic() fails and, as a side effect, clears iommu_intremap (as can happen at least on AMD). Latch the return value from the first invocation to replace the second one. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Jan Beulich authored
x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC mode (physical vs clustered) depends on iommu_intremap, that variable needs to be set to off as soon as we know we can't / won't enable interrupt remapping, i.e. in particular when parsing of the respective ACPI tables failed. Move the turning off of iommu_intremap from AMD specific code into acpi_iommu_init(), accompanying it by clearing of iommu_enable. Take the opportunity and also fully skip ACPI table parsing logic on VT-d when both "iommu=off" and "iommu=no-intremap" are in effect anyway, like was already the case for AMD. The tag below only references the commit uncovering a pre-existing anomaly. Fixes: d8bd8232 ("AMD/IOMMU: obtain IVHD type to use earlier") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Marek Marczykowski-Górecki authored
set_xcr0() and set_msr_xss() use cached value to avoid setting the register to the same value over and over. But suspend/resume implicitly reset the registers and since percpu areas are not deallocated on suspend anymore, the cache gets stale. Reset the cache on resume, to ensure the next write will really hit the hardware. Choose value 0, as it will never be a legitimate write to those registers - and so, will force write (and cache update). Note the cache is used io get_xcr0() and get_msr_xss() too, but: - set_xcr0() is called few lines below in xstate_init(), so it will update the cache with appropriate value - get_msr_xss() is not used anywhere - and thus not before any set_msr_xss() that will fill the cache Fixes: aca2a985 "xen: don't free percpu areas during suspend" Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 03 Nov, 2021 7 commits
-
-
Andrew Cooper authored
The call to debugger_trap_entry() should pass the correct vector. The break-for-gdbsx logic is in practice unreachable because PV guests can't generate #CP, but it will interfere with anyone inserting custom debugging into debugger_trap_entry(). Fixes: 5ad05b9c ("x86/traps: Implement #CP handler and extend #PF for shadow stacks") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Oleksandr Andrushchenko authored
While in vPCI MMIO trap handlers for the guest PCI host bridge it is not enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as the base address may not be aligned in the way that the translation always work. If not adjusted with respect to the base address it may not be able to properly convert SBDF. Fix this by adjusting the gpa with respect to the host bridge base address in a way as it is done for x86. Please note, that this change is not strictly required given the current value of GUEST_VPCI_ECAM_BASE which has bits 0 to 27 clear, but could cause issues if such value is changed, or when handlers for dom0 ECAM regions are added as those will be mapped over existing hardware regions that could use non-aligned base addresses. Fixes: d59168dc ("xen/arm: Enable the existing x86 virtual PCI support for ARM") Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Ian Jackson authored
Unfortunately this breaks the gitlab CI. See mails on-list. This reverts commit ce309942.
-
Andrew Cooper authored
The call to setup_cpu_root_pgt(0) in smp_prepare_cpus() is too early. It clones the BSP's stack while the .data mapping is still in use, causing all mappings to be fully read read/write (and with no guard pages either). This ultimately causes #DF when trying to enter the dom0 kernel for the first time. Defer setting up BSPs XPTI pagetable until reinit_bsp_stack() after we've set up proper shadow stack permissions. Fixes: 60016604 ("x86/shstk: Rework the stack layout to support shadow stacks") Fixes: b60ab42d ("x86/shstk: Activate Supervisor Shadow Stacks") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Juergen Gross authored
Using qemu-traditional as device model is deprecated for some time now. So change the default for building it to "disable". This will affect ioemu-stubdom, too, as there is a direct dependency between the two. Today it is possible to use a PVH/HVM Linux-based stubdom as device model. Additionally using ioemu-stubdom isn't really helping for security, as it requires to run a very old and potentially buggy qemu version in a PV domain. This is adding probably more security problems than it is removing by using a stubdom. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Dongli Zhang authored
The guest may access the pv vcpu_time_info immediately after VCPUOP_register_vcpu_info. This is to borrow the idea of VCPUOP_register_vcpu_time_memory_area, where the force_update_vcpu_system_time() is called immediately when the new memory area is registered. Otherwise, we may observe clock drift at the VM side if the VM accesses the clocksource immediately after VCPUOP_register_vcpu_info(). Reference: https://lists.xenproject.org/archives/html/xen-devel/2021-10/msg00571.html Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
Jan Beulich authored
As of 724b55f4 ("x86: introduce MWAIT-based, ACPI-less CPU idle driver") they (also) live in asm/mwait.h; no idea how I missed the duplicates back at the time. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 01 Nov, 2021 2 commits
-
-
Ian Jackson authored
Signed-off-by: Ian Jackson <iwj@xenproject.org>
-
Ian Jackson authored
Signed-off-by: Ian Jackson <iwj@xenproject.org>
-
- 29 Oct, 2021 4 commits
-
-
Stefano Stabellini authored
Introduce a test based on QEMU to run Xen, Dom0 and start a DomU. This is similar to the existing qemu-alpine-arm64.sh script and test. The only differences are: - use Debian's qemu-system-x86_64 (on ARM we build our own) - use ipxe instead of u-boot and ImageBuilder Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
-
Stefano Stabellini authored
Build a 5.10 kernel to be used as Dom0 and DomU kernel for testing. This is almost the same as the existing ARM64 recipe for Linux 5.9, the only differences are: - upgrade to latest 5.10.x stable - force Xen modules to built-in (on ARM it was already done by defconfig) Also add the exporting job to build.yaml so that the binary can be used during gitlab-ci runs. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
-
Stefano Stabellini authored
It is the same as the existing ARM64 alpine 3.12 test-artifact. It is used to export an Alpine rootfs for Dom0 used for testing. Also add the exporting job to build.yaml so that the binaries can be used during gitlab-ci runs. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
-
Roger Pau Monne authored
In order to be compatible with previous Xen versions, and not change max hypervisor leaf as a result of a migration, keep the clamping of the maximum leaf value provided to XEN_CPUID_MAX_NUM_LEAVES, instead of doing it based on the domain type. Also set the default maximum leaf without taking the domain type into account. The maximum hypervisor leaf is not migrated, so we need the default to not regress beyond what might already be reported to a guest by existing Xen versions. This is a partial revert of 540d911c and restores the previous behaviour and assures that HVM guests won't see it's maximum hypervisor leaf reduced from 5 to 4 as a result of a migration. Fixes: 540d911c ('x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents') Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 27 Oct, 2021 1 commit
-
-
Roger Pau Monne authored
Always allow the HPET to be setup, but don't report a frequency back to the platform time source probe in order to avoid it from being selected as a valid timer if it's not usable. Doing the setup even when not intended to be used as a platform timer is required so that is can be used in legacy replacement mode in order to assert the IO-APIC is capable of receiving interrupts. Fixes: c1273149 ('x86/hpet: Use another crystalball to evaluate HPET usability') Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
-
- 25 Oct, 2021 1 commit
-
-
Anthony PERARD authored
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
- 21 Oct, 2021 2 commits
-
-
Hongda Deng authored
Currently, Xen will return IO unhandled when guests write ICPENDR* virtual registers, which will raise a data abort inside the guest. For Linux guest, these virtual registers will not be accessed. But for Zephyr, these virtual registers will be accessed during the initialization. Zephyr guest will get an IO data abort and crash. Emulating ICPENDR is not easy with the existing vGIC, this patch reworks the emulation to ignore write access to ICPENDR* virtual registers and print a message about whether they are already pending instead of returning unhandled. More details can be found at [1]. [1] https://github.com/zephyrproject-rtos/zephyr/blob/eaf6cf745df3807e6e cc941c3a30de6c179ae359/drivers/interrupt_controller/intc_gicv3.c#L274 Signed-off-by: Hongda Deng <hongda.deng@arm.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Julien Grall <jgrall@amazon.com>
-
Julien Grall authored
Commit 939775cf "handle dying domains in live update" was meant to handle gracefully dying domain. However, the @releaseDomain watch will end up to be sent as soon as we finished to restore Xenstored state. This may be before Xen reports the domain to be dying (such as if the guest decided to revoke access to the xenstore page). Consequently daemon like xenconsoled will not clean-up the domain and it will be left as a zombie. To avoid the problem, mark the connection as ignored. This also requires to tweak conn_can_write() and conn_can_read() to prevent dereferencing a NULL pointer (the interface will not mapped). The check conn->is_ignored was originally added after the callbacks because the helpers for a socket connection may close the fd. However, ignore_connection() will close a socket connection directly. So it is fine to do the re-order. Signed-off-by: Julien Grall <jgrall@amazon.com> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
-
- 20 Oct, 2021 2 commits
-
-
Bertrand Marquis authored
Xen might not be able to discover at boot time all devices or some devices might appear after specific actions from dom0. In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some PCI devices to Xen. As those devices where not known from Xen before, the vpci handlers must be properly installed during pci_device_add for x86 PVH Dom0, in the same way as what is done currently on arm (where Xen does not detect PCI devices but relies on Dom0 to declare them all the time). So this patch is removing the ifdef protecting the call to vpci_add_handlers and the comment which was arm specific. vpci_add_handlers is called on during pci_device_add which can be called at runtime through hypercall physdev_op. Remove __hwdom_init as the call is not limited anymore to hardware domain init and fix linker script to only keep vpci_array in rodata section. Add missing vpci handlers cleanup during pci_device_remove and in case of error with iommu during pci_device_add. Move code adding the domain to the pdev domain_list as vpci_add_handlers needs this to be set and remove it from the list in the error path. Exit early of vpci_remove_device if the domain has no vpci support. Add empty static inline for vpci_remove_device when CONFIG_VPCI is not defined. Add an ASSERT in vpci_add_handlers to check that the function is not called twice for the same device. Fixes: d59168dc ("xen/arm: Enable the existing x86 virtual PCI support for ARM") Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
-
Thomas Gleixner authored
On recent Intel systems the HPET stops working when the system reaches PC10 idle state. The approach of adding PCI ids to the early quirks to disable HPET on these systems is a whack a mole game which makes no sense. Check for PC10 instead and force disable HPET if supported. The check is overbroad as it does not take ACPI, mwait-idle enablement and command line parameters into account. That's fine as long as there is at least PMTIMER available to calibrate the TSC frequency. The decision can be overruled by adding "clocksource=hpet" on the Xen command line. Remove the related PCI quirks for affected Coffee Lake systems as they are not longer required. That should also cover all other systems, i.e. Ice Lake, Tiger Lake, and newer generations, which are most likely affected by this as well. Fixes: Yet another hardware trainwreck Reported-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> [Linux commit: 6e3cd95234dc1eda488f4f487c281bac8fef4d9b] I have to admit that the purpose of checking CPUID5_ECX_INTERRUPT_BREAK is unclear to me, but I didn't want to diverge in technical aspects from the Linux commit. In mwait_pc10_supported(), besides some cosmetic adjustments, avoid UB from shifting left a signed 4-bit constant by 28 bits. Pull in Linux'es MSR_PKG_CST_CONFIG_CONTROL. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
-