On 17/06/15 13:48, Yu, Zhang wrote:
> Hi Malcolm,
>
> Thank you very much for accommodate our XenGT requirement in your
> design. Following are some XenGT related questions. :)
>
> On 6/13/2015 12:43 AM, Malcolm Crossley wrote:
>> Hi All,
>>
>> IOMMUOP_map_foreign_page
>>
>> T
>>> On 17.06.15 at 14:48, wrote:
>Thank you very much for accommodate our XenGT requirement in your
> design. Following are some XenGT related questions. :)
Please trim your replies.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://l
Hi Malcolm,
Thank you very much for accommodate our XenGT requirement in your
design. Following are some XenGT related questions. :)
On 6/13/2015 12:43 AM, Malcolm Crossley wrote:
Hi All,
Here is a design for allowing guests to control the IOMMU. This
allows for the guest GFN mapping to be p
>>> On 16.06.15 at 16:47, wrote:
> On 16/06/15 14:19, Jan Beulich wrote:
> On 12.06.15 at 18:43, wrote:
>>> IOMMU_QUERY_map_all_gfns 1IOMMUOP_map_page subop can map any MFN
>>> not used by Xen
>>
>> "gfns" or "MFN"?
>
> gfns . This is meant
On 16/06/15 14:19, Jan Beulich wrote:
On 12.06.15 at 18:43, wrote:
>> IOMMUOP_query_caps
>> --
>>
>> This subop queries the runtime capabilities of the PV-IOMMU interface for
>> the
>> specific called domain. This subop uses `struct pv_iommu_op` directly.
>
> "calling domain
>>> On 12.06.15 at 18:43, wrote:
> IOMMUOP_query_caps
> --
>
> This subop queries the runtime capabilities of the PV-IOMMU interface for
> the
> specific called domain. This subop uses `struct pv_iommu_op` directly.
"calling domain" perhaps?
> --
Hi All,
Here is a design for allowing guests to control the IOMMU. This
allows for the guest GFN mapping to be programmed into the IOMMU and
avoid using the SWIOTLB bounce buffer technique in the Linux kernel
(except for legacy 32 bit DMA IO devices).
Draft B has been expanded to include Bus Addr
