linux-kernel - Re: [PATCH] SCSI driver for VMware's virtual HBA.

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: <1251826877.16169.141.camel@ank32.eng.vmware.com>
Date:	Tue, 01 Sep 2009 10:41:17 -0700
From:	Alok Kataria <akataria@...are.com>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Dmitry Torokhov <dtor@...are.com>, Matthew Wilcox <matthew@....cx>,
	Roland Dreier <rdreier@...co.com>,
	Bart Van Assche <bvanassche@....org>,
	Robert Love <robert.w.love@...el.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Mike Christie <michaelc@...wisc.edu>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rolf Eike Beer <eike-kernel@...tec.de>,
	Maxime Austruy <maustruy@...are.com>
Subject: Re: [PATCH] SCSI driver for VMware's virtual HBA.


On Tue, 2009-09-01 at 10:25 -0700, James Bottomley wrote:
> On Tue, 2009-09-01 at 09:59 -0700, Alok Kataria wrote:
> > On Tue, 2009-09-01 at 09:52 -0700, James Bottomley wrote:
> > > On Tue, 2009-09-01 at 09:33 -0700, Dmitry Torokhov wrote:
> > > > On Tuesday 01 September 2009 09:16:51 am Matthew Wilcox wrote:
> > > > > On Tue, Sep 01, 2009 at 09:12:43AM -0700, Roland Dreier wrote:
> > > > > > I'm not really sure we should be trying to force drivers to share just
> > > > > > because they are paravirtualized -- if there is real commonality, then
> > > > > > sure put it in common code, but different hypervisors are probably as
> > > > > > different as different hardware.
> > > > > 
> > > > > I really disagree.  This kind of virtualised drivers are pretty much
> > > > > communication protocols, and not hardware.  As such, why design a new one?
> > > > > If there's an infelicity in the ibmvscsi protocol, it makes sense to
> > > > > design a new one.  But being different for the sake of being different
> > > > > is just a way to generate a huge amount of make-work.
> > > > > 
> > > > 
> > > > The same thing can be said about pretty much anything. We don't have
> > > > single SCSI, network, etc driver handling every devices in their
> > > > respective class, I don't see why it would be different here.
> > > > A hypervisor presents the same interface to the guest OS (whether
> > > > it is Linux, Solaris or another OS) much like a piece of silicone
> > > > does and it may very well be different form other hypervisors.
> > > 
> > > Nobody said you had to have the exact same driver for every hypervisor.
> > > What people are suggesting is that we look at commonalities in the
> > > interfaces both from a control plane point of view (transport class) and
> > > from a code sharing point of view (libscsivirt).  However, all the
> > > hypervisor interfaces I've seen are basically DMA rings ... they really
> > > do seem to be very similar across hypervisors, so it does seem there
> > > could be a lot of shared commonality.  I'm not going to insist on RDMA
> > > emulation, but perhaps you lot should agree on what a guest to
> > > hypervisor DMA interface looks like.
> > 
> > Which is this other hypervisor driver that you are talking about,
> > ibmvscsi is using RDMA emulation and I don't think you mean that. 
> 
> lguest uses the sg_ring abstraction.  Xen and KVM were certainly looking
> at this too.

I don't see the sg_ring abstraction that you are talking about. Can you
please give me some pointers. 
Also regarding Xen and KVM I think they are using the xenbus/vbus
interface, which is quite different than what we do here. 

> 
> > And anyways how large is the DMA code that we are worrying about here ?
> > Only about 300-400 LOC ? I don't think we might want to over-design for
> > such small gains.
> 
> So even if you have different DMA code, the remaining thousand or so
> lines would be in common.  That's a worthwhile improvement.

And not just that, different HV-vendors can have different features,
like say XYZ can come up tomorrow and implement the multiple rings
interface so the feature set doesn't remain common and we will have less
code to share in the not so distant future.


Thanks,
Alok
> 
> The benefit to users would be a common control plane and interface from
> the transport class, plus common code means more testers regardless of
> virtualisation technology chosen.


> 
> James
> 
> 

--
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/