Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5537625ybl; Tue, 10 Dec 2019 07:37:13 -0800 (PST) X-Google-Smtp-Source: APXvYqxUOebMdoil8yQQHWh1w4AfvVvxCIkFT9EqcBjPCUDy63DegDaqGH7jNmWubG486nbphwwy X-Received: by 2002:a05:6808:35a:: with SMTP id j26mr4463389oie.163.1575992233128; Tue, 10 Dec 2019 07:37:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575992233; cv=none; d=google.com; s=arc-20160816; b=dNNr5n8I+YNop13wshuyPoab1QgbiBZ+vjVj3K7Nu7NylgyxgALAHHjStXFDkaO4aY imMKAw6kleOnlEUzXXFwBmEIeso3nVDNwgd+IWncAfmYxFTGmwtzycVzUyV1NadOeo3d x23pdRUqM9Q6dR+JnTckvlro7TDwc62FFP1sS8RQptTsXPuPsDBKNmur75aPlw6/nbyP lQOy/AcwVoJe/YVEjGOy1lbNB728/u5QwmJkshXIjIuAAviRrRdqzsGKNVsFWmAazXfg kZIIRswJAx+OCQ+TrwUfbu9b0+8HO+lG5QstCB67xA4r414Uvy+/glzDr4yPPOVy3p/O QpSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:cc:to:from :date; bh=ebo/6iACpT3SDeUOsad4jN+LFCifWrto2LSHF+bnEDY=; b=On/O3TRpLb4psYcKEn6JTp0TUgdSG3PRRgdbtvzM5D/ZyMgivx3+/K43kLDSsglWiu kQAK1s6imDTlwz3ucSO1DKBl4v+NSMqmYuYfziwYkyWhYtxo06Jq6U+ScoMe/VYopS6B TlPqUEEDBsSO0KXGK+6V+mMwiCB3cBzQTJfBGTSJXOrisdDrVAIhTzERBFPmHlFt6PCO E85qJMWrG/baHUkI7h+go0DGWYeSTvLkxflVTU43U1zxzO/Ag3Uhzs6SDMruCILvxZqx vYT+Eg7d42E+AZ8ssP2OszeWpP1olkfv9YtOsaFWfXLhYsnKcKPgYZROuzKkMQfVPK/A ekHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d13si2018056ote.242.2019.12.10.07.37.00; Tue, 10 Dec 2019 07:37:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727562AbfLJPgG (ORCPT + 99 others); Tue, 10 Dec 2019 10:36:06 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:52106 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727380AbfLJPgG (ORCPT ); Tue, 10 Dec 2019 10:36:06 -0500 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBAFa3HJ139778 for ; Tue, 10 Dec 2019 10:36:05 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2wt2ktbsad-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Dec 2019 10:36:04 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Dec 2019 15:35:54 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 10 Dec 2019 15:35:50 -0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id xBAFZmlZ32571458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Dec 2019 15:35:48 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 61FBCA405F; Tue, 10 Dec 2019 15:35:48 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1D778A4054; Tue, 10 Dec 2019 15:35:45 +0000 (GMT) Received: from oc0525413822.ibm.com (unknown [9.80.204.137]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 10 Dec 2019 15:35:44 +0000 (GMT) Date: Tue, 10 Dec 2019 07:35:42 -0800 From: Ram Pai To: Alexey Kardashevskiy Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org, david@gibson.dropbear.id.au, paulus@ozlabs.org, mdroth@linux.vnet.ibm.com, hch@lst.de, andmike@us.ibm.com, sukadev@linux.vnet.ibm.com, mst@redhat.com, ram.n.pai@gmail.com, cai@lca.pw, tglx@linutronix.de, bauerman@linux.ibm.com, linux-kernel@vger.kernel.org, leonardo@linux.ibm.com Reply-To: Ram Pai References: <1575681159-30356-1-git-send-email-linuxram@us.ibm.com> <1575681159-30356-2-git-send-email-linuxram@us.ibm.com> <20191210051244.GB5702@oc0525413822.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 19121015-0020-0000-0000-000003963F28 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19121015-0021-0000-0000-000021ED80FB Message-Id: <20191210153542.GB5709@oc0525413822.ibm.com> Subject: RE: [PATCH v5 1/2] powerpc/pseries/iommu: Share the per-cpu TCE page with the hypervisor. X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-10_03:2019-12-10,2019-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=18 spamscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 malwarescore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912100133 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote: > > > On 10/12/2019 16:12, Ram Pai wrote: > > On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote: > >> > >> > >> On 07/12/2019 12:12, Ram Pai wrote: > >>> H_PUT_TCE_INDIRECT hcall uses a page filled with TCE entries, as one of > >>> its parameters. On secure VMs, hypervisor cannot access the contents of > >>> this page since it gets encrypted. Hence share the page with the > >>> hypervisor, and unshare when done. > >> > >> > >> I thought the idea was to use H_PUT_TCE and avoid sharing any extra > >> pages. There is small problem that when DDW is enabled, > >> FW_FEATURE_MULTITCE is ignored (easy to fix); I also noticed complains > >> about the performance on slack but this is caused by initial cleanup of > >> the default TCE window (which we do not use anyway) and to battle this > >> we can simply reduce its size by adding > > > > something that takes hardly any time with H_PUT_TCE_INDIRECT, takes > > 13secs per device for H_PUT_TCE approach, during boot. This is with a > > 30GB guest. With larger guest, the time will further detoriate. > > > No it will not, I checked. The time is the same for 2GB and 32GB guests- > the delay is caused by clearing the small DMA window which is small by > the space mapped (1GB) but quite huge in TCEs as it uses 4K pages; and > for DDW window + emulated devices the IOMMU page size will be 2M/16M/1G > (depends on the system) so the number of TCEs is much smaller. I cant get your results. What changes did you make to get it? > > > > > >> > >> -global > >> spapr-pci-host-bridge.dma_win_size=0x4000000 > > > > This option, speeds it up tremendously. But than should this option be > > enabled in qemu by default? only for secure VMs? for both VMs? > > > As discussed in slack, by default we do not need to clear the entire TCE > table and we only have to map swiotlb buffer using the small window. It > is a guest kernel change only. Thanks, Can you tell me what code you are talking about here. Where is the TCE table getting cleared? What code needs to be changed to not clear it? Is the code in tce_buildmulti_pSeriesLP(), the one that does the clear aswell? > > But before I close, you have not told me clearly, what is the problem with; 'share the page, make the H_PUT_INDIRECT_TCE hcall, unshare the page'. Remember this is the same page that is earmarked for doing H_PUT_INDIRECT_TCE, not by my patch, but its already earmarked by the existing code. So it not some random buffer that is picked. Second this page is temporarily shared and unshared, it does not stay shared for life. It does not slow the boot. it does not need any special command line options on the qemu. Shared pages technology was put in place, exactly for the purpose of sharing data with the hypervisor. We are using this technology exactly for that purpose. And finally I agreed with your concern of having shared pages staying around. Hence i addressed that concern, by unsharing the page. At this point, I fail to understand your concern. RP