[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: Live migration fails due to c/s 20627
> >. 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). > > I don't agree with you at this point. For guest numa support, > it should be a must to pin virtual node's vcpus to its > related physical node and crossing-node vcpu migration should > be disallowed by default, otherwise guest numa support is > meaningless, right ? It's not a must. A system administrator should always have the option of choosing flexibility vs performance. I agree that when performance is higher priority, pinning is a must, but pinning may even have issues when the guest's nvcpus exceeds the number of cores in a node. So I am saying there are many cases where TSC_AUX, when set by a guest OS, will be incorrect. And yes I agree there are cases (with pinning) where it will be correct. But how does an app or OS know whether to trust TSC_AUX or not? Better to have some other method to get pcpu/pnode information that is known to be always correct (via some method of querying the hypervisor directly). > If vcpu's migration only happens in its physical node, I > can't see why you thought the info provided in the MSR is > wrong. Actually, each vcpu should have a virtual > TSC_AUX_MSR(guest should set it before using it), and this > virtual MSR is saved/restored from/to physical TSC_AUX_MSR > between context switch, so in vmx non-root mode the value in > physical TSC_AUX_MSR should follow guest's setting rather > than host's setting , and it also reflect guest's info > related to virtual node/virtual cpu, and it still should be > the expected value for guest's applications. In addition, we > have to know host's TSC_AUX_MSR and guest's TSC_AUX_MSR are > totally two different things except that they are saved in > one physical register in cpu's different execution phases, > shouldn't mix them together. My argument is simply that if TSC_AUX cannot ALWAYS be trusted by an application, apps will NEVER trust it. And if apps NEVER trust it, why expose it at all? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |