From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/5] KVM paravirt_ops implementation Date: Sun, 17 Jun 2007 22:36:42 -0500 Message-ID: <4675FDCA.4040006@codemonkey.ws> References: <4675F462.1010708@codemonkey.ws> <4675F9DE.6080806@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4675F9DE.6080806-TSDbQ3PG+2Y@public.gmane.org> 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 To: Jeremy Fitzhardinge Cc: Zachary Amsden , kvm-devel , virtualization List-Id: virtualization@lists.linuxfoundation.org Hi Jeremy, Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > >> 1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not >> sure which paravirt_ops calls are actually re-entrant. >> > > I'm not sure that has specifically come up. The main issue is whether a > particular call can be preempted and whether that matters. I guess the > calls which affect a particular CPU's state will generally be called in > a non-preemptable context, but I guess we can't assume that; the best > approach is to assume that each call be atomic with respect to preemption. > So each call would need to disable preemption? I'm not sure that makes a whole lot of sense for something like CR reads/writes. In fact, without passing in a cpu parameter, I'm pretty sure that those operations *have* to require preemption to be disabled. For something like MMU operations, preemption really doesn't have to be disabled. > Things like batching must be completed with preemption disabled over the > whole batch. I check that with BUG_ON in the Xen code. > Right now the KVM batching requires preemption to be disabled for batching. I don't think that's a hard requirement though since we could pass the current batch PA as part of the flush hypercalls. Things are a lot easier though if we can just assume preemption is disabled :-) Are you aware of any paravirt_ops calls that are probably being called in the kernel with preemption enabled? >> 2) The paravirt_ops implementation is registered with >> core_initcall(). However, the paravirt_ops banner is also printed >> with core_initcall() so that fact that this works now is just the luck >> of build order. Need a better way to initialize the KVM paravirt_ops >> backend. >> > > Hm. We could make the banner printing later; obviously its purely > cosmetic. I put it as a core_initcall on the assumption that pv-ops > would be set up very early as it is with Xen and lguest, and so the > banner should print relatively early. But if your model is that you > boot fully virtualized for a while, and then become paravirtualized > later, then it would make sense to defer banner printing until then. > I don't see a compelling reason to paravirtualize earlier although I also don't see a compelling reason not too. I noticed that VMI hooks setup.c. It wasn't immediately obvious why it was hooking there but perhaps it worthwhile to have a common hook? I suspect VMI and KVM will have a similar model for startup. Thanks for the feedback! Regards, Anthony Liguori > J > > ------------------------------------------------------------------------- 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/