[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: Constraining where a guest may allocate virtio accessible resources
On Thu, Jun 18, 2020 at 04:58:40PM +0200, Jan Kiszka wrote: > >>>>> Option 5 - Additional Device > >>>>> ============================ > >>>>> > >>>>> The final approach would be to tie the allocation of virtqueues to > >>>>> memory regions as defined by additional devices. For example the > >>>>> proposed IVSHMEMv2 spec offers the ability for the hypervisor to present > >>>>> a fixed non-mappable region of the address space. Other proposals like > >>>>> virtio-mem allow for hot plugging of "physical" memory into the guest > >>>>> (conveniently treatable as separate shareable memory objects for QEMU > >>>>> ;-). > >>>>> > >>>> > >>>> I think you forgot one approach: virtual IOMMU. That is the advanced > >>>> form of the grant table approach. The backend still "sees" the full > >>>> address space of the frontend, but it will not be able to access all of > >>>> it and there might even be a translation going on. Well, like IOMMUs work. > >>>> > >>>> However, this implies dynamics that are under guest control, namely of > >>>> the frontend guest. And such dynamics can be counterproductive for > >>>> certain scenarios. That's where this static windows of shared memory > >>>> came up. > >>> > >>> Yes, I think IOMMU interfaces are worth investigating more too. IOMMUs > >>> are now widely implemented in Linux and virtualization software. That > >>> means guest modifications aren't necessary and unmodified guest > >>> applications will run. > >>> > >>> Applications that need the best performance can use a static mapping > >>> while applications that want the strongest isolation can map/unmap DMA > >>> buffers dynamically. > >> > >> I do not see yet that you can model with an IOMMU a static, not guest > >> controlled window. > > > > Well basically the IOMMU will have as part of the > > topology description and range of addresses devices behind it > > are allowed to access. What's the problem with that? > > > > I didn't look at the detail of the vIOMMU from that perspective, but our > requirement would be that it would just statically communicate to the > guest where DMA windows are, rather than allowing the guest to configure > that (which is the normal usage of an IOMMU). Right, I got that - IOMMUs aren't necessarily fully configurable though. E.g. some IOMMUs are restricted in the # of bits they can address. > In addition, it would only address the memory transfer topic. We would > still be left with the current issue of virtio that the hypervisor's > device model needs to understand all supported device types. > > Jan I'd expect the DMA API would try to paper over that likely using bounce buffering. If you want to avoid copies, that's a harder problem generally. -- MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]