|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers
>>> On 16.03.18 at 14:30, <roger.pau@xxxxxxxxxx> wrote:
> +int vpci_msix_arch_print(const struct vpci_msix *msix)
> +{
> + unsigned int i;
> +
> + for ( i = 0; i < msix->max_entries; i++ )
> + {
> + const struct vpci_msix_entry *entry = &msix->entries[i];
> +
> + printk("%6u vec=%02x%7s%6s%3sassert%5s%7s dest_id=%lu mask=%u pirq:
> %d\n",
> + i, MASK_EXTR(entry->data, MSI_DATA_VECTOR_MASK),
> + entry->data & MSI_DATA_DELIVERY_LOWPRI ? "lowest" : "fixed",
> + entry->data & MSI_DATA_TRIGGER_LEVEL ? "level" : "edge",
> + entry->data & MSI_DATA_LEVEL_ASSERT ? "" : "de",
> + entry->addr & MSI_ADDR_DESTMODE_LOGIC ? "log" : "phys",
> + entry->addr & MSI_ADDR_REDIRECTION_LOWPRI ? "lowest" :
> "fixed",
> + MASK_EXTR(entry->addr, MSI_ADDR_DEST_ID_MASK),
> + entry->masked, entry->arch.pirq);
> + if ( i && !(i % 64) )
> + {
> + struct pci_dev *pdev = msix->pdev;
> +
> + spin_unlock(&msix->pdev->vpci->lock);
> + process_pending_softirqs();
> + /* NB: we assume that pdev cannot go away for an alive domain. */
> + if ( !pdev->vpci || !spin_trylock(&pdev->vpci->lock) )
> + return -EBUSY;
> + msix = pdev->vpci->msix;
I disagree with resuming with a potentially changed msix here: This
can only lead to confusion of the consumer of the produced output.
> @@ -231,6 +232,23 @@ static int modify_bars(const struct pci_dev *pdev, bool
> map, bool rom_only)
> }
> }
>
> + /* Remove any MSIX regions if present. */
> + for ( i = 0; msix && i < ARRAY_SIZE(msix->tables); i++ )
> + {
> + paddr_t start = vmsix_table_addr(pdev->vpci, i);
> + paddr_t end = start + vmsix_table_size(pdev->vpci, i) - 1;
> +
> + rc = rangeset_remove_range(mem, PFN_DOWN(start), PFN_DOWN(end));
> + if ( rc )
> + {
> + printk(XENLOG_G_WARNING
> + "Failed to remove MSIX table [%" PRI_gfn ", %" PRI_gfn
> "]: %d\n",
> + PFN_DOWN(start), PFN_DOWN(end), rc);
In cases like this (where you don't use plain start/end anywhere,
but you do use the same calculation on them twice each), it's
certainly more efficient for the local variables to be frame numbers
right away.
Considering that I didn't notice this earlier, I won't insist on the
latter change to be made, i.e. with at least the former issue
addressed
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |