| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <37d1eee7-92c1-7e07-b73d-7af82fdb1652@arm.com>
Date: Wed, 22 May 2019 16:05:53 +0100
From: Jean-Philippe Brucker <jean-philippe.brucker@....com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Eric Auger <eric.auger@...hat.com>,
Alex Williamson <alex.williamson@...hat.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
Raj Ashok <ashok.raj@...el.com>,
Andriy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v3 09/16] iommu: Introduce guest PASID bind function
On 21/05/2019 23:50, Jacob Pan wrote:
>>> /**
>>> * struct gpasid_bind_data - Information about device and guest
>>> PASID binding
>>> * @version: Version of this data structure
>>> * @format: PASID table entry format
>>> * @flags: Additional information on guest bind request
>>> * @gpgd: Guest page directory base of the guest mm to bind
>>> * @hpasid: Process address space ID used for the guest mm
>>> in host IOMMU
>>> * @gpasid: Process address space ID used for the guest mm
>>> in guest IOMMU
>>
>> Trying to understand the full flow:
>> * @gpasid is the one allocated by the guest using a virtual command.
>> The guest writes @gpgd into the virtual PASID table at index @gpasid,
>> then sends an invalidate command to QEMU.
> yes
>> * QEMU issues a gpasid_bind ioctl (on the mdev or its container?).
>> VFIO forwards. The IOMMU driver installs @gpgd into the PASID table
>> using @hpasid, which is associated with the auxiliary domain.
>>
>> But why do we need the @hpasid field here? Does userspace know about
>> it at all, and does VFIO need to pass it to the IOMMU driver?
>>
> We need to support two guest-host PASID mappings through this API. Idea
> comes from Kevin & Yi.
> 1. identity mapping between host and guest PASID
> 2. guest owns its own pasid space
>
> For option 1, which will plan to support first in this series. There is
> no need for gpasid field since gpasid=hpasid. Guest allocates PASID
> using virtual command interface which gets a host PASID. Then PASID
> cache invalidation in the guest will result in bind_gpasid(), @gpasid is
> not valid in the bind data (indicated by the IOMMU_SVA_GPASID_VAL flag).
>
> For option 2, guest still uses virtual command to allocate guest pasid,
> but this time QEMU does the allocation for gpasid, at the same time
> QEMU will allocate a host pasid then maintain a G->H PASID lookup.
> When guest invalidate its PASID cache with GPASID, QEMU will find the
> match host PASID then pass both gpasid and hpasid down to the host IOMMU
> driver.
> Host IOMMU driver will store the gpgd at the hpasid entry but keep
> track of the gpasid->hpasid mapping. Host will never program gpasid in
> the IOMMU HW. Host IOMMU driver provides G->H PASID translation for PF
> device drivers that emulates mdev config space, i.e. virtual device
> composition module
> (https://events.linuxfoundation.org/wp-content/uploads/2017/12/Hardware-Assisted-Mediated-Pass-Through-with-VFIO-Kevin-Tian-Intel.pdf).
>
> These two options is a per VM choice. Hopefully the two diagrams below
> can help to explain. I will put them in the next patch headers.
Thanks for the explanation, makes sense to me now. So the host kernel
needs to know G->H because the guest may write GPASID into the config
space emulated by the host device driver, and device driver then
retrieves the HPASID via an iommu_ops callback? But the device driver
keeps track of aux domains so isn't HPASID retrievable with
aux_get_pasid() already?
>
> Option 1. Identity G-H PASID mapping diagram.
>
> .-------------. .---------------------------.
> | vIOMMU | | Guest process mm, FL only |
> | | '---------------------------'
> .----------------/
> | PASID Entry |--- PASID cache flush -
> '-------------'\ |
> | | \ |
> | | \ |
> '-------------' \________________ |
> GPASID = HPASID |
> Guest ^ ^ |
> ------| Shadow |-------| VCMD |-----------|------------
> v v | | |
> QEMU v v |
> ------------------------------------------|------------
> Host HPASID = ioasid_alloc() |
> | v
> | sva_bind_gpasid(HPASID)
> |
> .-------------. | .----------------------.
> | pIOMMU | | | Bind FL for GVA-GPA |
> | | | /'----------------------'
> .----------------' |
> | PASID Entry | V (Nested xlate)
> '----------------..---------------------.
> | | |Set SL to GPA-HPA |
> | | '---------------------'
> '-------------'
>
>
>
> Option 2. Non-identity G-H PASID mapping diagram.
>
> .-------------. .---------------------------.
> | vIOMMU | | Guest process mm, FL only |
> | | '---------------------------'
> .----------------/
> | PASID Entry |--- PASID cache flush -
> '-------------'\ | .-------------.
> | | \ | |Guest driver |
> | | \ | |writes GPASID|
> '-------------' \________________ | '-------------'
> GPASID | |
> Guest ^ ^ | |
> ------| Shadow |-------| VCMD |-----------|------------ |
> v v | | | |
> QEMU v v | |
> GPASID = qemu_gpasid_alloc() | |
> keep G->H PASID lookup | |
> ^ v |
> | lookup G->H PASID |
> -------------------|----------------------|------------ |
> Host HPASID = ioasid_alloc() | |
> | v |
> | sva_bind_gpasid(HPASID,GPASID)|
> | keep H-G PASID lookup |
> | \ -------------------.
> .-------------. | .----------------------. \| VDCM |
> | pIOMMU | | | Bind FL for GVA-GPA | | H = lookup(GPASID)|
> | | | /'----------------------' | write H to dev |
> .----------------' | '------------------'
> | PASID Entry | V (Nested xlate)
> '----------------..---------------------.
> | | |Set SL to GPA-HPA |
> | | '---------------------'
> '-------------'
> There is also implications in G-H pasid lookup for PRQ, that would be
> in the later series.
>
>>> * @addr_width: Guest address width. Paging mode can also be
>>> derived.
>>
>> What does the last sentence mean? @addr_width should probably be in
>> @vtd if it provides implicit information.
>>
> Derive 4 or 5 level paging mode from the address width. It can be in
> @vtd but i thought this can be generic.
Yes I think it's generic enough. It may be worth stating that this is
the *virtual* address width, and removing or clarifying what the paging
mode is (the sentence could be confusing on Arm, as we have different
page granules which cannot be derived from the address width)
Thanks,
Jean
Powered by blists - more mailing lists