Linux virtualization list
 help / color / mirror / Atom feed
* [PATCH] virtio: console: Unlock vqs while freeing buffers
From: Matt Redfearn @ 2016-10-11 11:05 UTC (permalink / raw)
  To: Amit Shah
  Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, stable,
	virtualization, Matt Redfearn

Commit c6017e793b93 ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:

WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44

Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.

Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---

 drivers/char/virtio_console.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 5da47e26a012..4aae0d27e382 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1540,19 +1540,29 @@ static void remove_port_data(struct port *port)
 	spin_lock_irq(&port->inbuf_lock);
 	/* Remove unused data this port might have received. */
 	discard_port_data(port);
+	spin_unlock_irq(&port->inbuf_lock);
 
 	/* Remove buffers we queued up for the Host to send us data in. */
-	while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
-		free_buf(buf, true);
-	spin_unlock_irq(&port->inbuf_lock);
+	do {
+		spin_lock_irq(&port->inbuf_lock);
+		buf = virtqueue_detach_unused_buf(port->in_vq);
+		spin_unlock_irq(&port->inbuf_lock);
+		if (buf)
+			free_buf(buf, true);
+	} while (buf);
 
 	spin_lock_irq(&port->outvq_lock);
 	reclaim_consumed_buffers(port);
+	spin_unlock_irq(&port->outvq_lock);
 
 	/* Free pending buffers from the out-queue. */
-	while ((buf = virtqueue_detach_unused_buf(port->out_vq)))
-		free_buf(buf, true);
-	spin_unlock_irq(&port->outvq_lock);
+	do {
+		spin_lock_irq(&port->outvq_lock);
+		buf = virtqueue_detach_unused_buf(port->out_vq);
+		spin_unlock_irq(&port->outvq_lock);
+		if (buf)
+			free_buf(buf, true);
+	} while (buf);
 }
 
 /*
-- 
2.7.4

^ permalink raw reply related

* [PATCH] virtio: remove config.c
From: Juergen Gross @ 2016-10-11  9:02 UTC (permalink / raw)
  To: linux-kernel, virtualization; +Cc: Juergen Gross, mst

Remove unused file config.c

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/virtio/config.c | 12 ------------
 1 file changed, 12 deletions(-)
 delete mode 100644 drivers/virtio/config.c

diff --git a/drivers/virtio/config.c b/drivers/virtio/config.c
deleted file mode 100644
index f70bcd2..0000000
--- a/drivers/virtio/config.c
+++ /dev/null
@@ -1,12 +0,0 @@
-/* Configuration space parsing helpers for virtio.
- *
- * The configuration is [type][len][... len bytes ...] fields.
- *
- * Copyright 2007 Rusty Russell, IBM Corporation.
- * GPL v2 or later.
- */
-#include <linux/err.h>
-#include <linux/virtio.h>
-#include <linux/virtio_config.h>
-#include <linux/bug.h>
-
-- 
2.6.6

^ permalink raw reply related

* Re: VIRTIO_F_IOMMU_PLATFORM
From: Michael S. Tsirkin @ 2016-10-11  1:51 UTC (permalink / raw)
  To: Will Deacon; +Cc: virtualization
In-Reply-To: <20161010210411-mutt-send-email-mst@kernel.org>

On Mon, Oct 10, 2016 at 09:07:35PM +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 10, 2016 at 05:59:03PM +0100, Will Deacon wrote:
> > On Fri, Oct 07, 2016 at 07:24:34AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote:
> > > > Hi Michael,
> > > > 
> > > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"),
> > > > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether
> > > > or not a given virtio device requires physical address or bus addresses.
> > > > 
> > > > Is there a plan to get this incorporated into the virtio spec [1]? At the
> > > > moment, I can't see a working draft that includes the new bit. Having it
> > > > in the spec would help convince implementors that it's not just a Linux
> > > > thing.
> > > > 
> > > > Thanks,
> > > > 
> > > > Will
> > > > 
> > > > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html
> > > 
> > > Absolutely. Want to contribute a patch?
> > 
> > I could have a look. Is there a git repo for the sources to the working
> > draft?
> > 
> > Will
> 
> Yes, though unfortunately it's svn :(
> 
> git svn clone --stdlayout https://tools.oasis-open.org/version-control/svn/virtio
> 
> Check out the main branch.
> 
> Patches must be sent to virtio-dev or virtio-comments list (subscription
> required).
> 
> Thanks!

A faster way is to go through a git mirror. See

