RE: [Qemu-devel] [virtio-comment] [PATCH] *** Vhost-pci RFC v2 ***

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/07/2016 01:17 PM, Stefan Hajnoczi wrote:
> On Mon, Sep 05, 2016 at 08:56:14AM +0000, Marc-André Lureau wrote:
> > Hi
> >
> > On Sat, Sep 3, 2016 at 5:36 PM Wang, Wei W <wei.w.wang@xxxxxxxxx> wrote:
> >
> > > Marc-André and I just got different thoughts about a design
> > > direction. I prefer to have all the frontend virtio devices (net,
> > > scsi, console etc.) from the same VM to be supported by one backend
> > > vhost-pci device (N-1), while Marc-André prefers to have each
> > > frontend virtio device be supported by a backend vhost-pci device (N-N).
> > >
> >
> > I suggested 1-1 (not n-n, but you can have several 1-1 pairs), unless
> > you have a good reason to do differently, starting from the use case
> > (is there a case that requires several backends/consumers in the same
> > VM? if yes, 1-1 design could still fit). If it's to save guest memory
> > space, it may not be a good enough reason, but I don't see clearly the
> implications.
> 
> N-1 saves address space but is probably a poor fit for modern PCI devices that
> are geared towards IOMMUs.
> 
> Each virtio device should be isolated in terms of memory space and
> hotplug/reset life cycle.  This ensures they are robust against driver bugs and can
> be safely delegated/passed through to different applications or nested VMs that
> don't trust each other.
> 
> Isolation between virtio device instances sharing a single vhost-pci device (N-1)
> will harder to achieve.  I would aim for the simpler 1-1 design instead where
> each device is isolated.
> 
> Are there specific reasons for wanting an N-1 design?

I made an N-1 design mainly for the sake of resource reusability (sharing the one pair of controlqs, the common initialization code and so on). But it looks like the consolidation is not that important here - I will take your suggestions to start from the simpler one. Thanks Stefan and Marc-André.

Best,
Wei
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux