On 09/02/2010 06:01 PM, Eduard - Gabriel Munteanu wrote:
On Thu, Sep 02, 2010 at 12:58:13PM +0300, Michael S. Tsirkin wrote:
On Thu, Sep 02, 2010 at 12:12:00PM +0300, Eduard - Gabriel Munteanu wrote:
On Thu, Sep 02, 2010 at 08:19:11AM +0300, Michael S. Tsirkin wrote:
On Sat, Aug 28, 2010 at 05:54:55PM +0300, Eduard - Gabriel Munteanu wrote:
I don't insist on this solution, but what other way do you propose to
avoid the overhead for everyone not using an iommu?
I'm all for a solution that would help iommu as well,
but one wasn't yet proposed.
Hm, we could get even better performance by simply making the IOMMU a
compile-time option. It also avoids problems in case some device hasn't
been converted yet, and involves little to no tradeoffs. What do you
think?
AFAICT, there are few uses for the IOMMU besides development and
avantgarde stuff, as you note. So distributions can continue supplying
prebuilt QEMU/KVM packages compiled with the IOMMU turned off for the
time being. The only practical (commercial) use right now would be in
the case of private virtual servers, which could be divided further into
nested guests (though real IOMMU hardware isn't widespread yet).
Blue Swirl, in the light of this, do you agree on making it a
compile-time option?
That's not a practical long term solution. Eventually everything gets
turned on.
I don't really see a problem with the additional indirection. By the
time we reach actual hardware to satisfy the request, we'll have gone
through many such indirections; modern processors deal very well with them.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
