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

[xen staging] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0



commit 43a1f8b38ed1ec20b47bd8c3e7de3eac845057dc
Author:     Jiqian Chen <Jiqian.Chen@xxxxxxx>
AuthorDate: Mon Aug 26 10:32:05 2024 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Aug 26 10:32:05 2024 +0200

    x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0
    
    The gsi of a passthrough device must be configured for it to be
    able to be mapped into a hvm domU.
    But When dom0 is PVH, the gsis may not get registered(see below
    clarification), it causes the info of apic, pin and irq not be
    added into irq_2_pin list, and the handler of irq_desc is not set,
    then when passthrough a device, setting ioapic affinity and vector
    will fail.
    
    To fix above problem, on Linux kernel side, a new code will
    need to call PHYSDEVOP_setup_gsi for passthrough devices to
    register gsi when dom0 is PVH.
    
    So, add PHYSDEVOP_setup_gsi into hvm_physdev_op for above
    purpose.
    
    Clarify two questions:
    First, why the gsi of devices belong to PVH dom0 can work?
    Because when probe a driver to a normal device, it uses the normal
    probe function of pci device, in its callstack, it requests irq
    and unmask corresponding ioapic of gsi, then trap into xen and
    register gsi finally.
    Callstack is(on linux kernel side) pci_device_probe->
    request_threaded_irq-> irq_startup-> __unmask_ioapic->
    io_apic_write, then trap into xen hvmemul_do_io->
    hvm_io_intercept-> hvm_process_io_intercept->
    vioapic_write_indirect-> vioapic_hwdom_map_gsi-> mp_register_gsi.
    So that the gsi can be registered.
    
    Second, why the gsi of passthrough device can't work when dom0
    is PVH?
    Because when assign a device to passthrough, it uses the specific
    probe function of pciback, in its callstack, it doesn't install a
    fake irq handler due to the ISR is not running. So that
    mp_register_gsi on Xen side is never called, then the gsi is not
    registered.
    Callstack is(on linux kernel side) pcistub_probe->pcistub_seize->
    pcistub_init_device-> xen_pcibk_reset_device->
    xen_pcibk_control_isr->isr_on==0.
    
    Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx>
    Signed-off-by: Huang Rui <ray.huang@xxxxxxx>
    Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/arch/x86/hvm/hypercall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index c1bd17571e..44342e7e7f 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -80,6 +80,7 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return -ENOSYS;
         break;
 
+    case PHYSDEVOP_setup_gsi:
     case PHYSDEVOP_pci_mmcfg_reserved:
     case PHYSDEVOP_pci_device_add:
     case PHYSDEVOP_pci_device_remove:
--
generated by git-patchbot for /home/xen/git/xen.git#staging



 


Rackspace

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