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

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Fri, 15 Dec 2023 07:20:24 +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=yAXjiSuuz4Ex211bdHR0aVLYn2YhKMgyPQrifGRwOxE=; b=MQrmOaW5ovK0KXtdSiEANhO5cJTqEKdu/0iJHja7sa5cTLJGoW6ABju+mgKBW5qTGNgSVwkHTKE8fChWKmd845dheNtzZR8TP2rXawXF3Fp6L4nRaG8C46UnMnx2HuqNO0mBpof+PAr2UYlrVwnkxP3ZI32TK6Y3/bT/+SeFjc8fBK2SE5Z0/u9n22tudfycZIxsBv0DL0oXDhXIlMC/ET9MRpBKuPq1bPwWMRoqlMkQRtguu21xFKwIsSVw+YOppdCr+D+ePuLRPXkbpqzcy429jBrcp8ZbAYU7upSUh7Lv+PYsWuOFF+6CVjFHwtq3NWEILJrcnxM20HnACbMkEA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lSyn2T0YLz8+PXBzt78hiC/ZLq7i3TAfFmYuC9zbU3iz+yJ5sXdsg+iVNpYEj0sBRkYS374BEJLLmwWXGVi4zMTP0aRaLVXH4mgkACyRpcR7yqoPm4wt+TZZFgpYSx+Yo4HoLE7281U8kP2HctdvZY6HAvom8XsyixKryHOMzJthSo/65igIYXvbqTJcjewXZKmCmhvHiOzNWMmOmmzB8SCGV48V12aI8jRkwJFRDlr63xtUJGaLb7JoefRu5/otcJu78UzBDKwvePSD4P2ynXjP6lg6dGeUSq9lq1OCqI2NMIprDu9APQhFLX9Ay6hZzkk+2vPc6fbItdmf0MT0Ew==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, "Daniel P . Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Hildebrand, Stewart" <Stewart.Hildebrand@xxxxxxx>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Fri, 15 Dec 2023 07:20:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHaK4ebBv/EWT+No0GAUR8lU4172LCkNzqAgAGFPID//6gjAIABpqIA///CiwCAAi33AP//lJaAAAAYnAAAAExygAAan/AAACJ1V4A=
  • Thread-topic: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On 2023/12/15 06:49, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Roger Pau Monné wrote:
>> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote:
>>> On 14.12.2023 10:55, Roger Pau Monné wrote:
>>>> On Thu, Dec 14, 2023 at 08:55:45AM +0000, Chen, Jiqian wrote:
>>>>> On 2023/12/13 15:03, Jan Beulich wrote:
>>>>>> On 13.12.2023 03:47, Chen, Jiqian wrote:
>>>>>>> On 2023/12/12 17:30, Jan Beulich wrote:
>>>>>>>> On 12.12.2023 07:49, Chen, Jiqian wrote:
>>>>>>>>> On 2023/12/11 23:31, Roger Pau Monné wrote:
>>>>>>>>>> On Mon, Dec 11, 2023 at 12:40:08AM +0800, Jiqian Chen wrote:
>>>>>>>>>>> --- a/xen/arch/x86/hvm/hypercall.c
>>>>>>>>>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>>>>>>>>>> @@ -72,8 +72,11 @@ long hvm_physdev_op(int cmd, 
>>>>>>>>>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>>>>>>>  
>>>>>>>>>>>      switch ( cmd )
>>>>>>>>>>>      {
>>>>>>>>>>> +    case PHYSDEVOP_setup_gsi:
>>>>>>>>>>
>>>>>>>>>> I think given the new approach on the Linux side patches, where
>>>>>>>>>> pciback will configure the interrupt, there's no need to expose
>>>>>>>>>> setup_gsi anymore?
>>>>>>>>> The latest patch(the second patch of v3 on kernel side) does 
>>>>>>>>> setup_gsi and map_pirq for passthrough device in pciback, so we need 
>>>>>>>>> this and below.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>      case PHYSDEVOP_map_pirq:
>>>>>>>>>>>      case PHYSDEVOP_unmap_pirq:
>>>>>>>>>>> +        if ( is_hardware_domain(currd) )
>>>>>>>>>>> +            break;
>>>>>>>>>>
>>>>>>>>>> Also Jan already pointed this out in v2: this hypercall needs to be
>>>>>>>>>> limited so a PVH dom0 cannot execute it against itself.  IOW: refuse
>>>>>>>>>> the hypercall if DOMID_SELF or the passed domid matches the current
>>>>>>>>>> domain domid.
>>>>>>>>> Yes, I remember Jan's suggestion, but since the latest patch(the 
>>>>>>>>> second patch of v3 on kernel side) has change the implementation, it 
>>>>>>>>> does setup_gsi and map_pirq for dom0 itself, so I didn't add the 
>>>>>>>>> DOMID_SELF check.
>>>>>>>>
>>>>>>>> And why exactly would it do specifically the map_pirq? (Even the 
>>>>>>>> setup_gsi
>>>>>>>> looks questionable to me, but there might be reasons there.)
>>>>>>> Map_pirq is to solve the check failure problem. (pci_add_dm_done-> 
>>>>>>> xc_domain_irq_permission-> XEN_DOMCTL_irq_permission-> 
>>>>>>> pirq_access_permitted->domain_pirq_to_irq->return irq is 0)
>>>>>>> Setup_gsi is because the gsi is never be unmasked, so the gsi is never 
>>>>>>> be registered( vioapic_hwdom_map_gsi-> mp_register_gsi is never be 
>>>>>>> called).
>>>>>>
>>>>>> And it was previously made pretty clear by Roger, I think, that doing a 
>>>>>> "map"
>>>>>> just for the purpose of granting permission is, well, at best a temporary
>>>>>> workaround in the early development phase. If there's presently no 
>>>>>> hypercall
>>>>>> to _only_ grant permission to IRQ, we need to add one.
>>>>> Could you please describe it in detail? Do you mean to add a new 
>>>>> hypercall to grant irq access for dom0 or domU?
>>>>> It seems XEN_DOMCTL_irq_permission is the hypercall to grant irq access 
>>>>> from dom0 to domU(see XEN_DOMCTL_irq_permission-> irq_permit_access). 
>>>>> There is no need to add hypercall to grant irq access.
>>>>> We failed here (XEN_DOMCTL_irq_permission-> 
>>>>> pirq_access_permitted->domain_pirq_to_irq->return irq is 0) is because 
>>>>> the PVH dom0 didn't use PIRQ, so we can't get irq from pirq if "current" 
>>>>> is PVH dom0.
>>>>
>>>> One way to bodge this would be to detect whether the caller of
>>>> XEN_DOMCTL_irq_permission is a PV or an HVM domain, and in case of HVM
>>>> assume the pirq field is a GSI.  I'm unsure however how that will work
>>>> with non-x86 architectures.
> 
> PIRQ is an x86-only concept. We have event channels but no PIRQs on ARM.
> I expect RISC-V will be the same.
> 
> 
>>>> It would  be better to introduce a new XEN_DOMCTL_gsi_permission, or
> 
> "GSI" is another x86-only concept.
> 
> So actually the best name was indeed XEN_DOMCTL_irq_permission, given
> that it is using the more arch-neutral "irq" terminology.
> 
> Perhaps it was always a mistake to pass PIRQs to
> XEN_DOMCTL_irq_permission and we should always have passed the real
> interrupt number (GSI on x86, SPI on ARM).
> 
> So your "bodge" is actually kind of OK in my opinion. Basically everyone
> else (x86 HVM/PVH, ARM, RISC-V, probably PPC too) will use
> XEN_DOMCTL_irq_permission with hardware interrupt numbers (GSIs, SPIs,
> etc.), the only special case is x86 PV. It is x86 PV the odd one.
> 
> Given that DOMCTL is an unstable interface anyway, I feel OK making
> changes to it, even better if backward compatible.
I try to understand your discussion about the modification of 
XEN_DOMCTL_irq_permission. At the xl level, gsi needs to be passed in instead 
of pirq, and then a judgment is added to XEN_DOMCTL_irq_permission, just like 
the implementation below?
diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index d3507d13a029..f665d17afbf5 100644
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1486,6 +1486,7 @@ static void pci_add_dm_done(libxl__egc *egc,
         goto out_no_irq;
     }
     if ((fscanf(f, "%u", &irq) == 1) && irq) {
+        int gsi = irq;
         r = xc_physdev_map_pirq(ctx->xch, domid, irq, &irq);
         if (r < 0) {
             LOGED(ERROR, domainid, "xc_physdev_map_pirq irq=%d (error=%d)",
@@ -1494,7 +1495,7 @@ static void pci_add_dm_done(libxl__egc *egc,
             rc = ERROR_FAIL;
             goto out;
         }
-        r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
+        r = xc_domain_irq_permission(ctx->xch, domid, gsi, 1);
         if (r < 0) {
             LOGED(ERROR, domainid,
                   "xc_domain_irq_permission irq=%d (error=%d)", irq, r);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index f5a71ee5f78d..782c4a7a70a4 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -658,7 +658,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
             ret = -EINVAL;
             break;
         }
-        irq = pirq_access_permitted(current->domain, pirq);
+
+        if ( is_hvm_domain(current->domain) )
+            irq = pirq;
+        else
+            irq = pirq_access_permitted(current->domain, pirq);
+
         if ( !irq || xsm_irq_permission(XSM_HOOK, d, irq, allow) )
             ret = -EPERM;
         else if ( allow )

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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