On Tue, Dec 12, 2023 at 06:16:43AM +0000, Chen, Jiqian wrote:
> 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.
>
I see, it does setup the IO-APIC pin but doesn't unmask it, that's
what I feared.
> > 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.
Yeah, that wasn't good.
> >
> > 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(),
Can we see about finding another way to fix this check?
One option would be granting permissions over the IRQ in
PHYSDEVOP_setup_gsi?
Otherwise we could see about modifying the logic in PHYSDEVOP_map_pirq
so that the hardware domain can map IRQs to other domains without
having it mapped to itself first?
I think the call to PHYSDEVOP_setup_gsi in pciback is fine, but I
would really like to avoid the usage of PHYSDEVOP_{,un}map_pirq on a
PVH dom0 against itself.
> >
> > 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.
It's not affected because of the specific usage in Linux, but allowing
the interface to be used against itself (so to manage interrupts
from assigned to dom0) is opening a whole new way to setup interrupts,
and it's unclear to me how that will affect the current way we use to
manage interrupts on a PVH dom0.
Thanks, Roger.
