On 2022/11/14 22:37, Yang, Lixiao wrote:
> On 2022/11/14 20:51, Yi Liu wrote:
>> On 2022/11/10 00:57, Jason Gunthorpe wrote:
>>> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
On 2022/11/8 17:19, Nicolin Chen wrote:
> On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe
On 11/9/22 11:57 AM, Jason Gunthorpe wrote:
> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
>> On 2022/11/8 17:19, Nicolin Chen wrote:
>>> On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
>>>
This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
On Mon, Nov 14, 2022 at 10:21:50AM -0500, Matthew Rosato wrote:
> On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> > On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
> AFAICT there is no equivalent means to specify
> vfio_iommu_type1.dma_entry_limit when using iommufd; looks
On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
AFAICT there is no equivalent means to specify
vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
we'll just always get the default 65535.
>>>
>>> No, there is
On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
> >> AFAICT there is no equivalent means to specify
> >> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
> >> we'll just always get the default 65535.
> >
> > No, there is no arbitary limit on iommufd
>
> Yeah,
On 11/14/22 9:23 AM, Jason Gunthorpe wrote:
> On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote:
>> On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
>>> This series provides an alternative container layer for VFIO implemented
>>> using iommufd. This is optional, if CONFIG_IOMMUFD is not set
On 2022/11/14 22:38, Jason Gunthorpe wrote:
On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote:
Our side, Yu He, Lixiao Yang has done below tests on Intel platform with
the above kernel, results are:
1) GVT-g test suit passed, Intel iGFx passthrough passed.
2) NIC passthrough test with
On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote:
> Our side, Yu He, Lixiao Yang has done below tests on Intel platform with
> the above kernel, results are:
>
> 1) GVT-g test suit passed, Intel iGFx passthrough passed.
>
> 2) NIC passthrough test with different guest memory (1G/4G),
On 2022/11/14 20:51, Yi Liu wrote:
> On 2022/11/10 00:57, Jason Gunthorpe wrote:
>> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
>>> On 2022/11/8 17:19, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
> This is on github:
>
On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote:
> On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
> > This series provides an alternative container layer for VFIO implemented
> > using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
> > not be compiled in.
> >
> >
On 2022/11/10 00:57, Jason Gunthorpe wrote:
On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
On 2022/11/8 17:19, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
[...]
v2:
On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
> This series provides an alternative container layer for VFIO implemented
> using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
> not be compiled in.
>
> At this point iommufd can be injected by passing in a iommfd FD to
>
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 8:48 PM
>
> On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote:
> > every mail in this series is shown thrice in lore:
> >
> > https://lore.kernel.org/all/0-v2-65016290f146+33e-
> vfio_iommufd_...@nvidia.com/
> >
> > not sure
On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
> On 2022/11/8 17:19, Nicolin Chen wrote:
> > On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
> >
> > > This is on github:
> > > https://github.com/jgunthorpe/linux/commits/vfio_iommufd
> > [...]
> > > v2:
> > > - Rebase
On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote:
> every mail in this series is shown thrice in lore:
>
> https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/
>
> not sure what caused it but it's annoying to check the conversation there.
It is sort of a
every mail in this series is shown thrice in lore:
https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/
not sure what caused it but it's annoying to check the conversation there.
the iommufd series doesn't have this problem.
> From: Jason Gunthorpe
> Sent: Tuesday,
On 2022/11/8 17:19, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
[...]
v2:
- Rebase to v6.1-rc3, v4 iommufd series
- Fixup comments and commit messages from list remarks
On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
> This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
[...]
> v2:
> - Rebase to v6.1-rc3, v4 iommufd series
> - Fixup comments and commit messages from list remarks
> - Fix leaking of the iommufd for mdevs
This series provides an alternative container layer for VFIO implemented
using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
not be compiled in.
At this point iommufd can be injected by passing in a iommfd FD to
VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer
19 matches
Mail list logo
