Commit graph

198686 commits

Author SHA1 Message Date
Glauber Costa
3a0d7256a6 x86, paravirt: don't compute pvclock adjustments if we trust the tsc
If the HV told us we can fully trust the TSC, skip any
correction

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:05 +03:00
Glauber Costa
838815a787 x86: KVM guest: Try using new kvm clock msrs
We now added a new set of clock-related msrs in replacement of the old
ones. In theory, we could just try to use them and get a return value
indicating they do not exist, due to our use of kvm_write_msr_save.

However, kvm clock registration happens very early, and if we ever
try to write to a non-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.

So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:04 +03:00
Glauber Costa
84478c829d KVM: x86: export paravirtual cpuid flags in KVM_GET_SUPPORTED_CPUID
Right now, we were using individual KVM_CAP entities to communicate
userspace about which cpuids we support. This is suboptimal, since it
generates a delay between the feature arriving in the host, and
being available at the guest.

A much better mechanism is to list para features in KVM_GET_SUPPORTED_CPUID.
This makes userspace automatically aware of what we provide. And if we
ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:03 +03:00
Glauber Costa
0e6ac58acb KVM: x86: add new KVMCLOCK cpuid feature
This cpuid, KVM_CPUID_CLOCKSOURCE2, will indicate to the guest
that kvmclock is available through a new set of MSRs. The old ones
are deprecated.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:02 +03:00
Glauber Costa
11c6bffa42 KVM: x86: change msr numbers for kvmclock
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:01 +03:00
Glauber Costa
489fb490db x86, paravirt: Add a global synchronization point for pvclock
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi warps a minute in some systems.
(to be fair, it wasn't that bad in most of them). Investigating further, I
found out that such warps were caused by the very offset-based calculation
pvclock is based on.

This happens even on some machines that report constant_tsc in its tsc flags,
specially on multi-socket ones.

Two reads of the same kernel timestamp at approx the same time, will likely
have tsc timestamped in different occasions too. This means the delta we
calculate is unpredictable at best, and can probably be smaller in a cpu
that is legitimately reading clock in a forward ocasion.

Some adjustments on the host could make this window less likely to happen,
but still, it pretty much poses as an intrinsic problem of the mechanism.

A while ago, I though about using a shared variable anyway, to hold clock
last state, but gave up due to the high contention locking was likely
to introduce, possibly rendering the thing useless on big machines. I argue,
however, that locking is not necessary.

We do a read-and-return sequence in pvclock, and between read and return,
the global value can have changed. However, it can only have changed
by means of an addition of a positive value. So if we detected that our
clock timestamp is less than the current global, we know that we need to
return a higher one, even though it is not exactly the one we compared to.

OTOH, if we detect we're greater than the current time source, we atomically
replace the value with our new readings. This do causes contention on big
boxes (but big here means *BIG*), but it seems like a good trade off, since
it provide us with a time source guaranteed to be stable wrt time warps.

After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Avi Kivity <avi@redhat.com>
CC: Marcelo Tosatti <mtosatti@redhat.com>
CC: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:41:00 +03:00
Glauber Costa
424c32f1aa x86, paravirt: Enable pvclock flags in vcpu_time_info structure
This patch removes one padding byte and transform it into a flags
field. New versions of guests using pvclock will query these flags
upon each read.

Flags, however, will only be interpreted when the guest decides to.
It uses the pvclock_valid_flags function to signal that a specific
set of flags should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.

Signed-off-by: Glauber Costa <glommer@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
Acked-by: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:40:59 +03:00
Roedel, Joerg
b69e8caef5 KVM: x86: Inject #GP with the right rip on efer writes
This patch fixes a bug in the KVM efer-msr write path. If a
guest writes to a reserved efer bit the set_efer function
injects the #GP directly. The architecture dependent wrmsr
function does not see this, assumes success and advances the
rip. This results in a #GP in the guest with the wrong rip.
This patch fixes this by reporting efer write errors back to
the architectural wrmsr function.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:39 +03:00
Joerg Roedel
0d945bd935 KVM: SVM: Don't allow nested guest to VMMCALL into host
This patch disables the possibility for a l2-guest to do a
VMMCALL directly into the host. This would happen if the
l1-hypervisor doesn't intercept VMMCALL and the l2-guest
executes this instruction.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:38 +03:00
Joerg Roedel
3f0fd2927b KVM: x86: Fix exception reinjection forced to true
The patch merged recently which allowed to mark an exception
as reinjected has a bug as it always marks the exception as
reinjected. This breaks nested-svm shadow-on-shadow
implementation.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:37 +03:00
Avi Kivity
9ed3c444ab KVM: Fix wallclock version writing race
Wallclock writing uses an unprotected global variable to hold the version;
this can cause one guest to interfere with another if both write their
wallclock at the same time.

Acked-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:36 +03:00
Avi Kivity
8facbbff07 KVM: MMU: Don't read pdptrs with mmu spinlock held in mmu_alloc_roots
On svm, kvm_read_pdptr() may require reading guest memory, which can sleep.

Push the spinlock into mmu_alloc_roots(), and only take it after we've read
the pdptr.

Tested-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:35 +03:00
Shane Wang
cafd66595d KVM: VMX: enable VMXON check with SMX enabled (Intel TXT)
Per document, for feature control MSR:

  Bit 1 enables VMXON in SMX operation. If the bit is clear, execution
        of VMXON in SMX operation causes a general-protection exception.
  Bit 2 enables VMXON outside SMX operation. If the bit is clear, execution
        of VMXON outside SMX operation causes a general-protection exception.

This patch is to enable this kind of check with SMX for VMXON in KVM.

Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:34 +03:00
Marcelo Tosatti
f1d86e469b KVM: x86: properly update ready_for_interrupt_injection
The recent changes to emulate string instructions without entering guest
mode exposed a bug where pending interrupts are not properly reflected
in ready_for_interrupt_injection.

The result is that userspace overwrites a previously queued interrupt,
when irqchip's are emulated in userspace.

Fix by always updating state before returning to userspace.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:33 +03:00
Avi Kivity
84ad33ef5d KVM: VMX: Atomically switch efer if EPT && !EFER.NX
When EPT is enabled, we cannot emulate EFER.NX=0 through the shadow page
tables.  This causes accesses through ptes with bit 63 set to succeed instead
of failing a reserved bit check.

Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:32 +03:00
Avi Kivity
61d2ef2ce3 KVM: VMX: Add facility to atomically switch MSRs on guest entry/exit
Some guest msr values cannot be used on the host (for example. EFER.NX=0),
so we need to switch them atomically during guest entry or exit.

Add a facility to program the vmx msr autoload registers accordingly.

Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:31 +03:00
Avi Kivity
5dfa3d170e KVM: VMX: Add definitions for guest and host EFER autoswitch vmcs entries
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:31 +03:00
Avi Kivity
19b95dba03 KVM: VMX: Add definition for msr autoload entry
Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:30 +03:00
Avi Kivity
0ee75bead8 KVM: Let vcpu structure alignment be determined at runtime
vmx and svm vcpus have different contents and therefore may have different
alignmment requirements.  Let each specify its required alignment.

Signed-off-by: Avi Kivity <avi@redhat.com>
2010-05-19 11:36:29 +03:00
Xiao Guangrong
884a0ff0b6 KVM: MMU: cleanup invlpg code
Using is_last_spte() to cleanup invlpg code

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:28 +03:00
Xiao Guangrong
5e1b3ddbf2 KVM: MMU: move unsync/sync tracpoints to proper place
Move unsync/sync tracepoints to the proper place, it's good
for us to obtain unsync page live time

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:27 +03:00
Xiao Guangrong
85f2067c31 KVM: MMU: convert mmu tracepoints
Convert mmu tracepoints by using DECLARE_EVENT_CLASS

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:26 +03:00
Xiao Guangrong
22c9b2d166 KVM: MMU: fix for calculating gpa in invlpg code
If the guest is 32-bit, we should use 'quadrant' to adjust gpa
offset

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:25 +03:00
Stephen Rothwell
329d20ba45 KVM: powerpc: use of kzalloc/kfree requires including slab.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:24 +03:00
Gui Jianfeng
d35b8dd935 KVM: Fix mmu shrinker error
kvm_mmu_remove_one_alloc_mmu_page() assumes kvm_mmu_zap_page() only reclaims
only one sp, but that's not the case. This will cause mmu shrinker returns
a wrong number. This patch fix the counting error.

Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:23 +03:00
Eric Northup
5a7388c2d2 KVM: MMU: fix hashing for TDP and non-paging modes
For TDP mode, avoid creating multiple page table roots for the single
guest-to-host physical address map by fixing the inputs used for the
shadow page table hash in mmu_alloc_roots().

Signed-off-by: Eric Northup <digitaleric@google.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-19 11:36:22 +03:00
Daniel Mack
24af320245 ds2760_battery: Document ABI change
Add some documentation for the newly added writeable properties.

Suggested-by: Greg KH <gregkh@suse.de>
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2010-05-19 12:25:39 +04:00
Daniel Mack
bd52ca555e ds2760_battery: Make charge_now and charge_full writeable
For userspace tools and daemons, it might be necessary to adjust
the charge_now and charge_full properties of the ds2760 battery monitor,
for example for unavoidable corrections due to aging batteries.

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Matt Reimer <mreimer@vpop.net>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Len Brown <len.brown@intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2010-05-19 12:14:42 +04:00
Daniel Mack
0011d2d4a5 power_supply: Add support for writeable properties
This patch adds support for writeable power supply properties and
exposes them as writeable to sysfs.

A power supply implementation must implement two new function calls in
order to use that feature:

  int set_property(struct power_supply *psy,
                   enum power_supply_property psp,
                   const union power_supply_propval *val);

  int property_is_writeable(struct power_supply *psy,
                            enum power_supply_property psp);

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Len Brown <len.brown@intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Matt Reimer <mreimer@vpop.net>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2010-05-19 12:14:42 +04:00
Anton Vorontsov
5f487cd34f power_supply: Use attribute groups
This fixes a race between power supply device and initial
attributes creation, plus makes it possible to implement
writable properties.

[Daniel Mack - removed superflous return statement
 and dropped .mode attribute from POWER_SUPPLY_ATTR]

Suggested-by: Greg KH <gregkh@suse.de>
Suggested-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Tested-by: Daniel Mack <daniel@caiaq.de>
2010-05-19 12:14:28 +04:00
Rusty Russell
480b02df3a module: drop the lock while waiting for module to complete initialization.
This fixes "gave up waiting for init of module libcrc32c." which
happened at boot time due to multiple parallel module loads.

The problem was a deadlock: we wait for a module to finish
initializing, but we keep the module_lock mutex so it can't complete.
In particular, this could reasonably happen if a module does a
request_module() in its initialization routine.

So we change use_module() to return an errno rather than a bool, and if
it's -EBUSY we drop the lock and wait in the caller, then reaquire the
lock.

Reported-by: Brandon Philips <brandon@ifup.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Brandon Philips <brandon@ifup.org>
2010-05-19 17:33:39 +09:30
Ondrej Zary
fedb3d27d9 MODULE_DEVICE_TABLE(isapnp, ...) does nothing
On Monday 23 November 2009 04:29:53 Rusty Russell wrote:
> On Mon, 23 Nov 2009 07:31:57 am Ondrej Zary wrote:
> > The problem is that
> > scripts/mod/file2alias.c simply ignores isapnp.
>
> AFAICT it always has, and noone has complained until now.  Perhaps
> something was still reading /lib/modules/`uname -r`/modules.isapnpmap?

The patch below works fine (at least with Debian). It needs your first
patch that moves the definitions to mod_devicetable.h. Verified that
aliases for these modules are generated correctly:

drivers/media/radio/radio-sf16fmi.c
drivers/net/ne.c
drivers/net/3c515.c
drivers/net/smc-ultra.c
drivers/pcmcia/i82365.c
drivers/scsi/aha1542.c
drivers/scsi/aha152x.c
drivers/scsi/sym53c416.c
drivers/scsi/g_NCR5380.c

Tested with RTL8019AS (ne), AVA-1505AE (aha152x) and dtc436e (g_NCR5380)
cards - they now work automatically.

Generate pnp:d aliases for isapnp_device_tables. This allows udev to load
these modules automatically.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2010-05-19 17:33:39 +09:30
Rusty Russell
031ffd1711 hisax_fcpcipnp: fix broken isapnp device table.
Found that drivers/isdn/hisax/hisax_fcpcipnp.c has broken pnp device table -
wrong type (isapnp instead of pnp) and also ending record missing.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (split patch)
2010-05-19 17:33:38 +09:30
Rusty Russell
90def62df6 isapnp: move definitions to mod_devicetable.h so file2alias can reach them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2010-05-19 17:33:38 +09:30
Ben Hutchings
fd0c889489 intel-iommu: Set a more specific taint flag for invalid BIOS DMAR tables
We now know how to deal with these tables so that they are harmless.
Set TAINT_FIRMWARE_WORKAROUND instead of the default TAINT_WARN.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-05-19 08:38:11 +01:00
Ben Hutchings
3a8663ee61 intel-iommu: Combine the BIOS DMAR table warning messages
We have nearly the same code for warnings repeated four times.  Move
it into a separate function.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-05-19 08:37:58 +01:00
Ben Hutchings
92946bc72f panic: Add taint flag TAINT_FIRMWARE_WORKAROUND ('I')
This taint flag will initially be used when warning about invalid ACPI
DMAR tables.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-05-19 08:37:43 +01:00
Ben Hutchings
b2be05273a panic: Allow warnings to set different taint flags
WARN() is used in some places to report firmware or hardware bugs that
are then worked-around.  These bugs do not affect the stability of the
kernel and should not set the flag for TAINT_WARN.  To allow for this,
add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number
as argument.

Architectures that implement warnings using trap instructions instead
of calls to warn_slowpath_*() now implement __WARN_TAINT(taint)
instead of __WARN().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Helge Deller <deller@gmx.de>
Tested-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2010-05-19 08:36:48 +01:00
Ben Skeggs
893887ed75 drm/nouveau: fix i2c-related init table handlers
Mutliple issues.  INIT_ZM_I2C_BYTE/INIT_I2C_BYTE didn't even try and
use the register value, and all the handlers were using the wrong
slave address.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:22:08 +10:00
Ben Skeggs
04f542c07e drm/nouveau: support init table i2c device identifier 0x81
It appears to be meant to reference the second "default index".

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:22:07 +10:00
Ben Skeggs
f8b0be1a75 drm/nouveau: ensure we've parsed i2c table entry for INIT_*I2C* handlers
We may not have parsed the entry yet if the i2c_index is for an i2c bus
that's not referenced by a DCB encoder.

This could be done oh so much more nicely, except we have to care about
prehistoric DCB tables too, and they make life painful.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:22:05 +10:00
Ben Skeggs
92b9618761 drm/nouveau: display error message for any failed init table opcode
Some handlers don't report specific errors, but we still *really* want to
know if we failed to parse a complete init table.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:22:04 +10:00
Ben Skeggs
9170a82438 drm/nouveau: fix init table handlers to return proper error codes
We really want to be able to distinguish between INIT_DONE and an actual
error sometimes.  This commit fixes up several lazy "return 0;" to be
actual error codes, and explicitly reserves "0" as "success, but stop
parsing this table".

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:22:00 +10:00
Ben Skeggs
e9ebb68b86 drm/nv50: support fractional feedback divider on newer chips
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 16:21:59 +10:00
David S. Miller
2ec8c6bb5d Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Conflicts:
	include/linux/mod_devicetable.h
	scripts/mod/file2alias.c
2010-05-18 23:01:55 -07:00
Amit Kumar Salecha
7b39f90fab qlcnic: adding co maintainer
Adding Anirban as co maintainer

Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-05-18 22:57:36 -07:00
David S. Miller
0a625fd2ab crypto: n2 - Add Niagara2 crypto driver
Current deficiencies:

1) No HMAC hash support yet.

