linux-kernel - Re: [vmw_vmci RFC 00/11] VMCI for Linux

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]

Date:	Mon, 4 Jun 2012 15:57:57 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Andy King <acking@...are.com>
Cc:	linux-kernel@...r.kernel.org, dtor@...are.com, dsouders@...are.com,
	cschamp@...are.com, akpm@...ux-foundation.org,
	virtualization@...ts.linux-foundation.org,
	"Andrew Stiegmann (stieg)" <astiegmann@...are.com>
Subject: Re: [vmw_vmci RFC 00/11] VMCI for Linux

On Fri, Jun 01, 2012 at 08:33:02AM -0700, Andy King wrote:
> Greg,
> 
> Thanks so much for the comments and apologies for the delayed response.
> 
> > Don't we have something like this already for KVM and maybe Xen?
> > virtio?  Can't you use that code instead of a new block of code that
> > is only used by vmware users?  It has virtual pci devices which
> > should give you what you want/need here, right?
> >
> > If not, why doesn't that work for you?  Would it be easier to just
> > extend it?
> 
> The VMCI virtual device for which this driver is intended has been
> around a lot longer than this submission might suggest.  The virtual
> hardware was released in a product before Rusty sent his RFC and
> quite a bit before it made it to mainline; there was, regrettably,
> no virtio then.
> 
> As such, it was designed to be its own transport, and it's something
> that is now very much fixed at the hardware level (enhancements
> not withstanding), and which we have to support all the way back.

What "hardware" are you refering to here?

> In addition to that, our hypervisor endpoints are written using
> the existing device backend; virtio doesn't currently make a lot of
> sense for them, and would require a lot of additional work.
> 
> All of this is unfortunate.  While I agree that virtio is certainly
> the right approach, and we need to avoid this proliferation, I think
> at this point we'd really like to try and upstream this in its current
> form.  There's certainly the possibility going forwards that we could
> add a glue layer, such that other clients could use virtio if they're
> willing to write their own hypervisor endpoints.
> 
> Does that sound reasonable?

Not really, why should we take an interface that is tied to something
that you are saying isn't something we should be using?  Don't you also
have control over the hypervisor side of things in order to properly
design this type of thing?

thanks,

greg k-h
--
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/