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=-4.3 required=3.0 tests=BAYES_00,DATE_IN_PAST_12_24, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C47DFC4363A for ; Wed, 28 Oct 2020 21:43:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A13420E65 for ; Wed, 28 Oct 2020 21:43:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=axis.com header.i=@axis.com header.b="A5RkGxHf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726274AbgJ1Vn0 (ORCPT ); Wed, 28 Oct 2020 17:43:26 -0400 Received: from smtp1.axis.com ([195.60.68.17]:30541 "EHLO smtp1.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726094AbgJ1VnQ (ORCPT ); Wed, 28 Oct 2020 17:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; l=1245; q=dns/txt; s=axis-central1; t=1603921395; x=1635457395; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=V5PC9rrr4wvQwwqKdrCWhTxTTXC0hA0+smGFsW9FA6A=; b=A5RkGxHfJuaQ1nUkFUxA8YBJ4fn4dn6wqQKRVt/yTTzPoJdj9ts18QdN NFRIFYo1Mnb3UDODqqjltKYIINRluw20sNq9kJ9y3A+E/6k6fcDuyrjJQ 3P5TBVUfn04zn9STq3C7qP5kMOs2ENG1TC6LL8vLYJdsHX5pdSikSAasZ +8smpR4X6eJw8SxTOoX8oG3eKfVj9Kkxo5KnMt22lCd4PT8rSCFKEfBD8 pm7qHW/0tV1s8oDiVnYDO8P0Uvh+fj18tvvC0jMBvQP9R4mDzVg5lS+Tq omtFFFBQ+WJguOaREPtetF1Yt4jzEG0komjhaIeCyuuoTUsOYQKpeOqCV Q==; IronPort-SDR: RW1GWNphPPFtmQaT7DrDcktgp5Xkcqs01gk50OCvjdEx3SaHFxbXIMUZ1/yl7R83QRb/R/Jge7 rCMCW/7NCuBK/+gi7TUbtOTmVH6n9Js46ipJmO0lJLNciEM+8ZX5kXBxvJzoOoZvbeI3750LoB d171LXGepfvaPJdhxcmCO+kyx4qerhaWegYn5nTGcYeZUgDtplkneIjjKgJIF09Agx+NCVPg12 Fl5cMQB1BUOyUOLZ5nHaWLAgGYXqWPcP7BmGmoN/Tktnhgg8BWQqlSAdZZiStVMIqCQo8yQbSh qII= X-IronPort-AV: E=Sophos;i="5.77,425,1596492000"; d="scan'208";a="14495795" Date: Wed, 28 Oct 2020 10:14:10 +0100 From: Vincent Whitchurch To: Sherry Sun CC: "sudeep.dutt@intel.com" , "ashutosh.dixit@intel.com" , Christoph Hellwig , "gregkh@linuxfoundation.org" , "arnd@arndb.de" , "kishon@ti.com" , "lorenzo.pieralisi@arm.com" , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used ring Message-ID: <20201028091410.o2odlqrhzzbiqh44@axis.com> References: <20201022050638.29641-1-sherry.sun@nxp.com> <20201022050638.29641-3-sherry.sun@nxp.com> <20201023092650.GB29066@infradead.org> <20201027062802.GC207971@kroah.com> <20201027151106.e4skr6dsbwvo4al6@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 28, 2020 at 02:47:49AM +0100, Sherry Sun wrote: > > Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used > > ring > > > > On Tue, Oct 27, 2020 at 08:05:43AM +0100, Sherry Sun wrote: > > > Can you help test the patch about removing the codes of reassign used > > > ring, and comment on the impact for Intel MIC platform? Thanks for > > > any help. > > > > I don't have access to MIC hardware myself, either. > > > > But this patch is quite certainly going to break it since guests using a kernel > > without the patch will not work with hosts with a kernel with the patch. > > Thanks for your reply. > This patch can be used by both guests and hosts. > I have tested it on imx8qm platform(both guest and host are ARM64 architecture), and it works well. > So I guess Intel MIC won't meet big problems when both guest and host > apply this patch. But it is best if it can be tested. The guest and host are different systems and it should be possible to upgrade the host kernel without being forced to upgrade the guest kernel, and vice-versa. This patch breaks that. If MIC hardware has no users and the drivers are being deleted then of course backward compatibility doesn't matter.