On Tue, Jun 10, 2025 at 02:20:03PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 31/5/25 02:23, Xu Yilun wrote:
> > On Fri, May 30, 2025 at 12:29:30PM +1000, Alexey Kardashevskiy wrote:
> > >
> > >
> > > On 30/5/25 00:41, Xu Yilun wrote:
> > > > > > > >
> > > > > > > > FLR to a bound device is a
On 6/10/25 12:20, Alexey Kardashevskiy wrote:
On 31/5/25 02:23, Xu Yilun wrote:
On Fri, May 30, 2025 at 12:29:30PM +1000, Alexey Kardashevskiy wrote:
On 30/5/25 00:41, Xu Yilun wrote:
FLR to a bound device is absolutely fine, just break the CC state.
Sometimes it is exactly what host need
On 14/5/25 13:20, Xu Yilun wrote:
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
On 10/5/25 13:47, Xu Yilun wrote:
On Fri, May 09, 2025 at 03:43:18PM -0300, Jason Gunthorpe wrote:
On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
On Fri, May 09, 2025 at 07:
On 31/5/25 02:23, Xu Yilun wrote:
On Fri, May 30, 2025 at 12:29:30PM +1000, Alexey Kardashevskiy wrote:
On 30/5/25 00:41, Xu Yilun wrote:
FLR to a bound device is absolutely fine, just break the CC state.
Sometimes it is exactly what host need to stop CC immediately.
The problem is in VFI
On Fri, May 30, 2025 at 12:29:30PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 30/5/25 00:41, Xu Yilun wrote:
> > > > > >
> > > > > > FLR to a bound device is absolutely fine, just break the CC state.
> > > > > > Sometimes it is exactly what host need to stop CC immediately.
> > > > > > The prob
On Thu, May 29, 2025 at 01:29:23PM -0300, Jason Gunthorpe wrote:
> On Thu, May 29, 2025 at 10:41:15PM +0800, Xu Yilun wrote:
>
> > > On AMD, the host can "revoke" at any time, at worst it'll see RMP
> > > events from IOMMU. Thanks,
> >
> > Is the RMP event firstly detected by host or guest? If by
On 30/5/25 00:41, Xu Yilun wrote:
FLR to a bound device is absolutely fine, just break the CC state.
Sometimes it is exactly what host need to stop CC immediately.
The problem is in VFIO's pre-FLR handling so we need to patch VFIO, not
PCI core.
What is a problem here exactly?
FLR by the ho
On Thu, May 29, 2025 at 10:41:15PM +0800, Xu Yilun wrote:
> > On AMD, the host can "revoke" at any time, at worst it'll see RMP
> > events from IOMMU. Thanks,
>
> Is the RMP event firstly detected by host or guest? If by host,
> host could fool guest by just suppress the event. Guest thought the
> > > >
> > > > FLR to a bound device is absolutely fine, just break the CC state.
> > > > Sometimes it is exactly what host need to stop CC immediately.
> > > > The problem is in VFIO's pre-FLR handling so we need to patch VFIO, not
> > > > PCI core.
> > >
> > > What is a problem here exactly?
>
On 24/5/25 13:13, Xu Yilun wrote:
On Thu, May 22, 2025 at 01:45:57PM +1000, Alexey Kardashevskiy wrote:
On 16/5/25 02:04, Xu Yilun wrote:
On Wed, May 14, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
We have an awkward fit for
On Tue, May 20, 2025 at 08:57:42PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 16/5/25 04:02, Xu Yilun wrote:
> > > IMHO, I think it might be helpful that you can picture out what are the
> > > minimum requirements (function/life cycle) to the current IOMMUFD TSM
> > > bind architecture:
> > >
>
On Thu, May 22, 2025 at 01:45:57PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 16/5/25 02:04, Xu Yilun wrote:
> > On Wed, May 14, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
> > > > > We have an awkward fit for what CCA people a
On 16/5/25 02:04, Xu Yilun wrote:
On Wed, May 14, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
We have an awkward fit for what CCA people are doing to the various
Linux APIs. Looking somewhat maximally across all the arches a "bin
On 16/5/25 02:53, Zhi Wang wrote:
On Thu, 15 May 2025 16:44:47 +
Zhi Wang wrote:
On 15.5.2025 13.29, Alexey Kardashevskiy wrote:
On 13/5/25 20:03, Zhi Wang wrote:
On Mon, 12 May 2025 11:06:17 -0300
Jason Gunthorpe wrote:
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevs
On 16/5/25 04:02, Xu Yilun wrote:
IMHO, I think it might be helpful that you can picture out what are the
minimum requirements (function/life cycle) to the current IOMMUFD TSM
bind architecture:
1.host tsm_bind (preparation) is in IOMMUFD, triggered by QEMU handling
the TVM-HOST call.
2. TDI
On Fri, May 16, 2025 at 09:49:53AM -0300, Jason Gunthorpe wrote:
> On Fri, May 16, 2025 at 02:19:45PM +0800, Xu Yilun wrote:
> > > I don't know why you'd disable a viommu while the VM is running,
> > > doesn't make sense.
> >
> > Here it means remove the CC setup for viommu, shared setup is still
On Fri, May 16, 2025 at 02:19:45PM +0800, Xu Yilun wrote:
> > I don't know why you'd disable a viommu while the VM is running,
> > doesn't make sense.
>
> Here it means remove the CC setup for viommu, shared setup is still
> kept.
That might makes sense for the vPCI function, but not the vIOMMU.
On Thu, May 15, 2025 at 04:21:27PM -0300, Jason Gunthorpe wrote:
> On Fri, May 16, 2025 at 02:02:29AM +0800, Xu Yilun wrote:
> > > IMHO, I think it might be helpful that you can picture out what are the
> > > minimum requirements (function/life cycle) to the current IOMMUFD TSM
> > > bind architect
On Thu, May 15, 2025 at 02:56:58PM -0300, Jason Gunthorpe wrote:
> On Fri, May 16, 2025 at 12:04:04AM +0800, Xu Yilun wrote:
> > > arches this was mostly invisible to the hypervisor?
> >
> > Attest & Accept can be invisible to hypervisor, or host just help pass
> > data blobs between guest, firmwa
On Fri, May 16, 2025 at 02:02:29AM +0800, Xu Yilun wrote:
> > IMHO, I think it might be helpful that you can picture out what are the
> > minimum requirements (function/life cycle) to the current IOMMUFD TSM
> > bind architecture:
> >
> > 1.host tsm_bind (preparation) is in IOMMUFD, triggered by Q
> IMHO, I think it might be helpful that you can picture out what are the
> minimum requirements (function/life cycle) to the current IOMMUFD TSM
> bind architecture:
>
> 1.host tsm_bind (preparation) is in IOMMUFD, triggered by QEMU handling
> the TVM-HOST call.
> 2. TDI acceptance is handled in
On Fri, May 16, 2025 at 12:04:04AM +0800, Xu Yilun wrote:
> > arches this was mostly invisible to the hypervisor?
>
> Attest & Accept can be invisible to hypervisor, or host just help pass
> data blobs between guest, firmware & device.
>
> Bind cannot be host agnostic, host should be aware not to
On 15.5.2025 13.29, Alexey Kardashevskiy wrote:
>
>
> On 13/5/25 20:03, Zhi Wang wrote:
>> On Mon, 12 May 2025 11:06:17 -0300
>> Jason Gunthorpe wrote:
>>
>>> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>>>
>> I'm surprised by this.. iommufd shouldn't be doing PCI s
On Thu, 15 May 2025 16:44:47 +
Zhi Wang wrote:
> On 15.5.2025 13.29, Alexey Kardashevskiy wrote:
> >
> >
> > On 13/5/25 20:03, Zhi Wang wrote:
> >> On Mon, 12 May 2025 11:06:17 -0300
> >> Jason Gunthorpe wrote:
> >>
> >>> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy
> >>>
On Wed, May 14, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
> On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
> > > We have an awkward fit for what CCA people are doing to the various
> > > Linux APIs. Looking somewhat maximally across all the arches a "bind"
> > > for a CC vPCI devi
On 13/5/25 20:03, Zhi Wang wrote:
On Mon, 12 May 2025 11:06:17 -0300
Jason Gunthorpe wrote:
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
I'm surprised by this.. iommufd shouldn't be doing PCI stuff,
it is just about managing the translation control of the device.
On Wed, 14 May 2025 17:47:12 +0800
Xu Yilun wrote:
> On Tue, May 13, 2025 at 01:03:15PM +0300, Zhi Wang wrote:
> > On Mon, 12 May 2025 11:06:17 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy
> > > wrote:
> > >
> > > > > > I'm surprised
On Wed, May 14, 2025 at 03:02:53PM +0800, Xu Yilun wrote:
> > We have an awkward fit for what CCA people are doing to the various
> > Linux APIs. Looking somewhat maximally across all the arches a "bind"
> > for a CC vPCI device creation operation does:
> >
> > - Setup the CPU page tables for the
On Tue, May 13, 2025 at 01:03:15PM +0300, Zhi Wang wrote:
> On Mon, 12 May 2025 11:06:17 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
> >
> > > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff,
> > > > > it is just abo
On Mon, May 12, 2025 at 11:06:17AM -0300, Jason Gunthorpe wrote:
> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>
> > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is
> > > > just about managing the translation control of the device.
> > >
> > > I h
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 10/5/25 13:47, Xu Yilun wrote:
> > On Fri, May 09, 2025 at 03:43:18PM -0300, Jason Gunthorpe wrote:
> > > On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
> > > > On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Y
On Mon, 12 May 2025 11:06:17 -0300
Jason Gunthorpe wrote:
> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>
> > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff,
> > > > it is just about managing the translation control of the device.
> > >
> > > I have a
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
> > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is
> > > just about managing the translation control of the device.
> >
> > I have a little difficulty to understand. Is TSM bind PCI stuff? To me
> > it is
On 10/5/25 13:47, Xu Yilun wrote:
On Fri, May 09, 2025 at 03:43:18PM -0300, Jason Gunthorpe wrote:
On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote:
On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
Ping?
On Fri, May 09, 2025 at 03:43:18PM -0300, Jason Gunthorpe wrote:
> On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
> > On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote:
> > > On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
> > > > Ping?
> > >
> > > Sorry for
On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
> On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote:
> > On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
> > > Ping?
> >
> > Sorry for late reply from vacation.
> >
> > > Also, since there is pushback on 01/12
On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote:
> On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
> > Ping?
>
> Sorry for late reply from vacation.
>
> > Also, since there is pushback on 01/12 "dma-buf: Introduce
> > dma_buf_get_pfn_unlocked() kAPI", what is the p
On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote:
> Ping?
Sorry for late reply from vacation.
> Also, since there is pushback on 01/12 "dma-buf: Introduce
> dma_buf_get_pfn_unlocked() kAPI", what is the plan now? Thanks,
As disscussed in the thread, this kAPI is not well con
Ping?
Also, since there is pushback on 01/12 "dma-buf: Introduce
dma_buf_get_pfn_unlocked() kAPI", what is the plan now? Thanks,
On 29/4/25 17:50, Alexey Kardashevskiy wrote:
On 29/4/25 16:48, Alexey Kardashevskiy wrote:
On 8/1/25 01:27, Xu Yilun wrote:
This series is based on an earlier k
On 29/4/25 16:48, Alexey Kardashevskiy wrote:
On 8/1/25 01:27, Xu Yilun wrote:
This series is based on an earlier kvm-coco-queue version (v6.12-rc2)
Has this been pushed somewhere public? The patchset does not apply on top of
v6.12-rc2, for example (I fixed locally).
Also, is there somewhe
On 8/1/25 01:27, Xu Yilun wrote:
This series is based on an earlier kvm-coco-queue version (v6.12-rc2)
Has this been pushed somewhere public? The patchset does not apply on top of
v6.12-rc2, for example (I fixed locally).
Also, is there somewhere a QEMU tree using this? I am trying to use this
This series is based on an earlier kvm-coco-queue version (v6.12-rc2)
which includes all basic TDX patches.
The series is to start the early stage discussion of the private MMIO
handling for Coco-VM, which is part of the Private Device
Assignment (aka TEE-IO, TIO) enabling. There are already some
42 matches
Mail list logo
