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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 84C83C433DB for ; Fri, 22 Jan 2021 16:47:36 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 04EED23AA1 for ; Fri, 22 Jan 2021 16:47:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04EED23AA1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:42488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2zaw-0006OG-T1 for qemu-devel@archiver.kernel.org; Fri, 22 Jan 2021 11:47:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2zZz-0005pV-2p for qemu-devel@nongnu.org; Fri, 22 Jan 2021 11:46:35 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:28679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1l2zZt-0006sU-Bp for qemu-devel@nongnu.org; Fri, 22 Jan 2021 11:46:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611333986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NjurElfJLsX6Y4qSc9qJ6RY8F486Tqa1R2MYxcpvW9Q=; b=A0y2JaEit93ryNPknFnrZ+91FTD8bu1Rmqz3lhFHMpvHnrx+mX/39Vr9l1a61VK5kmuH47 wsZFcEfQEUNxIL7mB1y2d7DA/AMinBwvwzDqMid+m5JUVWSHTz2HM55+V1C9cHoWVUJFXc D0r7QzRVHkTWzwD7j6rZbTNXKE4Vecc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-196-BFr37ueUO4i3ldcNrs-X9A-1; Fri, 22 Jan 2021 11:46:23 -0500 X-MC-Unique: BFr37ueUO4i3ldcNrs-X9A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 298A110054FF; Fri, 22 Jan 2021 16:46:22 +0000 (UTC) Received: from gondolin (ovpn-113-73.ams2.redhat.com [10.36.113.73]) by smtp.corp.redhat.com (Postfix) with ESMTP id 97E2F60C13; Fri, 22 Jan 2021 16:46:09 +0000 (UTC) Date: Fri, 22 Jan 2021 17:46:06 +0100 From: Cornelia Huck To: Matthew Rosato Subject: Re: [PATCH 0/8] s390x/pci: Fixing s390 vfio-pci ISM support Message-ID: <20210122174606.07bb1c68.cohuck@redhat.com> In-Reply-To: <60a2efe8-ff3d-6ea5-230c-408995eaf016@linux.ibm.com> References: <1611089059-6468-1-git-send-email-mjrosato@linux.ibm.com> <511aebd3-fc4f-d7d3-32c2-27720fb38fe8@linux.ibm.com> <15dbd981-7dda-2526-8f13-52ead6298ef1@linux.ibm.com> <914d4af3-32ee-e300-9738-92aececa81d6@linux.ibm.com> <789388f4-983b-2810-7f46-ce7f07022a66@linux.ibm.com> <213c00ca-1b8f-ecee-dd22-d86cad8eb63b@linux.ibm.com> <4a3e13fe-ec6a-27bc-7f30-9ad9691a4522@linux.ibm.com> <9522792d-6677-eed4-f480-4efaaf00dd51@linux.ibm.com> <20210121185036.41fde30c.cohuck@redhat.com> <60a2efe8-ff3d-6ea5-230c-408995eaf016@linux.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=cohuck@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=cohuck@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.182, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: thuth@redhat.com, Pierre Morel , david@redhat.com, Niklas Schnelle , richard.henderson@linaro.org, qemu-s390x@nongnu.org, qemu-devel@nongnu.org, pasic@linux.ibm.com, borntraeger@de.ibm.com, alex.williamson@redhat.com, mst@redhat.com, pbonzini@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 21 Jan 2021 13:06:24 -0500 Matthew Rosato wrote: > On 1/21/21 12:50 PM, Cornelia Huck wrote: > > On Thu, 21 Jan 2021 15:54:22 +0100 > > Niklas Schnelle wrote: > > > >> On 1/21/21 3:46 PM, Pierre Morel wrote: > >>> > >>> > >>> On 1/21/21 2:37 PM, Niklas Schnelle wrote: > >>>> > >>>> > >>>> On 1/21/21 1:30 PM, Pierre Morel wrote: > >>> > >>>>>> > >>>>>> Just wanted to say that we've had a very similar discussion with > >>>>>> Cornelia end of last year and came to the conclusion that explicitly > >>>>>> matching the PFT is likely the safest bet: > >>>>>> https://lkml.org/lkml/2020/12/22/479 > >>>>> > >>>>> What I see there is a discussion on the relation between relaxed access and MIO without explaining to Connie that we have in the kernel the possibility to know if a device support MIO or not independently of it supports the relaxed access. > >>>>> > >>>>> The all point here is about taking decisions for the right reasons. > >>>>> > >>>>> We have the possibility to take the decision based on functionalities and not on a specific PCI function. > >>>> > >>>> Yes but that goes both ways the functionality of the region has to match > >>>> that of the device and at least in it's current state the regions functionality > >>>> matches only ISM in a way that is so specific that it is very unlikely to match anything > >>>> else. For example it can't support a PCI device that requires non-MIO but > >>>> also MSI-X. In its current form it doesn't even support PCI Store only PCI Store > >>>> Block, we had that in an earlier version and it's trivial but then we get the MSI-X > >>>> problem. > >>> > >>> > >>> What does that change if we take one or the other solution considering the checking of MIO/MSIX/relax versus PFT? > >> > >> > >> If it's !MIO && !MSIX && relax_align I'm fine with that check but > >> then we should also add PCISTG to the region. > >> > > > > Just to double check: that would today cover only ISM (which doesn't > > use PCISTG), correct? > > > > Yes, correct -- So to summarize the proposal outlined is to use those > features to determine whether a device should be using the region or not > rather rather than strictly saying only PFT==ISM may use it. > > Practically speaking, ISM is the only device that fits the bill today > when you combine these things, and ISM does not use PCISTG -- so PCISTG > support was simply omitted from the region (prior versions before coming > upstream included it, was dropped since ISM doesn't use it). > > What Niklas suggests here is that, if we are going to be broad in > determining whether the region can be used for a given device vs saying > 'only PFT==ISM', then we can no longer assume that the device doesn't > use PCISTG and as such is suggesting the region should also include > PCISTG support as a means of future compatibility (to ensure non-MIO > PCISTG is issued for the device). Yes, if we go the "check for features" route, including PCISTG makes sense. However, I'm still not quite sure whether checking for ISM vs checking for features makes more sense in the long run. Is ISM that one weird device whose cousins you're not going to invite to the party, or is there a possibility that there will be devices that could make use of the region for performance etc.?