From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 567E48DA4 for ; Wed, 30 Sep 2015 21:06:54 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so1136364wic.0 for ; Wed, 30 Sep 2015 12:06:54 -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=ks99Cg1KWnR9DOc1p6UnT8ncyNQPgqWOEPtQPV8nHzw=; b=B1M3pRDtBMjYNbtIuXBKWaS6u74/9AcHyddziYXoLU3fLVb8avSVtHKfoj5bK3QX4c fVbfsYuY8OK0nWETiR86NqwOZXayVNZgrAtnG3bqfO5BWgw+JzKNxSioGFaKW/zaHgRt FlD8JNq/C2/Ms3zSrTsC1KKIf1B4j96gH8EyF9FP3+clNoPjql6JfzxZKyTJousRs26F 7OV7vdjsH+JLrJG79WdRPHnIRRiMFWL9oZvh74/YzjN/+ao5tYbBwPCBBSeA/HUDxNvZ 0Loksyb2ez5dFBADc6UyUDMsyhYHvMKs2OAfaElUaZVpB5UuskLkbPLW+6B62osadaGB zWdg== X-Gm-Message-State: ALoCoQlqZvDeYqmeM08ujp6Ens9lrsbBjISaeRRuABOLOKbc1fdntu/j9MxdbpPkBjD69lZJz2XD X-Received: by 10.194.110.37 with SMTP id hx5mr6167802wjb.149.1443640014084; Wed, 30 Sep 2015 12:06:54 -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 bf8sm2124282wjc.22.2015.09.30.12.06.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 12:06:53 -0700 (PDT) To: "Michael S. Tsirkin" 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> <20150930215027-mutt-send-email-mst@redhat.com> From: Vlad Zolotarov Message-ID: <560C32CC.90708@cloudius-systems.com> Date: Wed, 30 Sep 2015 22:06:52 +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: <20150930215027-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 19:06:54 -0000 On 09/30/15 21:55, Michael S. Tsirkin wrote: > 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. If it does - it will continue to do so with or without the patch and if it doesn't (for any reason) it won't do it even without the patch. So, again, the above (rhetorical) question stands. ;) I think Avi has already explained quite in detail why security is absolutely a non issue in regard to this patch or in regard to UIO in general. Security has to be enforced by some other means like iommu. > >> How would iommu >> virtualization change anything? > Kernel can use an iommu to limit device access to memory of > the controlling application. Ok, this is obvious but what it has to do with enabling using MSI/MSI-X interrupts support in uio_pci_generic? kernel may continue to limit the above access with this support as well. > >> 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. Corrupting Guest's memory due to any SW misbehavior (including bugs) is a non-issue by design - this is what HV and Guest machines were invented for. So, like Avi also said, instead of trying to enforce nobody cares about we'd rather make the developers life easier instead (by applying the not-yet-completed patch I'm working on). >