| Message ID | 20211116063155.901183-1-penny.zheng@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | direct-map memory map | expand |
On 16.11.2021 07:31, Penny Zheng wrote: > v3 changes: > - move flag XEN_DOMCTL_CDF_INTERNAL_directmap back to xen/include/xen/domain.h, > to let it be only available for domain created by XEN. > - name it with extra "INTERNAL" and add comments to warn developers not > to accidently use its bitfield when introducing new XEN_DOMCTL_CDF_xxx flag. FTR I continue to object to the hijacking of a public interface bit for this purpose. Not to the degree of nak-ing the change, but still. Jan
Hi Jan, On 16/11/2021 07:49, Jan Beulich wrote: > On 16.11.2021 07:31, Penny Zheng wrote: >> v3 changes: >> - move flag XEN_DOMCTL_CDF_INTERNAL_directmap back to xen/include/xen/domain.h, >> to let it be only available for domain created by XEN. >> - name it with extra "INTERNAL" and add comments to warn developers not >> to accidently use its bitfield when introducing new XEN_DOMCTL_CDF_xxx flag. > > FTR I continue to object to the hijacking of a public interface bit for > this purpose. Not to the degree of nak-ing the change, but still. I remember this discussion in v1 and I am a bit confused why this was re-introduced. Looking at the thread, I think you and I were happy with the following approach: 1) Switch the last parameter of domain_create() (i.e. bool is_priv) to flags. 2) Define a bit in the parameter to indicate whether the domain will be direct-mapped. Cheers,
On 16.11.2021 10:44, Julien Grall wrote: > On 16/11/2021 07:49, Jan Beulich wrote: >> On 16.11.2021 07:31, Penny Zheng wrote: >>> v3 changes: >>> - move flag XEN_DOMCTL_CDF_INTERNAL_directmap back to xen/include/xen/domain.h, >>> to let it be only available for domain created by XEN. >>> - name it with extra "INTERNAL" and add comments to warn developers not >>> to accidently use its bitfield when introducing new XEN_DOMCTL_CDF_xxx flag. >> >> FTR I continue to object to the hijacking of a public interface bit for >> this purpose. Not to the degree of nak-ing the change, but still. > > I remember this discussion in v1 and I am a bit confused why this was > re-introduced. Looking at the thread, I think you and I were happy with > the following approach: > > 1) Switch the last parameter of domain_create() (i.e. bool is_priv) > to flags. > 2) Define a bit in the parameter to indicate whether the domain will > be direct-mapped. Indeed, that's how I too would prefer this to be dealt with. Jan
On Tue, 16 Nov 2021, Penny Zheng wrote: > Cases where domU needs direct-map memory map: > * IOMMU not present in the system. > * IOMMU disabled if it doesn't cover a specific device and all the guests > are trusted. Thinking a mixed scenario, where a few devices with IOMMU and > a few without, then guest DMA security still could not be totally guaranteed. > So users may want to disable the IOMMU, to at least gain some performance > improvement from IOMMU disabled. > * IOMMU disabled as a workaround when it doesn't have enough bandwidth. > To be specific, in a few extreme situation, when multiple devices do DMA > concurrently, these requests may exceed IOMMU's transmission capacity. > * IOMMU disabled when it adds too much latency on DMA. For example, > TLB may be missing in some IOMMU hardware, which may bring latency in DMA > progress, so users may want to disable it in some realtime scenario. > * Guest OS relies on the host memory layout > > "direct-map" property shall be added under the appropriate domain node, > when users requesting direct-map memory mapping for the domain. > > Right now, direct-map is only supported when domain on Static Allocation, > that is, "xen,static-mem" is also necessary in the domain configuration. > > Looking into related [design link]( > https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg00882.html) > for more details. > > The whole design is about Static Allocation and direct-map, and this > Patch Serie only covers parts of it, which are direct-map memory map. > Other features will be delievered through different patch series. > > See https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg00855.html > for Domain on Static Allocation. > > This patch serie is based on > https://lists.xenproject.org/archives/html/xen-devel/2021-10/msg00822.html I haven't had a chance to review the series but I wanted to say that I tested it successfully both with and without direct-map, so: Tested-by: Stefano Stabellini <sstabellini@kernel.org>