On 07/30/2012 04:48 PM, Daniel P. Berrange wrote: > On Mon, Jul 30, 2012 at 02:43:33PM +0200, Martin Kletzander wrote: >> On 07/30/2012 02:33 PM, Daniel P. Berrange wrote: >>> On Mon, Jul 30, 2012 at 02:25:04PM +0200, Martin Kletzander wrote: >>>> There a two new elements in <features> implemented, which control what >>>> ACPI sleeping states will be advertised. The default is to have both >>>> states enabled, so this means no change for current machines. >>> >>>> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng >>>> index b7562ad..859cb26 100644 >>>> --- a/docs/schemas/domaincommon.rng >>>> +++ b/docs/schemas/domaincommon.rng >>>> @@ -2788,6 +2788,16 @@ >>>> <empty/> >>>> </element> >>>> </optional> >>>> + <optional> >>>> + <element name="disable_s3"> >>>> + <empty/> >>>> + </element> >>>> + </optional> >>>> + <optional> >>>> + <element name="disable_s4"> >>>> + <empty/> >>>> + </element> >>>> + </optional> >>>> </interleave> >>>> </element> >>>> </optional> >>> >>> This is not very nice design. With this if an app wants to request >>> S3, and have an error if it is not supported, they can't do that. >>> >> >> I'm sorry, but I don't quite understand what do you mean. If the guest >> wants to go to S3, there is (of course) no difference between the state >> not being supported or the support being disabled. If an application >> wants to request the guest to go to S3 through libvirt, then it will get >> an appropriate message (disabled/not supported). Having one more option >> means just setting the QEMU parameter to the default value (0). > > I'm talking about the host mgmt's POV. An application creating a guest > may want to guarantee that S3 is available to the guest. With your > proposal, there is no way they can do that - since there is no explicit > element in the XML to request S3. So the mgmt app may get a guest with > S3, or it may not - it has no way of being sure. The only thing a mgmt > app can do is forcably disable S3 . > Oh, yes, I get it now. Unfortunately, that is true. Sadly, the only thing I see we can do with QEMU is set the disable_s[34] parameter(s) to zero, but that won't guarantee anything, I guess. Global parameters are valid even if they don't make sense or they don't exist, so even "qemu-kvm -global a.s=df" is a valid command-line. Martin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list