1. 17 Nov, 2021 4 commits
  2. 16 Nov, 2021 1 commit
  3. 12 Nov, 2021 3 commits
  4. 11 Nov, 2021 3 commits
  5. 09 Nov, 2021 1 commit
  6. 08 Nov, 2021 2 commits
  7. 05 Nov, 2021 1 commit
    • Luca Fancellu's avatar
      xen/efi: Fix Grub2 boot on arm64 · 9bc9fff0
      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: default avatarLuca Fancellu <luca.fancellu@arm.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarBertrand Marquis <bertrand.marquis@arm.com>
      9bc9fff0
  8. 04 Nov, 2021 6 commits
  9. 03 Nov, 2021 7 commits
  10. 01 Nov, 2021 2 commits
  11. 29 Oct, 2021 4 commits
  12. 27 Oct, 2021 1 commit
  13. 25 Oct, 2021 1 commit
  14. 21 Oct, 2021 2 commits
    • Hongda Deng's avatar
      xen/arm: vgic: Ignore write access to ICPENDR* · 23ec1ebc
      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: default avatarHongda Deng <hongda.deng@arm.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      Reviewed-by: default avatarJulien Grall <jgrall@amazon.com>
      23ec1ebc
    • Julien Grall's avatar
      tools/xenstored: Ignore domain we were unable to restore · 98f60e5d
      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: default avatarJulien Grall <jgrall@amazon.com>
      Release-Acked-by: default avatarIan Jackson <iwj@xenproject.org>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarLuca Fancellu <luca.fancellu@arm.com>
      98f60e5d
  15. 20 Oct, 2021 2 commits
    • Bertrand Marquis's avatar
      xen/pci: Install vpci handlers on x86 and fix error paths · 118da371
      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: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarBertrand Marquis <bertrand.marquis@arm.com>
      Reviewed-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarJulien Grall <jgrall@amazon.com>
      118da371
    • Thomas Gleixner's avatar
      x86/hpet: Use another crystalball to evaluate HPET usability · c1273149
      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: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarThomas 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: default avatarJan Beulich <jbeulich@suse.com>
      Acked-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      c1273149