From: Amit Shah <amit.shah@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stratos Psomadakis <psomas@cslab.ece.ntua.gr>,
"Michael S. Tsirkin" <mst@redhat.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
virtualization@lists.linux-foundation.org,
Sasha Levin <levinsasha928@gmail.com>,
Jacek Galowicz <jacek@galowicz.de>,
Christoph Hellwig <hch@lst.de>, Davidlohr Bueso <dave@gnu.org>
Subject: Re: [PULL] virtio and lguest
Date: Fri, 13 Jan 2012 16:18:45 +0530 [thread overview]
Message-ID: <20120113104845.GC9506@amit.redhat.com> (raw)
In-Reply-To: <CA+55aFyOy4bWUq6PH3ThM2CXOFwi75FE8HGOJ8DNZjFWw9rq6A@mail.gmail.com>
Hi,
On (Thu) 12 Jan 2012 [16:29:14], Linus Torvalds wrote:
> On Wed, Jan 11, 2012 at 9:22 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >
> > Amit Shah (12):
> > virtio: pci: switch to new PM API
>
> Hmm. Afaik, this is broken, or at least not complete.
>
> Sure, it switches to the new PM API, but it still does the PCI ops itself.
>
> It should not need to - the PCI layer will do the power state and
> standard PCI device state saving. And setting the PCI_D3hot state when
> shared interrupts can still happen at suspend time is just a bad idea.
The idea behind this patchset is to get S4 working properly. There's
no change to the way S3 was/is being done, and the state-setting is
done only in the S3 PM callbacks.
> So I think you're doing extra work and introducing bugs by doing so -
> the default PCI bus operations should already do all you do, just do
For S4, we need some driver-specific (not just virtio-specific) work
to be done on the freeze/restore callbacks...
> it better. And then you can use the SIMPLE_DEV_PM_OPS() to build the
> dev_pm_ops structure and get all the normal cases right automatically.
... and we also have separate stuff to be done in thaw/restore/freeze
callbacks for different drivers. So using the *_PM_OPS() macros
wouldn't have worked.
> I don't know if there is any particularly good example of this, but
> you can see some of the network drivers for examples of this. Notice
> how they don't need to worry about PCI power states etc at all, they
> just need to worry about the actual chip suspend/resume (and for a
> network driver, you'd do the netif_device_detach/netif_device_attach
> etc)
I think your concern is with the way S3 is being done, and I volunteer
to look at improving the situation there. Might take a while, though.
Amit
prev parent reply other threads:[~2012-01-13 10:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 5:22 [PULL] virtio and lguest Rusty Russell
2012-01-13 0:29 ` Linus Torvalds
2012-01-13 2:29 ` Rusty Russell
2012-01-13 10:48 ` Amit Shah [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=20120113104845.GC9506@amit.redhat.com \
--to=amit.shah@redhat.com \
--cc=dave@gnu.org \
--cc=hch@lst.de \
--cc=jacek@galowicz.de \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=psomas@cslab.ece.ntua.gr \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.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).