* Re: [PATCH] Add a page cache-backed balloon device driver.
From: Rusty Russell @ 2012-09-12 5:25 UTC (permalink / raw)
To: Mike Waychison, Michael S. Tsirkin
Cc: Frank Swiderski, Andrea Arcangeli, Rik van Riel, kvm,
linux-kernel@vger.kernel.org, virtualization
In-Reply-To: <CAGTjWtCiqjkR_Ze=0-ebO08+eziz6c8TXLb+O1iiArRQeSE6zw@mail.gmail.com>
Mike Waychison <mikew@google.com> writes:
> On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote:
>>> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>>> > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
>>> >> This implementation of a virtio balloon driver uses the page cache to
>>> >> "store" pages that have been released to the host. The communication
>>> >> (outside of target counts) is one way--the guest notifies the host when
>>> >> it adds a page to the page cache, allowing the host to madvise(2) with
>>> >> MADV_DONTNEED. Reclaim in the guest is therefore automatic and implicit
>>> >> (via the regular page reclaim). This means that inflating the balloon
>>> >> is similar to the existing balloon mechanism, but the deflate is
>>> >> different--it re-uses existing Linux kernel functionality to
>>> >> automatically reclaim.
>>> >>
>>> >> Signed-off-by: Frank Swiderski <fes@google.com>
>>>
>>> Hi Michael,
>>>
>>> I'm very sorry that Frank and I have been silent on these threads.
>>> I've been out of the office and Frank has been been swamped :)
>>>
>>> I'll take a stab at answering some of your questions below, and
>>> hopefully we can end up on the same page.
Hi Mike, Frank, Michael,
Thanks for the explanation and discussion. I like that this
implementation is more dynamic: the guest can use more pages for a while
(and the balloon kthread will furiously start trying to grab more pages
to give back). This part is a completely reasonable implementation, and
more sophisticated that what we have.
It doesn't *quite* meet the spec, because we don't notify the host when
we pull a page from the balloon, but I think that is quite possible. If
this is a performance waster, we should add a "SILENT_DEFLATE" feature
to tell the driver that it doesn't need to, though we should stll
support the !SILENT_DEFLATE case.
And Michael: thanks again for doing the heavy lifting on this!
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Rusty Russell @ 2012-09-12 5:49 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <504DC831.1000709@redhat.com>
Jason Wang <jasowang@redhat.com> writes:
> On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
>> A final addition: what you suggest above would be
>> "TX follows RX", right?
BTW, yes. But it's a weird way to express what the nic is doing.
>> It is in anticipation of something like that, that I made
>> steering programming so generic.
>> I think TX follows RX is more immediately useful for reasons above
>> but we can add both to spec and let drivers and devices
>> decide what they want to support.
You mean "RX follows TX"? ie. accelerated RFS. I agree.
Perhaps Tom can explain how we avoid out-of-order receive for the
accelerated RFS case? It's not clear to me, but we need to be able to
do that for virtio-net if it implements accelerated RFS.
> AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> and virtio-net is that ixgbe driver programs the flow director during
> packet transmission but we suggest to do it silently in the device for
> simplicity.
Implying the receive queue by xmit will be slightly laggy. Don't know
if that's a problem.
Cheers,
Rusty.
^ permalink raw reply
* Re: [RFCv3] virtio_console: Add support for virtio remoteproc serial
From: Rusty Russell @ 2012-09-12 6:00 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Sjur Brændeland, Linus Walleij, linux-kernel, virtualization,
Amit Shah, Sjur Brændeland
In-Reply-To: <1347290307-8155-1-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com writes:
> I actually like this new approach better.
> It solves the issues Michael has pointed out, and we don't have to
> think through side effects of weired combination of feature bits.
Agreed.
Just one thing, should it depend on CONFIG_REMOTEPROC? And have
OMAP_REMOTEPROC depend on CONFIG_HAS_DMA (if it doesn't already).
Thanks,
Rusty.
PS. I've reserved 11 for you in the latest virtio spec draft.
^ permalink raw reply
* Re: [PATCH v2 2/2] virtio-ring: Allocate indirect buffers from cache when possible
From: Rusty Russell @ 2012-09-12 6:13 UTC (permalink / raw)
To: Thomas Lendacky
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization, avi,
Sasha Levin
In-Reply-To: <14037987.hiN6MSGY6z@tomlt1.ibmoffice.com>
Thomas Lendacky <tahm@linux.vnet.ibm.com> writes:
> I ran some TCP_RR and TCP_STREAM sessions, both host-to-guest and
> guest-to-host, with a form of the histogram patch applied against a
> RHEL6.3 kernel. The histogram values were reset after each test.
Hey, thanks! This is exactly what I wanted to see...
> 60 session TCP_RR from host-to-guest with 256 byte request and 256 byte
> response for 60 seconds:
>
> Queue histogram for virtio1:
> Size distribution for input (max=7818456):
> 1: 7818456 ################################################################
These are always 1, so we don't indirect them anyway, so no cache required.
> Size distribution for output (max=7816698):
> 2: 149
> 3: 7816698 ################################################################
> 4: 2
> 5: 1
> Size distribution for control (max=1):
> 0: 0
OK, tiny TCP data, but latency sensitive.
> Queue histogram for virtio1:
> Size distribution for input (max=16050941):
> 1: 16050941 ################################################################
> Size distribution for output (max=1877796):
> 2: 1877796 ################################################################
> 3: 5
> Size distribution for control (max=1):
> 0: 0
Acks. Not that many, not that latency sensitive.
> 4 session TCP_STREAM from guest-to-host with 4K message size for 60 seconds:
>
> Queue histogram for virtio1:
> Size distribution for input (max=1316069):
> 1: 1316069 ################################################################
> Size distribution for output (max=879213):
> 2: 24
> 3: 24097 #
> 4: 23176 #
> 5: 3412
> 6: 4446
> 7: 4663
> 8: 4195
> 9: 3772
> 10: 3388
> 11: 3666
> 12: 2885
> 13: 2759
> 14: 2997
> 15: 3060
> 16: 2651
> 17: 2235
> 18: 92721 ######
> 19: 879213 ################################################################
Hey, that +1 is there in MAX_SKB_FRAGS for a reason! Who knew?
This looks like we could really use a:
int vq_set_indirect_cache(struct virtqueue *vq, unsigned num);
Which networking would set on the xmit queue(s) if we have GSO.
The real question is now whether we'd want a separate indirect cache for
the 3 case (so num above should be a bitmap?), or reuse the same one, or
not use it at all?
Benchmarking will tell...
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works
From: Rusty Russell @ 2012-09-12 6:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: fes, aarcange, riel, kvm, yvugenfi, linux-kernel, mikew, yinghan,
Paolo Bonzini, virtualization
In-Reply-To: <20120910055150.GA16819@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> We have several options:
> 1. No memory overcommit feature. This is always the case ATM!
> 2. Do not hot-plug assigned device.
> 3. Hot-unplug assigned device.
> 4. Some assigned devices can be able to handle memory errors
> e.g. using ATS. Limit hotplug to these.
OK, let's leave it alone, and the first person to try to implement it in
a device can figure out how to fall back.
I replied on the other thread: I think a SILENT_DEFLATE option is
a future optimization.
Cheers,
Rusty.
^ permalink raw reply
* Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation
From: Rusty Russell @ 2012-09-12 6:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sjur Brændeland, Linus Walleij, linux-kernel, virtualization,
Amit Shah
In-Reply-To: <20120910221111.GA21854@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
>> virtio: don't crash when device is buggy
>>
>> Because of a sanity check in virtio_dev_remove, a buggy device can crash
>> kernel. And in case of rproc it's userspace so it's not a good idea.
>> We are unloading a driver so how bad can it be?
>> Be less aggressive in handling this error: if it's a driver bug,
>> warning once should be enough.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> Rusty?
Thanks, applied.
I really want to implement CONFIG_VIRTIO_DEVEL_DEBUG which would
incorporate the checks in virtio_ring.c as well as this. Then I could
also reshuffle descriptors (eg. split them) to find buggy devices like
qemu which assume the first descriptor is the struct virtio_net_hdr...
Cheers,
Rusty,
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Michael S. Tsirkin @ 2012-09-12 7:57 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <87har3dc4o.fsf@rustcorp.com.au>
On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell wrote:
> Jason Wang <jasowang@redhat.com> writes:
> > On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
> >> A final addition: what you suggest above would be
> >> "TX follows RX", right?
>
> BTW, yes. But it's a weird way to express what the nic is doing.
It explains what the system is doing.
TX is done by driver, RX by nic.
We document both driver and device in the spec
so I thought it's fine. any suggestions wellcome.
> >> It is in anticipation of something like that, that I made
> >> steering programming so generic.
>
> >> I think TX follows RX is more immediately useful for reasons above
> >> but we can add both to spec and let drivers and devices
> >> decide what they want to support.
>
> You mean "RX follows TX"? ie. accelerated RFS. I agree.
Yes that's what I meant. Thanks for the correction.
> Perhaps Tom can explain how we avoid out-of-order receive for the
> accelerated RFS case? It's not clear to me, but we need to be able to
> do that for virtio-net if it implements accelerated RFS.
Basically this has tx vq per cpu and relies on scheduler not bouncing threads
between cpus too aggressively. Appears to be what ixgbe does.
> > AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> > and virtio-net is that ixgbe driver programs the flow director during
> > packet transmission but we suggest to do it silently in the device for
> > simplicity.
>
> Implying the receive queue by xmit will be slightly laggy. Don't know
> if that's a problem.
>
> Cheers,
> Rusty.
Doesn't seem to be a problem in Jason's testing so far.
^ permalink raw reply
* Re: [PATCH v2 2/2] virtio-ring: Allocate indirect buffers from cache when possible
From: Sasha Levin @ 2012-09-12 10:44 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization, avi,
Thomas Lendacky
In-Reply-To: <87bohbdb0o.fsf@rustcorp.com.au>
On 09/12/2012 08:13 AM, Rusty Russell wrote:
> The real question is now whether we'd want a separate indirect cache for
> the 3 case (so num above should be a bitmap?), or reuse the same one, or
> not use it at all?
>
> Benchmarking will tell...
Since there are no specific decisions about actual values, I'll just modify the
code to use cache per-vq instead of per-device.
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Tom Herbert @ 2012-09-12 14:38 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, netdev, rick.jones2, virtualization,
levinsasha928, pbonzini
In-Reply-To: <87har3dc4o.fsf@rustcorp.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 2086 bytes --]
On Tue, Sep 11, 2012 at 10:49 PM, Rusty Russell <rusty@rustcorp.com.au>wrote:
> Jason Wang <jasowang@redhat.com> writes:
> > On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
> >> A final addition: what you suggest above would be
> >> "TX follows RX", right?
>
> BTW, yes. But it's a weird way to express what the nic is doing.
>
> >> It is in anticipation of something like that, that I made
> >> steering programming so generic.
>
> >> I think TX follows RX is more immediately useful for reasons above
> >> but we can add both to spec and let drivers and devices
> >> decide what they want to support.
>
> You mean "RX follows TX"? ie. accelerated RFS. I agree.
>
> RX following TX is logic of flow director I believe. {a}RFS has RX follow
CPU where application receive is done on the socket. So in RFS there is no
requirement to have a 1-1 correspondence between TX and RX queues, and in
fact this allows different number of queues between TX and RX. We found
this necessary when using priority HW queues, so that there are more TX
queues than RX.
Perhaps Tom can explain how we avoid out-of-order receive for the
> accelerated RFS case? It's not clear to me, but we need to be able to
> do that for virtio-net if it implements accelerated RFS.
>
> AFAIK ooo RX is possible with accelerated RFS. We have an algorithm that
prevents this for RFS case by deferring a migration to a new queue as long
as it's possible that a flow might have outstanding packets on the old
queue. I suppose this could be implemented in the device for the HW
queues, but I don't think it would be easy to cover all cases where packets
were already in transit to the host or other cases where host and device
queues are out of sync.
> > AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> > and virtio-net is that ixgbe driver programs the flow director during
> > packet transmission but we suggest to do it silently in the device for
> > simplicity.
>
> Implying the receive queue by xmit will be slightly laggy. Don't know
> if that's a problem.
>
> Cheers,
> Rusty.
>
[-- Attachment #1.2: Type: text/html, Size: 2944 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: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Tom Herbert @ 2012-09-12 14:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: rick.jones2, kvm, netdev, virtualization, levinsasha928, pbonzini
In-Reply-To: <20120912075737.GA30455@redhat.com>
On Wed, Sep 12, 2012 at 12:57 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell wrote:
>> Jason Wang <jasowang@redhat.com> writes:
>> > On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
>> >> A final addition: what you suggest above would be
>> >> "TX follows RX", right?
>>
>> BTW, yes. But it's a weird way to express what the nic is doing.
>
> It explains what the system is doing.
> TX is done by driver, RX by nic.
> We document both driver and device in the spec
> so I thought it's fine. any suggestions wellcome.
>
>> >> It is in anticipation of something like that, that I made
>> >> steering programming so generic.
>>
>> >> I think TX follows RX is more immediately useful for reasons above
>> >> but we can add both to spec and let drivers and devices
>> >> decide what they want to support.
>>
>> You mean "RX follows TX"? ie. accelerated RFS. I agree.
>
RX following TX is logic of flow director I believe. {a}RFS has RX
follow CPU where application receive is done on the socket. So in RFS
there is no requirement to have a 1-1 correspondence between TX and RX
queues, and in fact this allows different number of queues between TX
and RX. We found this necessary when using priority HW queues, so
that there are more TX queues than RX.
>
> Yes that's what I meant. Thanks for the correction.
>
>> Perhaps Tom can explain how we avoid out-of-order receive for the
>> accelerated RFS case? It's not clear to me, but we need to be able to
>> do that for virtio-net if it implements accelerated RFS.
>
AFAIK ooo RX is still possible with accelerated RFS. We have an
algorithm that prevents this for RFS by deferring a migration to a new
queue as long as it's possible that a flow might have outstanding
packets on the old queue. I suppose this could be implemented in the
device for the HW queues, but I don't think it would be easy to cover
all cases where packets were already in transit to the host or other
cases where host and device queues are out of sync.
> Basically this has tx vq per cpu and relies on scheduler not bouncing threads
> between cpus too aggressively. Appears to be what ixgbe does.
>
>> > AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
>> > and virtio-net is that ixgbe driver programs the flow director during
>> > packet transmission but we suggest to do it silently in the device for
>> > simplicity.
>>
>> Implying the receive queue by xmit will be slightly laggy. Don't know
>> if that's a problem.
>>
>> Cheers,
>> Rusty.
>
> Doesn't seem to be a problem in Jason's testing so far.
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Ben Hutchings @ 2012-09-12 19:11 UTC (permalink / raw)
To: Tom Herbert
Cc: rick.jones2, kvm, Michael S. Tsirkin, netdev, virtualization,
levinsasha928, pbonzini
In-Reply-To: <CA+mtBx9NB=t=3YAB=MdRY_6hMe9J=z4U9o-pPe3iYfmxkeKJRw@mail.gmail.com>
On Wed, 2012-09-12 at 07:40 -0700, Tom Herbert wrote:
> On Wed, Sep 12, 2012 at 12:57 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell wrote:
[...]
> >> Perhaps Tom can explain how we avoid out-of-order receive for the
> >> accelerated RFS case? It's not clear to me, but we need to be able to
> >> do that for virtio-net if it implements accelerated RFS.
> >
> AFAIK ooo RX is still possible with accelerated RFS. We have an
> algorithm that prevents this for RFS by deferring a migration to a new
> queue as long as it's possible that a flow might have outstanding
> packets on the old queue. I suppose this could be implemented in the
> device for the HW queues, but I don't think it would be easy to cover
> all cases where packets were already in transit to the host or other
> cases where host and device queues are out of sync.
[...]
Yes, I couldn't see any way to eliminate the possibility of OOO. The
software queue check in RFS should redirect the flow only when it is new
or has had an idle period, when I hope only a few packets will be
received before we send some kind of response (transport or application
layer ACK). So I think that OOO is not that likely in practice, but I
don't have the evidence to back that up.
If the filter update latency is high enough that a response can overtake
the filter update, there may be more of a problem.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* potential integer overflow in xenbus_file_write()
From: Dan Carpenter @ 2012-09-13 16:00 UTC (permalink / raw)
To: virtualization
Hi,
I was reading some code and had a question in xenbus_file_write()
drivers/xen/xenbus/xenbus_dev_frontend.c
461 if ((len + u->len) > sizeof(u->u.buffer)) {
^^^^^^^^^^^^
Can this addition overflow? Should the test be something like:
if (len > sizeof(u->u.buffer) || len + u->len > sizeof(u->u.buffer)) {
462 /* On error, dump existing buffer */
463 u->len = 0;
464 rc = -EINVAL;
465 goto out;
466 }
467
468 ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
469
regards,
dan carpenter
^ permalink raw reply
* [PATCH] virtio_console: Add support for remoteproc serial
From: sjur.brandeland @ 2012-09-13 18:04 UTC (permalink / raw)
To: Rusty Russell
Cc: Sjur Brændeland, Michael S. Tsirkin, Linus Walleij,
linux-kernel, virtualization, Amit Shah, Sjur Brændeland
In-Reply-To: <1347559440-6668-1-git-send-email-sjur.brandeland@stericsson.com>
From: Sjur Brændeland <sjur.brandeland@stericsson.com>
Add a virtio remoteproc serial driver: VIRTIO_ID_RPROC_SERIAL (0xB)
for communicating with a remote processor in an asymmetric
multi-processing configuration.
The virtio remoteproc serial driver reuses the existing virtio_console
implementation, and adds support for DMA allocation of data buffers
but disables support for tty console, mutiple ports, and the control queue.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Michael S. Tsirkin <mst@redhat.com>
cc: Amit Shah <amit.shah@redhat.com>
cc: Ohad Ben-Cohen <ohad@wizery.com>
cc: Linus Walleij <linus.walleij@linaro.org>
cc: virtualization@lists.linux-foundation.org
cc: linux-kernel@vger.kernel.org
>Just one thing, should it depend on CONFIG_REMOTEPROC? And have
>OMAP_REMOTEPROC depend on CONFIG_HAS_DMA (if it doesn't already).
I have changed to use CONFIG_REMOTEPROC_MODULE now. I'll send a patch
to Ohad adding an explicit dependency to HAS_DMA for remoteproc.
>PS. I've reserved 11 for you in the latest virtio spec draft.
Ok, I'll look into updating the spec.
Thanks,
Sjur
drivers/char/virtio_console.c | 137 +++++++++++++++++++++++++++++++++--------
include/linux/virtio_ids.h | 1 +
2 files changed, 112 insertions(+), 26 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index cdf2f54..7c697ca 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -35,6 +35,8 @@
#include <linux/wait.h>
#include <linux/workqueue.h>
#include <linux/module.h>
+#include <linux/dma-mapping.h>
+#include <linux/kconfig.h>
#include "../tty/hvc/hvc_console.h"
/*
@@ -323,6 +325,52 @@ static bool is_console_port(struct port *port)
return false;
}
+#ifdef CONFIG_REMOTEPROC_MODULE
+static inline bool is_rproc_serial(struct virtio_device *vdev)
+{
+ return vdev->id.device == VIRTIO_ID_RPROC_SERIAL;
+}
+#else
+static inline bool is_rproc_serial(struct virtio_device *vdev)
+{
+ return false;
+}
+#endif
+
+/* Allocate data buffer from DMA memory if requested */
+static inline void *
+alloc_databuf(struct virtio_device *vdev, size_t size, gfp_t flag)
+{
+ if (is_rproc_serial(vdev)) {
+ dma_addr_t dma;
+ struct device *dev = &vdev->dev;
+ /*
+ * Allocate DMA memory from ancestors. Finding the ancestor
+ * is a bit quirky when DMA_MEMORY_INCLUDES_CHILDREN is not
+ * implemented.
+ */
+ dev = dev->parent ? dev->parent : dev;
+ dev = dev->parent ? dev->parent : dev;
+ return dma_alloc_coherent(dev, size, &dma, flag);
+ }
+ return kmalloc(size, flag);
+}
+
+static inline void
+free_databuf(struct virtio_device *vdev, size_t size, void *cpu_addr)
+{
+
+ if (is_rproc_serial(vdev)) {
+ struct device *dev = &vdev->dev;
+ dma_addr_t dma_handle = virt_to_bus(cpu_addr);
+ dev = dev->parent ? dev->parent : dev;
+ dev = dev->parent ? dev->parent : dev;
+ dma_free_coherent(dev, size, cpu_addr, dma_handle);
+ return;
+ }
+ kfree(cpu_addr);
+}
+
static inline bool use_multiport(struct ports_device *portdev)
{
/*
@@ -334,20 +382,22 @@ static inline bool use_multiport(struct ports_device *portdev)
return portdev->vdev->features[0] & (1 << VIRTIO_CONSOLE_F_MULTIPORT);
}
-static void free_buf(struct port_buffer *buf)
+static void
+free_buf(struct virtqueue *vq, struct port_buffer *buf, size_t buf_size)
{
- kfree(buf->buf);
+ free_databuf(vq->vdev, buf_size, buf->buf);
kfree(buf);
}
-static struct port_buffer *alloc_buf(size_t buf_size)
+static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size)
{
struct port_buffer *buf;
buf = kmalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
goto fail;
- buf->buf = kzalloc(buf_size, GFP_KERNEL);
+ buf->buf = alloc_databuf(vq->vdev, buf_size, GFP_KERNEL);
+ memset(buf->buf, 0, buf_size);
if (!buf->buf)
goto free_buf;
buf->len = 0;
@@ -414,7 +464,7 @@ static void discard_port_data(struct port *port)
port->stats.bytes_discarded += buf->len - buf->offset;
if (add_inbuf(port->in_vq, buf) < 0) {
err++;
- free_buf(buf);
+ free_buf(port->in_vq, buf, PAGE_SIZE);
}
port->inbuf = NULL;
buf = get_inbuf(port);
@@ -485,7 +535,7 @@ static void reclaim_consumed_buffers(struct port *port)
return;
}
while ((buf = virtqueue_get_buf(port->out_vq, &len))) {
- kfree(buf);
+ free_databuf(port->portdev->vdev, len, buf);
port->outvq_full = false;
}
}
@@ -672,6 +722,7 @@ static ssize_t port_fops_write(struct file *filp, const char __user *ubuf,
char *buf;
ssize_t ret;
bool nonblock;
+ struct virtio_device *vdev;
/* Userspace could be out to fool us */
if (!count)
@@ -694,9 +745,10 @@ static ssize_t port_fops_write(struct file *filp, const char __user *ubuf,
if (!port->guest_connected)
return -ENODEV;
+ vdev = port->portdev->vdev;
count = min((size_t)(32 * 1024), count);
- buf = kmalloc(count, GFP_KERNEL);
+ buf = alloc_databuf(vdev, count, GFP_KERNEL);
if (!buf)
return -ENOMEM;
@@ -720,7 +772,7 @@ static ssize_t port_fops_write(struct file *filp, const char __user *ubuf,
goto out;
free_buf:
- kfree(buf);
+ free_databuf(vdev, count, buf);
out:
return ret;
}
@@ -918,7 +970,8 @@ static void resize_console(struct port *port)
return;
vdev = port->portdev->vdev;
- if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE))
+ if (!is_rproc_serial(vdev) &&
+ virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE))
hvc_resize(port->cons.hvc, port->cons.ws);
}
@@ -1102,7 +1155,7 @@ static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
nr_added_bufs = 0;
do {
- buf = alloc_buf(PAGE_SIZE);
+ buf = alloc_buf(vq, PAGE_SIZE);
if (!buf)
break;
@@ -1110,7 +1163,7 @@ static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
ret = add_inbuf(vq, buf);
if (ret < 0) {
spin_unlock_irq(lock);
- free_buf(buf);
+ free_buf(vq, buf, PAGE_SIZE);
break;
}
nr_added_bufs++;
@@ -1198,10 +1251,18 @@ static int add_port(struct ports_device *portdev, u32 id)
goto free_device;
}
- /*
- * If we're not using multiport support, this has to be a console port
- */
- if (!use_multiport(port->portdev)) {
+ if (is_rproc_serial(port->portdev->vdev))
+ /*
+ * For rproc_serial assume remote processor is connected.
+ * rproc_serial does not want the console port, but
+ * the generic port implementation.
+ */
+ port->host_connected = true;
+ else if (!use_multiport(port->portdev)) {
+ /*
+ * If we're not using multiport support,
+ * this has to be a console port.
+ */
err = init_port_console(port);
if (err)
goto free_inbufs;
@@ -1234,7 +1295,7 @@ static int add_port(struct ports_device *portdev, u32 id)
free_inbufs:
while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
- free_buf(buf);
+ free_buf(port->in_vq, buf, PAGE_SIZE);
free_device:
device_destroy(pdrvdata.class, port->dev->devt);
free_cdev:
@@ -1276,7 +1337,7 @@ static void remove_port_data(struct port *port)
/* Remove buffers we queued up for the Host to send us data in. */
while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
- free_buf(buf);
+ free_buf(port->in_vq, buf, PAGE_SIZE);
}
/*
@@ -1478,7 +1539,7 @@ static void control_work_handler(struct work_struct *work)
if (add_inbuf(portdev->c_ivq, buf) < 0) {
dev_warn(&portdev->vdev->dev,
"Error adding buffer to queue\n");
- free_buf(buf);
+ free_buf(portdev->c_ivq, buf, PAGE_SIZE);
}
}
spin_unlock(&portdev->cvq_lock);
@@ -1674,10 +1735,10 @@ static void remove_controlq_data(struct ports_device *portdev)
return;
while ((buf = virtqueue_get_buf(portdev->c_ivq, &len)))
- free_buf(buf);
+ free_buf(portdev->c_ivq, buf, PAGE_SIZE);
while ((buf = virtqueue_detach_unused_buf(portdev->c_ivq)))
- free_buf(buf);
+ free_buf(portdev->c_ivq, buf, PAGE_SIZE);
}
/*
@@ -1688,7 +1749,7 @@ static void remove_controlq_data(struct ports_device *portdev)
* config space to see how many ports the host has spawned. We
* initialize each port found.
*/
-static int __devinit virtcons_probe(struct virtio_device *vdev)
+static int virtcons_probe(struct virtio_device *vdev)
{
struct ports_device *portdev;
int err;
@@ -1724,10 +1785,12 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
multiport = false;
portdev->config.max_nr_ports = 1;
- if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT,
- offsetof(struct virtio_console_config,
- max_nr_ports),
- &portdev->config.max_nr_ports) == 0)
+ if (is_rproc_serial(vdev))
+ multiport = false;
+ else if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT,
+ offsetof(struct virtio_console_config,
+ max_nr_ports),
+ &portdev->config.max_nr_ports) == 0)
multiport = true;
err = init_vqs(portdev);
@@ -1838,6 +1901,16 @@ static unsigned int features[] = {
VIRTIO_CONSOLE_F_MULTIPORT,
};
+static struct virtio_device_id rproc_serial_id_table[] = {
+#ifdef CONFIG_REMOTEPROC_MODULE
+ { VIRTIO_ID_RPROC_SERIAL, VIRTIO_DEV_ANY_ID },
+#endif
+ { 0 },
+};
+
+static unsigned int rproc_serial_features[] = {
+};
+
#ifdef CONFIG_PM
static int virtcons_freeze(struct virtio_device *vdev)
{
@@ -1922,6 +1995,16 @@ static struct virtio_driver virtio_console = {
#endif
};
+static struct virtio_driver virtio_rproc_serial = {
+ .feature_table = rproc_serial_features,
+ .feature_table_size = ARRAY_SIZE(rproc_serial_features),
+ .driver.name = "virtio_rproc_serial",
+ .driver.owner = THIS_MODULE,
+ .id_table = rproc_serial_id_table,
+ .probe = virtcons_probe,
+ .remove = virtcons_remove,
+};
+
static int __init init(void)
{
int err;
@@ -1941,12 +2024,14 @@ static int __init init(void)
INIT_LIST_HEAD(&pdrvdata.consoles);
INIT_LIST_HEAD(&pdrvdata.portdevs);
- return register_virtio_driver(&virtio_console);
+ return register_virtio_driver(&virtio_console) &&
+ register_virtio_driver(&virtio_rproc_serial);
}
static void __exit fini(void)
{
unregister_virtio_driver(&virtio_console);
+ unregister_virtio_driver(&virtio_rproc_serial);
class_destroy(pdrvdata.class);
if (pdrvdata.debugfs_dir)
diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h
index 270fb22..07cf6f7 100644
--- a/include/linux/virtio_ids.h
+++ b/include/linux/virtio_ids.h
@@ -37,5 +37,6 @@
#define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */
#define VIRTIO_ID_SCSI 8 /* virtio scsi */
#define VIRTIO_ID_9P 9 /* 9p virtio console */
+#define VIRTIO_ID_RPROC_SERIAL 0xB /* virtio remoteproc serial link */
#endif /* _LINUX_VIRTIO_IDS_H */
--
1.7.5.4
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [PATCH 0/5] vhost-scsi: Add support for host virtualized target
From: Nicholas A. Bellinger @ 2012-09-13 20:12 UTC (permalink / raw)
To: Asias He
Cc: Stefan Hajnoczi, kvm-devel, Michael S. Tsirkin, Jan Kiszka,
qemu-devel, Zhi Yong Wu, Anthony Liguori, target-devel,
Paolo Bonzini, lf-virt, Christoph Hellwig
In-Reply-To: <504EBFD5.6050203@redhat.com>
On Tue, 2012-09-11 at 12:36 +0800, Asias He wrote:
> Hello Nicholas,
>
Hello Asias!
> On 09/07/2012 02:48 PM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> >
> > Hello Anthony & Co,
> >
> > This is the fourth installment to add host virtualized target support for
> > the mainline tcm_vhost fabric driver using Linux v3.6-rc into QEMU 1.3.0-rc.
> >
> > The series is available directly from the following git branch:
> >
> > git://git.kernel.org/pub/scm/virt/kvm/nab/qemu-kvm.git vhost-scsi-for-1.3
> >
> > Note the code is cut against yesterday's QEMU head, and dispite the name
> > of the tree is based upon mainline qemu.org git code + has thus far been
> > running overnight with > 100K IOPs small block 4k workloads using v3.6-rc2+
> > based target code with RAMDISK_DR backstores.
>
> Are you still seeing the performance degradation discussed in the thread
>
> "vhost-scsi port to v1.1.0 + MSI-X performance regression"
>
So the performance regression reported here with QEMU v1.2-rc +
virtio-scsi ended up being related to virtio interrupts being delivered
across multiple CPUs.
After explicitly setting the IRQ affinity of the virtio0-request MSI-X
vector to a specific CPU, the small block (4k) mixed random I/O
performance jumped back up to the expected ~100K IOPs for a single LUN.
FYI, I just tried this again with the most recent QEMU v1.2.50 (v1.3-rc)
code, and both cases appear to be performing as expected once again
regardless of the explicit IRQ affinity setting.
--nab
^ permalink raw reply
* Re: [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
From: Nicholas A. Bellinger @ 2012-09-13 22:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, Stefan Hajnoczi, kvm-devel, Jan Kiszka,
qemu-devel, lf-virt, Anthony Liguori, target-devel, Paolo Bonzini,
Zhi Yong Wu, Christoph Hellwig
In-Reply-To: <20120911150757.GA26666@redhat.com>
On Tue, 2012-09-11 at 18:07 +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 11, 2012 at 08:46:34AM -0500, Anthony Liguori wrote:
> > On 09/10/2012 01:24 AM, Michael S. Tsirkin wrote:
> > >On Mon, Sep 10, 2012 at 08:16:54AM +0200, Paolo Bonzini wrote:
> > >>Il 09/09/2012 00:40, Michael S. Tsirkin ha scritto:
> > >>>On Fri, Sep 07, 2012 at 06:00:50PM +0200, Paolo Bonzini wrote:
<SNIP>
> > >>>>Please create a completely separate device vhost-scsi-pci instead (or
> > >>>>virtio-scsi-tcm-pci, or something like that). It is used completely
> > >>>>differently from virtio-scsi-pci, it does not make sense to conflate the
> > >>>>two.
> > >>>
> > >>>Ideally the name would say how it is different, not what backend it
> > >>>uses. Any good suggestions?
> > >>
> > >>I chose the backend name because, ideally, there would be no other
> > >>difference. QEMU _could_ implement all the goodies in vhost-scsi (such
> > >>as reservations or ALUA), it just doesn't do that yet.
> > >>
> > >>Paolo
> > >
> > >Then why do you say "It is used completely differently from
> > >virtio-scsi-pci"? Isn't it just a different backend?
> > >
> > >If yes then it should be a backend option, like it is
> > >for virtio-net.
> >
> > I don't mean to bike shed here so don't take this as a nack on
> > making it a backend option, but in retrospect, the way we did
> > vhost-net was a mistake even though I strongly advocated for it to
> > be a backend option.
> >
> > The code to do it is really, really ugly. I think it would have
> > made a lot more sense to just make it a device and then have it not
> > use a netdev backend or any other kind of backend split.
> >
> > For instance:
> >
> > qemu -device vhost-net-pci,tapfd=X
> >
> > I know this breaks the model of separate backends and frontends but
> > since vhost-net absolutely requires a tap fd, I think it's better in
> > the long run to not abuse the netdev backend to prevent user
> > confusion. Having a dedicated backend type that only has one
> > possible option and can only be used by one device is a bit silly
> > too.
> >
> > So I would be in favor of dropping/squashing 3/5 and radically
> > simplifying how this was exposed to the user.
> >
> > I would just take qemu_vhost_scsi_opts and make them device properties.
> >
> > Regards,
> >
> > Anthony Liguori
>
> I'd like to clarify that I'm fine with either approach.
> Even a separate device is OK if this is what others want
> though I like it the least.
>
Hi MST, Paolo & Co,
I've been out the better part of the week with the flu, and am just now
catching up on emails from the last days..
So to better understand the reasoning for adding an separate PCI device
for vhost-scsi ahead of implementing the code changes, here are main
points from folk's comments:
*) Convert vhost-scsi into a separate standalone vhost-scsi-pci device
- Lets userspace know that virtio-scsi + QEMU block and virtio-scsi +
tcm_vhost do not track SCSI state (such as reservations + ALUA), and
hence are not interchangeable during live-migration.
- Reduces complexity of adding vhost-scsi related logic into existing
virtio-scsi-pci code path.
- Having backends with one possible option doesn’t make much sense.
*) Keep vhost-scsi as a backend to virtio-scsi-pci
- Reduces duplicated code amongst multiple virtio-scsi backends.
- Follows the split for what existing vhost-net code already does.
So that said, two quick questions for Paolo & Co..
For the standalone vhost-scsi-pci device case, can you give a brief idea
as to what extent you'd like to see virtio-scsi.c code/defs duplicated
and/or shared amongst a new vhost-scsi-pci device..?
Also to help me along, can you give an example based on the current
usage below how the QEMU command line arguments would change with a
standalone vhost-scsi-pci device..?
./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \
-hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \
-vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 \
-device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off
Thank you!
--nab
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: oVirt Workshop Europe 2012: Call For Participation
From: workshop-pc @ 2012-09-13 22:30 UTC (permalink / raw)
To: announce, users, engine-devel, vdsm-devel, virtualization; +Cc: workshop-pc
In-Reply-To: <20120814214405.GN20407@x200.localdomain>
* workshop-pc@ovirt.org (workshop-pc@ovirt.org) wrote:
> =================================================================
> oVirt Workshop Europe 2012: Call For Participation
> November 7-9, 2012 - Hotel Fira Palace - Barcelona, Spain
>
> (All submissions must be received before midnight Sep 14th, 2012)
> =================================================================
The submission deadline is being pushed out one week to Sep 21st, 2012.
There was a glitch in the CFP system causing the oVirt Workshop option
during CFP submission to disappear. It has been fixed and we're going
to extend the submission deadline by one week to accommodate. If you
were having trouble submitting a proposal, please try again. Sorry for
any inconvenience.
> The oVirt Project is an open virtualization project for anyone who cares
> about Linux-based KVM virtualization. Providing a feature-rich server
> virtualization management system with advanced capabilities for hosts
> and guests, including high availability, live migration, storage
> management, system scheduler, and more. By open we mean open source &
> open governance, done right.
>
> During this workshop you’ll learn about the technical background and
> direction of the oVirt project. You’ll meet the developers, and have an
> opportunity to see and dive into the code right away. The workshop is
> open to all who want to use, get involved with, or learn about the
> comprehensive open virtualization management platform, oVirt. The
> sessions cover the technical projects details, governance, getting
> involved, usage, and much more. If you have any interest in an Open
> Virtualization Management platform, this workshop is for you!
>
> We are excited to announce that this oVirt Workshop will be held in
> conjunction with the KVM Forum.
>
> http://events.linuxfoundation.org/events/kvm-forum/
>
> The KVM Forum and oVirt Workshop are co-located with the Linux
> Foundation's 2012 LinuxCon Europe in Barcelona, Spain.
>
> oVirt Workshop attendees will be able to attend KVM Forum sessions and
> are eligible to attend LinuxCon Europe for a discounted rate.
>
> http://events.linuxfoundation.org/events/kvm-forum/register
>
> We invite you to lead part of the discussion by submitting a speaking
> proposal for oVirt Workshop 2012.
>
> http://events.linuxfoundation.org/cfp
>
> Suggested topics:
>
> - community use case/stories
> - roadmaps
> - deep dives into features/areas
> - deep dives into code/debugging/tuning
> - integration and extensions
> - components: engine, vdsm, node, sdk/cli, reports, mom, guest agent, etc.
> - subjects: network, storage, vm life cycle, scheduling & sla, gluster, etc.
> - packaging, installation and distributions
> - community infrastructure and services
>
> SUBMISSION REQUIREMENTS
>
> Abstracts due: Sep 14th, 2012
> Notification: Sep 28th, 2012
>
> Please submit a short abstract (~150 words) describing your presentation
> proposal. In your submission please note how long your talk will take.
> Slots vary in length up to 45 minutes. Also include in your proposal
> the proposal type -- one of:
>
> - technical talk
> - end-user talk
> - birds of a feather (BOF) session
>
> Submit your proposal here:
>
> http://events.linuxfoundation.org/cfp
>
> You will receive a notification whether or not your presentation proposal
> was accepted by Sep 14th.
>
> END-USER COLLABORATION
>
> One of the big challenges as developers is to know what, where and how
> people actually use our software. We will reserve a few slots for end
> users talking about their deployment challenges and achievements.
>
> If you are using oVirt in production you are encouraged submit a speaking
> proposal. Simply mark it as an end-user collaboration proposal. As an
> end user, this is a unique opportunity to get your input to developers.
>
> BOF SESSION
>
> We will reserve some slots in the evening after the main conference
> tracks, for birds of a feather (BOF) sessions. These sessions will be
> less formal than presentation tracks and targetted for people who would
> like to discuss specific issues with other developers and/or users.
> If you are interested in getting developers and/or uses together to
> discuss a specific problem, please submit a BOF proposal.
>
> LIGHTNING TALKS
>
> In addition to submitted talks we will also have some room for lightning
> talks. These are short (5 minute) discussions to highlight new work or
> ideas that aren't complete enough to warrant a full presentation slot.
> Lightning talk submissions and scheduling will be handled on-site at
> oVirt Workshop.
>
> HOTEL / TRAVEL
>
> The oVirt Workshop Europe 2012 will be held in Barcelona, Spain at the
> Hotel Fira Palace.
>
> http://events.linuxfoundation.org/events/kvm-forum/hotel
>
> Thank you for your interest in oVirt. We're looking forward to your
> submissions and seeing you at the oVirt Workshop Europe 2012 in November!
>
> Thanks,
> your oVirt Workshop Europe 2012 Program Commitee
>
> Please contact us with any questions or comments.
> workshop-pc@ovirt.org
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
From: Paolo Bonzini @ 2012-09-14 6:45 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Anthony Liguori, Stefan Hajnoczi, kvm-devel, Michael S. Tsirkin,
Jan Kiszka, qemu-devel, lf-virt, Anthony Liguori, target-devel,
Zhi Yong Wu, Christoph Hellwig
In-Reply-To: <1347575263.7359.76.camel@haakon2.linux-iscsi.org>
Il 14/09/2012 00:27, Nicholas A. Bellinger ha scritto:
> *) Keep vhost-scsi as a backend to virtio-scsi-pci
>
> - Reduces duplicated code amongst multiple virtio-scsi backends.
>
> - Follows the split for what existing vhost-net code already does.
>
> So that said, two quick questions for Paolo & Co..
>
> For the standalone vhost-scsi-pci device case, can you give a brief idea
> as to what extent you'd like to see virtio-scsi.c code/defs duplicated
> and/or shared amongst a new vhost-scsi-pci device..?
Not much, in the end, would be shared; it could end up being just
parts of virtio_scsi_init and virtio_scsi_exit, and virtio_scsi_get_config.
Almost all the other code is to implement the SCSI bus interface,
which you do not need.
I don't remember if and how vhost handles configuration changes. If you
need any struct in virtio-scsi.c, either move it to virtio-scsi.h or
add the new device in the same file.
> Also to help me along, can you give an example based on the current
> usage below how the QEMU command line arguments would change with a
> standalone vhost-scsi-pci device..?
>
> ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \
> -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \
> -vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 \
> -device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off
Two possibilities. Either simply do s/virtio-scsi-pci/vhost-scsi-pci/ or do
./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \
-hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \
-device virtio-scsi-pci,wwpn=naa.600140579ad21088,tpgt=1,event_idx=off
^ permalink raw reply
* Re: [PATCH 0/5] vhost-scsi: Add support for host virtualized target
From: Paolo Bonzini @ 2012-09-14 8:21 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Stefan Hajnoczi, kvm-devel, Michael S. Tsirkin, Jan Kiszka,
qemu-devel, lf-virt, Anthony Liguori, target-devel, Zhi Yong Wu,
Christoph Hellwig
In-Reply-To: <1347567129.7359.14.camel@haakon2.linux-iscsi.org>
Il 13/09/2012 22:12, Nicholas A. Bellinger ha scritto:
>> > Are you still seeing the performance degradation discussed in the thread
>> >
>> > "vhost-scsi port to v1.1.0 + MSI-X performance regression"
>> >
> So the performance regression reported here with QEMU v1.2-rc +
> virtio-scsi ended up being related to virtio interrupts being delivered
> across multiple CPUs.
>
> After explicitly setting the IRQ affinity of the virtio0-request MSI-X
> vector to a specific CPU, the small block (4k) mixed random I/O
> performance jumped back up to the expected ~100K IOPs for a single LUN.
Have you tried setting rq_affinity to 2? Benchmarking this against
multiqueue virtio-scsi is on my todo list.
Paolo
> FYI, I just tried this again with the most recent QEMU v1.2.50 (v1.3-rc)
> code, and both cases appear to be performing as expected once again
> regardless of the explicit IRQ affinity setting.
^ permalink raw reply
* memory corruption in HYPERVISOR_physdev_op()
From: Dan Carpenter @ 2012-09-14 11:24 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Tang Liang, virtualization
Hi Jeremy,
My static analyzer complains about potential memory corruption in
HYPERVISOR_physdev_op()
arch/x86/include/asm/xen/hypercall.h
389 static inline int
390 HYPERVISOR_physdev_op(int cmd, void *arg)
391 {
392 int rc = _hypercall2(int, physdev_op, cmd, arg);
393 if (unlikely(rc == -ENOSYS)) {
394 struct physdev_op op;
395 op.cmd = cmd;
396 memcpy(&op.u, arg, sizeof(op.u));
397 rc = _hypercall1(int, physdev_op_compat, &op);
398 memcpy(arg, &op.u, sizeof(op.u));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some of the arg buffers are not as large as sizeof(op.u) which is either
12 or 16 depending on the size of longs in struct physdev_apic.
399 }
400 return rc;
401 }
One example of this is in xen_initdom_restore_msi_irqs().
arch/x86/pci/xen.c
337 struct physdev_pci_device restore_ext;
338
339 restore_ext.seg = pci_domain_nr(dev->bus);
340 restore_ext.bus = dev->bus->number;
341 restore_ext.devfn = dev->devfn;
342 ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
343 &restore_ext);
^^^^^^^^^^^^
There are only 4 bytes here.
344 if (ret == -ENOSYS)
^^^^^^^^^^^^^^
If we hit this condition, we have corrupted some memory.
345 pci_seg_supported = false;
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
From: Michael S. Tsirkin @ 2012-09-14 12:34 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Anthony Liguori, Stefan Hajnoczi, kvm-devel, Jan Kiszka,
qemu-devel, lf-virt, Anthony Liguori, target-devel, Zhi Yong Wu,
Christoph Hellwig
In-Reply-To: <5052D277.7010900@redhat.com>
On Fri, Sep 14, 2012 at 08:45:11AM +0200, Paolo Bonzini wrote:
> Il 14/09/2012 00:27, Nicholas A. Bellinger ha scritto:
> > *) Keep vhost-scsi as a backend to virtio-scsi-pci
> >
> > - Reduces duplicated code amongst multiple virtio-scsi backends.
> >
> > - Follows the split for what existing vhost-net code already does.
> >
> > So that said, two quick questions for Paolo & Co..
> >
> > For the standalone vhost-scsi-pci device case, can you give a brief idea
> > as to what extent you'd like to see virtio-scsi.c code/defs duplicated
> > and/or shared amongst a new vhost-scsi-pci device..?
>
> Not much, in the end, would be shared; it could end up being just
> parts of virtio_scsi_init and virtio_scsi_exit, and virtio_scsi_get_config.
>
> Almost all the other code is to implement the SCSI bus interface,
> which you do not need.
>
> I don't remember if and how vhost handles configuration changes.
All configuration changes are handled in userspace.
> If you
> need any struct in virtio-scsi.c, either move it to virtio-scsi.h or
> add the new device in the same file.
>
> > Also to help me along, can you give an example based on the current
> > usage below how the QEMU command line arguments would change with a
> > standalone vhost-scsi-pci device..?
> >
> > ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \
> > -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \
> > -vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 \
> > -device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off
>
> Two possibilities. Either simply do s/virtio-scsi-pci/vhost-scsi-pci/ or do
>
> ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \
> -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \
> -device virtio-scsi-pci,wwpn=naa.600140579ad21088,tpgt=1,event_idx=off
I think I like the second option better.
--
MST
^ permalink raw reply
* Re: [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
From: Michael S. Tsirkin @ 2012-09-14 12:50 UTC (permalink / raw)
To: Anthony Liguori
Cc: Stefan Hajnoczi, kvm-devel, Jan Kiszka, qemu-devel, lf-virt,
Anthony Liguori, target-devel, Paolo Bonzini, Zhi Yong Wu,
Christoph Hellwig
In-Reply-To: <504F40BA.7020800@us.ibm.com>
On Tue, Sep 11, 2012 at 08:46:34AM -0500, Anthony Liguori wrote:
> On 09/10/2012 01:24 AM, Michael S. Tsirkin wrote:
> >On Mon, Sep 10, 2012 at 08:16:54AM +0200, Paolo Bonzini wrote:
> >>Il 09/09/2012 00:40, Michael S. Tsirkin ha scritto:
> >>>On Fri, Sep 07, 2012 at 06:00:50PM +0200, Paolo Bonzini wrote:
> >>>>Il 07/09/2012 08:48, Nicholas A. Bellinger ha scritto:
> >>>>>Cc: Stefan Hajnoczi<stefanha@linux.vnet.ibm.com>
> >>>>>Cc: Zhi Yong Wu<wuzhy@linux.vnet.ibm.com>
> >>>>>Cc: Michael S. Tsirkin<mst@redhat.com>
> >>>>>Cc: Paolo Bonzini<pbonzini@redhat.com>
> >>>>>Signed-off-by: Nicholas Bellinger<nab@linux-iscsi.org>
> >>>>>---
> >>>>> hw/virtio-pci.c | 2 ++
> >>>>> hw/virtio-scsi.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>> hw/virtio-scsi.h | 1 +
> >>>>> 3 files changed, 52 insertions(+), 0 deletions(-)
> >>>>
> >>>>Please create a completely separate device vhost-scsi-pci instead (or
> >>>>virtio-scsi-tcm-pci, or something like that). It is used completely
> >>>>differently from virtio-scsi-pci, it does not make sense to conflate the
> >>>>two.
> >>>
> >>>Ideally the name would say how it is different, not what backend it
> >>>uses. Any good suggestions?
> >>
> >>I chose the backend name because, ideally, there would be no other
> >>difference. QEMU _could_ implement all the goodies in vhost-scsi (such
> >>as reservations or ALUA), it just doesn't do that yet.
> >>
> >>Paolo
> >
> >Then why do you say "It is used completely differently from
> >virtio-scsi-pci"? Isn't it just a different backend?
> >
> >If yes then it should be a backend option, like it is
> >for virtio-net.
>
> I don't mean to bike shed here so don't take this as a nack on
> making it a backend option, but in retrospect, the way we did
> vhost-net was a mistake even though I strongly advocated for it to
> be a backend option.
>
> The code to do it is really, really ugly. I think it would have
> made a lot more sense to just make it a device and then have it not
> use a netdev backend or any other kind of backend split.
>
> For instance:
>
> qemu -device vhost-net-pci,tapfd=X
We'd have to duplicate all tap options such as upscript then,
and educate users that vhost-net-pci is in fact same as virtio-net-pci
just faster. They have enough trouble guessing "-net-pci"
in virtio-net-pci.
IMHO a simple -device virtio-net-pci,vhost=on
would have been the right thing to do in retrospect.
> since vhost-net absolutely requires a tap fd, I think it's better in
> the long run to not abuse the netdev backend to prevent user
> confusion.
In practice adding an option (even if it was in the wrong place)
did not result in user confusion. Also in practice, renaming "virtio"
to virtio-net-pci etc did create confusion.
> Having a dedicated backend type that only has one
> possible option and can only be used by one device is a bit silly
> too.
By now we can just enable it by default. This was always the
idea.
> So I would be in favor of dropping/squashing 3/5 and radically
> simplifying how this was exposed to the user.
Let's just make sure we don't have implementation tail wagging
the user interface dog :)
>
> I would just take qemu_vhost_scsi_opts and make them device properties.
>
> Regards,
>
> Anthony Liguori
>
> >
^ permalink raw reply
* International Workshop on Management of Big Data Systems (MBDS 2012) - Call for Participation
From: Aravind Menon @ 2012-09-14 18:29 UTC (permalink / raw)
To: virtualization@lists.linux-foundation.org
Apologies if you received duplicate copies of this Call for Participation.
Sincerely,
Aravind Menon
MBDS 2012
**********************************************************************
CALL FOR PARTICIPATION
======================
Workshop on Management of Big Data Systems (MBDS 2012)
http://www.cercs.gatech.edu/mbds12
In conjunction with ICAC 2012
http://icac2012.cs.fiu.edu
September 21, 2012, San Jose, CA
**********************************************************************
Online registration is open and handled through ICAC 2012
(register for entire ICAC conference or only MBDS workshop):
http://icac2012.cs.fiu.edu/registration.shtm
**********************************************************************
PROGRAM
8:45-9:00AM
Opening Remarks
9:00-10:00AM
Keynote
An Overview of BDAS: the Berkeley (Big) Data Analytics System
Mike Franklin, AMPLab, UC Berkeley
10:00-10:30AM
Break
10:30-12:00PM
Session I: Academia Perspectives
Hierarchical Merge for Scalable MapReduce
Xinyu Que, Yandong Wang, Cong Xu and Weikuan Yu (Auburn University)
Project Hoover: Auto-Scaling Streaming Map-Reduce Applications
Rajalakshmi Ramesh, Liting Hu and Karsten Schwan (Georgia Tech)
Lightweight Black-box Failure Detection for Distributed Systems
Jiaqi Tan, Soila Kavulya, Rajeev Gandhi and Priya Narasimhan (Carnegie Mellon University)
Flex-KV: Enabling High-performance and Flexible KV Systems
Amar Phanishayee, David Andersen (Carnegie Mellon University) Himabindu Pucha, Anna Povzner and Wendy Belluomini (IBM Almaden)
12:00-1:30PM
Lunch
----------------------------------------------------------------------
1:30-4:00PM
Session II: Industry Perspectives
Experiences With Workload Management in Splunk
Archana Ganapathi, Ledion Bitincka and Steve Zhang (Splunk)
Big Data@Facebook
Aravind Menon (Facebook)
Challenges and Lessons Learned Building Monitoring and Diagnostics Tools for Hadoop
Matt Jacobs (Cloudera)
Break
Provisioning Disk Usage in a Large-Scale Cloud Environment
Murray Stokely (Google)
Big Data Benchmarking
Chaitan Baru (SDSC)
Big Data and NoSQL with Amazon DynamoDB
Simone Brunozzi (Amazon)
4:00-5:00PM
Open Discussion
**********************************************************************
WORKSHOP ORGANIZERS
Karsten Schwan, Georgia Tech
Vanish Talwar, HP Labs
PUBLICITY CHAIR
Aravind Menon, Facebook
ARRANGEMENTS CHAIR
Ada Gavrilovska, Georgia Tech
PROGRAM COMMITTEE
Amitanand Aiyer, Facebook
Adhyas Avasthi, Nokia Research
Milind Bhandarkar, Greenplum Labs, EMC
Randal Burns, John Hopkins University
Garth Gibson, Carnegie Mellon University and Panasas Inc.
Herodotos Herodotou, Duke University
Michael A Kozuch, Intel
Kai Li, Princeton University
Mohamed Mansour, Amazon
Aravind Menon, Facebook
Arif Merchant, Google
Beth Plale, Indiana University
Indrajit Roy, HP Labs
Gabor Szabo, Twitter
Craig Ulmer, Sandia National Lab
Kushagra Vaid, Microsoft
Weikuan Yu, Auburn University
Philip Zeyliger, Cloudera
**********************************************************************
^ permalink raw reply
* HPDC 2013 Call for Workshops
From: Ioan Raicu @ 2012-09-14 21:33 UTC (permalink / raw)
To: virtualization, micro_publicity, hpc-ft
[-- Attachment #1.1: Type: text/plain, Size: 3028 bytes --]
HPDC 2013 Call for Workshops
http://www.hpdc.org/2013/workshops/call-for-workshops/
The organizers of the 22nd International ACM Symposium on High-Performance
Parallel and Distributed Computing (HPDC'13) call for proposals for workshops
to be held with HPDC'13. The workshops will be held on June 17-18, 2013.
Workshops should provide forums for discussion among researchers and
practitioners on focused topics or emerging research areas relevant to the HPDC
community. Organizers may structure workshops as they see fit, including
invited talks, panel discussions, presentations of work in progress, fully
peer-reviewed papers, or some combination. Workshops could be scheduled for
half a day or a full day, depending on interest, space constraints, and
organizer preference. Organizers should design workshops for approximately 20-40
participants, to balance impact and effective discussion.
Workshop proposals must be sent in PDF format to the HPDC'13 Workshops Chair,
Abhishek Chandra (Email: chandra AT cs DOT umn DOT edu) with the subject line
"HPDC 2013 Workshop Proposal", and should include:
- The name and acronym of the workshop
- A description (0.5-1 page) of the theme of the workshop
- A description (one paragraph) of the relation between the theme of the
workshop and of HPDC
- A list of topics of interest
- The names and affiliations of the workshop organizers, and if applicable, of
a significant portion of the program committee
- A description of the expected structure of the workshop (papers, invited talks,
panel discussions, etc.)
- Data about previous offerings of the workshop (if any), including the
attendance, the numbers of papers or presentations submitted and accepted, and
the links to the corresponding websites
- A publicity plan for attracting submissions and attendees. Please also include
expected number of submissions, accepted papers, and attendees that you
anticipate for a successful workshop.
Due to publication deadlines, workshops must operate within roughly the
following timeline: papers due mid February (2-3 weeks after the HPDC deadline),
and selected and sent to the publisher by mid April.
Important dates:
Workshop Proposals Due: October 25, 2012
Notifications: November 2, 2012
Workshop CFPs Online and Distributed: November 25, 2012
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
[-- Attachment #1.2: Type: text/html, Size: 3798 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
* CFP: 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid) 2013
From: Ioan Raicu @ 2012-09-14 21:58 UTC (permalink / raw)
To: virtualization, micro_publicity
[-- Attachment #1.1: Type: text/plain, Size: 7391 bytes --]
**** CALL FOR PAPERS ****
The 13th IEEE/ACM International Symposium on
Cluster, Cloud and Grid Computing
(CCGrid 2013)
Delft University of Technology, Delft, the Netherlands
May 13-16, 2013
http://www.pds.ewi.tudelft.nl/ccgrid2013
Rapid advances in architectures, networks, and systems and middleware technologies
are leading to new concepts in and platforms for computing, ranging from Clusters and
Grids to Clouds and Datacenters. CCGrid is a series of very successful conferences,
sponsored by the IEEE Computer Society Technical Committee on Scalable Computing (TCSC)
and the ACM, with the overarching goal of bringing together international researchers,
developers, and users to provide an international forum to present leading research
activities and results on a broad range of topics related to these concepts and platforms,
and their applications. The conference features keynotes, technical presentations,
workshops, tutorials, and posters, as well as the SCALE challenge featuring live demonstrations.
In 2013, CCGrid will come to the Netherlands for the first time, and will be held in Delft,
a historical, picturesque city that is less than one hour away from Amsterdam-Schiphol airport.
The main conference will be held on May 14-16 (Tuesday to Thursday), with tutorials and
affiliated workshops taking place on May 13 (Monday).
**** IMPORTANT DATES ****
Papers Due: 12 November 2012
Author Notifications: 24 January 2013
Final Papers Due: 22 February 2013
**** TOPICS OF INTEREST ****
CCGrid 2013 will have a focus on important and immediate issues that are significantly
influencing all aspects of cluster, cloud and grid computing. Topics of interest include,
but are not limited to:
* Applications and Experiences: Applications to real and complex problems in science,
engineering, business, and society; User studies; Experiences with large-scale deployments,
systems, or applications
* Architecture: System architectures, design and deployment; Power and cooling; Security
and reliability; High availability solutions
* Autonomic Computing and Cyberinfrastructure: Self-managed behavior, models and technologies;
Autonomic paradigms and systems (control-based, bio-inspired, emergent, etc.); Bio-inspired
optimizations and computing
* Cloud Computing: Cloud architectures; Software tools and techniques for clouds
* Multicore and Accelerator-based Computing: Software and application techniques to utilize
multicore architectures and accelerators in clusters, grids, and clouds
* Performance Modeling and Evaluation: Performance prediction and modeling; Monitoring and
evaluation tools; Analysis of system and application performance; Benchmarks and testbeds
* Programming Models, Systems, and Fault-Tolerant Computing: Programming models and
environments for cluster, cloud, and grid computing; Fault-tolerant systems, programs and
algorithms; Systems software to support efficient computing
* Scheduling and Resource Management: Techniques to schedule jobs and resources on cluster,
cloud, and grid computing platforms; SLA definition and enforcement
**** PAPER SUBMISSION GUIDELINES ****
Authors are invited to submit papers electronically in PDF format. Submitted manuscripts
should be structured as technical papers and may not exceed 8 letter-size (8.5 x 11) pages
including figures, tables and references using the IEEE format for conference proceedings.
Submissions not conforming to these guidelines may be returned without review. Authors
should make sure that their file will print on a printer that uses letter-size (8.5 x 11)
paper. The official language of the conference is English. All manuscripts will be reviewed
and will be judged on correctness, originality, technical strength, significance, quality of
presentation, and interest and relevance to the conference attendees.
Submitted papers must represent original unpublished research that is not currently under
review for any other conference or journal. Papers not following these guidelines will be
rejected without review and further action may be taken, including (but not limited to)
notifications sent to the heads of the institutions of the authors and sponsors of the
conference. Submissions received after the due date, exceeding the page limit, or not
appropriately structured may not be considered. Authors may contact the conference chairs
for more information. The proceedings will be published through the IEEE Computer Society
Press, USA, and will be made available online through the IEEE Digital Library.
**** CALL FOR TUTORIAL AND WORKSHOP PROPOSALS ****
Tutorials and workshops affiliated with CCGrid 2013 will be held on May 13 (Monday). For
more information on the tutorials and workshops and for the complete Call for Tutorial and
Workshop Proposals, please see the conference website.
**** GENERAL CHAIR ****
Dick Epema, Delft University of Technology, the Netherlands
**** PROGRAM CHAIR ****
Thomas Fahringer, University of Innsbruck, Austria
**** PROGRAM VICE-CHAIRS ****
Rosa Badia, Barcelona Supercomputing Center, Spain
Henri Bal, Vrije Universiteit, the Netherlands
Marios Dikaiakos, University of Cyprus, Cyprus
Kirk Cameron, VirginiaTech, USA
Daniel Katz, University of Chicago & Argonne Nat Lab, USA
Kate Keahey, Argonne National Laboratory, USA
Martin Schulz, Lawrence Livermore National Laboratory, USA
Douglas Thain, University of Notre Dame, USA
Cheng-Zhong Xu, Shenzhen Inst. of Advanced Techn, China
**** WORKSHOPS CO-CHAIRS ****
Shantenu Jha, Rutgers and Louisana State University, USA
Ioan Raicu, Illinois Institute of Technology, USA
**** TOTORIALS CHAIR ****
Radu Prodan, University of Innsbruck, Austria
**** DOCTORAL SYMPOSIUM CO-CHAIRS ****
Yogesh Simmhan, University of Southern California, USA
Ana Varbanescu, Delft Univ of Technology, the Netherlands
**** SUBMISSIONS AND PROCEEDINGS CHAIR ****
Pavan Balaji, Argonne National Laboratory, USA
**** FINANCE AND REGISTRATION CHAIR ****
Alexandru Iosup, Delft Univ of Technology, the Netherlands
**** PUBLICITY CHAIRS ****
Nazareno Andrade, University Federal de Campina Grance, Brazil
Gabriel Antoniu, INRIA, France
Bahman Javadi, University of Western Sysney, Australia
Ioan Raicu, Illinois Institute of Technology and Argonne National Laboratory, USA
Kin Choong Yow, Shenzhen Inst. of Advanced Technology, China
**** CYBER CHAIR ****
Stephen van der Laan, Delft University of Technology, the Netherlands
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
[-- Attachment #1.2: Type: text/html, Size: 8165 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
* Call for Workshops: IEEE/ACM CCGrid 2013
From: Ioan Raicu @ 2012-09-14 23:59 UTC (permalink / raw)
To: virtualization, micro_publicity
**** CALL FOR WORKSHOPS ****
The 13th IEEE/ACM International Symposium on
Cluster, Cloud and Grid Computing
(CCGrid 2013)
Delft University of Technology, Delft, the Netherlands
May 13-16, 2013
http://www.pds.ewi.tudelft.nl/ccgrid2013
http://www.pds.ewi.tudelft.nl/ccgrid2013/calls/workshops/
Workshop proposals are invited for CCGrid 2013 on specific aspects of Grid, Cloud
and Cluster Computing, particularly relating to the subject areas indicated by the
topics below. We encourage workshops that will discuss fundamental research issues
driven by academic interests or more applied industrial or commercial concerns. The
format of the workshop will be determined by the organizers. Workshops can vary in
length from a half day to a full day. Having more than one co-organizer for a
workshop is strongly advised. Workshop proceedings will be published as part of the
CCGrid 2013 proceedings. So, it is very important that high quality workshops are
accepted, and that workshop chairs observe strict quality standards, no more than
50% acceptance, in the selection of papers for their events. Workshop attendees are
required to register for the main conference.
IMPORTANT DATES AND PROPOSAL SUBMISSION:
---------------------------------------------------------------------------
Workshop proposals and any enquiries should be sent by e-mail to the workshop chairs.
Proposals should be submitted in PDF format (printable on A4 paper).
Workshop Proposals Due: October 20, 2012
Notification: November 3, 2012
Workshops: May 13-16 2013
PROPOSAL REQUIREMENTS:
-------------------------------------------
Proposals for workshops should be between 2 to 5 pages in length. They should contain
the following information:
o Title and brief technical description of the workshop, specifying the goals and the
technical issues that will be its focus.
o A brief abstract of the workshop (less than 200 words), intended for the CCGrid 2013
web site.
o A brief description of why and to whom the workshop is of interest.
o A list of related workshops or similar events held in the last 3 years or to be held
in 2012/2013.
o The names and contact information (web page, email address) of the proposed
organizing committee. This committee should consist of two or three people
knowledgeable about the technical issues to be addressed, preferably not members of
the same institution. A brief description of the qualifications of the proposed
organizing committee with respect to organizing this workshop (e.g., papers published
in the proposed topic area, previous workshop organization, other relevant
information).
o Link to a preliminary web site of the workshop and a preliminary call for papers
o A list of committed and proposed PC members.
RESPONSIBILITIES:
------------------------------
Each workshop organizing committee will be responsible for the following:
o Producing a web page and a "Call for Papers/Participation" for their workshop. The
URL should be sent to the workshop co-chairs for CCGrid 2013.
o The call must make it clear that the workshop is open to all members of the
Distributed Computing community. It should mention that at least one author of each
accepted submission must attend the workshop and that all workshop participants must
pay the conference fee.
o Finally, it should also clearly describe the process by which the Organizing
Committee will select the participants.
o Ensure that all workshop papers are a maximum of 6 pages in length (in IEEE format).
It is the responsibility of the workshop organizers to ensure that this page limit has
been adhered to. Additional pages may be purchased (in some circumstances) subject to
approval of the proceedings chair.
o Provide a brief description of the workshop for the conference web page and program.
o Selecting the participants and the format of the workshop.
The publication of proceedings will be by the IEEE in the same volume as the main
conference. Camera-ready due date for the accepted workshop papers will be the same as the
main conference. Therefore, workshop organizers should set the acceptance notification date
at least 2 weeks earlier than the camera-ready due date. All other details can be up to
workshop organizers to set, such as advertising the workshop beyond the conference web page
and assistance in producing a camera-ready version of the workshop proceedings.
Important Note:
-----------------------
Workshop organizers must ensure that suitable quality measures have been taken to ensure that
the accepted papers are of high quality. All papers must be reviewed by an International
Programme Committee (with a minimum of 3 reviews per paper).
The CCGrid 2013 Organizing Committee will be responsible for the following:
o Providing a link to a workshop's local page.
o Providing logistics support and a meeting place for the workshop.
o In conjunction with the organizers, determining the workshop date and time.
o Providing copies of the workshop proceedings to attendees.
Important Note:
-----------------------
The CCGrid 2013 Organizing Committee may decide, if the workshop is too small
(i.e. does not attract enough submissions) to merge it with another workshop. So we encourage
workshop organizers to attract a large community. In extreme situations we may also cancel
workshops if there are not enough submissions.
Conference Topics of Interest and Area Keywords:
-------------------------------------------------------------------------
Topics of interest to the conference include (but are not restricted to):
o Autonomic Grid Computing
o Content Distribution Networks
o Cloud Computing
o Cluster Computing
o Grid Computing
o Peer-2-Peer Computing
o Multi-Core Systems
o Grid and Cloud Testbeds
o Semantic Grids
o Web 2.0 Technologies
o Workflow Tools and Applications
o Programming Models
o Energy Management in Data Centers
o Resource Management
o Service Level Agreements and Scheduling
o Tools and Environments
o Scientific Instruments and Grid Computing
o Application areas: HealthCare/Life Sciences, Engineering, etc.
WORKSHOP CHAIRS:
--------------------------------
Please send your proposals to both workshop chairs.
o Ioan Raicu (iraicu@cs.iit.edu), Illinois Institute of Technology, USA
o Shantenu Jha (shantenu.jha@rutgers.edu), Rutgers University, USA
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ 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