From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7nW-0003PV-DO for qemu-devel@nongnu.org; Thu, 19 May 2011 14:18:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN7nV-0001Co-DW for qemu-devel@nongnu.org; Thu, 19 May 2011 14:18:10 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:38071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7nV-0001Cb-B2 for qemu-devel@nongnu.org; Thu, 19 May 2011 14:18:09 -0400 Received: by ywl41 with SMTP id 41so1185954ywl.4 for ; Thu, 19 May 2011 11:18:08 -0700 (PDT) Message-ID: <4DD55EDD.9000308@codemonkey.ws> Date: Thu, 19 May 2011 13:18:05 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E610.1080201@siemens.com> <4DD4199E.2000702@codemonkey.ws> <4DD41DBB.2020108@web.de> <20110519082644.GC28399@redhat.com> <4DD4D53F.1090108@web.de> <4DD52082.1080804@codemonkey.ws> <4DD521C8.5020903@siemens.com> <4DD52363.7080201@codemonkey.ws> <4DD52526.3070909@redhat.com> In-Reply-To: <4DD52526.3070909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , qemu-devel , Gleb Natapov , Peter Maydell On 05/19/2011 09:11 AM, Avi Kivity wrote: > On 05/19/2011 05:04 PM, Anthony Liguori wrote: >> >> Right, the chipset register is mainly used to program the contents of >> SMM. >> >> There is a single access pin that has effectively the same semantics >> as setting the chipset register. >> >> It's not a per-CPU setting--that's the point. You can't have one CPU >> reading SMM memory at the exactly same time as accessing VGA. >> >> But I guess you can never have two simultaneous accesses anyway so >> perhaps it's splitting hairs :-) > > Exactly - it just works. Well, not really. kvm.ko has a global mapping of RAM regions and currently only allows code execution from RAM. This means the only way for QEMU to enable SMM support is to program the global RAM regions table to enable allow RAM access for the VGA region. The problem with this is that it's perfectly conceivable to have CPU 0 in SMM mode while CPU 1 is doing MMIO to the VGA planar. The same problem exists with PAM. It would be much easier to implement PAM correctly in QEMU if it were possible to execute code via MMIO as we could just mark the BIOS memory as non-RAM and deal with the dispatch ourselves. Would it be fundamentally hard to support this in KVM? I guess you would need to put the VCPU in single step mode and maintain a page to copy the results into. Regards, Anthony Liguori > > btw, a way to implement it would be to have two memory maps, one for SMM > and one for non-SMM, and select between them based on the CPU mode. >