Re: [PATCH 0/6] KVM support for TSC scaling

[Avi Kivity]

On 02/09/2011 07:29 PM, Joerg Roedel wrote:
> Hi Avi, Marcelo,
>
> here is the patch-set to implement the TSC-scaling feature of upcoming
> AMD CPUs. When this feature is supported the CPU provides a new MSR
> which holds a multiplier for the hardware TSC which is applied on the
> value rdtsc[p] and reads of MSR 0x10. This feature can be used to
> emulate a given tsc frequency for the guest.
> Patch 1 is not directly related to this patch-set because it only fixes
> a bug which prevented me from testing these patches. In fact it fixes
> the same bug Andre sent a patch for. But after the discussion about his
> patch he told me to just post my patch and thus here it is.

Questions:
- the tsc multiplier really is a multiplier, right?  Not an addend that 
is added every cycle.

So

    wrmsr(TSC, 1e9)
    wrmsr(TSC_MULT, 2.0000)
    t = rdtsc()

will return about 2e9, not 1e9 + 2*(time to execute the code snippet) ?

- what's the cost of wrmsr(TSC_MULT)?

There are really two ways to implement this feature.  One is fully 
generic, like you did.  The other is to implement it at the host level - 
have a sysfs file and/or kernel parameter for the desired tsc frequency, 
write it once, and forget about it.  Trust management to set the host 
tsc frequency to the same value on all hosts in a migration cluster.

The advantages of the the simpler implementation are, well, that it's 
simpler, and second that it avoids two wrmsrs per exit.  We could 
combine both implementations, and have

  if (guest_mult != host_mult)
      wrmsr(TSC_MULT, guest_mult)

etc.  But I'd like to understand if there are additional motivations for 
per-guest tsc frequency.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/