On (Thu) Aug 27 2009 [15:04:45], Michael Ellerman wrote:
On Wed, 2009-08-26 at 21:15 +0530, Amit Shah wrote:
[cc'ing some people who have made some commits in hvc_console.c]
On (Wed) Aug 26 2009 [16:57:18], Amit Shah wrote:
On (Tue) Aug 25 2009 [11:47:20], Amit Shah wrote:
On (Thu) Aug 27 2009 [14:07:03], Benjamin Herrenschmidt wrote:
On Wed, 2009-08-26 at 21:15 +0530, Amit Shah wrote:
- Convert hvc's usage of spinlocks to mutexes. I've no idea how this
will play out; I'm no expert here. But I did try doing this and so far
it all looks OK. No
On Thu, 2009-08-27 at 10:08 +0100, Alan Cox wrote:
- Then, are we certain that there's no case where the tty layer will
call us with some lock held or in an atomic context ? To be honest,
I've totally lost track of the locking rules in tty land lately so it
might well be ok, but something
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's for the per_vector case,
because
we don't have the names. This is what prevented me from doing a nice
encapsulation.
Yes. But let's split free_vectors out into free_msix_vectors and
On Wed, 26 Aug 2009 06:58:28 pm Amit Shah wrote:
Saves us one cycle of alloc-add-free if the queue was full.
Signed-off-by: Amit Shah amit.s...@redhat.com
Thanks, applied with one change:
@@ -323,7 +323,7 @@ static bool try_fill_recv_maxbufs(struct virtnet_info
*vi, gfp_t gfp)
On Thu, Aug 27, 2009 at 07:00:34PM +0930, Rusty Russell wrote:
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's for the per_vector case,
because
we don't have the names. This is what prevented me from doing a nice
encapsulation.
On Thu, 27 Aug 2009 02:26:55 am Michael S. Tsirkin wrote:
On Tue, Aug 25, 2009 at 04:16:34PM +0300, Michael S. Tsirkin wrote:
+ /* If they don't want an interrupt, don't send one, unless
empty. */
+ if ((flags VRING_AVAIL_F_NO_INTERRUPT) vq-inflight)
+
On Wed, Aug 26, 2009 at 03:40:59PM +0200, Arnd Bergmann wrote:
On Tuesday 25 August 2009, Michael S. Tsirkin wrote:
I'd like to avoid that here,
though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to take
a
struct like:
u32 feature_size;
u32
On (Thu) Aug 27 2009 [19:17:20], Rusty Russell wrote:
On Wed, 26 Aug 2009 06:58:28 pm Amit Shah wrote:
Saves us one cycle of alloc-add-free if the queue was full.
Signed-off-by: Amit Shah amit.s...@redhat.com
Thanks, applied with one change:
@@ -323,7 +323,7 @@ static bool
On Tue, Aug 25, 2009 at 09:40:40PM +0930, Rusty Russell wrote:
Also, see other fixes to the lguest launcher since then which might
be relevant to this code:
lguest: get more serious about wmb() in example Launcher code
Heh, this just gets one step closer to a real wmb. I just used the
On Thu, 27 Aug 2009 07:19:26 pm Michael S. Tsirkin wrote:
On Thu, Aug 27, 2009 at 07:00:34PM +0930, Rusty Russell wrote:
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's for the per_vector case,
because
we don't have the names.
On Thu, 27 Aug 2009 07:40:26 pm Michael S. Tsirkin wrote:
On Wed, Aug 26, 2009 at 03:40:59PM +0200, Arnd Bergmann wrote:
On Tuesday 25 August 2009, Michael S. Tsirkin wrote:
I'd like to avoid that here,
though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to
take a
On Thu, 27 Aug 2009 07:59:06 pm Amit Shah wrote:
On (Thu) Aug 27 2009 [19:17:20], Rusty Russell wrote:
On Wed, 26 Aug 2009 06:58:28 pm Amit Shah wrote:
Saves us one cycle of alloc-add-free if the queue was full.
Signed-off-by: Amit Shah amit.s...@redhat.com
Thanks, applied with
On Thu, 27 Aug 2009 08:15:18 pm Michael S. Tsirkin wrote:
On Tue, Aug 25, 2009 at 09:40:40PM +0930, Rusty Russell wrote:
Also, see other fixes to the lguest launcher since then which might
be relevant to this code:
lguest: get more serious about wmb() in example Launcher code
Heh,
On (Thu) Aug 27 2009 [20:36:07], Rusty Russell wrote:
I'm missing something though: the value of 'num' changes in the loop and
the value of num when it will be compared will just have been used by
add_buf. The next iteration of the loop will probably use a different
value (-- from just
On Thu, Aug 27, 2009 at 08:40:02PM +0930, Rusty Russell wrote:
On Thu, 27 Aug 2009 08:15:18 pm Michael S. Tsirkin wrote:
On Tue, Aug 25, 2009 at 09:40:40PM +0930, Rusty Russell wrote:
Also, see other fixes to the lguest launcher since then which might
be relevant to this code:
On Thu, Aug 27, 2009 at 08:32:24PM +0930, Rusty Russell wrote:
On Thu, 27 Aug 2009 07:19:26 pm Michael S. Tsirkin wrote:
On Thu, Aug 27, 2009 at 07:00:34PM +0930, Rusty Russell wrote:
On Tue, 25 Aug 2009 09:34:34 pm Michael S. Tsirkin wrote:
That's because we didn't do the request_irq's
Stephen Hemminger wrote:
Or Gerlitz ogerl...@voltaire.com wrote:
Looking in macvlan_set_multicast_list() it acts in a similar manner to
macvlan_set_mac_address() in the sense that it calls dev_mc_sync(). I assume
what's left is to add macvlan_hash_xxx multicast logic to map/unmap
multicast
On Wed, Aug 26, 2009 at 05:04:44PM +0930, Rusty Russell wrote:
On Tue, 25 Aug 2009 10:04:41 pm Arnd Bergmann wrote:
On Tuesday 25 August 2009, Avi Kivity wrote:
On 08/25/2009 05:22 AM, Anthony Liguori wrote:
I think 2.6.32 is pushing it.
2.6.32 is pushing it, but we need to
When mm switched to matches that of active mm, we don't need to
increment and then drop the mm count. Making that conditional reduces
contention on that cache line on SMP systems.
Acked-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
There's similarity with vringfd, with some differences and reduced scope
- uses eventfd for
vhost net module wants to do copy to/from user from a kernel thread,
which needs use_mm (like what fs/aio has). Move that into mm/ and
export to modules.
Acked-by: Andrew Morton a...@linux-foundation.org
Acked-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Michael S. Tsirkin
Rusty, ok, I think I've addressed your comments so far here.
Coming next:
- TSO
- tap support
Thanks!
---
This implements vhost: a kernel-level backend for virtio,
The main motivation for this work is to reduce virtualization
overhead for virtio by removing system calls on data path,
without
On Thu, Aug 27, 2009 at 07:27:23PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-08-27 at 10:08 +0100, Alan Cox wrote:
So at this stage, I think the reasonably thing to do is to stick to the
spinlock, but we can try to make it a bit smarter, and we can definitely
attempt to fix the case
- Then, are we certain that there's no case where the tty layer will
call us with some lock held or in an atomic context ? To be honest,
I've totally lost track of the locking rules in tty land lately so it
might well be ok, but something to verify.
Some of the less well behaved line
25 matches
Mail list logo
