Re: [Xen-devel] [PATCH] hvm/hpet: Correctly gate the virtual HPET on HVM_PARAM_HPET_ENABLE

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.01.15 at 16:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/01/15 15:34, Jan Beulich wrote:
>>>>> On 15.01.15 at 15:40, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> c/s 3f8e22de7 "x86 hvm: Allow HPET to be configured as a per-domain config
>>> option" introduced the parameter to conditionally enable the HPET.
>>>
>>> However, having the check in hpet_range() does not have the intended effect.
>>> As currently implemented, when the HPET is disabled, the range is not 
>>> claimed
>>> and an ioreq is forwarded to qemu, which implements an HPET itself.
>>>
>>> Properly disable the HPET by always claiming the range, dropping writes and
>>> reading ~0.
>> Hmm, while the patch certainly does what you describe above, is that
>> really correct? There could be something else at that address when
>> the HPET is disabled. Therefore I would rather think that qemu should
>> be told to also not make a HPET available when the option is off.
> 
> Without out wiring up northbridge chipset reigsters from Qemu to Xen to
> control where components such as the HPET appear, I think we can
> reasonably assume that there will be nothing there.
> 
> Whether the HPET is present or not, the range ought to reserved in the
> E820 and not free for arbitrary reuse by the OS.

"assume" and "should" are kind of weak. Just having checked two
arbitrary physical machines - one reserves the HPET area in E820,
the other doesn't. But since hvmloader correctly reserves the
necessary (or actually a larger) area, I think I'm fine with the
change.

Jan


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