sjur.brandel...@stericsson.com writes:
> From: Sjur Brændeland
>
> Add helper macro for drivers that don't do anything
> special in module init/exit.
>
> Signed-off-by: Sjur Brændeland
Applied!
Thanks,
Rusty.
___
Virtualization mailing list
Virtualiz
Hi Gerd,
> > +/* Option name for socket's service label. Use as the option name in
> > + * setsockopt(3) or getsockopt(3) to set or get the service label for a
> > socket.
> > + * The service label is a C-style NUL-terminated string. Only available
> > for
> > + * hypervisor endpoints.
> > + */
> stream_has_data: Returns amount of data available (in bytes) in the
> socket's receive buffer, or -1 if empty.
>
> stream_has_space: Returns amount of space available (in bytes) in the
> socket's send buffer, or -1 if full.
Actually, I think it's for empty/full, and -1 for an error (say, the
tr
unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.
Signed-off-by: Cyril Roelandt
---
drivers/xen/pcpu.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 067fcfa..5a27a45 100
On Tue, Feb 12, 2013 at 09:08:27PM +0100, Paolo Bonzini wrote:
> Il 12/02/2013 19:23, Michael S. Tsirkin ha scritto:
> > On Tue, Feb 12, 2013 at 07:04:27PM +0100, Paolo Bonzini wrote:
> Perhaps, but 3 or 4 arguments (in/out/nsg or in/out/nsg_in/nsg_out) just
> for this are definitely too
Il 12/02/2013 19:23, Michael S. Tsirkin ha scritto:
> On Tue, Feb 12, 2013 at 07:04:27PM +0100, Paolo Bonzini wrote:
Perhaps, but 3 or 4 arguments (in/out/nsg or in/out/nsg_in/nsg_out) just
for this are definitely too many and make the API harder to use.
You have to find a balan
Hi Rusty,
On Mon, Feb 4, 2013 at 10:44 PM, Rusty Russell wrote:
> Sjur Brændeland writes:
...
>> I guess my vringh related stuff should go into your tree together with your
>> vringh patches...
>> Would you be willing to take this via your tree, provided that I get acks
>> from the right people?
On Tue, Feb 12, 2013 at 07:04:27PM +0100, Paolo Bonzini wrote:
> >> Perhaps, but 3 or 4 arguments (in/out/nsg or in/out/nsg_in/nsg_out) just
> >> for this are definitely too many and make the API harder to use.
> >>
> >> You have to find a balance. Having actually used the API, the
> >> possibilit
Il 12/02/2013 18:34, Michael S. Tsirkin ha scritto:
> On Tue, Feb 12, 2013 at 05:57:55PM +0100, Paolo Bonzini wrote:
>> Il 12/02/2013 17:35, Michael S. Tsirkin ha scritto:
>>> On Tue, Feb 12, 2013 at 05:17:47PM +0100, Paolo Bonzini wrote:
Il 12/02/2013 17:13, Michael S. Tsirkin ha scritto:
>>>
virtio device drivers translate requests from higher layer in two steps:
a device-specific step in the device driver, and generic preparation
of virtio direct or indirect buffers in virtqueue_add_buf. Because
virtqueue_add_buf also accepts the outcome of the first step as a single
struct scatterli
On Tue, Feb 12, 2013 at 05:57:55PM +0100, Paolo Bonzini wrote:
> Il 12/02/2013 17:35, Michael S. Tsirkin ha scritto:
> > On Tue, Feb 12, 2013 at 05:17:47PM +0100, Paolo Bonzini wrote:
> >> Il 12/02/2013 17:13, Michael S. Tsirkin ha scritto:
> > + * @nsg: the number of sg lists that will be
Il 12/02/2013 17:35, Michael S. Tsirkin ha scritto:
> On Tue, Feb 12, 2013 at 05:17:47PM +0100, Paolo Bonzini wrote:
>> Il 12/02/2013 17:13, Michael S. Tsirkin ha scritto:
> + * @nsg: the number of sg lists that will be added
>>> This means number of calls to add_sg ? Not sure why this
On Tue, Feb 12, 2013 at 05:17:47PM +0100, Paolo Bonzini wrote:
> Il 12/02/2013 17:13, Michael S. Tsirkin ha scritto:
> >>> + * @nsg: the number of sg lists that will be added
> > This means number of calls to add_sg ? Not sure why this matters.
> > How about we pass in in_num/out_num -
Il 12/02/2013 17:13, Michael S. Tsirkin ha scritto:
>>> + * @nsg: the number of sg lists that will be added
> This means number of calls to add_sg ? Not sure why this matters.
> How about we pass in in_num/out_num - that is total # of sg,
> same as add_buf?
It is used to c
On Tue, Feb 12, 2013 at 04:48:39PM +0100, Paolo Bonzini wrote:
> Il 12/02/2013 16:43, Michael S. Tsirkin ha scritto:
> > On Tue, Feb 12, 2013 at 04:32:27PM +0100, Paolo Bonzini wrote:
> >> Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto:
> > +/**
> > + * virtqueue_start_buf - start build
Il 12/02/2013 16:43, Michael S. Tsirkin ha scritto:
> On Tue, Feb 12, 2013 at 04:32:27PM +0100, Paolo Bonzini wrote:
>> Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto:
> +/**
> + * virtqueue_start_buf - start building buffer for the other end
> + * @vq: the struct virtqueue we're ta
On Tue, Feb 12, 2013 at 04:32:27PM +0100, Paolo Bonzini wrote:
> Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto:
> >> > +/**
> >> > + * virtqueue_start_buf - start building buffer for the other end
> >> > + * @vq: the struct virtqueue we're talking about.
> >> > + * @data: the token identifying
Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto:
>> > +/**
>> > + * virtqueue_start_buf - start building buffer for the other end
>> > + * @vq: the struct virtqueue we're talking about.
>> > + * @data: the token identifying the buffer.
>> > + * @nents: the number of buffers that will be added
>
CALL FOR PAPERS
Special Session on Cloud Interoperability - CI 2013
In conjunction with the 3rd International Conference on Cloud Computing and
Services Science - CLOSER 2013
Website: http://closer.scitevents.org/CI.aspx
May 8 - 10, 2013
Aachen, Germany
Co-organized by: RWTH
Sponso
Hi Gerd,
> > +struct vsock_transport {
...
> Whoa. This has grown *alot*. Care to explain this please? Patch
> creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I removed the vmci header from the core code.
On Tue, Feb 12, 2013 at 01:23:27PM +0100, Paolo Bonzini wrote:
> virtio device drivers translate requests from higher layer in two steps:
> a device-specific step in the device driver, and generic preparation
> of virtio direct or indirect buffers in virtqueue_add_buf. Because
> virtqueue_add_buf
From: Sjur Brændeland
When rproc_serial is initialized, guest_connected should be set
to true. We can then revert the extra checks introduced in
commit: "virtio_console: Let unconnected rproc device receive data."
Signed-off-by: Sjur Brændeland
---
drivers/char/virtio_console.c |7 ++-
Avoid duplicated code in all of the callers.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 3dd
From: Wanlong Gao
Add hot cpu notifier to reset the request virtqueue affinity
when doing cpu hotplug.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Wanlong Gao
[ The version that doesn't get/put_online_cpus is now called
__virtscsi_set_affinity - Paolo ]
Signed-off-by: Paolo Bonzini
---
dr
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU,
This will be needed soon in order to retrieve the per-target
struct.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virti
virtio_scsi_target_state is now empty, but we will find new uses
for it in the next few patches. However, dropping the sglist lets
us turn the array-of-pointers into a simple array, which simplifies
the allocation.
However, we do not leave the virtio_scsi_target_state structs in the
flexible arra
This series implements virtio-scsi queue steering, which gives
performance improvements of up to 50% (measured both with QEMU and
tcm_vhost backends). The patches build on top of the new virtio APIs
at http://permalink.gmane.org/gmane.linux.kernel.virtualization/18431;
the new API simplifies the l
Eliminate the code duplication between virtqueue_add_buf and
virtqueue_add_sg. That's safe to do now that no devices will
pass scatterlists with a termination marker in the middle.
Signed-off-by: Paolo Bonzini
---
drivers/virtio/virtio_ring.c | 159 +++---
1
Adding a single direct buffer is a very common case. Introduce
an optimized function for that.
Signed-off-by: Paolo Bonzini
---
drivers/char/hw_random/virtio-rng.c |2 +-
drivers/char/virtio_console.c |4 +-
drivers/net/virtio_net.c|2 +-
drivers/rpmsg/virtio_rpmsg
Using the new virtio_scsi_add_sg function lets us simplify the queueing
path. In particular, all data protected by the tgt_lock is just gone
(multiqueue will find a new use for the lock).
The speedup is relatively small (2-4%) but it is worthwhile because of
the code simplification it enables. A
Prepare for when virtqueue_add_buf will use sg_next instead of
ignoring ending markers.
Note that for_each_sg (and thus virtqueue_add_sg) allows you
to pass a "truncated" scatterlist that does not have a marker
on the last item. We rely on this in add_recvbuf_mergeable.
Signed-off-by: Paolo Bonz
This is useful in places that recycle the same scatterlist multiple
times, and do not want to incur the cost of sg_init_table every
time in hot paths.
Acked-by: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/blk-integrity.c |2 +-
block/blk-merge.c |2 +-
include/linu
This is similar to the previous patch, but a bit more radical
because the bio and req paths now share the buffer construction
code. Because the req path doesn't use vbr->sg, however, we
need to add a couple of arguments to __virtblk_add_req.
We also need to teach __virtblk_add_req how to build SC
Move the creation of the request header and response footer to
__virtblk_add_req. vbr->sg only contains the data scatterlist,
the header/footer are added separately using the new piecewise
API for building virtqueue buffers.
With this change, virtio-blk (with use_bio) is not relying anymore on
th
Right now, both virtblk_add_req and virtblk_add_req_wait call
virtqueue_add_buf. To prepare for the next patches, abstract the call
to virtqueue_add_buf into a new function __virtblk_add_req, and include
the waiting logic directly in virtblk_add_req.
Signed-off-by: Paolo Bonzini
---
drivers/blo
virtio device drivers translate requests from higher layer in two steps:
a device-specific step in the device driver, and generic preparation
of virtio direct or indirect buffers in virtqueue_add_buf. Because
virtqueue_add_buf also accepts the outcome of the first step as a single
struct scatterli
Most device drivers do not need to perform any postprocessing on the
scatterlists they receive from higher-level drivers (e.g. the block
or SCSI layer), because they translate the request metadata directly
from the various C structs into the data that is required by the device.
virtio devices howe
From: Vikram ARV
Add the the Virtio shared memory driver for STE Modems.
caif_virtio is implemented utilizing the virtio framework
for data transport and is managed with the remoteproc frameworks.
The Virtio queue is used for transmitting data to the modem, and
the new vringh implementation is r
From: Sjur Brændeland
Add helper macro for drivers that don't do anything
special in module init/exit.
Signed-off-by: Sjur Brændeland
---
include/linux/virtio.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
inde
From: Sjur Brændeland
Add functions for creating, deleting and kicking host-side virtio rings.
The host ring is not integrated with virtiqueues and cannot be managed
through virtio-config. Remoteproc must export functions for handling the
host-side virtio rings.
The functions rproc_virtio_get_v
From: Sjur Brændeland
This driver depends on Rusty's new host virtio ring implementation,
so this patch-set is based on the vringh branch in Rusty's git.
Changes since V1:
- Use the new iov helper functions, and simplify iov handling.
However this triggers compile warnings, as it takes struct
On 02/07/13 01:23, Andy King wrote:
Hi,
> +/* Option name for socket's service label. Use as the option name in
> + * setsockopt(3) or getsockopt(3) to set or get the service label for a
> socket.
> + * The service label is a C-style NUL-terminated string. Only available for
> + * hypervisor
On Tue, Feb 12, 2013 at 11:01:10AM +0100, Sjur Brændeland wrote:
> On Tue, Feb 12, 2013 at 10:42 AM, Michael S. Tsirkin wrote:
> ...
> > > > > How about setting port->guest_connected = true in the init routines
> > > > > instead? Keeps this code path cleaner.
> > > >
> > > > Agree, I'll respin th
On Tue, Feb 12, 2013 at 10:42 AM, Michael S. Tsirkin wrote:
...
> > > > How about setting port->guest_connected = true in the init routines
> > > > instead? Keeps this code path cleaner.
> > >
> > > Agree, I'll respin this patch.
> >
> > Hm, Rusty has already picked this up.
>
> I don't see it in
On Tue, Feb 12, 2013 at 10:14:59AM +0100, Sjur Brændeland wrote:
> Hi Amit,
>
> > > @@ -1763,8 +1763,11 @@ static void in_intr(struct virtqueue *vq)
> >
> > > > * tty is spawned) and the host sends out data to console
> > > > * ports. For generic serial ports, the host won't
> > > >
On (Tue) 12 Feb 2013 [10:14:59], Sjur Brændeland wrote:
> Hi Amit,
>
> > > @@ -1763,8 +1763,11 @@ static void in_intr(struct virtqueue *vq)
> >
> > > > * tty is spawned) and the host sends out data to console
> > > > * ports. For generic serial ports, the host won't
> > > > * (shou
Hi Amit,
> > @@ -1763,8 +1763,11 @@ static void in_intr(struct virtqueue *vq)
>
> > > * tty is spawned) and the host sends out data to console
> > > * ports. For generic serial ports, the host won't
> > > * (shouldn't) send data till the guest is connected.
> > > +* However a r
48 matches
Mail list logo