2) Although the algs are registered as ASYNC they always run
   synchronously.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19 14:14:04 +10:00
David S. Miller
bf06099db1 crypto: skcipher - Add ablkcipher_walk interfaces
These are akin to the blkcipher_walk helpers.

The main differences in the async variant are:

1) Only physical walking is supported.  We can't hold on to
   kmap mappings across the async operation to support virtual
   ablkcipher_walk operations anyways.

2) Bounce buffers used for async more need to be persistent and
   freed at a later point in time when the async op completes.
   Therefore we maintain a list of writeback buffers and require
   that the ablkcipher_walk user call the 'complete' operation
   so we can copy the bounce buffers out to the real buffers and
   free up the bounce buffer chunks.

These interfaces will be used by the new Niagara2 crypto driver.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19 14:13:07 +10:00
David S. Miller
a8f1a05292 crypto: testmgr - Add testing for async hashing and update/final
Extend testmgr such that it tests async hash algorithms,
and that for both sync and async hashes it tests both
->digest() and ->update()/->final() sequences.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19 14:12:03 +10:00
David S. Miller
beb63da739 crypto: tcrypt - Add speed tests for async hashing
These are invoked in the 'mode' range of 400 to 499.

The cost of async vs. sync for the software algorithm implementations
varies.  It can be as low as 16 cycles but as much as a couple hundred.

