* Re: [PATCH] VSOCK: Don't call vsock_stream_has_data in atomic context
From: Stefan Hajnoczi @ 2017-11-23 10:02 UTC (permalink / raw)
To: Jorgen Hansen
Cc: pv-drivers, netdev, linux-kernel, Linux Virtualization,
Greg Kroah-Hartman, David Miller
In-Reply-To: <1511261184-45913-1-git-send-email-jhansen@vmware.com>
On Tue, Nov 21, 2017 at 10:46 AM, Jorgen Hansen <jhansen@vmware.com> wrote:
> When using the host personality, VMCI will grab a mutex for any
> queue pair access. In the detach callback for the vmci vsock
> transport, we call vsock_stream_has_data while holding a spinlock,
> and vsock_stream_has_data will access a queue pair.
>
> To avoid this, we can simply omit calling vsock_stream_has_data
> for host side queue pairs, since the QPs are empty per default
> when the guest has detached.
>
> This bug affects users of VMware Workstation using kernel version
> 4.4 and later.
>
> Testing: Ran vsock tests between guest and host, and verified that
> with this change, the host isn't calling vsock_stream_has_data
> during detach. Ran mixedTest between guest and host using both
> guest and host as server.
>
> Reviewed-by: Adit Ranadive <aditr@vmware.com>
> Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
> ---
> net/vmw_vsock/vmci_transport.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)
From: Christoph Hellwig @ 2017-11-23 14:02 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Jens Axboe, mst@redhat.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, Bart Van Assche, Christoph Hellwig
In-Reply-To: <1aeecf2e-a68e-4c18-5912-2473f457e6ea@de.ibm.com>
I can't reproduce it in my VM with adding a new CPU. Do you have
any interesting blk-mq like actually using multiple queues? I'll
give that a spin next.
^ permalink raw reply
* Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)
From: Christoph Hellwig @ 2017-11-23 14:08 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Jens Axboe, mst@redhat.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, Bart Van Assche, Christoph Hellwig
In-Reply-To: <20171123140208.GA28914@lst.de>
Ok, it helps to make sure we're actually doing I/O from the CPU,
I've reproduced it now.
^ permalink raw reply
* Re: [PATCH] VSOCK: Don't call vsock_stream_has_data in atomic context
From: David Miller @ 2017-11-23 16:29 UTC (permalink / raw)
To: jhansen; +Cc: pv-drivers, netdev, gregkh, linux-kernel, virtualization
In-Reply-To: <1511261184-45913-1-git-send-email-jhansen@vmware.com>
From: Jorgen Hansen <jhansen@vmware.com>
Date: Tue, 21 Nov 2017 02:46:24 -0800
> When using the host personality, VMCI will grab a mutex for any
> queue pair access. In the detach callback for the vmci vsock
> transport, we call vsock_stream_has_data while holding a spinlock,
> and vsock_stream_has_data will access a queue pair.
>
> To avoid this, we can simply omit calling vsock_stream_has_data
> for host side queue pairs, since the QPs are empty per default
> when the guest has detached.
>
> This bug affects users of VMware Workstation using kernel version
> 4.4 and later.
>
> Testing: Ran vsock tests between guest and host, and verified that
> with this change, the host isn't calling vsock_stream_has_data
> during detach. Ran mixedTest between guest and host using both
> guest and host as server.
>
> Reviewed-by: Adit Ranadive <aditr@vmware.com>
> Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
This doesn't apply cleanly to the current 'net' GIT tree.
^ permalink raw reply
* CFP ICETE 2018 - 15th Int.l Joint Conf. on e-Business and Telecommunications (Porto/Portugal)
From: icete @ 2017-11-23 18:03 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
15th International Joint Conference on e-Business and Telecommunications
Submission Deadline: March 13, 2018
http://www.icete.org/
July 26 - 28, 2018
Porto, Portugal.
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
ICETE Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.icete.org/
e-mail: icete.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP DCNET 2018 - 9th Int.l Conf. on Data Communication Networking (Porto/Portugal)
From: icete @ 2017-11-23 18:03 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
9th International Conference on Data Communication Networking
Submission Deadline: March 13, 2018
http://www.dcnet.icete.org/
July 26 - 28, 2018
Porto, Portugal.
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
DCNET Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.dcnet.icete.org/
e-mail: dcnet.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP SECRYPT 2018 - 15th Int.l Conf. on Security and Cryptography (Porto/Portugal)
From: icete @ 2017-11-23 18:04 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
15th International Conference on Security and Cryptography
Submission Deadline: March 13, 2018
http://www.secrypt.icete.org/
July 26 - 28, 2018
Porto, Portugal.
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
SECRYPT Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.secrypt.icete.org/
e-mail: secrypt.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* CFP WINSYS 2018 - 15th Int.l Conf. on Wireless Networks and Mobile Systems (Porto/Portugal)
From: icete @ 2017-11-23 18:04 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
15th International Conference on Wireless Networks and Mobile Systems
Submission Deadline: March 13, 2018
http://www.winsys.icete.org/
July 26 - 28, 2018
Porto, Portugal.
WINSYS is organized in 3 major tracks:
- Sensor Networks and Ad Hoc Communications
- Wireless and Mobile Technologies
- Mobile Software and Services
A short list of presented papers will be selected so that revised and extended versions of these papers will be published by Springer.
All papers presented at the congress venue will also be available at the SCITEPRESS Digital Library (http://www.scitepress.org/DigitalLibrary/).
Should you have any question please don’t hesitate contacting me.
Kind regards,
WINSYS Secretariat
Address: Av. D. Manuel I, 27A, 2º esq.
2910-595 Setubal, Portugal
Tel: +351 265 520 185
Fax: +351 265 520 186
Web: http://www.winsys.icete.org/
e-mail: winsys.secretariat@insticc.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH v2] VSOCK: Don't call vsock_stream_has_data in atomic context
From: Jorgen Hansen @ 2017-11-24 14:25 UTC (permalink / raw)
To: netdev, linux-kernel, virtualization
Cc: pv-drivers, gregkh, davem, Jorgen Hansen
When using the host personality, VMCI will grab a mutex for any
queue pair access. In the detach callback for the vmci vsock
transport, we call vsock_stream_has_data while holding a spinlock,
and vsock_stream_has_data will access a queue pair.
To avoid this, we can simply omit calling vsock_stream_has_data
for host side queue pairs, since the QPs are empty per default
when the guest has detached.
This bug affects users of VMware Workstation using kernel version
4.4 and later.
Testing: Ran vsock tests between guest and host, and verified that
with this change, the host isn't calling vsock_stream_has_data
during detach. Ran mixedTest between guest and host using both
guest and host as server.
v2: Rebased on top of recent change to sk_state values
Reviewed-by: Adit Ranadive <aditr@vmware.com>
Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
---
net/vmw_vsock/vmci_transport.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 391775e..56573dc 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -797,9 +797,13 @@ static void vmci_transport_handle_detach(struct sock *sk)
/* We should not be sending anymore since the peer won't be
* there to receive, but we can still receive if there is data
- * left in our consume queue.
+ * left in our consume queue. If the local endpoint is a host,
+ * we can't call vsock_stream_has_data, since that may block,
+ * but a host endpoint can't read data once the VM has
+ * detached, so there is no available data in that case.
*/
- if (vsock_stream_has_data(vsk) <= 0) {
+ if (vsk->local_addr.svm_cid == VMADDR_CID_HOST ||
+ vsock_stream_has_data(vsk) <= 0) {
sk->sk_state = TCP_CLOSE;
if (sk->sk_state == TCP_SYN_SENT) {
@@ -2144,7 +2148,7 @@ static void __exit vmci_transport_exit(void)
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMCI transport for Virtual Sockets");
-MODULE_VERSION("1.0.4.0-k");
+MODULE_VERSION("1.0.5.0-k");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("vmware_vsock");
MODULE_ALIAS_NETPROTO(PF_VSOCK);
--
1.7.0
^ permalink raw reply related
* [PATCH 00/13] remove_conflicting_framebuffers() cleanup
From: Michał Mirosław @ 2017-11-24 17:53 UTC (permalink / raw)
To: dri-devel
Cc: linux-tegra, Teddy Wang, Sudip Mukherjee, David Airlie,
Bartlomiej Zolnierkiewicz, amd-gfx, virtualization, Eric Anholt,
Chen-Yu Tsai, Thierry Reding, Alex Deucher, Maxime Ripard,
Jonathan Hunter
This series cleans up duplicated code for replacing firmware FB
driver with proper DRI driver and adds handover support to
Tegra driver.
The last patch is here because it uses new semantics of
remove_conflicting_framebuffers() from this series. This
can be considered independently, though.
---
Michał Mirosław (13):
fbdev: show fbdev number for debugging
fbdev: add remove_conflicting_pci_framebuffers()
drm/amdgpu: use simpler remove_conflicting_pci_framebuffers()
drm/bochs: use simpler remove_conflicting_pci_framebuffers()
drm/cirrus: use simpler remove_conflicting_pci_framebuffers()
drm/mgag200: use simpler remove_conflicting_pci_framebuffers()
drm/radeon: use simpler remove_conflicting_pci_framebuffers()
drm/virtio: use simpler remove_conflicting_pci_framebuffers()
staging: sm750fb: use simpler remove_conflicting_pci_framebuffers()
fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
drm/vc4: use simpler remove_conflicting_framebuffers(NULL)
drm/sun4i: use simpler remove_conflicting_framebuffers(NULL)
drm/tegra: kick out simplefb
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 +-----------------
drivers/gpu/drm/bochs/bochs_drv.c | 18 +-------------
drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +-----------------
drivers/gpu/drm/mgag200/mgag200_drv.c | 21 +----------------
drivers/gpu/drm/mgag200/mgag200_main.c | 9 -------
drivers/gpu/drm/radeon/radeon_drv.c | 23 +-----------------
drivers/gpu/drm/sun4i/sun4i_drv.c | 18 +-------------
drivers/gpu/drm/tegra/drm.c | 4 ++++
drivers/gpu/drm/vc4/vc4_drv.c | 20 +---------------
drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +++----------------
drivers/staging/sm750fb/sm750.c | 22 +-----------------
drivers/video/fbdev/core/fbmem.c | 40 ++++++++++++++++++++++++++++++--
include/drm/drm_fb_helper.h | 12 ++++++++++
include/linux/fb.h | 2 ++
14 files changed, 67 insertions(+), 192 deletions(-)
--
2.11.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Michał Mirosław @ 2017-11-24 17:53 UTC (permalink / raw)
To: dri-devel
Cc: Teddy Wang, Sudip Mukherjee, David Airlie, amd-gfx,
virtualization, Alex Deucher
In-Reply-To: <cover.1511544782.git.mirq-linux@rere.qmqm.pl>
Almost all drivers using remove_conflicting_framebuffers() wrap it with
the same code. Extract common part from PCI drivers into separate
remove_conflicting_pci_framebuffers().
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/video/fbdev/core/fbmem.c | 22 ++++++++++++++++++++++
include/drm/drm_fb_helper.h | 12 ++++++++++++
include/linux/fb.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 30a18d4c9de4..5ea980e5d3b7 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -34,6 +34,7 @@
#include <linux/fb.h>
#include <linux/fbcon.h>
#include <linux/mem_encrypt.h>
+#include <linux/pci.h>
#include <asm/fb.h>
@@ -1788,6 +1789,27 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
}
EXPORT_SYMBOL(remove_conflicting_framebuffers);
+int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id, const char *name)
+{
+ struct apertures_struct *ap;
+ bool primary = false;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, res_id);
+ ap->ranges[0].size = pci_resource_len(pdev, res_id);
+#ifdef CONFIG_X86
+ primary = pdev->resource[PCI_ROM_RESOURCE].flags &
+ IORESOURCE_ROM_SHADOW;
+#endif
+ remove_conflicting_framebuffers(ap, name, primary);
+ kfree(ap);
+ return 0;
+}
+EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
+
/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 33fe95927742..ac3412290289 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -520,4 +520,16 @@ drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
#endif
}
+static inline int
+drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
+ int resource_id,
+ const char *name)
+{
+#if IS_REACHABLE(CONFIG_FB)
+ return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
+#else
+ return 0;
+#endif
+}
+
#endif
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f4386b0ccf40..4196cb09e58e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -624,6 +624,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
extern int register_framebuffer(struct fb_info *fb_info);
extern int unregister_framebuffer(struct fb_info *fb_info);
extern int unlink_framebuffer(struct fb_info *fb_info);
+extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id,
+ const char *name);
extern int remove_conflicting_framebuffers(struct apertures_struct *a,
const char *name, bool primary);
extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
--
2.11.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH 05/13] drm/cirrus: use simpler remove_conflicting_pci_framebuffers()
From: Michał Mirosław @ 2017-11-24 17:53 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, virtualization
In-Reply-To: <cover.1511544782.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +----------------------
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 69c4e352dd78..85ed8657c862 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -42,33 +42,12 @@ static const struct pci_device_id pciidlist[] = {
};
-static int cirrus_kick_out_firmware_fb(struct pci_dev *pdev)
-{
- struct apertures_struct *ap;
- bool primary = false;
-
- ap = alloc_apertures(1);
- if (!ap)
- return -ENOMEM;
-
- ap->ranges[0].base = pci_resource_start(pdev, 0);
- ap->ranges[0].size = pci_resource_len(pdev, 0);
-
-#ifdef CONFIG_X86
- primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
-#endif
- drm_fb_helper_remove_conflicting_framebuffers(ap, "cirrusdrmfb", primary);
- kfree(ap);
-
- return 0;
-}
-
static int cirrus_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
int ret;
- ret = cirrus_kick_out_firmware_fb(pdev);
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "cirrusdrmfb");
if (ret)
return ret;
--
2.11.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH 04/13] drm/bochs: use simpler remove_conflicting_pci_framebuffers()
From: Michał Mirosław @ 2017-11-24 17:53 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, virtualization
In-Reply-To: <cover.1511544782.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/gpu/drm/bochs/bochs_drv.c | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c
index 7b20318483e4..c61b40c72b62 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -143,22 +143,6 @@ static const struct dev_pm_ops bochs_pm_ops = {
/* ---------------------------------------------------------------------- */
/* pci interface */
-static int bochs_kick_out_firmware_fb(struct pci_dev *pdev)
-{
- struct apertures_struct *ap;
-
- ap = alloc_apertures(1);
- if (!ap)
- return -ENOMEM;
-
- ap->ranges[0].base = pci_resource_start(pdev, 0);
- ap->ranges[0].size = pci_resource_len(pdev, 0);
- drm_fb_helper_remove_conflicting_framebuffers(ap, "bochsdrmfb", false);
- kfree(ap);
-
- return 0;
-}
-
static int bochs_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -171,7 +155,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
- ret = bochs_kick_out_firmware_fb(pdev);
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "bochsdrmfb");
if (ret)
return ret;
--
2.11.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH 08/13] drm/virtio: use simpler remove_conflicting_pci_framebuffers()
From: Michał Mirosław @ 2017-11-24 17:53 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, virtualization
In-Reply-To: <cover.1511544782.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +++---------------------
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
index 7df8d0c9026a..115ed546ca4e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c
@@ -28,26 +28,6 @@
#include "virtgpu_drv.h"
-static void virtio_pci_kick_out_firmware_fb(struct pci_dev *pci_dev)
-{
- struct apertures_struct *ap;
- bool primary;
-
- ap = alloc_apertures(1);
- if (!ap)
- return;
-
- ap->ranges[0].base = pci_resource_start(pci_dev, 0);
- ap->ranges[0].size = pci_resource_len(pci_dev, 0);
-
- primary = pci_dev->resource[PCI_ROM_RESOURCE].flags
- & IORESOURCE_ROM_SHADOW;
-
- drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb", primary);
-
- kfree(ap);
-}
-
int drm_virtio_init(struct drm_driver *driver, struct virtio_device *vdev)
{
struct drm_device *dev;
@@ -69,7 +49,9 @@ int drm_virtio_init(struct drm_driver *driver, struct virtio_device *vdev)
pname);
dev->pdev = pdev;
if (vga)
- virtio_pci_kick_out_firmware_fb(pdev);
+ drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
+ 0,
+ "virtiodrmfb");
snprintf(unique, sizeof(unique), "pci:%s", pname);
ret = drm_dev_set_unique(dev, unique);
--
2.11.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH] uapi: add SPDX identifier to vm_sockets_diag.h
From: Stephen Hemminger @ 2017-11-24 20:08 UTC (permalink / raw)
To: stefanha; +Cc: netdev, Stephen Hemminger, virtualization
New file seems to have missed the SPDX license scan and update.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
include/uapi/linux/vm_sockets_diag.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/vm_sockets_diag.h b/include/uapi/linux/vm_sockets_diag.h
index 14cd7dc5a187..0b4dd54f3d1e 100644
--- a/include/uapi/linux/vm_sockets_diag.h
+++ b/include/uapi/linux/vm_sockets_diag.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/* AF_VSOCK sock_diag(7) interface for querying open sockets */
#ifndef _UAPI__VM_SOCKETS_DIAG_H__
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] uapi: add SPDX identifier to vm_sockets_diag.h
From: Stefan Hajnoczi @ 2017-11-25 7:08 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Stephen Hemminger, Stefan Hajnoczi, Linux Virtualization
In-Reply-To: <20171124200840.5551-1-sthemmin@microsoft.com>
On Fri, Nov 24, 2017 at 8:08 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> New file seems to have missed the SPDX license scan and update.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> include/uapi/linux/vm_sockets_diag.h | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* Re: [PATCH v2] VSOCK: Don't call vsock_stream_has_data in atomic context
From: David Miller @ 2017-11-25 19:22 UTC (permalink / raw)
To: jhansen; +Cc: pv-drivers, netdev, gregkh, linux-kernel, virtualization
In-Reply-To: <1511533528-5253-1-git-send-email-jhansen@vmware.com>
From: Jorgen Hansen <jhansen@vmware.com>
Date: Fri, 24 Nov 2017 06:25:28 -0800
> When using the host personality, VMCI will grab a mutex for any
> queue pair access. In the detach callback for the vmci vsock
> transport, we call vsock_stream_has_data while holding a spinlock,
> and vsock_stream_has_data will access a queue pair.
>
> To avoid this, we can simply omit calling vsock_stream_has_data
> for host side queue pairs, since the QPs are empty per default
> when the guest has detached.
>
> This bug affects users of VMware Workstation using kernel version
> 4.4 and later.
>
> Testing: Ran vsock tests between guest and host, and verified that
> with this change, the host isn't calling vsock_stream_has_data
> during detach. Ran mixedTest between guest and host using both
> guest and host as server.
>
> v2: Rebased on top of recent change to sk_state values
> Reviewed-by: Adit Ranadive <aditr@vmware.com>
> Reviewed-by: Aditya Sarwade <asarwade@vmware.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] uapi: add SPDX identifier to vm_sockets_diag.h
From: David Miller @ 2017-11-25 19:25 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin, stefanha, virtualization
In-Reply-To: <20171124200840.5551-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 24 Nov 2017 12:08:40 -0800
> New file seems to have missed the SPDX license scan and update.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Daniel Vetter @ 2017-11-27 10:27 UTC (permalink / raw)
To: Michał Mirosław
Cc: Teddy Wang, Christian König, David Airlie, amd-gfx,
virtualization, dri-devel, Alex Deucher, Sudip Mukherjee
In-Reply-To: <1738dbed0239bffc886f126fd3091daa39cd14c9.1511544782.git.mirq-linux@rere.qmqm.pl>
On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> Almost all drivers using remove_conflicting_framebuffers() wrap it with
> the same code. Extract common part from PCI drivers into separate
> remove_conflicting_pci_framebuffers().
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Since the only driver that seems to use this is the staging one, which imo
is a DOA project, not sure it's worth to bother with this here.
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 22 ++++++++++++++++++++++
> include/drm/drm_fb_helper.h | 12 ++++++++++++
> include/linux/fb.h | 2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 30a18d4c9de4..5ea980e5d3b7 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -34,6 +34,7 @@
> #include <linux/fb.h>
> #include <linux/fbcon.h>
> #include <linux/mem_encrypt.h>
> +#include <linux/pci.h>
>
> #include <asm/fb.h>
>
> @@ -1788,6 +1789,27 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> +int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id, const char *name)
> +{
> + struct apertures_struct *ap;
> + bool primary = false;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return -ENOMEM;
> +
> + ap->ranges[0].base = pci_resource_start(pdev, res_id);
> + ap->ranges[0].size = pci_resource_len(pdev, res_id);
> +#ifdef CONFIG_X86
> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> + IORESOURCE_ROM_SHADOW;
> +#endif
> + remove_conflicting_framebuffers(ap, name, primary);
> + kfree(ap);
> + return 0;
> +}
> +EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
> +
> /**
> * register_framebuffer - registers a frame buffer device
> * @fb_info: frame buffer info structure
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 33fe95927742..ac3412290289 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -520,4 +520,16 @@ drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> #endif
> }
>
> +static inline int
> +drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> + int resource_id,
> + const char *name)
> +{
> +#if IS_REACHABLE(CONFIG_FB)
> + return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
> +#else
> + return 0;
> +#endif
> +}
> +
> #endif
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index f4386b0ccf40..4196cb09e58e 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -624,6 +624,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
> extern int register_framebuffer(struct fb_info *fb_info);
> extern int unregister_framebuffer(struct fb_info *fb_info);
> extern int unlink_framebuffer(struct fb_info *fb_info);
> +extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id,
> + const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
> --
> 2.11.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 00/13] remove_conflicting_framebuffers() cleanup
From: Daniel Vetter @ 2017-11-27 10:30 UTC (permalink / raw)
To: Michał Mirosław
Cc: Teddy Wang, Bartlomiej Zolnierkiewicz, David Airlie,
Christian König, dri-devel, virtualization, Alex Deucher,
Chen-Yu Tsai, Thierry Reding, amd-gfx, linux-tegra, Maxime Ripard,
Jonathan Hunter, Sudip Mukherjee
In-Reply-To: <cover.1511544782.git.mirq-linux@rere.qmqm.pl>
On Fri, Nov 24, 2017 at 06:53:25PM +0100, Michał Mirosław wrote:
> This series cleans up duplicated code for replacing firmware FB
> driver with proper DRI driver and adds handover support to
> Tegra driver.
>
> The last patch is here because it uses new semantics of
> remove_conflicting_framebuffers() from this series. This
> can be considered independently, though.
Except for that patches I've commented on:
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since this is for tegra and Thierry has drm-misc commit rights, it's
probably simplest when Thierry pushes this all to drm-misc once driver
maintainers had a chance to look at it. Also needs and ack from Bart for
the fbdev sides.
-Daniel
>
> ---
>
> Michał Mirosław (13):
> fbdev: show fbdev number for debugging
> fbdev: add remove_conflicting_pci_framebuffers()
> drm/amdgpu: use simpler remove_conflicting_pci_framebuffers()
> drm/bochs: use simpler remove_conflicting_pci_framebuffers()
> drm/cirrus: use simpler remove_conflicting_pci_framebuffers()
> drm/mgag200: use simpler remove_conflicting_pci_framebuffers()
> drm/radeon: use simpler remove_conflicting_pci_framebuffers()
> drm/virtio: use simpler remove_conflicting_pci_framebuffers()
> staging: sm750fb: use simpler remove_conflicting_pci_framebuffers()
> fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
> drm/vc4: use simpler remove_conflicting_framebuffers(NULL)
> drm/sun4i: use simpler remove_conflicting_framebuffers(NULL)
> drm/tegra: kick out simplefb
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 +-----------------
> drivers/gpu/drm/bochs/bochs_drv.c | 18 +-------------
> drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +-----------------
> drivers/gpu/drm/mgag200/mgag200_drv.c | 21 +----------------
> drivers/gpu/drm/mgag200/mgag200_main.c | 9 -------
> drivers/gpu/drm/radeon/radeon_drv.c | 23 +-----------------
> drivers/gpu/drm/sun4i/sun4i_drv.c | 18 +-------------
> drivers/gpu/drm/tegra/drm.c | 4 ++++
> drivers/gpu/drm/vc4/vc4_drv.c | 20 +---------------
> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +++----------------
> drivers/staging/sm750fb/sm750.c | 22 +-----------------
> drivers/video/fbdev/core/fbmem.c | 40 ++++++++++++++++++++++++++++++--
> include/drm/drm_fb_helper.h | 12 ++++++++++
> include/linux/fb.h | 2 ++
> 14 files changed, 67 insertions(+), 192 deletions(-)
>
> --
> 2.11.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 00/13] remove_conflicting_framebuffers() cleanup
From: Thierry Reding @ 2017-11-27 10:33 UTC (permalink / raw)
To: Daniel Vetter
Cc: Teddy Wang, Bartlomiej Zolnierkiewicz, David Airlie,
Christian König, Jonathan Hunter, dri-devel,
Michał Mirosław, Alex Deucher, Chen-Yu Tsai, amd-gfx,
linux-tegra, Maxime Ripard, virtualization, Sudip Mukherjee
In-Reply-To: <20171127103044.faakzch7ehlkc3or@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 783 bytes --]
On Mon, Nov 27, 2017 at 11:30:44AM +0100, Daniel Vetter wrote:
> On Fri, Nov 24, 2017 at 06:53:25PM +0100, Michał Mirosław wrote:
> > This series cleans up duplicated code for replacing firmware FB
> > driver with proper DRI driver and adds handover support to
> > Tegra driver.
> >
> > The last patch is here because it uses new semantics of
> > remove_conflicting_framebuffers() from this series. This
> > can be considered independently, though.
>
> Except for that patches I've commented on:
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Since this is for tegra and Thierry has drm-misc commit rights, it's
> probably simplest when Thierry pushes this all to drm-misc once driver
> maintainers had a chance to look at it.
Will do.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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
* [PATCH] VSOCK: Don't set sk_state to TCP_CLOSE before testing it
From: Jorgen Hansen @ 2017-11-27 13:29 UTC (permalink / raw)
To: netdev, linux-kernel, virtualization
Cc: pv-drivers, gregkh, Jorgen Hansen, davem, stefanha
A recent commit (3b4477d2dcf2) converted the sk_state to use
TCP constants. In that change, vmci_transport_handle_detach
was changed such that sk->sk_state was set to TCP_CLOSE before
we test whether it is TCP_SYN_SENT. This change moves the
sk_state change back to the original locations in that function.
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
---
net/vmw_vsock/vmci_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 56573dc..a7a73ff 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -804,8 +804,6 @@ static void vmci_transport_handle_detach(struct sock *sk)
*/
if (vsk->local_addr.svm_cid == VMADDR_CID_HOST ||
vsock_stream_has_data(vsk) <= 0) {
- sk->sk_state = TCP_CLOSE;
-
if (sk->sk_state == TCP_SYN_SENT) {
/* The peer may detach from a queue pair while
* we are still in the connecting state, i.e.,
@@ -815,10 +813,12 @@ static void vmci_transport_handle_detach(struct sock *sk)
* event like a reset.
*/
+ sk->sk_state = TCP_CLOSE;
sk->sk_err = ECONNRESET;
sk->sk_error_report(sk);
return;
}
+ sk->sk_state = TCP_CLOSE;
}
sk->sk_state_change(sk);
}
--
2.6.2
^ permalink raw reply related
* [PATCH] drm/virtio: Don't return invalid caps on timeout
From: Tomeu Vizoso @ 2017-11-27 14:21 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, Tomeu Vizoso,
open list:VIRTIO GPU DRIVER
If the wait timeouts, the caps are probably invalid and we shouldn't be
passing them to userspace.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b94bd5440e57..902120ad4a6d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -517,6 +517,8 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
ret = wait_event_timeout(vgdev->resp_wq,
atomic_read(&cache_ent->is_valid), 5 * HZ);
+ if (!ret)
+ return -EBUSY;
ptr = cache_ent->caps_cache;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Sudip Mukherjee @ 2017-11-27 20:52 UTC (permalink / raw)
To: Daniel Vetter
Cc: Teddy Wang, David Airlie, amd-gfx, virtualization, dri-devel,
Alex Deucher, Michał Mirosław, Christian König
In-Reply-To: <20171127102758.y7c6yzyey6wfntxh@phenom.ffwll.local>
On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > the same code. Extract common part from PCI drivers into separate
> > remove_conflicting_pci_framebuffers().
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Since the only driver that seems to use this is the staging one, which imo
> is a DOA project, not sure it's worth to bother with this here.
afaik, this device is used in production by few manufacturers and it is
usefull for them to have it in the tree and the only reason it is still
in staging is because Tomi announced he will not take any new drivers in
fbdev. And, so I have not taken the initiative to properly move it out
of staging. I think Bartlomiej will also not accept new drivers in fbdev.
--
Regards
Sudip
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Daniel Vetter @ 2017-11-28 10:22 UTC (permalink / raw)
To: Sudip Mukherjee, Greg KH
Cc: Teddy Wang, David Airlie, amd-gfx, Michał Mirosław,
dri-devel, Daniel Vetter, Alex Deucher, virtualization,
Christian König
In-Reply-To: <20171127205219.GA3537@sudip-laptop>
On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote:
> On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > the same code. Extract common part from PCI drivers into separate
> > > remove_conflicting_pci_framebuffers().
> > >
> > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> >
> > Since the only driver that seems to use this is the staging one, which imo
> > is a DOA project, not sure it's worth to bother with this here.
>
> afaik, this device is used in production by few manufacturers and it is
> usefull for them to have it in the tree and the only reason it is still
> in staging is because Tomi announced he will not take any new drivers in
> fbdev. And, so I have not taken the initiative to properly move it out
> of staging. I think Bartlomiej will also not accept new drivers in fbdev.
Imo, if no one cares about porting it to kms (which will give you an fbdev
driver for free), then we should throw it out. At least I thought staging
was only for stuff that had a reasonable chance to get mainlined. Not as a
dumping ground for drivers that people use, but don't bother to get ready
for mainline.
Greg?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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