From: Jan Kiszka <jan.kiszka@web.de>
To: Jason Baron <jbaron@redhat.com>
Cc: alex.williamson@redhat.com, qemu-devel@nongnu.org,
kvm@vger.kernel.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH] kvm: deassign irqs in reset path
Date: Sat, 31 Mar 2012 10:54:02 +0200 [thread overview]
Message-ID: <4F76C62A.5040904@web.de> (raw)
In-Reply-To: <201203301918.q2UJI63c005908@int-mx02.intmail.prod.int.phx2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
prev parent reply other threads:[~2012-03-31 8:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 19:18 [Qemu-devel] [PATCH] kvm: deassign irqs in reset path Jason Baron
2012-03-30 19:29 ` Jan Kiszka
2012-03-30 20:13 ` Jason Baron
2012-03-30 20:18 ` Jan Kiszka
2012-03-30 20:31 ` Jason Baron
2012-03-30 20:35 ` Jan Kiszka
2012-03-30 21:09 ` Alex Williamson
2012-03-30 22:15 ` Jan Kiszka
2012-04-01 10:57 ` Michael S. Tsirkin
2012-03-31 8:54 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F76C62A.5040904@web.de \
--to=jan.kiszka@web.de \
--cc=alex.williamson@redhat.com \
--cc=jbaron@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).