From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Sander Eikelenboom <linux@eikelenboom.it>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset slot or bus with 'do_flr' SysFS attribute
Date: Mon, 8 Dec 2014 11:04:02 -0500 [thread overview]
Message-ID: <20141208160402.GF7745@laptop.dumpdata.com> (raw)
In-Reply-To: <54857F91.3020002@citrix.com>
On Mon, Dec 08, 2014 at 10:38:09AM +0000, David Vrabel wrote:
> On 05/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 05, 2014 at 10:30:01AM +0000, David Vrabel wrote:
> >> On 04/12/14 15:39, Alex Williamson wrote:
> >>>
> >>> I don't know what workaround you're talking about. As devices are
> >>> released from the user, vfio-pci attempts to reset them. If
> >>> pci_reset_function() returns success we mark the device clean, otherwise
> >>> it gets marked dirty. Each time a device is released, if there are
> >>> dirty devices we test whether we can try a bus/slot reset to clean them.
> >>> In the case of assigning a GPU this typically means that the GPU or
> >>> audio function come through first, there's no reset mechanism so it gets
> >>> marked dirty, the next device comes through and we manage to try a bus
> >>> reset. vfio-pci does not have any device specific resets, all
> >>> functionality is added to the PCI-core, thank-you-very-much. I even
> >>> posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> >>> bad so that pci_reset_function() won't claim that worked. All VGA
> >>> access quirks are done in QEMU, the kernel doesn't have any business in
> >>> remapping config space over MMIO regions or trapping other config space
> >>> backdoors.
> >>
> >> Thanks for the info Alex, I hadn't got around to actually looking and
> >> the vfio-pci code and was just going to what Sander said.
> >>
> >> We probably do need to have a more in depth look at now PCI devices and
> >> handled by both the toolstack and pciback but in the short term I would
> >> like a simple solution that does not extend the ABI.
> >
> > Could you enumerate the 'simple solution' then please? I am having
> > a frustrating time figuring out what it is that you are proposing.
>
> I've posted it repeatedly.
Are you referring to http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01270.html
which is still waiting for your feedback?
next prev parent reply other threads:[~2014-12-08 16:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 12:06 [PATCH v5 9/9] xen/pciback: Implement PCI reset slot or bus with 'do_flr' SysFS attribute Konrad Rzeszutek Wilk
2014-12-04 12:06 ` Konrad Rzeszutek Wilk
2014-12-04 12:24 ` [Xen-devel] " David Vrabel
2014-12-04 13:10 ` Sander Eikelenboom
2014-12-04 13:10 ` Sander Eikelenboom
2014-12-04 13:43 ` [Xen-devel] " David Vrabel
2014-12-04 14:09 ` Sander Eikelenboom
2014-12-04 14:09 ` [Xen-devel] " Sander Eikelenboom
2014-12-04 14:14 ` Sander Eikelenboom
2014-12-04 14:14 ` Sander Eikelenboom
2014-12-04 14:31 ` David Vrabel
2014-12-04 14:31 ` [Xen-devel] " David Vrabel
2014-12-04 14:50 ` Sander Eikelenboom
2014-12-04 14:50 ` [Xen-devel] " Sander Eikelenboom
2014-12-04 15:39 ` Alex Williamson
2014-12-04 15:39 ` [Xen-devel] " Alex Williamson
2014-12-04 16:25 ` Sander Eikelenboom
2014-12-04 16:25 ` [Xen-devel] " Sander Eikelenboom
2014-12-04 16:55 ` Alex Williamson
2014-12-04 16:55 ` [Xen-devel] " Alex Williamson
2014-12-05 10:30 ` David Vrabel
2014-12-05 17:22 ` Konrad Rzeszutek Wilk
2014-12-08 10:38 ` David Vrabel
2014-12-08 10:38 ` [Xen-devel] " David Vrabel
2014-12-08 16:04 ` Konrad Rzeszutek Wilk
2014-12-08 16:04 ` Konrad Rzeszutek Wilk [this message]
2014-12-05 17:22 ` Konrad Rzeszutek Wilk
2014-12-05 10:30 ` David Vrabel
2014-12-04 19:05 ` [Xen-devel] " Konrad Rzeszutek Wilk
2014-12-04 19:05 ` Konrad Rzeszutek Wilk
2014-12-04 13:43 ` David Vrabel
2014-12-04 12:24 ` David Vrabel
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=20141208160402.GF7745@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@eikelenboom.it \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.