On 2024/7/1 15:52, Jan Beulich wrote: > On 30.06.2024 14:33, 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 don't get registered, it causes > > As per below, it's not "don't" but "may not". As the details don't > follow right away, you may also want to add something like "(see > below)". OK, will change in next version.
> >> 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 calls(on linux >> kernel side) pci_device_probe-> request_threaded_irq-> >> irq_startup-> __unmask_ioapic-> io_apic_write, then trap into xen >> side 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 pciback to >> probe the device, and it calls pcistub_probe->pcistub_seize-> >> pcistub_init_device-> xen_pcibk_reset_device-> >> xen_pcibk_control_isr->isr_on, but isr_on is not set, so that the >> fake IRQ handler is not installed, then the gsi isn't unmasked. >> What's more, we can see on Xen side, the function >> vioapic_hwdom_map_gsi-> mp_register_gsi will be called only when >> the gsi is unmasked, so that the gsi can't work for passthrough >> device. > > While this provides the requested detail (thanks), personally I find > this pretty hard to follow. It would likely be easier if it was > written to a larger part in English, rather than in call chain > terminology. But I'm not going to insist, unless others would agree > with that view of mine. I will add the language description in next version, and also keep the call stack if not necessary to remove. > > Jan -- Best regards, Jiqian Chen.
