search for: pasids

...versions will extend it. > > >> * Simplify PROBE request by removing the ack part, and flattening RESV > > >> properties. > > >> * Rename "address space" to "domain". The change might seem futile but > > >> allows to introduce PASIDs and other features cleanly in the next > > >> versions. In the same vein, the few remaining "device" occurrences were > > >> replaced by "endpoint", to avoid any confusion with "the device" > > >> referring to the virtio device...

...t; >> future versions will extend it. > >> * Simplify PROBE request by removing the ack part, and flattening RESV > >> properties. > >> * Rename "address space" to "domain". The change might seem futile but > >> allows to introduce PASIDs and other features cleanly in the next > >> versions. In the same vein, the few remaining "device" occurrences were > >> replaced by "endpoint", to avoid any confusion with "the device" > >> referring to the virtio device across the doc...

...t; >> future versions will extend it. > >> * Simplify PROBE request by removing the ack part, and flattening RESV > >> properties. > >> * Rename "address space" to "domain". The change might seem futile but > >> allows to introduce PASIDs and other features cleanly in the next > >> versions. In the same vein, the few remaining "device" occurrences were > >> replaced by "endpoint", to avoid any confusion with "the device" > >> referring to the virtio device across the doc...

Hi Baolu, On Tue, May 30, 2023 at 01:37:07PM +0800, Lu Baolu wrote: > - The timeout value for the pending page fault messages. Ideally we > should determine the timeout value from the device configuration, but > I failed to find any statement in the PCI specification (version 6.x). > A default 100 milliseconds is selected in the implementation, but it > leave the room for

...s will extend it. >>>>> * Simplify PROBE request by removing the ack part, and flattening RESV >>>>> properties. >>>>> * Rename "address space" to "domain". The change might seem futile but >>>>> allows to introduce PASIDs and other features cleanly in the next >>>>> versions. In the same vein, the few remaining "device" occurrences were >>>>> replaced by "endpoint", to avoid any confusion with "the device" >>>>> referring to the virtio...

...t; >>>>> * Simplify PROBE request by removing the ack part, and flattening RESV > >>>>> properties. > >>>>> * Rename "address space" to "domain". The change might seem futile but > >>>>> allows to introduce PASIDs and other features cleanly in the next > >>>>> versions. In the same vein, the few remaining "device" occurrences were > >>>>> replaced by "endpoint", to avoid any confusion with "the device" > >>>>> referring...

...t; >>>>> * Simplify PROBE request by removing the ack part, and flattening RESV > >>>>> properties. > >>>>> * Rename "address space" to "domain". The change might seem futile but > >>>>> allows to introduce PASIDs and other features cleanly in the next > >>>>> versions. In the same vein, the few remaining "device" occurrences were > >>>>> replaced by "endpoint", to avoid any confusion with "the device" > >>>>> referring...

...ults are available but >> future versions will extend it. >> * Simplify PROBE request by removing the ack part, and flattening RESV >> properties. >> * Rename "address space" to "domain". The change might seem futile but >> allows to introduce PASIDs and other features cleanly in the next >> versions. In the same vein, the few remaining "device" occurrences were >> replaced by "endpoint", to avoid any confusion with "the device" >> referring to the virtio device across the document. >>...

...poke at kernel memory (needed for kernel driver to work). Yes, maybe if device is not buggy it's all fine, but it's better if we do not have to trust the device otherwise the security picture becomes more murky. I suggested attaching a PASID to (some) queues - see my old post "using PASIDs to enable a safe variant of direct ring access". Then using IOMMU with VFIO to limit access through queue to corrent ranges of memory. -- MST

...poke at kernel memory (needed for kernel driver to work). Yes, maybe if device is not buggy it's all fine, but it's better if we do not have to trust the device otherwise the security picture becomes more murky. I suggested attaching a PASID to (some) queues - see my old post "using PASIDs to enable a safe variant of direct ring access". Then using IOMMU with VFIO to limit access through queue to corrent ranges of memory. -- MST

