qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [virtio-dev] Vhost-pci RFC2.0


From: Wei Wang
Subject: Re: [Qemu-devel] [virtio-dev] Vhost-pci RFC2.0
Date: Wed, 19 Apr 2017 18:42:42 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 04/19/2017 05:57 PM, Stefan Hajnoczi wrote:
On Wed, Apr 19, 2017 at 06:38:11AM +0000, Wang, Wei W wrote:
We made some design changes to the original vhost-pci design, and want to open
a discussion about the latest design (labelled 2.0) and its extension (2.1).
2.0 design: One VM shares the entire memory of another VM
2.1 design: One VM uses an intermediate memory shared with another VM for
                      packet transmission.
Hi,
Can you talk a bit about the motivation for the 2.x design and major
changes compared to 1.x?

1.x refers to the design we presented at KVM Form before. The major
change includes:
1) inter-VM notification support
2) TX engine and RX engine, which is the structure built in the driver. From
the device point of view, the local rings of the engines need to be registered.

The motivation is to build a common design for 2.0 and 2.1.


What is the relationship between 2.0 and 2.1?  Do you plan to upstream
both?
2.0 and 2.1 use different ways to share memory.

2.0: VM1 shares the entire memory of VM2, which achieves 0 copy
between VMs while being less secure.
2.1: VM1 and VM2 use an intermediate shared memory to transmit
packets, which results in 1 copy between VMs while being more secure.

Yes, plan to upstream both. Since the difference is the way to share memory,
I think it wouldn't have too many patches to upstream 2.1 if 2.0 is ready (or
changing the order if needed).

For the convenience of discussion, I have some pictures presented at this link:
https://github.com/wei-w-wang/vhost-pci-discussion/blob/master/vhost-pci-rfc2.0.pdf

Fig. 1 shows the common driver frame that we want use to build the 2.0 and 2.1
What does "frame" mean in this context?  "Framework" or "design".
"design" is more accurate here. We want to have a fundamental common design,
(please have a check Fig. 1. ), and build 2.0 and 2.1 on it.

Best,
Wei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]