[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 07/18] s390x: protvirt: Inhibit balloon when switching to
From: |
David Hildenbrand |
Subject: |
Re: [PATCH v5 07/18] s390x: protvirt: Inhibit balloon when switching to protected mode |
Date: |
Fri, 20 Mar 2020 10:36:53 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 19.03.20 18:45, Michael S. Tsirkin wrote:
> On Thu, Mar 19, 2020 at 02:54:11PM +0100, David Hildenbrand wrote:
>> Why does the balloon driver not support VIRTIO_F_IOMMU_PLATFORM? It is
>> absolutely not clear to me. The introducing commit mentioned that it
>> "bypasses DMA". I fail to see that.
>
> Well sure one can put the balloon behind an IOMMU. If will shuffle PFN
> lists through a shared page. Problem is, you can't run an untrusted
> driver with it since if you do it can corrupt guest memory.
> And VIRTIO_F_IOMMU_PLATFORM so far meant that you can run
> a userspace driver.
Just to clarify: Is it sufficient to clear VIRTIO_F_IOMMU_PLATFORM in
the *guest kernel driver* to prohibit *guest userspace drivers*?
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)
>
> 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.
--
Thanks,
David / dhildenb