...nly unrecoverable faults are available but > future versions will extend it. > * Simplify PROBE request by removing the ack part, and flattening RESV > properties. > * Rename "address space" to "domain". The change might seem futile but > allows to introduce PASIDs and other features cleanly in the next > versions. In the same vein, the few remaining "device" occurrences were > replaced by "endpoint", to avoid any confusion with "the device" > referring to the virtio device across the document. > * Add implement...

...driver. For the moment only unrecoverable faults are available but future versions will extend it. * Simplify PROBE request by removing the ack part, and flattening RESV properties. * Rename "address space" to "domain". The change might seem futile but allows to introduce PASIDs and other features cleanly in the next versions. In the same vein, the few remaining "device" occurrences were replaced by "endpoint", to avoid any confusion with "the device" referring to the virtio device across the document. * Add implementation notes for RESV...

...driver. For the moment only unrecoverable faults are available but future versions will extend it. * Simplify PROBE request by removing the ack part, and flattening RESV properties. * Rename "address space" to "domain". The change might seem futile but allows to introduce PASIDs and other features cleanly in the next versions. In the same vein, the few remaining "device" occurrences were replaced by "endpoint", to avoid any confusion with "the device" referring to the virtio device across the document. * Add implementation notes for RESV...

...> > Yes, maybe if device is not buggy it's all fine, but it's better if we > > do not have to trust the device otherwise the security picture becomes > > more murky. > > > > I suggested attaching a PASID to (some) queues - see my old post > > "using PASIDs to enable a safe variant of direct ring access". > Ideally we can have a device binding with normal driver in host, meanwhile support to allocate a few queues attaching with PASID on-demand. By vhost mdev transport channel, the data path ability of queues(as a device) can expose to qemu vh...

On Fri, Oct 30, 2020 at 07:44:43PM +0800, Jason Wang wrote: > >On 2020/10/30 ??6:54, Stefano Garzarella wrote: >>On Fri, Oct 30, 2020 at 06:02:18PM +0800, Jason Wang wrote: >>> >>>On 2020/10/30 ??1:43, Stefano Garzarella wrote: >>>>This patch enables the IOTLB API support for vhost-vsock devices, >>>>allowing the userspace to emulate an IOMMU

...> > Introducing a probe request is more flexible than advertising those > features in virtio config, because capabilities are dynamic, and depend on > which devices are attached to an address space. Within a single address > space, devices may support different numbers of contexts (PASIDs), and > some may not support recoverable faults. > > (3) Device responds success with all page table formats implemented by the > physical IOMMU in pg_format. 'model' 0 is invalid, so driver can > initialize the array to 0 and deduce from there which entries have &gt...

...> > Introducing a probe request is more flexible than advertising those > features in virtio config, because capabilities are dynamic, and depend on > which devices are attached to an address space. Within a single address > space, devices may support different numbers of contexts (PASIDs), and > some may not support recoverable faults. > > (3) Device responds success with all page table formats implemented by the > physical IOMMU in pg_format. 'model' 0 is invalid, so driver can > initialize the array to 0 and deduce from there which entries have &gt...

...y isolated in this case. > > Yes, maybe if device is not buggy it's all fine, but > it's better if we do not have to trust the device > otherwise the security picture becomes more murky. > > I suggested attaching a PASID to (some) queues - see my old post "using > PASIDs to enable a safe variant of direct ring access". > > Then using IOMMU with VFIO to limit access through queue to corrent > ranges of memory. Well userspace driver could benefit from this too. And we can even go further by using nested IO page tables to share IOVA address space betw...

...39;t support mdev bus. > > Yes, maybe if device is not buggy it's all fine, but > it's better if we do not have to trust the device > otherwise the security picture becomes more murky. > > I suggested attaching a PASID to (some) queues - see my old post "using > PASIDs to enable a safe variant of direct ring access". It's pretty cool. We also have some similar ideas. Cunming will talk more about this. Best regards, Tiwei Bie > > Then using IOMMU with VFIO to limit access through queue to corrent > ranges of memory. > > > -- >...

iommufd follows the same design as KVM and uses memory cgroups to limit the amount of kernel memory a iommufd file descriptor can pin down. The various internal data structures already use GFP_KERNEL_ACCOUNT to charge its own memory. However, one of the biggest consumers of kernel memory is the IOPTEs stored under the iommu_domain and these allocations are not tracked. This series is the first