| 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
| ||
|
Message-ID: <4A0448DF.90705@codemonkey.ws> Date: Fri, 08 May 2009 09:59:43 -0500 From: Anthony Liguori <anthony@...emonkey.ws> To: Avi Kivity <avi@...hat.com> CC: Gregory Haskins <ghaskins@...ell.com>, Chris Wright <chrisw@...s-sol.org>, Gregory Haskins <gregory.haskins@...il.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org Subject: Re: [RFC PATCH 0/3] generic hypercall support Avi Kivity wrote: > > Hmm, reminds me of something I thought of a while back. > > We could implement an 'mmio hypercall' that does mmio reads/writes via > a hypercall instead of an mmio operation. That will speed up mmio for > emulated devices (say, e1000). It's easy to hook into Linux > (readl/writel), is pci-friendly, non-x86 friendly, etc. By the time you get down to userspace for an emulated device, that 2us difference between mmio and hypercalls is simply not going to make a difference. I'm surprised so much effort is going into this, is there any indication that this is even close to a bottleneck in any circumstance? We have much, much lower hanging fruit to attack. The basic fact that we still copy data multiple times in the networking drivers is clearly more significant than a few hundred nanoseconds that should occur less than once per packet. Regards, Anthony Liguori -- 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/
Powered by blists - more mailing lists