OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi

On Fri, Sep 2, 2016 at 5:30 AM Wei Wang <wei.w.wang@intel.com> wrote:
On 09/01/2016 09:05 PM, Marc-André Lureau wrote:
> On Thu, Sep 1, 2016 at 4:13 PM Wei Wang <wei.w.wang@intel.com
> <mailto:wei.w.wang@intel.com>> wrote:
> My question is not about the support of various kind of devices (that
> is clearly a worthy goal to me) but to have support simultaneously of
> several frontend/provider devices on the same vhost-pci device: is
> this required or necessary? I think it would simplify things if it was
> 1-1 instead, I would like to understand why you propose a different
> design.

It is not required, but necessary, I think. As mentioned above, those
consumer-side functionalities basically access the same provider VM's
memory, so I think one vhost-pci device is enough to hold that memory.
When it comes to the consumer guest kernel, we only need to ioremap that
memory once. Also, a pair of controlq-s is enough to handle the control
path messages between all those functionalities and the QEMU. I think
the design also looks compact in this way. what do you think?


If it's not required, I would propose to stick to a 1-1 design for now. (1-n support could be added later, even if it means a new device kind) Michael, what do you think?

--
Marc-André Lureau


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]