On Thu, 26 Oct 2023, David Woodhouse wrote: > On Thu, 2023-10-26 at 11:07 -0700, Stefano Stabellini wrote: > > On Thu, 26 Oct 2023, David Woodhouse wrote: > > > On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote: > > > > Hi, > > > > This patch series add support for grant mappings as a pseudo RAM region > > > > for Xen. > > > > > > > > Enabling grant mappings patches(first 6) are written by Juergen in 2021. > > > > > > > > QEMU Virtio device provides an emulated backends for Virtio frontned > > > > devices > > > > in Xen. > > > > Please set "iommu_platform=on" option when invoking QEMU. As this will > > > > set > > > > VIRTIO_F_ACCESS_PLATFORM feature which will be used by virtio frontend > > > > in Xen > > > > to know whether backend supports grants or not. > > > > > > I don't really understand what's going on here. The subject of the > > > cover letter certainly doesn't help me, because we *already* support > > > grant mappings under Xen, don't we? > > > > > > I found > > > https://static.linaro.org/connect/lvc21/presentations/lvc21-314.pdf but > > > I think it's a bit out of date; the decision about how to handle grant > > > mappings for virtio devices is still 'TBD'. > > > > See this presentation: > > https://www.youtube.com/watch?v=boRQ8UHc760 > > > > The patch series is for the guest (e.g. Linux) to use grants to share > > memory with virtio devices. The plumbing was already done in Linux a > > couple of years ago, but QEMU support for it is still missing. > > Thanks. > > > > Can you talk me through the process of what happens when a guest wants > > > to a virtio device to initiate 'DMA' to one of its pages? I assume it > > > starts by creating a grant mapping, and then taking the gntref and... > > > then what? > > > > First the guest gets a grant reference for the page, then it uses it as > > "dma address" to pass to the virtio device. The top bit (1ULL << 63) is > > used to signal that the address in question is a grant address. > > OK, so the guest sets the top bit in the DMA address and that indicates > that this is no longer actually a guest physical address, but instead, > bits 62-12 are a (starting) grant ref. (And the address *within* the > page is still bits 0-11, assuming 4KiB pages). > > An alternative way of implementing this on the QEMU side would just be > to teach the virtio mapping to recognise the "special" format with the > top bit set, and call qemu_xen_gnttab_map_refs() directly to get the > mapping? > > This seems like a lot of code to replace that simpler option... is > there a massive performance win from doing it this way? Would we want > to use this trick for the Xen PV backends (qdisk, qnic) *too*? Might it > make sense to introduce the simple version and *then* the optimisation, > with some clear benchmarking to show the win?
This is not done for performance but for safety (as in safety certifications, ISO 26262, etc.). This is to enable unprivileged virtio backends running in a DomU. By unprivileged I mean a virtio backend that is unable to map arbitrary memory (the xenforeignmemory interface is prohibited). The goal is to run Xen on safety-critical systems such as cars, industrial robots and more. In this configuration there is no traditional Dom0 in the system at all. If you would like to know more: https://www.youtube.com/watch?v=tisljY6Bqv0&list=PLYyw7IQjL-zHtpYtMpFR3KYdRn0rcp5Xn&index=8 > If we're just going to switch to grant mappings, why *aren't* we using > Xen PV device models on Arm anyway? I think you mean Xen PV drivers. Yes we have been using them for a while. Now we would also like to add the option of running virtio devices but we can only do that if the virtio backend is unprivileged as we have no Dom0 in the system.
