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 purpose. It
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/unuse as an API? It's
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 current use/unuse.
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 resources a
On Wed, Oct 19, 2011 at 01:17:03PM +0200, Jan Kiszka wrote:
On 2011-10-19 11:03, Michael S. Tsirkin wrote:
I thought we need to match APIC ID. That needs a table lookup, no?
Yes. But that's completely independent of a concrete MSI message. In
fact, this is the same thing we need when
On 2011-10-19 02:56, Michael S. Tsirkin wrote:
On Wed, Oct 19, 2011 at 12:13:49AM +0200, Jan Kiszka wrote:
On 2011-10-18 23:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 09:37:14PM +0200, Jan Kiszka wrote:
On 2011-10-18 20:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at
On Wed, Oct 19, 2011 at 08:41:48AM +0200, Jan Kiszka wrote:
a single GSI and vice versa. As there are less GSIs than possible
MSI
messages, we could run out of them when creating routes, statically
or
lazily.
What would probably help us long-term out of your concerns regarding
On 2011-10-19 11:03, Michael S. Tsirkin wrote:
I thought we need to match APIC ID. That needs a table lookup, no?
Yes. But that's completely independent of a concrete MSI message. In
fact, this is the same thing we need when interpreting an IOAPIC
redirection table entry. So let's create an
On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote:
On 2011-10-17 17:48, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
This optimization was only required to keep KVM route usage low. Now
that we solve that problem via lazy updates, we can
On 2011-10-18 13:58, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote:
On 2011-10-17 17:48, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
This optimization was only required to keep KVM route usage low. Now
that we
On Tue, Oct 18, 2011 at 02:08:59PM +0200, Jan Kiszka wrote:
On 2011-10-18 13:58, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote:
On 2011-10-17 17:48, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
This
On 2011-10-18 14:33, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 02:08:59PM +0200, Jan Kiszka wrote:
On 2011-10-18 13:58, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote:
On 2011-10-17 17:48, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at
On Tue, Oct 18, 2011 at 02:38:36PM +0200, Jan Kiszka wrote:
On 2011-10-18 14:33, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 02:08:59PM +0200, Jan Kiszka wrote:
On 2011-10-18 13:58, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote:
On 2011-10-17
On 2011-10-17 17:48, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
This optimization was only required to keep KVM route usage low. Now
that we solve that problem via lazy updates, we can drop the field. We
still need interfaces to clear pending vectors,
On 2011-10-18 14:48, Michael S. Tsirkin wrote:
To my understanding, virtio will be the exception as no other device
will have a chance to react on resource shortage while sending(!) an MSI
message.
Hmm, are you familiar with that spec?
Not by heart.
This is not what virtio does,
resource
On Tue, Oct 18, 2011 at 03:00:29PM +0200, Jan Kiszka wrote:
On 2011-10-18 14:48, Michael S. Tsirkin wrote:
To my understanding, virtio will be the exception as no other device
will have a chance to react on resource shortage while sending(!) an MSI
message.
Hmm, are you familiar with
On 2011-10-18 15:37, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 03:00:29PM +0200, Jan Kiszka wrote:
On 2011-10-18 14:48, Michael S. Tsirkin wrote:
To my understanding, virtio will be the exception as no other device
will have a chance to react on resource shortage while sending(!) an
On Tue, Oct 18, 2011 at 03:46:06PM +0200, Jan Kiszka wrote:
On 2011-10-18 15:37, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 03:00:29PM +0200, Jan Kiszka wrote:
On 2011-10-18 14:48, Michael S. Tsirkin wrote:
To my understanding, virtio will be the exception as no other device
will
On 2011-10-18 16:01, Michael S. Tsirkin wrote:
I actually would not mind preallocating everything upfront which is much
easier. But with your patch we get a silent failure or a drastic
slowdown which is much more painful IMO.
Again: did we already saw that limit? And where does it come from
On Tue, Oct 18, 2011 at 04:08:46PM +0200, Jan Kiszka wrote:
On 2011-10-18 16:01, Michael S. Tsirkin wrote:
I actually would not mind preallocating everything upfront which is
much
easier. But with your patch we get a silent failure or a drastic
slowdown which is much more painful IMO.
On 2011-10-18 17:08, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 04:08:46PM +0200, Jan Kiszka wrote:
On 2011-10-18 16:01, Michael S. Tsirkin wrote:
I actually would not mind preallocating everything upfront which is
much
easier. But with your patch we get a silent failure or a
On Tue, Oct 18, 2011 at 05:22:38PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:08, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 04:08:46PM +0200, Jan Kiszka wrote:
On 2011-10-18 16:01, Michael S. Tsirkin wrote:
I actually would not mind preallocating everything upfront which is
much
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an arbitrary MSI message
(theoretically 64+32 bits, in practice it's much of course much less) to
( There are 24 distinguishing bits in an MSI message on x86, but that's
only a current interpretation of one specific arch.
On 2011-10-18 17:56, Michael S. Tsirkin wrote:
What would probably help us long-term out of your concerns regarding
lazy routing is to bypass that redundant GSI translation for dynamic
messages, i.e. those that are not associated with an irqfd number or an
assigned device irq. Something like a
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an arbitrary MSI message
(theoretically 64+32 bits, in practice it's much of course much less) to
( There are 24 distinguishing bits in an MSI message on
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an arbitrary MSI message
(theoretically 64+32 bits, in practice it's much of course much less) to
( There are
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an arbitrary MSI message
(theoretically 64+32 bits, in practice it's much of course much less) to
( There are
On Tue, Oct 18, 2011 at 08:24:39PM +0200, Jan Kiszka wrote:
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an arbitrary MSI message
(theoretically 64+32
On 2011-10-18 20:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 08:24:39PM +0200, Jan Kiszka wrote:
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18 17:22, Jan Kiszka wrote:
What KVM has to do is just mapping an
On Tue, Oct 18, 2011 at 09:37:14PM +0200, Jan Kiszka wrote:
On 2011-10-18 20:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 08:24:39PM +0200, Jan Kiszka wrote:
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
On 2011-10-18
On 2011-10-18 23:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 09:37:14PM +0200, Jan Kiszka wrote:
On 2011-10-18 20:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 08:24:39PM +0200, Jan Kiszka wrote:
On 2011-10-18 19:06, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at
On Wed, Oct 19, 2011 at 12:13:49AM +0200, Jan Kiszka wrote:
On 2011-10-18 23:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 09:37:14PM +0200, Jan Kiszka wrote:
On 2011-10-18 20:40, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 08:24:39PM +0200, Jan Kiszka wrote:
On 2011-10-18
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
This optimization was only required to keep KVM route usage low. Now
that we solve that problem via lazy updates, we can drop the field. We
still need interfaces to clear pending vectors, though (and we have to
make use of them more
33 matches
Mail list logo
