> Date: Tue, 8 Oct 2024 09:14:29 +0200 (CEST)
> From: Stefan Fritsch <sf@openbsd.org>
> 
> Hi,
> 
> we always use the standard pci busdma machinery. Therefore we should
> negotiate the VIRTIO_F_ACCESS_PLATFORM feature if it is offered.
> Strictly speaking we should bypass any existing iommus if the host 
> does not offer this feature, but this no regression and we can do that 
> when/if we introduce our own busdma tag for virtio.
> 
> Accepting VIRTIO_F_ACCESS_PLATFORM is required for SEV on KVM/qemu.
> 
> ok?

Sorry, but your explanation makes no sense.  What does "the standard
pci busdma machinery" mean?  I think it means different things on
different architectures.

The description of the VIRTIO_F_ACCESS_PLATFORM flag is very vague.  I
think the only possible interpretation is that not setting the flag
means "we're Linux and you can make assumptions and optimize things".
So indeed setting that flag uncodinitionally may make sense.  But we
need a better comment.

> Cheers,
> Stefan
> 
> diff --git a/sys/dev/pci/virtio_pci.c b/sys/dev/pci/virtio_pci.c
> index f9c8801ceb7..3e6f3d69295 100644
> --- a/sys/dev/pci/virtio_pci.c
> +++ b/sys/dev/pci/virtio_pci.c
> @@ -821,6 +821,8 @@ virtio_pci_negotiate_features_10(struct virtio_softc *vsc,
>  	uint64_t host, negotiated;
>  
>  	vsc->sc_driver_features |= VIRTIO_F_VERSION_1;
> +	/* we always use the standard pci busdma_tag */
> +	vsc->sc_driver_features |= VIRTIO_F_ACCESS_PLATFORM;
>  	/* notify on empty is 0.9 only */
>  	vsc->sc_driver_features &= ~VIRTIO_F_NOTIFY_ON_EMPTY;
>  	CWRITE(sc, device_feature_select, 0);
> 
>