>> I would have thought we would have to disallow on the hypervisor/device
>> side. (no expert on user space drivers, especially how they
>> detect/enable/access virtio devices)
>
> QEMU does exactly this:
>
> static int virtio_validate_features(VirtIODevice *vdev)
> {
> VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
>
> if (virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM) &&
> !virtio_vdev_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) {
> return -EFAULT;
> }
> ...
> }
Okay, that makes sense. Thanks!
>
>
>>>
>>> Maybe we need a separate feature bit for this kind of thing where you
>>> assume the driver is trusted? Such a bit - unlike
>>> VIRTIO_F_IOMMU_PLATFORM - would allow legacy guests ...
>>
>> Let's take virtio-mem as an example. You cannot zap memory outside of
>> the scope of a virtio-mem device. So I assume having a user space driver
>> would be ok (although most probably of limited use :) )?
>>
>> Still, for virtio-mem, special s390x handling, similar to virtio-balloon
>> - (un)sharing of pages - would have to be performed.
>>
>> So some feature bits to cleanly separate the different limitations would
>> be great. At least in regard to s390x, I guess we don't have to worry
>> too much about legacy guests.
>
> So if you have the cycles to think through and document how balloon
> interacts with different access limitations, that would be great!
I'll add it to my ever-growing todo list. Would be great if Halil could
help out thinking how to express the semantics so we can handle PV
properly (both, virtio-balloon, but also virtio-mem).
Cheers!
--
Thanks,
David / dhildenb