Here two runs of md5 testing, async then sync:

testing speed of async md5
test  0 (   16 byte blocks,   16 bytes per update,   1 updates):   2448 cycles/operation,  153 cycles/byte
test  1 (   64 byte blocks,   16 bytes per update,   4 updates):   4992 cycles/operation,   78 cycles/byte
test  2 (   64 byte blocks,   64 bytes per update,   1 updates):   3808 cycles/operation,   59 cycles/byte
test  3 (  256 byte blocks,   16 bytes per update,  16 updates):  14000 cycles/operation,   54 cycles/byte
test  4 (  256 byte blocks,   64 bytes per update,   4 updates):   8480 cycles/operation,   33 cycles/byte
test  5 (  256 byte blocks,  256 bytes per update,   1 updates):   7280 cycles/operation,   28 cycles/byte
test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates):  50016 cycles/operation,   48 cycles/byte
test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates):  22496 cycles/operation,   21 cycles/byte
test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates):  21232 cycles/operation,   20 cycles/byte
test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates): 117184 cycles/operation,   57 cycles/byte
test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates):  43008 cycles/operation,   21 cycles/byte
test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates):  40176 cycles/operation,   19 cycles/byte
test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):  39888 cycles/operation,   19 cycles/byte
test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 194176 cycles/operation,   47 cycles/byte
test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates):  84096 cycles/operation,   20 cycles/byte
test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):  78336 cycles/operation,   19 cycles/byte
test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):  77120 cycles/operation,   18 cycles/byte
test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates): 403056 cycles/operation,   49 cycles/byte
test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates): 166112 cycles/operation,   20 cycles/byte
test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates): 154768 cycles/operation,   18 cycles/byte
test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates): 151904 cycles/operation,   18 cycles/byte
test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates): 155456 cycles/operation,   18 cycles/byte

