On Wed, Jan 22, 2025 at 08:55:12AM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2025 at 12:32:56PM +0800, Xu Yilun wrote:
> > On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote:
> > >
>
On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote:
> On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote:
>
> > When VFIO works as a TEE user in VM, it means an attester (e.g. PCI
> > subsystem) has already moved the device to RUN state. So VFIO & DPDK
>
On Mon, Jan 20, 2025 at 02:44:13PM +0100, Christian König wrote:
> Am 21.06.24 um 00:02 schrieb Xu Yilun:
> > On Thu, Jan 16, 2025 at 04:13:13PM +0100, Christian König wrote:
> > > Am 15.01.25 um 18:09 schrieb Jason Gunthorpe:
> > >
> > > On Wed, Jan 15,
On Mon, Jan 20, 2025 at 09:25:25AM -0400, Jason Gunthorpe wrote:
> On Mon, Jun 24, 2024 at 03:59:53AM +0800, Xu Yilun wrote:
> > > But it also seems to me that VFIO should be able to support putting
> > > the device into the RUN state
> >
> > Firstly I think V
5 00:35, Jason Gunthorpe wrote:
> > > > > On Tue, Jun 18, 2024 at 07:28:43AM +0800, Xu Yilun wrote:
> > > > >
> > > > > > > is needed so the secure world can prepare anything it needs prior
> > > > > > > to
> &
On Thu, Jan 16, 2025 at 04:13:13PM +0100, Christian König wrote:
>Am 15.01.25 um 18:09 schrieb Jason Gunthorpe:
>
> On Wed, Jan 15, 2025 at 05:34:23PM +0100, Christian König wrote:
>
> Granted, let me try to improve this.
> Here is a real world example of one of the issues we ran int
On Thu, Jan 16, 2025 at 06:33:48AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 09:34:19AM -0400, Jason Gunthorpe wrote:
> > > Or do you mean some that don't have pages associated with them, and
> > > thus have pfn_valid fail on them? They still have a PFN, just not
> > > one that is
On Mon, Jan 13, 2025 at 12:49:35PM -0400, Jason Gunthorpe wrote:
> On Sat, Jan 11, 2025 at 11:48:06AM +0800, Xu Yilun wrote:
>
> > > > > can be sure what is the correct UAPI. In other words, make the
> > > > > VFIO device into a CC device shou
On Fri, Jan 10, 2025 at 04:38:38PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 08:34:55PM +0100, Simona Vetter wrote:
>
> > So if I'm getting this right, what you need from a functional pov is a
> > dma_buf_tdx_mmap? Because due to tdx restrictions, the normal dma_buf_mmap
I'm not sur
On Fri, Jan 10, 2025 at 09:31:16AM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 12:40:28AM +0800, Xu Yilun wrote:
>
> > So then we face with the shared <-> private device conversion in CoCo VM,
> > and in turn shared <-> private MMIO conversion. MMIO re
On Thu, Jan 09, 2025 at 10:40:51AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 09, 2025 at 12:57:58AM +0800, Xu Yilun wrote:
> > On Wed, Jan 08, 2025 at 09:30:26AM -0400, Jason Gunthorpe wrote:
> > > On Tue, Jan 07, 2025 at 10:27:15PM +0800, Xu Yilun wrote:
> >
> So I guess my first question is, which locking rules do you want here for
> pfn importers?
>
> follow_pfn() is unwanted for private MMIO, so dma_resv_lock.
>
>As Sima explained you either have follow_pfn() and mmu_notifier or you
>have DMA addresses and dma_resv lock / dma_fence.
>
On Wed, Jan 08, 2025 at 07:44:54PM +0100, Simona Vetter wrote:
> On Wed, Jan 08, 2025 at 12:22:27PM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 08, 2025 at 04:25:54PM +0100, Christian König wrote:
> > > Am 08.01.25 um 15:58 schrieb Jason Gunthorpe:
> > > > I have imagined a staged approach were D
> > > 5) iommufd and kvm are both using CPU addresses without DMA. No
> > > exporter mapping is possible
> >
> > We have customers using both KVM and XEN with DMA-buf, so I can clearly
> > confirm that this isn't true.
>
> Today they are mmaping the dma-buf into a VMA and then using KVM's
> follo
On Wed, Jan 08, 2025 at 09:30:26AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 07, 2025 at 10:27:15PM +0800, Xu Yilun wrote:
> > Add a flag for ioctl(VFIO_DEVICE_BIND_IOMMUFD) to mark a device as
> > for private assignment. For these private assigned devices, disallow
> > host
Implement TDX specific private MMIO map/unmap in existing TDP MMU hooks.
Signed-off-by: Yan Zhao
Signed-off-by: Xu Yilun
---
TODO: This patch is still based on the earlier kvm-coco-queue version
(v6.13-rc2). Will follow up the latest SEAMCALL wrapper change. [1]
[1] https://lore.kernel.org
From: Xu Yilun
Export kvm_is_mmio_pfn() for KVM TDX to decide which seamcall should be
used to setup SEPT leaf entry.
TDX Module requires tdh_mem_page_aug() for memory page setup,
and tdh_mmio_map() for MMIO setup.
Signed-off-by: Yan Zhao
Signed-off-by: Xu Yilun
---
arch/x86/kvm/mmu.h
device of the
MMIO region is already assigned to the same CoCo VM.
Signed-off-by: Xu Yilun
---
virt/kvm/vfio_dmabuf.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/virt/kvm/vfio_dmabuf.c b/virt/kvm/vfio_dmabuf.c
index c427ab39c68a..26e01b815ebf 100644
--- a/virt
export struct kvm * handler attached to the vfio device. This
allows KVM to do another sanity check. MMIO should only be assigned to
a CoCo VM if its owner device is already assigned to the same VM.
Signed-off-by: Xu Yilun
---
drivers/vfio/pci/dma_buf.c | 24
include
for these
regions, instead add a new VFIO_REGION_INFO_FLAG_PRIVATE flag to
indicate users should create dma-buf for MMIO mapping in KVM MMU.
Signed-off-by: Xu Yilun
---
drivers/vfio/device_cdev.c | 9 -
drivers/vfio/pci/vfio_pci_core.c | 14 ++
drivers/vfio/pci
//lore.kernel.org/all/ywywgcih6biwz...@nvidia.com/
[2] https://lore.kernel.org/kvm/14-v4-0de2f6c78ed0+9d1-iommufd_...@nvidia.com/
Signed-off-by: Xu Yilun
---
Documentation/virt/kvm/api.rst | 7 ++
include/linux/kvm_host.h | 18 +
include/uapi/linux/kvm.h | 1 +
virt/kvm/Kconf
and
toggles KVM_MEMORY_EXIT_FLAG_PRIVATE. Unlike gmem slot, vfio_dmabuf
slot has only one backend MMIO resource, the switching of GFN's
attribute won't change the way of getting PFN, the vfio_dmabuf specific
way, kvm_vfio_dmabuf_get_pfn().
Signed-off-by: Xu Yilun
---
arch/x86
Implement get_pfn() callback for exported MMIO resources.
Signed-off-by: Xu Yilun
---
drivers/vfio/pci/dma_buf.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/dma_buf.c b/drivers/vfio/pci/dma_buf.c
index 1d5f46744922
[1]
https://lore.kernel.org/kvm/20240624065552.1572580-4-vivek.kasire...@intel.com/
[2]
https://lore.kernel.org/all/ia0pr11mb7185fdd56cfdd0a2b8d21468f8...@ia0pr11mb7185.namprd11.prod.outlook.com/
Original-patch-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
Signed-off-by: Xu Yilun
---
drivers
From: Vivek Kasireddy
There is no need to share the main device pointer (struct vfio_device *)
with all the feature functions as they only need the core device
pointer. Therefore, extract the core device pointer once in the
caller (vfio_pci_core_ioctl_feature) and share it instead.
Signed-off-by
From: Vivek Kasireddy
These helpers are useful for managing additional references taken
on the device from other associated VFIO modules.
Original-patch-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
---
drivers/vfio/vfio_main.c | 2 ++
include/linux/vfio.h | 2 ++
2 files changed, 4
evolving of basic TDX patches.
Vivek Kasireddy (3):
vfio: Export vfio device get and put registration helpers
vfio/pci: Share the core device pointer while invoking feature
functions
vfio/pci: Allow MMIO regions to be exported through dma-buf
Xu Yilun (9):
dma-buf: Introduce dma_buf_get_
e importer choose to do dynamic attach, it also should handle the
dma-buf move notification.
Only the unlocked version of dma_buf_get_pfn is implemented for now,
just because no locked version is used for now.
Signed-off-by: Xu Yilun
---
IIUC, Only get_pfn() is needed but no put_pfn(). The whole
2,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
> {
> struct eventfd_ctx *trigger = arg;
>
> - eventfd_signal(trigger, 1);
> + eventfd_signal(trigger);
For FPGA part,
Acked-by: Xu Yilun
> return IRQ_HANDLED;
> }
29 matches
Mail list logo