https://tools.oasis-open.org/version-control/svn/virtio/trunk/git-svn.txt
section named "Faster initial clone from git mirror".



> -- 
> MST

^ permalink raw reply

* Re: VIRTIO_F_IOMMU_PLATFORM
From: Michael S. Tsirkin @ 2016-10-10 18:07 UTC (permalink / raw)
  To: Will Deacon; +Cc: virtualization
In-Reply-To: <20161010165903.GH14561@arm.com>

On Mon, Oct 10, 2016 at 05:59:03PM +0100, Will Deacon wrote:
> On Fri, Oct 07, 2016 at 07:24:34AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote:
> > > Hi Michael,
> > > 
> > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"),
> > > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether
> > > or not a given virtio device requires physical address or bus addresses.
> > > 
> > > Is there a plan to get this incorporated into the virtio spec [1]? At the
> > > moment, I can't see a working draft that includes the new bit. Having it
> > > in the spec would help convince implementors that it's not just a Linux
> > > thing.
> > > 
> > > Thanks,
> > > 
> > > Will
> > > 
> > > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html
> > 
> > Absolutely. Want to contribute a patch?
> 
> I could have a look. Is there a git repo for the sources to the working
> draft?
> 
> Will

Yes, though unfortunately it's svn :(

git svn clone --stdlayout https://tools.oasis-open.org/version-control/svn/virtio

Check out the main branch.

Patches must be sent to virtio-dev or virtio-comments list (subscription
required).

Thanks!

-- 
MST

^ permalink raw reply

* Re: VIRTIO_F_IOMMU_PLATFORM
From: Will Deacon @ 2016-10-10 16:59 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: virtualization
In-Reply-To: <20161007042434.jpu7ql3djfo6o6kd@redhat.com>

On Fri, Oct 07, 2016 at 07:24:34AM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote:
> > Hi Michael,
> > 
> > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"),
> > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether
> > or not a given virtio device requires physical address or bus addresses.
> > 
> > Is there a plan to get this incorporated into the virtio spec [1]? At the
> > moment, I can't see a working draft that includes the new bit. Having it
> > in the spec would help convince implementors that it's not just a Linux
> > thing.
> > 
> > Thanks,
> > 
> > Will
> > 
> > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html
> 
> Absolutely. Want to contribute a patch?

I could have a look. Is there a git repo for the sources to the working
draft?

Will

^ permalink raw reply

* Re: virtio_blk: Rename a jump label in virtblk_get_id()
From: SF Markus Elfring @ 2016-10-10  8:18 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Julia Lawall, kernel-janitors, LKML, virtualization
In-Reply-To: <20161010022831-mutt-send-email-mst@kernel.org>

> Please don't send me such patches, I'm not really interested in renaming labels

Thanks for your feedback.


> unless it clearly adds to a significant improvement in readability.

Have you got any more concrete conditions for the selection of appropriate
identifiers in this use case according to your software development view?

Regards,
Markus

^ permalink raw reply

* Re: [PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()
From: Michael S. Tsirkin @ 2016-10-09 23:30 UTC (permalink / raw)
  To: SF Markus Elfring; +Cc: Julia Lawall, kernel-janitors, LKML, virtualization
In-Reply-To: <a303f7a6-c675-5228-99bd-a03c9e9252e9@users.sourceforge.net>

On Tue, Sep 13, 2016 at 02:15:20PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 13 Sep 2016 13:50:56 +0200
> 
> Adjust a jump label according to the current Linux coding style convention.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Please don't send me such patches, I'm not really
interested in renaming labels unless it clearly adds
to a significant improvement in readability.

> ---
>  drivers/block/virtio_blk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 696f452..fef2bd0 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -247,10 +247,10 @@ static int virtblk_get_id(struct gendisk *disk, char *id_str)
>  
>  	err = blk_rq_map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
>  	if (err)
> -		goto out;
> +		goto put_request;
>  
>  	err = blk_execute_rq(vblk->disk->queue, vblk->disk, req, false);
> -out:
> + put_request:
>  	blk_put_request(req);
>  	return err;
>  }
> -- 
> 2.10.0

^ permalink raw reply

* [PATCH] drm/virtio: kconfig: Fixup white space.
From: Peter Griffin @ 2016-10-08  7:55 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, airlied, kraxel,
	dri-devel, virtualization
  Cc: peter.griffin, lee.jones

Use tabs instead of spaces.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..81d1807 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,10 +1,10 @@
 config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
 	depends on DRM && VIRTIO
-        select DRM_KMS_HELPER
-        select DRM_TTM
+	select DRM_KMS_HELPER
+	select DRM_TTM
 	help
 	   This is the virtual GPU driver for virtio.  It can be used with
-           QEMU based VMMs (like KVM or Xen).
+	   QEMU based VMMs (like KVM or Xen).
 
 	   If unsure say M.
-- 
1.9.1

^ permalink raw reply related

* CFP - WorldCIST'2017 - 5th World Conference on Information Systems and Technologies (Published by Springer)
From: ML @ 2016-10-07 18:00 UTC (permalink / raw)
  To: virtualization

[-- Attachment #1: Type: text/plain, Size: 8030 bytes --]

Please disseminate by your contacts. Thank you!

*Best papers published in more than twenty SCI/SSCI-indexed journals
---------------------------------------------------------------------------
WorldCIST'17 - 5th World Conference on Information Systems and Technologies 
Porto Santo Island, Madeira, Portugal
11th-13th of April 2017
http://www.worldcist.org/
--------------------------------------------------------------------


SCOPE

The WorldCist'17 - 5th World Conference on Information Systems and Technologies, to be held at Porto Santo Island, Madeira, Portugal, 11 - 13 April 2017, 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'17 (http://www.worldcist.org/). 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).


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 or download a DOC example) 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 Publication form 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 & INDEXING

To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 8th of January 2017, 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 in the Conference Proceedings. 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 Series. Poster and company papers will be published by AISTI.

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 (IF: 6.085 / Q1)
- Integrated Computer-Aided Engineering (IF: 4.981 / Q1)
- International Journal of Information Management (IF: 2.692 / Q1)
- Electronic Commerce Research and Applications (IF: 2.139 / Q1)
- Computers, Environment and Urban Systems (IF: 2.092 / Q1)
- Data Mining and Knowledge Discovery (IF: 1.759 / Q1)
- Journal of Medical Systems (IF: 2.213 / Q2)
- Journal of Business Research (IF: 2.129 / Q2)
- Pervasive and Mobile Computing (IF: 1.719 / Q2)
- Knowledge and Information Systems (IF: 1.702 / Q2)
- Journal of Grid Computing (IF: 1.561 / Q2) - Special Issue on "Big Data"
- Cluster Computing (IF:1.514 / Q2) - Special Issue on "Advanced Machine Learning in Parallel and Distributed Knowledge Discovery"
- International Journal of Critical Infrastructure Protection (IF: 1.351 / Q2)
- Expert Systems - Journal of Knowledge Engineering (IF: 0.947 / Q3)
- Concurrency and Computation: Practice and Experience (IF: 0.942 / Q3)
- Science of Computer Programming (IF: 0.828 / Q3)
- Ethics and Information Technology (IF: 0.739 / Q3)
- Annals of Telecommunications (IF: 0.722 / Q3)
- Engineering Computations (IF: 0.691 / Q3)
- Advances in Complex Systems (IF: 0.461 / Q3)
- Computing and Informatics (IF: 0.504 / Q4)
- AI Communications (IF: 0.364 / Q4)
- Journal of Hospitality and Tourism Technology (SR: 0.672 / Q2)
- Transforming Government: People, Process and Policy (SR: 0.642 / Q2)
- TEM Journal - Technology, Education, Management, Informatics (ISI - Emerging Sources Citation Index)
- Computer Methods in Biomechanics and Biomedical Engineering - Imaging & Visualization (ISI - Emerging Sources Citation Index)
- Journal of Information Systems Engineering & Management


IMPORTANT DATES

Paper Submission: November 13, 2016

Notification of Acceptance: December 25, 20156

Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 8, 2017.

Camera-ready Submission: January 8, 2017


-

Website of WorldCIST'17
http://www.worldcist.org/


-

Best regards,

AISTI
http://www.aisti.eu/


----
PS: If you do not wish to receive any more notices from AISTI (http://www.aisti.eu) just reply to this message with the word REMOVE in the subject line.





[-- 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 v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
  To: Emil Velikov
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
	ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
	Lee Jones, open list:VIRTIO GPU DRIVER
In-Reply-To: <CACvgo50vU5_=KFUCAZDaQPepPdsbnF8KN1b+f6KJNuBW6qRdSg@mail.gmail.com>

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:

> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio _bus_"
> 

Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.

> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.

Yep OK.

> 
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?

Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 

> 
> This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
> mean there is anything wrong with your feet."

If the shoe doesn't fit, chop off the leg :)

> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 

If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

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

^ permalink raw reply

* Re: VIRTIO_F_IOMMU_PLATFORM
From: Michael S. Tsirkin @ 2016-10-07  4:24 UTC (permalink / raw)
  To: Will Deacon; +Cc: virtualization
In-Reply-To: <20160927085713.GB3489@arm.com>

On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote:
> Hi Michael,
> 
> In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"),
> you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether
> or not a given virtio device requires physical address or bus addresses.
> 
> Is there a plan to get this incorporated into the virtio spec [1]? At the
> moment, I can't see a working draft that includes the new bit. Having it
> in the spec would help convince implementors that it's not just a Linux
> thing.
> 
> Thanks,
> 
> Will
> 
> [1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html

Absolutely. Want to contribute a patch?

-- 
MST

^ permalink raw reply

* [PATCH] VMCI: Doorbell create and destroy fixes
From: Jorgen Hansen @ 2016-10-06 11:43 UTC (permalink / raw)
  To: linux-kernel, virtualization; +Cc: pv-drivers, gregkh, Jorgen Hansen

This change consists of two changes:

1) If vmci_doorbell_create is called when neither guest nor
   host personality as been initialized, vmci_get_context_id
   will return VMCI_INVALID_ID. In that case, we should fail
   the create call.
2) In doorbell destroy, we assume that vmci_guest_code_active()
   has the same return value on create and destroy. That may not
   be the case, so we may end up with the wrong refcount.
   Instead, destroy should check explicitly whether the doorbell
   is in the index table as an indicator of whether the guest
   code was active at create time.

Reviewed-by: Adit Ranadive <aditr@vmware.com>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
---
 drivers/misc/vmw_vmci/vmci_doorbell.c |    8 +++++++-
 drivers/misc/vmw_vmci/vmci_driver.c   |    2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/vmw_vmci/vmci_doorbell.c b/drivers/misc/vmw_vmci/vmci_doorbell.c
index a8cee33..b3fa738 100644
--- a/drivers/misc/vmw_vmci/vmci_doorbell.c
+++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
@@ -431,6 +431,12 @@ int vmci_doorbell_create(struct vmci_handle *handle,
 	if (vmci_handle_is_invalid(*handle)) {
 		u32 context_id = vmci_get_context_id();
 
+		if (context_id == VMCI_INVALID_ID) {
+			pr_warn("Failed to get context ID\n");
+			result = VMCI_ERROR_NO_RESOURCES;
+			goto free_mem;
+		}
+
 		/* Let resource code allocate a free ID for us */
 		new_handle = vmci_make_handle(context_id, VMCI_INVALID_ID);
 	} else {
@@ -525,7 +531,7 @@ int vmci_doorbell_destroy(struct vmci_handle handle)
 
 	entry = container_of(resource, struct dbell_entry, resource);
 
-	if (vmci_guest_code_active()) {
+	if (!hlist_unhashed(&entry->node)) {
 		int result;
 
 		dbell_index_table_remove(entry);
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c
index 896be15..d7eaf1e 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
-MODULE_VERSION("1.1.4.0-k");
+MODULE_VERSION("1.1.5.0-k");
 MODULE_LICENSE("GPL v2");
-- 
1.7.0

^ permalink raw reply related

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, Lee Jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
	dan.j.williams, Bjorn Andersson, open list:VIRTIO GPU DRIVER,
	LAKML
In-Reply-To: <20161006104807.GB436@griffinp-ThinkPad-X1-Carbon-2nd>

Hi Peter,

On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?

>>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>> >
>> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
>> > mfd subsystem, client drivers select MFD_CORE.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
>> > recently, maybe he has some thoughts on whether this is the correct fix or not?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:

Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.

If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)

In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.

Thanks
Emil

^ permalink raw reply

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
  To: Emil Velikov
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, lee.jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
	dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
	LAKML
In-Reply-To: <CACvgo53fuoPVjBAkZbWFPVxosObjvxoDgFdR_BkSTgevqyGg9g@mail.gmail.com>

Hi Emil,

On Wed, 21 Sep 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.

VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.

> 
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.

Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.

I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?

It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.

Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced. 

regards,

Peter.

^ permalink raw reply

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
	ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
	Lee Jones, open list:VIRTIO GPU DRIVER
In-Reply-To: <20161006093721.GA436@griffinp-ThinkPad-X1-Carbon-2nd>

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

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

^ permalink raw reply

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	Linux-Kernel@Vger. Kernel. Org, ML dri-devel, patrice.chotard,
	Peter Griffin, David Airlie, dmaengine, dan.j.williams,
	open list:VIRTIO GPU DRIVER, Lee Jones, LAKML
In-Reply-To: <20160927170115.GD7509@tuxbot>

Hi Bjorn,

On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>>
>
> The general idea here is that VIRTIO provides the "framework" and as
> such drivers implementing VIRTIO do select and drivers using virtio use
> depends.
>
> This is found in several places around the kernel.
>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>
> There's nothing unusual in remoteproc that forces us to stay with this
> model; however the parts related to the REMOTEPROC config is useless by
> themselves.
>
I'm afraid that the "supporting" arguments you're using are generic
and not specific to remoteproc. Although as Jani mentioned and pointed
to the documentation, remoteproc is {mis,ab}using 'select' leading to
issues elsewhere.

In the long term we might want to switch to 'select' and attribute
kconfig like Jani suggested.  But in the short term we want to avoid
select-ing things just for our "convenience".

Thanks
Emil

^ permalink raw reply

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Peter Griffin @ 2016-10-06  9:37 UTC (permalink / raw)
  To: Jani Nikula
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	Emil Velikov, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, dmaengine, dan.j.williams,
	bjorn.andersson, lee.jones, open list:VIRTIO GPU DRIVER, LAKML
In-Reply-To: <8760pqncee.fsf@intel.com>

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.

Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)

I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.

That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

^ permalink raw reply

* Re: [PATCH v3 0/4] implement vcpu preempted check
From: Christian Borntraeger @ 2016-10-05 11:00 UTC (permalink / raw)
  To: Pan Xinhui, linux-kernel, linuxppc-dev, virtualization,
	linux-s390, xen-devel-request, kvm
  Cc: kernellwp, jgross, peterz, benh, will.deacon, mingo, paulus, mpe,
	pbonzini, paulmck
In-Reply-To: <1469101514-49475-1-git-send-email-xinhui.pan@linux.vnet.ibm.com>

On 07/21/2016 01:45 PM, Pan Xinhui wrote:
> change from v2:
> 	no code change, fix typos, update some comments
> 
> change from v1:
> 	a simplier definition of default vcpu_is_preempted
> 	skip mahcine type check on ppc, and add config. remove dedicated macro.
> 	add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. 
> 	add more comments
> 	thanks boqun and Peter's suggestion.
> 
> This patch set aims to fix lock holder preemption issues.
> 
> test-case:
> perf record -a perf bench sched messaging -g 400 -p && perf report
> 
> before patch:
> 18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
> 12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
>  5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>  3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
>  3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>  3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
>  2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call
> 
> after patch:
>  9.99%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>  5.28%  sched-messaging  [unknown]         [H] 0xc0000000000768e0
>  4.27%  sched-messaging  [kernel.vmlinux]  [k] __copy_tofrom_user_power7
>  3.77%  sched-messaging  [kernel.vmlinux]  [k] copypage_power7
>  3.24%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>  3.02%  sched-messaging  [kernel.vmlinux]  [k] system_call
>  2.69%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
> 
> We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin
> loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
> These spin_on_onwer variant also cause rcu stall before we apply this patch set
> 
> Pan Xinhui (4):
>   kernel/sched: introduce vcpu preempted check interface
>   powerpc/spinlock: support vcpu preempted check
>   locking/osq: Drop the overhead of osq_lock()
>   kernel/locking: Drop the overhead of {mutex,rwsem}_spin_on_owner
> 
>  arch/powerpc/include/asm/spinlock.h | 18 ++++++++++++++++++
>  include/linux/sched.h               | 12 ++++++++++++
>  kernel/locking/mutex.c              | 15 +++++++++++++--
>  kernel/locking/osq_lock.c           | 10 +++++++++-
>  kernel/locking/rwsem-xadd.c         | 16 +++++++++++++---
>  5 files changed, 65 insertions(+), 6 deletions(-)
> 

Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
for the full series. With my patch on top this really improves
some benchmarks for overcommitted KVM guests.

^ permalink raw reply

* [PATCH] x86/vmware: Skip lapic calibration on VMware.
From: Renat Valiullin @ 2016-10-04 20:11 UTC (permalink / raw)
  To: Alok Kataria, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
	virtualization, linux-kernel

In virtualized environment the APIC timer calibration could go wrong
when the host is overcommitted or the guest is running nested,
this would result in the APIC timers operating at an incorrect frequency.
Since VMware supports a mechanism to retrieve the local APIC frequency
we can ask the hypervisor for it and skip this APIC calibration loop.

Signed-off-by: Renat Valiullin <rvaliullin@vmware.com>
Acked-by: Alok N Kataria <akataria@vmware.com>
---
 arch/x86/kernel/cpu/vmware.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 1ff0598..8116057 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -27,6 +27,7 @@
 #include <asm/div64.h>
 #include <asm/x86_init.h>
 #include <asm/hypervisor.h>
+#include <asm/apic.h>
 
 #define CPUID_VMWARE_INFO_LEAF	0x40000000
 #define VMWARE_HYPERVISOR_MAGIC	0x564D5868
@@ -82,10 +83,17 @@ static void __init vmware_platform_setup(void)
 
 	VMWARE_PORT(GETHZ, eax, ebx, ecx, edx);
 
-	if (ebx != UINT_MAX)
+	if (ebx != UINT_MAX) {
 		x86_platform.calibrate_tsc = vmware_get_tsc_khz;
-	else
+#ifdef CONFIG_X86_LOCAL_APIC
+		/* Skip lapic calibration since we know the bus frequency. */
+		lapic_timer_frequency = ecx / HZ;
+		pr_info("Host bus clock speed read from hypervisor : %u Hz\n",
+			ecx);
+#endif
+	} else {
 		pr_warn("Failed to get TSC freq from the hypervisor\n");
+	}
 }
 
 /*
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH v2 1/1] virtio: update balloon size in balloon "probe"
From: Konstantin Neumoin @ 2016-10-04 10:47 UTC (permalink / raw)
  To: virtualization, linux-kernel; +Cc: Denis V. Lunev, Michael S . Tsirkin
In-Reply-To: <1475144232-10579-1-git-send-email-den@openvz.org>

ping

On 09/29/2016 01:17 PM, Denis V. Lunev wrote:
> From: Konstantin Neumoin <kneumoin@virtuozzo.com>
>
> The following commit 'fad7b7b27b6a (virtio_balloon: Use a workqueue
> instead of "vballoon" kthread)' has added a regression. Original code with
> kthread starts the thread inside probe and checks the necessity to update
> balloon inside the thread immediately.
>
> Nowadays the code behaves differently. Work is queued only on the first
> command from the host after the negotiation. Thus there is a window
> especially at the guest startup or the module reloading when the balloon
> size is not updated until the notification from the host.
>
> This patch adds balloon size check at the end of the probe to match
> original behaviour.
>
> Signed-off-by: Konstantin Neumoin <kneumoin@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Michael S. Tsirkin <mst@redhat.com>
> ---
>   drivers/virtio/virtio_balloon.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> Changes from v1:
> - fixed description
> - removed update_balloon_size() call
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 4e7003d..181793f 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -577,6 +577,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
>   
>   	virtio_device_ready(vdev);
>   
> +	if (towards_target(vb))
> +		virtballoon_changed(vdev);
>   	return 0;
>   
>   out_del_vqs:

^ permalink raw reply

* Re: [PATCH v2 1/1] s390/spinlock: Provide vcpu_is_preempted
From: Christian Borntraeger @ 2016-10-04 10:17 UTC (permalink / raw)
  To: Pan Xinhui, Boqun Feng
  Cc: kernellwp, linux-s390, benh, jgross, kvm, Peter Zijlstra,
	Pan Xinhui, Heiko Carstens, linux-kernel, will.deacon,
	virtualization, mingo, paulus, mpe, xen-devel-request,
	Martin Schwidefsky, pbonzini, paulmck
In-Reply-To: <99d81ce9-8362-1b6b-15e1-e451ed379d50@linux.vnet.ibm.com>

On 09/30/2016 08:35 AM, Pan Xinhui wrote:
> 
> 
> 在 2016/9/30 13:52, Boqun Feng 写道:
>> On Fri, Sep 30, 2016 at 12:49:52PM +0800, Pan Xinhui wrote:
>>>
>>>
>>> 在 2016/9/29 23:51, Christian Borntraeger 写道:
>>>> this implements the s390 backend for commit
>>>> "kernel/sched: introduce vcpu preempted check interface"
>>>> by reworking the existing smp_vcpu_scheduled into
>>>> arch_vcpu_is_preempted. We can then also get rid of the
>>>> local cpu_is_preempted function by moving the
>>>> CIF_ENABLED_WAIT test into arch_vcpu_is_preempted.
>>>>
>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> ---
>>>
>>> hi, Christian
>>>     thanks for your patch!
>>>
>>>>  arch/s390/include/asm/spinlock.h |  3 +++
>>>>  arch/s390/kernel/smp.c           |  9 +++++++--
>>>>  arch/s390/lib/spinlock.c         | 25 ++++++++-----------------
>>>>  3 files changed, 18 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/arch/s390/include/asm/spinlock.h b/arch/s390/include/asm/spinlock.h
>>>> index 63ebf37..e16e02f 100644
>>>> --- a/arch/s390/include/asm/spinlock.h
>>>> +++ b/arch/s390/include/asm/spinlock.h
>>>> @@ -21,6 +21,9 @@ _raw_compare_and_swap(unsigned int *lock, unsigned int old, unsigned int new)
>>>>      return __sync_bool_compare_and_swap(lock, old, new);
>>>>  }
>>>>
>>>> +bool arch_vcpu_is_preempted(int cpu);
>>>> +#define vcpu_is_preempted arch_vcpu_is_preempted
>>>> +
>>>>  /*
>>>>   * Simple spin lock operations.  There are two variants, one clears IRQ's
>>>>   * on the local processor, one does not.
>>>> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
>>>> index 7b89a75..4aadd16 100644
>>>> --- a/arch/s390/kernel/smp.c
>>>> +++ b/arch/s390/kernel/smp.c
>>>> @@ -376,10 +376,15 @@ int smp_find_processor_id(u16 address)
>>>>      return -1;
>>>>  }
>>>>
>>>> -int smp_vcpu_scheduled(int cpu)
>>> root@ltcalpine2-lp13:~/linux# git grep -wn smp_vcpu_scheduled arch/s390/
>>> arch/s390/include/asm/smp.h:34:extern int smp_vcpu_scheduled(int cpu);
>>> arch/s390/include/asm/smp.h:56:static inline int smp_vcpu_scheduled(int cpu) { return 1; }
>>> arch/s390/kernel/smp.c:371:int smp_vcpu_scheduled(int cpu)
>>> arch/s390/lib/spinlock.c:44:    if (smp_vcpu_scheduled(cpu))
>>>
>>>> +bool arch_vcpu_is_preempted(int cpu)
>>>>  {
>>>> -    return pcpu_running(pcpu_devices + cpu);
>>>> +    if (test_cpu_flag_of(CIF_ENABLED_WAIT, cpu))
>>>> +        return false;
>>>> +    if (pcpu_running(pcpu_devices + cpu))
>>>> +        return false;
>>> I saw smp_vcpu_scheduled() returns true always on !SMP system.
>>>
>>> maybe we can do somegthing silimar. like below
>>>
>>> #ifndef CONFIG_SMP
>>> static inline bool arch_vcpu_is_preempted(int cpu) { return !test_cpu_flag_of(CIF_ENABLED_WAIT, cpu); }
>>> #else
>>> ...
>>>
>>> but I can't help thinking that if this is a!SMP system, maybe we could only
>>> #ifndef CONFIG_SMP
>>> static inline bool arch_vcpu_is_preempted(int cpu) { return false; }
>>> #else
>>
>> Why do we need a vcpu_is_preempted() implementation for UP? Where will
>> you use it?
>>
> yep, I also wonder that :)
> 
> But there is a definitaion of smp_vcpu_scheduled() for !SMP kernel.
> So I am a little worried that some code has included this spinlock.h for UP kernel also.
> 
> Hi, Christian
>     Could you help confirms that your patch works on UP? :)

My patch as is seems to work fine for !SMP. So it looks like the extra define
is not necessary and we could simply go with v2




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

^ permalink raw reply

* Re: virtio_blk: Rename a jump label in virtblk_get_id()
From: SF Markus Elfring @ 2016-10-03 12:12 UTC (permalink / raw)
  To: Stefan Hajnoczi
  Cc: Julia Lawall, Michael S. Tsirkin, kernel-janitors, LKML,
	Linux Virtualization
In-Reply-To: <CAJSP0QV2WUJPqeiSKcWiXWk+AoJ2MGo2zG4=JQ2tfpTprAyV=g@mail.gmail.com>

>> Adjust a jump label according to the current Linux coding style convention.
> 
> I think you mean "goto label".  "Jump label" has a different meaning,
> see <linux/jump_label.h>.

Does a "goto" statement jump to the code position finally
which is specified by the label?


>> @@ -247,10 +247,10 @@ static int virtblk_get_id(struct gendisk *disk, char *id_str)
>>
>>         err = blk_rq_map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
>>         if (err)
>> -               goto out;
>> +               goto put_request;
>>
>>         err = blk_execute_rq(vblk->disk->queue, vblk->disk, req, false);
>> -out:
>> + put_request:
> 
> I checked Documentation/CodingStyle and see no reason to rename the label.

Can the suggested longer identifier explain better the "what" and "why"
for this software situation?


> It's also not clear why you added a space.  The CodingStyle example
> does not use a space before the label.

Do you find information from a commit like "docs: Remove space-before-label guidance
from CodingStyle" (from 2016-09-21) interesting?   ;-)
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=79c70c304b0b443429b2a0019518532c5162817a

Regards,
Markus

^ permalink raw reply

* Re: virtio_blk: Clarification for communication difficulties?
From: SF Markus Elfring @ 2016-10-03 12:00 UTC (permalink / raw)
  To: Stefan Hajnoczi
  Cc: Michael S. Tsirkin, Chao Fan, kernel-janitors, LKML,
	Linux Virtualization, Julia Lawall, Minfei Huang, Stefan Hajnoczi
In-Reply-To: <CAJSP0QV_V-aEvdE76PnOH6TNJPJCuf+6N7SkySDAnrhbNNhv3w@mail.gmail.com>

>> I hope that our collaboration potential can be still constructive, can't it?
> 
> I can understand why others are fed up with this discussion.

Thanks for another feedback.


> Your communication style is exhausting

How did you get this impression?


> and you've pushed into the territory where any benefits of taking

Would you dare to acknowledge benefits from my update suggestions
for any other software components?


> the patches are not worth the time and hassle of dealing with you.

How are the chances that such a conclusion will change?


> I left Reviewed-bys on two patches.

Thanks for your constructive responses.


> Maybe they will get picked up.

I am also curious on how the software evolution will be continued.


> But please think again about what Christian explained.  Reviewers and
> maintainers spend time on your patches so make it worth their while.

I risk something just by proposing so many software updates for places
where change opportunities were found by special source code search patterns.

Regards,
Markus

^ permalink raw reply

* Re: virtio_blk: Clarification for communication difficulties?
From: Stefan Hajnoczi @ 2016-10-03  9:20 UTC (permalink / raw)
  To: SF Markus Elfring
  Cc: Michael S. Tsirkin, Chao Fan, kernel-janitors, LKML,
	Linux Virtualization, Julia Lawall, Minfei Huang, Stefan Hajnoczi
In-Reply-To: <a1642c2a-c013-2dec-29fb-1748a52e1c24@users.sourceforge.net>

On Wed, Sep 14, 2016 at 10:09 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
>> FWIW, he already gained a place on my ignore list for pestering me
>> offline about his patches and not stopping even when told to do so.
>
> How did I "pester" you "offline"?
>
>
>> So while I won't object if you choose to apply selected patches,
>
> Another bit of interesting information, isn't it?
>
>
>> I won't comment on any and won't take any (hey, I even won't see
>> them unless someone else replies...)
>
> I find this reaction strange. - I hope that our collaboration potential
> can be still constructive, can't it?

I can understand why others are fed up with this discussion.  Your
communication style is exhausting and you've pushed into the territory
where any benefits of taking the patches are not worth the time and
hassle of dealing with you.

I left Reviewed-bys on two patches.  Maybe they will get picked up.
But please think again about what Christian explained.  Reviewers and
maintainers spend time on your patches so make it worth their while.

Stefan

^ permalink raw reply

* Re: [PATCH 1/4] virtio_blk: Use kmalloc_array() in init_vq()
From: Stefan Hajnoczi @ 2016-10-03  9:11 UTC (permalink / raw)
  To: SF Markus Elfring
  Cc: Julia Lawall, Michael S. Tsirkin, kernel-janitors, LKML,
	Linux Virtualization
In-Reply-To: <7a8dd874-3700-1445-2143-2a604cd043ab@users.sourceforge.net>

On Tue, Sep 13, 2016 at 1:12 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 13 Sep 2016 11:32:22 +0200
>
> Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.
> Thus use the corresponding function "kmalloc_array".
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/block/virtio_blk.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox