On 09/28/2010 12:41 AM, Dave Airlie wrote:
On Mon, Sep 27, 2010 at 11:20 PM, Thomas Hellstrom
<thellstrom@xxxxxxxxxx> wrote:
Don't suspend or hibernate when there are 3D resources active since we
can't restore the device's 3D state. Instead fail with an error message.
Its not acceptable to block suspend ever like that, you need to
restore the devices 3D state somehow,
since if you are running a compiz desktop or something, you'll never
have a time when the resources aren't active.
Dave.
Dave,
In principle I agree.
However, in this case we should be aware, that suspending / hibernating
a guest VM using S3 / S4 is an extremely rare event, that is the result
of the user doing something stupid. A VM should be suspended from the
GUI (which justs makes the host stop the VM saving its complete state).
If the host is suspending / hibernating, like if you close the lid, the
VM will just go to sleep like any other user-space process, and the
suspend / hibernate event will not be propagated to the guest.
But unfortunately we can't stop the user from trying S3/S4 suspend /
hibernate, from within the guest VM, so we need to do some kind of
graceful failure here. The alternative is a 3D hang when the user
resumes, because we can't really introduce code in the kernel that
tracks the complete state of all 3D contexts (well, we probably can, but
it's going to be ugly and error-prone).
I think a future version of the device will have capabilities to save
and restore the device state.
Given this special case,
Would this patch be acceptable?
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
