[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v5 00/11] x86/hvm: Add Extended MSI destination ID support



Thank you Teddy and Jan for the detailed review on v4! Jan you're right,
When recently asking I didn't understand the issue with only having a
ENABLED/DISABLED for the ext_dest_id flag. Now it's clear why we need a
tri-state, but also why a tri-state is sufficient. I have converted it
to UNSET, DISABLED, or ENABLED. So, after a migration we know that if
it's still UNSET the domain is unaware of the feature and we will not
announce it no matter how many ioreq servers have opt'ed in on the new
host.

I have also split the parts that "just" move code around with no
functional changes into smaller chunks so each of them is easier to
diff:
Patch 1  x86/vioapic: check of the IOAPIC save record.
Path 2-6 Refactor pt_irq_create_bind(): brace the retry block, turn
         "goto restart" into a loop, extract pt_irq_dpci_setup(),
         extract the PT_IRQ_TYPE_MSI body into pt_irq_bind_msi() as just
         a code move, then re-indent. No functional change.
Patch 7  Switch pt_irq_bind_msi() and struct hvm_gmsi_info to the raw
         MSI address/data words, add MSI_ADDR_DEST(), reject a stored
         address that is not in 0xfeexxxxx MSI format. domctl callers
         keep working via a gflags -> message rebuild. No functional
         change for existing 8-bit-destination guests.
Patch 8  Add the tri-state d->arch.hvm.ext_dest_id and fold the extended
         bits into every call site, guarded by hvmext_dest_id_active().
         Still never enabled, so still no functional change.
Patch 9  Add XEN_DMOP_{,un}bind_pt_msi_irq (raw address/data) and remove
         PT_IRQ_TYPE_MSI from XEN_DOMCTL_{,un}bind_pt_irq. This is an
         incompatible hypercall-ABI change, recorded in CHANGELOG.md and
         public/domctl.h.
Patch 10 Negotiate the feature per ioreq server (a flags byte on
         XEN_DMOP_create_ioreq_server), level it across all servers,
         latch it at arch_domain_creation_finished(), and migrate it in
         a new HVM_SAVE_TYPE(EXT_DEST_ID) record.
Patch 11 Advertise XEN_HVM_CPUID_EXT_DEST_ID from the latched value.

I only have two remaining questions:
- As pointed out by Jan: The new DM ops now only relies on xsm_dm_op()
  for access control. Daniel Smith can you comment on, whether a
  xsm_bind_pt_irq hook is also wanted here?
- In dm.c we still use the read_lock(&d->pci_lock) around the
  bind/unbind calls, as was the case in v4. Jan you suspected no lock is
  needed there, but for now I left it as-is.

Signed-off-by: Julian Vetter <julian.vetter@xxxxxxxxxx>
---
Changes in v5:
- The domctl MSI path is no longer rejected (that broke older DMs and
  left dead code). PT_IRQ_TYPE_MSI keeps working until patch 9 removes
  it alltogether, with the now-dead pt_irq_create_bind() case deleted in
  the same step.
- pt_irq_bind_msi() rejects an address not in MSI format (0xfeexxxxx),
  so every caller storing into gmsi.addr is guaranteed a well-formed
  message.
- The ext_dest_id "bool" state is now a tri-state (UNSET / DISABLED /
  ENABLED). Every decode site folds in the extended bits only when the
  feature is active and treats them as reserved otherwise, rather than
  rejecting a guest that left values there. Removed the ioapic_check()
  extended-bit rejection loop.
- The creation_finished latch only fires while the state is UNSET, so a
  migrated value wins.
- hvm_load() resolves a record-less stream (from an "old" Xen) to
  DISABLED.
- v4's single "extract pt_irq_bind_msi()" patch is split into
  - The goto -> loop conversion is its own patch (Patch 3) and does a
    "for ( ; ; )" instead of do/while
  - A code move (Patch 4)
  - A re-indent (Patches 5, 6)
- Moved hvm_ext_dest_id_enabled() into common/ioreq.c as a function that
  iterates over ARRAY_SIZE(d->ioreq_server.server). Flag-bit validation
  is now arch specific. The Arm stub rejects any non-zero flag. Added a
  check handler for the EXT_DEST_ID save record.
- Fixed a bug in _hvm_dpci_msi_eoi(). Function tested
  XEN_DOMCTL_VMSI_X86_DM_MASK against a raw address and not against
  MSI_ADDR_DESTMODE_MASK.
