* Re: [PATCH net-next v2 3/5] virtio_ring: add packed ring support
From: Jason Wang @ 2018-11-09 10:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtio-dev, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20181108225555-mutt-send-email-mst@kernel.org>
On 2018/11/9 上午11:58, Michael S. Tsirkin wrote:
> On Fri, Nov 09, 2018 at 10:25:28AM +0800, Jason Wang wrote:
>> On 2018/11/8 下午10:14, Michael S. Tsirkin wrote:
>>> On Thu, Nov 08, 2018 at 04:18:25PM +0800, Jason Wang wrote:
>>>> On 2018/11/8 上午9:38, Tiwei Bie wrote:
>>>>>>> +
>>>>>>> + if (vq->vq.num_free < descs_used) {
>>>>>>> + pr_debug("Can't add buf len %i - avail = %i\n",
>>>>>>> + descs_used, vq->vq.num_free);
>>>>>>> + /* FIXME: for historical reasons, we force a notify here if
>>>>>>> + * there are outgoing parts to the buffer. Presumably the
>>>>>>> + * host should service the ring ASAP. */
>>>>>> I don't think we have a reason to do this for packed ring.
>>>>>> No historical baggage there, right?
>>>>> Based on the original commit log, it seems that the notify here
>>>>> is just an "optimization". But I don't quite understand what does
>>>>> the "the heuristics which KVM uses" refer to. If it's safe to drop
>>>>> this in packed ring, I'd like to do it.
>>>> According to the commit log, it seems like a workaround of lguest networking
>>>> backend. I agree to drop it, we should not have such burden.
>>>>
>>>> But we should notice that, with this removed, the compare between packed vs
>>>> split is kind of unfair.
>>> I don't think this ever triggers to be frank. When would it?
>>
>> I think it can happen e.g in the path of XDP transmission in
>> __virtnet_xdp_xmit_one():
>>
>>
>> err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdpf, GFP_ATOMIC);
>> if (unlikely(err))
>> return -ENOSPC; /* Caller handle free/refcnt */
>>
> I see. We used to do it for regular xmit but stopped
> doing it. Is it fine for xdp then?
There's no traffic control in XDP, so it was the only thing we can do.
>
>>>> Consider the removal of lguest support recently,
>>>> maybe we can drop this for split ring as well?
>>>>
>>>> Thanks
>>> If it's helpful, then for sure we can drop it for virtio 1.
>>> Can you see any perf differences at all? With which device?
>>
>> I don't test but consider the case of XDP_TX in guest plus vhost_net in
>> host. Since vhost_net is half duplex, it's pretty easier to trigger this
>> condition.
>>
>> Thanks
> Sounds reasonable. Worth testing before we change things though.
Let me test and submit a patch.
Thanks
>
>>>>> commit 44653eae1407f79dff6f52fcf594ae84cb165ec4
>>>>> Author: Rusty Russell<rusty@rustcorp.com.au>
>>>>> Date: Fri Jul 25 12:06:04 2008 -0500
>>>>>
>>>>> virtio: don't always force a notification when ring is full
>>>>> We force notification when the ring is full, even if the host has
>>>>> indicated it doesn't want to know. This seemed like a good idea at
>>>>> the time: if we fill the transmit ring, we should tell the host
>>>>> immediately.
>>>>> Unfortunately this logic also applies to the receiving ring, which is
>>>>> refilled constantly. We should introduce real notification thesholds
>>>>> to replace this logic. Meanwhile, removing the logic altogether breaks
>>>>> the heuristics which KVM uses, so we use a hack: only notify if there are
>>>>> outgoing parts of the new buffer.
>>>>> Here are the number of exits with lguest's crappy network implementation:
>>>>> Before:
>>>>> network xmit 7859051 recv 236420
>>>>> After:
>>>>> network xmit 7858610 recv 118136
>>>>> Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
>>>>>
>>>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>>>>> index 72bf8bc09014..21d9a62767af 100644
>>>>> --- a/drivers/virtio/virtio_ring.c
>>>>> +++ b/drivers/virtio/virtio_ring.c
>>>>> @@ -87,8 +87,11 @@ static int vring_add_buf(struct virtqueue *_vq,
>>>>> if (vq->num_free < out + in) {
>>>>> pr_debug("Can't add buf len %i - avail = %i\n",
>>>>> out + in, vq->num_free);
>>>>> - /* We notify*even if* VRING_USED_F_NO_NOTIFY is set here. */
>>>>> - vq->notify(&vq->vq);
>>>>> + /* FIXME: for historical reasons, we force a notify here if
>>>>> + * there are outgoing parts to the buffer. Presumably the
>>>>> + * host should service the ring ASAP. */
>>>>> + if (out)
>>>>> + vq->notify(&vq->vq);
>>>>> END_USE(vq);
>>>>> return -ENOSPC;
>>>>> }
>>>>>
>>>>>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] virtio_ring: add packed ring support
From: Jason Wang @ 2018-11-09 10:05 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtio-dev, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20181108225858-mutt-send-email-mst@kernel.org>
On 2018/11/9 下午12:00, Michael S. Tsirkin wrote:
> On Fri, Nov 09, 2018 at 10:30:50AM +0800, Jason Wang wrote:
>> On 2018/11/8 下午11:56, Michael S. Tsirkin wrote:
>>> On Thu, Nov 08, 2018 at 07:51:48PM +0800, Tiwei Bie wrote:
>>>> On Thu, Nov 08, 2018 at 04:18:25PM +0800, Jason Wang wrote:
>>>>> On 2018/11/8 上午9:38, Tiwei Bie wrote:
>>>>>>>> +
>>>>>>>> + if (vq->vq.num_free < descs_used) {
>>>>>>>> + pr_debug("Can't add buf len %i - avail = %i\n",
>>>>>>>> + descs_used, vq->vq.num_free);
>>>>>>>> + /* FIXME: for historical reasons, we force a notify here if
>>>>>>>> + * there are outgoing parts to the buffer. Presumably the
>>>>>>>> + * host should service the ring ASAP. */
>>>>>>> I don't think we have a reason to do this for packed ring.
>>>>>>> No historical baggage there, right?
>>>>>> Based on the original commit log, it seems that the notify here
>>>>>> is just an "optimization". But I don't quite understand what does
>>>>>> the "the heuristics which KVM uses" refer to. If it's safe to drop
>>>>>> this in packed ring, I'd like to do it.
>>>>> According to the commit log, it seems like a workaround of lguest networking
>>>>> backend.
>>>> Do you know why removing this notify in Tx will break "the
>>>> heuristics which KVM uses"? Or what does "the heuristics
>>>> which KVM uses" refer to?
>>> Yes. QEMU has a mode where it disables notifications and processes TX
>>> ring periodically from a timer. It's off by default but used to be on
>>> by default a long time ago. If ring becomes full this causes traffic
>>> stalls.
>>
>> Do you mean tx-timer? If yes, we can still enable it for packed ring
> Yes we can but I doubt anyone does.
>
>> and the
>> timer will finally fired and we can go.
> on tx ring full we probably don't want to wait for timer.
> But I think we can just prevent qemu from using tx timer
> with virtio 1.
Yes, we can.
Thanks
>
>>> As a work-around Rusty put in this hack to kick on ring full
>>> even with notifications disabled.
>>
>> From the commit log it looks more like a performance workaround instead of a
>> bug fix.
> it's a quality of implementation issue, yes.
>
>>> It's easy enough to make sure QEMU
>>> does not combine devices with packed ring support with the timer hack.
>>> And I am guessing it's safe enough to also block that option completely
>>> e.g. when virtio 1.0 is enabled.
>>
>> I agree.
>>
>> Thanks
>>
>>
>>>>> I agree to drop it, we should not have such burden.
>>>>>
>>>>> But we should notice that, with this removed, the compare between packed vs
>>>>> split is kind of unfair. Consider the removal of lguest support recently,
>>>>> maybe we can drop this for split ring as well?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>> commit 44653eae1407f79dff6f52fcf594ae84cb165ec4
>>>>>> Author: Rusty Russell<rusty@rustcorp.com.au>
>>>>>> Date: Fri Jul 25 12:06:04 2008 -0500
>>>>>>
>>>>>> virtio: don't always force a notification when ring is full
>>>>>> We force notification when the ring is full, even if the host has
>>>>>> indicated it doesn't want to know. This seemed like a good idea at
>>>>>> the time: if we fill the transmit ring, we should tell the host
>>>>>> immediately.
>>>>>> Unfortunately this logic also applies to the receiving ring, which is
>>>>>> refilled constantly. We should introduce real notification thesholds
>>>>>> to replace this logic. Meanwhile, removing the logic altogether breaks
>>>>>> the heuristics which KVM uses, so we use a hack: only notify if there are
>>>>>> outgoing parts of the new buffer.
>>>>>> Here are the number of exits with lguest's crappy network implementation:
>>>>>> Before:
>>>>>> network xmit 7859051 recv 236420
>>>>>> After:
>>>>>> network xmit 7858610 recv 118136
>>>>>> Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
>>>>>>
>>>>>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>>>>>> index 72bf8bc09014..21d9a62767af 100644
>>>>>> --- a/drivers/virtio/virtio_ring.c
>>>>>> +++ b/drivers/virtio/virtio_ring.c
>>>>>> @@ -87,8 +87,11 @@ static int vring_add_buf(struct virtqueue *_vq,
>>>>>> if (vq->num_free < out + in) {
>>>>>> pr_debug("Can't add buf len %i - avail = %i\n",
>>>>>> out + in, vq->num_free);
>>>>>> - /* We notify*even if* VRING_USED_F_NO_NOTIFY is set here. */
>>>>>> - vq->notify(&vq->vq);
>>>>>> + /* FIXME: for historical reasons, we force a notify here if
>>>>>> + * there are outgoing parts to the buffer. Presumably the
>>>>>> + * host should service the ring ASAP. */
>>>>>> + if (out)
>>>>>> + vq->notify(&vq->vq);
>>>>>> END_USE(vq);
>>>>>> return -ENOSPC;
>>>>>> }
>>>>>>
>>>>>>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
From: Gerd Hoffmann @ 2018-11-09 10:13 UTC (permalink / raw)
To: Emil Velikov
Cc: Rob Herring, Gustavo Padovan, Robert Foss,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel,
open list:VIRTIO GPU DRIVER, David Airlie, Emil Velikov
In-Reply-To: <CACvgo53vCBbgmu4OV4e0WeOYQSXNk=3qwyRBtPx+XAcCSZO8aQ@mail.gmail.com>
On Mon, Nov 05, 2018 at 05:25:05PM +0000, Emil Velikov wrote:
> On Mon, 5 Nov 2018 at 11:42, Robert Foss <robert.foss@collabora.com> wrote:
> >
> > When the execbuf call receives an in-fence it will get the dma_fence
> > related to that fence fd and wait on it before submitting the draw call.
> >
> > On the out-fence side we get fence returned by the submitted draw call
> > and attach it to a sync_file and send the sync_file fd to userspace. On
> > error -1 is returned to userspace.
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> > Signed-off-by: Robert Foss <robert.foss@collabora.com>
> > Suggested-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
> > ---
> >
> > Changes since v3:
> > - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block
> Fwiw my suggestion was to explicitly document whether the IOCTL can
> support, simultaneously, IN and OUT fence.
Yes, that would be good. Code looks like it is supposed to work, but
explicitly saying so in the commit message would be nice.
Also: should we use separate fields for in/out fds?
cheers,
Gerd
^ permalink raw reply
* [PATCH] x86/vmware: Do not trace vmware_sched_clock()
From: Steven Rostedt @ 2018-11-09 20:22 UTC (permalink / raw)
To: LKML
Cc: GwanYeong Kim, x86, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Alok Kataria, virtualization, Thomas Gleixner
From: Steven Rostedt (VMware) <rostedt@goodmis.org>
When running function tracing on a Linux guest running on VMware
Workstation, the guest would crash. This is due to tracing of the
sched_clock internal call of the VMware vmware_sched_clock(), which
causes an infinite recursion within the tracing code (clock calls must
not be traced).
Make vmware_sched_clock() not traced by ftrace.
Cc: stable@vger.kernel.org
Fixes: 80e9a4f21fd7c ("x86/vmware: Add paravirt sched clock")
Reported-by: GwanYeong Kim <gy741.kim@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index d9ab49bed8af..0eda91f8eeac 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -77,7 +77,7 @@ static __init int setup_vmw_sched_clock(char *s)
}
early_param("no-vmw-sched-clock", setup_vmw_sched_clock);
-static unsigned long long vmware_sched_clock(void)
+static unsigned long long notrace vmware_sched_clock(void)
{
unsigned long long ns;
^ permalink raw reply related
* Call for Papers - WorldCIST'19 - La Toja Island, Spain
From: Marle @ 2018-11-11 17:48 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 9244 bytes --]
*** Proceedings published by Springer
------------------------------ -----------------------------
WorldCIST'19 - 7th World Conference on Information Systems and Technologies
16 - 19 April 2019 | La Toja Island, Spain
http://www.worldcist.org/ <http://www.worldcist.org/>
------------------------------ ------------------------------ ------------------------------ ------
Scope
The WorldCist'19 - 7th World Conference on Information Systems and Technologies, to be held at La Toja Island, Galicia, Spain, 16 - 19 April 2019, is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.
We are pleased to invite you to submit your papers to WorldCist'18. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
Themes
Submitted papers should be related with one or more of the main themes proposed for the Conference:
A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);
M) Information Technologies in Radiocommunications (ITR);
N) Technologies for Biomedical Applications (TBA)
Types of Submissions and Decisions
Four types of papers can be submitted:
Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.
Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.
Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.
Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.
Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see Instructions for Authors at Springer Website <https://www.springer.com/us/authors-editors/conference-proceedings/conference-proceedings-guidelines> or download a Word Template <ftp://ftp.springernature.com/cs-proceeding/llncs/word/splnproc1703.zip>or Latex Package <ftp://ftp.springernature.com/cs-proceeding/svproc/templates/ProcSci_TeX.zip>) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publish form <http://worldcist.org/copyright.pdf> filled out, in a ZIP file, and uploaded at the conference management system.
All papers will be subjected to a “double-blind review” by at least two members of the Program Committee.
Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.
The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.
The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.
Publication and Indexing
To ensure that a full paper, short paper, poster paper or company paper is published, at least one of the authors must be fully registered by the 13th of January 2019, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing <http://www.springer.com/series/11156> series. Poster and company papers will not be published, just presented in the conference.
Published full and short papers will be submitted for indexation by ISI, EI-Compendex, SCOPUS, DBLP and Google Scholar, among others, and will be available in the SpringerLink Digital Library.
The authors of the best selected papers will be invited to extend them for publication in international journals indexed by ISI/SCI, SCOPUS and DBLP, among others, such as:
International Journal of Neural Systems <https://www.worldscientific.com/worldscinet/ijns> (IF: 4.58 / Q1)
Integrated Computer-Aided Engineering <http://www.iospress.nl/journal/integrated-computer-aided-engineering/> (IF: 3.667 / Q1)
Telecommunications Policy <https://www.journals.elsevier.com/telecommunications-policy> (IF: 2.087 / Q1)
Group Decision and Negotiation <https://www.springer.com/business+%26+management/operations+research/journal/10726> (IF: 1.869 / Q1)
Computers in Industry <https://www.journals.elsevier.com/computers-in-industry> (IF: 2.850 / Q2)
Journal of Medical Systems <http://www.springer.com/public+health/journal/10916> (IF: 2.098 / Q2)
Computer Languages, Systems & Structures <https://www.journals.elsevier.com/computer-languages-systems-and-structures/> (IF: 1.840 / Q2)
Cluster Computing <https://www.springer.com/computer/communication+networks/journal/10586> (IF: 1.601 / Q2)
Expert Systems - Journal of Knowledge Engineering <http://onlinelibrary.wiley.com/journal/10.1111/(ISSN)1468-0394> (IF: 1.43 / Q2)
Informatica - An International Journal <https://www.mii.lt/informatica/> (IF: 1.386 / Q2)
Journal of Intelligent & Fuzzy Systems <https://www.iospress.nl/journal/journal-of-intelligent-fuzzy-systems/> (IF: 1.426 / Q3)
Enterprise Information Systems <https://www.tandfonline.com/toc/teis20/current> (IF: 1.683 / Q3)
Data Technologies and Applications <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=dta> (IF: 1.170 / Q3)
Innovations in Education and Teaching International <https://www.tandfonline.com/toc/riie20/current> (IF: 1.106 / Q3)
Intelligent Data Analysis <http://www.iospress.nl/journal/intelligent-data-analysis> (IF: 0.691 / Q4)
Computational and Mathematical Organization Theory <http://www.springer.com/business+%26+management/journal/10588> (IF: 0.641 / Q4)
AI Communications <https://www.iospress.nl/journal/ai-communications/> (IF: 0.461 / Q4)
Journal of Web Engineering <http://www.riverpublishers.com/journal.php?j=JWE/17/4> (IF: 0.311 / Q4)
Journal of Database Management <https://www.igi-global.com/journal/journal-database-management/1072> (IF: 0.231 / Q4)
Journal of Hospitality and Tourism Technology <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=jhtt> (ISI - Emerging Sources Citation Index)
Computer Methods in Biomechanics and Biomedical Engineering - Imaging & Visualization <http://www.tandfonline.com/action/journalInformation?show=aimsScope&journalCode=tciv20#.V4KqBzUmMQs> (ISI - Emerging Sources Citation Index)
Journal of Information Systems Engineering & Management <http://www.lectitojournals.com/journal-for-information-systems-engineering-management>
Important Dates
Paper Submission: November 18, 2018
Notification of Acceptance: December 30, 2018
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 13, 2019.
Camera-ready Submission: January 13, 2019
Website of WorldCIST'19: http://www.worldcist.org/ <http://www.worldcist.org/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 20391 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
From: Gerd Hoffmann @ 2018-11-12 9:10 UTC (permalink / raw)
To: Robert Foss
Cc: David Airlie, Emil Velikov, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, open list:VIRTIO GPU DRIVER, Gustavo Padovan,
Emil Velikov
In-Reply-To: <f5143d56-3e11-51f7-a07a-9106aa8bda49@collabora.com>
On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote:
> Hey Gerd,
>
> On 2018-11-09 11:13, Gerd Hoffmann wrote:
> > On Mon, Nov 05, 2018 at 05:25:05PM +0000, Emil Velikov wrote:
> > > On Mon, 5 Nov 2018 at 11:42, Robert Foss <robert.foss@collabora.com> wrote:
> > > >
> > > > When the execbuf call receives an in-fence it will get the dma_fence
> > > > related to that fence fd and wait on it before submitting the draw call.
> > > >
> > > > On the out-fence side we get fence returned by the submitted draw call
> > > > and attach it to a sync_file and send the sync_file fd to userspace. On
> > > > error -1 is returned to userspace.
> > > >
> > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> > > > Signed-off-by: Robert Foss <robert.foss@collabora.com>
> > > > Suggested-by: Rob Herring <robh@kernel.org>
> > > > Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
> > > > ---
> > > >
> > > > Changes since v3:
> > > > - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block
> > > Fwiw my suggestion was to explicitly document whether the IOCTL can
> > > support, simultaneously, IN and OUT fence.
> >
> > Yes, that would be good. Code looks like it is supposed to work, but
> > explicitly saying so in the commit message would be nice.
>
> On it! Will send out a v5.
>
> >
> > Also: should we use separate fields for in/out fds?
>
> I'm not sure I understand which fields you're referring to.
fence_in_fd & fence_out_fd in the ioctl struct (patch #2).
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v5 0/4] virgl: fence fd support
From: Gerd Hoffmann @ 2018-11-14 12:14 UTC (permalink / raw)
To: Robert Foss
Cc: Rob Herring, airlied, linux-kernel, dri-devel, virtualization,
Gustavo Padovan, Emil Velikov
In-Reply-To: <20181112165157.32765-1-robert.foss@collabora.com>
On Mon, Nov 12, 2018 at 05:51:53PM +0100, Robert Foss wrote:
>
> This series implements fence support for drm/virtio and
> has been tested using qemu, kmscube and the below branches.
>
> Rob Herring solved a reference counting issue and
> suggested a context check for the execbuf ioctl, his
> changes have been included in the below commits to
> keep the tree working at all commits.
Patches added to qemu queue, should land in drm-misc-next soon.
thanks,
Gerd
^ permalink raw reply
* Re: [PATCH][drm-next] drm/virtio: fix memory leak of vfpriv on error return path
From: Gerd Hoffmann @ 2018-11-14 12:14 UTC (permalink / raw)
To: Colin King
Cc: David Airlie, kernel-janitors, linux-kernel, dri-devel,
virtualization
In-Reply-To: <20181107203122.6861-1-colin.king@canonical.com>
On Wed, Nov 07, 2018 at 08:31:22PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The allocation for vfpriv is being leaked on an error return path,
> fix this by kfree'ing it before returning.
>
> Detected by CoverityScan, CID#1475380 ("Resource Leak")
Patches added to qemu queue, should land in drm-misc-next soon.
thanks,
Gerd
^ permalink raw reply
* Re: [PATCH -next] drm/qxl: remove set but not used variable 'map'
From: Gerd Hoffmann @ 2018-11-14 12:16 UTC (permalink / raw)
To: YueHaibing
Cc: David Airlie, kernel-janitors, linux-kernel, dri-devel,
virtualization, Dave Airlie
In-Reply-To: <1541821486-40631-1-git-send-email-yuehaibing@huawei.com>
On Sat, Nov 10, 2018 at 03:44:46AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/qxl/qxl_object.c: In function 'qxl_bo_kunmap_atomic_page':
> drivers/gpu/drm/qxl/qxl_object.c:189:21: warning:
> variable 'map' set but not used [-Wunused-but-set-variable]
Both qxl patches added to qemu queue, should land in drm-misc-next soon.
thanks,
Gerd
^ permalink raw reply
* Call for Papers - WorldCIST'19 - La Toja Island, Spain | Deadline: November 28
From: Marle @ 2018-11-14 19:11 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 9252 bytes --]
*** Proceedings published by Springer
------------------------------ -----------------------------
WorldCIST'19 - 7th World Conference on Information Systems and Technologies
16 - 19 April 2019 | La Toja Island, Spain
http://www.worldcist.org/ <http://www.worldcist.org/>
------------------------------ ------------------------------ ------------------------------ ------
Scope
The WorldCist'19 - 7th World Conference on Information Systems and Technologies, to be held at La Toja Island, Galicia, Spain, 16 - 19 April 2019, is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.
We are pleased to invite you to submit your papers to WorldCist'18. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
Themes
Submitted papers should be related with one or more of the main themes proposed for the Conference:
A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);
M) Information Technologies in Radiocommunications (ITR);
N) Technologies for Biomedical Applications (TBA)
Types of Submissions and Decisions
Four types of papers can be submitted:
Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.
Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.
Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.
Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.
Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see Instructions for Authors at Springer Website <https://www.springer.com/us/authors-editors/conference-proceedings/conference-proceedings-guidelines> or download a Word Template <ftp://ftp.springernature.com/cs-proceeding/llncs/word/splnproc1703.zip>or Latex Package <ftp://ftp.springernature.com/cs-proceeding/svproc/templates/ProcSci_TeX.zip>) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publish form <http://worldcist.org/copyright.pdf> filled out, in a ZIP file, and uploaded at the conference management system.
All papers will be subjected to a “double-blind review” by at least two members of the Program Committee.
Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.
The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.
The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.
Publication and Indexing
To ensure that a full paper, short paper, poster paper or company paper is published, at least one of the authors must be fully registered by the 13th of January 2019, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing <http://www.springer.com/series/11156> series. Poster and company papers will not be published, just presented in the conference.
Published full and short papers will be submitted for indexation by ISI, EI-Compendex, SCOPUS, DBLP and Google Scholar, among others, and will be available in the SpringerLink Digital Library.
The authors of the best selected papers will be invited to extend them for publication in international journals indexed by ISI/SCI, SCOPUS and DBLP, among others, such as:
International Journal of Neural Systems <https://www.worldscientific.com/worldscinet/ijns> (IF: 4.58 / Q1)
Integrated Computer-Aided Engineering <http://www.iospress.nl/journal/integrated-computer-aided-engineering/> (IF: 3.667 / Q1)
Telecommunications Policy <https://www.journals.elsevier.com/telecommunications-policy> (IF: 2.087 / Q1)
Group Decision and Negotiation <https://www.springer.com/business+%26+management/operations+research/journal/10726> (IF: 1.869 / Q1)
Computers in Industry <https://www.journals.elsevier.com/computers-in-industry> (IF: 2.850 / Q2)
Journal of Medical Systems <http://www.springer.com/public+health/journal/10916> (IF: 2.098 / Q2)
Computer Languages, Systems & Structures <https://www.journals.elsevier.com/computer-languages-systems-and-structures/> (IF: 1.840 / Q2)
Cluster Computing <https://www.springer.com/computer/communication+networks/journal/10586> (IF: 1.601 / Q2)
Expert Systems - Journal of Knowledge Engineering <http://onlinelibrary.wiley.com/journal/10.1111/(ISSN)1468-0394> (IF: 1.43 / Q2)
Informatica - An International Journal <https://www.mii.lt/informatica/> (IF: 1.386 / Q2)
Journal of Intelligent & Fuzzy Systems <https://www.iospress.nl/journal/journal-of-intelligent-fuzzy-systems/> (IF: 1.426 / Q3)
Enterprise Information Systems <https://www.tandfonline.com/toc/teis20/current> (IF: 1.683 / Q3)
Data Technologies and Applications <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=dta> (IF: 1.170 / Q3)
Innovations in Education and Teaching International <https://www.tandfonline.com/toc/riie20/current> (IF: 1.106 / Q3)
Intelligent Data Analysis <http://www.iospress.nl/journal/intelligent-data-analysis> (IF: 0.691 / Q4)
Computational and Mathematical Organization Theory <http://www.springer.com/business+%26+management/journal/10588> (IF: 0.641 / Q4)
AI Communications <https://www.iospress.nl/journal/ai-communications/> (IF: 0.461 / Q4)
Journal of Web Engineering <http://www.riverpublishers.com/journal.php?j=JWE/17/4> (IF: 0.311 / Q4)
Journal of Database Management <https://www.igi-global.com/journal/journal-database-management/1072> (IF: 0.231 / Q4)
Journal of Hospitality and Tourism Technology <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=jhtt> (ISI - Emerging Sources Citation Index)
Computer Methods in Biomechanics and Biomedical Engineering - Imaging & Visualization <http://www.tandfonline.com/action/journalInformation?show=aimsScope&journalCode=tciv20#.V4KqBzUmMQs> (ISI - Emerging Sources Citation Index)
Journal of Information Systems Engineering & Management <http://www.lectitojournals.com/journal-for-information-systems-engineering-management>
Important Dates
Paper Submission: November 28, 2018
Notification of Acceptance: December 30, 2018
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 13, 2019.
Camera-ready Submission: January 13, 2019
Website of WorldCIST'19: http://www.worldcist.org/ <http://www.worldcist.org/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 20439 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 3:56 UTC (permalink / raw)
To: stefanha, stefanha, Jason Wang, mst; +Cc: netdev, kvm, virtualization
Hi Stefan, Michael, Jason and everyone,
Several days ago, I discussed with jason about "Vsock over Virtio-net".
This idea has two advantages:
First, it can use many great features of virtio-net, like batching,
mergeable rx buffer and multiqueue, etc.
Second, it can reduce many duplicate codes and make it easy to be
maintained.
Before the implement, I want to discuss with everyone again, and
want to know everyone's suggestions.
After the discussion, based on this point I will try to implement
this idea, but I am not familiar with the virtio-net, that is a
pity. :(
-------------------------Simple idea------------------------------
1. The packet layout will become as follows:
+---------------------------------+
| Virtio-net header |
|(struct virtio_net_hdr_mrg_rxbuf)|
+---------------------------------+
| Vsock header |
| (struct virtio_vsock_hdr) |
+---------------------------------+
| payload |
| (until end of packet) |
+---------------------------------+
2. The Guest->Host basic code flow as follow:
+------------+
| Client |
+------------+
|
|
+------------------------------------------------------------------+
|VSOCK Core Module |
|ops->sendmsg; (vsock_stream_sendmsg) |
| -> alloc_skb; /* it will packet a skb buffer, and include vsock |
| * hdr and payload */ |
| -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
|vsock hdr and payload, and then call |
+------------------------------------------------------------------+
|
|
+------------------------------------------------------------------+
|Virtio-net Module |
|start_xmit |
| -> add virtio_net_hdr and pack sg in ring desc, notify Host |
+------------------------------------------------------------------+
|
|
+------------------------------------------------------------------+
|Vhost-net Module |
|handle_tx |
| -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
| /* This point has some differences, vhost-net use ->sendmsg to |
| * forward information, however vsock only need to notify server |
| * that data ready. */ |
+------------------------------------------------------------------+
|
|
+------------------------------------------------------------------+
|VSOCK Core Module |
|alloc_pkt, copy skb data to pkt. |
|add pkt to rx_queue and notify server to get data. |
+------------------------------------------------------------------+
3. To Host->Guest
I have a problem and difficult, mainly I know about virtio-net a little),
because I have been doing work related with storage and file system.
The problem as follows:
we should monitor all of socket of vsock in handle_rx, when there are
data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
get data, it is different with socket. To vsock, I think host will
not call ->recvmsg when it need to send message to guest. To net,
vhost-net only as forwarding layer.
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 4:19 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BECEE53.7090408@huawei.com>
On 2018/11/15 上午11:56, jiangyiwen wrote:
> Hi Stefan, Michael, Jason and everyone,
>
> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> This idea has two advantages:
> First, it can use many great features of virtio-net, like batching,
> mergeable rx buffer and multiqueue, etc.
> Second, it can reduce many duplicate codes and make it easy to be
> maintained.
>
> Before the implement, I want to discuss with everyone again, and
> want to know everyone's suggestions.
>
> After the discussion, based on this point I will try to implement
> this idea, but I am not familiar with the virtio-net, that is a
> pity. :(
I think we should have a new feature flag for this. E.g
VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest
doesn't support this to avoid confusion. When this feature is
negotiated, we will use it only for VOSCK transport. This can simplify
things somehow.
> -------------------------Simple idea------------------------------
>
> 1. The packet layout will become as follows:
>
> +---------------------------------+
> | Virtio-net header |
> |(struct virtio_net_hdr_mrg_rxbuf)|
> +---------------------------------+
> | Vsock header |
> | (struct virtio_vsock_hdr) |
> +---------------------------------+
> | payload |
> | (until end of packet) |
> +---------------------------------+
>
> 2. The Guest->Host basic code flow as follow:
> +------------+
> | Client |
> +------------+
> |
> |
> +------------------------------------------------------------------+
> |VSOCK Core Module |
> |ops->sendmsg; (vsock_stream_sendmsg) |
> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
> | * hdr and payload */ |
> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
> |vsock hdr and payload, and then call |
> +------------------------------------------------------------------+
Note, if we've negotiated the feature, virtio-net driver must not use
register_netdev to register it to network core. This can avoid lots of
confusion.
> |
> |
> +------------------------------------------------------------------+
> |Virtio-net Module |
> |start_xmit |
> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
> +------------------------------------------------------------------+
> |
> |
> +------------------------------------------------------------------+
> |Vhost-net Module |
> |handle_tx |
> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
> | /* This point has some differences, vhost-net use ->sendmsg to |
> | * forward information, however vsock only need to notify server |
> | * that data ready. */ |
> +------------------------------------------------------------------+
When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock
transport, we can then forward it to vsock core.
> |
> |
> +------------------------------------------------------------------+
> |VSOCK Core Module |
> |alloc_pkt, copy skb data to pkt. |
> |add pkt to rx_queue and notify server to get data. |
> +------------------------------------------------------------------+
>
> 3. To Host->Guest
> I have a problem and difficult, mainly I know about virtio-net a little),
> because I have been doing work related with storage and file system.
>
> The problem as follows:
> we should monitor all of socket of vsock in handle_rx, when there are
> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
> get data, it is different with socket. To vsock, I think host will
> not call ->recvmsg when it need to send message to guest. To net,
> vhost-net only as forwarding layer.
Know not much here, but is it possible to have a vsock(tap) to be passed
to vhost_net and let vhost call its recvmgs()? Bascially it was a socket
on host as well I believe?
If this doesn't work, we can have vsock specific receiving routine in
vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
Generally, I think we should try out best to keep the exist
sendmsg()/recvmsg() interfaces and only consider the alternatives if we
meet some real blocker.
Thanks
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:46 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <88eaf53b-b148-7b27-491a-30706398ae06@redhat.com>
On 2018/11/15 12:19, Jason Wang wrote:
>
> On 2018/11/15 上午11:56, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>
>
> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>
>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>>
>> 2. The Guest->Host basic code flow as follow:
>> +------------+
>> | Client |
>> +------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |ops->sendmsg; (vsock_stream_sendmsg) |
>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>> | * hdr and payload */ |
>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>> |vsock hdr and payload, and then call |
>> +------------------------------------------------------------------+
>
>
> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
Hi Jason,
You mean we should not register netdev if use vsock, and in order to
avoid confusion, then I think whether we should keep vsock and export
some virtio-net's functions that can be shared. In this way, first, vsock
may keep existing architecture and will not affect virtio-net. In addition,
vsock doesn't need to use virtio_net header too, then it don't need to pack
skb structure.
Thanks,
Yiwen.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |Virtio-net Module |
>> |start_xmit |
>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>> +------------------------------------------------------------------+
>> |
>> |
>> +------------------------------------------------------------------+
>> |Vhost-net Module |
>> |handle_tx |
>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>> | /* This point has some differences, vhost-net use ->sendmsg to |
>> | * forward information, however vsock only need to notify server |
>> | * that data ready. */ |
>> +------------------------------------------------------------------+
>
>
> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>
>
>> |
>> |
>> +------------------------------------------------------------------+
>> |VSOCK Core Module |
>> |alloc_pkt, copy skb data to pkt. |
>> |add pkt to rx_queue and notify server to get data. |
>> +------------------------------------------------------------------+
>>
>> 3. To Host->Guest
>> I have a problem and difficult, mainly I know about virtio-net a little),
>> because I have been doing work related with storage and file system.
>>
>> The problem as follows:
>> we should monitor all of socket of vsock in handle_rx, when there are
>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>> get data, it is different with socket. To vsock, I think host will
>> not call ->recvmsg when it need to send message to guest. To net,
>> vhost-net only as forwarding layer.
>
> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
For vsock, Host->Guest, it's code flow as follows:
Server call send()
-> sendmsg(); (vsock_stream_sendmsg)
-> virtio_trasnport_send_pkt_info
-> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
Vhost_worker
-> vhost_transport_send_pkt_work
-> get pkt from send_pkt_list
-> get vq input desc and then fill data to desc addr
-> update used ring and then signal guest
In the whole process, host don't call recvmsg() because it is a net device, and
it also receives any messages.
For vhost-net, I understand it is a tap device, so it can receive messages
from other net device.
This is my understanding, it may have some errors.
Thanks.
>
> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>
> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>
> Thanks
>
>
>>
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 6:49 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 14:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>>
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net. In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
>
> Thanks,
> Yiwen.
>
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>>
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
Sorry, it is *not* a net device, it *does not* receive any messages.
Thanks.
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-11-15 7:04 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5BECEE53.7090408@huawei.com>
On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
> Hi Stefan, Michael, Jason and everyone,
>
> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> This idea has two advantages:
> First, it can use many great features of virtio-net, like batching,
> mergeable rx buffer and multiqueue, etc.
> Second, it can reduce many duplicate codes and make it easy to be
> maintained.
I'm not sure I get the motivation. Which features of
virtio net are relevant to vsock? The ones that you mention
all seem to be mostly of use to the networking stack.
> Before the implement, I want to discuss with everyone again, and
> want to know everyone's suggestions.
>
> After the discussion, based on this point I will try to implement
> this idea, but I am not familiar with the virtio-net, that is a
> pity. :(
>
> -------------------------Simple idea------------------------------
>
> 1. The packet layout will become as follows:
>
> +---------------------------------+
> | Virtio-net header |
> |(struct virtio_net_hdr_mrg_rxbuf)|
Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
> +---------------------------------+
> | Vsock header |
> | (struct virtio_vsock_hdr) |
> +---------------------------------+
> | payload |
> | (until end of packet) |
> +---------------------------------+
Thanks,
--
MST
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 7:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
>
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock? The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
>> Before the implement, I want to discuss with everyone again, and
>> want to know everyone's suggestions.
>>
>> After the discussion, based on this point I will try to implement
>> this idea, but I am not familiar with the virtio-net, that is a
>> pity. :(
>>
>> -------------------------Simple idea------------------------------
>>
>> 1. The packet layout will become as follows:
>>
>> +---------------------------------+
>> | Virtio-net header |
>> |(struct virtio_net_hdr_mrg_rxbuf)|
>
> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>
Hi Michael,
Yes, currently vsock has poor performance, first, it only support transport
small packet, in order to make the balance between performance and guest memory.
In order to solve this problem, there are two features vsock can used,
mergeable rx buffer and multiqueue. Based on this, there are some shared
codes vsock can use.
Thanks,
Yiwen.
>> +---------------------------------+
>> | Vsock header |
>> | (struct virtio_vsock_hdr) |
>> +---------------------------------+
>> | payload |
>> | (until end of packet) |
>> +---------------------------------+
>
> Thanks,
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Michael S. Tsirkin @ 2018-11-15 8:10 UTC (permalink / raw)
To: jiangyiwen; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <5BED2267.8030306@huawei.com>
On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
> > On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
> >> Hi Stefan, Michael, Jason and everyone,
> >>
> >> Several days ago, I discussed with jason about "Vsock over Virtio-net".
> >> This idea has two advantages:
> >> First, it can use many great features of virtio-net, like batching,
> >> mergeable rx buffer and multiqueue, etc.
> >> Second, it can reduce many duplicate codes and make it easy to be
> >> maintained.
> >
> > I'm not sure I get the motivation. Which features of
> > virtio net are relevant to vsock? The ones that you mention
> > all seem to be mostly of use to the networking stack.
> >
> >
> >> Before the implement, I want to discuss with everyone again, and
> >> want to know everyone's suggestions.
> >>
> >> After the discussion, based on this point I will try to implement
> >> this idea, but I am not familiar with the virtio-net, that is a
> >> pity. :(
> >>
> >> -------------------------Simple idea------------------------------
> >>
> >> 1. The packet layout will become as follows:
> >>
> >> +---------------------------------+
> >> | Virtio-net header |
> >> |(struct virtio_net_hdr_mrg_rxbuf)|
> >
> > Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
> >
>
> Hi Michael,
>
> Yes, currently vsock has poor performance, first, it only support transport
> small packet, in order to make the balance between performance and guest memory.
>
> In order to solve this problem, there are two features vsock can used,
> mergeable rx buffer and multiqueue. Based on this, there are some shared
> codes vsock can use.
>
> Thanks,
> Yiwen.
Supporting more queues with vsock is probably significantly
less work than a completely new interface.
For mergeable, as buffers are split arbitrarily, why can't you combine
them within guest driver before sending them up the stack?
Probably better than relying on host to do it.
> >> +---------------------------------+
> >> | Vsock header |
> >> | (struct virtio_vsock_hdr) |
> >> +---------------------------------+
> >> | payload |
> >> | (until end of packet) |
> >> +---------------------------------+
> >
> > Thanks,
> >
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:19 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED162C.5070902@huawei.com>
On 2018/11/15 下午2:46, jiangyiwen wrote:
> On 2018/11/15 12:19, Jason Wang wrote:
>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>> Hi Stefan, Michael, Jason and everyone,
>>>
>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>> This idea has two advantages:
>>> First, it can use many great features of virtio-net, like batching,
>>> mergeable rx buffer and multiqueue, etc.
>>> Second, it can reduce many duplicate codes and make it easy to be
>>> maintained.
>>>
>>> Before the implement, I want to discuss with everyone again, and
>>> want to know everyone's suggestions.
>>>
>>> After the discussion, based on this point I will try to implement
>>> this idea, but I am not familiar with the virtio-net, that is a
>>> pity. :(
>>
>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>
>>
>>> -------------------------Simple idea------------------------------
>>>
>>> 1. The packet layout will become as follows:
>>>
>>> +---------------------------------+
>>> | Virtio-net header |
>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> +---------------------------------+
>>> | Vsock header |
>>> | (struct virtio_vsock_hdr) |
>>> +---------------------------------+
>>> | payload |
>>> | (until end of packet) |
>>> +---------------------------------+
>>>
>>> 2. The Guest->Host basic code flow as follow:
>>> +------------+
>>> | Client |
>>> +------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>> | * hdr and payload */ |
>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>> |vsock hdr and payload, and then call |
>>> +------------------------------------------------------------------+
>>
>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
> Hi Jason,
>
> You mean we should not register netdev if use vsock, and in order to
> avoid confusion, then I think whether we should keep vsock and export
> some virtio-net's functions that can be shared. In this way, first, vsock
> may keep existing architecture and will not affect virtio-net.
At least it needs new feature bits which will be a functional
duplication of virtio-net (e.g mrg_rxbuf).
> In addition,
> vsock doesn't need to use virtio_net header too, then it don't need to pack
> skb structure.
For mergeable rx buffer it need I think?
>
> Thanks,
> Yiwen.
>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Virtio-net Module |
>>> |start_xmit |
>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>> +------------------------------------------------------------------+
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |Vhost-net Module |
>>> |handle_tx |
>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>> | * forward information, however vsock only need to notify server |
>>> | * that data ready. */ |
>>> +------------------------------------------------------------------+
>>
>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>
>>
>>> |
>>> |
>>> +------------------------------------------------------------------+
>>> |VSOCK Core Module |
>>> |alloc_pkt, copy skb data to pkt. |
>>> |add pkt to rx_queue and notify server to get data. |
>>> +------------------------------------------------------------------+
>>>
>>> 3. To Host->Guest
>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>> because I have been doing work related with storage and file system.
>>>
>>> The problem as follows:
>>> we should monitor all of socket of vsock in handle_rx, when there are
>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>> get data, it is different with socket. To vsock, I think host will
>>> not call ->recvmsg when it need to send message to guest. To net,
>>> vhost-net only as forwarding layer.
>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
> For vsock, Host->Guest, it's code flow as follows:
> Server call send()
> -> sendmsg(); (vsock_stream_sendmsg)
> -> virtio_trasnport_send_pkt_info
> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>
> Vhost_worker
> -> vhost_transport_send_pkt_work
> -> get pkt from send_pkt_list
> -> get vq input desc and then fill data to desc addr
> -> update used ring and then signal guest
>
> In the whole process, host don't call recvmsg() because it is a net device, and
> it also receives any messages.
If I understand this correctly, there's no a socket object on host that
represent vosck in guest? If yes, maybe we can invent one.
Thanks
>
> For vhost-net, I understand it is a tap device, so it can receive messages
> from other net device.
>
> This is my understanding, it may have some errors.
>
> Thanks.
>
>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>
>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>
>> Thanks
>>
>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:24 UTC (permalink / raw)
To: Michael S. Tsirkin, jiangyiwen; +Cc: virtualization, kvm, stefanha, netdev
In-Reply-To: <20181115015547-mutt-send-email-mst@kernel.org>
On 2018/11/15 下午3:04, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>> Hi Stefan, Michael, Jason and everyone,
>>
>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>> This idea has two advantages:
>> First, it can use many great features of virtio-net, like batching,
>> mergeable rx buffer and multiqueue, etc.
>> Second, it can reduce many duplicate codes and make it easy to be
>> maintained.
> I'm not sure I get the motivation. Which features of
> virtio net are relevant to vsock?
Vsock is just a L2 (and above) protocol from the view of the device. So
I think we should answer the question why we need two different paths
for networking traffic? Or what is the fundamental reason that makes
vsock does not go for virtio-net?
I agree they could be different type of devices but codes could be
shared in both guest and host (or even qemu) for not duplicating
features(bugs).
Thanks
> The ones that you mention
> all seem to be mostly of use to the networking stack.
>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 8:27 UTC (permalink / raw)
To: Michael S. Tsirkin, jiangyiwen; +Cc: virtualization, kvm, stefanha, netdev
In-Reply-To: <20181115025622-mutt-send-email-mst@kernel.org>
On 2018/11/15 下午4:10, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
>> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
>>> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>> I'm not sure I get the motivation. Which features of
>>> virtio net are relevant to vsock? The ones that you mention
>>> all seem to be mostly of use to the networking stack.
>>>
>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity.:(
>>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>>>
>> Hi Michael,
>>
>> Yes, currently vsock has poor performance, first, it only support transport
>> small packet, in order to make the balance between performance and guest memory.
>>
>> In order to solve this problem, there are two features vsock can used,
>> mergeable rx buffer and multiqueue. Based on this, there are some shared
>> codes vsock can use.
>>
>> Thanks,
>> Yiwen.
> Supporting more queues with vsock is probably significantly
> less work than a completely new interface.
> For mergeable, as buffers are split arbitrarily, why can't you combine
> them within guest driver before sending them up the stack?
I don't get this question. But I think the fact that we use mergeable
buffer by default for virtio-net answer the question. Or anything
special in vsock?
Thanks
> Probably better than relying on host to do it.
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 8:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, virtualization, stefanha, netdev
In-Reply-To: <20181115025622-mutt-send-email-mst@kernel.org>
On 2018/11/15 16:10, Michael S. Tsirkin wrote:
> On Thu, Nov 15, 2018 at 03:38:15PM +0800, jiangyiwen wrote:
>> On 2018/11/15 15:04, Michael S. Tsirkin wrote:
>>> On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>>
>>> I'm not sure I get the motivation. Which features of
>>> virtio net are relevant to vsock? The ones that you mention
>>> all seem to be mostly of use to the networking stack.
>>>
>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity. :(
>>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>
>>> Which fields in virtio_net_hdr_mrg_rxbuf are of interest to vsock?
>>>
>>
>> Hi Michael,
>>
>> Yes, currently vsock has poor performance, first, it only support transport
>> small packet, in order to make the balance between performance and guest memory.
>>
>> In order to solve this problem, there are two features vsock can used,
>> mergeable rx buffer and multiqueue. Based on this, there are some shared
>> codes vsock can use.
>>
>> Thanks,
>> Yiwen.
>
> Supporting more queues with vsock is probably significantly
> less work than a completely new interface.
> For mergeable, as buffers are split arbitrarily, why can't you combine
> them within guest driver before sending them up the stack?
> Probably better than relying on host to do it.
>
Actually, I want to said the mergeable *rx* buffer, it cause the
default packet size of vsock is set to 4k. For tx buffer, it is
actually can be scattered in tx vq only need to modify very few codes.
In addition, I has already first version about vsock support mergeable
rx buffer and send patch to the VSOCK community, these codes are
revisited from virtio-net, and some codes are duplicated. Based on
this, we want to use virtio-net as transport of vsock. It can make
the vsock code easy to maintained.
Thanks.
>>>> +---------------------------------+
>>>> | Vsock header |
>>>> | (struct virtio_vsock_hdr) |
>>>> +---------------------------------+
>>>> | payload |
>>>> | (until end of packet) |
>>>> +---------------------------------+
>>>
>>> Thanks,
>>>
>>
>
> .
>
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: virtio-mmio: Add IOMMU description
From: Auger Eric @ 2018-11-15 8:45 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, virtualization, devicetree
Cc: mark.rutland, peter.maydell, lorenzo.pieralisi, tnowicki, mst,
marc.zyngier, linux-pci, will.deacon, kvmarm, robh+dt,
robin.murphy, joro
In-Reply-To: <20181012145917.6840-2-jean-philippe.brucker@arm.com>
Hi Jean,
On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
> The nature of a virtio-mmio node is discovered by the virtio driver at
> probe time. However the DMA relation between devices must be described
> statically. When a virtio-mmio node is a virtio-iommu device, it needs an
> "#iommu-cells" property as specified by bindings/iommu/iommu.txt.
>
> Otherwise, the virtio-mmio device may perform DMA through an IOMMU, which
> requires an "iommus" property. Describe these requirements in the
> device-tree bindings documentation.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
> .../devicetree/bindings/virtio/mmio.txt | 30 +++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt
> index 5069c1b8e193..748595473b36 100644
> --- a/Documentation/devicetree/bindings/virtio/mmio.txt
> +++ b/Documentation/devicetree/bindings/virtio/mmio.txt
> @@ -8,10 +8,40 @@ Required properties:
> - reg: control registers base address and size including configuration space
> - interrupts: interrupt generated by the device
>
> +Required properties for virtio-iommu:
> +
> +- #iommu-cells: When the node corresponds to a virtio-iommu device, it is
> + linked to DMA masters using the "iommus" or "iommu-map"
> + properties [1][2]. #iommu-cells specifies the size of the
> + "iommus" property. For virtio-iommu #iommu-cells must be
> + 1, each cell describing a single endpoint ID.
> +
> +Optional properties:
> +
> +- iommus: If the device accesses memory through an IOMMU, it should
> + have an "iommus" property [1]. Since virtio-iommu itself
> + does not access memory through an IOMMU, the "virtio,mmio"
> + node cannot have both an "#iommu-cells" and an "iommus"
> + property.
> +
> Example:
>
> virtio_block@3000 {
> compatible = "virtio,mmio";
> reg = <0x3000 0x100>;
> interrupts = <41>;
> +
> + /* Device has endpoint ID 23 */
> + iommus = <&viommu 23>
> }
> +
> + viommu: virtio_iommu@3100 {
> + compatible = "virtio,mmio";
> + reg = <0x3100 0x100>;
> + interrupts = <42>;
> +
> + #iommu-cells = <1>
> + }
> +
> +[1] Documentation/devicetree/bindings/iommu/iommu.txt
> +[2] Documentation/devicetree/bindings/pci/pci-iommu.txt
>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: virtio: Add virtio-pci-iommu node
From: Auger Eric @ 2018-11-15 8:45 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, virtualization, devicetree
Cc: mark.rutland, peter.maydell, lorenzo.pieralisi, tnowicki, mst,
marc.zyngier, linux-pci, will.deacon, kvmarm, robh+dt,
robin.murphy, joro
In-Reply-To: <20181012145917.6840-3-jean-philippe.brucker@arm.com>
Hi Jean,
On 10/12/18 4:59 PM, Jean-Philippe Brucker wrote:
> Some systems implement virtio-iommu as a PCI endpoint. The operating
> systems needs to discover the relationship between IOMMU and masters long
s/systems/system
> before the PCI endpoint gets probed. Add a PCI child node to describe the
> virtio-iommu device.
>
> The virtio-pci-iommu is conceptually split between a PCI programming
> interface and a translation component on the parent bus. The latter
> doesn't have a node in the device tree. The virtio-pci-iommu node
> describes both, by linking the PCI endpoint to "iommus" property of DMA
> master nodes and to "iommu-map" properties of bus nodes.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
> .../devicetree/bindings/virtio/iommu.txt | 66 +++++++++++++++++++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/virtio/iommu.txt
>
> diff --git a/Documentation/devicetree/bindings/virtio/iommu.txt b/Documentation/devicetree/bindings/virtio/iommu.txt
> new file mode 100644
> index 000000000000..2407fea0651c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/virtio/iommu.txt
> @@ -0,0 +1,66 @@
> +* virtio IOMMU PCI device
> +
> +When virtio-iommu uses the PCI transport, its programming interface is
> +discovered dynamically by the PCI probing infrastructure. However the
> +device tree statically describes the relation between IOMMU and DMA
> +masters. Therefore, the PCI root complex that hosts the virtio-iommu
> +contains a child node representing the IOMMU device explicitly.
> +
> +Required properties:
> +
> +- compatible: Should be "virtio,pci-iommu"
> +- reg: PCI address of the IOMMU. As defined in the PCI Bus
> + Binding reference [1], the reg property is a five-cell
> + address encoded as (phys.hi phys.mid phys.lo size.hi
> + size.lo). phys.hi should contain the device's BDF as
> + 0b00000000 bbbbbbbb dddddfff 00000000. The other cells
> + should be zero.
> +- #iommu-cells: Each platform DMA master managed by the IOMMU is assigned
> + an endpoint ID, described by the "iommus" property [2].
> + For virtio-iommu, #iommu-cells must be 1.
> +
> +Notes:
> +
> +- DMA from the IOMMU device isn't managed by another IOMMU. Therefore the
> + virtio-iommu node doesn't have an "iommus" property, and is omitted from
> + the iommu-map property of the root complex.
> +
> +Example:
> +
> +pcie@10000000 {
> + compatible = "pci-host-ecam-generic";
> + ...
> +
> + /* The IOMMU programming interface uses slot 00:01.0 */
> + iommu0: iommu@0008 {
> + compatible = "virtio,pci-iommu";
> + reg = <0x00000800 0 0 0 0>;
> + #iommu-cells = <1>;
> + };
> +
> + /*
> + * The IOMMU manages all functions in this PCI domain except
> + * itself. Omit BDF 00:01.0.
> + */
> + iommu-map = <0x0 &iommu0 0x0 0x8>
> + <0x9 &iommu0 0x9 0xfff7>;
> +};
> +
> +pcie@20000000 {
> + compatible = "pci-host-ecam-generic";
> + ...
> + /*
> + * The IOMMU also manages all functions from this domain,
> + * with endpoint IDs 0x10000 - 0x1ffff
> + */
> + iommu-map = <0x0 &iommu0 0x10000 0x10000>;
> +};
> +
> +ethernet@fe001000 {
> + ...
> + /* The IOMMU manages this platform device with endpoint ID 0x20000 */
> + iommus = <&iommu0 0x20000>;
> +};
> +
> +[1] Documentation/devicetree/bindings/pci/pci.txt
> +[2] Documentation/devicetree/bindings/iommu/iommu.txt
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks
Eric
>
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: jiangyiwen @ 2018-11-15 9:02 UTC (permalink / raw)
To: Jason Wang, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <015e1638-525f-7236-dbd9-38cced6b75db@redhat.com>
On 2018/11/15 16:19, Jason Wang wrote:
>
> On 2018/11/15 下午2:46, jiangyiwen wrote:
>> On 2018/11/15 12:19, Jason Wang wrote:
>>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>>> Hi Stefan, Michael, Jason and everyone,
>>>>
>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>> This idea has two advantages:
>>>> First, it can use many great features of virtio-net, like batching,
>>>> mergeable rx buffer and multiqueue, etc.
>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>> maintained.
>>>>
>>>> Before the implement, I want to discuss with everyone again, and
>>>> want to know everyone's suggestions.
>>>>
>>>> After the discussion, based on this point I will try to implement
>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>> pity. :(
>>>
>>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>>
>>>
>>>> -------------------------Simple idea------------------------------
>>>>
>>>> 1. The packet layout will become as follows:
>>>>
>>>> +---------------------------------+
>>>> | Virtio-net header |
>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>> +---------------------------------+
>>>> | Vsock header |
>>>> | (struct virtio_vsock_hdr) |
>>>> +---------------------------------+
>>>> | payload |
>>>> | (until end of packet) |
>>>> +---------------------------------+
>>>>
>>>> 2. The Guest->Host basic code flow as follow:
>>>> +------------+
>>>> | Client |
>>>> +------------+
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |VSOCK Core Module |
>>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>>> | * hdr and payload */ |
>>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>>> |vsock hdr and payload, and then call |
>>>> +------------------------------------------------------------------+
>>>
>>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>> Hi Jason,
>>
>> You mean we should not register netdev if use vsock, and in order to
>> avoid confusion, then I think whether we should keep vsock and export
>> some virtio-net's functions that can be shared. In this way, first, vsock
>> may keep existing architecture and will not affect virtio-net.
>
>
> At least it needs new feature bits which will be a functional duplication of virtio-net (e.g mrg_rxbuf).
Hi Jason,
Actually I mean only use some shared function to make vsock support these
features, in that way, guest see the device is still vsock device instead of
virtio-net device, in addition, it can have less codes and easier to be
compatible with old vsock version.
Thanks,
Yiwen.
>
>
>> In addition,
>> vsock doesn't need to use virtio_net header too, then it don't need to pack
>> skb structure.
>
>
> For mergeable rx buffer it need I think?
As said above, I will define the related structure in the virtio-vsock module.
>
>
>>
>> Thanks,
>> Yiwen.
>>
>>>
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |Virtio-net Module |
>>>> |start_xmit |
>>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>>> +------------------------------------------------------------------+
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |Vhost-net Module |
>>>> |handle_tx |
>>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>>> | * forward information, however vsock only need to notify server |
>>>> | * that data ready. */ |
>>>> +------------------------------------------------------------------+
>>>
>>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>>
>>>
>>>> |
>>>> |
>>>> +------------------------------------------------------------------+
>>>> |VSOCK Core Module |
>>>> |alloc_pkt, copy skb data to pkt. |
>>>> |add pkt to rx_queue and notify server to get data. |
>>>> +------------------------------------------------------------------+
>>>>
>>>> 3. To Host->Guest
>>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>>> because I have been doing work related with storage and file system.
>>>>
>>>> The problem as follows:
>>>> we should monitor all of socket of vsock in handle_rx, when there are
>>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>>> get data, it is different with socket. To vsock, I think host will
>>>> not call ->recvmsg when it need to send message to guest. To net,
>>>> vhost-net only as forwarding layer.
>>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>> For vsock, Host->Guest, it's code flow as follows:
>> Server call send()
>> -> sendmsg(); (vsock_stream_sendmsg)
>> -> virtio_trasnport_send_pkt_info
>> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>>
>> Vhost_worker
>> -> vhost_transport_send_pkt_work
>> -> get pkt from send_pkt_list
>> -> get vq input desc and then fill data to desc addr
>> -> update used ring and then signal guest
>>
>> In the whole process, host don't call recvmsg() because it is a net device, and
>> it also receives any messages.
>
>
> If I understand this correctly, there's no a socket object on host that represent vosck in guest? If yes, maybe we can invent one.
>
> Thanks
>
Sorry, I am not understanding you very much, vsock only a socket
channel, it does not have a network device entity, so it only
transmit the data between server and client, the data is only
saved in server and client. Instead of vhost-net, I feel it
has a network device that can saved the data, so when host
send message to guest, it can use recvmsg() from the
network device(tap). For Vsock, recvmsg() interface will
read message from tx vq.
>
>>
>> For vhost-net, I understand it is a tap device, so it can receive messages
>> from other net device.
>>
>> This is my understanding, it may have some errors.
>>
>> Thanks.
>>
>>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>>
>>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>>
>>> Thanks
>>>
>>>
>>> .
>>>
>>
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Discuss about an new idea "Vsock over Virtio-net"
From: Jason Wang @ 2018-11-15 9:21 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha, mst; +Cc: netdev, kvm, virtualization
In-Reply-To: <5BED361E.3090805@huawei.com>
On 2018/11/15 下午5:02, jiangyiwen wrote:
> On 2018/11/15 16:19, Jason Wang wrote:
>> On 2018/11/15 下午2:46, jiangyiwen wrote:
>>> On 2018/11/15 12:19, Jason Wang wrote:
>>>> On 2018/11/15 上午11:56, jiangyiwen wrote:
>>>>> Hi Stefan, Michael, Jason and everyone,
>>>>>
>>>>> Several days ago, I discussed with jason about "Vsock over Virtio-net".
>>>>> This idea has two advantages:
>>>>> First, it can use many great features of virtio-net, like batching,
>>>>> mergeable rx buffer and multiqueue, etc.
>>>>> Second, it can reduce many duplicate codes and make it easy to be
>>>>> maintained.
>>>>>
>>>>> Before the implement, I want to discuss with everyone again, and
>>>>> want to know everyone's suggestions.
>>>>>
>>>>> After the discussion, based on this point I will try to implement
>>>>> this idea, but I am not familiar with the virtio-net, that is a
>>>>> pity. :(
>>>> I think we should have a new feature flag for this. E.g VIRTIO_NET_F_VSOCK. And host should fail the negotiation if guest doesn't support this to avoid confusion. When this feature is negotiated, we will use it only for VOSCK transport. This can simplify things somehow.
>>>>
>>>>
>>>>> -------------------------Simple idea------------------------------
>>>>>
>>>>> 1. The packet layout will become as follows:
>>>>>
>>>>> +---------------------------------+
>>>>> | Virtio-net header |
>>>>> |(struct virtio_net_hdr_mrg_rxbuf)|
>>>>> +---------------------------------+
>>>>> | Vsock header |
>>>>> | (struct virtio_vsock_hdr) |
>>>>> +---------------------------------+
>>>>> | payload |
>>>>> | (until end of packet) |
>>>>> +---------------------------------+
>>>>>
>>>>> 2. The Guest->Host basic code flow as follow:
>>>>> +------------+
>>>>> | Client |
>>>>> +------------+
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |VSOCK Core Module |
>>>>> |ops->sendmsg; (vsock_stream_sendmsg) |
>>>>> | -> alloc_skb; /* it will packet a skb buffer, and include vsock |
>>>>> | * hdr and payload */ |
>>>>> | -> dev_queue_xmit(); /* it will call start_xmit(virtio-net.c) */|
>>>>> |vsock hdr and payload, and then call |
>>>>> +------------------------------------------------------------------+
>>>> Note, if we've negotiated the feature, virtio-net driver must not use register_netdev to register it to network core. This can avoid lots of confusion.
>>> Hi Jason,
>>>
>>> You mean we should not register netdev if use vsock, and in order to
>>> avoid confusion, then I think whether we should keep vsock and export
>>> some virtio-net's functions that can be shared. In this way, first, vsock
>>> may keep existing architecture and will not affect virtio-net.
>>
>> At least it needs new feature bits which will be a functional duplication of virtio-net (e.g mrg_rxbuf).
> Hi Jason,
>
> Actually I mean only use some shared function to make vsock support these
> features, in that way, guest see the device is still vsock device instead of
> virtio-net device, in addition, it can have less codes and easier to be
> compatible with old vsock version.
Yes, I think we're talking about same thing. Both of us want to share
codes. What you want is to export and share some common helpers between
virtio-net and vsock. What I meant is to e.g probe vsock device and
merge vsock specific codes into virtio-net driver. I agree it's not a
small project. We can start from e.g patches that try to share the
codes. This could also give us inspiration for how to unify them.
>
> Thanks,
> Yiwen.
>
>>
>>> In addition,
>>> vsock doesn't need to use virtio_net header too, then it don't need to pack
>>> skb structure.
>>
>> For mergeable rx buffer it need I think?
> As said above, I will define the related structure in the virtio-vsock module.
>
>>
>>> Thanks,
>>> Yiwen.
>>>
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |Virtio-net Module |
>>>>> |start_xmit |
>>>>> | -> add virtio_net_hdr and pack sg in ring desc, notify Host |
>>>>> +------------------------------------------------------------------+
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |Vhost-net Module |
>>>>> |handle_tx |
>>>>> | -> get tx buffer, skip virtio_net_hdr and call Vsock function. |
>>>>> | /* This point has some differences, vhost-net use ->sendmsg to |
>>>>> | * forward information, however vsock only need to notify server |
>>>>> | * that data ready. */ |
>>>>> +------------------------------------------------------------------+
>>>> When VIRTIO_NET_F_VOSCK is negotiated, we know that it's a vsock transport, we can then forward it to vsock core.
>>>>
>>>>
>>>>> |
>>>>> |
>>>>> +------------------------------------------------------------------+
>>>>> |VSOCK Core Module |
>>>>> |alloc_pkt, copy skb data to pkt. |
>>>>> |add pkt to rx_queue and notify server to get data. |
>>>>> +------------------------------------------------------------------+
>>>>>
>>>>> 3. To Host->Guest
>>>>> I have a problem and difficult, mainly I know about virtio-net a little),
>>>>> because I have been doing work related with storage and file system.
>>>>>
>>>>> The problem as follows:
>>>>> we should monitor all of socket of vsock in handle_rx, when there are
>>>>> data coming, and copy data to vq desc. Vhost-net use ->recvmsg to
>>>>> get data, it is different with socket. To vsock, I think host will
>>>>> not call ->recvmsg when it need to send message to guest. To net,
>>>>> vhost-net only as forwarding layer.
>>>> Know not much here, but is it possible to have a vsock(tap) to be passed to vhost_net and let vhost call its recvmgs()? Bascially it was a socket on host as well I believe?
>>> For vsock, Host->Guest, it's code flow as follows:
>>> Server call send()
>>> -> sendmsg(); (vsock_stream_sendmsg)
>>> -> virtio_trasnport_send_pkt_info
>>> -> alloc pkt, add pkt to send_pkt_list, wake up vhost_worker
>>>
>>> Vhost_worker
>>> -> vhost_transport_send_pkt_work
>>> -> get pkt from send_pkt_list
>>> -> get vq input desc and then fill data to desc addr
>>> -> update used ring and then signal guest
>>>
>>> In the whole process, host don't call recvmsg() because it is a net device, and
>>> it also receives any messages.
>>
>> If I understand this correctly, there's no a socket object on host that represent vosck in guest? If yes, maybe we can invent one.
>>
>> Thanks
>>
> Sorry, I am not understanding you very much, vsock only a socket
> channel, it does not have a network device entity, so it only
> transmit the data between server and client, the data is only
> saved in server and client. Instead of vhost-net, I feel it
> has a network device that can saved the data, so when host
> send message to guest, it can use recvmsg() from the
> network device(tap). For Vsock, recvmsg() interface will
> read message from tx vq.
So I understand the model is not a real socket pair on host which
AF_UNIX did. Maybe it's better to have one. What I meant is, have a
socket that represent for each guest vsock device on host (guest
socket). Then when you transfer packets from host to guest, you can
queue the packets into the receive queue of the guest socket and wake up
vhost-net and it will call recvmsg() for the guest socket. And when you
want to transfer packets form guest to host, vhost_net will call
sendmsg() to the guest socket on host then it can search the correct
destination and queue packet on the receive of host socket. This can
make vsock much more easier to be integrated with vhost_net.
Thanks
>
>>> For vhost-net, I understand it is a tap device, so it can receive messages
>>> from other net device.
>>>
>>> This is my understanding, it may have some errors.
>>>
>>> Thanks.
>>>
>>>> If this doesn't work, we can have vsock specific receiving routine in vhost_net if VIRTIO_NET_F_VOSCK is negotiated.
>>>>
>>>> Generally, I think we should try out best to keep the exist sendmsg()/recvmsg() interfaces and only consider the alternatives if we meet some real blocker.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> .
>>>>
>> .
>>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox