Re: [1/2] tun: Only free a netdev when all tun descriptors are closed

2009-04-16 Thread Michael S. Tsirkin
On Thu, Apr 16, 2009 at 01:08:18AM -, Herbert Xu wrote: On Wed, Apr 15, 2009 at 10:38:34PM +0800, Herbert Xu wrote: So how about this? We replace the dev destructor with our own that doesn't immediately call free_netdev. We only call free_netdev once all tun fd's attached to the

Re: [1/2] tun: Only free a netdev when all tun descriptors are closed

2009-04-18 Thread Michael S. Tsirkin
On Fri, Apr 17, 2009 at 08:09:23AM +0800, Herbert Xu wrote: On Thu, Apr 16, 2009 at 10:57:45PM +0300, Michael S. Tsirkin wrote: This last bit seems to make a simple test using a non-persistent tap device deadlock for me: we don't drop a reference acquired with __tun_get sock

[PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-27 Thread Michael S. Tsirkin
. Tsirkin m...@redhat.com --- Here's a draft set of patches for MSI-X support in the guest. It still needs to be tested properly, and performance impact measured, but I thought I'd share it here in the hope of getting some very early feedback/flames. Michael S. Tsirkin (8): virtio: add request_vqs

[PATCH 1/8] virtio: add request_vqs/free_vqs operations

2009-04-27 Thread Michael S. Tsirkin
This adds 2 new optional virtio operations: request_vqs/free_vqs. They will be used for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- include/linux/virtio_config.h | 35 +++ 1

[PATCH 2/8] virtio_blk: add request_vqs/free_vqs calls

2009-04-27 Thread Michael S. Tsirkin
Add request_vqs/free_vqs calls to virtio_blk. These will be required for MSI support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/block/virtio_blk.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block

[PATCH 3/8] virtio-rng: add request_vqs/free_vqs calls

2009-04-27 Thread Michael S. Tsirkin
Add request_vqs/free_vqs calls to virtio-rng. These will be required for MSI support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/char/hw_random/virtio-rng.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/char/hw_random/virtio-rng.c b

[PATCH 4/8] virtio_console: add request_vqs/free_vqs calls

2009-04-27 Thread Michael S. Tsirkin
Add request_vqs/free_vqs calls to virtio_console. These will be required for MSI support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/char/virtio_console.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers

[PATCH 6/8] virtio_balloon: add request_vqs/free_vqs calls

2009-04-27 Thread Michael S. Tsirkin
Add request_vqs/free_vqs calls to virtio_balloon. These will be required for MSI support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_balloon.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b

[PATCH 7/8] virtio_pci: split up vp_interrupt

2009-04-27 Thread Michael S. Tsirkin
This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c | 45 +- 1 files changed, 35 insertions(+), 10 deletions

[PATCH 5/8] virtio_net: add request_vqs/free_vqs calls

2009-04-27 Thread Michael S. Tsirkin
Add request_vqs/free_vqs calls to virtio_net. These will be required for MSI support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/net/virtio_net.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-27 Thread Michael S. Tsirkin
On Mon, Apr 27, 2009 at 06:59:52PM +0200, Christian Borntraeger wrote: Am Monday 27 April 2009 17:39:36 schrieb Michael S. Tsirkin: So we'll probably need to rename request_vqs to request_vectors, but we probably still need the driver to pass the number of vectors it wants to the transport

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-27 Thread Michael S. Tsirkin
On Mon, Apr 27, 2009 at 05:37:25PM +0200, Christian Borntraeger wrote: As number of virtqueues = number of vectors, we could pre-allocate all vectors that host supports, but this seems a bit drastic as an MSI-X device could support up to 2K vectors. In fact, the transport has to have

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-27 Thread Michael S. Tsirkin
On Mon, Apr 27, 2009 at 09:39:06AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Add optional MSI-X support: use a vector per virtqueue with fallback to a common vector and finally to regular interrupt. Teach all drivers to use it. I added 2 new virtio operations: request_vqs

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-28 Thread Michael S. Tsirkin
On Tue, Apr 28, 2009 at 09:47:14AM +0300, Avi Kivity wrote: Michael S. Tsirkin wrote: That saves us the new API (at the expense of a lot more code, but with added flexibility). So we'll probably need to rename request_vqs to request_vectors, but we probably still need the driver

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-28 Thread Michael S. Tsirkin
On Tue, Apr 28, 2009 at 08:51:08PM +0300, Avi Kivity wrote: Michael S. Tsirkin wrote: This does not work for MSIX - in linux, you must map all MSI-X entries to interrupt vectors upfront. What? that's very inflexible. Can you point me at the code? See pci_enable_msix in include/linux

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-04-28 Thread Michael S. Tsirkin
On Tue, Apr 28, 2009 at 02:56:15PM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: So to map vq 0 to vector 0, vq 1 to vector 1 and vq 2 to vector 2 the driver would do: struct virtio_interrupt_mapping mapping[3] = { {0, 0}, {1, 1}, {2, 2} }; vec = map_vqs_to_interrupt(dev, mapping

Re: [PATCH 1/8] virtio: add request_vqs/free_vqs operations

2009-05-04 Thread Michael S. Tsirkin
On Mon, May 04, 2009 at 09:02:20PM +0930, Rusty Russell wrote: On Mon, 27 Apr 2009 10:01:53 pm Michael S. Tsirkin wrote: This adds 2 new optional virtio operations: request_vqs/free_vqs. They will be used for MSI support, because MSI needs to know the total number of vectors upfront

Re: [PATCH RFC 0/8] virtio: add guest MSI-X support

2009-05-04 Thread Michael S. Tsirkin
On Mon, May 04, 2009 at 12:21:28PM +0300, Avi Kivity wrote: Michael S. Tsirkin wrote: So what I see is transports providing something like: struct virtio_interrupt_mapping { int virtqueue; int interrupt; }; map_vqs_to_interrupt(dev, struct virtio_interrupt_mapping *, int

[PATCH] msi-x: let drivers retry when not enough vectors

2009-05-07 Thread Michael S. Tsirkin
pci_enable_msix currently returns -EINVAL if you ask for more vectors than supported by the device, which would typically cause fallback to regular interrupts. It's better to return the table size, making the driver retry MSI-X with less vectors. Signed-off-by: Michael S. Tsirkin m...@redhat.com

Re: [PATCH] msi-x: let drivers retry when not enough vectors

2009-05-07 Thread Michael S. Tsirkin
On Thu, May 07, 2009 at 04:51:24PM +0800, Sheng Yang wrote: On Thursday 07 May 2009 16:28:41 Michael S. Tsirkin wrote: pci_enable_msix currently returns -EINVAL if you ask for more vectors than supported by the device, which would typically cause fallback to regular interrupts. It's

Re: [PATCH] msi-x: let drivers retry when not enough vectors

2009-05-07 Thread Michael S. Tsirkin
On Thu, May 07, 2009 at 05:10:46PM +0800, Sheng Yang wrote: I think driver should read from capability list to know how many vector supported by this device before enable MSI-X for device, as pci_msix_table_size() did... Drivers can do this, but it's more code. Since pci_enable_msix

Re: [PATCH] msi-x: let drivers retry when not enough vectors

2009-05-07 Thread Michael S. Tsirkin
On Thu, May 07, 2009 at 06:19:53PM +0800, Sheng Yang wrote: On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote: On Thu, May 07, 2009 at 05:40:15PM +0800, Sheng Yang wrote: It's indeed weird. Why the semantic of pci_enable_msix can be changed to enable msix, or tell me how many vector

[PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-07 Thread Michael S. Tsirkin
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/block/virtio_blk.c | 11

[PATCH 2/3] virtio_pci: split up vp_interrupt

2009-05-07 Thread Michael S. Tsirkin
This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c | 45 +- 1 files changed, 35 insertions(+), 10 deletions

[PATCH 3/3] virtio_pci: optional MSI-X support

2009-05-07 Thread Michael S. Tsirkin
This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin m...@redhat.com

Re: [PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-08 Thread Michael S. Tsirkin
On Fri, May 08, 2009 at 04:37:06PM +0930, Rusty Russell wrote: On Thu, 7 May 2009 11:40:39 pm Michael S. Tsirkin wrote: This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number

Re: [PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-10 Thread Michael S. Tsirkin
On Sun, May 10, 2009 at 01:37:06PM +0930, Rusty Russell wrote: Yes, and in fact a rough look at your patch reveals that we don't actually need del_vq: now we track them, we can just do that as part of vdev destruction, right? Let's assume that a driver encounters an error in probe after it

[PATCH 1/2] qemu-kvm: add MSI-X support

2009-05-11 Thread Michael S. Tsirkin
This adds (incomplete) MSI-X support to virtio net device. Missing is save/load support, and command-line flag to control the feature. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Makefile.target |2 +- hw/msix.c | 362

[PATCH 2/2] qemu-kvm: use common code for assigned msix

2009-05-11 Thread Michael S. Tsirkin
For assigned devices, use common code to enable msi-x. Add hack option as assigned devices lack a standard way to get vector usage. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/device-assignment.c | 336 hw/device-assignment.h |8

[PATCH RFC 0/2] qemu-kvm: MSI-X support

2009-05-11 Thread Michael S. Tsirkin
Here's a draft MSI-X support patch. Among missing features: save/load support, and command-line flag to control the feature. This is on top of qemu-kvm: msi-x is disabled without kvm interrupt injection support for now. Michael S. Tsirkin (2): qemu-kvm: add MSI-X support qemu-kvm: use common

[PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-11 Thread Michael S. Tsirkin
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/block/virtio_blk.c | 11

[PATCHv3 0/3] virtio: MSI-X support

2009-05-11 Thread Michael S. Tsirkin
Here's an updated draft of virtio patches which work with the qemu-kvm code that I just posted. This still needs to be rebased on top of Rusty's recent virtqueue list patch. I am posting it in case people want to start trying MSI-X out. Michael S. Tsirkin (3): virtio: find_vqs/del_vqs virtio

[PATCH 2/3] virtio_pci: split up vp_interrupt

2009-05-11 Thread Michael S. Tsirkin
This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c | 53 +++--- 1 files changed, 34 insertions(+), 19 deletions

Re: [PATCH RFC 0/2] qemu-kvm: MSI-X support

2009-05-12 Thread Michael S. Tsirkin
On Mon, May 11, 2009 at 05:24:25PM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Here's a draft MSI-X support patch. Among missing features: save/load support, and command-line flag to control the feature. This is on top of qemu-kvm: msi-x is disabled without kvm interrupt injection

Re: [PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-12 Thread Michael S. Tsirkin
On Wed, May 13, 2009 at 12:00:02AM +0930, Rusty Russell wrote: On Tue, 12 May 2009 07:49:32 am Michael S. Tsirkin wrote: This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number

[PATCHv4] virtio: find_vqs/del_vqs virtio operations

2009-05-12 Thread Michael S. Tsirkin
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Untested - Rusty could you pls take a look before I

Re: [PATCH] msi-x: let drivers retry when not enough vectors

2009-05-12 Thread Michael S. Tsirkin
On Fri, May 08, 2009 at 09:25:00AM +0930, Rusty Russell wrote: On Thu, 7 May 2009 07:49:53 pm Sheng Yang wrote: On Thursday 07 May 2009 17:53:02 Matthew Wilcox wrote: Here's a good example. Let's suppose you have a driver which supports two different models of cards, one has 16 MSI-X

Re: [PATCH 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-13 Thread Michael S. Tsirkin
On Wed, May 13, 2009 at 10:47:08AM +0930, Rusty Russell wrote: On Wed, 13 May 2009 01:03:30 am Michael S. Tsirkin wrote: On Wed, May 13, 2009 at 12:00:02AM +0930, Rusty Russell wrote and perhaps consider varargs for the callbacks (or would that be too horrible at the implementation end

[PATCHv5 1/3] virtio: find_vqs/del_vqs virtio operations

2009-05-13 Thread Michael S. Tsirkin
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/block/virtio_blk.c |6

[PATCHv5 2/3] virtio_pci: split up vp_interrupt

2009-05-13 Thread Michael S. Tsirkin
This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c | 53 +++--- 1 files changed, 34 insertions(+), 19 deletions

[PATCHv5 3/3] virtio_pci: optional MSI-X support

2009-05-13 Thread Michael S. Tsirkin
This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin m...@redhat.com

[PATCHv6 0/4] virtio: MSI-X support

2009-05-14 Thread Michael S. Tsirkin
Here's the latest draft of virtio patches. This is on top of Rusty's recent virtqueue list + name patch, which is included in series for completeness. Changelog: changes since v5: fix build on s390 (only patch 2/4 modified) Michael S. Tsirkin (3): virtio: find_vqs/del_vqs virtio

[PATCHv6 1/4] virtio: add names to virtqueue struct, mapping from devices to queues.

2009-05-14 Thread Michael S. Tsirkin
From: Rusty Russell ru...@rustcorp.com.au Add a linked list of all virtqueues for a virtio device: this helps for debugging and is also needed for upcoming interface change. Also, add a name field for clearer debug messages. Signed-off-by: Rusty Russell ru...@rustcorp.com.au --- including this

[PATCHv6 2/4] virtio: find_vqs/del_vqs virtio operations

2009-05-14 Thread Michael S. Tsirkin
This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/block/virtio_blk.c |6

[PATCHv6 3/4] virtio_pci: split up vp_interrupt

2009-05-14 Thread Michael S. Tsirkin
This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c | 53 +++--- 1 files changed, 34 insertions(+), 19 deletions

[PATCHv6 4/4] virtio_pci: optional MSI-X support

2009-05-14 Thread Michael S. Tsirkin
This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated if enough vectors available. Signed-off-by: Michael S. Tsirkin m...@redhat.com

Re: [PATCHv6 4/4] virtio_pci: optional MSI-X support

2009-05-18 Thread Michael S. Tsirkin
On Mon, May 18, 2009 at 12:30:49AM +0300, Avi Kivity wrote: Michael S. Tsirkin wrote: This implements optional MSI-X support in virtio_pci. MSI-X is used whenever the host supports at least 2 MSI-X vectors: 1 for configuration changes and 1 for virtqueues. Per-virtqueue vectors are allocated

[PATCHv2-RFC 0/2] qemu-kvm: MSI-X support

2009-05-20 Thread Michael S. Tsirkin
at capability bit support that I added in pci save/load. Does it look sane? Simple version number is not sufficient for msi, because user has an option to turn off msi even in new qemu. Signed-off-by: Michael S. Tsirkin m...@redhat.com Michael S. Tsirkin (2): qemu-kvm: add MSI-X support qemu-kvm

[PATCHv2-RFC 1/2] qemu-kvm: add MSI-X support

2009-05-20 Thread Michael S. Tsirkin
This adds MSI-X support infrastructure and uses that to enable MSI-X support in virtio net device. Also add a global option to disable MSI-X. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Makefile.target|2 +- hw/device-assignment.c |2 + hw/msix.c | 447

[PATCHv2-RFC 2/2] qemu-kvm: use common code for assigned msix

2009-05-20 Thread Michael S. Tsirkin
For assigned devices, use common code to enable msi-x. We need a special assigned option as assigned devices lack a standard way to get vector usage. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/device-assignment.c | 329 hw/device

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: define api for allocating/setting up msi-x irqs

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: define api for allocating/setting up msi-x irqs

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: define api for allocating/setting up msi-x irqs, and for updating them with msi-x vector information, supply implementation in ioapic. Please comment on this API: I intend

[PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
define api for allocating/setting up msi-x irqs, and for updating them with msi-x vector information, supply implementation in ioapic. Please comment on this API: I intend to port my msi-x patch to work on top of it. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/apic.c |1

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S. Tsirkin wrote: On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 11:18:56PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-20 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 11:26:42PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S. Tsirkin wrote: On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Wed, May 20, 2009 at 11:44:57PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 11:26:42PM +0300, Blue Swirl wrote: On 5/20/09, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 11:34:11AM +0100, Paul Brook wrote: The PCI bus doesn't need any special support (I think) but something on the other end needs to interpret those writes. Sure. But there's definitely nothing PCI specific about it. I assumed this would all be contained within the

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 03:08:18PM +0300, Avi Kivity wrote: Paul Brook wrote: In any case we need some internal API for this, and qemu_irq looks like a good choice. What do you expect to be using this API? virtio, emulated devices capable of supporting MSI (e1000?), device

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 01:29:37PM +0100, Paul Brook wrote: On Thursday 21 May 2009, Avi Kivity wrote: Paul Brook wrote: In any case we need some internal API for this, and qemu_irq looks like a good choice. What do you expect to be using this API? virtio, emulated devices

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 03:38:56PM +0300, Avi Kivity wrote: Paul Brook wrote: Instead of writing directly, let's abstract it behind a qemu_set_irq(). This is easier for device authors. The default implementation of the irq callback could write to apic memory, while for kvm we can directly

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 02:23:20PM +0100, Paul Brook wrote: MSI provides multiple edge triggered interrupts, whereas traditional mode provides a single level triggered interrupt. My guess is most devices will want to treat these differently anyway. So, is qemu_send_msi better than

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 02:53:14PM +0100, Paul Brook wrote: which is a trivial wrapper around stl_phys. OK, but I'm adding another level of indirection in the middle, to allow us to tie in a kvm backend. kvm has no business messing with the PCI device code. Yes it has :) kvm needs

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 03:50:18PM +0100, Paul Brook wrote: kvm has no business messing with the PCI device code. kvm has a fast path for irq injection. If qemu wants to support it we need some abstraction here. Fast path from where to where? Having the PCI layer

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 02:31:26PM +0100, Paul Brook wrote: On Thursday 21 May 2009, Paul Brook wrote: MSI provides multiple edge triggered interrupts, whereas traditional mode provides a single level triggered interrupt. My guess is most devices will want to treat these differently

Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api

2009-05-21 Thread Michael S. Tsirkin
On Thu, May 21, 2009 at 07:45:20PM +0300, Michael S. Tsirkin wrote: On Thu, May 21, 2009 at 02:31:26PM +0100, Paul Brook wrote: On Thursday 21 May 2009, Paul Brook wrote: MSI provides multiple edge triggered interrupts, whereas traditional mode provides a single level triggered

[PATCHv2] qemu: make default_write_config use mask table

2009-05-25 Thread Michael S. Tsirkin
devices, depending on capabilities present. As a result, writing a single byte in BAR registers now works as it should. Writing to upper limit registers in the bridge also works as it should. Code is also shorter. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- This fixes a minor bug in previous

[PATCH 00/11] qemu: MSI-X support

2009-05-25 Thread Michael S. Tsirkin
. At Paul's suggestion, I use stl_phy to decouple APIC and MSI-X implementation. This is on top of 'PATCHv2 make default_write_config use mask table' that I posted previously. I have included that patch here for completeness. -- MST Michael S. Tsirkin (11): qemu: make default_write_config use mask

[PATCH 01/11] qemu: make default_write_config use mask table

2009-05-25 Thread Michael S. Tsirkin
devices, depending on capabilities present. As a result, writing a single byte in BAR registers now works as it should. Writing to upper limit registers in the bridge also works as it should. Code is also shorter. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- This is the same as v2 of the patch

[PATCH 03/11] qemu: add routines to manage PCI capabilities

2009-05-25 Thread Michael S. Tsirkin
Add routines to manage PCI capability list. First user will be MSI-X. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 98 -- hw/pci.h | 18 +++- 2 files changed, 106 insertions(+), 10 deletions(-) diff

[PATCH 02/11] qemu: capability bits in pci save/restore

2009-05-25 Thread Michael S. Tsirkin
Add support for capability bits in save/restore for pci. These will be used for MSI, where the capability might be present or not as requested by user, which does not map well into a single version number. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 14 -- hw

[PATCH 04/11] qemu: helper routines for pci access.

2009-05-25 Thread Michael S. Tsirkin
Add inline routines for convenient access to pci devices with correct (little) endianness. Will be used by MSI-X support. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.h | 30 +++--- 1 files changed, 27 insertions(+), 3 deletions(-) diff --git a/hw/pci.h

[PATCH 05/11] qemu: MSI-X support functions

2009-05-25 Thread Michael S. Tsirkin
Add functions implementing MSI-X support. First user will be virtio-pci. Note that platform must set a flag to declare MSI supported. For PC this will be set by APIC. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Makefile.target |2 +- hw/msix.c | 423

[PATCH 06/11] qemu: add flag to disable MSI-X by default

2009-05-25 Thread Michael S. Tsirkin
Add global flag to disable MSI-X by default. This is useful primarily to make images loadable by older qemu (without msix). Even when MSI-X is disabled by flag, you can still load images that have MSI-X enabled. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/msix.c |3

[PATCH 07/11] qemu: minimal MSI/MSI-X implementation for PC

2009-05-25 Thread Michael S. Tsirkin
are reserved in APIC MMIO and vice versa. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/apic.c | 50 ++ 1 files changed, 46 insertions(+), 4 deletions(-) diff --git a/hw/apic.c b/hw/apic.c index 8c8b2de..d831709 100644 --- a/hw/apic.c +++ b/hw

[PATCH 08/11] qemu: add support for resizing regions

2009-05-25 Thread Michael S. Tsirkin
Make it possible to resize PCI regions. This will be used by virtio with MSI-X, where the region size depends on whether MSI-X is enabled, and can change across load/save. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 54

[PATCH 10/11] qemu: MSI-X support in virtio PCI

2009-05-25 Thread Michael S. Tsirkin
This enables actual support for MSI-X in virtio PCI. First user will be virtio-net. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/virtio-pci.c | 152 -- 1 files changed, 112 insertions(+), 40 deletions(-) diff --git a/hw/virtio

[PATCH 09/11] qemu: virtio support for many interrupt vectors

2009-05-25 Thread Michael S. Tsirkin
to bindings yet, so they are left stubbed out for now. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/syborg_virtio.c | 13 -- hw/virtio-pci.c| 24 +++ hw/virtio.c| 63 ++- hw/virtio.h| 10

[PATCH] qemu: virtio save/load bindings

2009-05-25 Thread Michael S. Tsirkin
Implement bindings for virtio save/load. Use them in virtio pci. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Is anyone working to fill in load/save bindings so that saving virtio devices works? Here's a trivial patch to do this (this one is on top of my MSI-X patchset). Comments? hw

Re: [Qemu-devel] [PATCH 04/11] qemu: helper routines for pci access.

2009-05-26 Thread Michael S. Tsirkin
On Tue, May 26, 2009 at 11:33:37AM +0900, Isaku Yamahata wrote: On Mon, May 25, 2009 at 03:25:33PM +0300, Michael S. Tsirkin wrote: Add inline routines for convenient access to pci devices with correct (little) endianness. Will be used by MSI-X support. Just a minor comment. How about

Re: [Qemu-devel] [PATCH 04/11] qemu: helper routines for pci access.

2009-05-26 Thread Michael S. Tsirkin
On Tue, May 26, 2009 at 11:07:33AM +0300, Avi Kivity wrote: Michael S. Tsirkin wrote: On Tue, May 26, 2009 at 11:33:37AM +0900, Isaku Yamahata wrote: On Mon, May 25, 2009 at 03:25:33PM +0300, Michael S. Tsirkin wrote: Add inline routines for convenient access to pci devices

Re: [Qemu-devel] [PATCH 03/11] qemu: add routines to manage PCI capabilities

2009-05-26 Thread Michael S. Tsirkin
On Tue, May 26, 2009 at 05:49:26PM +0900, Isaku Yamahata wrote: On Mon, May 25, 2009 at 03:25:20PM +0300, Michael S. Tsirkin wrote: Add routines to manage PCI capability list. First user will be MSI-X. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 98

[PATCH] qemu: fix pci_find_capability for multiple caps

2009-05-26 Thread Michael S. Tsirkin
pci_find_capability_list has a bug so it'd stop at the first capability. This only happens to work as we only support a single capability (MSI-X). Here's a fix. Found-by: Isaku Yamahata yamah...@valinux.co.jp Signed-off-by: Michael S. Tsirkin m...@redhat.com --- This is a fixup for my patch

Re: find_vqs operation starting at arbitrary index

2009-06-01 Thread Michael S. Tsirkin
On Mon, Jun 01, 2009 at 01:33:48PM +0530, Amit Shah wrote: Hello, The recent find_vqs operation doesn't allow for a vq to be found at an arbitrary location; it's meant to be called once at startup to find all possible queues and never called again. This doesn't work for devices which can

Re: find_vqs operation starting at arbitrary index

2009-06-01 Thread Michael S. Tsirkin
On Mon, Jun 01, 2009 at 02:05:10PM +0530, Amit Shah wrote: On (Mon) Jun 01 2009 [11:11:06], Michael S. Tsirkin wrote: On Mon, Jun 01, 2009 at 01:33:48PM +0530, Amit Shah wrote: Hello, The recent find_vqs operation doesn't allow for a vq to be found at an arbitrary location; it's

Re: find_vqs operation starting at arbitrary index

2009-06-01 Thread Michael S. Tsirkin
On Mon, Jun 01, 2009 at 02:21:28PM +0530, Amit Shah wrote: On (Mon) Jun 01 2009 [11:43:27], Michael S. Tsirkin wrote: On Mon, Jun 01, 2009 at 02:05:10PM +0530, Amit Shah wrote: On (Mon) Jun 01 2009 [11:11:06], Michael S. Tsirkin wrote: On Mon, Jun 01, 2009 at 01:33:48PM +0530, Amit Shah

Re: find_vqs operation starting at arbitrary index

2009-06-01 Thread Michael S. Tsirkin
On Mon, Jun 01, 2009 at 02:21:28PM +0530, Amit Shah wrote: On (Mon) Jun 01 2009 [11:43:27], Michael S. Tsirkin wrote: On Mon, Jun 01, 2009 at 02:05:10PM +0530, Amit Shah wrote: On (Mon) Jun 01 2009 [11:11:06], Michael S. Tsirkin wrote: On Mon, Jun 01, 2009 at 01:33:48PM +0530, Amit Shah

[PATCHv2 00/13] qemu: MSI-X support

2009-06-02 Thread Michael S. Tsirkin
to decouple APIC and MSI-X implementation. This uses the mask table patch that I posted previously, and which is now included in the series. -- MST Michael S. Tsirkin (13): qemu: make default_write_config use mask table qemu: capability bits in pci save/restore qemu: add routines to manage

[PATCHv2 01/13] qemu: make default_write_config use mask table

2009-06-02 Thread Michael S. Tsirkin
devices, depending on capabilities present. As a result, writing a single byte in BAR registers now works as it should. Writing to upper limit registers in the bridge also works as it should. Code is also shorter. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 145

[PATCHv2 06/13] qemu: add flag to disable MSI-X by default

2009-06-02 Thread Michael S. Tsirkin
Add global flag to disable MSI-X by default. This is useful primarily to make images loadable by older qemu (without msix). Even when MSI-X is disabled by flag, you can still load images that have MSI-X enabled. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/msix.c |3

[PATCHv2 11/13] qemu: request 3 vectors in virtio-net

2009-06-02 Thread Michael S. Tsirkin
Request up to 3 vectors in virtio-net. Actual bindings might supply less. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/virtio-net.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/virtio-net.c b/hw/virtio-net.c index 60aa6da..6118fe3 100644 --- a/hw/virtio

[PATCHv2 08/13] qemu: add support for resizing regions

2009-06-02 Thread Michael S. Tsirkin
Make it possible to resize PCI regions. This will be used by virtio with MSI-X, where the region size depends on whether MSI-X is enabled, and can change across load/save. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.c | 54

[PATCHv2 07/13] qemu: minimal MSI/MSI-X implementation for PC

2009-06-02 Thread Michael S. Tsirkin
are reserved in APIC MMIO and vice versa. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/apic.c | 50 ++ 1 files changed, 46 insertions(+), 4 deletions(-) diff --git a/hw/apic.c b/hw/apic.c index 8c8b2de..d831709 100644 --- a/hw/apic.c +++ b/hw

[PATCHv2 13/13] qemu: add pci_get/set_byte

2009-06-02 Thread Michael S. Tsirkin
Add pci_get/set_byte to keep *_word and *_long access functions company. They are unused for now. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/pci.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/hw/pci.h b/hw/pci.h index 4072f16..e1e4fb4 100644

[PATCHv2 05/13] qemu: MSI-X support functions

2009-06-02 Thread Michael S. Tsirkin
Add functions implementing MSI-X support. First user will be virtio-pci. Note that platform must set a flag to declare MSI supported. For PC this will be set by APIC. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Makefile.target |2 +- hw/msix.c | 423

[PATCHv2 10/13] qemu: MSI-X support in virtio PCI

2009-06-02 Thread Michael S. Tsirkin
This enables actual support for MSI-X in virtio PCI. First user will be virtio-net. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/virtio-pci.c | 152 -- 1 files changed, 112 insertions(+), 40 deletions(-) diff --git a/hw/virtio

[PATCHv2 12/13] qemu: virtio save/load bindings

2009-06-02 Thread Michael S. Tsirkin
Implement bindings for virtio save/load. Use them in virtio pci. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/virtio-pci.c | 49 - hw/virtio.c | 31 ++- hw/virtio.h |4 3 files changed

Re: find_vqs operation starting at arbitrary index

2009-06-02 Thread Michael S. Tsirkin
On Tue, Jun 02, 2009 at 08:53:07AM +0930, Rusty Russell wrote: On Mon, 1 Jun 2009 05:33:48 pm Amit Shah wrote: Hello, The recent find_vqs operation doesn't allow for a vq to be found at an arbitrary location; it's meant to be called once at startup to find all possible queues and never

  1   2   3   4   5   6   7   8   9   10   >