testing speed of md5
test  0 (   16 byte blocks,   16 bytes per update,   1 updates):   2208 cycles/operation,  138 cycles/byte
test  1 (   64 byte blocks,   16 bytes per update,   4 updates):   5008 cycles/operation,   78 cycles/byte
test  2 (   64 byte blocks,   64 bytes per update,   1 updates):   3600 cycles/operation,   56 cycles/byte
test  3 (  256 byte blocks,   16 bytes per update,  16 updates):  14080 cycles/operation,   55 cycles/byte
test  4 (  256 byte blocks,   64 bytes per update,   4 updates):   8560 cycles/operation,   33 cycles/byte
test  5 (  256 byte blocks,  256 bytes per update,   1 updates):   7040 cycles/operation,   27 cycles/byte
test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates):  50592 cycles/operation,   49 cycles/byte
test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates):  22736 cycles/operation,   22 cycles/byte
test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates):  24960 cycles/operation,   24 cycles/byte
test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates):  99312 cycles/operation,   48 cycles/byte
test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates):  43520 cycles/operation,   21 cycles/byte
test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates):  40704 cycles/operation,   19 cycles/byte
test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):  39552 cycles/operation,   19 cycles/byte
test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 196720 cycles/operation,   48 cycles/byte
test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates):  85152 cycles/operation,   20 cycles/byte
test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):  79408 cycles/operation,   19 cycles/byte
test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):  76816 cycles/operation,   18 cycles/byte
test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates): 391520 cycles/operation,   47 cycles/byte
test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates): 168464 cycles/operation,   20 cycles/byte
test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates): 156912 cycles/operation,   19 cycles/byte
test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates): 154016 cycles/operation,   18 cycles/byte
test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates): 153856 cycles/operation,   18 cycles/byte

We can ditch the sync hash code at some point if we feel that makes
sense.  For now I've left it there.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19 14:11:21 +10:00