Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp198298iog; Tue, 14 Jun 2022 23:50:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaRa3XdkQSqjS1BZe24m1qAQmQTG8VRsny4AJP9qLTr5N0nGAmeU0ZovHR3prm//aYO9vf X-Received: by 2002:a05:6a00:2389:b0:51c:3ca7:b177 with SMTP id f9-20020a056a00238900b0051c3ca7b177mr8418688pfc.17.1655275809555; Tue, 14 Jun 2022 23:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655275809; cv=none; d=google.com; s=arc-20160816; b=VZpIHXvUCWfRSBIa1yTqMEjE9qFYieC3LAjBODlE6BoFcUsRcau8QHrQP+xNamqRF6 CubrPyAnvgQ7Dk0pwtilCQsoyGEqzBTsk8fwzxEajqlMrPA2kMDu79/htnPf1oYSNmG7 Bz6m+1I+CnLKWcb1xZwcKVmWK2W9DVqdLPbFNGXeaQ6qHiDrP5i04KqT6NcInHji7jlz CsWsBCo6v81sH+igIabMCgJ4JvxbCC25c2gGpwFP00rJIaT2K1VgqZRgqu6imnoFnWw7 AiBZzlgaqJft6x9LuI7e5IQ78YePfx803SaF1hpxU4H/+O3a2dn5ZFo6HHYdgiimTPaW ZErQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=LshRSzq22wtp4qhXs+/iZas8+X4eeCgZ5sV4MhFsw2w=; b=nhKsFO6zQMN0fBXH4x0NCZWoCzukGADYJnWQwO5Q5kreUnS+QtdA4/AZn+BoYF8Eew 7b2IJVgZ1iHQa2qUKFZXGZ/z/9ABfbSxu+q7UrayyY2EF3ZrZ40H3y1nspAeuO3HvAZ6 B75sQsyiOlF1I6+XBz2cM6wX9o2Xfwf9NYJSUufmIUJzV+0lVMozL43/TwqQ5pUd3Vwg znmHmRifw82x08FJFLCDLQBs7pX1pXpgH9S/LaLvDno/MdIa2OnBpxJJ/e7s81Rhx4mD Wl29v7aO0MXV2RA7l3p9uY+Oka8j/vvjKwN7B8IvqGBqzvxtcPReM8BN5kZh0iFwtXJh Jc/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=luyrFMQU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z131-20020a633389000000b0040505587cdfsi16701553pgz.321.2022.06.14.23.49.57; Tue, 14 Jun 2022 23:50:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=luyrFMQU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352156AbiFOGYM (ORCPT + 99 others); Wed, 15 Jun 2022 02:24:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344650AbiFOGYH (ORCPT ); Wed, 15 Jun 2022 02:24:07 -0400 Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E770B27FEE for ; Tue, 14 Jun 2022 23:24:06 -0700 (PDT) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-31336535373so51297497b3.2 for ; Tue, 14 Jun 2022 23:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LshRSzq22wtp4qhXs+/iZas8+X4eeCgZ5sV4MhFsw2w=; b=luyrFMQUtVOGazWD1iq3vMXmKdEc5Z9Js2dg0RzKB7UAOL8BZ52UtgL/CXxEVKZVuw Lk4Uf50DB2KCN4AdmvHrHj1dL0buHpaWhvQP2ITrsXjzfMfLafIeW+ByvnE87ylrbN96 NwgiKQIz2gnpUTJtwkHDdaMyi+OtlkO+HpgYQJA1Xb2gbQ0wx/i1jppcWMwFNPIic/BL gHYZPBNIQEnouIR/kcjreA0RJP6sNCa0Cj7vrEecr1j2QTQoDizmKigSbHDaJYHag7vx 4kk8G8Q4AJJasQv7l8ujLQaoEfvqb6jDOCcGYTrSjw5pjx5idMc+9lQHaLuotaWJ/2ID lxcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LshRSzq22wtp4qhXs+/iZas8+X4eeCgZ5sV4MhFsw2w=; b=IbKk8I9yWQuUUsCl+n9V5HBukUFuDPQxySPf+OFvkXy0QhXFBxWPTeJIuXoJYfBi9d 2TUj2ZlJwahigM+tt79oRjdu/KaUSR6AKgCDO0gygx0en0lOSxxJF+Df3wB/h3PcmdCV ChVBwStEgGPySsbXRDA/z3vqwvBzGCt6a0EoOhlOLsTks+z/aUs/OTcaYzCt0FdJTcb5 xJBjP5ptoPLHTX2xTLZsIs7fw1zEPW4OrHs+/3FeGl9MjSzr/LmaxL351H1bSE2Kba2u i2gKw8Bvfm3ZmnOSv4V2SXK2u3n2oq991klBoJ2ivMZGfnQLdGkQEGQkrM48jqj3HG1P Jdqw== X-Gm-Message-State: AJIora+VxS84I5CoP0dDtMCetIR9HqvBHFJZDNRBPBbB0qtkt/eCrOXS 4eImqcyJo8qo7Hwg8H3JoobZrp8UJ9m1JYqxoDk= X-Received: by 2002:a81:ad7:0:b0:2e6:84de:3223 with SMTP id 206-20020a810ad7000000b002e684de3223mr10019086ywk.209.1655274245807; Tue, 14 Jun 2022 23:24:05 -0700 (PDT) MIME-Version: 1.0 References: <1654197833-25362-1-git-send-email-olekstysh@gmail.com> In-Reply-To: <1654197833-25362-1-git-send-email-olekstysh@gmail.com> From: Viresh Kumar Date: Wed, 15 Jun 2022 11:53:54 +0530 Message-ID: Subject: Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer To: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Linux Kernel Mailing List , Linux ARM , virtualization@lists.linux-foundation.org, x86@kernel.org, Oleksandr Tyshchenko , "Michael S. Tsirkin" , Christoph Hellwig , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Julien Grall , Bertrand Marquis , Wei Chen , Henry Wang , Kaly Xin , Jiamei Xie , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Vincent Guittot , Mathieu Poirier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oleksandr, On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko wrote: > The high level idea is to create new Xen=E2=80=99s grant table based DMA-= mapping layer for the guest Linux whose main > purpose is to provide a special 64-bit DMA address which is formed by usi= ng the grant reference (for a page > to be shared with the backend) with offset and setting the highest addres= s bit (this is for the backend to > be able to distinguish grant ref based DMA address from normal GPA). For = this to work we need the ability > to allocate contiguous (consecutive) grant references for multi-page allo= cations. And the backend then needs > to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it= must support virtio-mmio modern > transport for 64-bit addresses in the virtqueue). I was trying your series, from Linus's tree now and started seeing boot failures, failed to mount rootfs. And the reason probably is these messages: [ 1.222498] virtio_scsi virtio1: device must provide VIRTIO_F_ACCESS_PLATFO= RM [ 1.316334] virtio_net virtio0: device must provide VIRTIO_F_ACCESS_PLATFOR= M I understand from your email that the backends need to offer VIRTIO_F_ACCESS_PLATFORM flag now, but should this requirement be a bit soft ? I mean shouldn't we allow both types of backends to run with the= same kernel, ones that offer this feature and others that don't ? The ones that = don't offer the feature, should continue to work like they used to, i.e. without the restricted memory access feature. I am testing Xen currently with help of Qemu over my x86 desktop and these backends (scsi and net) are part of QEMU itself I think, and I don't really want to go and make the change there. Thanks. -- Viresh