From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7h2-0000dH-Ue for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN7h1-0008R1-4i for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:28 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:43843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7h0-0008Pj-L4 for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:26 -0400 Message-ID: <4DD55D48.1080000@web.de> Date: Thu, 19 May 2011 20:11:20 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD52848.6030102@codemonkey.ws> <4DD52910.4080106@siemens.com> <4DD52B0E.2080604@codemonkey.ws> <4DD52BF2.2080506@redhat.com> <20110519161731.GA27310@redhat.com> <4DD5446A.6030003@siemens.com> <20110519162805.GC27310@redhat.com> <4DD545B2.70705@siemens.com> <4DD54729.8050707@codemonkey.ws> <4DD54A2C.6050706@siemens.com> <20110519171207.GE27310@redhat.com> In-Reply-To: <20110519171207.GE27310@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig51286D8D3C2BA3BADE866CC3" 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: Gleb Natapov Cc: Avi Kivity , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig51286D8D3C2BA3BADE866CC3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-05-19 19:12, Gleb Natapov wrote: > On Thu, May 19, 2011 at 06:49:48PM +0200, Jan Kiszka wrote: >> On 2011-05-19 18:36, Anthony Liguori wrote: >>> On 05/19/2011 11:30 AM, Jan Kiszka wrote: >>>> On 2011-05-19 18:28, Gleb Natapov wrote: >>>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote: >>>>>> On 2011-05-19 18:17, Gleb Natapov wrote: >>>>>>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote: >>>>>>>> On 05/19/2011 05:37 PM, Anthony Liguori wrote: >>>>>>>>> >>>>>>>>> So.... do you do: >>>>>>>>> >>>>>>>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority= ) >>>>>>>>> { >>>>>>>>> chipset_register_region(bus->chipset, mr, priority + 1); >>>>>>>>> } >>>>>>>>> >>>>>>>>> I don't really understand how you can fold everything into one >>>>>>>>> table and not allow devices to override their parents using >>>>>>>>> priorities. >>>>>>>> >>>>>>>> Think of how a window manager folds windows with priorities onto= a >>>>>>>> flat framebuffer. >>>>>>>> >>>>>>>> You do a depth-first walk of the tree. For each child list, you= >>>>>>>> iterate it from the lowest to highest priority, allowing later >>>>>>>> subregions override earlier subregions. >>>>>>>> >>>>>>> And how you set those priorities in a sensible way? Why two devic= e on a >>>>>>> PCI bus will want to register their memory region with anything b= ut >>>>>>> highest priority? And if you let PCI subsystem to assign prioriti= es how >>>>>>> it will coordinate with ISA subsystem/memory controller what prio= rities >>>>>>> to assign to get meaningful system? >>>>>> >>>>>> Priorities>default will only be used for explicit overlays, e.g. R= AM >>>>>> over MMIO in PAM regions. Non-default priorities won't be assigned= to >>>>>> normal PCI bars or any other device's region. >>>>>> >>>>> That does not explain who and how assign those priorities in global= ly >>>>> meaningful way. >>>> >>>> There are no global priorities. Priorities are only used inside each= >>>> level of the memory region hierarchy to generate a resulting, flatte= ned >>>> view for the next higher level. At that level, everything imported f= rom >>>> below has the default prio again, ie. the lowest one. >>> >>> Then SMM is impossible. >> >> For sure it is. The CPU and the chipset, each at their mapping level, >> create a corresponding RAM region and register it with higher prio at >> the SMRAM start address (CPU and chipset will need to exchange that >> address or otherwise coordinate the mapping information - the price fo= r >> per-CPU SMRAM). >> > So to get priorities right two components need to know a priori about > overlap and coordinate the priorities? Nope, the integrator, i.e. the bridge (an abstract one, please) needs to know that it registers possibly overlapping regions. It declares that some region is allowed to overlap by using the corresponding service, optionally providing a priority > default in order get a well-define ordering. >=20 >>> >>> Why do we need priorities at all? There should be no overlap at each= =20 >>> level in the hierarchy. >>> >>> If you have overlapping BARs, the PCI bus will always send the reques= t=20 >>> to a single device based on something that's implementation specific.= =20 >>> This works because each PCI device advertises the BAR locations and=20 >>> sizes in it's config space. >> >> That's not a use case for priorities at all. Priorities are useful for= >> PAM and SMRAM-like scenarios. >> > It looks like you are talking about very shallow model were overlap may= > happen only in chipset and chipset directly controls all of the physica= l > address space. But we need to have solution for more complex topologies= > where PAM/SMRAM like scenarios may happen on each level. That's precisely my goal. PAM/SMRAM is just one example for such overlays at any bridge level, not just the chipset. > You are dismissing > PCI as an example because all memory regions there are of the same > priority, but this is just the special case of more generic scenario. > Why this is not the "use case for priorities"? Because we know that PCI bars can overlap and are allowed to, and that this will generate some random result. So we don't need to worry about assigning priorities, we just need to declare overlaps valid. Jan --------------enig51286D8D3C2BA3BADE866CC3 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/ iEYEARECAAYFAk3VXUwACgkQitSsb3rl5xT4bQCg2rv6CstuuSTpxYgS6dMpit98 EUQAoK1Ac6mFTy7AuQb05qIujIfPWaQa =MkYB -----END PGP SIGNATURE----- --------------enig51286D8D3C2BA3BADE866CC3--