On Fri, Feb 21, 2020 at 05:41:51PM +0100, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 04:33:35PM -0500, Michael S. Tsirkin wrote: > > So it sounds like a host issue: the emulation of s390 unnecessarily complicated. > > Working around it by the guest looks wrong ... > > Yes. If your host (and I don't care if you split hypervisor, > ultravisor and megavisor out in your implementation) wants to > support a VM architecture where the host can't access all guest > memory you need to ensure the DMA API is used. Extra points for > simply always setting the flag and thus future proofing the scheme. Moving towards F_ACCESS_PLATFORM everywhere is a good idea (for other reasons), but that doesn't make the problem as it exists right now go away. But, "you need to ensure the DMA API is used" makes no sense from the host point of view. The existence of the DMA API is an entirely guest side, and Linux specific detail, the host can't make decisions based on that. For POWER - possibly s390 as well - the hypervisor has no way of knowing at machine construction time whether it will be an old kernel (or non Linux OS) which can't support F_ACCESS_PLATFORM, or a guest which will enter secure mode and therefore requires F_ACCESS_PLATFORM (according to you). That's the fundamental problem here. The normal virtio model of features that the guest can optionally accept would work nicely here - except that that wouldn't work for the case of hardware virtio devices, where the access limitations come from "host" (platform) side and therefore can't be disabled by that host. We really do have two cases here: 1) access restrictions originating with the host/platform (e.g. hardware virtio) and 2) access restrictions originating with the guest (e.g. secure VMs). What we need to do to deal with them is basically the same at the driver level, but it has subtle and important differences at the platform level. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
