On Thu, Nov 18, 2010 at 03:48:43PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 18, 2010 at 03:35:01PM +0200, Gleb Natapov wrote:
> > On Thu, Nov 18, 2010 at 03:20:27PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 18, 2010 at 03:14:53PM +0200, Gleb Natapov wrote:
> > > > On Thu, Nov 18, 201
On Thu, Nov 18, 2010 at 03:35:01PM +0200, Gleb Natapov wrote:
> On Thu, Nov 18, 2010 at 03:20:27PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 18, 2010 at 03:14:53PM +0200, Gleb Natapov wrote:
> > > On Thu, Nov 18, 2010 at 03:03:37PM +0200, Michael S. Tsirkin wrote:
> > > > > >+static inline v
On Thu, Nov 18, 2010 at 03:39:15PM +0200, Avi Kivity wrote:
> On 11/18/2010 03:35 PM, Gleb Natapov wrote:
> >>
> >> or something like this.
> >Ah so you want to do it only for MSI? For MSI it makes sense. Remember
> >though that sometimes destination depend on message itself (specifically
> >on de
On 11/18/2010 03:35 PM, Gleb Natapov wrote:
>
> or something like this.
Ah so you want to do it only for MSI? For MSI it makes sense. Remember
though that sometimes destination depend on message itself (specifically
on delivery mode).
Yes, broadcast or multicast or lowest priority wouldn't get
On Thu, Nov 18, 2010 at 03:20:27PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 18, 2010 at 03:14:53PM +0200, Gleb Natapov wrote:
> > On Thu, Nov 18, 2010 at 03:03:37PM +0200, Michael S. Tsirkin wrote:
> > > > >+static inline void kvm_irq_routing_update(struct kvm *kvm,
> > > > >+
On Thu, Nov 18, 2010 at 03:14:53PM +0200, Gleb Natapov wrote:
> On Thu, Nov 18, 2010 at 03:03:37PM +0200, Michael S. Tsirkin wrote:
> > > >+static inline void kvm_irq_routing_update(struct kvm *kvm,
> > > >+ struct kvm_irq_routing_table
> > > >*irq_rt)
> >
On 11/18/2010 03:14 PM, Gleb Natapov wrote:
On Thu, Nov 18, 2010 at 03:03:37PM +0200, Michael S. Tsirkin wrote:
> > >+static inline void kvm_irq_routing_update(struct kvm *kvm,
> > >+ struct kvm_irq_routing_table
*irq_rt)
> > >+{
> > >+ rcu_a
On Thu, Nov 18, 2010 at 03:03:37PM +0200, Michael S. Tsirkin wrote:
> > >+static inline void kvm_irq_routing_update(struct kvm *kvm,
> > >+struct kvm_irq_routing_table *irq_rt)
> > >+{
> > >+ rcu_assign_pointer(kvm->irq_routing, irq_rt);
> > >+}
> > >+
> > > st
On 11/18/2010 03:03 PM, Michael S. Tsirkin wrote:
> > int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level);
> >+int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm
*kvm,
> >+ int irq_source_id, int level);
>
> No point in the level argu
On Thu, Nov 18, 2010 at 02:29:11PM +0200, Avi Kivity wrote:
> On 11/18/2010 01:10 PM, Michael S. Tsirkin wrote:
> >> I guess I should create an empty Documentation/kvm/locking.txt and
> >> force everyone else to update it.
> >
> >Comments near the relevant fields not better?
> >
>
> Not an eithe
On 11/18/2010 01:10 PM, Michael S. Tsirkin wrote:
> I guess I should create an empty Documentation/kvm/locking.txt and
> force everyone else to update it.
Comments near the relevant fields not better?
Not an either/or. You can't understand the system from random source
comments.
diff -
On Thu, Nov 18, 2010 at 01:03:44PM +0200, Avi Kivity wrote:
> On 11/18/2010 12:57 PM, Michael S. Tsirkin wrote:
> >So the following on top will fix it all.
> >Any more comments befpre I bundle it up,
> >test and report?
> >
>
> Nope (not that I can comment on an incremental).
Here it is rolled up
On 11/18/2010 12:57 PM, Michael S. Tsirkin wrote:
So the following on top will fix it all.
Any more comments befpre I bundle it up,
test and report?
Nope (not that I can comment on an incremental).
I guess I should create an empty Documentation/kvm/locking.txt and force
everyone else to upda
So the following on top will fix it all.
Any more comments befpre I bundle it up,
test and report?
kvm: fix up msi fastpath
This will be folded into the msi fastpath patch.
Changes:
- simplify irq_entry/irq_routing update rules:
simply to it all under irqfds.lock
- document locking for rcu upd
On Thu, Nov 18, 2010 at 11:34:26AM +0200, Michael S. Tsirkin wrote:
> > > @@ -125,10 +129,18 @@ irqfd_wakeup(wait_queue_t *wait, unsigned mode, int
> > > sync, void *key)
> > > {
> > > struct _irqfd *irqfd = container_of(wait, struct _irqfd, wait);
> > > unsigned long flags = (unsigned long)k
On 11/18/2010 12:12 AM, Michael S. Tsirkin wrote:
Store irq routing table pointer in the irqfd object,
and use that to inject MSI directly without bouncing out to
a kernel thread.
While we touch this structure, rearrange irqfd fields to make fastpath
better packed for better cache utilization.
On Thu, Nov 18, 2010 at 11:05:22AM +0200, Gleb Natapov wrote:
> On Thu, Nov 18, 2010 at 12:12:54AM +0200, Michael S. Tsirkin wrote:
> > Store irq routing table pointer in the irqfd object,
> > and use that to inject MSI directly without bouncing out to
> > a kernel thread.
> >
> > While we touch t
On Thu, Nov 18, 2010 at 11:16:02AM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 18, 2010 at 11:05:22AM +0200, Gleb Natapov wrote:
> > On Thu, Nov 18, 2010 at 12:12:54AM +0200, Michael S. Tsirkin wrote:
> > > Store irq routing table pointer in the irqfd object,
> > > and use that to inject MSI dir
On Thu, Nov 18, 2010 at 11:05:22AM +0200, Gleb Natapov wrote:
> On Thu, Nov 18, 2010 at 12:12:54AM +0200, Michael S. Tsirkin wrote:
> > Store irq routing table pointer in the irqfd object,
> > and use that to inject MSI directly without bouncing out to
> > a kernel thread.
> >
> > While we touch t
On Thu, Nov 18, 2010 at 12:12:54AM +0200, Michael S. Tsirkin wrote:
> Store irq routing table pointer in the irqfd object,
> and use that to inject MSI directly without bouncing out to
> a kernel thread.
>
> While we touch this structure, rearrange irqfd fields to make fastpath
> better packed for
Store irq routing table pointer in the irqfd object,
and use that to inject MSI directly without bouncing out to
a kernel thread.
While we touch this structure, rearrange irqfd fields to make fastpath
better packed for better cache utilization.
Some notes on the design:
- Use pointer into the rt
21 matches
Mail list logo
