On Mon, 22 May 2017 19:15:36 +1000 David Gibson <da...@gibson.dropbear.id.au> wrote: [...] > > > > > > Hrm. I dislike code for the core object directly reaching into the > > > machine to check the compat flag here (and a bunch of other places > > > below). I can think of a few possible ways of avoiding this: > > > > > > 1) The most direct is to make another compat flag in the cpu core > > > object, set by the machine. Straightforward, but ugly. > > > > > > 2) Use a property to optionally pass a reference to the ICP array into > > > the core object. If set it will give the cpu objects ICPs from that > > > array (compat mode), if not it will allocate them (new style mode). > > > > for 2) we can just use a object_property_add_const_link() like > > we do to pass the 'xics' object which is needed by the ICSes. > > Yes. Though you'll need to pass one for each thread down to the core > object, which will be fiddly. > > > > 3) (Preferred, if it works) Always have the core allocate ICPs for > > > each CPU. For compat mode instead of directly allocating ICPs, the > > > machine sets up an array of pointers to the existing ICPs for each > > > CPU. The "extra" slots that don't have ICPs in new-style allocation > > > get references to dummy ICP objects (maybe even all the same one). > > > Only the dummy ICP(s) are allocated by the machine, the rest remain > > > owned by the cpu. > > > > I like this solution too as it should isolate the compat handling under > > the machine, maybe even in a single routine. > > Right, that's the hope. Plus it means we reduce the difference in > runtime QOM structure between the two modes, which is best when > possible. >
I'll try to do 3)
pgpNCw619H509.pgp
Description: OpenPGP digital signature