From: Don Dutile <ddutile@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function, aka FLR or D3 support.
Date: Thu, 05 Jan 2012 13:58:50 -0500 [thread overview]
Message-ID: <4F05F2EA.5030502@redhat.com> (raw)
In-Reply-To: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
On 01/05/2012 05:24 AM, Ian Campbell wrote:
> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
>> We use the __pci_reset_function_locked to perform the action.
>> Also on attaching ("bind") and detaching ("unbind") we save and
>> restore the configuration states. When the device is disconnected
>> from a guest we use the "pci_reset_function" to also reset the
>> device before being passed to another guest.
>
> Currently I thought the toolstack was supposed to do the reset (by
> writing to the reset node in sysfs) as it was (de)assigning devices
> to/from guests. That's not to say that there isn't an argument for
> preferring to do it kernels side but it would be interesting to make
> that argument explicitly.
>
> I guess the toolstack doesn't currently save/restore the configuration
> state, could it though? I guess the state is all available in sysfs. On
pci_reset_function() saves the config state before doing a fcn-level reset.
the libvirt toolstack handles the unbind/reset/bind functionality
and is used by kvm for it's device assignment.
> the other hand the kernel provides us with a very handy function which
> Just Does It...
>
> Ian.
>
>>
>> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>> ---
>> drivers/xen/xen-pciback/pci_stub.c | 41 +++++++++++++++++++++++++++++++++--
>> drivers/xen/xen-pciback/pciback.h | 1 +
>> 2 files changed, 39 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
>> index 8f06e1e..0ce0dc6 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
>> static void pcistub_device_release(struct kref *kref)
>> {
>> struct pcistub_device *psdev;
>> + struct xen_pcibk_dev_data *dev_data;
>>
>> psdev = container_of(kref, struct pcistub_device, kref);
>> + dev_data = pci_get_drvdata(psdev->dev);
>>
>> dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
>>
>> xen_unregister_device_domain_owner(psdev->dev);
>>
>> - /* Clean-up the device */
>> + /* Call the reset function which does not take lock as this
>> + * is called from "unbind" which takes a device_lock mutex.
>> + */
>> + __pci_reset_function_locked(psdev->dev);
>> + if (pci_load_and_free_saved_state(psdev->dev,
>> + &dev_data->pci_saved_state)) {
>> + dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
>> + } else
>> + pci_restore_state(psdev->dev);
>> +
>> + /* Disable the device */
>> xen_pcibk_reset_device(psdev->dev);
>> +
>> + kfree(dev_data);
>> + pci_set_drvdata(psdev->dev, NULL);
>> +
>> + /* Clean-up the device */
>> xen_pcibk_config_free_dyn_fields(psdev->dev);
>> xen_pcibk_config_free_dev(psdev->dev);
>> - kfree(pci_get_drvdata(psdev->dev));
>> - pci_set_drvdata(psdev->dev, NULL);
>>
>> pci_dev_put(psdev->dev);
>>
>> @@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
>> /* Cleanup our device
>> * (so it's ready for the next domain)
>> */
>> +
>> + /* This is OK - we are running from workqueue context
>> + * and want to inhibit the user from fiddling with 'reset'
>> + */
>> + pci_reset_function(dev);
>> + pci_restore_state(psdev->dev);
>> +
>> + /* This disables the device. */
>> xen_pcibk_reset_device(found_psdev->dev);
>> +
>> + /* And cleanup up our emulated fields. */
>> xen_pcibk_config_free_dyn_fields(found_psdev->dev);
>> xen_pcibk_config_reset_dev(found_psdev->dev);
>>
>> @@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>> if (err)
>> goto config_release;
>>
>> + dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> + __pci_reset_function_locked(dev);
>> +
>> + /* We need the device active to save the state. */
>> + dev_dbg(&dev->dev, "save state of device\n");
>> + pci_save_state(dev);
>> + dev_data->pci_saved_state = pci_store_saved_state(dev);
>> + if (!dev_data->pci_saved_state)
>> + dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
>> +
>> /* Now disable the device (this also ensures some private device
>> * data is setup before we export)
>> */
>> diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
>> index e9b4011..a7def01 100644
>> --- a/drivers/xen/xen-pciback/pciback.h
>> +++ b/drivers/xen/xen-pciback/pciback.h
>> @@ -41,6 +41,7 @@ struct xen_pcibk_device {
>>
>> struct xen_pcibk_dev_data {
>> struct list_head config_fields;
>> + struct pci_saved_state *pci_saved_state;
>> unsigned int permissive:1;
>> unsigned int warned_on_write:1;
>> unsigned int enable_intx:1;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-01-05 18:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 0:46 [PATCH] Support Function Level Reset (FLR) in the xen-pciback module (v1) and some fixes Konrad Rzeszutek Wilk
2012-01-05 0:46 ` [PATCH 1/5] pci: Introduce __pci_reset_function_locked to be used when holding device_lock Konrad Rzeszutek Wilk
2012-01-05 0:46 ` [PATCH 2/5] xen/pciback: Support pci_reset_function, aka FLR or D3 support Konrad Rzeszutek Wilk
2012-01-05 10:24 ` [Xen-devel] " Ian Campbell
2012-01-05 18:58 ` Don Dutile [this message]
2012-01-05 21:34 ` Konrad Rzeszutek Wilk
2012-01-06 16:53 ` Don Dutile
2012-01-06 16:17 ` Konrad Rzeszutek Wilk
2012-01-05 0:46 ` [PATCH 3/5] xen/pciback: Move the PCI_DEV_FLAGS_ASSIGNED ops to the "[un|]bind" Konrad Rzeszutek Wilk
2012-01-05 0:46 ` [PATCH 4/5] xen/pciback: Expand the warning message to include domain id Konrad Rzeszutek Wilk
2012-01-06 8:38 ` [Xen-devel] " Jan Beulich
2012-01-06 8:38 ` Jan Beulich
2012-01-06 11:03 ` Andrew Cooper
2012-01-06 15:03 ` [Xen-devel] " Konrad Rzeszutek Wilk
2012-01-06 15:50 ` Keir Fraser
2012-01-06 15:50 ` Keir Fraser
2012-01-06 15:51 ` Ian Campbell
2012-01-06 16:00 ` Konrad Rzeszutek Wilk
2012-01-06 22:19 ` Konrad Rzeszutek Wilk
2012-01-09 9:29 ` Jan Beulich
2012-01-09 9:50 ` Ian Campbell
2012-01-09 15:11 ` Konrad Rzeszutek Wilk
2012-01-09 15:16 ` Ian Campbell
2012-01-09 15:22 ` Konrad Rzeszutek Wilk
2012-01-05 0:46 ` [PATCH 5/5] xen/pciback: Fix "device has been assigned to X domain!" warning Konrad Rzeszutek Wilk
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=4F05F2EA.5030502@redhat.com \
--to=ddutile@redhat.com \
--cc=Ian.Campbell@citrix.com \
--cc=jbarnes@virtuousgeek.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/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.