On 2024/8/19 17:08, Jan Beulich wrote:
> On 16.08.2024 13:08, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>> a passthrough device by using gsi, see qemu code
>> xen_pt_realize->xc_physdev_map_pirq and libxl code
>> pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
>> will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
>> is not allowed because currd is PVH dom0 and PVH has no
>> X86_EMU_USE_PIRQ flag, it will fail at has_pirq check.
>>
>> So, allow PHYSDEVOP_map_pirq when dom0 is PVH and also allow
>> iPHYSDEVOP_unmap_pirq for the removal device path to unmap pirq.
>> So that the interrupt of a passthrough device can be successfully
>> mapped to pirq for domU with a notion of PIRQ when dom0 is PVH.
>>
>> To exposing the functionality to wider than (presently) necessary
>> audience(like PVH domU), so it doesn't add any futher restrictions.
>
> The code change is fine, but I'm struggling with this sentence. I can't
> really derive what you're trying to say.
Ah, I wanted to explain why this path not add any further restrictions, then
used your comments of last version.
How do I need to change this explanation?
>
>> And there already are some senarios for domains without
>> X86_EMU_USE_PIRQ to use these functions.
>
> Are there? If so, pointing out an example may help.
If I understand correctly, Roger mentioned that PIRQs is disable by default for
HVM guest("hvm_pirq=0") and passthrough device to guest.
In this scene, guest doesn't have PIRQs, but it still needs this hypercall.
>
> Jan
--
Best regards,
Jiqian Chen.
