Michael S. Tsirkin
2020-Aug-11 09:52 UTC
vdpa: handling of VIRTIO_F_ACCESS_PLATFORM/VIRTIO_F_ORDER_PLATFORM
Hi! I'd like to raise the question of whether we can drop the requirement of VIRTIO_F_ACCESS_PLATFORM from vdpa? As far as I can see, it is merely required for virtio vdpa - so should we not enforce it there? The point is support for legacy guests - which mostly just works on x86. Also, what is the plan for VIRTIO_F_ORDER_PLATFORM? -- MST
Jason Wang
2020-Aug-12 02:07 UTC
vdpa: handling of VIRTIO_F_ACCESS_PLATFORM/VIRTIO_F_ORDER_PLATFORM
On 2020/8/11 ??5:52, Michael S. Tsirkin wrote:> Hi! > I'd like to raise the question of whether we can drop the requirement > of VIRTIO_F_ACCESS_PLATFORM from vdpa? > As far as I can see, it is merely required for virtio vdpa - > so should we not enforce it there?If we don't enforce it, virtio will use PA which breaks the setup when IOMMU is enabled. As discussed in the past, mandating DMA API for virito can just solve this issue.> > The point is support for legacy guests - which mostly just works > on x86.Legacy guest should work even if we mandate ACCESS_PLATFORM. This is because we don't simply pass through guest features (qemu will always set ACCESS_PLATFORM to vhost-vdpa).> > Also, what is the plan for VIRTIO_F_ORDER_PLATFORM?I think we should mandate ORDER_PLATFORM, (even for guest). Thanks>
Maybe Matching Threads
- [PATCH] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM
- [PATCH] vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
- [PATCH] vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
- [PATCH] vhost: vdpa: remove per device feature whitelist
- [PATCH v2 1/2] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM