On Tue, Oct 10, 2023 at 3:58 PM Xuan Zhuo wrote:
>
> On Tue, 10 Oct 2023 14:41:39 +0800, Jason Wang wrote:
> > On Tue, Oct 10, 2023 at 11:11 AM Xuan Zhuo
> > wrote:
> > >
> > > Some buggy devices, the common cfg size may not match the features.
> > >
> > > This patch checks the common cfg size
On Tue, Oct 10, 2023 at 2:19 PM Akihiko Odaki wrote:
>
> On 2023/10/10 15:00, Jason Wang wrote:
> > On Tue, Oct 10, 2023 at 1:51 PM Akihiko Odaki
> > wrote:
> >>
> >> On 2023/10/10 14:45, Jason Wang wrote:
> >>> On Tue, Oct 10, 2023 at 9:52 AM Akihiko Odaki
> >>> wrote:
>
> On
On Tue, Oct 10, 2023 at 07:09:08PM +0300, Yishai Hadas wrote:
>
> > > Assuming that we'll put each command inside virtio as the generic layer,
> > > we
> > > won't be able to call/use this API internally to get the PF as of cyclic
> > > dependencies between the modules, link will fail.
I just
On Tue, Oct 10, 2023 at 04:21:15PM +, Parav Pandit wrote:
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, October 10, 2023 9:37 PM
> >
> > On Tue, Oct 10, 2023 at 12:03:29PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Oct 10, 2023 at 12:59:37PM -0300, Jason Gunthorpe wrote:
> > > > On
> From: Jason Gunthorpe
> Sent: Tuesday, October 10, 2023 9:37 PM
>
> On Tue, Oct 10, 2023 at 12:03:29PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 12:59:37PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 10, 2023 at 11:14:56AM -0400, Michael S. Tsirkin wrote:
> > >
> > > >
On 10/10/2023 18:58, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 06:43:32PM +0300, Yishai Hadas wrote:
On 10/10/2023 18:14, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
On 10/10/2023 17:54, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at
On Tue, Oct 10, 2023 at 12:59:37PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 10, 2023 at 11:14:56AM -0400, Michael S. Tsirkin wrote:
>
> > I suggest 3 but call it on the VF. commands will switch to PF
> > internally as needed. For example, intel might be interested in exposing
> > admin
> From: Yishai Hadas
> Sent: Tuesday, October 10, 2023 9:14 PM
>
> On 10/10/2023 18:14, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
> >> On 10/10/2023 17:54, Michael S. Tsirkin wrote:
> >>> On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason
On Tue, Oct 10, 2023 at 06:43:32PM +0300, Yishai Hadas wrote:
> On 10/10/2023 18:14, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
> > > On 10/10/2023 17:54, Michael S. Tsirkin wrote:
> > > > On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason Gunthorpe
On 10/10/2023 18:14, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
On 10/10/2023 17:54, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason Gunthorpe wrote:
On Tue, Oct 10, 2023 at 09:56:00AM -0400, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
> On 10/10/2023 17:54, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 10, 2023 at 09:56:00AM -0400, Michael S. Tsirkin wrote:
> > >
> > > > > However - the Intel GPU
On 10/10/2023 17:54, Michael S. Tsirkin wrote:
On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason Gunthorpe wrote:
On Tue, Oct 10, 2023 at 09:56:00AM -0400, Michael S. Tsirkin wrote:
However - the Intel GPU VFIO driver is such a bad experiance I don't
want to encourage people to make VFIO
On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 10, 2023 at 09:56:00AM -0400, Michael S. Tsirkin wrote:
>
> > > However - the Intel GPU VFIO driver is such a bad experiance I don't
> > > want to encourage people to make VFIO drivers, or code that is only
> > > used
On Tue, Oct 10, 2023 at 10:10:31AM -0300, Jason Gunthorpe wrote:
> > > There is alot of code in VFIO and the VMM side to take a VF and turn
> > > it into a vPCI function. You can't just trivially duplicate VFIO in a
> > > dozen drivers without creating a giant mess.
> >
> > I do not advocate for
On Mon, Oct 09, 2023 at 12:24:27PM -0600, Gustavo A. R. Silva wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
>
Since commit 6f5312f80183 ("vdpa/mlx5: Add support for running with
virtio_vdpa"), mlx5_vdpa starts with preallocate 1:1 DMA MR at device
creation time. This 1:1 DMA MR will be implicitly destroyed while
the first .set_map call is invoked, in which case callers like
vhost-vdpa will start to set up
Userspace needs this feature flag to distinguish if vhost-vdpa
iotlb in the kernel supports persistent IOTLB mapping across
device reset. Without it, userspace has no way to tell apart
if it's running on an older kernel, which could silently drop
all iotlb mapping across vDPA reset.
There are 3
In order to reduce needlessly high setup and teardown cost
of iotlb mapping during live migration, it's crucial to
decouple the vhost-vdpa iotlb abstraction from the virtio
device life cycle, i.e. iotlb mappings should be left
intact across virtio device reset [1]. For it to work, the
on-chip
Device specific IOMMU parent driver who wishes to see mapping to be
decoupled from virtio or vdpa device life cycle (device reset) can use
it to restore memory mapping in the device IOMMU to the initial or
default state. The reset of mapping is done per address space basis.
The reason why a
Devices with on-chip IOMMU or vendor specific IOTLB implementation
may need to restore iotlb mapping to the initial or default state
using the .reset_map op, as it's desirable for some parent devices
to solely manipulate mappings by its own, independent of virtio device
state. For instance, device
On Tue, 10 Oct 2023 14:41:39 +0800, Jason Wang wrote:
> On Tue, Oct 10, 2023 at 11:11 AM Xuan Zhuo wrote:
> >
> > Some buggy devices, the common cfg size may not match the features.
> >
> > This patch checks the common cfg size for the
> > features(VIRTIO_F_NOTIF_CONFIG_DATA,
On Mon, Oct 09, 2023 at 11:24:18PM +0300, Arseniy Krasnov wrote:
On 09.10.2023 18:17, Stefano Garzarella wrote:
On Sat, Oct 07, 2023 at 08:21:37PM +0300, Arseniy Krasnov wrote:
This adds three tests for MSG_ZEROCOPY feature:
1) SOCK_STREAM tx with different buffers.
2) SOCK_SEQPACKET tx with
On Sat, Sep 30, 2023 at 4:46 AM Jakub Sitnicki wrote:
>
> Some virtual devices, such as the virtio network device, can use multiple
> virtqueues (or multiple pairs of virtqueues in the case of a vNIC). In such
> case, when there are multiple vCPUs present, it is possible to process
> virtqueue
On Tue, Oct 10, 2023 at 11:11 AM Xuan Zhuo wrote:
>
> This patch adds the definition of VIRTIO_F_NOTIF_CONFIG_DATA feature bit
> in the relevant header file.
>
> This feature indicates that the driver uses the data provided by the
> device as a virtqueue identifier in available buffer
On Tue, Oct 10, 2023 at 11:11 AM Xuan Zhuo wrote:
>
> The function vp_modern_map_capability() takes the size parameter,
> which corresponds to the size of virtio_pci_common_cfg. As a result,
> this indicates the size of memory area to map.
>
> Now the size is the size of virtio_pci_common_cfg,
On Tue, Oct 10, 2023 at 11:11 AM Xuan Zhuo wrote:
>
> Some buggy devices, the common cfg size may not match the features.
>
> This patch checks the common cfg size for the
> features(VIRTIO_F_NOTIF_CONFIG_DATA, VIRTIO_F_RING_RESET). When the
> common cfg size does not match the corresponding
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> For the following sequence:
> - cvq group is in ASID 0
> - .set_map(1, cvq_iotlb)
> - .set_group_asid(cvq_group, 1)
>
> ... the cvq mapping from ASID 0 will be used. This is not always correct
> behaviour.
>
> This patch adds support for
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> They will be used in a follow-up patch.
>
> For dup_iotlb, avoid the src == dst case. This is an error.
>
> Acked-by: Eugenio Pérez
> Signed-off-by: Dragos Tatulea
Acked-by: Jason Wang
Thanks
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> Vq descriptor mappings are supported in hardware by filling in an
> additional mkey which contains the descriptor mappings to the hw vq.
>
> A previous patch in this series added support for hw mkey (mr) creation
> for ASID 1.
>
> This
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> Introduce the vq descriptor group and mr per ASID. Until now
> .set_map on ASID 1 was only updating the cvq iotlb. From now on it also
> creates a mkey for it. The current patch doesn't use it but follow-up
> patches will add hardware
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> The current flow for updating an mr works directly on mvdev->mr which
> makes it cumbersome to handle multiple new mr structs.
>
> This patch makes the flow more straightforward by having
> mlx5_vdpa_create_mr return a new mr which will
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> The mutex is named like it is supposed to protect only the mkey but in
> reality it is a global lock for all mr resources.
>
> Shift the mutex to it's rightful location (struct mlx5_vdpa_dev) and
> give it a more appropriate name.
>
>
On Mon, Oct 9, 2023 at 7:25 PM Dragos Tatulea wrote:
>
> This patch adapts the mr creation/deletion code to be able to work with
> any given mr struct pointer. All the APIs are adapted to take an extra
> parameter for the mr.
>
> mlx5_vdpa_create/delete_mr doesn't need a ASID parameter anymore.
On Tue, Oct 10, 2023 at 1:51 PM Akihiko Odaki wrote:
>
> On 2023/10/10 14:45, Jason Wang wrote:
> > On Tue, Oct 10, 2023 at 9:52 AM Akihiko Odaki
> > wrote:
> >>
> >> On 2023/10/09 19:44, Willem de Bruijn wrote:
> >>> On Mon, Oct 9, 2023 at 3:12 AM Akihiko Odaki
> >>> wrote:
>
> On
34 matches
Mail list logo
