[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] poweroff in 3.2 and 3.3
>>> "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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |