On 29/10/2024 01:54, Jiatong Shen wrote:
Thank you very much. We found that Windows guests will use RTC (146818 in QEMU) as a timer. If the timing on the host machine goes backwards, there is a chance the guest could crash. Have you ever observed such behavior and can you share some advices on such situations?
if you set os_type=windows in the galnce image it should enable the windows, guest enligthenments which shoudl provide an alternitive clock config. if its windows we first set the clk type to localtime https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6... we also enabel the hypervclock in the guest https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6... thats in addtion to the 2 other clocks we p[rovide by default in the form of the pit and rtc https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6... the trc is configure with tickpolicy='catchup' https://libvirt.org/formatdomain.html#time-keeping that should nto run backwards form what i understand but i guess if your host clock did it might. catchup Deliver ticks at a higher rate to catch up with the missed ticks. The guest OS will not notice anything is amiss, as from its point of view time will have continued to flow normally. Once the timer has managed to catch up with all the missing ticks, the time in the guest and in the host should match. enabling the hpet might help but i would first make sure the glance image has os_type=windows defiend and confirm the instance also has it set in its cached copy in the instance_system_metadata table. if it does not then you can simply update it with https://docs.openstack.org/nova/latest/cli/nova-manage.html#image-property-s... if your usign the q35 machine type i belive there is also a timestampe counter (TSC) clock automatically in the guest so windows guest shoudl ahve at least 4 timesouces avilable in teh guest to use in addtion to the hpet if its enabeld.
Thank you.
Best, Jiatong shen
On Tue, Oct 29, 2024 at 7:18 AM Sean Mooney <smooney@redhat.com> wrote:
Hello Community Experts,
I found that to enable the HPET timer for x86 guests, the operator should set hw_time_hpet on the given image. Image properties are primarily for end users to express the requirements of images
On 27/10/2024 02:07, Jiatong Shen wrote: they upload rather then for operators, but they can be set by operators too.
By default, HPET is disabled. My question is what are the pros and cons for using HPET? Its off by default because there some security concerns with access to the HPET and the minimal
performance overhead it introduces.
support was added in https://github.com/openstack/nova/commit/9e884de68af9b83a92850e823cae152cfe8...
The hpet is generally not required by almost any application but it does provided more precision but higher overhead.
In general unless you need it you should leave it disabled.
The security concern is just that if you provide a high precision time source to a guest it can help execute timing based attacks leveraging some of cpu vulnerability that leverage speculative execution. in practice this is not very practical to exploit so the hpet is generally considered safe.
Thanks.