From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLvy-0003Xz-0L for qemu-devel@nongnu.org; Fri, 20 May 2011 05:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNLvx-0000vz-5Y for qemu-devel@nongnu.org; Fri, 20 May 2011 05:23:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLvw-0000vr-O6 for qemu-devel@nongnu.org; Fri, 20 May 2011 05:23:49 -0400 Message-ID: <4DD6331E.8000105@redhat.com> Date: Fri, 20 May 2011 12:23:42 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> <4DD580FD.2030409@codemonkey.ws> In-Reply-To: <4DD580FD.2030409@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Richard Henderson On 05/19/2011 11:43 PM, Anthony Liguori wrote: > On 05/19/2011 09:12 AM, Avi Kivity wrote: >> The memory API separates the attributes of a memory region (its size, >> how >> reads or writes are handled, dirty logging, and coalescing) from >> where it >> is mapped and whether it is enabled. This allows a device to configure >> a memory region once, then hand it off to its parent bus to map it >> according >> to the bus configuration. >> >> Hierarchical registration also allows a device to compose a region >> out of >> a number of sub-regions with different properties; for example some >> may be >> RAM while others may be MMIO. >> >> + struct { >> + /* If nonzero, specify bounds on access sizes beyond which a >> machine >> + * check is thrown. >> + */ >> + unsigned min_access_size; >> + unsigned max_access_size; >> + /* If true, unaligned accesses are supported. Otherwise >> unaligned >> + * accesses throw machine checks. >> + */ >> + bool unaligned; >> + } valid; > > Under what circumstances would this be used? > > The behavior of devices that receive non-natural accesses varies wildly. > > For PCI devices, invalid accesses almost always return ~0. I can't > think of a device where an MCE would occur. This was requested by Richard, so I'll let him comment. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.