|
[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
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.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |