On Fri, Oct 27, 2023 at 4:07 AM Steve Sistare wrote:
>
> mlx5_vdpa does not preserve userland's view of vring base for the control
> queue in the following sequence:
>
> ioctl VHOST_SET_VRING_BASE
> ioctl VHOST_VDPA_SET_STATUS VIRTIO_CONFIG_S_DRIVER_OK
> mlx5_vdpa_set_status()
> setup_cvq_vr
Steve, I think this is a loose end that I myself am not sure if worth
fixing, copy Eugenio for his awareness. Reason is that when CVQ is in
place it always has to cope with device state saving and restoration
using shadowed virtqueue for a lot of cases not just migration, and
that's the reas
On 10/26/2023 4:11 PM, Steve Sistare wrote:
> mlx5_vdpa does not preserve userland's view of vring base for the control
> queue in the following sequence:
>
> ioctl VHOST_SET_VRING_BASE
> ioctl VHOST_VDPA_SET_STATUS VIRTIO_CONFIG_S_DRIVER_OK
> mlx5_vdpa_set_status()
> setup_cvq_vring()
>
mlx5_vdpa does not preserve userland's view of vring base for the control
queue in the following sequence:
ioctl VHOST_SET_VRING_BASE
ioctl VHOST_VDPA_SET_STATUS VIRTIO_CONFIG_S_DRIVER_OK
mlx5_vdpa_set_status()
setup_cvq_vring()
vringh_init_iotlb()
vringh_init_kern()
mlx5_vdpa does not preserve userland's view of vring base for the control
queue in the following sequence:
ioctl VHOST_SET_VRING_BASE
ioctl VHOST_VDPA_SET_STATUS VIRTIO_CONFIG_S_DRIVER_OK
mlx5_vdpa_set_status()
setup_cvq_vring()
vringh_init_iotlb()
vringh_init_kern()
On Thu, Oct 26, 2023 at 11:55:39AM -0600, Alex Williamson wrote:
> On Thu, 26 Oct 2023 15:08:12 +0300
> Yishai Hadas wrote:
>
> > On 25/10/2023 22:13, Alex Williamson wrote:
> > > On Wed, 25 Oct 2023 17:35:51 +0300
> > > Yishai Hadas wrote:
> > >
> > >> On 24/10/2023 22:57, Alex Williamson wro
On Thu, 26 Oct 2023 15:08:12 +0300
Yishai Hadas wrote:
> On 25/10/2023 22:13, Alex Williamson wrote:
> > On Wed, 25 Oct 2023 17:35:51 +0300
> > Yishai Hadas wrote:
> >
> >> On 24/10/2023 22:57, Alex Williamson wrote:
> >>> On Tue, 17 Oct 2023 16:42:17 +0300
> >>> Yishai Hadas wrote:
> >
On Thu, Oct 26, 2023 at 06:25:08PM +0200, Jakub Sitnicki wrote:
> On Wed, Oct 25, 2023 at 04:53 PM +02, Jakub Sitnicki wrote:
> > Since commit 65c7cdedeb30 ("genirq: Provide new interfaces for affinity
> > hints") irq_set_affinity_hint is being phased out.
> >
> > Switch to new interfaces for setti
On Wed, Oct 25, 2023 at 04:53 PM +02, Jakub Sitnicki wrote:
> Since commit 65c7cdedeb30 ("genirq: Provide new interfaces for affinity
> hints") irq_set_affinity_hint is being phased out.
>
> Switch to new interfaces for setting and applying irq affinity hints.
>
> Signed-off-by: Jakub Sitnicki
> -
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 9:16 PM
> On Thu, Oct 26, 2023 at 03:09:13PM +, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin
> > > Sent: Thursday, October 26, 2023 8:36 PM
> > >
> > > On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
> >
On Thu, Oct 26, 2023 at 03:09:13PM +, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin
> > Sent: Thursday, October 26, 2023 8:36 PM
> >
> > On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
> > >
> > > > From: Michael S. Tsirkin
> > > > Sent: Thursday, October 26, 2023 6:45 PM
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 8:36 PM
>
> On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin
> > > Sent: Thursday, October 26, 2023 6:45 PM
> >
> > > > Followed by an open coded driver check for 0x1000 to 0x103f rang
On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin
> > Sent: Thursday, October 26, 2023 6:45 PM
>
> > > Followed by an open coded driver check for 0x1000 to 0x103f range.
> > > Do you mean windows driver expects specific subsystem vendor id of 0x1af4?
>
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 6:45 PM
> > Followed by an open coded driver check for 0x1000 to 0x103f range.
> > Do you mean windows driver expects specific subsystem vendor id of 0x1af4?
>
> Look it up, it's open source.
Those are not OS inbox drivers anyway.
On Thu, Oct 26, 2023 at 12:40:04PM +, Parav Pandit wrote:
> > From: Michael S. Tsirkin
> > Sent: Thursday, October 26, 2023 5:42 PM
> >
> > On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote:
> > > > > Makes sense ?
> > > > So do I understand correctly that virtio dictates the subsy
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 5:42 PM
>
> On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote:
> > > > Makes sense ?
> > > So do I understand correctly that virtio dictates the subsystem
> > > device ID for all subsystem vendor IDs that implement a legacy
On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote:
> > > Makes sense ?
> > So do I understand correctly that virtio dictates the subsystem device
> > ID for all subsystem vendor IDs that implement a legacy virtio
> > interface? Ok, but this device didn't actually implement a legacy
> >
On 25/10/2023 22:13, Alex Williamson wrote:
On Wed, 25 Oct 2023 17:35:51 +0300
Yishai Hadas wrote:
On 24/10/2023 22:57, Alex Williamson wrote:
On Tue, 17 Oct 2023 16:42:17 +0300
Yishai Hadas wrote:
Introduce a vfio driver over virtio devices to support the legacy
interface functionality
oad.01.org/0day-ci/archive/20231026/202310261653.lkirqagq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231026/202310261653.lkirqagq-...@intel.com/reproduce)
If you fix the issue in a separate patch/c
On Thu, Oct 26, 2023 at 12:14:33AM -0700, Si-Wei Liu wrote:
> 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
> in
On 10/25/2023 11:55 PM, Si-Wei Liu wrote:
On 10/25/2023 10:26 PM, Michael S. Tsirkin wrote:
On Wed, Oct 25, 2023 at 04:13:14PM -0700, Si-Wei Liu wrote:
When the vhost-vdpa device is being closed, vhost_vdpa_cleanup()
doesn't
clean up the vqs pointer after free. This could lead to use-after
In order to reduce excessive memory mapping cost in live migration and
VM reboot, it is desirable to decouple the vhost-vdpa IOTLB abstraction
from the virtio device life cycle, i.e. mappings can be kept intact
across virtio device reset. Leverage the .reset_map callback, which is
meant to destroy
Using .compat_reset op from the previous patch, the buggy .reset
behaviour can be kept as-is on older userspace apps, which don't ack the
IOTLB_PERSIST backend feature. As this compatibility quirk is limited to
those drivers that used to be buggy in the past, it won't affect change
the behaviour or
Userspace needs this feature flag to distinguish if vhost-vdpa iotlb in
the kernel can be trusted to persist IOTLB mapping across vDPA 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, especially
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
Some device specific IOMMU parent drivers have long standing bogus
behaviour that mistakenly clean up the maps during .reset. By
definition, this is violation to the on-chip IOMMU ops (i.e. .set_map,
or .dma_map & .dma_unmap) in those offending drivers, as the removal of
internal maps is completely
Some device specific IOMMU parent drivers have long standing bogus
behavior that mistakenly clean up the maps during .reset. By definition,
this is violation to the on-chip IOMMU ops (i.e. .set_map, or .dma_map &
.dma_unmap) in those offending drivers, as the removal of internal maps
is completely
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 not work
with DMA ops and maintain a simple IOMMU model with .reset_map. In
particular, device r
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 IOMMU
29 matches
Mail list logo
