On Tue, Jul 19, 2022 at 04:11:50PM +0000, Keir Fraser wrote: > On Tue, Jul 19, 2022 at 08:51:54AM -0700, Christoph Hellwig wrote: > > On Tue, Jul 19, 2022 at 03:46:08PM +0000, Keir Fraser wrote: > > > However, if the general idea at least is acceptable, would the > > > implementation be acceptable if I add an explicit API for this to the > > > DMA subsystem, and hide the detail there? > > > > I don't think so. The right thing to key off is > > VIRTIO_F_ACCESS_PLATFORM, which really should be set in any modern > > virtio device after all the problems we had with the lack of it. > > Ok. Certainly the flag description in virtio spec fits the bill. Maybe. But balloon really isn't a normal device. Yes the rings kind of operate more or less normally. However consider for example free page hinting. We stick a page address in ring for purposes of telling host it can blow it away at any later time unless we write something into the page. Free page reporting is similar. Sending gigabytes of memory through swiotlb is at minimum not a good idea. Conversely, is it even okay security wise that host can blow away any guest page? Because with balloon GFNs do not go through bounce buffering. > > > Or a completely different approach would be to revert the patch > > > e41b1355508d which clears VIRTIO_F_ACCESS_PLATFORM in the balloon > > > driver. MST: That's back in your court, as it's your patch! > > > > Which also means this needs to be addresses, but I don't think a > > simple revert is enough. > > Well here are two possible approaches: > > 1. Revert e41b1355508d outright. I'm not even sure what it would mean > for reported pages to go through IOMMU. And VIRTIO_F_ACCESS_PLATFORM > is no longer IOMMU-specific anyway. > > 2. Continue to clear the flag during virtio_balloon negotiation, but > remember that it was offered, and test for that in vring_use_dma_api() > as well as, or instead of, virtio_has_dma_quirk(). > > Do either of those appeal? I think the use case needs to be documented better. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
