netdev - Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

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: <20070709.000640.122589877.davem@davemloft.net>
Date:	Mon, 09 Jul 2007 00:06:40 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	muli@...ibm.com
Cc:	mitch.a.williams@...el.com, shemminger@...ux-foundation.org,
	netdev@...r.kernel.org
Subject: Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

From: Muli Ben-Yehuda <muli@...ibm.com>
Date: Sun, 8 Jul 2007 19:17:30 +0300

> On Fri, Jul 06, 2007 at 12:20:19PM -0700, David Miller wrote:
> > From: "Williams, Mitch A" <mitch.a.williams@...el.com>
> > Date: Fri, 6 Jul 2007 10:14:56 -0700
> > 
> > > In my opinion, IOMMU table locking is the major issue with this
> > > type of architecture.  Since both Intel and AMD are touting IOMMUs
> > > for virtual- ization support, this is an issue that's going to
> > > need a lot of scrutiny.
> > 
> > For the allocation of IOMMU entries themselves you can play tricks
> > using atomic operations on 64-bit words of the allocator bitmap to
> > avoid locking that.
> 
> Hmm, any pointers?

I've never implemented it but it is certainly possible to do.

> That works, but isn't optimal when you have an isolation-capable IOMMU
> and you want the full isolation properties of the IOMMU. If you only
> flush the IOTLB when the allocator wraps around, a stale entry in the
> IOTLB can allow a DMA to go through for an IO entry that has already
> been unmapped. One way to mitigate that and still retain full
> isolation is to make sure no one else gets to use the frames that are
> the targets of the DMA until the translation has been flushed out of
> the IOTLB, but that requires pretty deep surgery.

Virtualization sucks doesn't it? :-)

It's one of the worst aspects of all of this virtualization business.
In my view it makes no sense to split up the physical hardware.  Just
give control nodes complete access to everything and instead of
playing games partializing real hardware, just give virtual instances
to everybody and be done with all of this complexity.

Anyways, hypervisors et al. have already decided to do this braindamage
so you will need to find some way to make it go fast now won't you? :)
-
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