Avi Kivity wrote: > ron minnich wrote: > > On 8/2/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > > > > Li, Xin B wrote: > > > > > > > > Did you see any performance improvements out of this? > > > > > > > > > > > > > > Acturally we don't expect any obviously performance because MSR > > > > accesses are not frequent. > > > > > > > > > > > Well, why do this then? > > > > > > > ah, see, you asked the question I was going to ask. OK, this can be > > faster; but, are you sure you really care? > > > > > > Looking at the Linux context switch code, it can bang on MSR_FS_BASE and > MSR_KERNEL_GS_BASE. A high context switch rate between threads (which > use %gs or %fs) can show an improvement with this. Things like kbuild > probably won't as they use single threaded processes.
Right. > + disable_intercept_for_msr(MSR_FS_BASE, va); > + disable_intercept_for_msr(MSR_GS_BASE, va); > + > + disable_intercept_for_msr(MSR_IA32_SYSENTER_CS, va); > + disable_intercept_for_msr(MSR_IA32_SYSENTER_ESP, va); > + disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, va); I think we should focus on MSR_FS_BASE and MSR_GS_BASE. The rest are typically set up once for the life of OS. Some other MSRs like MSR_IA32_PERF_CTL can be accessed frequently in some configration, but we don't want such a pass-through in KVM. Jun --- Intel Open Source Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
