From: Rusty Russell <rusty@rustcorp.com.au>
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>,
Amit Shah <amit.shah@redhat.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 12:59:19 +1030 [thread overview]
Message-ID: <87fwfkjpxc.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CA+55aFyOy4bWUq6PH3ThM2CXOFwi75FE8HGOJ8DNZjFWw9rq6A@mail.gmail.com>
On Thu, 12 Jan 2012 16:29:14 -0800, Linus Torvalds <torvalds@linux-foundation.org> 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.
>
> 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
> 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.
>
> 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)
Ok, I'll confess complete ignorance, and wait for Amit to respond. I
must admit that PM for virtual devices is not a personal priority...
Thanks,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Amit Shah <amit.shah@redhat.com>, Christoph Hellwig <hch@lst.de>,
Davidlohr Bueso <dave@gnu.org>,
Jacek Galowicz <jacek@galowicz.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Sasha Levin <levinsasha928@gmail.com>,
Stratos Psomadakis <psomas@cslab.ece.ntua.gr>,
virtualization@lists.linux-foundation.org
Subject: Re: [PULL] virtio and lguest
Date: Fri, 13 Jan 2012 12:59:19 +1030 [thread overview]
Message-ID: <87fwfkjpxc.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CA+55aFyOy4bWUq6PH3ThM2CXOFwi75FE8HGOJ8DNZjFWw9rq6A@mail.gmail.com>
On Thu, 12 Jan 2012 16:29:14 -0800, Linus Torvalds <torvalds@linux-foundation.org> 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.
>
> 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
> 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.
>
> 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)
Ok, I'll confess complete ignorance, and wait for Amit to respond. I
must admit that PM for virtual devices is not a personal priority...
Thanks,
Rusty.
next prev parent reply other threads:[~2012-01-13 2:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 5:22 [PULL] virtio and lguest Rusty Russell
2012-01-12 5:22 ` Rusty Russell
2012-01-13 0:29 ` Linus Torvalds
2012-01-13 0:29 ` Linus Torvalds
2012-01-13 2:29 ` Rusty Russell [this message]
2012-01-13 2:29 ` Rusty Russell
2012-01-13 10:48 ` Amit Shah
2012-01-13 10:48 ` Amit Shah
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=87fwfkjpxc.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=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 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.