Re: [RFC KERNEL PATCH v2 2/3] xen/pvh: Unmask irq for passthrough device in PVH dom0

[Chen, Jiqian]

On 2023/12/11 23:45, Roger Pau Monné wrote:
> On Wed, Dec 06, 2023 at 06:07:26AM +0000, Chen, Jiqian wrote:
>>
>> When PVH dom0 enable a device, it will get trigger and polarity from ACPI (see acpi_pci_irq_enable)
>> I have a version of patch which tried that way, see below:
>>
>> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
>> index ada3868c02c2..43e1bda9f946 100644
>> --- a/arch/x86/xen/enlighten_pvh.c
>> +++ b/arch/x86/xen/enlighten_pvh.c
>> @@ -1,6 +1,7 @@
>>  // SPDX-License-Identifier: GPL-2.0
>>  #include <linux/acpi.h>
>>  #include <linux/export.h>
>> +#include <linux/pci.h>
>>
>>  #include <xen/hvc-console.h>
>>
>> @@ -25,6 +26,127 @@
>>  bool __ro_after_init xen_pvh;
>>  EXPORT_SYMBOL_GPL(xen_pvh);
>>
>> +typedef struct gsi_info {
>> +       int gsi;
>> +       int trigger;
>> +       int polarity;
>> +       int pirq;
>> +} gsi_info_t;
>> +
>> +struct acpi_prt_entry {
>> +       struct acpi_pci_id      id;
>> +       u8                      pin;
>> +       acpi_handle             link;
>> +       u32                     index;          /* GSI, or link _CRS index */
>> +};
>> +
>> +static int xen_pvh_get_gsi_info(struct pci_dev *dev,
>> +                                                               gsi_info_t *gsi_info)
>> +{
>> +       int gsi;
>> +       u8 pin = 0;
>> +       struct acpi_prt_entry *entry;
>> +       int trigger = ACPI_LEVEL_SENSITIVE;
>> +       int polarity = acpi_irq_model == ACPI_IRQ_MODEL_GIC ?
>> +                                     ACPI_ACTIVE_HIGH : ACPI_ACTIVE_LOW;
>> +
>> +       if (dev)
>> +               pin = dev->pin;
>> +       if (!pin) {
>> +               xen_raw_printk("No interrupt pin configured\n");
>> +               return -EINVAL;
>> +       }
>> +
>> +       entry = acpi_pci_irq_lookup(dev, pin);
>> +       if (entry) {
>> +               if (entry->link)
>> +                       gsi = acpi_pci_link_allocate_irq(entry->link,
>> +                                                        entry->index,
>> +                                                        &trigger, &polarity,
>> +                                                        NULL);
>> +               else
>> +                       gsi = entry->index;
>> +       } else
>> +               return -EINVAL;
>> +
>> +       gsi_info->gsi = gsi;
>> +       gsi_info->trigger = trigger;
>> +       gsi_info->polarity = polarity;
>> +
>> +       return 0;
>> +}
>> +
>> +static int xen_pvh_map_pirq(gsi_info_t *gsi_info)
>> +{
>> +       struct physdev_map_pirq map_irq;
>> +       int ret;
>> +
>> +       map_irq.domid = DOMID_SELF;
>> +       map_irq.type = MAP_PIRQ_TYPE_GSI;
>> +       map_irq.index = gsi_info->gsi;
>> +       map_irq.pirq = gsi_info->gsi;
>> +
>> +       ret = HYPERVISOR_physdev_op(PHYSDEVOP_map_pirq, &map_irq);
>> +       gsi_info->pirq = map_irq.pirq;
>> +
>> +       return ret;
>> +}
>> +
>> +static int xen_pvh_unmap_pirq(gsi_info_t *gsi_info)
>> +{
>> +       struct physdev_unmap_pirq unmap_irq;
>> +
>> +       unmap_irq.domid = DOMID_SELF;
>> +       unmap_irq.pirq = gsi_info->pirq;
>> +
>> +       return HYPERVISOR_physdev_op(PHYSDEVOP_unmap_pirq, &unmap_irq);
>> +}
>> +
>> +static int xen_pvh_setup_gsi(gsi_info_t *gsi_info)
>> +{
>> +       struct physdev_setup_gsi setup_gsi;
>> +
>> +       setup_gsi.gsi = gsi_info->gsi;
>> +       setup_gsi.triggering = (gsi_info->trigger == ACPI_EDGE_SENSITIVE ? 0 : 1);
>> +       setup_gsi.polarity = (gsi_info->polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
>> +
>> +       return HYPERVISOR_physdev_op(PHYSDEVOP_setup_gsi, &setup_gsi);
>> +}
> 
> Hm, why not simply call pcibios_enable_device() from pciback?  What
pcibios_enable_device had been called when using cmd "xl pci-assignable-add sbdf" from pciback. But it didn't do map_pirq and setup_gsi.
Because pcibios_enable_device-> pcibios_enable_irq-> __acpi_register_gsi(acpi_register_gsi_ioapic PVH specific)
> you are doing here using the hypercalls is a backdoor into what's done
> automatically by Xen on IO-APIC accesses by a PVH dom0.
But the gsi didn't be unmasked, and vioapic_hwdom_map_gsi is never called.
So, I think in pciback, if we can do what vioapic_hwdom_map_gsi does.
> 
> It will be much more natural for the PVH dom0 model to simply use the
> native way to configure and unmask the IO-APIC pin, and that would
> correctly setup the triggering/polarity and bind it to dom0 without
> requiring the usage of any hypercalls.
Do you still prefer that I called unmask_irq in pcistub_init_device, as this v2 patch do?
But Thomas Gleixner think it is not suitable to export unmask_irq.
> 
> Is that an issue since in that case the gsi will get mapped and bound
> to dom0?
Dom0 do map_pirq is to pass the check xc_domain_irq_permission()-> pirq_access_permitted(), 
> 
> Otherwise I would prefer if the gsi is just configured from pciback
> (PHYSDEVOP_setup_gsi) but not mapped, as allowing a PVH dom0 to map
> interrupts using PHYSDEVOP_{,un}map_pirq to itself introduces a new
> interface to manage interrupts that clashes with the native way that a
> PVH dom0 uses.
This method does map_pirq and setup_gsi only when a device is assigned to passthrough, it won't affect the other device using native way.

> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.