From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8bv-0000ZX-Su for qemu-devel@nongnu.org; Thu, 19 May 2011 15:10:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN8bu-0002P6-RH for qemu-devel@nongnu.org; Thu, 19 May 2011 15:10:15 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:51764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8bu-0002Om-B9 for qemu-devel@nongnu.org; Thu, 19 May 2011 15:10:14 -0400 Message-ID: <4DD56B13.8010004@web.de> Date: Thu, 19 May 2011 21:10:11 +0200 From: Jan Kiszka 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> <4DD55EDD.9000308@codemonkey.ws> <4DD56693.2070602@web.de> <4DD5694C.10703@codemonkey.ws> In-Reply-To: <4DD5694C.10703@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83B0ACE7C104256C5A2B42DC" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Avi Kivity , Gleb Natapov , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83B0ACE7C104256C5A2B42DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-05-19 21:02, Anthony Liguori wrote: > On 05/19/2011 01:50 PM, Jan Kiszka wrote: >> On 2011-05-19 20:18, Anthony Liguori wrote: >>> 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 regio= n. >>> >>> 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 impleme= nt >>> 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. >> >> If we already have to change KVM (I guess we have to), let's better ad= d >> per-CPU memory slot support. That will allow to switch between VGA and= >> SMRAM without costly dispatching. At this chance, I think we also need= >> some support for half-MMIO (MMIO on write, RAM on read) for proper fla= sh >> support. >=20 > This is needed for PAM too. Yeah, right, there were some to-do comments I strictly ignored >=20 > But RAM isn't mapped per-CPU so this is at best an optimization. SMRAM is mapped per CPU, depending on the execution mode. That is the poi= nt. > You > can (and do) execute instructions out of non-RAM memory though. I thin= k > if we lifted this restriction in KVM, it would allow us to handle > SMRAM/PAM in a more thorough way. I do not disagree that having such feature would be nice for certain corner cases. But executing code by jumping to user space on every instruction fetch, maybe just to dispatch between SMRAM and normal MMIO on a per-CPU base, will give you horrible performance. That can at best be an intermediate step, though I bet it's better to address both at roughly the same time. Jan --------------enig83B0ACE7C104256C5A2B42DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VaxMACgkQitSsb3rl5xQIgACg7abyceKsXqdNuypOD6txZtY7 SfsAoN+FUuP46evBaLblDO4dYXPgV9xF =1mp0 -----END PGP SIGNATURE----- --------------enig83B0ACE7C104256C5A2B42DC--