From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41118)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1YYfQz-0000Vd-PG
	for qemu-devel@nongnu.org; Thu, 19 Mar 2015 14:44:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1YYfQw-0007sv-Hr
	for qemu-devel@nongnu.org; Thu, 19 Mar 2015 14:44:45 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39411)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1YYfQw-0007so-96
	for qemu-devel@nongnu.org; Thu, 19 Mar 2015 14:44:42 -0400
Message-ID: <550B1909.7070501@redhat.com>
Date: Thu, 19 Mar 2015 19:44:25 +0100
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <1426515305-17766-1-git-send-email-somlo@cmu.edu>
	<1426515305-17766-7-git-send-email-somlo@cmu.edu>
	<5508202E.7020700@redhat.com>
	<20150319182755.GA890@morn.localdomain>
In-Reply-To: <20150319182755.GA890@morn.localdomain>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 6/6] qga: RFC: guest-side retrieval of
 fw_cfg file
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: matt.fleming@intel.com, mdroth@linux.vnet.ibm.com, rjones@redhat.com, jordan.l.justen@intel.com, "Gabriel L. Somlo" <somlo@cmu.edu>, gleb@cloudius-systems.com, qemu-devel@nongnu.org, gsomlo@gmail.com, kraxel@redhat.com, pbonzini@redhat.com

On 03/19/15 19:27, Kevin O'Connor wrote:
> On Tue, Mar 17, 2015 at 01:38:06PM +0100, Laszlo Ersek wrote:
>> On 03/16/15 15:15, Gabriel L. Somlo wrote:
>>>   1. I can't for the life of me figure out how to stop gcc -O2
>>>      from assuming the if() test below is ALWAYS FALSE, and thus
>>>      optimizing it out completely. For now I've forced -O0 on
>>>      the entire function, but for some reason fw_cfg_read(&fcfile, ...)
>>>      does not appear to count as potentially modifying fcfile...
> [...]
>>> +static void
>>> +fw_cfg_read(void *buf, int len)
>>> +{
>>> +    insb(PORT_FW_CFG_DATA, buf, len);
>>> +}
> [...]
>> I think fw_cfg_read() is inlined under -O2, and the insb() from that
>> function is somehow confusing gcc.
>>
>> From "/usr/include/sys/io.h", on my RHEL-7.1 laptop:
>>
>> static __inline void
>> insb (unsigned short int __port, void *__addr, unsigned long int __count)
>> {
>>   __asm__ __volatile__ ("cld ; rep ; insb":"=D" (__addr), "=c" (__count)
>>                         :"d" (__port), "0" (__addr), "1" (__count));
>> }
> 
> My read of this is that gcc knows it must emit the instruction, and it
> knows that __addr and __count can change.  But, it doesn't know that
> the memory at *__addr can change.  I'd see if a barrier() fixes it.
> 
> See the section on "clobber" at:
> 
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
> 
> In particular:
> 
>   You can use a trick to avoid this if the size of the memory being
>   accessed is known at compile time. For example, if accessing ten bytes
>   of a string, use a memory input like:
> 
>   {"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.

I think you nailed it, thanks.

Laszlo