similar to: [PATCH 4/4] lguest: GET_ID "support"

From 4780a4792ca7776268107e200ae77003c36d55c9 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Wed, 19 Dec 2007 23:52:43 +0200 Subject: [PATCH] virtio block device This patch implements the backend support for the virtio block device. It's designed to support in-order queueing of a virtually unlimited size so it will be able to perform better than SCSI. Besides

From 4780a4792ca7776268107e200ae77003c36d55c9 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Wed, 19 Dec 2007 23:52:43 +0200 Subject: [PATCH] virtio block device This patch implements the backend support for the virtio block device. It's designed to support in-order queueing of a virtually unlimited size so it will be able to perform better than SCSI. Besides

We never supported the ATA VIRTIO_BLK_F_IDENTIFY anyway, but simply including it in the struct definition broke us (see commit 8ef562d112 "lguest: fix descriptor corruption in example launcher"). Now we can acknowledge that it's deprecated, and get the struct without it. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 18

We never supported the ATA VIRTIO_BLK_F_IDENTIFY anyway, but simply including it in the struct definition broke us (see commit 8ef562d112 "lguest: fix descriptor corruption in example launcher"). Now we can acknowledge that it's deprecated, and get the struct without it. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 18

From 5d85cee1fb14608b79b5b6103d8be2d90bb76ca4 Mon Sep 17 00:00:00 2001 From: Anthony Liguori <aliguori@us.ibm.com> Date: Mon, 12 Nov 2007 21:30:26 -0600 Subject: [PATCH] virtio: simplify config mechanism. Previously we used a type/len pair within the config space, but this seems overkill. We now simply define a structure which represents the layout in the config space: the config space can

From 5d85cee1fb14608b79b5b6103d8be2d90bb76ca4 Mon Sep 17 00:00:00 2001 From: Anthony Liguori <aliguori@us.ibm.com> Date: Mon, 12 Nov 2007 21:30:26 -0600 Subject: [PATCH] virtio: simplify config mechanism. Previously we used a type/len pair within the config space, but this seems overkill. We now simply define a structure which represents the layout in the config space: the config space can

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe

Hi! Is it possible to somehow eliminate the use of the self.get_id''s in most situations? When you set up an event, you always must type sg. like evt_tree_key_down(self.get_id) {|e| where self.get_id can be the default or something... Gergo -- +-[ Kontra, Gergely<kgergely@mcl.hu> PhD student Room IB113 ]---------+ | http://www.mcl.hu/~kgergely "Olyan langesz

From 2334d90a3b9f8b9207163e9e0fad714e88a28771 Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Wed, 7 Nov 2007 21:02:22 +1100 Subject: [PATCH] virtio: An entropy device, as suggested by hpa. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- Documentation/lguest/lguest.c | 53 +++++++++++++++ drivers/char/hw_random/Kconfig | 10 +++

From 2334d90a3b9f8b9207163e9e0fad714e88a28771 Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Wed, 7 Nov 2007 21:02:22 +1100 Subject: [PATCH] virtio: An entropy device, as suggested by hpa. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- Documentation/lguest/lguest.c | 53 +++++++++++++++ drivers/char/hw_random/Kconfig | 10 +++

Since we disabled Nagle's algorithm we may send very small packets over the wire in some situations where we are calling send(2) from states that are responsible for small parts of the protocol. By setting the MSG_MORE flag we can indicate to the kernel that more data will follow (usually) immediately and so it can append the data to the same outgoing packet. Although there is some

This field contains optimization flags (ie. MSG_MORE) which are passed through to the socket layer if it supports them. The flags are reset automatically when we move to another state. --- generator/states.c | 6 ++++-- lib/internal.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/generator/states.c b/generator/states.c index e879a83..36cca37 100644 ---

Previously we performed a single call to recv(2) or send(2) (or the GnuTLS equivalents), and even if more data/space was immediately available to receive/send we would return to poll. Instead of this, loop until the socket returns EAGAIN. --- generator/states.c | 91 ++++++++++++++++++++++------------------------ 1 file changed, 43 insertions(+), 48 deletions(-) diff --git a/generator/states.c

There's an obvious bug in this patch in that it doesn't reset the h->wflags field in all cases. Updated patch below. I rechecked the performance measurements and they are the same after the updated patch. Rich. >From 15a687b50acecebcfd3dc6222d93e6df984b83c6 Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" <rjones@redhat.com> Date: Sat, 8 Jun 2019 19:12:22 +0100

As already noted in our state machine, a client that batches up a large read followed by large writes, coupled with a server that only processes commands in order, can result in deadlock (the server won't read more until we unblock its ability to write out its reply to our first command; but we aren't willing to read until we are done writing out our second command). Break the deadlock by

As already noted in our state machine, a client that batches up a large read followed by large writes, coupled with a server that only processes commands in order, can result in deadlock (the server won't read more until we unblock its ability to write out its reply to our first command; but we aren't willing to read until we are done writing out our second command). Break the deadlock by

Add an optional .send method flags parameter. This parameter may be ignored by the socket layer. If used it is intended to add optimization flags such as MSG_MORE for socket layers which can handle this. --- generator/states.c | 2 +- lib/crypto.c | 2 +- lib/internal.h | 2 +- lib/socket.c | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git

Just a simple refactoring in preparation for forthcoming work. --- generator/states-reply.c | 2 +- generator/states.c | 4 ++-- lib/crypto.c | 5 +++-- lib/internal.h | 6 ++++-- lib/socket.c | 5 +++-- 5 files changed, 13 insertions(+), 9 deletions(-) diff --git a/generator/states-reply.c b/generator/states-reply.c index 5be3431..f0ef47c 100644 ---

I took a stub at documenting CMD and FLUSH request types in virtio block. Christoph, could you look over this please? I note that the interface seems full of warts to me, this might be a first step to cleaning them. One issue I struggled with especially is how type field mixes bits and non-bit values. I ended up simply defining all legal values, so that we have CMD = 2, CMD_OUT = 3 and so on.