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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 BB186C43460 for ; Mon, 17 May 2021 17:21:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 984486134F for ; Mon, 17 May 2021 17:21:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242817AbhEQRWn (ORCPT ); Mon, 17 May 2021 13:22:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235374AbhEQRWn (ORCPT ); Mon, 17 May 2021 13:22:43 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D99FC061573 for ; Mon, 17 May 2021 10:21:26 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id lg14so10329080ejb.9 for ; Mon, 17 May 2021 10:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KSak/9y8LWCPIDO3G6CswSdOFb8LMwY6kG8ALECOcQ4=; b=FAoQU13gvykSeVPaT8SD0dcXsm4yCutPyV3HXGbrkMqJURqJJ1TpCC2N9Sby2v9Quu SxEDs9LDJrwAQ7+xPzYiZmHAFww2P6PNBPs5s2nkSPuZp+MTzuMyyZ5beiPs+5UfN2mT xGKwFWY4bNQ2WSd4YF6rlGmI5eoa++Lymx2PKTFoCA2kXd33AOOPsMGvM+KJzM90Skwn 5DNpXxhL0Iras7qtd/gCMDz9CGnp2/wSFPpmt4GoEVGvWKxYmlsaSE1cjNQSje8OFsiE ++BQ+plVjguBvcA0RzBTh+3tH0tiGrNYLkZ2uh0afF6wM6z2X+T9p0fmruHcfs/C/ekM EYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KSak/9y8LWCPIDO3G6CswSdOFb8LMwY6kG8ALECOcQ4=; b=VnN650nDvN8MpJUV/cUv7XpB2cy3jszzKU4xwkTl26uQn0F6aARYhT+s0oOfdJJt1A JnLcNU3WRtOUxPtrITiCfzqwB+GHelF2WinEYB95swvMRvwM+yaHlK3LBCHi5qZ6+zD9 RpN+5OO51ZZb50csxNZhweM/jnKfhuwlKF9TjARC/Mr1rmO+tDPiVqpH9EVoy2gEeC7T 9ugXvDMbrIXt/IcWTAyUfCfdlu9jzYnW84+3IZhUu6ekONz2tEI2g7wkqAtTy7ItrhvR W0V3JvO9cs0m1tF8dhJ1N2+3qtZ6uwO+Ppb3e3nbWCPy6xtBV8fOA1rDJHPRTsBtyHvR b5Vg== X-Gm-Message-State: AOAM530F7BktbcT7ijGt4Wq1aTzFF18/B3BTV6tRp8EmdGt69lliwJgx UBRoVsplOeaO4dDBlCmyWxWDkNz9u3UtzDiooo2TBA== X-Google-Smtp-Source: ABdhPJwDSuY1Ew65cNeQBqF/NU4BCq0/RPemhz48ePAYjbpwvuGcrf2z9Kf9uaXqxeWBtzA0bGQ4GodiWR5b72do9Cs= X-Received: by 2002:a17:907:3e28:: with SMTP id hp40mr1001966ejc.523.1621272085131; Mon, 17 May 2021 10:21:25 -0700 (PDT) MIME-Version: 1.0 References: <20210419165451.2176200-1-Jonathan.Cameron@huawei.com> <20210419165451.2176200-3-Jonathan.Cameron@huawei.com> <20210506215934.GJ1904484@iweiny-DESK2.sc.intel.com> <20210511175006.00007861@Huawei.com> <20210514094755.00002081@Huawei.com> <20210517094045.00004d58@Huawei.com> In-Reply-To: <20210517094045.00004d58@Huawei.com> From: Dan Williams Date: Mon, 17 May 2021 10:21:14 -0700 Message-ID: Subject: Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support To: Jonathan Cameron Cc: Ira Weiny , linux-cxl@vger.kernel.org, Linux PCI , Bjorn Helgaas , Lorenzo Pieralisi , Ben Widawsky , Chris Browy , Linux ACPI , "Schofield, Alison" , Vishal L Verma , Linuxarm , Fangjian , Greg KH Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, May 17, 2021 at 1:42 AM Jonathan Cameron wrote: > > On Fri, 14 May 2021 11:37:12 -0700 > Dan Williams wrote: > > > On Fri, May 14, 2021 at 1:50 AM Jonathan Cameron > > wrote: > > [..] > > > > If it simplifies the kernel implementation to assume single > > > > kernel-initiator then I think that's more than enough reason to block > > > > out userspace, and/or provide userspace a method to get into the > > > > kernel's queue for service. > > > > > > This last suggestion makes sense to me. Let's provide a 'right' way > > > to access the DOE from user space. I like the idea if it being possible > > > to run CXL compliance tests from userspace whilst the driver is loaded. > > > > Ah, and I like your observation that once the kernel provides a > > "right" way to access DOE then userspace direct-access of DOE is > > indeed a "you get to keep the pieces" event like any other unwanted > > userspace config-write. > > > > > Bjorn, given this would be a generic PCI thing, any preference for what > > > this interface might look like? /dev/pcidoe[xxxxxx].i with ioctls similar > > > to those for the BAR based CXL mailboxes? > > > > (warning, anti-ioctl bias incoming...) > > I feel very similar about ioctls - my immediate thought was to shove this in > debugfs, but that feels the wrong choice if we are trying to persuade people > to use it instead of writing code that directly accesses the config space. > > > > > Hmm, DOE has an enumeration capability, could the DOE driver use a > > scheme to have a sysfs bin_attr per discovered object type? This would > > make it simliar to the pci-vpd sysfs interface. > > We can discover the protocols, but anything beyond that is protocol > specific. I don't think there is a enough info available by any standards > defined method. Also part of the reason to allow a safe userspace interface > would be to provide a generic interface for vendor protocols and things like > CXL compliance tests where we will almost certainly never provide a more > specific kernel interface. > > Whilst sysfs would work for CDAT, some protocols are challenge response rather > than simple read back and that really doesn't fit well for sysfs model. > If we get other protocols that are simple data read back, then I would > advocate giving them a simple sysfs interface much like proposed for CDAT > as it will always be simpler to use + self describing. > > On a lesser note it might be helpful to provide sysfs attrs for > what protocols are supported. The alternative is to let userspace run > the discovery protocol. Perhaps we can do this as a later phase. > > > > > Then the kernel could cache objects like CDAT that don't change > > outside of some invalidation event. > > It's been a while since I last saw any conversation on sysfs bin_attrs > but mostly I thought the feeling was pretty strongly against them for anything > but a few niche usecases. > > Feels to me like it would break most of the usual rules in a way vpd does > not (IIRC VPD is supposed to be a simple in the sense that if you write a value > to a writable part, you will read back the same value). > > +CC Greg who is a fount of knowledge in this area (and regularly + correctly > screams at the ways I try to abuse sysfs :) Note I don't think Dan was > suggesting implementing response / request directly, but I think that is > all we could do given DOE protocols can be vendor specific and the standard > discovery protocol doesn't let us know the fine grained support (what commands > within a given protocol). I'm not all that interested in supporting vendor defined DOE shenanigans. There's more than enough published DOE protocols that the kernel could limit its support to the known set. This is similar to how ACPI DSMs are not generically supported, but when they appear in a published specification the kernel may then grow the support. The supported protocols could be limited to: CDAT, PCIe IDE, CXL Compliance, etc... Vendor specific DOE is in the same class as unfettered /dev/mem access, first you need to disable the kernel's integrity and confidentiality protections, and then you can do whatever you want. If a vendor wants a DOE protocol supported in the "trusted" set they can simply publish the specification and send the proper support patches.