From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
David Gibson <david@gibson.dropbear.id.au>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
Alex Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: add fixup for broken PCI devices
Date: Thu, 07 Jun 2012 14:37:37 +1000 [thread overview]
Message-ID: <1339043857.24838.8.camel@pasglop> (raw)
In-Reply-To: <1339041383.23475.396.camel@bling.home>
On Wed, 2012-06-06 at 21:56 -0600, Alex Williamson wrote:
> In so far as vfio should only have to call pci_reset_function and
> device
> quirks take care of everything else, I agree with you, but that
> doesn't
> answer any of my questions. Sure, we may want pre- and post-reset
> fixup
> quirks and a pony, but what quirk is actually necessary for this
> device?
> Does it fit into the existing pci_dev_specific_reset quirking?
> Reloading config space isn't a good generic solution, but it might at
> least shed some light on whether the reset function is doing anything
> and if a simple config space change fixes it. VFIO needs to do this
> anyway. Thanks,
Knowing those NEC OHCI critters I suspect it just continues DMA'ing as
usual and just ignores the reset... not sure what the actual setup is
though, those are PCI 2.x devices behind a PCI-E to PCI-X bridge, so I'm
not even sure they support a semi-decent reset.
We might want to even tell the bridge to hard reset what's behind it in
that case (everything is one isolation group behind that bridge anyway)
but that has its own problems (CSR unreliability, need for extra delays,
need to reconfigure the whole config space etc....)
Cheers,
Ben.
next prev parent reply other threads:[~2012-06-07 4:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 7:35 [Qemu-devel] [RFC PATCH] vfio: add fixup for broken PCI devices Alexey Kardashevskiy
2012-05-25 8:28 ` Benjamin Herrenschmidt
2012-05-25 12:24 ` Alex Williamson
2012-05-25 12:36 ` Benjamin Herrenschmidt
2012-05-28 12:44 ` Michael S. Tsirkin
2012-05-28 12:48 ` Jan Kiszka
2012-05-28 13:15 ` Michael S. Tsirkin
2012-06-06 23:17 ` Alex Williamson
2012-06-07 2:52 ` Benjamin Herrenschmidt
2012-06-07 3:56 ` Alex Williamson
2012-06-07 4:37 ` Benjamin Herrenschmidt [this message]
2012-06-22 8:16 ` Alexey Kardashevskiy
2012-08-17 14:28 ` Alexey Kardashevskiy
2012-08-21 2:31 ` Alex Williamson
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=1339043857.24838.8.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=kvm@vger.kernel.org \
--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).