* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Paolo Bonzini @ 2018-10-25 23:28 UTC (permalink / raw)
To: Christoph Hellwig, Daniel Verkamp
Cc: Jens Axboe, Michael S. Tsirkin, virtualization, linux-block,
Stefan Hajnoczi, Changpeng Liu
In-Reply-To: <20181015092740.GA3964@infradead.org>
On 15/10/2018 11:27, Christoph Hellwig wrote:
> There is some issues in this spec. For one using the multiple ranges
> also for write zeroes is rather inefficient. Write zeroes really should
> use the same format as read and write.
What makes it inefficient?
> Second the unmap flag isn't properly specified at all, as nothing
> says the device may not unmap without the unmap flag. Please take
> a look at the SCSI or NVMe ѕpec for some guidance.
Thanks, I'll submit a patch for this.
Paolo
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Stefan Hajnoczi @ 2018-10-26 8:08 UTC (permalink / raw)
To: Daniel Verkamp
Cc: Jens Axboe, Michael S. Tsirkin, virtualization, linux-block,
Changpeng Liu
In-Reply-To: <20181012210628.226361-1-dverkamp@chromium.org>
[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]
On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> + range[n].flags = cpu_to_le32(flags);
> + range[n].num_sectors = cpu_to_le32(num_sectors);
> + range[n].sector = cpu_to_le64(sector);
...
> +/* Discard/write zeroes range for each request. */
> +struct virtio_blk_discard_write_zeroes {
> + /* discard/write zeroes start sector */
> + __virtio64 sector;
> + /* number of discard/write zeroes sectors */
> + __virtio32 num_sectors;
> + /* flags for this range */
> + __virtio32 flags;
cpu_to_le32() is being used on __virtio32 fields instead of cpu_to_virtio32().
From include/uapi/linux/virtio_types.h:
/*
* __virtio{16,32,64} have the following meaning:
* - __u{16,32,64} for virtio devices in legacy mode, accessed in native endian
* - __le{16,32,64} for standard-compliant virtio devices
*/
From the VIRTIO specification:
struct virtio_blk_discard_write_zeroes {
le64 sector;
le32 num_sectors;
struct {
le32 unmap:1;
le32 reserved:31;
} flags;
};
Since the VIRTIO spec says these fields are little-endian, I think these
fields should be declared just __u32 and __u64 instead of __virtio32 and
__virtio64.
Stefan
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Christoph Hellwig @ 2018-10-26 8:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Jens Axboe, Michael S. Tsirkin, virtualization, Christoph Hellwig,
linux-block, Stefan Hajnoczi, Changpeng Liu
In-Reply-To: <486afcff-a8bd-a05b-e331-e395d4d14853@redhat.com>
On Fri, Oct 26, 2018 at 01:28:54AM +0200, Paolo Bonzini wrote:
> On 15/10/2018 11:27, Christoph Hellwig wrote:
> > There is some issues in this spec. For one using the multiple ranges
> > also for write zeroes is rather inefficient. Write zeroes really should
> > use the same format as read and write.
>
> What makes it inefficient?
We require a memory allocation for each write zeroes instead of encoding
the lba/len in the command.
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Michael S. Tsirkin @ 2018-10-26 14:47 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Jens Axboe, virtualization, linux-block, Changpeng Liu
In-Reply-To: <20181026080838.GB4234@stefanha-x1.localdomain>
On Fri, Oct 26, 2018 at 09:08:38AM +0100, Stefan Hajnoczi wrote:
> On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> > + range[n].flags = cpu_to_le32(flags);
> > + range[n].num_sectors = cpu_to_le32(num_sectors);
> > + range[n].sector = cpu_to_le64(sector);
> ...
> > +/* Discard/write zeroes range for each request. */
> > +struct virtio_blk_discard_write_zeroes {
> > + /* discard/write zeroes start sector */
> > + __virtio64 sector;
> > + /* number of discard/write zeroes sectors */
> > + __virtio32 num_sectors;
> > + /* flags for this range */
> > + __virtio32 flags;
>
> cpu_to_le32() is being used on __virtio32 fields instead of cpu_to_virtio32().
>
> From include/uapi/linux/virtio_types.h:
>
> /*
> * __virtio{16,32,64} have the following meaning:
> * - __u{16,32,64} for virtio devices in legacy mode, accessed in native endian
> * - __le{16,32,64} for standard-compliant virtio devices
> */
>
> From the VIRTIO specification:
>
> struct virtio_blk_discard_write_zeroes {
> le64 sector;
> le32 num_sectors;
> struct {
> le32 unmap:1;
> le32 reserved:31;
> } flags;
> };
>
>
> Since the VIRTIO spec says these fields are little-endian, I think these
> fields should be declared just __u32 and __u64 instead of __virtio32 and
> __virtio64.
>
> Stefan
__le32/__le64 rather?
^ permalink raw reply
* RE: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Liu, Changpeng @ 2018-10-29 3:21 UTC (permalink / raw)
To: Christoph Hellwig, Paolo Bonzini
Cc: Jens Axboe, Michael S. Tsirkin,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, Stefan Hajnoczi
In-Reply-To: <20181026082640.GA1147@infradead.org>
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Friday, October 26, 2018 4:27 PM
> To: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Christoph Hellwig <hch@infradead.org>; Daniel Verkamp
> <dverkamp@chromium.org>; Jens Axboe <axboe@kernel.dk>; Michael S. Tsirkin
> <mst@redhat.com>; virtualization@lists.linux-foundation.org; linux-
> block@vger.kernel.org; Stefan Hajnoczi <stefanha@redhat.com>; Liu, Changpeng
> <changpeng.liu@intel.com>
> Subject: Re: [PATCH v8] virtio_blk: add discard and write zeroes support
>
> On Fri, Oct 26, 2018 at 01:28:54AM +0200, Paolo Bonzini wrote:
> > On 15/10/2018 11:27, Christoph Hellwig wrote:
> > > There is some issues in this spec. For one using the multiple ranges
> > > also for write zeroes is rather inefficient. Write zeroes really should
> > > use the same format as read and write.
> >
> > What makes it inefficient?
>
> We require a memory allocation for each write zeroes instead of encoding
> the lba/len in the command.
Make sense to me, but need to change the spec first.
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Stefan Hajnoczi @ 2018-10-29 5:05 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jens Axboe, virtualization, linux-block, Changpeng Liu
In-Reply-To: <20181026104636-mutt-send-email-mst@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1623 bytes --]
On Fri, Oct 26, 2018 at 10:47:16AM -0400, Michael S. Tsirkin wrote:
> On Fri, Oct 26, 2018 at 09:08:38AM +0100, Stefan Hajnoczi wrote:
> > On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> > > + range[n].flags = cpu_to_le32(flags);
> > > + range[n].num_sectors = cpu_to_le32(num_sectors);
> > > + range[n].sector = cpu_to_le64(sector);
> > ...
> > > +/* Discard/write zeroes range for each request. */
> > > +struct virtio_blk_discard_write_zeroes {
> > > + /* discard/write zeroes start sector */
> > > + __virtio64 sector;
> > > + /* number of discard/write zeroes sectors */
> > > + __virtio32 num_sectors;
> > > + /* flags for this range */
> > > + __virtio32 flags;
> >
> > cpu_to_le32() is being used on __virtio32 fields instead of cpu_to_virtio32().
> >
> > From include/uapi/linux/virtio_types.h:
> >
> > /*
> > * __virtio{16,32,64} have the following meaning:
> > * - __u{16,32,64} for virtio devices in legacy mode, accessed in native endian
> > * - __le{16,32,64} for standard-compliant virtio devices
> > */
> >
> > From the VIRTIO specification:
> >
> > struct virtio_blk_discard_write_zeroes {
> > le64 sector;
> > le32 num_sectors;
> > struct {
> > le32 unmap:1;
> > le32 reserved:31;
> > } flags;
> > };
> >
> >
> > Since the VIRTIO spec says these fields are little-endian, I think these
> > fields should be declared just __u32 and __u64 instead of __virtio32 and
> > __virtio64.
> >
> > Stefan
>
>
> __le32/__le64 rather?
Yes.
Stefan
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 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 v3] drm/bochs: add edid support.
From: Gerd Hoffmann @ 2018-10-29 13:45 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, David Airlie, open list,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/bochs/bochs.h | 1 +
drivers/gpu/drm/bochs/bochs_hw.c | 39 +++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/bochs/bochs_kms.c | 18 +++++++++++++++---
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index e7a69077e4..06b8166efa 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -66,6 +66,7 @@ struct bochs_device {
u16 yres_virtual;
u32 stride;
u32 bpp;
+ struct edid *edid;
/* drm */
struct drm_device *dev;
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index cacff73a64..db4afe94c5 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -69,6 +69,41 @@ static void bochs_hw_set_little_endian(struct bochs_device *bochs)
#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
#endif
+static int bochs_load_edid(struct bochs_device *bochs)
+{
+ uint8_t *blob;
+ size_t i, len;
+ uint8_t num_exts;
+
+ if (!bochs->mmio)
+ return -1;
+
+ if ((readb(bochs->mmio+0) != 0x00 ||
+ readb(bochs->mmio+1) != 0xff))
+ return -1;
+
+ num_exts = readb(bochs->mmio + 126);
+ len = EDID_LENGTH * (1 + num_exts);
+ if (len > 0x400 /* vga register offset */)
+ return -1;
+
+ kfree(bochs->edid);
+ bochs->edid = kmalloc(len, GFP_KERNEL);
+ blob = (void *)bochs->edid;
+ for (i = 0; i < len; i++) {
+ blob[i] = readb(bochs->mmio+i);
+ }
+
+ if (!drm_edid_is_valid(bochs->edid)) {
+ DRM_ERROR("EDID is not valid, ignoring.\n");
+ kfree(bochs->edid);
+ bochs->edid = NULL;
+ return -1;
+ }
+
+ return 0;
+}
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
@@ -150,6 +185,9 @@ int bochs_hw_init(struct drm_device *dev)
}
noext:
+ if (bochs_load_edid(bochs) == 0)
+ DRM_INFO("Found EDID data blob.\n");
+
return 0;
}
@@ -164,6 +202,7 @@ void bochs_hw_fini(struct drm_device *dev)
if (bochs->fb_map)
iounmap(bochs->fb_map);
pci_release_regions(dev->pdev);
+ kfree(bochs->edid);
}
void bochs_hw_setmode(struct bochs_device *bochs,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
index 9bc5b438ae..b9931443a7 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
static int bochs_connector_get_modes(struct drm_connector *connector)
{
- int count;
+ struct bochs_device *bochs =
+ container_of(connector, struct bochs_device, connector);
+ int count = 0;
- count = drm_add_modes_noedid(connector, 8192, 8192);
- drm_set_preferred_mode(connector, defx, defy);
+ if (bochs->edid)
+ count = drm_add_edid_modes(connector, bochs->edid);
+
+ if (!count) {
+ count = drm_add_modes_noedid(connector, 8192, 8192);
+ drm_set_preferred_mode(connector, defx, defy);
+ }
return count;
}
@@ -271,6 +278,11 @@ static void bochs_connector_init(struct drm_device *dev)
drm_connector_helper_add(connector,
&bochs_connector_connector_helper_funcs);
drm_connector_register(connector);
+
+ if (bochs->edid) {
+ drm_connector_attach_edid_property(connector);
+ drm_connector_update_edid_property(connector, bochs->edid);
+ }
}
--
2.9.3
^ permalink raw reply related
* Re: [Outreachy kernel] [PATCH 0/6] drm/qxl: Remove checkpatch issues
From: Daniel Vetter @ 2018-10-29 13:54 UTC (permalink / raw)
To: Shayenne da Luz Moura
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
outreachy-kernel, Dave Airlie
In-Reply-To: <cover.1540579956.git.shayenneluzmoura@gmail.com>
On Fri, Oct 26, 2018 at 04:20:30PM -0300, Shayenne da Luz Moura wrote:
> This series cleans the following checkpatch.pl issues:
>
> ERROR: trailing whitespace
> WARNING: Missing a blank line after declarations
> CHECK: Please don't use multiple blank lines
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ERROR: space required before the open parenthesis '('
> CHECK: Avoid using bool structure members because of possible alignment issues
I looked through the patches, all fine, great work. I've pinged
maintainers and will merge it all as soon as they've acked it.
Assuming you want to continue hacking on gpu drivers, we have a todo list
with more advanced tasks:
https://dri.freedesktop.org/docs/drm/gpu/todo.html
Best to discuss those on #dri-devel irc before getting started, to make
sure scope and all is clear.
Cheers, Daniel
>
> Shayenne da Luz Moura (6):
> drm/qxl: Remove trailing whitespace
> drm/qxl: Add line after variable declarations
> drm/qxl: Remove exceding whiteline
> drm/qxl: Use 'unsigned int' instead of 'usigned'
> drm/qxl: Add space before open parentheses
> drm/qxl: Use 'unsigned int' instead of bool
>
> drivers/gpu/drm/qxl/qxl_cmd.c | 7 +++++--
> drivers/gpu/drm/qxl/qxl_debugfs.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_dev.h | 1 -
> drivers/gpu/drm/qxl/qxl_display.c | 19 ++++++++++---------
> drivers/gpu/drm/qxl/qxl_draw.c | 11 ++++++-----
> drivers/gpu/drm/qxl/qxl_drv.h | 31 ++++++++++++++-----------------
> drivers/gpu/drm/qxl/qxl_dumb.c | 3 ++-
> drivers/gpu/drm/qxl/qxl_fb.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_image.c | 4 +++-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 2 ++
> drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_object.h | 2 ++
> drivers/gpu/drm/qxl/qxl_prime.c | 1 -
> drivers/gpu/drm/qxl/qxl_release.c | 1 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 12 +++++-------
> 16 files changed, 56 insertions(+), 54 deletions(-)
>
> --
> 2.19.1
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/cover.1540579956.git.shayenneluzmoura%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] x86/paravirt: pv_ops isn't GPL only
From: Juergen Gross @ 2018-10-29 15:01 UTC (permalink / raw)
To: linux-kernel, xen-devel, x86, virtualization
Cc: Juergen Gross, boris.ostrovsky, rusty, mingo, hpa, akataria, tglx
Commit 5c83511bdb9832 ("x86/paravirt: Use a single ops structure")
introduced a regression for out-of-tree modules using spinlocks, as
pv_lock_ops was exported via EXPORT_SYMBOL(), while the new pv_ops
structure now containing the pv lock operations is exported via
EXPORT_SYMBOL_GPL().
Change that by using EXPORT_SYMBOL(pv_ops).
Fixes: 5c83511bdb9832 ("x86/paravirt: Use a single ops structure")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
arch/x86/kernel/paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index e4d4df37922a..45123b116c05 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -483,5 +483,5 @@ NOKPROBE_SYMBOL(native_set_debugreg);
NOKPROBE_SYMBOL(native_load_idt);
#endif
-EXPORT_SYMBOL_GPL(pv_ops);
+EXPORT_SYMBOL(pv_ops);
EXPORT_SYMBOL_GPL(pv_info);
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v3] drm/bochs: add edid support.
From: Jani Nikula @ 2018-10-29 17:44 UTC (permalink / raw)
To: Gerd Hoffmann, dri-devel
Cc: David Airlie, David Airlie,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU, open list
In-Reply-To: <20181029134507.7775-1-kraxel@redhat.com>
On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Recent qemu (latest master branch, upcoming 3.1 release) got support
> for EDID data. This patch adds guest driver support.
>
> EDID support in qemu is not (yet) enabled by default, so please use
> 'qemu -device VGA,edid=on' for testing.
Any chance of making this use drm_get_edid() (requires an i2c_adapter)
or at least drm_do_get_edid()?
BR,
Jani.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/gpu/drm/bochs/bochs.h | 1 +
> drivers/gpu/drm/bochs/bochs_hw.c | 39 +++++++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/bochs/bochs_kms.c | 18 +++++++++++++++---
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index e7a69077e4..06b8166efa 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -66,6 +66,7 @@ struct bochs_device {
> u16 yres_virtual;
> u32 stride;
> u32 bpp;
> + struct edid *edid;
>
> /* drm */
> struct drm_device *dev;
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
> index cacff73a64..db4afe94c5 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -69,6 +69,41 @@ static void bochs_hw_set_little_endian(struct bochs_device *bochs)
> #define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
> #endif
>
> +static int bochs_load_edid(struct bochs_device *bochs)
> +{
> + uint8_t *blob;
> + size_t i, len;
> + uint8_t num_exts;
> +
> + if (!bochs->mmio)
> + return -1;
> +
> + if ((readb(bochs->mmio+0) != 0x00 ||
> + readb(bochs->mmio+1) != 0xff))
> + return -1;
> +
> + num_exts = readb(bochs->mmio + 126);
> + len = EDID_LENGTH * (1 + num_exts);
> + if (len > 0x400 /* vga register offset */)
> + return -1;
> +
> + kfree(bochs->edid);
> + bochs->edid = kmalloc(len, GFP_KERNEL);
> + blob = (void *)bochs->edid;
> + for (i = 0; i < len; i++) {
> + blob[i] = readb(bochs->mmio+i);
> + }
> +
> + if (!drm_edid_is_valid(bochs->edid)) {
> + DRM_ERROR("EDID is not valid, ignoring.\n");
> + kfree(bochs->edid);
> + bochs->edid = NULL;
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> int bochs_hw_init(struct drm_device *dev)
> {
> struct bochs_device *bochs = dev->dev_private;
> @@ -150,6 +185,9 @@ int bochs_hw_init(struct drm_device *dev)
> }
>
> noext:
> + if (bochs_load_edid(bochs) == 0)
> + DRM_INFO("Found EDID data blob.\n");
> +
> return 0;
> }
>
> @@ -164,6 +202,7 @@ void bochs_hw_fini(struct drm_device *dev)
> if (bochs->fb_map)
> iounmap(bochs->fb_map);
> pci_release_regions(dev->pdev);
> + kfree(bochs->edid);
> }
>
> void bochs_hw_setmode(struct bochs_device *bochs,
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
> index 9bc5b438ae..b9931443a7 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
>
> static int bochs_connector_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct bochs_device *bochs =
> + container_of(connector, struct bochs_device, connector);
> + int count = 0;
>
> - count = drm_add_modes_noedid(connector, 8192, 8192);
> - drm_set_preferred_mode(connector, defx, defy);
> + if (bochs->edid)
> + count = drm_add_edid_modes(connector, bochs->edid);
> +
> + if (!count) {
> + count = drm_add_modes_noedid(connector, 8192, 8192);
> + drm_set_preferred_mode(connector, defx, defy);
> + }
> return count;
> }
>
> @@ -271,6 +278,11 @@ static void bochs_connector_init(struct drm_device *dev)
> drm_connector_helper_add(connector,
> &bochs_connector_connector_helper_funcs);
> drm_connector_register(connector);
> +
> + if (bochs->edid) {
> + drm_connector_attach_edid_property(connector);
> + drm_connector_update_edid_property(connector, bochs->edid);
> + }
> }
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Paolo Bonzini @ 2018-10-29 18:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Michael S. Tsirkin, virtualization, linux-block,
Stefan Hajnoczi, Changpeng Liu
In-Reply-To: <20181026082640.GA1147@infradead.org>
On 26/10/2018 10:26, Christoph Hellwig wrote:
> On Fri, Oct 26, 2018 at 01:28:54AM +0200, Paolo Bonzini wrote:
>> On 15/10/2018 11:27, Christoph Hellwig wrote:
>>> There is some issues in this spec. For one using the multiple ranges
>>> also for write zeroes is rather inefficient. Write zeroes really should
>>> use the same format as read and write.
>>
>> What makes it inefficient?
>
> We require a memory allocation for each write zeroes instead of encoding
> the lba/len in the command.
Oh, I see. That's not a spec issue, the lba/length descriptor can be
included in the same buffer as the rest of the command; using
kmalloc_array even for a single-bio REQ_OP_WRITE_ZEROES is a choice made
by this patch, I suppose for simplicity.
It is possible to special case single-bio unmap and write zeroes so that
they don't call virtblk_setup_discard_write_zeroes and avoid
RQF_SPECIAL_PAYLOAD.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH v3] drm/bochs: add edid support.
From: Gerd Hoffmann @ 2018-10-29 20:05 UTC (permalink / raw)
To: Jani Nikula
Cc: David Airlie, David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU
In-Reply-To: <87in1kejgj.fsf@intel.com>
On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
> On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > Recent qemu (latest master branch, upcoming 3.1 release) got support
> > for EDID data. This patch adds guest driver support.
> >
> > EDID support in qemu is not (yet) enabled by default, so please use
> > 'qemu -device VGA,edid=on' for testing.
>
> Any chance of making this use drm_get_edid() (requires an i2c_adapter)
> or at least drm_do_get_edid()?
I'll have a look at using drm_do_get_edid(). drm_get_edid() will not
fly as there is no i2c adapter in the first place.
cheers,
Gerd
^ permalink raw reply
* [PATCH v4] drm/bochs: add edid support.
From: Gerd Hoffmann @ 2018-10-29 20:50 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, open list, jani.nikula,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU, David Airlie
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/bochs/bochs.h | 2 ++
drivers/gpu/drm/bochs/bochs_hw.c | 30 ++++++++++++++++++++++++++++++
drivers/gpu/drm/bochs/bochs_kms.c | 20 +++++++++++++++++---
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index e7a69077e4..577a8b917c 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -66,6 +66,7 @@ struct bochs_device {
u16 yres_virtual;
u32 stride;
u32 bpp;
+ struct edid *edid;
/* drm */
struct drm_device *dev;
@@ -126,6 +127,7 @@ void bochs_hw_setmode(struct bochs_device *bochs,
const struct drm_format_info *format);
void bochs_hw_setbase(struct bochs_device *bochs,
int x, int y, u64 addr);
+int bochs_hw_load_edid(struct bochs_device *bochs);
/* bochs_mm.c */
int bochs_mm_init(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index cacff73a64..c90a0d492f 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -69,6 +69,35 @@ static void bochs_hw_set_little_endian(struct bochs_device *bochs)
#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
#endif
+static int bochs_get_edid_block(void *data, u8 *buf,
+ unsigned int block, size_t len)
+{
+ struct bochs_device *bochs = data;
+ size_t i, start = block * EDID_LENGTH;
+
+ if (start + len > 0x400 /* vga register offset */)
+ return -1;
+
+ for (i = 0; i < len; i++) {
+ buf[i] = readb(bochs->mmio + start + i);
+ }
+ return 0;
+}
+
+int bochs_hw_load_edid(struct bochs_device *bochs)
+{
+ if (!bochs->mmio)
+ return -1;
+
+ kfree(bochs->edid);
+ bochs->edid = drm_do_get_edid(&bochs->connector,
+ bochs_get_edid_block, bochs);
+ if (bochs->edid == NULL)
+ return -1;
+
+ return 0;
+}
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
@@ -164,6 +193,7 @@ void bochs_hw_fini(struct drm_device *dev)
if (bochs->fb_map)
iounmap(bochs->fb_map);
pci_release_regions(dev->pdev);
+ kfree(bochs->edid);
}
void bochs_hw_setmode(struct bochs_device *bochs,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
index 9bc5b438ae..f87c284dd9 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
static int bochs_connector_get_modes(struct drm_connector *connector)
{
- int count;
+ struct bochs_device *bochs =
+ container_of(connector, struct bochs_device, connector);
+ int count = 0;
- count = drm_add_modes_noedid(connector, 8192, 8192);
- drm_set_preferred_mode(connector, defx, defy);
+ if (bochs->edid)
+ count = drm_add_edid_modes(connector, bochs->edid);
+
+ if (!count) {
+ count = drm_add_modes_noedid(connector, 8192, 8192);
+ drm_set_preferred_mode(connector, defx, defy);
+ }
return count;
}
@@ -271,6 +278,13 @@ static void bochs_connector_init(struct drm_device *dev)
drm_connector_helper_add(connector,
&bochs_connector_connector_helper_funcs);
drm_connector_register(connector);
+
+ bochs_hw_load_edid(bochs);
+ if (bochs->edid) {
+ DRM_INFO("Found EDID data blob.\n");
+ drm_connector_attach_edid_property(connector);
+ drm_connector_update_edid_property(connector, bochs->edid);
+ }
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 0/4] Improve virtio ID allocation
From: Gerd Hoffmann @ 2018-10-29 21:53 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: David Airlie, linux-kernel, dri-devel, virtualization
In-Reply-To: <20180926160031.15721-1-willy@infradead.org>
On Wed, Sep 26, 2018 at 09:00:27AM -0700, Matthew Wilcox wrote:
> I noticed you were using IDRs where you could be using the more efficient
> IDAs, then while fixing that I noticed the lack of error handling,
> and I decided to follow that up with an efficiency improvement.
>
> There's probably a v2 of this to follow because I couldn't figure
> out how to properly handle one of the error cases ... see the comment
> embedded in one of the patches.
#1 + #2 pushed to drm-misc-next now.
#3 should not be needed any more.
waiting for v2 of #4 ...
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
From: Gerd Hoffmann @ 2018-10-30 5:36 UTC (permalink / raw)
To: Jani Nikula
Cc: Sabyasachi Gupta, airlied, linux-kernel, dri-devel,
virtualization, Souptick Joarder, Brajeswar Ghosh
In-Reply-To: <87sh0xc7pv.fsf@intel.com>
On Tue, Oct 23, 2018 at 12:50:36PM +0300, Jani Nikula wrote:
> On Tue, 23 Oct 2018, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> > On Fri, Oct 19, 2018 at 9:30 PM Sabyasachi Gupta
> > <sabyasachi.linux@gmail.com> wrote:
> >>
> >> Replaced kmem_cache_alloc + memset with kmem_cache_zalloc
> >
> > Put a new line gap in between these two lines and send v2.
>
> Nah, the maintainers can trivially add the newline while
> applying. Review is much more valuable than nitpicking on the commit
> message.
Queued (and added newline).
thanks,
Gerd
^ permalink raw reply
* [PATCH net] vhost: Fix Spectre V1 vulnerability
From: Jason Wang @ 2018-10-30 6:10 UTC (permalink / raw)
To: mst, jasowang
Cc: Andrea Arcangeli, kvm, netdev, linux-kernel, virtualization,
Josh Poimboeuf
The idx in vhost_vring_ioctl() was controlled by userspace, hence a
potential exploitation of the Spectre variant 1 vulnerability.
Fixing this by sanitizing idx before using it to index d->vqs.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f52008bb8df7..3a5f81a66d34 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -30,6 +30,7 @@
#include <linux/sched/mm.h>
#include <linux/sched/signal.h>
#include <linux/interval_tree_generic.h>
+#include <linux/nospec.h>
#include "vhost.h"
@@ -1387,6 +1388,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
if (idx >= d->nvqs)
return -ENOBUFS;
+ idx = array_index_nospec(idx, d->nvqs);
vq = d->vqs[idx];
mutex_lock(&vq->mutex);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences
From: Gerd Hoffmann @ 2018-10-30 6:11 UTC (permalink / raw)
To: Robert Foss
Cc: Rob Herring, airlied, linux-kernel, dri-devel, virtualization,
Gustavo Padovan, Emil Velikov
In-Reply-To: <20181025183739.9375-3-robert.foss@collabora.com>
Hi,
> The execbuffer IOCTL is now read-write to allow the userspace to read the
> out-fence.
> #define DRM_IOCTL_VIRTGPU_EXECBUFFER \
> - DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
> + DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
> struct drm_virtgpu_execbuffer)
That changes the ioctl number and breaks the userspace api.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH 0/6] drm/qxl: Remove checkpatch issues
From: Gerd Hoffmann @ 2018-10-30 6:15 UTC (permalink / raw)
To: Shayenne da Luz Moura
Cc: David Airlie, linux-kernel, dri-devel, virtualization,
outreachy-kernel, Dave Airlie
In-Reply-To: <cover.1540579956.git.shayenneluzmoura@gmail.com>
On Fri, Oct 26, 2018 at 04:20:30PM -0300, Shayenne da Luz Moura wrote:
> This series cleans the following checkpatch.pl issues:
>
> ERROR: trailing whitespace
> WARNING: Missing a blank line after declarations
> CHECK: Please don't use multiple blank lines
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ERROR: space required before the open parenthesis '('
> CHECK: Avoid using bool structure members because of possible alignment issues
Patches queued up.
thanks,
Gerd
^ permalink raw reply
* [PATCH v4 1/2] virtio-gpu: add VIRTIO_GPU_F_EDID feature
From: Gerd Hoffmann @ 2018-10-30 6:32 UTC (permalink / raw)
To: virtio-dev, dri-devel
Cc: Michael S. Tsirkin, David Airlie, open list,
open list:VIRTIO CORE, NET AND BLOCK DRIVERS
In-Reply-To: <20181030063206.19528-1-kraxel@redhat.com>
The feature allows the guest request an EDID blob (describing monitor
capabilities) for a given scanout (aka virtual monitor connector).
It brings a new command message, which has just a scanout field (beside
the standard virtio-gpu header) and a response message which carries the
EDID data.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
---
include/uapi/linux/virtio_gpu.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index f43c3c6171..8e88eba1fa 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -41,6 +41,7 @@
#include <linux/types.h>
#define VIRTIO_GPU_F_VIRGL 0
+#define VIRTIO_GPU_F_EDID 1
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -56,6 +57,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING,
VIRTIO_GPU_CMD_GET_CAPSET_INFO,
VIRTIO_GPU_CMD_GET_CAPSET,
+ VIRTIO_GPU_CMD_GET_EDID,
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -76,6 +78,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
VIRTIO_GPU_RESP_OK_CAPSET_INFO,
VIRTIO_GPU_RESP_OK_CAPSET,
+ VIRTIO_GPU_RESP_OK_EDID,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -291,6 +294,21 @@ struct virtio_gpu_resp_capset {
__u8 capset_data[];
};
+/* VIRTIO_GPU_CMD_GET_EDID */
+struct virtio_gpu_cmd_get_edid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 scanout;
+ __le32 padding;
+};
+
+/* VIRTIO_GPU_RESP_OK_EDID */
+struct virtio_gpu_resp_edid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 size;
+ __le32 padding;
+ __u8 edid[1024];
+};
+
#define VIRTIO_GPU_EVENT_DISPLAY (1 << 0)
struct virtio_gpu_config {
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/2] drm/virtio: add edid support
From: Gerd Hoffmann @ 2018-10-30 6:32 UTC (permalink / raw)
To: virtio-dev, dri-devel
Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181030063206.19528-1-kraxel@redhat.com>
linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++
drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++++++
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 8 ++++
drivers/gpu/drm/virtio/virtgpu_vq.c | 67 ++++++++++++++++++++++++++++++++
5 files changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d29f0c7c76..852078419d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -114,6 +114,7 @@ struct virtio_gpu_output {
struct drm_encoder enc;
struct virtio_gpu_display_one info;
struct virtio_gpu_update_cursor cursor;
+ struct edid *edid;
int cur_x;
int cur_y;
bool enabled;
@@ -204,6 +205,7 @@ struct virtio_gpu_device {
spinlock_t ctx_id_idr_lock;
bool has_virgl_3d;
+ bool has_edid;
struct work_struct config_changed_work;
@@ -298,6 +300,7 @@ int virtio_gpu_cmd_get_capset_info(struct virtio_gpu_device *vgdev, int idx);
int virtio_gpu_cmd_get_capset(struct virtio_gpu_device *vgdev,
int idx, int version,
struct virtio_gpu_drv_cap_cache **cache_p);
+int virtio_gpu_cmd_get_edids(struct virtio_gpu_device *vgdev);
void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id,
uint32_t nlen, const char *name);
void virtio_gpu_cmd_context_destroy(struct virtio_gpu_device *vgdev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index 8f8fed471e..b5580b11a0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -169,6 +169,12 @@ static int virtio_gpu_conn_get_modes(struct drm_connector *connector)
struct drm_display_mode *mode = NULL;
int count, width, height;
+ if (output->edid) {
+ count = drm_add_edid_modes(connector, output->edid);
+ if (count)
+ return count;
+ }
+
width = le32_to_cpu(output->info.r.width);
height = le32_to_cpu(output->info.r.height);
count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
@@ -287,6 +293,8 @@ static int vgdev_output_init(struct virtio_gpu_device *vgdev, int index)
drm_connector_init(dev, connector, &virtio_gpu_connector_funcs,
DRM_MODE_CONNECTOR_VIRTUAL);
drm_connector_helper_add(connector, &virtio_gpu_conn_helper_funcs);
+ if (vgdev->has_edid)
+ drm_connector_attach_edid_property(connector);
drm_encoder_init(dev, encoder, &virtio_gpu_enc_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
@@ -378,6 +386,10 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev)
{
+ int i;
+
+ for (i = 0 ; i < vgdev->num_scanouts; ++i)
+ kfree(vgdev->outputs[i].edid);
virtio_gpu_fbdev_fini(vgdev);
drm_mode_config_cleanup(vgdev->ddev);
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c
index d9287c144f..f7f32a885a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -80,6 +80,7 @@ static unsigned int features[] = {
*/
VIRTIO_GPU_F_VIRGL,
#endif
+ VIRTIO_GPU_F_EDID,
};
static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 65060c0852..f6cbbb27e4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -44,6 +44,8 @@ static void virtio_gpu_config_changed_work_func(struct work_struct *work)
virtio_cread(vgdev->vdev, struct virtio_gpu_config,
events_read, &events_read);
if (events_read & VIRTIO_GPU_EVENT_DISPLAY) {
+ if (vgdev->has_edid)
+ virtio_gpu_cmd_get_edids(vgdev);
virtio_gpu_cmd_get_display_info(vgdev);
drm_helper_hpd_irq_event(vgdev->ddev);
events_clear |= VIRTIO_GPU_EVENT_DISPLAY;
@@ -174,6 +176,10 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags)
#else
DRM_INFO("virgl 3d acceleration not supported by guest\n");
#endif
+ if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) {
+ vgdev->has_edid = true;
+ DRM_INFO("EDID support available.\n");
+ }
ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
@@ -219,6 +225,8 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags)
if (num_capsets)
virtio_gpu_get_capsets(vgdev, num_capsets);
+ if (vgdev->has_edid)
+ virtio_gpu_cmd_get_edids(vgdev);
virtio_gpu_cmd_get_display_info(vgdev);
wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
5 * HZ);
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 4e2e037aed..dd149a59c7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -604,6 +604,45 @@ static void virtio_gpu_cmd_capset_cb(struct virtio_gpu_device *vgdev,
wake_up(&vgdev->resp_wq);
}
+static int virtio_get_edid_block(void *data, u8 *buf,
+ unsigned int block, size_t len)
+{
+ struct virtio_gpu_resp_edid *resp = data;
+ size_t start = block * EDID_LENGTH;
+
+ if (start + len > le32_to_cpu(resp->size))
+ return -1;
+ memcpy(buf, resp->edid + start, len);
+ return 0;
+}
+
+static void virtio_gpu_cmd_get_edid_cb(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_vbuffer *vbuf)
+{
+ struct virtio_gpu_cmd_get_edid *cmd =
+ (struct virtio_gpu_cmd_get_edid *)vbuf->buf;
+ struct virtio_gpu_resp_edid *resp =
+ (struct virtio_gpu_resp_edid *)vbuf->resp_buf;
+ uint32_t scanout = le32_to_cpu(cmd->scanout);
+ struct virtio_gpu_output *output;
+ struct edid *new_edid, *old_edid;
+
+ if (scanout >= vgdev->num_scanouts)
+ return;
+ output = vgdev->outputs + scanout;
+
+ new_edid = drm_do_get_edid(&output->conn, virtio_get_edid_block, resp);
+
+ spin_lock(&vgdev->display_info_lock);
+ old_edid = output->edid;
+ output->edid = new_edid;
+ drm_connector_update_edid_property(&output->conn, output->edid);
+ spin_unlock(&vgdev->display_info_lock);
+
+ kfree(old_edid);
+ wake_up(&vgdev->resp_wq);
+}
+
int virtio_gpu_cmd_get_display_info(struct virtio_gpu_device *vgdev)
{
struct virtio_gpu_ctrl_hdr *cmd_p;
@@ -706,6 +745,34 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device *vgdev,
return 0;
}
+int virtio_gpu_cmd_get_edids(struct virtio_gpu_device *vgdev)
+{
+ struct virtio_gpu_cmd_get_edid *cmd_p;
+ struct virtio_gpu_vbuffer *vbuf;
+ void *resp_buf;
+ int scanout;
+
+ if (WARN_ON(!vgdev->has_edid))
+ return -EINVAL;
+
+ for (scanout = 0; scanout < vgdev->num_scanouts; scanout++) {
+ resp_buf = kzalloc(sizeof(struct virtio_gpu_resp_edid),
+ GFP_KERNEL);
+ if (!resp_buf)
+ return -ENOMEM;
+
+ cmd_p = virtio_gpu_alloc_cmd_resp
+ (vgdev, &virtio_gpu_cmd_get_edid_cb, &vbuf,
+ sizeof(*cmd_p), sizeof(struct virtio_gpu_resp_edid),
+ resp_buf);
+ cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_GET_EDID);
+ cmd_p->scanout = cpu_to_le32(scanout);
+ virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+ }
+
+ return 0;
+}
+
void virtio_gpu_cmd_context_create(struct virtio_gpu_device *vgdev, uint32_t id,
uint32_t nlen, const char *name)
{
--
2.9.3
^ permalink raw reply related
* [PATCH] x86/paravirt: remove unused _paravirt_ident_32
From: Juergen Gross @ 2018-10-30 6:33 UTC (permalink / raw)
To: linux-kernel, xen-devel, x86, virtualization
Cc: Juergen Gross, boris.ostrovsky, rusty, mingo, hpa, akataria, tglx
There is no user of _paravirt_ident_32 left in the tree. Remove it
together with the related paravirt_patch_ident_32().
paravirt_patch_ident_64() can be moved inside CONFIG_PARAVIRT_XXL.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
arch/x86/include/asm/paravirt_types.h | 2 --
arch/x86/kernel/paravirt.c | 26 +++++++-------------------
arch/x86/kernel/paravirt_patch_32.c | 18 ++++++------------
arch/x86/kernel/paravirt_patch_64.c | 20 ++++++--------------
4 files changed, 19 insertions(+), 47 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index fba54ca23b2a..26942ad63830 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -361,7 +361,6 @@ extern struct paravirt_patch_template pv_ops;
__visible extern const char start_##ops##_##name[], end_##ops##_##name[]; \
asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops, name))
-unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
unsigned paravirt_patch_default(u8 type, void *insnbuf,
unsigned long addr, unsigned len);
@@ -651,7 +650,6 @@ void paravirt_leave_lazy_mmu(void);
void paravirt_flush_lazy_mmu(void);
void _paravirt_nop(void);
-u32 _paravirt_ident_32(u32);
u64 _paravirt_ident_64(u64);
#define paravirt_nop ((void *)_paravirt_nop)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 45123b116c05..c0e0101133f3 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -56,17 +56,6 @@ asm (".pushsection .entry.text, \"ax\"\n"
".type _paravirt_nop, @function\n\t"
".popsection");
-/* identity function, which can be inlined */
-u32 notrace _paravirt_ident_32(u32 x)
-{
- return x;
-}
-
-u64 notrace _paravirt_ident_64(u64 x)
-{
- return x;
-}
-
void __init default_banner(void)
{
printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
@@ -102,6 +91,12 @@ static unsigned paravirt_patch_call(void *insnbuf, const void *target,
}
#ifdef CONFIG_PARAVIRT_XXL
+/* identity function, which can be inlined */
+u64 notrace _paravirt_ident_64(u64 x)
+{
+ return x;
+}
+
static unsigned paravirt_patch_jmp(void *insnbuf, const void *target,
unsigned long addr, unsigned len)
{
@@ -146,13 +141,11 @@ unsigned paravirt_patch_default(u8 type, void *insnbuf,
else if (opfunc == _paravirt_nop)
ret = 0;
+#ifdef CONFIG_PARAVIRT_XXL
/* identity functions just return their single argument */
- else if (opfunc == _paravirt_ident_32)
- ret = paravirt_patch_ident_32(insnbuf, len);
else if (opfunc == _paravirt_ident_64)
ret = paravirt_patch_ident_64(insnbuf, len);
-#ifdef CONFIG_PARAVIRT_XXL
else if (type == PARAVIRT_PATCH(cpu.iret) ||
type == PARAVIRT_PATCH(cpu.usergs_sysret64))
/* If operation requires a jmp, then jmp */
@@ -309,13 +302,8 @@ struct pv_info pv_info = {
#endif
};
-#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE)
-/* 32-bit pagetable entries */
-#define PTE_IDENT __PV_IS_CALLEE_SAVE(_paravirt_ident_32)
-#else
/* 64-bit pagetable entries */
#define PTE_IDENT __PV_IS_CALLEE_SAVE(_paravirt_ident_64)
-#endif
struct paravirt_patch_template pv_ops = {
/* Init ops. */
diff --git a/arch/x86/kernel/paravirt_patch_32.c b/arch/x86/kernel/paravirt_patch_32.c
index 6368c22fa1fa..de138d3912e4 100644
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -10,24 +10,18 @@ DEF_NATIVE(cpu, iret, "iret");
DEF_NATIVE(mmu, read_cr2, "mov %cr2, %eax");
DEF_NATIVE(mmu, write_cr3, "mov %eax, %cr3");
DEF_NATIVE(mmu, read_cr3, "mov %cr3, %eax");
-#endif
-
-#if defined(CONFIG_PARAVIRT_SPINLOCKS)
-DEF_NATIVE(lock, queued_spin_unlock, "movb $0, (%eax)");
-DEF_NATIVE(lock, vcpu_is_preempted, "xor %eax, %eax");
-#endif
-
-unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len)
-{
- /* arg in %eax, return in %eax */
- return 0;
-}
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len)
{
/* arg in %edx:%eax, return in %edx:%eax */
return 0;
}
+#endif
+
+#if defined(CONFIG_PARAVIRT_SPINLOCKS)
+DEF_NATIVE(lock, queued_spin_unlock, "movb $0, (%eax)");
+DEF_NATIVE(lock, vcpu_is_preempted, "xor %eax, %eax");
+#endif
extern bool pv_is_native_spin_unlock(void);
extern bool pv_is_native_vcpu_is_preempted(void);
diff --git a/arch/x86/kernel/paravirt_patch_64.c b/arch/x86/kernel/paravirt_patch_64.c
index 7ca9cb726f4d..9d9e04b31077 100644
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -15,27 +15,19 @@ DEF_NATIVE(cpu, wbinvd, "wbinvd");
DEF_NATIVE(cpu, usergs_sysret64, "swapgs; sysretq");
DEF_NATIVE(cpu, swapgs, "swapgs");
-#endif
-
-DEF_NATIVE(, mov32, "mov %edi, %eax");
DEF_NATIVE(, mov64, "mov %rdi, %rax");
-#if defined(CONFIG_PARAVIRT_SPINLOCKS)
-DEF_NATIVE(lock, queued_spin_unlock, "movb $0, (%rdi)");
-DEF_NATIVE(lock, vcpu_is_preempted, "xor %eax, %eax");
-#endif
-
-unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len)
-{
- return paravirt_patch_insns(insnbuf, len,
- start__mov32, end__mov32);
-}
-
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len)
{
return paravirt_patch_insns(insnbuf, len,
start__mov64, end__mov64);
}
+#endif
+
+#if defined(CONFIG_PARAVIRT_SPINLOCKS)
+DEF_NATIVE(lock, queued_spin_unlock, "movb $0, (%rdi)");
+DEF_NATIVE(lock, vcpu_is_preempted, "xor %eax, %eax");
+#endif
extern bool pv_is_native_spin_unlock(void);
extern bool pv_is_native_vcpu_is_preempted(void);
--
2.16.4
^ permalink raw reply related
* Re: virtio-gpu without ARCH_HAS_SG_CHAIN
From: Gerd Hoffmann @ 2018-10-30 7:23 UTC (permalink / raw)
To: Michael Forney, christian.koenig; +Cc: linux-riscv, dri-devel, virtualization
In-Reply-To: <CAGw6cBsWHB4aRf=kPoT+v-FbtL0ymeBtZNEwKYobFizc0cLeaQ@mail.gmail.com>
On Mon, Oct 29, 2018 at 12:46:34PM -0700, Michael Forney wrote:
> Hi,
>
> I was looking at adding virtio-gpu support to tinyemu
> (https://bellard.org/tinyemu/). I got it to work on x86, but just for
> fun I tried it under riscv and ran into an issue with buffer
> allocations (though, this should affect any arch without
> ARCH_HAS_SG_CHAIN).
>
> virtio-gpu uses ttm to allocate buffers, which swaps pages to ensure
> that they aren't consecutive[0][1].
Interesting.
While hacking the virtio-gpu ttm code I've already noticed that I get
non-contignous memory even for small allocations (cursor, which is only
4 pages), but havn't found the time yet to look at this.
Christian, care to explain the background? The commit message sounds a
bit like it papers over a bug somewhere else.
> However, this causes sg_alloc_table_from_pages to use a sg entry for
> every single page, limiting buffers to only 170 pages (the number of
> sg entries that can fit into a page). This is only 417x417 with 32bpp.
> I believe the page swapping also makes TRANSFER_TO_HOST_2D inefficient
> by forcing the host to do many memcpys instead of just a few.
Probably not *that* bad, the amount of data copyed doesn't change after
all. But, yes, I'd prefer to have shorter sh lists too.
cheers,
Gerd
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=fdb1a2236b07948e83e0a777e1795d4f07e52c33
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=ae937fe19636067ec5e20d7f1fa10c6cc6000b52
^ permalink raw reply
* Re: [PATCH v3] drm/bochs: add edid support.
From: Daniel Vetter @ 2018-10-30 9:06 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU, Jani Nikula,
David Airlie
In-Reply-To: <20181029200520.jfnmvbkng2er5qbc@sirius.home.kraxel.org>
On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote:
> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
> > On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > Recent qemu (latest master branch, upcoming 3.1 release) got support
> > > for EDID data. This patch adds guest driver support.
> > >
> > > EDID support in qemu is not (yet) enabled by default, so please use
> > > 'qemu -device VGA,edid=on' for testing.
> >
> > Any chance of making this use drm_get_edid() (requires an i2c_adapter)
> > or at least drm_do_get_edid()?
>
> I'll have a look at using drm_do_get_edid(). drm_get_edid() will not
> fly as there is no i2c adapter in the first place.
Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world
flakiness of sinks (it's where all the retry logic resides), if you don't
have a i2c_adapater (because the hw has some magic "give me an edid"
block). For virtual hw we hopefully don't randomly drop bits on the floor
between the guest and host. Imo totally fine as-is.
E.g. we also don't feed the VBT edid through drm_do_get_edid either.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: virtio-gpu without ARCH_HAS_SG_CHAIN
From: Koenig, Christian @ 2018-10-30 9:27 UTC (permalink / raw)
To: Gerd Hoffmann, Michael Forney
Cc: linux-riscv@lists.infradead.org, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20181030072344.sstmq6jxcmyzbqmr@sirius.home.kraxel.org>
Am 30.10.18 um 08:23 schrieb Gerd Hoffmann:
> On Mon, Oct 29, 2018 at 12:46:34PM -0700, Michael Forney wrote:
>> Hi,
>>
>> I was looking at adding virtio-gpu support to tinyemu
>> (https://bellard.org/tinyemu/). I got it to work on x86, but just for
>> fun I tried it under riscv and ran into an issue with buffer
>> allocations (though, this should affect any arch without
>> ARCH_HAS_SG_CHAIN).
>>
>> virtio-gpu uses ttm to allocate buffers, which swaps pages to ensure
>> that they aren't consecutive[0][1].
> Interesting.
>
> While hacking the virtio-gpu ttm code I've already noticed that I get
> non-contignous memory even for small allocations (cursor, which is only
> 4 pages), but havn't found the time yet to look at this.
>
> Christian, care to explain the background? The commit message sounds a
> bit like it papers over a bug somewhere else.
The problem is that the TTM pool handler thinks that we need to free
pages to the huge page pool when it sees that they are consecutive.
The root problem of that in turn is that we can't use compound pages for
device allocated memory, but a real fix for that would require quite
some work in the MM.
What we can do rather easily is to paper over the problem by only
swapping page 511 and 510 to avoid that the pool things that this is a
huge page.
Regards,
Christian.
>
>> However, this causes sg_alloc_table_from_pages to use a sg entry for
>> every single page, limiting buffers to only 170 pages (the number of
>> sg entries that can fit into a page). This is only 417x417 with 32bpp.
>> I believe the page swapping also makes TRANSFER_TO_HOST_2D inefficient
>> by forcing the host to do many memcpys instead of just a few.
> Probably not *that* bad, the amount of data copyed doesn't change after
> all. But, yes, I'd prefer to have shorter sh lists too.
>
> cheers,
> Gerd
>
>> [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=fdb1a2236b07948e83e0a777e1795d4f07e52c33
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=ae937fe19636067ec5e20d7f1fa10c6cc6000b52
^ permalink raw reply
* Re: [PATCH v3] drm/bochs: add edid support.
From: Jani Nikula @ 2018-10-30 9:28 UTC (permalink / raw)
To: Daniel Vetter, Gerd Hoffmann
Cc: David Airlie, David Airlie, open list, dri-devel,
open list:DRM DRIVER FOR BOCHS VIRTUAL GPU
In-Reply-To: <20181030090632.GJ21967@phenom.ffwll.local>
On Tue, 30 Oct 2018, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Oct 29, 2018 at 09:05:20PM +0100, Gerd Hoffmann wrote:
>> On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
>> > On Mon, 29 Oct 2018, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> > > Recent qemu (latest master branch, upcoming 3.1 release) got support
>> > > for EDID data. This patch adds guest driver support.
>> > >
>> > > EDID support in qemu is not (yet) enabled by default, so please use
>> > > 'qemu -device VGA,edid=on' for testing.
>> >
>> > Any chance of making this use drm_get_edid() (requires an i2c_adapter)
>> > or at least drm_do_get_edid()?
>>
>> I'll have a look at using drm_do_get_edid(). drm_get_edid() will not
>> fly as there is no i2c adapter in the first place.
>
> Hm, not sure that makes sense. drm_do_get_edid is to handle the real-world
> flakiness of sinks (it's where all the retry logic resides), if you don't
> have a i2c_adapater (because the hw has some magic "give me an edid"
> block). For virtual hw we hopefully don't randomly drop bits on the floor
> between the guest and host. Imo totally fine as-is.
>
> E.g. we also don't feed the VBT edid through drm_do_get_edid either.
But nowadays we do handle the debugfs EDID override and the EDID
firmware loading in drm_do_get_edid(), so using that gives you those
features.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ 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