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

RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR



Dan Magenheimer wrote:
>>> If this is true the only safe use of TSC_AUX is for
>>> its originally designed intent: To determine if two
>>> successive rdtscp instructions were or were not
>>> executed on the same processor.  Since this cannot
>>> be guaranteed in a VM, that's a reasonable argument
>>> that TSC_AUX shouldn't be exposed at all (meaning the
>>> rdtscp bit in cpuid should be turned off by Xen).
>> 
>> This should work if you bind (i.e. pin) each vcpu to each
>> CPU, as I suggested.
> 
> Yes, it does.  If there were a reasonable way for an
> application to check "am I running on a VM for which
> each vcpu has been pinned?" this might be a reasonable
> constraint as, if the app isn't, it could fail or at least
> log a message.  But if the app will randomly fail
> (or perform horribly) depending on whether the
> underlying VM is pinned or not (which might even
> change across a migration or if a sysadmin is
> "tuning" his data center), I don't think
> enterprise customers would appreciate that.

Dan, 
        If later guest NUMA is implemented, both APP and 
Hypervisor/Guest are NUMA awared. APP could get benefit
>From the information of node/processor which is got from
RDTSCP. But how to implement guest NUMA is another story,
either we can use pin, or something other creative idea.

Best Regards,
-- Dongxiao
_______________________________________________
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®.