From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id C14F18D90 for ; Wed, 30 Sep 2015 20:15:58 +0200 (CEST) Received: by wicfx3 with SMTP id fx3so74215208wic.0 for ; Wed, 30 Sep 2015 11:15:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eXx4ja18QR9tPnmuh6oH8S3OzvWJWbAbIwMDt9OXWgk=; b=VSa5ibYdklb6dHJhtgpklFQ5AJK/KB2LI1TgAYzbrselqxw/hqLPTD+5rkZUS5gPNX EZFsskcKlhGtHp/9x/6pKwJ58mx+0tmEgGxrPpu/dHCmHYUW3BVMHeAHXfWJa9bdYojZ +UkShKHGl1XrQRhfm4WCcy9mrbQAcdi3fz1bFDJrXPxvkjvgnnMtgmoIXdn7C/ht7S2O fYfZCHBC3suZE4Cdk321u0ocQiJT+yM8phUfrq283+HQRCO83GJu4SiWuNTNU9U+oqDb 4l9NpLFzcVfFqSUFnZZpm/3UqIxnAJ/KMvX4s+EOAPjURHBLmpoByc8Nw0cidRN63Ttu oL8g== X-Gm-Message-State: ALoCoQn+eDSMGQFWZQTZFK91m8Kwp8mICVyXYwVzY7Ms68mvK75HAvwNTpIxsNQpArnNlLKFyMk2 X-Received: by 10.194.93.229 with SMTP id cx5mr5783798wjb.62.1443636958519; Wed, 30 Sep 2015 11:15:58 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-180-197-252.red.bezeqint.net. [79.180.197.252]) by smtp.googlemail.com with ESMTPSA id xa5sm1927649wjc.20.2015.09.30.11.15.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 11:15:57 -0700 (PDT) To: "Michael S. Tsirkin" References: <20150930004714-mutt-send-email-mst@redhat.com> <560BBB62.3050502@cloudius-systems.com> <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> From: Vlad Zolotarov Message-ID: <560C26DC.80209@cloudius-systems.com> Date: Wed, 30 Sep 2015 21:15:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150930182155-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 18:15:58 -0000 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? How would iommu virtualization change anything? And why do we care about an assigned device to be able to access all Guest memory? >