On Thu, Oct 13, 2011 at 12:53:22PM +0100, Daniel P. Berrange wrote: > On Mon, Oct 03, 2011 at 03:28:44PM +0530, Bharata B Rao wrote: > > Hi, > > > > I discussed the possibilities of adding NUMA topology XML specification > > support for guests here some time back. Since my latest proposal > > (http://permalink.gmane.org/gmane.comp.emulators.libvirt/44626) > > didn't get any response, I am posting a prototype implementation > > that supports specifying NUMA topology for QEMU guests. > > > > - The implementation is based on the last proposal I listed above. > > So we're basically only allowing a flat NUMA toplogy > > <numa> > <node cpus='0,2,4,6' mems='1024> > <node cpus='8,10,12,14' mems='1024> > <node cpus='1,3,5,7' mems='1024'> > <node cpus='9,11,13,15' mems='1024'> > </numa> > > which mirrors what QEMU allows currently. Should we need > to support a hierarchy, we can trivially extend this > syntax in a backwards compatible fashion > > <numa> > <node> > <node cpus='0,2,4,6' mems='1024> > <node cpus='8,10,12,14' mems='1024> > </node> > <node> > <node cpus='1,3,5,7' mems='1024'> > <node cpus='9,11,13,15' mems='1024'> > </node> > </numa> > > so I think this limitation is OK for now. Fine then. > > In the virsh capabilities XML, we actually use the > word 'cell' rather than 'node'. I think it might > be preferrable to be consistent and use 'cell' here > too. I feel NUMA node sounds more familiar than NUMA cell. But if libvirt prefers cell, we can go with cell I suppose. > > > - The implementation is for QEMU only. > > That's fine. > > > - The patchset has gone through extremely light testing and I have > > just tested booting a 2 socket 2 core 2 thread QEMU guest. > > - I haven't really bothered to cover all the corner cases and haven't > > run libvirt tests after this patchset. For eg, there is no code > > to validate if the CPU combination specified by <topology> and > > <numa> match with each other. I plan to cover all these after we > > freeze the specification itself. > > ok > > > WRT the question about CPU enumeration order in the URL quoted > above. I don't think it matters whether we enumerate CPUs in the > same order as real hardware. The key thing is that we just choose > an order, document what *our* enumeration order is, and then stick > to it forever. Ok fine. Regards, Bharata. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list