On 20.08.2024 08:12, Chen, Jiqian wrote:
> 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?
I think you want to take Roger's earlier comments (when he requested
the relaxation) as basis to re-write (combine) both of the latter two
paragraphs above (or maybe even all three of them). It's odd to first
talk about Dom0, as if the operations were to be exposed just there,
and only then add DomU-s.
>>> 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.
In which case please say so in order to be concrete, not vague.
Jan
