On Thu, Jun 09, 2022 at 01:39:48PM +0100, Will Deacon wrote: > On Tue, Jun 07, 2022 at 06:02:15PM +0100, Jean-Philippe Brucker wrote: > > Add support for version 1 of the virtio transport to kvmtool. Based on a > > RFC by Sasha Levin [1], I've been trying to complete it here and there. > > It's long overdue and is quite painful to rebase, so let's get it > > merged. > > > > Several reasons why the legacy transport needs to be replaced: > > > > * Only 32 feature bits are supported. Most importantly > > VIRTIO_F_ACCESS_PLATFORM, which forces a Linux guest to use the DMA > > API, cannot be enabled. So we can't support private guests that > > decrypt or share only their DMA memory with the host. > > Woohoo! > > > * Legacy virtqueue address is a 32-bit pfn, aligned on 4kB. Since Linux > > guests bypass the DMA API they can't support large GPAs. > > > > * New devices types (iommu, crypto, memory, etc) and new features cannot > > be supported. > > > > * New guests won't implement the legacy transport. Existing guests will > > eventually drop legacy support. > > > > Support for modern transport becomes the default and legacy is enabled > > with --virtio-legacy. > > > > I only tested what I could: vsock, scsi and vhost-net are currently > > broken and can be fixed later (they have issues with mem regions and > > feature mask, among other things). I also haven't tested big-endian. > > If these are broken, then shall we default to legacy mode and have the > modern transport be opt-in? Otherwise we're regressing people in a > confusing way. What I meant was that even without these patches, I wasn't able to use any of the vhost devices, they already had several bugs. But now that I spent a little more time trying to fix them, it looks like the modern transport does add one regression (vhost ioeventfd is set on I/O port but modern transport uses MMIO). I'll sort this out and resend. Thanks for picking up the base patches! Thanks, Jean
