Re: [PATCH v3 1/2] virtio-rng: fix stuck of hot-unplugging busy device
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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)
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
