From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/vLAPIC: adjust types in internal read/write handling Date: Mon, 22 Jun 2015 15:06:39 +0100 Message-ID: <5588166F.60908@citrix.com> References: <55881270020000780008778A@mail.emea.novell.com> <5587FC61.8090009@citrix.com> <558821F80200007800087872@mail.emea.novell.com> <5588077D.9080908@citrix.com> <558829680200007800087953@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z72NM-0005Ub-Nl for xen-devel@lists.xenproject.org; Mon, 22 Jun 2015 14:07:04 +0000 In-Reply-To: <558829680200007800087953@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 22/06/15 14:27, Jan Beulich wrote: >>>> On 22.06.15 at 15:02, wrote: >> On 22/06/15 13:55, Jan Beulich wrote: >>>>>> On 22.06.15 at 14:15, wrote: >>>> On 22/06/15 12:49, Jan Beulich wrote: >>>>> @@ -847,47 +834,41 @@ static int vlapic_write(struct vcpu *v, >>>>> * According to the IA32 Manual, all accesses should be 32 bits. >>>>> * Some OSes do 8- or 16-byte accesses, however. >>>>> */ >>>>> - val = (uint32_t)val; >>>>> - if ( len != 4 ) >>>>> + if ( unlikely(len != 4) ) >>>>> { >>>>> - unsigned int tmp; >>>>> - unsigned char alignment; >>>>> - >>>>> - gdprintk(XENLOG_INFO, "Notice: Local APIC write with len = >> %lx\n",len); >>>>> - >>>>> - alignment = offset & 0x3; >>>>> - (void)vlapic_read_aligned(vlapic, offset & ~0x3, &tmp); >>>>> + unsigned int tmp = vlapic_read_aligned(vlapic, offset & ~3); >>>>> + unsigned char alignment = (offset & 3) * 8; >>>>> >>>>> switch ( len ) >>>>> { >>>>> case 1: >>>>> - val = ((tmp & ~(0xff << (8*alignment))) | >>>>> - ((val & 0xff) << (8*alignment))); >>>>> + val = ((tmp & ~(0xff << alignment)) | >>>>> + ((val & 0xff) << alignment)); >>>> These should probably be explicitly unsigned constants, to avoid issues >>>> with shifting a 1 into the sign bit. >>> I don't see what harm the sign bit would do here - even if the shift >>> operation is one on signed int, the & converts the operand to >>> unsigned int anyway (and with them being the same size, the >>> binary representation doesn't change). >> The problem is with 0xff << 24, which where the sign bit will change >> given the shift. >> >> If 0xff is interpreted as signed, then shifted, then promoted to >> unsigned by the ~ operation, then the result is undefined behaviour >> (altering the sign bit of a number with a shift). > Okay, while I can buy that, I suppose we've got many more of these > throughout the tree (and the compiler is treating them quite fine). We likely have. I try my best to fix them as I find them. As for the compiler, it is probably easiest to ignore the potential problem which ends up generating correct code (and is a legitimate action to take with UB). It is more likely to be a problem with extreme levels of optimisations enabled, as the compiler tries harder and harder to throw operations away. ~Andrew