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

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

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.

>
> 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.

+1 to having an ACPI option, but as indicated above, I expect it to be
used in the longterm even for domU.

~Andrew

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