[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR
> It's possible, and the way guest NUMA supposed to be. We are > working on that. I'd be very interested in learning more about your plans. > -----Original Message----- > From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx] > Sent: Friday, December 11, 2009 11:38 AM > To: Dan Magenheimer; Xu, Dongxiao; Keir Fraser; Zhang, Xiantao; > xen-devel@xxxxxxxxxxxxxxxxxxx > Cc: Dugger, Donald D > Subject: RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR > > > Dan Magenheimer wrote on Fri, 11 Dec 2009 at 08:12:00: > > >>> Yes, but code which uses fast vgetcpu is expecting > >>> to get physical cpu and physical node number. Since > >>> an HVM guest OS only has access to virtual cpu and > >>> virtual node number, the information written to TSC_AUX > >>> by a guest OS is misleading and may silently break any > >>> userland code that assumes it is getting physical > >>> information. > >> > >> This is depend on how the node info is virtualized. > >> If the virtual node could reflect the physical > >> node info, what rdtscp returns is valuable to applications. > > > > If it is possible to ensure that the cpu/node info > > is virtualized so that TSC_AUX always correctly provides the > > information needed by apps, I agree this would be > > valuable. I don't see how this is possible, but maybe > > you have some creative ideas? > > It's possible, and the way guest NUMA supposed to be. We are > working on that. > > Jun > ___ > Intel Open Source Technology Center > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |