[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for virtual IOMMU binding b/w vIOMMU and passthrough devices


  • To: Elliott Mitchell <ehem+xen@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Wed, 2 Nov 2022 08:50:58 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v35/mGrKtMar9Hx6IpTQx3/+KlpCVHSkPX70F4d5i8g=; b=nQufWMDvh37iXEXSs9WgGBfRHGVJ8s3UGGHsBQXw/ixLrr0n1IiyWwLn8NfZSWKUWimHx4G8MjsIsSCPriz1gbfNhKhBE1KgzYsI6sfPQAXn9u9FAppyBorMzQQmEI4mKQsBkfvp2p0Yjkxi18VmVxE5dYngBoT2ETzlJBYeEcaO8IfGwATeE5Yp5Rs8IUKY2Q0TgSn8uv5Y/wMDWyI4qyTDzaacZrofr1t8MLephycnfxloTirBP+qtHRH/MECn7WYBMhmWmWeaJnY5GCpkarkDZs91dgq15mQk5txfmkGdacMV9QpPewMUhMPY3X6kVZ+pyj5bcq7bWbAZ8wUAqA==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v35/mGrKtMar9Hx6IpTQx3/+KlpCVHSkPX70F4d5i8g=; b=JcflzCNPeR9uBWxDtgaaQ+9IGVpU9uM6I3FWE+NoYuYEZIzQLmw9jiHGyFoqmvB4TMPt5zKc4KgLG2rVMFEjnvzZRyFhhfcSH6/I+pwlQQa1e0y5OVKt6ST2eRrhgpEHQtD2m7BwxznQrSXDfiGb8zDNeRlZHP+oy/BLWnvXKLqHzys2KS4yWc2l5RktVxpvDsqQU8yhBfnA56OKCkBOJpjDVxOhO0IKOsyr8l0lezaIs6brns+iCg2wY9Rc6ersFK7KakQ/Skf13MapGe2tDmMzZQ2lU1wjiMAJ15wr2IziSzo6bqQO585V5X7SiAhi8+1EbbRA2rPmMAdymmEsOw==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Zip11gxD7FZb1ITly/xi/OtyTlNr7/alm08iTAM30sTSadV85RSU0BDEjrwcpZEyQN1K+LKT7M94sKg/ZscY84d7BzLqCr/1UumVpfRl/HebBWbwhPqP7i/a7OsTy9bn0PdJpyrxC0gxEor5eAEtPR5eOXhMxXDLizb6TWoyZ1Na3zdPbNAak/u0gdtt6HSCGmvIqcMgzXFo84Z3A8vIFHUkSEuV8RxgoJJrvXW0GfUIKnqy45oafHeEx93n8r4Xhwm/WmsxW829AZpsOSq2eFVYOHcLm0AWcjP2lLkVV641muC7QhGgAIKgx87QNg1RawQlUd3Zx1/sysLJT6X3LA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=krW6P3SVVFv/inosnx2QeIXLEpNYbl1+AaGPBYqos1Q/dZqld33HKEGyW/POKpBfU9weu5ob8skEQxivzbTvPLakLSqCWPR8EuWVzNqkblhjSeElm4p/AJ+gHHqd9DC3EeBNIwTCIhH/i/MIKLXDPLYyI6SPQ6XBRHK1De8eQh1FbEEZ+FAIgwWRz23Gfkuec5yVv/lbx4eElquBFIu/56ZcBlynTDESJUtmMw4RrfZrQYYMERY4t1+ailnzv3ux5tVP95LNAAlSI0i1qSrtbrRTyEzwcKjVVWYYmuEVmJI/2Qk7IIr/GWmqH4Dp/JxyZQTRePVnl62EecbPyOQhug==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, Xen developer discussion <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Michal Orzel <Michal.Orzel@xxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
  • Delivery-date: Wed, 02 Nov 2022 08:51:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHY6T1V+gcJbmRqpEyt0b8GeG9bFq4grXIAgAAQCACAAFf9AIABVMyAgAAG64CAAVVJgIAAAzuAgAACBwCAAAPNgIADNHqAgABdGACAABWOgIABD7SAgAGs8ICAABi+AIAAQbAAgADQQAA=
  • Thread-topic: Proposal for virtual IOMMU binding b/w vIOMMU and passthrough devices

Hi Elliott,

> On 1 Nov 2022, at 20:25, Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
> 
> On Tue, Nov 01, 2022 at 04:30:31PM +0000, Bertrand Marquis wrote:
>> 
>>> On 1 Nov 2022, at 15:01, Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
>>> 
>>> On Mon, Oct 31, 2022 at 01:26:44PM +0000, Bertrand Marquis wrote:
>>>> 
>>>>> On 30 Oct 2022, at 21:14, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
>>>>> wrote:
>>>>> 
>>>>> Ideally this would be something quick that can be easily invoked as the
>>>>> first step of an external third-party build process.
>>>> 
>>>> I think that we are making this problem a lot to complex and I am not sure
>>>> that all this complexity is required.
>>> 
>>> Speaking of complexity.  Is it just me or does a vIOMMU had an odd sort
>>> of similarity with a Grant Table?
>>> 
>>> Both are about allowing foreign entities access to portions of the
>>> current domain's memory.  Just in the case of a Grant Table the entity
>>> happens to be another domain, whereas for a vIOMMU it is a hardware
>>> device.
>>> 
>>> Perhaps some functionality could be shared between the two?  Perhaps
>>> this is something for the designer of the next version of IOMMU to think
>>> about?  (or perhaps I'm off the deep end and bringing in a silly idea)
>> 
>> I am not quite sure what you mean here.
>> 
>> The IOMMU is something not Xen specific. Linux is using it to restrict the 
>> area
>> of memory accessible to a device using its DMA engine. Here we just try to 
>> give
>> the same possibility when running on top Xen in a transparent way so that the
>> Linux (or an other guest) can continue to do the same even if it is running 
>> on
>> top of Xen.
>> In practice, the guest is not telling us what it does, we just get the 
>> pointer to the
>> first level of page table and we write it in the hardware which is doing the 
>> rest.
>> We need to have a vIOMMU because we need to make sure the guest is only
>> doing this for devices assigned to him and that it is not modifying the 
>> second
>> level of page tables which is used by Xen to make sure that only the memory
>> from the guest is accessible using the DMA engine. 
>> 
>> So I am not exactly seeing the common part with grant tables here.
> 
> With Grant Tables, one domain is allocating pages and then allowing
> another domain to read and potentially write to them.  What is being
> given to Xen is the tuple of page address and other domain.

With the IOMMU we do not get to that information, we only get the first level of
page table pointer and the hardware is doing the rest, protecting the access
using the second level of page tables handled by Xen.

> 
> With the model presently being discussed you would have a vIOMMU for each
> other domain.  The the pages access is being granted to are the pages
> being entered into the vIOMMU page table.

Which Xen does not check.

> 
> Allocate a domain Id to each IOMMU domain and this very much seems quite
> similar to Xen's grant tables.  I'm unsure the two can be unified, but
> they appear to have many common aspects.

>From an high level point of view it might but from the guest point of view the
IOMMU is something used with or without Xen where grant tables are very
specific to Xen. I do not see anything that could be unified there.

Maybe I am missing something here that other could see though :-)

Cheers
Bertrand




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.