On Wed, Oct 11, 2023 at 02:43:37AM -0400, Michael S. Tsirkin wrote:
> > Btw, what is that intel thing everyone is talking about? And why
> > would the virtio core support vendor specific behavior like that?
>
> It's not a thing it's Zhu Lingshan :) intel is just one of the vendors
> that implemen
On Tue, Oct 10, 2023 at 11:13:30PM -0700, Christoph Hellwig 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:
> >
> > > I suggest 3 but call it on the VF. commands will switch to PF
> > > internally as
On Tue, Oct 10, 2023 at 10:10:31AM -0300, Jason Gunthorpe wrote:
> We've talked around ideas like allowing the VF config space to do some
> of the work. For simple devices we could get away with 1 VF config
> space register. (VF config space is owned by the hypervisor, not the
> guest)
Which assum
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 commands
On Tue, Oct 10, 2023 at 06:43:32PM +0300, Yishai Hadas 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 commands through a memory BAR of VF itself.
> >
> The driver who owns the VF is VFI
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 2023/1
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 me
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 Tue,
> 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 11:0
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 commands
> 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 Gunthorp
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 wro
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:
How
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 VFIO
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 drivers
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 b
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 d
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
> array
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 ca
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
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 separa
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, VIRTIO_F_RING_RESET)
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
27 matches
Mail list logo
