On 16.08.2024 13:08, Jiqian Chen wrote: > 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.c...@amd.com> > Signed-off-by: Huang Rui <ray.hu...@amd.com> > Signed-off-by: Jiqian Chen <jiqian.c...@amd.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
