On Sat, May 10, 2025 at 10:51:58PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 10/5/25 08:07, Jason Gunthorpe wrote:
> > On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
> > >
> > >
> > > On 7/5/25 22:24, Jason Gunthorpe wrote:
> > > > On Wed, May 07, 2025 at 09:18:29PM +10
On 10/5/25 08:07, Jason Gunthorpe wrote:
On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
On 7/5/25 22:24, Jason Gunthorpe wrote:
On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
We should not destroy the vdevice for something like that. In a CC
On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 7/5/25 22:24, Jason Gunthorpe wrote:
> > On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
> >
> > > > We should not destroy the vdevice for something like that. In a CC
> > > > case that would unp
On 7/5/25 22:24, Jason Gunthorpe wrote:
On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
We should not destroy the vdevice for something like that. In a CC
case that would unplug it from the VM which is not right.
vdevice is not directly seen by the guest, is not it? T
On Wed, May 07, 2025 at 09:18:29PM +1000, Alexey Kardashevskiy wrote:
> > We should not destroy the vdevice for something like that. In a CC
> > case that would unplug it from the VM which is not right.
>
> vdevice is not directly seen by the guest, is not it? The guest will
> see, for example, a
On Tue, May 06, 2025 at 12:55:02PM -0700, Nicolin Chen wrote:
> On Tue, May 06, 2025 at 09:58:47AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
> > > On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > > > On Wed, Apr 30, 2025 at 1
On 6/5/25 22:58, Jason Gunthorpe wrote:
On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
... and I just hit a problem with it - this is basically gues
On Tue, May 06, 2025 at 09:58:47AM -0300, Jason Gunthorpe wrote:
> On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
> > On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> > > The bus numbers can be reas
On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
> On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> >
> > > > ... and I just hit a problem with it - this is basically guest BDFn
> > > > and it works as
> From: Nicolin Chen
> Sent: Tuesday, May 6, 2025 10:54 AM
>
> On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> >
> > > > ... and I just hit a problem with it - this is basically guest BDFn
> > > > and it works as
On 6/5/25 12:53, Nicolin Chen wrote:
On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
... and I just hit a problem with it - this is basically guest BDFn
and it works as long as I'm hotplugging the TEE-IO VF into
On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
>
> > > ... and I just hit a problem with it - this is basically guest BDFn
> > > and it works as long as I'm hotplugging the TEE-IO VF into an SNP VM
> > > but does not
On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
> > ... and I just hit a problem with it - this is basically guest BDFn
> > and it works as long as I'm hotplugging the TEE-IO VF into an SNP VM
> > but does not when I pass through via the QEMU cmdline - bus numbers
> > are not assigne
On Wed, Apr 30, 2025 at 05:54:53PM +1000, Alexey Kardashevskiy wrote:
> On 4/10/24 21:41, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> >
> > > > + __u32 __reserved;
> > > > + __aligned_u64 vdev_id;
>
> I believe this ended up being
On 4/10/24 21:41, Jason Gunthorpe wrote:
On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
+ __u32 __reserved;
+ __aligned_u64 vdev_id;
I believe this ended up being "virt_id"...
What is the nature of this id?
It should be the vIOMMU's HW representation
On Fri, Oct 04, 2024 at 01:33:33PM -0700, Nicolin Chen wrote:
> On Fri, Oct 04, 2024 at 05:17:46PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
> >
> > > With that, I wonder what is better for the initial version of
> > > this structure, a generic
On Fri, Oct 04, 2024 at 05:17:46PM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
>
> > With that, I wonder what is better for the initial version of
> > this structure, a generic virtual ID or a driver-named ID like
> > "Stream ID"? The latter might
On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
> With that, I wonder what is better for the initial version of
> this structure, a generic virtual ID or a driver-named ID like
> "Stream ID"? The latter might be more understandable/flexible,
> so we won't need to justify a generic v
On Fri, Oct 04, 2024 at 03:50:19PM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 04, 2024 at 11:13:46AM -0700, Nicolin Chen wrote:
> > On Fri, Oct 04, 2024 at 08:41:47AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > > > For my SEV-TIO ex
On Fri, Oct 04, 2024 at 11:13:46AM -0700, Nicolin Chen wrote:
> On Fri, Oct 04, 2024 at 08:41:47AM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > > For my SEV-TIO exercise ("trusted IO"), I am looking for a kernel
> > > interface
> > > t
On Fri, Oct 04, 2024 at 08:41:47AM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > For my SEV-TIO exercise ("trusted IO"), I am looking for a kernel interface
> > to pass the guest's BDFs for a specific host device (which is passed
> > throu
On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > + __u32 __reserved;
> > + __aligned_u64 vdev_id;
>
> What is the nature of this id?
It should be the vIOMMU's HW representation for the virtual device.
On ARM it is the stream id, the index into the Stream Table
On A
On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
> > +/**
> > + * struct iommu_viommu_set_vdev_id - ioctl(IOMMU_VIOMMU_SET_VDEV_ID)
> > + * @size: sizeof(struct iommu_viommu_set_vdev_id)
> > + * @viommu_id: viommu ID to associate with the device to store its virtual
> > ID
> >
On 28/8/24 02:59, Nicolin Chen wrote:
Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
that should be linked to a physical device id via an idev pointer.
Continue the support IOMMU_VIOMMU_TYPE_DEFAULT for a core-managed viommu.
Provide a lookup function for drivers to l
On Tue, Oct 01, 2024 at 10:46:20AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 01, 2024 at 01:54:05AM -0700, Nicolin Chen wrote:
> > On Thu, Sep 05, 2024 at 10:38:23AM -0700, Nicolin Chen wrote:
> > > On Thu, Sep 05, 2024 at 01:03:53PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 27, 2024 at 0
On Thu, Sep 05, 2024 at 10:38:23AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 01:03:53PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> > > Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
> > > that should be li
On Tue, Oct 01, 2024 at 01:54:05AM -0700, Nicolin Chen wrote:
> On Thu, Sep 05, 2024 at 10:38:23AM -0700, Nicolin Chen wrote:
> > On Thu, Sep 05, 2024 at 01:03:53PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> > > > Introduce a pair of new ioct
On Fri, Sep 27, 2024 at 3:58 PM Jason Gunthorpe wrote:
>
> On Fri, Sep 27, 2024 at 02:22:20PM +, Mostafa Saleh wrote:
>
> > > We don't support multi SID through this interface, at least in this
> > > version.
> > >
> > > To do multi-sid you have to inform the VM of all the different pSIDs
> >
On Fri, Sep 27, 2024 at 02:22:20PM +, Mostafa Saleh wrote:
> > We don't support multi SID through this interface, at least in this
> > version.
> >
> > To do multi-sid you have to inform the VM of all the different pSIDs
> > the device has and then setup the vSID/pSID translation to map them
On Fri, Sep 27, 2024 at 11:01:41AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 27, 2024 at 01:50:52PM +, Mostafa Saleh wrote:
>
> > My understanding of IOMMUFD is very little, but AFAICT, that means that
> > it’s assumed that each device can only have one stream ID(RID)?
> >
> > As I can see
On Fri, Sep 27, 2024 at 01:50:52PM +, Mostafa Saleh wrote:
> My understanding of IOMMUFD is very little, but AFAICT, that means that
> it’s assumed that each device can only have one stream ID(RID)?
>
> As I can see in patch 17 in arm_smmu_convert_viommu_vdev_id(), it
> converts the virtual I
Hi Nicolin,
On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
> that should be linked to a physical device id via an idev pointer.
>
> Continue the support IOMMU_VIOMMU_TYPE_DEFAULT for a core-managed viommu.
On Wed, Sep 11, 2024 at 07:18:52AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Wednesday, September 11, 2024 3:12 PM
> >
> > On Wed, Sep 11, 2024 at 06:19:10AM +, Tian, Kevin wrote:
> > > > From: Nicolin Chen
> > > > Sent: Friday, September 6, 2024 4:15 AM
> > > >
> > > > On Th
> From: Nicolin Chen
> Sent: Wednesday, September 11, 2024 3:12 PM
>
> On Wed, Sep 11, 2024 at 06:19:10AM +, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Friday, September 6, 2024 4:15 AM
> > >
> > > On Thu, Sep 05, 2024 at 02:43:26PM -0300, Jason Gunthorpe wrote:
> > > > On Thu,
On Wed, Sep 11, 2024 at 06:19:10AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Friday, September 6, 2024 4:15 AM
> >
> > On Thu, Sep 05, 2024 at 02:43:26PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Sep 05, 2024 at 10:37:45AM -0700, Nicolin Chen wrote:
> > > > That being said, if w
> From: Nicolin Chen
> Sent: Friday, September 6, 2024 4:15 AM
>
> On Thu, Sep 05, 2024 at 02:43:26PM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 05, 2024 at 10:37:45AM -0700, Nicolin Chen wrote:
> > > That being said, if we have a clear picture that in the long term
> > > we would extend it to
On Thu, Sep 05, 2024 at 02:43:26PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 05, 2024 at 10:37:45AM -0700, Nicolin Chen wrote:
>
> > we only have virtual device ID in its data structure. Also, the
> > virtual device sounds a bit confusing, given we already have idev.
>
> idev is "iommufd device
On Thu, Sep 05, 2024 at 10:37:45AM -0700, Nicolin Chen wrote:
> we only have virtual device ID in its data structure. Also, the
> virtual device sounds a bit confusing, given we already have idev.
idev is "iommufd device" which is the physical device
The virtual device is the host side handle of
On Thu, Sep 05, 2024 at 01:03:53PM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> > Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
> > that should be linked to a physical device id via an idev pointer.
>
> Given some of t
On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
> Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
> that should be linked to a physical device id via an idev pointer.
Given some of the other discussions around CC I suspect we should
rename these to 'create/
40 matches
Mail list logo
