[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Thu, 4 Jul 2024 06:51:16 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yKe0UYjYqbi6NU5nU6YnuY/41cFqKiyH4edeqP67hNQ=; b=IF1vg2Lcm89G+o9w8E3EyZq4RahhkhC+3iGlTTOMC5xJdi8Mh74VAVbtdiPYNilhV/GdGQBQ/mjwAuUh80EMYFspxRG1GBegwEK++8bWd9YAAq68Y2iRaOiU9/oXbqyXXe4X04XtUId70hU7mjq1KSeqIQQ6D0HXDpRK+UOG00PWxsfeL0q1NwGs1ci6pjaGx+k3Jnldb2Hi5aul0mJI+EwxSxMt8wyzBEuFgccghblINlYAQ/34Efp/9SK4sEC3M/cpMAXUKXfSmdDd9ORLb8YYaApUO/zdTw55jchH5Jhz2iapOVnvXGLj5vlMiHDA2rph0qyLus38FGvjx6/cSg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WLpsVJ2TCtyrNsoLHg9NsIAhrzCGiiPZjDRKKN1InjVbdT6LB86xqfWJsGYgnVsNI1cUdlcILKIHZZHLv4Rxim0JcvRzNKMFtiuf8qjrBPAxqk6wVZVaHVKM5TUW2uRD3TOvPiUKKy/c3I7iY/UQuO6/v1OOp+svl4Fi2UdeXcnLUqph8HOW6Ol9xMi+/1T/lIpRd9cgbaU5U5UfnFchkEvjTxTKYo6xi7HjE3aiiP4GExEIHKFl1DXDMpL61t9RGTBXH7cjxEjU6YsZSBjV0iPVBu97KbkG1BRjdmHtaVc3tQRpv+jiqUw14ZrhLowC+DXXYLakl4QS9dbg1nE9DQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "Daniel P . Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "Hildebrand, Stewart" <Stewart.Hildebrand@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Thu, 04 Jul 2024 06:51:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHayunRhQS+lhfPgk6PWMYxsBafhLHhf0AAgAHJ+4D//9kSgIADSGaA//+49wCAAImYAA==
  • Thread-topic: [XEN PATCH v11 2/8] x86/pvh: Allow (un)map_pirq when dom0 is PVH

On 2024/7/4 14:38, Jan Beulich wrote:
> On 04.07.2024 04:56, Chen, Jiqian wrote:
>> On 2024/7/2 16:44, Jan Beulich wrote:
>>> On 02.07.2024 05:15, Chen, Jiqian wrote:
>>>> On 2024/7/1 15:44, Jan Beulich wrote:
>>>>> On 30.06.2024 14:33, Jiqian Chen wrote:
>>>>>> --- a/xen/arch/x86/physdev.c
>>>>>> +++ b/xen/arch/x86/physdev.c
>>>>>> @@ -323,6 +323,13 @@ ret_t do_physdev_op(int cmd, 
>>>>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>>          if ( !d )
>>>>>>              break;
>>>>>>  
>>>>>> +        /* Prevent mapping when the subject domain has no 
>>>>>> X86_EMU_USE_PIRQ */
>>>>>> +        if ( is_hvm_domain(d) && !has_pirq(d) )
>>>>>> +        {
>>>>>> +            rcu_unlock_domain(d);
>>>>>> +            return -EOPNOTSUPP;
>>>>>> +        }
>>>>>> +
>>>>>>          ret = physdev_map_pirq(d, map.type, &map.index, &map.pirq, 
>>>>>> &msi);
>>>>>>  
>>>>>>          rcu_unlock_domain(d);
>>>>>> @@ -346,6 +353,13 @@ ret_t do_physdev_op(int cmd, 
>>>>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>>          if ( !d )
>>>>>>              break;
>>>>>>  
>>>>>> +        /* Prevent unmapping when the subject domain has no 
>>>>>> X86_EMU_USE_PIRQ */
>>>>>> +        if ( is_hvm_domain(d) && !has_pirq(d) )
>>>>>> +        {
>>>>>> +            rcu_unlock_domain(d);
>>>>>> +            return -EOPNOTSUPP;
>>>>>> +        }
>>>>>> +
>>>>>>          ret = physdev_unmap_pirq(d, unmap.pirq);
>>>>>>  
>>>>>>          rcu_unlock_domain(d);
>>>>>
>>>>> If you did go look, you will have noticed that we use "return" in the 
>>>>> middle
>>>>> of this function only very sparingly (when alternatives would result in 
>>>>> more
>>>>> complicated code elsewhere). I think you want to avoid "return" here, too,
>>>>> and probably go even further and avoid the extra rcu_unlock_domain() as 
>>>>> well.
>>>>> That's easily possible to arrange for (taking the latter case as example):
>>>>>
>>>>>         /* Prevent unmapping when the subject domain has no 
>>>>> X86_EMU_USE_PIRQ */
>>>>>         if ( !is_hvm_domain(d) || has_pirq(d) )
>>>>>             ret = physdev_unmap_pirq(d, unmap.pirq);
>>>>>         else
>>>>>             ret = -EOPNOTSUPP;
>>>>>
>>>>>         rcu_unlock_domain(d);
>>>>>
>>>>> Personally I would even use a conditional operator here, but I believe
>>>>> others might dislike its use in situations like this one.
>>>>>
>>>>> The re-arrangement make a little more noticeable though that the comment
>>>>> isn't quite right either: PV domains necessarily have no
>>>>> X86_EMU_USE_PIRQ. Maybe "... has no notion of pIRQ"?
>>>>
>>>> Or just like below?
>>>>
>>>>         /*
>>>>          * Prevent unmapping when the subject hvm domain has no
>>>>          * X86_EMU_USE_PIRQ
>>>>          */
>>>>         if ( is_hvm_domain(d) && !has_pirq(d) )
>>>>             ret = -EOPNOTSUPP;
>>>>         else
>>>>             ret = physdev_unmap_pirq(d, unmap.pirq);
>>>
>>> No objection to the slightly changed comment. The code alternative you
>>> present is of course functionally identical, yet personally I prefer to
>>> have the "good" case on the "if" branch and the "bad" one following
>>> "else". I wouldn't insist, though.
>> OK, will change "good" case on the "if" branch.
>> Do I need to change "!is_hvm_domain(d)" to "is_pv_domain(d)" ?
>> And then have:
>>
>>         /* Only unmapping when the subject domain has a notion of PIRQ */
>>         if ( is_pv_domain(d) || has_pirq(d) )
>>             ret = physdev_unmap_pirq(d, unmap.pirq);
>>         else
>>             ret = -EOPNOTSUPP;
> 
> I for one would prefer if you kept using is_hvm_domain(), for being more
> precise in this situation.
OK, thanks. Will change in next version.

> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.