From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: [RFC] Handling VMEXITS with interrupts disabled? Date: Sun, 22 Apr 2007 22:08:53 -0500 Message-ID: <462C2345.6040507@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-devel Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Howdy, I had an idea for improving VMEXIT time by only saving/restoring sys{enter,call,ret} MSRs when exiting from kernel space code since as long as these instructions aren't executed on the host, everything should be fine. This worked fine for MSR_IA32_SYSENTER* msrs, but not so much for the ?TAR msrs. I have hooks in vcpu_{get,put} but I suspect we're making a blocking call somewhere which is resulting in the scheduler being invoked (while we still have the vcpu). This then results in generally badness in the host. I'm still a little unclear about this though as I would think that if this could happen, it would create problems with VT since KVM another guest could run and overwrite the VMCS msr. I'm I interpreting this correctly? Does disabling preemption not guarantee that you won't potentially drop to userspace in your critical block? Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/