From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance Date: Wed, 30 Sep 2015 21:55:31 +0300 Message-ID: <20150930215027-mutt-send-email-mst@redhat.com> References: <20150930134533-mutt-send-email-mst@redhat.com> <560BC6C9.4020505@cloudius-systems.com> <20150930143927-mutt-send-email-mst@redhat.com> <560BCD2F.5060505@cloudius-systems.com> <20150930150115-mutt-send-email-mst@redhat.com> <560BD284.7040505@cloudius-systems.com> <20150930151632-mutt-send-email-mst@redhat.com> <560BDA81.6070807@cloudius-systems.com> <20150930182155-mutt-send-email-mst@redhat.com> <560C26DC.80209@cloudius-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" To: Vlad Zolotarov Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 821C3CF9 for ; Wed, 30 Sep 2015 20:55:35 +0200 (CEST) Content-Disposition: inline In-Reply-To: <560C26DC.80209@cloudius-systems.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote: > > > On 09/30/15 18:26, Michael S. Tsirkin wrote: > >On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote: > >>How not virtualizing iommu forces "all or nothing" approach? > >Looks like you can't limit an assigned device to only access part of > >guest memory that belongs to a given process. Either let it access all > >of guest memory ("all") or don't assign the device ("nothing"). > > Ok. A question then: can u limit the assigned device to only access part of > the guest memory even if iommu was virtualized? That's exactly what an iommu does - limit the device io access to memory. > How would iommu > virtualization change anything? Kernel can use an iommu to limit device access to memory of the controlling application. > And why do we care about an assigned device > to be able to access all Guest memory? Because we want to be reasonably sure a kernel memory corruption is not a result of a bug in a userspace application. -- MST