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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 16E34C433DF for ; Mon, 8 Jun 2020 09:11:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EEB11206C3 for ; Mon, 8 Jun 2020 09:11:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728956AbgFHJLH (ORCPT ); Mon, 8 Jun 2020 05:11:07 -0400 Received: from mga05.intel.com ([192.55.52.43]:2017 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726038AbgFHJLH (ORCPT ); Mon, 8 Jun 2020 05:11:07 -0400 IronPort-SDR: fD+vcAqL+03p7ub4XTNlzpAlyWEiGdmhMToTDq3yi5goe/TNmKdn0Wuh+ZDbzMaz6gDfAXJe5x h1qudhmYtLrg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2020 02:11:05 -0700 IronPort-SDR: c6ZAhXQaDJ4dIM9JJuB5GZtmw6xqbYPfM0945uT+/Ru/NmZgrmDQg06GmHfhtPHtU9pg2Ir1JO luFM8hYzCbfw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,487,1583222400"; d="scan'208";a="258641818" Received: from gliakhov-mobl2.ger.corp.intel.com (HELO ubuntu) ([10.249.46.212]) by fmsmga007.fm.intel.com with ESMTP; 08 Jun 2020 02:11:02 -0700 Date: Mon, 8 Jun 2020 11:11:00 +0200 From: Guennadi Liakhovetski To: "Michael S. Tsirkin" Cc: 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 , Jason Wang , Ohad Ben-Cohen , Bjorn Andersson , Mathieu Poirier Subject: Re: [PATCH v3 0/5] Add a vhost RPMsg API Message-ID: <20200608091100.GC10562@ubuntu> References: <20200527180541.5570-1-guennadi.liakhovetski@linux.intel.com> <20200604151917-mutt-send-email-mst@kernel.org> <20200605063435.GA32302@ubuntu> <20200608073715.GA10562@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200608073715.GA10562@ubuntu> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Update: I looked through VirtIO 1.0 and 1.1 specs, data format their, including byte order, is defined on a per-device type basis. RPMsg is indeed included in the spec as device type 7, but that's the only mention of it in both versions. It seems RPMsg over VirtIO isn't standardised yet. Also it looks like newer interface definitions specify using "guest native endianness" for Virtual Queue data. So I think the same should be done for RPMsg instead of enforcing LE? Thanks Guennadi On Mon, Jun 08, 2020 at 09:37:15AM +0200, Guennadi Liakhovetski wrote: > Hi Michael, > > On Fri, Jun 05, 2020 at 08:34:35AM +0200, Guennadi Liakhovetski wrote: > > > > On Thu, Jun 04, 2020 at 03:23:37PM -0400, Michael S. Tsirkin wrote: > > [snip] > > > > Another it's out of line with 1.0 spec passing guest > > > endian data around. Won't work if host and guest > > > endian-ness do not match. Should pass eveything in LE and > > > convert. > > > > Yes, I have to fix this, thanks. > > Just to make sure my understanding is correct: this would involve also > modifying the current virtio_rpmsg_bus.c implementation to add > endianness conversions. That's what you meant, right?