Re: [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/11/15 16:17, Jan Beulich wrote:
>>>> On 04.11.15 at 17:05, <roger.pau@citrix.com> wrote:
>> El 03/11/15 a les 13.41, Jan Beulich ha escrit:
>>>>>> On 03.11.15 at 11:57, <andrew.cooper3@citrix.com> wrote:
>>>> On 03/11/15 07:21, Jan Beulich wrote:
>>>>>>>> On 30.10.15 at 16:36, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 30/10/15 13:16, Jan Beulich wrote:
>>>>>>>>>> On 30.10.15 at 13:50, <roger.pau@citrix.com> wrote:
>>>>>>>> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
>>>>>>>>>>>> On 02.10.15 at 17:48, <roger.pau@citrix.com> wrote:
>>>>>>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>>> ---
>>>>>>>>>> Changes since v6:
>>>>>>>>>>  - Return ENODEV in pmtimer_load if the timer is disabled.
>>>>>>>>>>  - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
>>>>>>>>>>    pmtimer is disabled.
>>>>>>>>> But how are those two features connected? I don't think you can
>>>>>>>>> assume absence of a PM block just because there's no PM timer.
>>>>>>>>> Or if you want to tie them together for now, the predicate needs
>>>>>>>>> to be renamed.
>>>>>>>>>
>>>>>>>>>>  - Return ENODEV if pmtimer_change_ioport is called with the pmtimer
>>>>>>>>>>    disabled.
>>>>>>>>> Same here.
>>>>>>>> What about changing XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and this
>>>>>>>> flags disables all PM stuff?
>>>>>>> Ah, right, that's a reasonable option.
>>>>>> It still might be a nice idea to split them in two, given future work.
>>>>>>
>>>>>> To support hotplug properly (cpu, ram and pci), Xen needs to inject
>>>>>> GPEs, which comes from part of the PM infrastructure.  To support PCI
>>>>>> devices in the future without the whole PM infrastructure, it would be
>>>>>> nice to keep the split.
>>>>> Coming back to this - I'm not sure: The hotplug aspect as you
>>>>> mention it should matter for Dom0 only. DomU could (and perhaps
>>>>> should) use a PV interface instead.
>>>> I disagree.
>>>>
>>>> All PVH guests should use the same mechanism; making a split between
>>>> dom0 and domU will only make our lives harder.
>>>>
>>>> Where reasonable, we should follow what happens on native; one of the
>>>> underlying points of PVH is to have less of an impact on the guest
>>>> side.  In some cases it is indeed nasty, but has the advantage of being
>>>> well understood.
>>> What meaning would ACPI have to a PVH DomU?
>>>
>>>>> So I'd like to suggest quite the opposite: Don't call the thing PM,
>>>>> but make it more general and call it ACPI. And instead of
>>>>> separating HPET, we might have this fall under ACPI as well, or
>>>>> we might have a second TIMER flag, requiring both to be set
>>>>> for there to be a HPET and PMTMR. This leaves open the option
>>>>> of Dom0 getting ACPI enabled (despite this then being "real",
>>>>> not emulated ACPI), but TIMER left off.
>>>> An HPET can exist independently of other features such as ACPI.  It
>>>> should have its own option.
>>> Without ACPI there's no defined way to discover it. Doing what
>>> Linux does - applying chipset knowledge - won't work on PVH either,
>>> because there's no emulated chipset. Which would leave scanning
>>> physical memory, but if there is none, none can be found.
>>>
>>>> +1 to having an ACPI option, but as indicated above, I expect it to be
>>>> used in the longterm even for domU.
>>> Again - why and how?
>> I think that at this point in the design it's not so important to have
>> all the XEN_X86_EMU_* properly defined. This is not a public interface,
>> so we can expand/reduce them whenever we want. Would it be fine, for the
>> time being to just have a XEN_X86_EMU_PM and control both the PM and the
>> PMTMR?
> I think so, yes.

Also +1 for now.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel