* [RFC] Handling VMEXITS with interrupts disabled?
@ 2007-04-23 3:08 Anthony Liguori
[not found] ` <462C2345.6040507-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Anthony Liguori @ 2007-04-23 3:08 UTC (permalink / raw)
To: kvm-devel
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/
^ permalink raw reply [flat|nested] 2+ messages in thread[parent not found: <462C2345.6040507-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]
* Re: [RFC] Handling VMEXITS with interrupts disabled? [not found] ` <462C2345.6040507-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> @ 2007-04-23 7:02 ` Avi Kivity 0 siblings, 0 replies; 2+ messages in thread From: Avi Kivity @ 2007-04-23 7:02 UTC (permalink / raw) To: Anthony Liguori; +Cc: kvm-devel Anthony Liguori wrote: > 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. > Yup. > 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. > You might compile the host with CONFIG_PREEMPT, which should get you a nice stacktrace after the "scheduling while atomic" message. > 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? > This is only checked under CONFIG_PREEMPT, otherwise preempt_disable (and get_cpu()) are no-ops. I really need to enable CONFIG_PREEMPT myself... -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/ ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-04-23 7:02 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-23 3:08 [RFC] Handling VMEXITS with interrupts disabled? Anthony Liguori
[not found] ` <462C2345.6040507-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-04-23 7:02 ` Avi Kivity
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox