[Xen-devel] RE: Live migration fails due to c/s 20627

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

Dan Magenheimer wrote:
> Oops, forgot to reply to this part of your message.
> 
>>> There are many cases where rdtsc/rdtscp instructions
>>> are emulated and so most of the code is already there.
>>> You only need to intercept illegal instruction traps,
>>> so there is not a significant performance issue.
>>> And the code to do the emulation is necessary
>>> to implement the pvrdtscp algorithm on hvm anyway
>> 
>> I think in HVM environment, we should respect the native
>> behavior.
> 
> I'm not sure why you think that.  There are many many
> native silicon features that are not exposed directly
> to the guest OS.  The whole point of virtualization
> is to present an abstract hardware interface so that
> multiple VMs can be supported on a single machine and
> VMs can be moved between underlying hardware implementations.
> Breaking that flexibility for a rarely utilized instruction
> such as rdtscp seems like a very bad idea.

I didn't break the flexibility, as stated before, my next patch
will move the code for guest cpuid presentation, and then 
Administrator could mask the bit for migration. It is not only
Rdtscp has this problem.

> 
>> Moreover, it would be valuable for
>> guest if it could get the node/cpu info which reflects
>> hardware topology.
> 
> As Jeremy has pointed out, the guest OS already has
> other mechanisms to provide this information, and
> as Jun has pointed out, the non-rdtscp mechanism (lsl
> on Linux) may even be faster. Windows does not even
> provide TSC_AUX, so it definitely has other ways to
> obtain node/cpu info.  And, as I've said before,
> the node/cpu info provided by Linux in TSC_AUX is
> wrong anyway (except in very constrained environments
> such as where the admin has pinned vcpus to pcpus).

After guest numa is implemented, it is not a constrained
environment. Guest will benefit from the information such as
Implementing fast vgetcpu() and so on...

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