From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <mst@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id 821C3CF9
for <dev@dpdk.org>; Wed, 30 Sep 2015 20:55:35 +0200 (CEST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
by mx1.redhat.com (Postfix) with ESMTPS id E625D2FE81A;
Wed, 30 Sep 2015 18:55:34 +0000 (UTC)
Received: from redhat.com (ovpn-116-83.ams2.redhat.com [10.36.116.83])
by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id
t8UItW82022677; Wed, 30 Sep 2015 14:55:32 -0400
Date: Wed, 30 Sep 2015 21:55:31 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vlad Zolotarov <vladz@cloudius-systems.com>
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
Content-Disposition: inline
In-Reply-To: <560C26DC.80209@cloudius-systems.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Having troubles binding an SR-IOV VF to
uio_pci_generic on Amazon instance
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 18:55:35 -0000
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