All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: libxl__device_pci_reset() questions
Date: Thu, 19 Feb 2015 15:26:24 +0000	[thread overview]
Message-ID: <1424359584.30924.91.camel@citrix.com> (raw)
In-Reply-To: <92904325.20150219160938@eikelenboom.it>

On Thu, 2015-02-19 at 16:09 +0100, Sander Eikelenboom wrote:
> Thursday, February 19, 2015, 3:30:52 PM, you wrote:
> 
> > On Thu, 2015-02-19 at 13:59 +0000, Jan Beulich wrote:
> >> All,
> >> 
> >> in the context of someone seeing "The kernel doesn't support reset
> >> from sysfs for PCI device", is my understanding correct that the lack
> >> of error checking in any caller (perhaps intentional) means that any
> >> of the errors logged from this function are really just warnings, i.e.
> >> don't prevent the assignment from taking place?
> 
> > It was a long while ago, but I believe that was the intention, yes.
> 
> >> Furthermore I'm puzzled by the function first thing trying to access
> >> a "do_flr" file supposedly made available by the pciback driver, yet
> >> I can't see either the upstream or the old 2.6.18 driver surfacing
> >> such a file. What am I missing here?
> 
> > I'm not sure, on the basis of
> > http://lists.xen.org/archives/html/xen-devel/2014-06/msg03105.html and 
> > http://lists.xen.org/archives/html/xen-devel/2014-07/msg01108.html I've
> > added Konrad to the CC.
> 
> You seemed to have missed the actual CC, added now

Nope, Konrad's mailman configuration is such that the list copy of the
mail ends up with his CC stripped -- that's really a feature of mailman!

> and also David who nacked these patches.

I didn't know about this.

Oh well, I'll let other fight it out as to what the correct approach is.

> 
> The fundamental issue seems to be:
> A) Does this even have to be sysfs triggered functionality. The most prominent 
>    reason for this construct with pciback deferring it to the toolstack which in 
>    turn invokes a sysfs to pciback again were issues around locking.
>    However vfio/virtio also has the bus/slot reset logic and seems to be able to
>    work around said locking issues.
> 
> B) If it *has* to be done with a sysfs entry, the naming of the sysfs entry 
>    "do_flr" is misleading since it doesn't do an FLR, but hooks up bus/slot 
>    reset.
> 
> That said, i'm running for quite some time now with the mentioned do_flr patches
> from Konrad applied, these fix issues with pci devices not being properly reset 
> when stopping and starting VM's with pci devices passed through. Most 
> prominently VGA cards (without it they won't work any more after a VM shutdown
> and you would have to restart the host (you also see the screen isn't reset to 
> all black after the VM shuts down.)
> 
> So the functionality is valuable, but it would be nice if the implementation 
> could be contained within pciback (when a device is being mappend/ unmapped 
> from a guest) and the sysfs attribute could be dropped (solves the naming issue)
> 
> --
> Sander
> 
> > Ian.
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2015-02-19 15:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19 13:59 libxl__device_pci_reset() questions Jan Beulich
2015-02-19 14:30 ` Ian Campbell
2015-02-19 15:09   ` Sander Eikelenboom
2015-02-19 15:26     ` Ian Campbell [this message]
2015-02-26 14:28   ` Jan Beulich
2015-02-27 22:11     ` Konrad Rzeszutek Wilk
2015-02-19 15:30 ` 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=1424359584.30924.91.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=david.vrabel@citrix.com \
    --cc=linux@eikelenboom.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --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.