On Mon, 2013-05-20 at 13:27 +0300, Gleb Natapov wrote: > On Mon, May 20, 2013 at 08:25:11PM +1000, Vadim Rozenfeld wrote: > > On Mon, 2013-05-20 at 12:25 +0300, Gleb Natapov wrote: > > > On Mon, May 20, 2013 at 10:56:22AM +0200, Paolo Bonzini wrote: > > > > In any case, this patch needs more comments and a better commit message. > > > > Microsoft docs are decent, but there are several non-obvious points in > > > > how the patches were done, and they need to be documented. > > > I wish you were right about Microsoft docs :) So in Hyper-V spec they > > > say: > > > > > > Special value of 0xFFFFFFFF is used to indicate that this facility is no > > > longer a reliable source of reference time and the virtual machine must > > > fall back to a different source (for example, the virtual PM timer). > > > > > > May be they really mean "virtual PM timer" here and reference counter is > > > not considered as a fall back source, but this is not what we want. > > > > As far as I know, you cannot fall back from iTSC to PMTimer or HPET, > > but you can fallback to reference counters. > > > What if you put 0xFFFFFFFF as a sequence? Or is this another case where > the spec is wrong. > it will use PMTimer (maybe HPET if you have it) if you specify it on VM's start up. But I'm not sure if it will work if you migrate from TSC or reference counter to 0xFFFFFFFF > > > > > > On the other hand in API specification [1] they have: > > > > > > #define HV_REFERENCE_TSC_SEQUENCE_INVALID (0x00000000) > > > > > > which is not even documented in hyper-v spec. Actually 0 is specified as > > > valid value there. Go figure. > > > > > > [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff540244%28v=vs.85%29.aspx > > > > > > -- > > > Gleb. > > > > -- > Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
