Re: [PATCH v3 1/2] virtio-rng: fix stuck of hot-unplugging busy device

2014-09-11 Thread Rusty Russell
Amit Shah  writes:
> On (Wed) 10 Sep 2014 [14:11:36], Amos Kong wrote:
>> When we try to hot-remove a busy virtio-rng device from QEMU monitor,
>> the device can't be hot-removed. Because virtio-rng driver hangs at
>> wait_for_completion_killable().
>> 
>> This patch exits the waiting by completing have_data completion before
>> unregistering, resets data_avail to avoid the hwrng core use wrong
>> buffer bytes.
>> 
>> Signed-off-by: Amos Kong 
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Amit Shah 

Thanks, applied.

Cheers,
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: Rusty away 18th September -- 11th October

2014-09-11 Thread Linus Torvalds
On Wed, Sep 10, 2014 at 5:56 PM, Rusty Russell  wrote:
>
> Probably won't read mail.  Linus, I'll have pull requests early
> next week; if there's anything needed I'm sure Michael Tsirkin can
> handle it.

So according to "normal timing", I would do the 3.17 release about
three weeks from now, Oct 5th, and you would indeed be gone beginning
of the next merge window.

However, Oct 5th is also when I leave for LinuxCon EU, and while I am
willing to sometimes do the second week of the merge window while
traveling, doing the first week is just very impractical for me.
That's when most of the big pull requests get merged, and when I want
to do lots of allmodconfig builds etc, so doing it on the road is just
not worth it.

So right now my options are that
 (a) I can release 3.17 a week early (ie forego a rc7 entirely, and do
the final 3.17 late September) and then just do the second week while
traveling - something I've done many times or
 (b) just delay the merge window until after I come back (and whether
that then delays 3.17 or not is a largely independent issue).

3.17 looks fine so far, and so maybe "skip rc7" is an option. It is
the less likely one, I feel. I won't know until it happens, though.

So having the pull request available early for next merge window is
certainly much appreciated, but it may well be that you'll be back by
the time I actually open it.

I really have been cursed this year timing-wise wrt releases and
travel. I haven't even traveled any more than previous years, but for
some reason my travel dates have just been hitting the release dates
constantly.

> PS.  England and Italy for a holiday; my daughter chose them (somehow I
>  forgot to inform her of the existence of Euro Disney...)

Have fun.

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


Re: [virtio-dev] Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Paolo Bonzini
> On Do, 2014-09-11 at 16:20 +0100, Peter Maydell wrote:
> > On 11 September 2014 16:09, Gerd Hoffmann  wrote:
> > > This patch adds the header file with structs and defines for
> > > the virtio based gpu device.  Covers 2d operations only.
> > 
> > Please don't cc subscriber only mailing lists
> > (virtio-...@lists.oasis-open.org) on posts to qemu-devel;
> > it just means everybody responding gets mailer bounce
> > junkmail.
> 
> I don't feel like splitting the discussion though.  Suggestions how to
> deal with that?  I think I've seen most active virtio-dev folks on the
> virtualization list too, is it ok to just drop virtio-dev for the next
> round and hope that folks see it via virtualization list?

There's also virtio-comment.

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


Re: [Qemu-devel] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

2014-09-11 Thread Eric Blake
On 09/11/2014 09:09 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 
> ---
>  docs/specs/virtio-gpu.txt | 165 
> ++
>  1 file changed, 165 insertions(+)
>  create mode 100644 docs/specs/virtio-gpu.txt
> 
> diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt
> new file mode 100644
> index 000..9455383
> --- /dev/null
> +++ b/docs/specs/virtio-gpu.txt
> @@ -0,0 +1,165 @@
> +virtio-gpu specification

I know you are just following existing bad practice in this directory,
but it would be nice to declare copyright and license on this file.


> +
> +The two members events_read and events_clear are used to signal events
> +to the driver.  Currently one event is defined for a display
> +change. When a config space interrupt is received the driver should
> +read the events_read field.  The events processed should be written to
> +the events_clear field.  The device will clear the bits in events_read
> +then, mimicing write-to-clear behavior.

s/mimicing/mimicking/ (stupid English rule that any verb ending in 'ic'
becomes 'ick' when adding 'ed' or 'ing')

> +Both queues have the same format.  Each request and each response have
> +a fixed header (struct virtgpu_ctrl_hdr), followed by command specific
> +data fieds.  The separate cursor queue is the "fast track" for

