|
xen-devel
RE: [Xen-devel] poweroff in 3.2 and 3.3
>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.
>>
>> 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.
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?
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home