RE: [Xen-ia64-devel] SMP guest and itc

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

>    I guess I'm not sure what you mean by exposing the formula
> cooperatively.  Could you explain?  I'm thinking along the lines of
> trapping access to the ITC and emulating, but you mention in a
> separate email that a trap isn't required.
Taking the example in pseudo code if we virtualize in this way:
        guest_ITC = host_ACPI_timer_count * fact1 + offset1.

Original Linux code:  "xx=ar.itc" in para guest will be changed to 
      x1=ACPI_timer_count
      x2 = x1 * fact1
      xx=x2+offset1
Here ACPI_timer_count read is an MMIO read that is directly mapped to
para-dom. fact1 is a pre-calculated factor between guest ITC frequency
and ACPI_timer_count here for example. offset1 may be in share memory if
both guest and xen want to access.
For simplicity, it can use host ITC here to replace ACPI_timer_count,
but this implies problem in SMP system.


> Thread #1                Thread #2
> gettimeofday(&t1)
> sync-primitive()         sync-primitive()
>                          gettimeofday(&t2)
> 
This approach can also precisely solve the guest time rewind issue as
Tony mentioned. Because we are using platform time as base for all VPs.


>    Definitely, this is where I was thinking a paravirtualized time
> interpolator might also work well.  The xen backend of the code could
Not sure about the details of paravirtualized time interpolator mean
here. Any details?

> could use the HPET or ITC depending on what's available on the
No matter HPET or ITC, in above formula the only difference is the fact1
and offset1.

> platform. Once we do that, I'm not sure how valuable the fully
> virtualized ITC would be.  I don't think that one necessarily
When we say full virtualization, it  is comparing with non
virtualization like current non-VTI code did that directly assign host
ITC to guest ITC.
Yes, we can implement what ever algorithm for full virtualization, the
above formula is only for example, it doesn't mean to exclude other
approaches:-)

> excludes the other, they may be complimentary together.  Thanks,
> 
Yes, I don't want to exclude any other ideas here, but do think assuming
guest ITC=host ITC is problematic. We need to handle the different
frequency issues to support big system like NUMA and save/restore etc.
And keep the possiblity to avoid guest device/application timeout in
future.
Thx,eddie


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