s/fieds/fields/

> +The virtio-gpu is based around the concept of resources private to the
> +host, the guest must DMA transfer into these resources. This is a
> +design requirement in order to interface with future 3D rendering. In
> +the unaccelerated there is no support for DMA transfers from

s/unaccelerated/unaccelerated mode/

> +  This creates a 2D resource on the host with the specified width,
> +  height and format. Only a small subset of formats are support. The

s/support/supported/
and can you delineate that subset?


> +  This sets the scanout parameters for a single scanout. The
> +  resource_id is the resource to be scanned out from, along with a
> +  rectangle specified by x, y, width and height.

Is it worth a mention here or generically up front where 0,0 is in
relation to the screen, and in which direction positive numbers move?
I'm assuming 0,0 is top left, and larger x moves right, larger y moves down.

Are there restrictions against rectangles that overlap beyond screen
boundaries?


> +  This assign an array of guest pages (struct virtgpu_mem_entry) as

s/assign/assigns/

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Eric Blake
On 09/11/2014 09:09 AM, Gerd Hoffmann wrote:
> This patch adds the header file with structs and defines for
> the virtio based gpu device.  Covers 2d operations only.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/hw/virtio/virtgpu_hw.h | 158 
> +
>  1 file changed, 158 insertions(+)
>  create mode 100644 include/hw/virtio/virtgpu_hw.h
> 
> diff --git a/include/hw/virtio/virtgpu_hw.h b/include/hw/virtio/virtgpu_hw.h
> new file mode 100644
> index 000..461f452
> --- /dev/null
> +++ b/include/hw/virtio/virtgpu_hw.h
> @@ -0,0 +1,158 @@
> +#ifndef VIRTGPU_HW_H
> +#define VIRTGPU_HW_H

Non-trivial file, deserves a copyright and license notice.

