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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 62B72C433F5 for ; Mon, 4 Apr 2022 17:06:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bZKbPN1UG6u0ouRJj8SJDL7TRbWCJKs5xNM0N5HujRo=; b=FsmPrt5yTmsveq u91MOsZ1RonHDdef0WsvwBHnLeOIp+G+pL52nF0cU+FJOQeTJtkBiRcoq2Ut/+stpI+588HmM4Pp7 i+90q1jZ+vKdOSg5Jb80rDzEUSEJ6/o8ruZWz/STjeGjfH7k9eo58hbiZPWDr4kgEXYL2PwtT5NAv +Mh5bMBjNuKQDk77AuCMcDVJ8MNmabqHuHIf5uemajSMgkB5u4SqRXP4XtchF61b1L5QGTvUD48cJ SBr+3gHkYr7rUIuWJ3QfGrNp8Z1kewTAZVljGjtCGlJ5LgKV3q8uuDRDDcpGh0hL4IGZ9PzFBnKdk SMOlhJjL+fxlNIdUH9Eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbQ8x-00FuLO-Di; Mon, 04 Apr 2022 17:05:31 +0000 Received: from mail-qv1-xf2b.google.com ([2607:f8b0:4864:20::f2b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbQ5f-00Fsmw-3J for linux-arm-kernel@lists.infradead.org; Mon, 04 Apr 2022 17:02:08 +0000 Received: by mail-qv1-xf2b.google.com with SMTP id f3so7930797qvz.10 for ; Mon, 04 Apr 2022 10:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ldaf9TCMiXf7fL1dfzaYzOZ+TQNop4UbheNTFjQvaPQ=; b=DILSNJNq+rL63EuAH3jYTlZXN2YyTH/lzUbBGFQNH3SKIfZSE8jtgB2QmtM5bBleyw MLBizaWPQO1/lE94wIbJUlSiC6cM3dXdJIisc8aUf2yoSUMfKMsPyKsi24GOdA6D85YE /xYzfGZ2Uer3WxSQoCfrclLAfoTuH4Fcj5wl4ZL2lKeY9xTdW4y2r7vH0Qa9KWA+s+sh eMW38qinbbSNeGkgM0ll86nvFu1HOIY6USJXxD3No14R1YOb1vnuKBB5+hiDcfo9OOI0 8YGcQbCbgiBWilV+E6cxwKlycInhIHJLriWoBz3LjEpseXjVVckMCkeVNRUynYgBz2hV aQ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ldaf9TCMiXf7fL1dfzaYzOZ+TQNop4UbheNTFjQvaPQ=; b=Z/3vC5WtauRwhbqZFEc8uFCYH1TqyBOC3FY7LaJ0qlHE3kmrWpx3lOT6gZzYKGK7ev 1HWVosjBHrWHuOL74M5g4yza9K708R9jJ6cEHgnRoudXQu5WgjJdqf2EPmsobWmWy/st 03+tVI8yDbVze3o+gRCxfoed0c6i/RGpQI55tQ1IyIFSWC42MXsuePX5bNisNjt/vcki z9dtdhY4hCG9f/cgcgMT8taGFYRjFI9TujUINQjktCWFqYvtUHGDe+epbyDJadAuD/Fv 0NQ7d019oYZF7423d3MP7aAgtA1GZ3qTy6EWPaW5+dfiiW2OjkDt/JiYbFZ9ZhK11iWR R7dA== X-Gm-Message-State: AOAM531wigie06Hh4m5NCEiBn3sRFq6wEquvmV4IUirN0cPpqlD2sUWy b6xXn6cd7TqbA+OSdk5nUqpmVg== X-Google-Smtp-Source: ABdhPJy/HBdadnCNKiofw8Pq8aQUNK1kcH5nxeVllxEF7eiEPlBVFzDcAkFaS7EwH4xr9jAPm9bxpA== X-Received: by 2002:a05:6214:1c85:b0:443:8347:d7a5 with SMTP id ib5-20020a0562141c8500b004438347d7a5mr508563qvb.11.1649091724773; Mon, 04 Apr 2022 10:02:04 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id n8-20020ac85a08000000b002e06aa02021sm9070384qta.49.2022.04.04.10.02.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:02:03 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1nbQ5a-00CUal-Fs; Mon, 04 Apr 2022 14:02:02 -0300 Date: Mon, 4 Apr 2022 14:02:02 -0300 From: Jason Gunthorpe To: Marc Zyngier Cc: xieming , sashal@kernel.org, catalin.marinas@arm.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, alex.williamson@redhat.com, will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] kvm/arm64: fixed passthrough gpu into vm on arm64 Message-ID: <20220404170202.GR64706@ziepe.ca> References: <20220401090828.614167-1-xieming@kylinos.cn> <87tubcbvgk.wl-maz@kernel.org> <20220404132405.GQ64706@ziepe.ca> <87o81gc3dc.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87o81gc3dc.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220404_100207_450638_2F2AC447 X-CRM114-Status: GOOD ( 25.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 04, 2022 at 03:47:11PM +0100, Marc Zyngier wrote: > > I'm guessing it will turn into a SBSA like thing where the ARM ARM is > > kind of vauge but a SOC has to implement Normal-NC in a certain way to > > be functional for the server market. > > The main issue is that this equivalence isn't architected, so people > can build whatever they want. SBSA means nothing to KVM (or Linux at > large), and there is currently no way to describe which devices are > safe to map as Normal-NC vs Device. And people have, we know of some ARM SOC's that don't work fully with NORMAL_NC for this usage. That is already a problem for baremetal Linux, let alone KVM.. That is why I likened it to SBSA - if you want to build a server SOC that works with existing server software, you have to support NORMAL_NC in this way. Even if it isn't architected. The KVM challenge, at least, is to support a CPU with working NORMAL_NC to create VM that emulates the same CPU with working NORMAL_NC. I didn't quite understand your other remarks though - is there a problem here? It seems like yes from the other thread you pointed at? I would think that KVM should mirror the process page table configuration into the KVM page table and make this into a userspace problem? That turns it into a VFIO problem to negotiate with userspace and set the proper pgprot. At least VFIO has a better chance than KVM to consult DT or something to learn about the specific device's properties. I don't know how VFIO/qemu/etc can make this all work automatically correctly 100% of the time. It seems to me it is the same problem as just basic baremetal "WC" is troubled on ARM in general today. Maybe some tables and a command line option in qemu is the best we can hope for. Long ago I asked that the ARM folks could come with some Linux definition of all the WC-like modes and some arch calls to indicate which one(s) should be used. Nobody seemed interested in doing that, so the above SOC was left non-working in mainline Linux.. > We either have to take userspace's word for it, or rely on some other > heuristics (do this for PCIe, but not anything else). None of which > are entirely safe. Not to mention that no currently available CPU > implements FEAT_DGH. DHG is an optimization, not a functional requirement. Currently available CPUs use one of the more expensive barriers that are architected to include DHG behavior. In any event, this is an important optimization. It is why ARMv9 is introducing a new instruction specifically to optmize it. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel