RE: [Xen-devel] [PATCH] Fix hvm guest time to be more accurate

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

>
>The vpt timer code in effect accumulates missed ticks
>when a guest is running but has interrupts disabled
>or when the platform timer is starved. For guests

This case, VMM will pick up the lost ticks into pending_intr_nr.
The only issue is that if a guest is suspended or save/restored
for long time such as several hours or days, we may see tons 
of lost ticks, which is difficult to be injected back (cost minutes
of times or even longer). So we give up those amount of 
pending_intr_nr.  In all above case, guest need to re-sync its
timer with others like network time for example. So it is 
harmless.

Similar situation happens when somebody is debugging a guest.

>like 64 bit Linux which calculates missed ticks on each
>clock interrupt based on the current tsc and the tsc
>of the last interrupt and then adds missed ticks to jiffies
>there is redundant accounting.
>
>This change subtracts off the hypervisor calculated missed
>ticks while guest running for 64 bit guests using the pit.
>Missed ticks when vcpu 0 is descheduled are unaffected.
>
I think this one is not the right direction.

The problem in time virtualization is that we don't how guest will use
it.
Latest 64 bit Linux can pick up the missed ticks from TSC like you
mentioned, but it is not true for other 64 bits guest even linux 
such as 2.6.16, nor for Windows.

Besides PV timer approach which is not always ready, basically
we have 3 HVM time virtualization approaches:

1: Current one:
        Freeze guest time when the guest is descheduled and
thus sync all guest time resource together. This one
precisely solve the guest time cross-reference issues, guest TSC
precisely represent guest time and thus can be cross-referenced
 in guest to pick up lossed ticks if have. but the logic 
is relatively complicated and is easy to see bugs :-(


2: Pin guest time to host time.
        This is simplest approach, guest TSC is always pinned to
host TSC with a fixed offset no matter the vCPU is descheduled or
not. In this case, other guest periodic IRQ driven time resource 
are not synced to guest TSC.
        Base on this, we have 2 deviations:
        A: Accumulate pending_intr_nr like current #1 approach.
        B: Give up accumulated pending_intr_nr. We only inject
one IRQ for a periodic IRQ driven guest time such as PIT.

        What you mentioned here is a special case of 2B.

        Since we don't know how guest behaviors, what we are
proposing recently is to implement all of above, and let administrate
tools to choose the one to use base on knowledge of guest OS
type. 

thanks, eddie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel