From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Enhance perf to support KVM Date: Fri, 26 Feb 2010 14:17:53 -0600 Message-ID: <4B882C71.2030400@codemonkey.ws> References: <1267068445.1726.25.camel@localhost> <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Ingo Molnar Return-path: Received: from mail-iw0-f182.google.com ([209.85.223.182]:42203 "EHLO mail-iw0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965955Ab0BZUR6 (ORCPT ); Fri, 26 Feb 2010 15:17:58 -0500 Received: by iwn12 with SMTP id 12so501834iwn.21 for ; Fri, 26 Feb 2010 12:17:58 -0800 (PST) In-Reply-To: <20100226103545.GA7463@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 04:35 AM, Ingo Molnar wrote: > Basically what is needed is plain filesystem access - properly privileged. So > doing this via a vmchannel would be nice, but for the symbol extraction it > would be a glorified NFS server in essence. > > Do you have (or plan) any turn-key 'access to all files of the guest' kind of > guest-transparent facility that could be used for such purposes? That would > have various advantages over a traditional explicit file server approach: > > - it would not contaminate the guest port space > > - no guest side configuration needed (the various oprofile remote daemons > always sucked as they needed extra setup) > > - it might even be used with a guest that does no networking > If you look at VMware, they provide a guest daemon that runs in userspace and communicates with the host to allow the host to do operations like execute a binary or read a file. We've been trying to build this for years and virtio-console is what we've finally settled on. The userspace bits are super easy to build. The problem is that we need guest kernel support. We've not had a lot of success there as we've had a number of things Nacked. The approach we originally started with was to introduce a new socket family for virtualization. This is what s390 does and this is what VMware does. But Dave Miller nacked that. VMware happily carries their own module so they don't have to deal with problems like this. I guess s390 was able to get away with it because noone pays attention to what they do. Rusty had a proposal very similar to vhost-net that he posted two years ago but Andrew Morton nacked that because it wasn't generic enough (serves us right for trying to do anything generic in the first place). Honestly, what's hardest for us to build a turn key solution is that unlike our competition, we've got to deal with getting people who don't necessarily care about virtualization to agree with what we're doing as opposed to just maintaining our own set of kernel modules. Things limited to userspace have not slowed us down compared to getting things into the kernel. Look at how difficult it was to get MMU notifiers merged as another example. If you're volunteering to commit the things that we need to build a turn key solution, then that would certainly be a big help to us. Regards, Anthony Liguori