[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer
>>> On 03.11.15 at 11:57, <andrew.cooper3@xxxxxxxxxx> wrote: > On 03/11/15 07:21, Jan Beulich wrote: >>>>> On 30.10.15 at 16:36, <andrew.cooper3@xxxxxxxxxx> wrote: >>> On 30/10/15 13:16, Jan Beulich wrote: >>>>>>> On 30.10.15 at 13:50, <roger.pau@xxxxxxxxxx> wrote: >>>>> El 14/10/15 a les 16.37, Jan Beulich ha escrit: >>>>>>>>> On 02.10.15 at 17:48, <roger.pau@xxxxxxxxxx> wrote: >>>>>>> Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx> >>>>>>> Cc: Jan Beulich <jbeulich@xxxxxxxx> >>>>>>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>>>>>> --- >>>>>>> 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |