Re: [Xen-devel] [PATCH v2] x86/viridian: Add Partition Reference Time enlightenment

[Matt Wilson <msw@xxxxxxxxx>]

On Mon, Sep 29, 2014 at 11:28:44AM +0100, Paul Durrant wrote:
> The presence of the partition reference time enlightenment persuades newer
> versions of Windows to prefer the TSC as their primary time source. Hence,
> if rdtsc is not being emulated and is invariant then many vmexits (for
> alternative time sources such as the HPET or reference counter MSR) can
> be avoided.
> 
> The implementation is not yet complete as no attempt is made to prevent
> emulation of rdtsc if the enlightenment is active and guest and host
> TSC frequencies differ. To do that requires invasive changes in the core
> x86 time code and hence a lot more testing.
> 
> This patch avoids the issue by disabling the enlightenment if rdtsc is
> being emulated, causing Windows to choose another time source. This is
> safe, but may cause a big variation in performance of guests migrated
> between hosts of differing TSC frequency. Thus the enlightenment is not
> enabled in the default set, but may be enabled to improve guest performance
> where such migrations are not a concern.
> 
> See section 15.4 of the Microsoft Hypervisor Top Level Functional
> Specification v4.0a for details.
> 
> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> Cc: Keir Fraser <keir@xxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Cc: Christoph Egger <chegger@xxxxxxxxx>

[...]

> +    /*
> +     * The guest will calculate reference time according to the following
> +     * formula:
> +     *
> +     * ReferenceTime = ((RDTSC() * TscScale) >> 64) + TscOffset
> +     *
> +     * Windows uses a 100ns tick, so we need a scale which is cpu
> +     * ticks per 100ns shifted left by 64.
> +     */
> +    p->TscScale = ((10000ul << 32) / d->arch.tsc_khz) << 32;
> +
> +    do {
> +        p->TscSequence++;
> +    } while ( p->TscSequence == 0xFFFFFFFF ||
> +              p->TscSequence == 0 ); /* Avoid both 'invalid' values */

Anthony Liguori and I were looking this over today and he pointed
something out: couldn't a second vCPU of the guest write 0 or
0xffffffff in a tight loop to cause a hypervisor DoS?

--msw

> +    unmap_domain_page(p);
> +
> +    put_page_and_type(page);
> +}
> +
[...]

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