- Added the missing libxendevicemodel.map VERS_1.5 entry and Makefile
  MINOR bump. The new parameter for xendevicemodel_create_ioreq_server()
  is a compatibility break for DMs, now mentioned in CHANGELOG.md.
- ioapic_check() validates base_address alignment, hap_paddr_bits and
  bounds the APIC ID by the IO_APIC_reg_02 field and the ioregsel check
  is gone, since vioapic_write() has no such restriction.
- Addressed general feedback from Jan:
  - machine_irq / gflags and the flags parameters are unsigned int
  - MSI_ADDR_DEST() derives its shift from a new MSI_ADDR_DEST_ID_WIDTH
    and leaves the existing MSI_ADDR_DEST_ID_* lines alone
  - Removed the "Intel convention" in a comment
  - MASK_EXTR / MASK_INSR used consistently
  - Removed redundant nr_pirqs check and "!!"
  - DM op debug print shortened to "%pd: fn() failed: %ld"
  - DM op struct fields are pirq / msg_addr / msg_data, the flag
    is XEN_DMOP_MSI_BIND_UNMASKED
  - gtable is documented as a guest-physical address
  - x86-specific wording is out of the public header
  - needless typedefs / blank line removed
  - The unbind op no longer requires current-domain IRQ permission.
---
Julian Vetter (11):
  x86/vioapic: Add ioapic_check() to validate IO-APIC state before
    restore
  x86/passthrough: Wrap pt_irq_create_bind() restart block in braces
  x86/passthrough: Replace pt_irq_create_bind() goto restart with a loop
  x86/passthrough: Extract pt_irq_dpci_setup() from pt_irq_create_bind()
  x86/passthrough: Extract PT_IRQ_TYPE_MSI body into pt_irq_bind_msi()
  x86/passthrough: Re-indent pt_irq_bind_msi() body
  x86/passthrough: Switch pt_irq_bind_msi() to raw MSI address/data
  x86/hvm: Decode extended MSI / IO-APIC destination IDs when opted in
  x86/dmop: Add XEN_DMOP_{,un}bind_pt_msi_irq
  hvm/ioreq: Negotiate extended destination ID support per ioreq server
  x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID

 CHANGELOG.md                                 |   6 +
 tools/include/xendevicemodel.h               |  33 +-
 tools/libs/ctrl/xc_devicemodel_compat.c      |   2 +-
 tools/libs/ctrl/xc_domain.c                  |  51 ++-
 tools/libs/devicemodel/Makefile              |   2 +-
 tools/libs/devicemodel/core.c                |  41 ++-
 tools/libs/devicemodel/libxendevicemodel.map |   6 +
 xen/arch/arm/ioreq.c                         |   6 +
 xen/arch/x86/cpuid.c                         |   8 +
 xen/arch/x86/domain.c                        |  13 +
 xen/arch/x86/domctl.c                        |  11 +-
 xen/arch/x86/hvm/dm.c                        |  66 ++++
 xen/arch/x86/hvm/ioreq.c                     |  57 +++
 xen/arch/x86/hvm/irq.c                       |   6 +-
 xen/arch/x86/hvm/save.c                      |   9 +
 xen/arch/x86/hvm/vioapic.c                   |  49 ++-
 xen/arch/x86/hvm/vmsi.c                      |  59 ++-
 xen/arch/x86/include/asm/hvm/domain.h        |  13 +
 xen/arch/x86/include/asm/hvm/hvm.h           |  12 +-
 xen/arch/x86/include/asm/hvm/irq.h           |   4 +-
 xen/arch/x86/include/asm/hvm/vioapic.h       |  10 +
 xen/arch/x86/include/asm/msi.h               |  19 +
 xen/common/ioreq.c                           |  31 +-
 xen/drivers/passthrough/x86/hvm.c            | 366 +++++++++++--------
 xen/include/public/arch-x86/hvm/save.h       |  20 +-
 xen/include/public/hvm/dm_op.h               |  51 ++-
 xen/include/xen/iommu.h                      |   3 +
 xen/include/xen/ioreq.h                      |  11 +
 xen/include/xlat.lst                         |   2 +
 29 files changed, 723 insertions(+), 244 deletions(-)

-- 
2.53.0



--
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.