From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751993AbeFDJuY (ORCPT ); Mon, 4 Jun 2018 05:50:24 -0400 Received: from gate.crashing.org ([63.228.1.57]:47776 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbeFDJuX (ORCPT ); Mon, 4 Jun 2018 05:50:23 -0400 Message-ID: Subject: Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices From: Benjamin Herrenschmidt To: David Gibson Cc: "Michael S. Tsirkin" , Anshuman Khandual , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, aik@ozlabs.ru, robh@kernel.org, joe@perches.com, elfring@users.sourceforge.net, jasowang@redhat.com, mpe@ellerman.id.au, hch@infradead.org Date: Mon, 04 Jun 2018 19:48:54 +1000 In-Reply-To: <20180604085742.GQ4251@umbus> References: <20180522063317.20956-1-khandual@linux.vnet.ibm.com> <20180523213703-mutt-send-email-mst@kernel.org> <20180604085742.GQ4251@umbus> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 (3.28.1-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-06-04 at 18:57 +1000, David Gibson wrote: > > > - First qemu doesn't know that the guest will switch to "secure mode" > > in advance. There is no difference between a normal and a secure > > partition until the partition does the magic UV call to "enter secure > > mode" and qemu doesn't see any of it. So who can set the flag here ? > > This seems weird to me. As a rule HV calls should go through qemu - > or be allowed to go directly to KVM *by* qemu. It's not an HV call, it's a UV call, qemu won't see it, qemu isn't trusted. Now the UV *will* reflect that to the HV via some synthetized HV calls, and we *could* have those do a pass by qemu, however, so far, our entire design doesn't rely on *any* qemu knowledge whatsoever and it would be sad to add it just for that purpose. Additionally, this is rather orthogonal, see my other email, the problem we are trying to solve is *not* a qemu problem and it doesn't make sense to leak that into qemu. > We generally reserve > the latter for hot path things. Since this isn't a hot path, having > the call handled directly by the kernel seems wrong. > > Unless a "UV call" is something different I don't know about. Yes, a UV call goes to the Ultravisor, not the Hypervisor. The Hypervisor isn't trusted. > > - Second, when using VIRTIO_F_IOMMU_PLATFORM, we also make qemu (or > > vhost) go through the emulated MMIO for every access to the guest, > > which adds additional overhead. > Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices Date: Mon, 04 Jun 2018 19:48:54 +1000 Message-ID: References: <20180522063317.20956-1-khandual@linux.vnet.ibm.com> <20180523213703-mutt-send-email-mst@kernel.org> <20180604085742.GQ4251@umbus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180604085742.GQ4251@umbus> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: David Gibson Cc: robh@kernel.org, "Michael S. Tsirkin" , mpe@ellerman.id.au, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, hch@infradead.org, joe@perches.com, linuxppc-dev@lists.ozlabs.org, elfring@users.sourceforge.net, Anshuman Khandual List-Id: virtualization@lists.linuxfoundation.org On Mon, 2018-06-04 at 18:57 +1000, David Gibson wrote: > > > - First qemu doesn't know that the guest will switch to "secure mode" > > in advance. There is no difference between a normal and a secure > > partition until the partition does the magic UV call to "enter secure > > mode" and qemu doesn't see any of it. So who can set the flag here ? > > This seems weird to me. As a rule HV calls should go through qemu - > or be allowed to go directly to KVM *by* qemu. It's not an HV call, it's a UV call, qemu won't see it, qemu isn't trusted. Now the UV *will* reflect that to the HV via some synthetized HV calls, and we *could* have those do a pass by qemu, however, so far, our entire design doesn't rely on *any* qemu knowledge whatsoever and it would be sad to add it just for that purpose. Additionally, this is rather orthogonal, see my other email, the problem we are trying to solve is *not* a qemu problem and it doesn't make sense to leak that into qemu. > We generally reserve > the latter for hot path things. Since this isn't a hot path, having > the call handled directly by the kernel seems wrong. > > Unless a "UV call" is something different I don't know about. Yes, a UV call goes to the Ultravisor, not the Hypervisor. The Hypervisor isn't trusted. > > - Second, when using VIRTIO_F_IOMMU_PLATFORM, we also make qemu (or > > vhost) go through the emulated MMIO for every access to the guest, > > which adds additional overhead. > Ben.