Am 05.03.2014 12:30, schrieb Paolo Bonzini: > Il 05/03/2014 12:05, Andreas Färber ha scritto: >> Am 04.03.2014 15:00, schrieb Paolo Bonzini: >>> This series includes all the pending work on QOMifying the memory >>> backends. >> [snip] >> >> There's also a recent RFC from Chen Fan about how to model the >> association between NUMA nodes and CPU socket/core/thread that >> would/should influence this series if we're aiming for 2.1 now. > > I don't think it should, apart from conflicts. This series only changes > things about memory. CPUs are handled the same before and after the > patches. > >> I didn't review it in-depth yet, but minor technical issues apart, I >> think we need to keep NUMA and CPU separate, > > I agree.
Here you agreed ... >> Compare that to: >> >> /machine >> /node[0] # This is not really telling! >> /socket[0] >> /core[0] >> /thread[0] # So CPUState != thread? >> cpu -> /machine/unassigned/device[0] >> /unassigned >> /device[0] > > I think this is better; in our world we can have multiple sockets in the > same NUMA node. But CPUState == thread, so you can have just /thread[0] > -> /machine/unassigned/device[0]. ... but you seem to have missed my point about separation. Here the socket object is a child<> of the NUMA node and would get realized together with it but separate from the link<>ed CPUState. > Alternatively, and to keep CPU + NUMA even *more* separate: > > /machine > /node[0] > /cpu[0] -> /machine/unassigned/device[0] > ... > /socket[0] > /core[0] > /thread[0] -> /machine/unassigned/device[0] > /unassigned > /device[0] Now this is pretty much my proposal ;) except that you retained the criticized "node" as name and moved "socket[0]" out of /machine/unassigned (I had /machine/peripheral in mind for -device) and keep the CPUState out of the socket object. Anthony had requested hot-add to happen via "device_add Xeon4242", adding a full socket object with 6 cores at once. In that case CPUState needs to be an integral part of that socket-derived device for recursive realization. Objects that are just link<>ed to wouldn't get automatically realized. Since the only two other places for creating an X86CPU are PC code plus cpu-add I don't envision problems with adding it as child<> to its core. >> which then brings up the >> question Chen Fan asked about whether we need to support splitting CPU >> threads of one core or CPU cores of one socket onto different NUMA >> nodes. If we can stop supporting this, 2.0 would be a good point in time >> to catch this with an error message at least, even if the remodeling >> depending on it happens post-2.0. > >> Note that according to my interpretation of QOM ABI stability rules we >> can't just turn a link<cpu> into a child<cpu> without renaming, thus >> trying to be forward-looking for where we want to go design-wise. > > I think we can. Children and links look exactly the same from the outside. Well, we can't qom-get/qom-set a path string from/to a child<> property, can we? But paths can indeed be resolved either way. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
