lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101118133501.GQ7948@redhat.com>
Date:	Thu, 18 Nov 2010 15:35:01 +0200
From:	Gleb Natapov <gleb@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
	Xiao Guangrong <xiaoguangrong@...fujitsu.com>,
	Gregory Haskins <ghaskins@...ell.com>,
	Chris Lalancette <clalance@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] kvm: fast-path msi injection with irqfd

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,
> > > > >+					  struct kvm_irq_routing_table *irq_rt)
> > > > >+{
> > > > >+	rcu_assign_pointer(kvm->irq_routing, irq_rt);
> > > > >+}
> > > > >+
> > > > >  static inline int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
> > > > >  {
> > > > >  	return -ENOSYS;
> > > > 
> > > > Apart from these minor issues, looks good.
> > > 
> > > 
> > > Something we should consider improving is the loop over all VCPUs that
> > > kvm_irq_delivery_to_apic invokes.  I think that (for non-broadcast
> > > interrupts) it should be possible to precompute an store the CPU
> > > in question as part of the routing entry.
> > > 
> > > Something for a separate patch ... comments?
> > > 
> > I do not think this info should be part of routing entry. Routing entry
> > is more about describing wires on the board.
> 
> Not for msi. kvm_kernel_irq_routing_entry seems to just keep an
> address/data pair in that case. So
> 
Yeah. Using routing_entry for MSI was miss design. We discussed that too :)

> 	union {
> 		struct {
> 			unsigned irqchip;
> 			unsigned pin;
> 		} irqchip;
> 		struct msi_msg msi;
> 	};
> 
> would become
> 
> 	union {
> 		struct {
> 			unsigned irqchip;
> 			unsigned pin;
> 		} irqchip;
> 		struct {
> 			struct msi_msg msi;
> 			struct kvm_vpcu *dest;
> 		} msi;
> 	};
> 
> 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).

> 
> > Other then that
> > this is a good idea that, IIRC, we already discussed once.
> > 
> > --
> > 			Gleb.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