linux-kernel - Re: [RFC PATCH 3/4] KVM: emulate: avoid per-byte copying in instruction fetches

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

Message-ID: <5369F167.5000005@redhat.com>
Date:	Wed, 07 May 2014 10:40:07 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Bandan Das <bsd@...hat.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 3/4] KVM: emulate: avoid per-byte copying in instruction
 fetches

Il 07/05/2014 06:36, Bandan Das ha scritto:
>> > +	_x = *(_type __aligned(1) *) &_fc->data[ctxt->_eip - _fc->start]; \
> For my own understanding, how does the __aligned help here ?

Except for 16-byte SSE accesses, x86 doesn't distinguish aligned and 
unaligned accesses.  You can read 4 bytes at 0x2345 and the processor 
will do the right thing.  Still it's better to tell the compiler what 
we're doing.

> Wouldn't
> that result in unaligned accesses that will actually impact performance ?

These accesses *can* and will in fact be unaligned.  For example, say 
you have "mov ax,0x1234" which is 0xb8 0x34 0x12.  When you read it into 
the fetch cache, you will have data[0] == 0xb8, data[1] == 0x34, data[2] 
== 0x12.  Fetching the 16-bit immediate from data[1] will then be an 
unaligned access.

Paolo
--
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/