From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE709C433E2 for ; Thu, 17 Sep 2020 08:43:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68C4E2075E for ; Thu, 17 Sep 2020 08:43:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=axis.com header.i=@axis.com header.b="lqR+O7Qb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726211AbgIQIn6 (ORCPT ); Thu, 17 Sep 2020 04:43:58 -0400 Received: from smtp2.axis.com ([195.60.68.18]:7897 "EHLO smtp2.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726180AbgIQIn6 (ORCPT ); Thu, 17 Sep 2020 04:43:58 -0400 X-Greylist: delayed 431 seconds by postgrey-1.27 at vger.kernel.org; Thu, 17 Sep 2020 04:43:57 EDT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; l=1732; q=dns/txt; s=axis-central1; t=1600332237; x=1631868237; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9NKLIVDraz6+fyMH3+VMwK8eJnp6H6X4d9mocI9g0Kc=; b=lqR+O7Qb7Lb88vs7TWjewCwfddCjJ3YNsoufO4exRG6AFL+NF9nX5SUu 7aKRsOx9xxGAXUN6w27oLDII6e1rvO4u4zuEn4aG4s6+DoghWUIOiGJGh pcgqRksPWur2qj7G0JtobNMibJ6cq88zXMXk5lHwcQwy+9JACr80+36m1 n5S4dWjzeSfyeIELRjFwRWjQm7lTmzmgSef/XB8V76W+X8FXFLPV4YrqW Z8HKsGlpA9AaR8iXTV9wyYnAUfP49o65RNAw4q1ekkf8gyu4DFZYUGM4T djuu+HMoypcyybQMN5cbYNoWFJLDpYGxN4/2PbzsYNqor5xb5Q0/EelRU w==; IronPort-SDR: oDhvlA/ddrSklE6SljIF/+4cdbbGS38ZQ1+JfYDEJ16X4ULPtiXAW3r6j9cjc5HVT5P/h+lrsE iwnX44zhcc9hyXYUSy9ikb40bCPd5b1n8AI4/vg+P8fSdMofqk+PueLiDv1xopJHbRSlY/1DUQ I7EoQa5t/QzxOSTeE7WmmbwuaBpQnzyAe489aj+dYnLPmqgnMqiDFlRTkJe7n5mG7VO80wPAwM D5Q+TMautFCVhASARpm2xUGtkJaClGq4lRoOCMBdVhKOLK0Agzf/s6aRSZhMDrF6sEPayskDeC Jm4= X-IronPort-AV: E=Sophos;i="5.76,436,1592863200"; d="scan'208";a="12573765" Date: Thu, 17 Sep 2020 10:36:44 +0200 From: Vincent Whitchurch To: Guennadi Liakhovetski CC: Arnaud POULIQUEN , "kvm@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "sound-open-firmware@alsa-project.org" , Pierre-Louis Bossart , Liam Girdwood , "Michael S. Tsirkin" , Jason Wang , Ohad Ben-Cohen , Bjorn Andersson , Mathieu Poirier , Subject: Re: [PATCH v6 0/4] Add a vhost RPMsg API Message-ID: <20200917083644.66yjer4zvoiftrk3@axis.com> References: <20200901151153.28111-1-guennadi.liakhovetski@linux.intel.com> <9433695b-5757-db73-bd8a-538fd1375e2a@st.com> <20200917054705.GA11491@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200917054705.GA11491@ubuntu> User-Agent: NeoMutt/20170113 (1.7.2) Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org On Thu, Sep 17, 2020 at 07:47:06AM +0200, Guennadi Liakhovetski wrote: > On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote: > > So i would be agree with Vincent[2] which proposed to switch on a RPMsg API > > and creating a vhost rpmsg device. This is also proposed in the > > "Enhance VHOST to enable SoC-to-SoC communication" RFC[3]. > > Do you think that this alternative could match with your need? > > As I replied to Vincent, I understand his proposal and the approach taken > in the series [3], but I'm not sure I agree, that adding yet another > virtual device / driver layer on the vhost side is a good idea. As far as > I understand adding new completely virtual devices isn't considered to be > a good practice in the kernel. Currently vhost is just a passive "library" > and my vhost-rpmsg support keeps it that way. Not sure I'm in favour of > converting vhost to a virtual device infrastructure. I know it wasn't what you meant, but I noticed that the above paragraph could be read as if my suggestion was to convert vhost to a virtual device infrastructure, so I just want to clarify that that those are not related. The only similarity between what I suggested in the thread in [2] and Kishon's RFC in [3] is that both involve creating a generic vhost-rpmsg driver which would allow the RPMsg API to be used for both sides of the link, instead of introducing a new API just for the server side. That can be done without rewriting drivers/vhost/. > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 > > [2]. https://www.spinics.net/lists/linux-virtualization/msg44195.html > > [3]. https://www.spinics.net/lists/linux-remoteproc/msg06634.html