Re: [PATCH 0 of 5] PV on HVM Xen

[Frank van der Linden <frank.van.der.linden@oracle.com>]

On 03/15/10 05:08 PM, Jeremy Fitzhardinge wrote:
> On 03/15/2010 05:28 AM, Stefano Stabellini wrote:
>> I like your pv clocksource implementation.
>> The only reason why I would defer the patch is that I don't particularly
>> like the "enable_pv" hypercall, so I would try to get away without it,
>> resetting the tsc offset automatically when enabling the VIRQ_TIMER on
>> an HVM domain.
>
> Ah, so the issue is that if we're using the pvclock, the host and 
> guest need to share the same tsc, so we can't deal with any kind of 
> tsc offset?
>
> In that case, I'd prefer to have an explicit "set/remove tsc offset" 
> vcpu op rather than making it the implicit side-effect of anything 
> else.  In particular, since clock sources and event sources are 
> completely distinct, making tsc offset (a clock source thing) affected 
> VIRQ_TIMER (and event source thing) seems like a particularly poor idea.
>
> That, or make the pvclock structure the HVM vcpu sees have timing 
> parameters which already incorporate the tsc offset.  We've already 
> demonstrated that there's no need to have the time info in the real 
> shared memory between Xen and the domain (it can be updated via copy 
> when needed).

I'd like to see it done explicitly too. You could use PV timestamps 
without actually using VIRQ_TIMER. It would not be an optimal 
combination, but you could do it. In fact, just today I looked at an old 
patch that I had lying around to do just this for Solaris PV domU.

Also, relying on side-effects makes for bad interfaces.

- Frank