> +
> +enum virtgpu_ctrl_type {
> +VIRTGPU_UNDEFINED = 0,
> +
> +/* 2d commands */
> +VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,

Please consider also adding:

#define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO

and friends.  It makes it MUCH nicer for application software to probe
for later extensions if every member of the enum is also associated with
a preprocessor macro.


> +
> +struct virtgpu_ctrl_hdr {
> +uint32_t type;
> +uint32_t flags;
> +uint64_t fence_id;
> +uint32_t ctx_id;
> +uint32_t padding;
> +};
> +

Is the padding to ensure that this is aligned regardless of 32-bit or
64-bit hosts?  Is it worth adding a compile-time assertion about the
size of the struct to ensure the compiler doesn't add any additional
padding?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Christopher Covington
On 09/11/2014 11:43 AM, Gerd Hoffmann wrote:
> On Do, 2014-09-11 at 16:20 +0100, Peter Maydell wrote:
>> On 11 September 2014 16:09, Gerd Hoffmann  wrote:
>>> This patch adds the header file with structs and defines for
>>> the virtio based gpu device.  Covers 2d operations only.
>>
>> Please don't cc subscriber only mailing lists
>> (virtio-...@lists.oasis-open.org) on posts to qemu-devel;
>> it just means everybody responding gets mailer bounce
>> junkmail.
> 
> I don't feel like splitting the discussion though.  Suggestions how to
> deal with that?  I think I've seen most active virtio-dev folks on the
> virtualization list too, is it ok to just drop virtio-dev for the next
> round and hope that folks see it via virtualization list?

Perhaps you and other subscribers to the offending list can BCC it and
announce that it's BCC'd body.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Gerd Hoffmann
On Do, 2014-09-11 at 16:20 +0100, Peter Maydell wrote:
> On 11 September 2014 16:09, Gerd Hoffmann  wrote:
> > This patch adds the header file with structs and defines for
> > the virtio based gpu device.  Covers 2d operations only.
> 
> Please don't cc subscriber only mailing lists
> (virtio-...@lists.oasis-open.org) on posts to qemu-devel;
> it just means everybody responding gets mailer bounce
> junkmail.

I don't feel like splitting the discussion though.  Suggestions how to
deal with that?  I think I've seen most active virtio-dev folks on the
virtualization list too, is it ok to just drop virtio-dev for the next
round and hope that folks see it via virtualization list?

cheers,
  Gerd


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


Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Gerd Hoffmann
  Hi,

> > +enum virtgpu_ctrl_type {
> > +VIRTGPU_UNDEFINED = 0,
> >
> 
> This is clearly all well out of line with our
> coding style guide, which isn't a terribly good start...

Oh yea, code style is fun.  This file is needed in both qemu & linux
kernel, which have different code styles.  I pipe it though a sed script
already when syncing them up, weeding out the tabs.  I'll go tweak my
script to fix the indent too.

cheers,
  Gerd


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


Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Peter Maydell
On 11 September 2014 16:09, Gerd Hoffmann  wrote:
> This patch adds the header file with structs and defines for
> the virtio based gpu device.  Covers 2d operations only.

Please don't cc subscriber only mailing lists
(virtio-...@lists.oasis-open.org) on posts to qemu-devel;
it just means everybody responding gets mailer bounce
junkmail.

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


Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Peter Maydell
On 11 September 2014 16:09, Gerd Hoffmann  wrote:
> This patch adds the header file with structs and defines for
> the virtio based gpu device.  Covers 2d operations only.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/hw/virtio/virtgpu_hw.h | 158 
> +
>  1 file changed, 158 insertions(+)
>  create mode 100644 include/hw/virtio/virtgpu_hw.h
>
> diff --git a/include/hw/virtio/virtgpu_hw.h b/include/hw/virtio/virtgpu_hw.h
> new file mode 100644
> index 000..461f452
> --- /dev/null
> +++ b/include/hw/virtio/virtgpu_hw.h
> @@ -0,0 +1,158 @@
> +#ifndef VIRTGPU_HW_H
> +#define VIRTGPU_HW_H
> +
> +enum virtgpu_ctrl_type {
> +VIRTGPU_UNDEFINED = 0,
>

This is clearly all well out of line with our
coding style guide, which isn't a terribly good start...

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


[PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

2014-09-11 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
 docs/specs/virtio-gpu.txt | 165 ++
 1 file changed, 165 insertions(+)
 create mode 100644 docs/specs/virtio-gpu.txt

diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt
new file mode 100644
index 000..9455383
--- /dev/null
+++ b/docs/specs/virtio-gpu.txt
@@ -0,0 +1,165 @@
+virtio-gpu specification
+
+
+virtio-gpu is a virtio based graphics adapter.  It can operate in 2D
+mode and in 3D (virgl) mode.  3D mode will offload rendering ops to
+the host gpu and therefore requires a gpu with 3D support on the host
+machine.
+
+The initial version will have 2D mode only.  It provides support for
+ARGB Hardware cursors and multiple scanouts (aka heads).
+
+
+features
+
+
+There are no feature bits (yet).
+There will be one in the future for 3D mode support.
+
+
+config space
+
+
+struct virtgpu_config {
+uint32_t events_read;
+uint32_t events_clear;
+uint32_t num_scanouts;
+uint32_t reserved;
+};
+
+The two members events_read and events_clear are used to signal events
+to the driver.  Currently one event is defined for a display
+change. When a config space interrupt is received the driver should
+read the events_read field.  The events processed should be written to
+the events_clear field.  The device will clear the bits in events_read
+then, mimicing write-to-clear behavior.
+
+num_scanouts specifies the number of scanouts supported by the device.
+
+The fourth field is reserved (3D mode will need this in the future).
+
+
+virt queues
+---
+
+The virtio-gpu exposes 2 virtio queues to the guest:
+
+ (1) control vq - guest->host queue for sending commands and getting
+ responses when required.
+ (2) cursor vq - guest->host queue for sending cursor position and
+ resource updates
+
+Both queues have the same format.  Each request and each response have
+a fixed header (struct virtgpu_ctrl_hdr), followed by command specific
+data fieds.  The separate cursor queue is the "fast track" for
+cursor-related commands, so they go though without being possibly
+delayed by other commands in the control queue.
+
+
+drive virtio-gpu in 2D mode
+---
+
+The virtio-gpu is based around the concept of resources private to the
+host, the guest must DMA transfer into these resources. This is a
+design requirement in order to interface with future 3D rendering. In
+the unaccelerated there is no support for DMA transfers from
+resources, just to them.
+
+Resources are initially simple 2D resources, consisting of a width,
+height and format along with an identifier. The guest must then attach
+backing store to the resources in order for DMA transfers to
+work. This is like a GART in a real GPU.
+
+A typical guest user would create a 2D resource using
+VIRTGPU_CMD_RESOURCE_CREATE_2D, attach backing store using
+VIRTGPU_CMD_RESOURCE_ATTACH_BACKING, then attach the resource to a
+scanout using VIRTGPU_CMD_SET_SCANOUT, then use
+VIRTGPU_CMD_TRANSFER_SEND_2D to send updates to the resource, and
+finally VIRTGPU_CMD_RESOURCE_FLUSH to flush the scanout buffers to
+screen.
+
+
+control queue commands (2D)
+---
+
+VIRTGPU_CMD_GET_DISPLAY_INFO:
+  Command: none (just struct virtgpu_ctrl_hdr).
+  Returns: struct virtgpu_resp_display_info.
+
+  Retrieve the current output configuration.
+
+VIRTGPU_CMD_RESOURCE_CREATE_2D:
+  Command: struct virtgpu_resource_create_2d
+
+  Create a 2D resource on the host.
+
+  This creates a 2D resource on the host with the specified width,
+  height and format. Only a small subset of formats are support. The
+  resource ids are generated by the guest.
+
+VIRTGPU_CMD_RESOURCE_UNREF:
+  Command: struct virtgpu_resource_unref
+
+  Destroy a resource.
+
+  This informs the host that a resource is no longer required by the
+  guest.
+
+VIRTGPU_CMD_SET_SCANOUT:
+  Command: struct virtgpu_set_scanout
+
+  Set the scanout parameters for a single output.
+
+  This sets the scanout parameters for a single scanout. The
+  resource_id is the resource to be scanned out from, along with a
+  rectangle specified by x, y, width and height.
+
+VIRTGPU_CMD_RESOURCE_FLUSH:
+  Command: struct virtgpu_resource_flush
+
+  Flush a scanout resource.
+
+  This flushes a resource to screen, it takes a rectangle and a
+  resource id, and flushes any scanouts the resource is being used on.
+
+VIRTGPU_CMD_TRANSFER_TO_HOST_2D:
+  Command: struct virtgpu_transfer_to_host_2d
+
+  Transfer from guest memory to host resource.
+
+  This takes a resource id along with an destination offset into the
+  resource, and a box to transfer from the host backing for the
+  resource.
+
+VIRTGPU_CMD_RESOURCE_ATTACH_BACKING:
+  Command: struct virtgpu_resource_attach_backing
+
+  Assign backing pages to a resource.
+
+  This assign an array of guest pages (struct virtgpu_mem_entry) as
+  the backing store for a resource. These

[PATCH 1/2] virtio-gpu/2d: add hardware spec include file

2014-09-11 Thread Gerd Hoffmann
This patch adds the header file with structs and defines for
the virtio based gpu device.  Covers 2d operations only.

Signed-off-by: Gerd Hoffmann 
---
 include/hw/virtio/virtgpu_hw.h | 158 +
 1 file changed, 158 insertions(+)
 create mode 100644 include/hw/virtio/virtgpu_hw.h

diff --git a/include/hw/virtio/virtgpu_hw.h b/include/hw/virtio/virtgpu_hw.h
new file mode 100644
index 000..461f452
--- /dev/null
+++ b/include/hw/virtio/virtgpu_hw.h
@@ -0,0 +1,158 @@
+#ifndef VIRTGPU_HW_H
+#define VIRTGPU_HW_H
+
+enum virtgpu_ctrl_type {
+VIRTGPU_UNDEFINED = 0,
+
+/* 2d commands */
+VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,
+VIRTGPU_CMD_RESOURCE_CREATE_2D,
+VIRTGPU_CMD_RESOURCE_UNREF,
+VIRTGPU_CMD_SET_SCANOUT,
+VIRTGPU_CMD_RESOURCE_FLUSH,
+VIRTGPU_CMD_TRANSFER_TO_HOST_2D,
+VIRTGPU_CMD_RESOURCE_ATTACH_BACKING,
+VIRTGPU_CMD_RESOURCE_INVAL_BACKING,
+
+/* cursor commands */
+VIRTGPU_CMD_UPDATE_CURSOR = 0x0300,
+VIRTGPU_CMD_MOVE_CURSOR,
+
+/* success responses */
+VIRTGPU_RESP_OK_NODATA = 0x1100,
+VIRTGPU_RESP_OK_DISPLAY_INFO,
+
+/* error responses */
+VIRTGPU_RESP_ERR_UNSPEC = 0x1200,
+};
+
+#define VIRTGPU_FLAG_FENCE (1 << 0)
+
+struct virtgpu_ctrl_hdr {
+uint32_t type;
+uint32_t flags;
+uint64_t fence_id;
+uint32_t ctx_id;
+uint32_t padding;
+};
+
+/* data passed in the cursor vq */
+
+struct virtgpu_cursor_pos {
+uint32_t scanout_id;
+uint32_t x, y;
+};
+
+/* VIRTGPU_CMD_UPDATE_CURSOR, VIRTGPU_CMD_MOVE_CURSOR */
+struct virtgpu_update_cursor {
+struct virtgpu_ctrl_hdr hdr;
+struct virtgpu_cursor_pos pos;  /* update & move */
+uint32_t resource_id;   /* update only */
+uint32_t hot_x, hot_y;  /* update only */
+};
+
+/* data passed in the control vq, 2d related */
+
+/* VIRTGPU_CMD_RESOURCE_UNREF */
+struct virtgpu_resource_unref {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+};
+
+/* VIRTGPU_CMD_RESOURCE_CREATE_2D: create a simple 2d resource with a format */
+struct virtgpu_resource_create_2d {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t format;
+uint32_t width;
+uint32_t height;
+};
+
+/* VIRTGPU_CMD_SET_SCANOUT */
+struct virtgpu_set_scanout {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t scanout_id;
+uint32_t resource_id;
+uint32_t width;
+uint32_t height;
+uint32_t x;
+uint32_t y;
+};
+
+/* VIRTGPU_CMD_RESOURCE_FLUSH */
+struct virtgpu_resource_flush {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t width;
+uint32_t height;
+uint32_t x;
+uint32_t y;
+};
+
+/* VIRTGPU_CMD_TRANSFER_TO_HOST_2D: simple transfer to_host */
+struct virtgpu_transfer_to_host_2d {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t offset;
+uint32_t width;
+uint32_t height;
+uint32_t x;
+uint32_t y;
+};
+
+struct virtgpu_mem_entry {
+uint64_t addr;
+uint32_t length;
+uint32_t pad;
+};
+
+/* VIRTGPU_CMD_RESOURCE_ATTACH_BACKING */
+struct virtgpu_resource_attach_backing {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t nr_entries;
+};
+
+/* VIRTGPU_CMD_RESOURCE_INVAL_BACKING */
+struct virtgpu_resource_inval_backing {
+struct virtgpu_ctrl_hdr hdr;
+uint32_t resource_id;
+};
+
+/* VIRTGPU_RESP_OK_DISPLAY_INFO */
+#define VIRTGPU_MAX_SCANOUTS 16
+struct virtgpu_resp_display_info {
+struct virtgpu_ctrl_hdr hdr;
+struct virtgpu_display_one {
+uint32_t enabled;
+uint32_t width;
+uint32_t height;
+uint32_t x;
+uint32_t y;
+uint32_t flags;
+} pmodes[VIRTGPU_MAX_SCANOUTS];
+};
+
+#define VIRTGPU_EVENT_DISPLAY (1 << 0)
+
+struct virtgpu_config {
+uint32_t events_read;
+uint32_t events_clear;
+uint32_t num_scanouts;
+uint32_t reserved;
+};
+
+/* simple formats for fbcon/X use */
+enum virtgpu_formats {
+VIRGL_FORMAT_B8G8R8A8_UNORM  = 1,
+VIRGL_FORMAT_B8G8R8X8_UNORM  = 2,
+VIRGL_FORMAT_A8R8G8B8_UNORM  = 3,
+VIRGL_FORMAT_X8R8G8B8_UNORM  = 4,
+
+VIRGL_FORMAT_B5G5R5A1_UNORM  = 5,
+VIRGL_FORMAT_B5G6R5_UNORM= 7,
+
+VIRGL_FORMAT_R8_UNORM= 64,
+};
+
+#endif
-- 
1.8.3.1

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


[PATCH 0/2] virtio-gpu: hardware specification

2014-09-11 Thread Gerd Hoffmann
  Hi folks,

Lets kick off the virtio-gpu review process, starting with the virtio
protocol.

This is a tiny patch series for qemu.  Patch #1 carries the header file
describing the virtual hardware: config space, command structs being
sent over the rings, defines etc.  Patch #2 adds a text file describing
virtio-gpu to docs/specs/.  It covers 2D support only for now.

For anybody who wants to dig a bit deeper:  Here are the branches for
qemu and the linux kernel:

  https://www.kraxel.org/cgit/qemu/log/?h=rebase/vga-wip
  https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase

The qemu patches are in a reasonable state.  The linux kernel patches
are not cleaned up yet, you probably want to look at the final tree
only.

Work has been done by Dave Airlie  and me.  The
authorship info in git got lost in the qemu patch cleanup process
though.  Suggestions how to handle that best?  Simply add both mine
and Dave's signed-off-by to all virtio-gpu qemu patches?  Is that fine
with you Dave?  Anyone has better ideas?

please review,
  Gerd Hoffmann

Gerd Hoffmann (2):
  virtio-gpu/2d: add hardware spec include file
  virtio-gpu/2d: add docs/specs/virtio-gpu.txt

 docs/specs/virtio-gpu.txt  | 165 +
 include/hw/virtio/virtgpu_hw.h | 158 +++
 2 files changed, 323 insertions(+)
 create mode 100644 docs/specs/virtio-gpu.txt
 create mode 100644 include/hw/virtio/virtgpu_hw.h

-- 
1.8.3.1

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


Re: [PATCH 2/2] virtio-rng: fix stuck in catting hwrng attributes

2014-09-11 Thread Rusty Russell
Amos Kong  writes:
> When I check hwrng attributes in sysfs, cat process always gets
> stuck if guest has only 1 vcpu and uses a slow rng backend.
>
> Currently we check if there is any tasks waiting to be run on
> current cpu in rng_dev_read() by need_resched(). But need_resched()
> doesn't work because rng_dev_read() is executing in user context.

I don't understand this explanation?  I'd expect the sysfs process to be
woken by the mutex_unlock().

If we're really high priority (vs. the sysfs process) then I can see why
we'd need schedule_timeout_interruptible() instead of just schedule(),
and in that case, need_resched() would be false too.

You could argue that's intended behaviour, but I can't see how it
happens in the normal case anyway.

What am I missing?

Thanks,
Rusty.

> This patch removed need_resched() and increase delay to 10 jiffies,
> then other tasks can have chance to execute protected code.
> Delaying 1 jiffy also works, but 10 jiffies is safer.
>
> Signed-off-by: Amos Kong 
> ---
>  drivers/char/hw_random/core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index c591d7e..b5d1b6f 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char 
> __user *buf,
>  
>   mutex_unlock(&rng_mutex);
>  
> - if (need_resched())
> - schedule_timeout_interruptible(1);
> + schedule_timeout_interruptible(10);
>  
>   if (signal_pending(current)) {
>   err = -ERESTARTSYS;
> -- 
> 1.9.3
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: Rusty away 18th September -- 11th October

2014-09-11 Thread Michael S. Tsirkin
On Thu, Sep 11, 2014 at 10:26:52AM +0930, Rusty Russell wrote:
> Hi all,
> 
> Probably won't read mail.  Linus, I'll have pull requests early
> next week; if there's anything needed I'm sure Michael Tsirkin can
> handle it.

Sure.
Rusty, there's a small chance virtio 1.0 bits will be ready in time.
I started working on them based on your virtio-pci-new-layout branch.

If ready before the merge window, are you ok with me merging this
support (without you having the opportunity to review first)?

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


blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)

2014-09-11 Thread Christian Borntraeger
Folks,

we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq 
rework that happened between 3.15 and 3.16, but it can be something completely 
different.


[   65.992022] Unable to handle kernel pointer dereference in virtual kernel 
address space
[   65.992187] failing address: d000 TEID: d803
[   65.992363] Fault in home space mode while using kernel ASCE.
[   65.992365] AS:00a7c007 R3:0024 
[   65.993754] Oops: 0038 [#1] SMP 
[   65.993923] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi virtio_balloon vhost_net vhost macvtap macvlan kvm 
dm_multipath virtio_net virtio_blk sunrpc
[   65.994274] CPU: 0 PID: 44 Comm: kworker/u6:2 Not tainted 
3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
[   65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
[   65.996222] task: 0225 ti: 02258000 task.ti: 
02258000
[   65.996228] Krnl PSW : 0704f0018000 003ed114 
(blk_mq_tag_to_rq+0x20/0x38)
[   65.997299]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 
EA:3
   Krnl GPRS: 0040  01619000 
004e
[   65.997301]004e  0001 
00a0de18
[   65.997302]77ffbe18 77ffbd50 6d72d620 
004f
[   65.997304]01a99400 0080 003eddee 
77ffbc28
[   65.997864] Krnl Code: 003ed106: e3102034lg  
%r1,48(%r2)
  003ed10c: 91082044tm  
68(%r2),8
 #003ed110: a7840009brc 8,3ed122
 >003ed114: e34016880004lg  
%r4,1672(%r1)
  003ed11a: 59304100c   
%r3,256(%r4)
  003ed11e: a7840003brc 8,3ed124
  003ed122: 07febcr 15,%r14
  003ed124: b9040024lgr %r2,%r4
[   65.998221] Call Trace:
[   65.998224] ([<0001>] 0x1)
[   65.998227]  [<003f17b6>] blk_mq_tag_busy_iter+0x7a/0xc4
[   65.998228]  [<003edcd6>] blk_mq_rq_timer+0x96/0x13c
[   65.999226]  [<0013ee60>] call_timer_fn+0x40/0x110
[   65.999230]  [<0013f642>] run_timer_softirq+0x2de/0x3d0
[   65.999238]  [<00135b70>] __do_softirq+0x124/0x2ac
[   65.999241]  [<00136000>] irq_exit+0xc4/0xe4
[   65.999435]  [<0010bc08>] do_IRQ+0x64/0x84
[   66.437533]  [<0067ccd8>] ext_skip+0x42/0x46
[   66.437541]  [<003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8
[   66.437544] ([<003ed788>] __blk_mq_alloc_request+0x2c/0x1e8)
[   66.437547]  [<003eef82>] blk_mq_map_request+0xc2/0x208
[   66.437549]  [<003ef860>] blk_sq_make_request+0xac/0x350
[   66.437721]  [<003e2d6c>] generic_make_request+0xc4/0xfc
[   66.437723]  [<003e2e56>] submit_bio+0xb2/0x1a8
[   66.438373]  [<0031e8aa>] ext4_io_submit+0x52/0x80
[   66.438375]  [<0031ccfa>] ext4_writepages+0x7c6/0xd0c
[   66.438378]  [<002aea20>] __writeback_single_inode+0x54/0x274
[   66.438379]  [<002b0134>] writeback_sb_inodes+0x28c/0x4ec
[   66.438380]  [<002b042e>] __writeback_inodes_wb+0x9a/0xe4
[   66.438382]  [<002b06a2>] wb_writeback+0x22a/0x358
[   66.438383]  [<002b0cd0>] bdi_writeback_workfn+0x354/0x538
[   66.438618]  [<0014e3aa>] process_one_work+0x1aa/0x418
[   66.438621]  [<0014ef94>] worker_thread+0x48/0x524
[   66.438625]  [<001560ca>] kthread+0xee/0x108
[   66.438627]  [<0067c76e>] kernel_thread_starter+0x6/0xc
[   66.438628]  [<0067c768>] kernel_thread_starter+0x0/0xc
[   66.438629] Last Breaking-Event-Address:
[   66.438631]  [<003edde8>] blk_mq_timeout_check+0x6c/0xb8

I looked into the dump, and the full function is  (annotated by me to match the 
source code)
r2= tags
r3= tag (4e)
Dump of assembler code for function blk_mq_tag_to_rq:
   0x003ed0f4 <+0>: lg  %r1,96(%r2) # r1 
has now tags->rqs
   0x003ed0fa <+6>: sllg%r2,%r3,3   # r2 
has tag*8
   0x003ed100 <+12>:lg  %r2,0(%r2,%r1)  # r2 
now has rq (=tags->rqs[tag])
   0x003ed106 <+18>:lg  %r1,48(%r2) # r1 
now has rq->q
   0x003ed10c <+24>:tm  68(%r2),8   # test 
for rq->cmd_flags & REQ_FLUSH_SEQ
   0x003ed110 <+28>:je  0x3ed122   #  if 
not goto 3ed122
   0x003ed114 <+32>:lg  %r4,1672(%r1)   # r4 = 
rq->q->flush_rq  < CRASHES as rq->q points to 
   0x003ed11a <+38>:c   %r3,256(%r4)# 
compare