qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] kvm: deassign irqs in reset path


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] kvm: deassign irqs in reset path
Date: Sat, 31 Mar 2012 10:54:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-03-30 21:18, Jason Baron wrote:
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 89823f1..31aed17 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -1609,10 +1609,32 @@ static void reset_assigned_device(DeviceState *dev)
>  {
>      PCIDevice *pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
>      AssignedDevice *adev = DO_UPCAST(AssignedDevice, dev, pci_dev);
> +    struct kvm_assigned_irq assigned_irq_data;
>      char reset_file[64];
>      const char reset[] = "1";
>      int fd, ret;
>  
> +    /*
> +     * Make sure the irq for the device is set to a consistent state of INTx
> +     * on reset. This also ensures that a subsequent deassign_irq/assign_irq
> +     * sequence (such as during 'system_reset'), does not touch memory
> +     * mapped msi space, since we are about to disallow that access via a
> +     * 0 write to the command register. In addition, the 'kvm_deassign_irq()'
> +     * clears the msi enable bit, thus preventing any unexpected MSIs.
> +     */
> +    memset(&assigned_irq_data, 0, sizeof assigned_irq_data);
> +    assigned_irq_data.assigned_dev_id  =
> +        calc_assigned_dev_id(adev);
> +    assigned_irq_data.flags = adev->irq_requested_type;
> +    free_dev_irq_entries(adev);
> +    ret = kvm_deassign_irq(kvm_state, &assigned_irq_data);
> +    /* -ENXIO means no assigned irq */
> +    if (ret && ret != -ENXIO) {
> +        perror("reset_assigned_device: deassign irq");
> +    }
> +
> +    adev->irq_requested_type = 0;
> +

What is actually missing here, independent of the kernel bug you saw, is
a proper reset of the MSI[-X] control flags followed by a call to our
update handlers. The day we stop open-coding MSI support here, that will
be triggered by the MSI layer, but for now we need a

if (requested_type == MSI)
        clear_msi_in_shadow_cap
        update_msi
else if (requested_type == MSIX)
        clear_msix_in_shadow_cap
        update_msix

Or, better, fix the update handlers to allow unconditional

clear_msi_in_shadow_cap
update_msi
clear_msix_in_shadow_cap
update_msix

because that is the pattern we will once get from a refactored version
anyway where msi[x]_reset will be invoked automatically.

But we also need to calm down the PCI error handling to not get hysteric
over untrusted devices.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]