* Re: [Qemu-devel] security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device)
From: Michael S. Tsirkin @ 2019-02-11 23:07 UTC (permalink / raw)
To: David Hildenbrand
Cc: Pankaj Gupta, jack, kvm, linux-nvdimm, Dave Chinner, qemu-devel,
virtualization, pbonzini, adilger kernel, zwisler,
Andrea Arcangeli, dave jiang, darrick wong, vishal l verma, willy,
hch, linux-acpi, jmoyer, nilal, riel, stefanha, dchinner,
dan j williams, lcapitulino, linux-ext4, tytso,
xiaoguangrong eric, rjw, linux-kernel, linux-xfs, linux-fsdevel,
imammedo@
In-Reply-To: <b2be7796-9dee-b9fd-87e5-1ae570aa7db6@redhat.com>
On Mon, Feb 11, 2019 at 11:58:15PM +0100, David Hildenbrand wrote:
> On 11.02.19 23:29, Dave Chinner wrote:
> > On Mon, Feb 11, 2019 at 02:29:46AM -0500, Pankaj Gupta wrote:
> >> Hello Dave,
> >> Are we okay with this?
> >
> > Sure.
> >
> > I'm not sure I agree with all the analysis presented, but, well, I
> > haven't looked any deeper because I'm tired of being shouted at and
> > being called argumentative for daring to ask hard questions about
> > this topic....
>
> I think if you have concerns, they should definitely be discussed.
> Making people frustrated that review code is not what we want. Not at all.
>
> I suggest that Pankaj properly documents what we found out so far about
> security concerns and properly describes intended use cases and answers
> other questions you had in the cover letter / documentation of the
> follow up series.
>
> Thanks Dave!
Right. Also, there's an open question that you posed:
Also other storage devices have caches like that (well, the caches size
depends on the device) - thinking especially about storage systems -
which would in my opinion, also allow similar leaks. How are such
security concerns handled there? Are they different (besides eventually
access speed)?
and that needs some looking into, and reporting on.
> >
> > Cheers,
> >
> > Dave.
> >
>
>
> --
>
> Thanks,
>
> David / dhildenb
^ permalink raw reply
* Re: [PATCH RFC] virtio: hint if callbacks surprisingly might sleep
From: Cornelia Huck @ 2019-02-13 13:44 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Halil Pasic, linux-s390, linux-kernel, virtualization
In-Reply-To: <20190131102713-mutt-send-email-mst@kernel.org>
On Thu, 31 Jan 2019 10:27:53 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Jan 31, 2019 at 01:53:14PM +0100, Cornelia Huck wrote:
> > A virtio transport is free to implement some of the callbacks in
> > virtio_config_ops in a matter that they cannot be called from
> > atomic context (e.g. virtio-ccw, which maps a lot of the callbacks
> > to channel I/O, which is an inherently asynchronous mechanism).
> > This can be very surprising for developers using the much more
> > common virtio-pci transport, just to find out that things break
> > when used on s390.
> >
> > The documentation for virtio_config_ops now contains a comment
> > explaining this, but it makes sense to add a might_sleep() annotation
> > to various wrapper functions in the virtio core to avoid surprises
> > later.
> >
> > Note that annotations are NOT added to two classes of calls:
> > - direct calls from device drivers (all current callers should be
> > fine, however)
> > - calls which clearly won't be made from atomic context (such as
> > those ultimately coming in via the driver core)
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>
>
> Makes sense to me. I don't think we should push our luck in
> this release though, better defer until the merge window.
Friendly ping, as we're quite close to the release of 5.0 now.
^ permalink raw reply
* Re: [PATCH RFC] virtio: hint if callbacks surprisingly might sleep
From: Michael S. Tsirkin @ 2019-02-13 15:04 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Halil Pasic, linux-s390, linux-kernel, virtualization
In-Reply-To: <20190213144414.6543cd22.cohuck@redhat.com>
On Wed, Feb 13, 2019 at 02:44:14PM +0100, Cornelia Huck wrote:
> On Thu, 31 Jan 2019 10:27:53 -0500
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Jan 31, 2019 at 01:53:14PM +0100, Cornelia Huck wrote:
> > > A virtio transport is free to implement some of the callbacks in
> > > virtio_config_ops in a matter that they cannot be called from
> > > atomic context (e.g. virtio-ccw, which maps a lot of the callbacks
> > > to channel I/O, which is an inherently asynchronous mechanism).
> > > This can be very surprising for developers using the much more
> > > common virtio-pci transport, just to find out that things break
> > > when used on s390.
> > >
> > > The documentation for virtio_config_ops now contains a comment
> > > explaining this, but it makes sense to add a might_sleep() annotation
> > > to various wrapper functions in the virtio core to avoid surprises
> > > later.
> > >
> > > Note that annotations are NOT added to two classes of calls:
> > > - direct calls from device drivers (all current callers should be
> > > fine, however)
> > > - calls which clearly won't be made from atomic context (such as
> > > those ultimately coming in via the driver core)
> > >
> > > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> >
> >
> > Makes sense to me. I don't think we should push our luck in
> > this release though, better defer until the merge window.
>
> Friendly ping, as we're quite close to the release of 5.0 now.
Queued now, thanks!
^ permalink raw reply
* [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Jason Wang @ 2019-02-15 7:53 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, linux-kernel, kvm, virtualization
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a2e5dc7716e2 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
len, iov, 64, VHOST_ACCESS_WO);
- if (ret)
+ if (ret < 0)
return ret;
for (i = 0; i < ret; i++) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 0/5] Clean up TTM mmap offsets
From: Hans de Goede @ 2019-02-15 15:25 UTC (permalink / raw)
To: Thomas Zimmermann, alexander.deucher, christian.koenig,
David1.Zhou, airlied, kraxel, z.liuxinliang, zourongrong,
kong.kongxinwei, puck.chen, bskeggs, thellstrom,
linux-graphics-maintainer, daniel, arnd, gregkh, ray.huang,
Jerry.Zhang
Cc: spice-devel, amd-gfx, dri-devel, virtualization
In-Reply-To: <20190207085931.29569-1-tzimmermann@suse.de>
Hi,
On 2/7/19 9:59 AM, Thomas Zimmermann wrote:
> Almost all TTM-based drivers use the same values for the mmap-able
> range of BO addresses. Each driver therefore duplicates the
> DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
> configurable by drivers.
>
> This patch set replaces driver-specific configuration with a single
> setup. All code is located within TTM. TTM and GEM share the same
> range for mmap-able BOs.
>
> Thomas Zimmermann (5):
> staging/vboxvideo: Use same BO mmap offset as other drivers
> drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant
> drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init()
> drm/ttm: Quick-test mmap offset in ttm_bo_mmap()
> drm: Use the same mmap-range offset and size for GEM and TTM
The first patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The vboxvideo bits in the other patches look good to me to:
Acked-by: Hans de Goede <hdegoede@redhat.com>
For the other patches in the series.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Stephen Hemminger @ 2019-02-15 16:45 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20190215075324.18891-1-jasowang@redhat.com>
On Fri, 15 Feb 2019 15:53:24 +0800
Jason Wang <jasowang@redhat.com> wrote:
> When fail, translate_desc() returns negative value, otherwise the
> number of iovs. So we should fail when the return value is negative
> instead of a blindly check against zero.
>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Looks good. It is best to put the Addresses-Coverity-Id tag on these kind
of bug fixes so that the automated tools see it.
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: David Miller @ 2019-02-15 18:03 UTC (permalink / raw)
To: jasowang; +Cc: kvm, mst, netdev, linux-kernel, virtualization
In-Reply-To: <20190215075324.18891-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 15 Feb 2019 15:53:24 +0800
> When fail, translate_desc() returns negative value, otherwise the
> number of iovs. So we should fail when the return value is negative
> instead of a blindly check against zero.
>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Jason, please put the Fixes tag first.
Thank you.
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Michael S. Tsirkin @ 2019-02-15 21:59 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190215075324.18891-1-jasowang@redhat.com>
On Fri, Feb 15, 2019 at 03:53:24PM +0800, Jason Wang wrote:
> When fail, translate_desc() returns negative value, otherwise the
> number of iovs. So we should fail when the return value is negative
> instead of a blindly check against zero.
>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
and I guess the log was backported to stable so we want
this backported too.
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 24a129fcdd61..a2e5dc7716e2 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
>
> ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
> len, iov, 64, VHOST_ACCESS_WO);
> - if (ret)
> + if (ret < 0)
> return ret;
>
> for (i = 0; i < ret; i++) {
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH] VMCI: Support upto 64-bit PPNs
From: gregkh @ 2019-02-16 19:52 UTC (permalink / raw)
To: Vishnu DASA
Cc: Pv-drivers, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20190215162738.21334-1-vdasa@vmware.com>
On Fri, Feb 15, 2019 at 04:32:47PM +0000, Vishnu DASA wrote:
> diff --git a/include/linux/vmw_vmci_defs.h b/include/linux/vmw_vmci_defs.h
> index b724ef7005de..eaa1e762bf06 100644
> --- a/include/linux/vmw_vmci_defs.h
> +++ b/include/linux/vmw_vmci_defs.h
> @@ -45,6 +45,7 @@
> #define VMCI_CAPS_GUESTCALL 0x2
> #define VMCI_CAPS_DATAGRAM 0x4
> #define VMCI_CAPS_NOTIFICATIONS 0x8
> +#define VMCI_CAPS_PPN64 0x10
BIT()?
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Jason Wang @ 2019-02-19 6:50 UTC (permalink / raw)
To: David Miller; +Cc: kvm, mst, netdev, linux-kernel, virtualization
In-Reply-To: <20190215.100356.251698752340585300.davem@davemloft.net>
On 2019/2/16 上午2:03, David Miller wrote:
> From: Jason Wang<jasowang@redhat.com>
> Date: Fri, 15 Feb 2019 15:53:24 +0800
>
>> When fail, translate_desc() returns negative value, otherwise the
>> number of iovs. So we should fail when the return value is negative
>> instead of a blindly check against zero.
>>
>> Reported-by: Stephen Hemminger<stephen@networkplumber.org>
>> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
>> Signed-off-by: Jason Wang<jasowang@redhat.com>
> Jason, please put the Fixes tag first.
>
> Thank you.
Ok. Will post V2.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
From: Jason Wang @ 2019-02-19 6:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20190215084502.23feed0e@shemminger-XPS-13-9360>
On 2019/2/16 上午12:45, Stephen Hemminger wrote:
> On Fri, 15 Feb 2019 15:53:24 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> When fail, translate_desc() returns negative value, otherwise the
>> number of iovs. So we should fail when the return value is negative
>> instead of a blindly check against zero.
>>
>> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
>> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Looks good. It is best to put the Addresses-Coverity-Id tag on these kind
> of bug fixes so that the automated tools see it.
Ok. Will do this in V2.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH net V2] vhost: correctly check the return value of translate_desc() in log_used()
From: Jason Wang @ 2019-02-19 6:53 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, linux-kernel, kvm, virtualization
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE)
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a2e5dc7716e2 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
len, iov, 64, VHOST_ACCESS_WO);
- if (ret)
+ if (ret < 0)
return ret;
for (i = 0; i < ret; i++) {
--
2.17.1
^ permalink raw reply related
* [PATCH][next] vhost: only return early if ret indicates an error or no iovecs have been processed
From: Colin King @ 2019-02-19 13:57 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, kvm, virtualization, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently the loop that calls log_write_hva on each iovec is never
executed because of an incorrect error check on the return from the
call to translate_desc. The check should be checking for a -ve error
return and because it makes no sense to iterate over zero items, the
checks should also check for zero too.
Detected by CoverityScan, CID#1476969 ("Logically dead code")
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a9a1709a859a 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
len, iov, 64, VHOST_ACCESS_WO);
- if (ret)
+ if (ret <= 0)
return ret;
for (i = 0; i < ret; i++) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH][next] vhost: only return early if ret indicates an error or no iovecs have been processed
From: Michael S. Tsirkin @ 2019-02-19 16:35 UTC (permalink / raw)
To: Colin King; +Cc: kvm, netdev, kernel-janitors, linux-kernel, virtualization
In-Reply-To: <20190219135713.10426-1-colin.king@canonical.com>
On Tue, Feb 19, 2019 at 01:57:13PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently the loop that calls log_write_hva on each iovec is never
> executed because of an incorrect error check on the return from the
> call to translate_desc. The check should be checking for a -ve error
> return and because it makes no sense to iterate over zero items, the
> checks should also check for zero too.
>
> Detected by CoverityScan, CID#1476969 ("Logically dead code")
>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Jason posted a similar patch recently.
Are you happy with that one?
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 24a129fcdd61..a9a1709a859a 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
>
> ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
> len, iov, 64, VHOST_ACCESS_WO);
> - if (ret)
> + if (ret <= 0)
> return ret;
>
> for (i = 0; i < ret; i++) {
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH][next] vhost: only return early if ret indicates an error or no iovecs have been processed
From: Colin Ian King @ 2019-02-19 16:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, netdev, kernel-janitors, linux-kernel, virtualization
In-Reply-To: <20190219113510-mutt-send-email-mst@kernel.org>
On 19/02/2019 16:35, Michael S. Tsirkin wrote:
> On Tue, Feb 19, 2019 at 01:57:13PM +0000, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> Currently the loop that calls log_write_hva on each iovec is never
>> executed because of an incorrect error check on the return from the
>> call to translate_desc. The check should be checking for a -ve error
>> return and because it makes no sense to iterate over zero items, the
>> checks should also check for zero too.
>>
>> Detected by CoverityScan, CID#1476969 ("Logically dead code")
>>
>> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Jason posted a similar patch recently.
>
> Are you happy with that one?
Sure, ignore mine, I was late to the party.
>
>> ---
>> drivers/vhost/vhost.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index 24a129fcdd61..a9a1709a859a 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
>>
>> ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
>> len, iov, 64, VHOST_ACCESS_WO);
>> - if (ret)
>> + if (ret <= 0)
>> return ret;
>>
>> for (i = 0; i < ret; i++) {
>> --
>> 2.20.1
^ permalink raw reply
* Re: [PATCH net V2] vhost: correctly check the return value of translate_desc() in log_used()
From: David Miller @ 2019-02-19 21:16 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20190219065344.24923-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 19 Feb 2019 14:53:44 +0800
> When fail, translate_desc() returns negative value, otherwise the
> number of iovs. So we should fail when the return value is negative
> instead of a blindly check against zero.
>
> Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE)
>
> Fixes: cc5e71075947 ("vhost: log dirty page correctly")
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] drm/qxl: unbind vgacon
From: Gerd Hoffmann @ 2019-02-20 14:36 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
Daniel Vetter, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
Dave Airlie
Problem: qxl switches from native mode back into vga compatibility mode
when it notices someone is accessing vga registers. And vgacon does
exactly that before fbcon takes over.
Before qxl switched to the generic fbdev emulation that didn't cause any
problems. With the generic fbdev emulation the switch to vga mode
happens now and then, probably caused by a initialization order change
and triggered by a printk in a bad moment.
So make sure we take vgacon out of the picture by making dummycon
taking over the console early enough.
Not entriely happy with the approach, I'm open to better ideas.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_drv.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb..88349dc13e 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -30,6 +30,7 @@
#include <linux/module.h>
#include <linux/console.h>
+#include <linux/vt_kern.h>
#include <drm/drmP.h>
#include <drm/drm.h>
@@ -89,6 +90,11 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
drm_kms_helper_poll_init(&qdev->ddev);
+ /* unbind vgacon to make sure it doesn't touch our vga registers */
+ console_lock();
+ ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true);
+ console_unlock();
+
/* Complete initialization. */
ret = drm_dev_register(&qdev->ddev, ent->driver_data);
if (ret)
--
2.9.3
^ permalink raw reply related
* Re: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it
From: Christoph Hellwig @ 2019-02-20 15:19 UTC (permalink / raw)
To: ira.weiny
Cc: linux-fbdev, Michal Hocko, kvm, linux-sh, Peter Zijlstra,
James Hogan, linux-fpga, Heiko Carstens, dri-devel, linux-mips,
linux-mm, Rich Felker, Paul Mackerras, sparclinux, ceph-devel,
devel, linux-s390, rds-devel, Yoshinori Sato, linux-rdma,
Jason Gunthorpe, Ingo Molnar, Benjamin Herrenschmidt, xen-devel,
devel, linux-media, John Hubbard, kvm-ppc, Borisla
In-Reply-To: <20190220053040.10831-1-ira.weiny@intel.com>
On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and the IB changes are very minor. But they
> could just as well go through the IB tree.
>
> NOTE: This series depends on my clean up patch to remove the write parameter
> from gup_fast_permitted()[1]
>
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages. These pages can be held for a significant time. But
> get_user_pages_fast() does not protect against mapping of FS DAX pages.
This I don't get - if you do lock down long term mappings performance
of the actual get_user_pages call shouldn't matter to start with.
What do I miss?
^ permalink raw reply
* [PATCH] drm/bochs: Fix the ID mismatch error
From: Alistair Francis @ 2019-02-21 0:33 UTC (permalink / raw)
To: kraxel@redhat.com, virtualization@lists.linux-foundation.org
Cc: david.abdurachmanov@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Alistair Francis,
alistair23@gmail.com, linux-riscv@lists.infradead.org
When running RISC-V QEMU with the Bochs device attached via PCIe the
probe of the Bochs device fails with:
[drm:bochs_hw_init] *ERROR* ID mismatch
This was introduced by this commit:
7780eb9ce8 bochs: convert to drm_dev_register
To fix the error we ensure that pci_enable_device() is called before
bochs_load().
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com>
---
drivers/gpu/drm/bochs/bochs_drv.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c
index f3dd66ae990a..aa35007262cd 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -154,6 +154,10 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (IS_ERR(dev))
return PTR_ERR(dev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto err_free_dev;
+
dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] drm/qxl: unbind vgacon
From: Daniel Vetter @ 2019-02-21 9:57 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Daniel Vetter,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190220143640.9970-1-kraxel@redhat.com>
On Wed, Feb 20, 2019 at 03:36:40PM +0100, Gerd Hoffmann wrote:
> Problem: qxl switches from native mode back into vga compatibility mode
> when it notices someone is accessing vga registers. And vgacon does
> exactly that before fbcon takes over.
>
> Before qxl switched to the generic fbdev emulation that didn't cause any
> problems. With the generic fbdev emulation the switch to vga mode
> happens now and then, probably caused by a initialization order change
> and triggered by a printk in a bad moment.
>
> So make sure we take vgacon out of the picture by making dummycon
> taking over the console early enough.
>
> Not entriely happy with the approach, I'm open to better ideas.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index bb81e310eb..88349dc13e 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -30,6 +30,7 @@
>
> #include <linux/module.h>
> #include <linux/console.h>
> +#include <linux/vt_kern.h>
>
> #include <drm/drmP.h>
> #include <drm/drm.h>
> @@ -89,6 +90,11 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> drm_kms_helper_poll_init(&qdev->ddev);
>
> + /* unbind vgacon to make sure it doesn't touch our vga registers */
> + console_lock();
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true);
> + console_unlock();
Still seems very late, in i915 we kick out vgacon as pretty much the first
thing in driver load. See i915_kick_out_vgacon.
I wonder whether we should integrate that logic into
drm_fb_helper_remove_conflicting_pci_framebuffers, by checking whether
that pci device can decode VGA and kick out vgacon in that case. Instead
of sprinkling the same logic over all drivers.
-Daniel
> +
> /* Complete initialization. */
> ret = drm_dev_register(&qdev->ddev, ent->driver_data);
> if (ret)
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] drm/qxl: unbind vgacon
From: Gerd Hoffmann @ 2019-02-21 11:26 UTC (permalink / raw)
To: dri-devel, Dave Airlie, David Airlie,
open list:DRM DRIVER FOR QXL VIRTUAL GPU,
open list:DRM DRIVER FOR QXL VIRTUAL GPU, open list
In-Reply-To: <20190221095751.GN2665@phenom.ffwll.local>
> > + /* unbind vgacon to make sure it doesn't touch our vga registers */
> > + console_lock();
> > + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, true);
> > + console_unlock();
>
> Still seems very late, in i915 we kick out vgacon as pretty much the first
> thing in driver load. See i915_kick_out_vgacon.
So the idea isn't completely silly ...
thanks for the pointer,
Gerd
^ permalink raw reply
* [PATCH v2 2/2] drm/qxl: kick out vgacon
From: Gerd Hoffmann @ 2019-02-21 11:35 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, open list:DRM DRIVER FOR QXL VIRTUAL GPU,
daniel, open list:DRM DRIVER FOR QXL VIRTUAL GPU, Dave Airlie
In-Reply-To: <20190221113534.20764-1-kraxel@redhat.com>
Problem: qxl switches from native mode back into vga compatibility mode
when it notices someone is accessing vga registers. And vgacon does
exactly that before fbcon takes over. So make sure we kick out vgacon
early enough that it wouldn't disturb us.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/qxl/qxl_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb..08446561aa 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -95,6 +95,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto modeset_cleanup;
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
+ drm_fb_helper_kick_out_vgacon();
drm_fbdev_generic_setup(&qdev->ddev, 32);
return 0;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] drm/bochs: Fix the ID mismatch error
From: kraxel @ 2019-02-21 11:52 UTC (permalink / raw)
To: Alistair Francis
Cc: david.abdurachmanov@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org, alistair23@gmail.com,
linux-riscv@lists.infradead.org
In-Reply-To: <20190221003231.31625-1-alistair.francis@wdc.com>
On Thu, Feb 21, 2019 at 12:33:03AM +0000, Alistair Francis wrote:
> When running RISC-V QEMU with the Bochs device attached via PCIe the
> probe of the Bochs device fails with:
> [drm:bochs_hw_init] *ERROR* ID mismatch
>
> This was introduced by this commit:
> 7780eb9ce8 bochs: convert to drm_dev_register
>
> To fix the error we ensure that pci_enable_device() is called before
> bochs_load().
>
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> Reported-by: David Abdurachmanov <david.abdurachmanov@gmail.com>
Pushed to drm-misc-fixes.
thanks,
Gerd
^ permalink raw reply
* Re: [PATCH -next] drm/qxl: remove set but not used variable 'bo_old'
From: Gerd Hoffmann @ 2019-02-21 12:05 UTC (permalink / raw)
To: YueHaibing
Cc: David Airlie, kernel-janitors, linux-kernel, dri-devel,
virtualization, Daniel Vetter, spice-devel, Dave Airlie
In-Reply-To: <20190218085459.196470-1-yuehaibing@huawei.com>
On Mon, Feb 18, 2019 at 08:54:59AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_atomic_update':
> drivers/gpu/drm/qxl/qxl_display.c:538:17: warning:
> variable 'bo_old' set but not used [-Wunused-but-set-variable]
>
> It's not used any more after 4979904c62b9 ("drm/qxl: use shadow bo directly")
Pushed to drm-misc-next.
thanks,
Gerd
^ permalink raw reply
* CFP WEBIST 2019 - 15th Int.l Conf. on Web Information Systems and Technologies (Vienna/Austria)
From: webist @ 2019-02-21 12:18 UTC (permalink / raw)
To: virtualization
SUBMISSION DEADLINE
15th International Conference on Web Information Systems and Technologies
Submission Deadline: April 29, 2019
http://www.webist.org/
September 18 - 20, 2019
Vienna, Austria.
WEBIST is organized in 5 major tracks:
- Internet Technology
- Mobile and NLP Information Systems
- Service Based Information Systems, Platforms and Eco-Systems
- Web Intelligence
- Web Interfaces
Proceedings will be submitted for indexation by: DBLP, Thomson Reuters, EI, SCOPUS, Semantic Scholar and Google Scholar.
With the presence of internationally distinguished keynote speakers:
Steffen Staab, University of Koblenz-Landau, Germany
Karl Aberer, EPFL, Switzerland
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,
WEBIST Secretariat
Address: Avenida de São Francisco Xavier Lote 7L Cave
2910-595 Setubal, Portugal
Tel: +351 265 520 184
Fax: +351 265 520 186
Web: http://www.webist.org/
e-mail: webist.secretariat@insticc.org
_______________________________________________
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