On Wed, Aug 27, 2014 at 8:45 AM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Wed, Aug 27, 2014 at 08:11:15AM -0700, Andy Lutomirski wrote:
>> On Aug 26, 2014 11:46 PM, "Stefan Hajnoczi" <stefa...@gmail.com> wrote:
>> >
>> > On Tue, Aug 26, 2014 at 10:16 PM, Andy Lutomirski <l...@amacapital.net> 
>> > wrote:
>> > > There are two outstanding issues.  virtio_net warns if DMA debugging
>> > > is on because it does DMA from the stack.  (The warning is correct.)
>> > > This also is likely to do something unpleasant to s390.
>> > > (Maintainers are cc'd -- I don't know what to do about it.)
>> >
>> > This changes the semantics of vring and breaks existing guests when
>> > bus address != physical address.
>> >
>> > Can you use a transport feature bit to indicate that bus addresses are
>> > used?  That way both approaches can be supported.
>>
>> I can try to support both styles of addressing, but I don't think that
>> this can be negotiated between the device (i.e. host or physical
>> virtio-speaking device) and the guest.  In the Xen case that I care
>> about (Linux on Xen on KVM), the host doesn't know about the
>> translation at all -- Xen is an intermediate layer that only the guest
>> is aware of.  In this case, there are effectively two layers of
>> virtualization, and only the inner one (Xen) knows about the
>> translation despite the fact that the the outer layer is the one
>> providing the virtio device.
>>
>> I could change virtio_ring to use the DMA API only if requested by the
>> lower driver (virtio_pci, etc) and to have only virtio_pci enable that
>> feature.  Will that work for all cases?
>>
>> On s390, this shouldn't work just like the current code.  On x86, I
>> think that if QEMU ever starts exposing an IOMMU attached to a
>> virtio-pci device, then QEMU should expect that IOMMU to be used.  If
>> QEMU expects to see physical addresses, then it shouldn't advertise an
>> IOMMU.  Since QEMU doesn't currently support guest IOMMUs, this should
>> be fine for everything that uses QEMU.
>>
>> At least x86's implementation of the DMA ops for devices that aren't
>> behind an IOMMU should be very fast.
>>
>> Are there any other weird cases for which this might be a problem?
>>
>> >
>> > Please also update the virtio specification:
>> > https://tools.oasis-open.org/version-control/browse/wsvn/virtio/
>> >
>>
>> I'm not sure it will need an update.  Perhaps a note in the PCI
>> section indicating that, if the host expects the guest to program an
>> IOMMU, then it should use the appropriate platform-specific mechanism
>> to expose that IOMMU.
>>
>> --Andy
>
> If there's no virtio mechanism to negotate enabling/disabling
> translations, then specification does not need an extension.

It wouldn't shock me if someone wants to negotiate this for
virtio_mmio some day, but that might be more of a device tree thing.
I have no idea how that works, but I think it can wait until someone
wants it.

I updated the patches, and I'll send them out after I try to test-boot
s390 under QEMU :)

--Andy
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Reply via email to