[RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed

This make let virtio-net driver can send gratituous packet by a new config bit - VIRTIO_NET_S_ANNOUNCE in each config update interrupt. When this bit is set by backend, the driver would schedule a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through b

[RFC v2 PATCH 4/4] virtio-net: notify guest to annouce itself

It's hard to track all mac address and its usage (vlan, bondings, ipv6) in qemu to send gratituous packet in qemu side, so the better choice is let guest do it. The patch introduces a new rw config status bit of virtio-net, VIRTIO_NET_S_ANNOUNCE which is used to notify guest to announce itself ( s

[RFC v2 PATCH 3/4] net: model specific announcing support

This patch introduce a function pointer in NetClientInfo which is called during self announcement to do the model specific announcement such as sending gratuitous packet. Previous method is kept when model specific announcing fails or without it. The first user would be virtio-net. Signed-off-by:

[RFC v2 PATCH 2/4] net: export announce_self_create()

Export and move announce_self_create() to net.c in order to be used by model specific announcing function. Signed-off-by: Jason Wang --- net.c| 31 +++ net.h|1 + savevm.c | 32 3 files changed, 32 insertions(+), 32 del

[RFC v2 PATCH 1/4] announce self after vm start

We send gratituous packets to let switch to update its mac address table, this is only done after migration currently because guest may move to the host with another port connect to switch. Unfortunately this kind of notification is also needed for continue a stopped vm as the mac address table en

[RFC v2 PATCH 0/4] Support sending gratuitous by guest

We only track primary mac address in qemu and send rarp packets after migration to notify the switch to update its mac address table. This may not works when guest have complicated network configurations such as tagged vlan or ipv6, those connection may lost or stall after migration. One method to

Re: [PATCH RFC 0/2] KVM: remove host and guest pv mmu support

On Thu, Oct 20, 2011 at 05:44:23PM -0700, Chris Wright wrote: > This feature hasn't been in use for some years now. The host side bits > are deprecated for almost a year. The guest side would only get used > on old hosts, and it's slower than shadow or hw assisted paging. > > Time to remove it.

Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

On 2011-10-21 14:04, Michael S. Tsirkin wrote: > On Fri, Oct 21, 2011 at 01:51:15PM +0200, Jan Kiszka wrote: >> On 2011-10-21 13:06, Michael S. Tsirkin wrote: >>> On Fri, Oct 21, 2011 at 11:19:19AM +0200, Jan Kiszka wrote: Currently, MSI messages can only be injected to in-kernel irqchips by >

[no subject]

subscribe kvm -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

On Fri, Oct 21, 2011 at 01:51:15PM +0200, Jan Kiszka wrote: > On 2011-10-21 13:06, Michael S. Tsirkin wrote: > > On Fri, Oct 21, 2011 at 11:19:19AM +0200, Jan Kiszka wrote: > >> Currently, MSI messages can only be injected to in-kernel irqchips by > >> defining a corresponding IRQ route for each me

Re: [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

On Fri, Oct 21, 2011 at 11:27:48AM +0200, Jan Kiszka wrote: > On 2011-10-21 09:54, Michael S. Tsirkin wrote: > > On Fri, Oct 21, 2011 at 09:09:10AM +0200, Jan Kiszka wrote: > >> On 2011-10-21 00:02, Michael S. Tsirkin wrote: > > Yes. But this still makes an API for acquiring per-vector resource

Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

On 2011-10-21 13:06, Michael S. Tsirkin wrote: > On Fri, Oct 21, 2011 at 11:19:19AM +0200, Jan Kiszka wrote: >> Currently, MSI messages can only be injected to in-kernel irqchips by >> defining a corresponding IRQ route for each message. This is not only >> unhandy if the MSI messages are generated

[PATCH] kvm tools: Simplify msi message handling

This patch simplifies passing around msi messages by using 'struct kvm_irq_routing_msi' for storing of msi messages instead of passing all msi parameters around. Signed-off-by: Sasha Levin --- tools/kvm/hw/pci-shmem.c|5 + tools/kvm/include/kvm/irq.h |3 ++- tools/kvm/include/kvm

Re: Convert one .img disk created with sparse=true to no sparse

Thank you Stefan. That's exactly what i needed. I worked perfectly. 2011/10/20 Simon Wilson : > - Message from Stefan Hajnoczi - >   Date: Thu, 20 Oct 2011 07:43:45 -0700 >   From: Stefan Hajnoczi > Subject: Re: Convert one .img disk created with sparse=true to no sparse >     To: G

Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

On Fri, Oct 21, 2011 at 11:19:19AM +0200, Jan Kiszka wrote: > Currently, MSI messages can only be injected to in-kernel irqchips by > defining a corresponding IRQ route for each message. This is not only > unhandy if the MSI messages are generated "on the fly" by user space, > IRQ routes are a limi

[PATCH v3] kvm tools: Allow piping debug output to file descriptor

This patch makes debug output go to a 'debug_fd' instead of stdout. Doing so allows us to send the output to a different console when required. This patch also changes the behaviour of 'kvm debug' to show the debug output in the console that executed the debug command instead of in the console of

Re: Convert one .img disk created with sparse=true to no sparse

2011-10-21, 07:28(+10), Simon Wilson: [...] > If working with a NON-sparse VM img (i.e. originally created with > virt-install --nonsparse), does a cp without --sparse=never retain the > non-sparse nature of the file, or does it have to be specified? [...] See the man page for your "cp" comman

Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

On Fri, 2011-10-21 at 11:19 +0200, Jan Kiszka wrote: > Currently, MSI messages can only be injected to in-kernel irqchips by > defining a corresponding IRQ route for each message. This is not only > unhandy if the MSI messages are generated "on the fly" by user space, > IRQ routes are a limited res

Re: [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

On 2011-10-21 09:54, Michael S. Tsirkin wrote: > On Fri, Oct 21, 2011 at 09:09:10AM +0200, Jan Kiszka wrote: >> On 2011-10-21 00:02, Michael S. Tsirkin wrote: > Yes. But this still makes an API for acquiring per-vector resources a > requirement. Yes, but a different one than curr

[RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

Currently, MSI messages can only be injected to in-kernel irqchips by defining a corresponding IRQ route for each message. This is not only unhandy if the MSI messages are generated "on the fly" by user space, IRQ routes are a limited resource that user space as to manage carefully. By providing a

Re: [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

On Fri, Oct 21, 2011 at 09:09:10AM +0200, Jan Kiszka wrote: > On 2011-10-21 00:02, Michael S. Tsirkin wrote: > >>> Yes. But this still makes an API for acquiring per-vector resources a > >>> requirement. > >> > >> Yes, but a different one than current use/unuse. > > > > What's wrong with use/unus

Re: [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

On 2011-10-21 00:02, Michael S. Tsirkin wrote: >>> Yes. But this still makes an API for acquiring per-vector resources a >>> requirement. >> >> Yes, but a different one than current use/unuse. > > What's wrong with use/unuse as an API? It's already in place > and virtio calls it. Not for that pu