netdev - Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model

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-next>] [day] [month] [year] [list]

Message-Id: <4A8A67F70200005A000528F8@sinclair.provo.novell.com>
Date:	Tue, 18 Aug 2009 06:36:07 -0600
From:	"Gregory Haskins" <GHaskins@...ell.com>
To:	<avi@...hat.com>
Cc:	<mingo@...e.hu>, <gregory.haskins@...il.com>,
	<alacrityvm-devel@...ts.sourceforge.net>, <mst@...hat.com>,
	<kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model

Yeah, I agree.  I am not advocating we expend energy on this now.  But my thoughts at the time were that that particular problem can be solved at io-setup time with some kind of call to qualify the address.

Iow: a slow path call with the address would return flags on whether iowrite() should do a real io, or a IOoHC.

-greg
 
-----Original Message-----
From: Avi Kivity <avi@...hat.com>
To: Gregory Haskins <GHaskins@...ell.com>
Cc:  <mingo@...e.hu>
Cc:  <gregory.haskins@...il.com>
Cc:  <alacrityvm-devel@...ts.sourceforge.net>
Cc:  <mst@...hat.com>
Cc:  <kvm@...r.kernel.org>
Cc:  <linux-kernel@...r.kernel.org>
Cc:  <netdev@...r.kernel.org>

Sent: 8/18/2009 6:29:08 AM
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model	 for

On 08/18/2009 03:24 PM, Gregory Haskins wrote:
> (Again on the top post)
>
> No, Avi, nothing has changed to my knowledge.  I just saw that you and Michael were heading down the same path, so I thought I might interject that we've already covered that ground.
>
> As of right now, I am of the opinion that its not worth any change in the short term, and may be worth IOoHC in the long term (primarily so that mmios get a boost)
>    

The primary issue with IOoHC is that while hypercalls are faster than 
emulated mmio, they're much slower than assigned mmio.  So we have to 
distinguish between these two cases, which gets kinda icky.

-- 
error compiling committee.c: too many arguments to function


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html