RE: [Xen-devel] poweroff in 3.2 and 3.3

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 20.11.08 03:39 >>>
>>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>>Sent: Wednesday, November 19, 2008 9:22 PM
>>
>>On 19/11/08 13:18, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>
>>> The hypervisor appears to make the assumption that all but the vCPU
>>> XENPF_enter_acpi_sleep is being called on are down (in 3.2 
>>because the
>>> sender of the event check IPI assumes the remote CPU is 
>>idle, in 3.3 by
>>> and explicit check in __cpu_disable() - here we also have an 
>>incorrect
>>> comment stating that this path can only be used when entering S3).
>
>Comment says "Only s3 is using this path", instead of "this path
>can only be used by s3". :-) At that time cpu online/offline is not
>supported and thus only s3 is the user on that path. If you look at
>latest xen upstream with cpu offline support, that comment went
>away.

But my point is that this is wrong (no matter how it's worded): entering
S5 also uses this path, and in that case there's nothing that stops
non-current vCPU-s of dom0.

>>> I can't, however, see how this would be guaranteed on the kernel side
>>> (and apart from that I don't think the hypervisor should be 
>>dependent on
>>> kernel behavior here, even if it's dom0). Shouldn't therefore
>>> freeze_domains() not only freeze all DomU-s, but also all non-current
>>> vCPU-s of Dom0?
>>
>>Kevin Tian is probably best placed to answer this. I'm happy 
>>to see this
>>added if he agrees.
>>
>
>Yes, original design depends on cooperation from dom0 kernel (
>offline other vcpus) and control panels (send virtual S3 or equivalent
>suspend command to all domains except dom0). It's expected that
>adminstrator should request system S3 on top of control panel, 
>instead of accessing raw sysfs interface. Current code gives a final 
>brute-force action to freeze domains. I agree that such guard should
>be also added to dom0's vcpus if following this policy.

I'll prepare a patch for this then.

>However I'm considering the point whether Xen can simply reject the
>s3 request, when observing non-current vcpus still alive. Domain can
>be in trouble if unaware of underlying sleep phase, such time keeping
>and softlockup warning. More seriously, domain with passthrough
>devices can't recover device state since it's even not notified to save
>context. Opinions?

I agree to this. But as per above, S3 (and S4 if ever supported) must be
distinguished from S5 in this regard.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel