Project

General

Profile

Actions

Bug #2214

open

non-hw drivers can't prevent fastreboot

Added by Rich Lowe over 10 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
kernel
Start date:
2012-02-29
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

A driver can prevent fastreboot in exactly one way: It "needs" to quiesce, yet fails to.

The specifics of "fails to" vary, either ddi_quiesce_not_supported(), not implemented, or returning failure.

However, it is all predicated on our belief that the driver "needs" to quiesce. If you are a pseudo driver, or a driver with no HW property, you are assumed to "not need to", and thus have absolutely of no way of saying that you can't.

You would think that making the system honour ddi_quiesce_not_supported() as actually meaning it, regardless of "need" was thus a good idea, but that too is flawed. pretty much every driver we have claims to not support it, many actually meaning they don't need it. Fixing ddi_quiesce_not_supported() would prevent any system from fast rebooting (this is not, necessarily, a bad thing). Someone would have to, in tandem, fix every driver that really meant they didn't need to quiesce to actually say that.

should_implement_quiesce() decides whether any quiesce you have will be listened to.
If you have a quiesce which is not ddi_quiesce_not_supported (irony!) it will be called (regardless)
but if should_implement_quiesce() did not return positively, even trying to quiesce and returning failure will not block the boot.

(I've run upon this by inspection trying to cause KVM to prevent fastboot, I have not yet tried it, and would love to be wrong).

Actions

Also available in: Atom PDF