From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59665 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ok1Bx-0002ei-8i for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:49:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ok1BY-0001Yc-Bj for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:49:05 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:59055) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok1BY-0001YW-7H for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:49:04 -0400 Received: by gyd10 with SMTP id 10so1190246gyd.4 for ; Fri, 13 Aug 2010 13:49:03 -0700 (PDT) Message-ID: <4C65AFB9.5030505@codemonkey.ws> Date: Fri, 13 Aug 2010 15:48:57 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4C659881.70806@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 00/15] RFC xen device model support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" On 08/13/2010 02:35 PM, Stefano Stabellini wrote: >> We should limit XenStore interactions to strictly be device model >> setup. Any management operations should be done through QMP. The main >> reason to take this approach is to ensure that we don't end up with a >> more powerful interface via xenstore verses QMP or vice versa. >> >> > I want to be clear on this: I like QMP and I dislike xenstore, > especially when it is used as an RPC mechanism. > I have NO intention of transforming xenstore in a QMP alternative, in > fact we removed quite a lot of xenstore interactions developing this > series, in particular the whole disk setup (and it felt good :). > Ah, fantastic :-) >> The target changes are probably the most contentious. Fortunately, we >> have a very similar set of goals with KVM so I think we'll be able to >> come up with a common solution to the problem. >> >> > Yes, this is the part that worries me the most. > Do you think is reasonable to keep the new target for the time being or > do you want us to try the other approach ASAP? > Let's figure out the right solution and then we'll figure out the incremental approach. I don't mind if you keep it in the next few rounds of the series but I don't think we can merge it. A good way to start would be for ya'll to take a look at the places where we hook for KVM. For instance, cpu_register_phys_memory_client. With an additional hook in the map()/unmap()/rw() path, you should be able to implement the map cache support and deal with memory in a sane way. I think that would allow us to separate the discussion of having xen hooks with removing TCG support in the Xen builds which as I said earlier, is something we also would like to do in KVM. Regards, Anthony Liguori > If you really want us to drop the xen specific target we'll need > close guidance in how to proceed. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 00/15] RFC xen device model support Date: Fri, 13 Aug 2010 15:48:57 -0500 Message-ID: <4C65AFB9.5030505@codemonkey.ws> References: <4C659881.70806@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: Anthony Perard , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" List-Id: xen-devel@lists.xenproject.org On 08/13/2010 02:35 PM, Stefano Stabellini wrote: >> We should limit XenStore interactions to strictly be device model >> setup. Any management operations should be done through QMP. The main >> reason to take this approach is to ensure that we don't end up with a >> more powerful interface via xenstore verses QMP or vice versa. >> >> > I want to be clear on this: I like QMP and I dislike xenstore, > especially when it is used as an RPC mechanism. > I have NO intention of transforming xenstore in a QMP alternative, in > fact we removed quite a lot of xenstore interactions developing this > series, in particular the whole disk setup (and it felt good :). > Ah, fantastic :-) >> The target changes are probably the most contentious. Fortunately, we >> have a very similar set of goals with KVM so I think we'll be able to >> come up with a common solution to the problem. >> >> > Yes, this is the part that worries me the most. > Do you think is reasonable to keep the new target for the time being or > do you want us to try the other approach ASAP? > Let's figure out the right solution and then we'll figure out the incremental approach. I don't mind if you keep it in the next few rounds of the series but I don't think we can merge it. A good way to start would be for ya'll to take a look at the places where we hook for KVM. For instance, cpu_register_phys_memory_client. With an additional hook in the map()/unmap()/rw() path, you should be able to implement the map cache support and deal with memory in a sane way. I think that would allow us to separate the discussion of having xen hooks with removing TCG support in the Xen builds which as I said earlier, is something we also would like to do in KVM. Regards, Anthony Liguori > If you really want us to drop the xen specific target we'll need > close guidance in how to proceed. >