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
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
. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Tue, Jun 02, 2009 at 10:39:16PM +0530, Amit Shah wrote:
On (Tue) Jun 02 2009 [19:32:27], Michael S. Tsirkin wrote:
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
As I'm new to qemu/kvm, to figure out how networking performance can be
improved, I
went over the code and took some notes. As I did this, I tried to record ideas
from recent discussions and ideas that came up on improving performance. Thus
this list.
This includes a partial overview of
On Thu, Jun 04, 2009 at 01:16:05PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
As I'm new to qemu/kvm, to figure out how networking performance can be
improved, I
went over the code and took some notes. As I did this, I tried to record
ideas
from recent discussions
1 - 100 of 8051 matches
Mail list logo
