[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

> 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).

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.