Re: [XEN PATCH v13 2/6] x86/pvh: Allow (un)map_pirq when dom0 is PVH

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.09.2024 08:20, Chen, Jiqian wrote:
> On 2024/9/3 14:09, Jan Beulich wrote:
>> On 03.09.2024 06:01, Chen, Jiqian wrote:
>>> On 2024/8/20 15:07, Jan Beulich wrote:
>>>> 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.
>>>
>>> I tried to understand and summarize Roger's previous comments and changed 
>>> commit message to the following. Do you think it is fine?
>>
>> What are we talking about here? 
> You had some concern about the description of commit message of this patch.
> So I send a draft below to get your opinion.
> If you forgot, I will directly send a new version(v14) later today.

I still don't get it. Yes, the patch could have done with a better
description, but ...

>> The patch was committed over a month ago?
> Yes, I sent this v13 in Aug 16, and sorry to reply late.

... it's simply too late now.

Jan