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. >