[...] >> Hi Chris, >> >> I'm working on a neighboring item with implementing cpu-comparison. Since >> there >> are some similarities with both comparison and baseline, I'd like for us to >> work together on driving both features forward. >> >> Thus far, I've created the qemu_monitor_json interface, tied it into the qemu >> driver, and can issue virsh cpu-compare <file.xml> successfully. (Though it's >> no where near perfect yet ;) ) >> >> I've already noted some differences between our JSON interaces (namely, yours >> works with qemuMonitorCPUModelInfoPtrs, and mine works with virCPUDefPtrs). >> >> Ultimately, I think your patches are in good shape. >> >> Let's discuss further on my comparison patches posted here: >> >> https://www.redhat.com/archives/libvir-list/2018-April/msg01375.html >> >> I'm open to any suggestions / design ideas you have. >> >> -- >> Respectfully, >> - Collin Walling >> >> > > Hi Collin, > > Not sure if you received my previous reply on this... It's possible it got stuck in my mail box. > > Seems like we have got our wires crossed on this... > I also have an implementation going in parallel for virsh cpu-comparison I have been working under Bug 1511996 - Implement "virsh cpu-compare" for s390x. > > As you mentioned the requirements for both are similar in that > 1) Both functions work with cpu model info > 2) Both functions require a qemu instance to be spun up during execution. > > I took a look at your code for cpu-comparison. > > 1) Seems like it will be good to compare and contrast how both of us spin up the qemu instance for best practice I look forward to seeing your approach on this. > 2) Looks like you translate between XML --- virCpuDef --- qemu qmp JSON > I ended up just going straight from XML --- qemu qmp JSON > > Think there is an open question about which approach is best. I did XML -> CpuDef -> JSON because my approach utilized the CpuDef found in virCaps (which I stole from qemuCaps, but it looks like this is not the way we should being do this). It looked cleaner to pass two cpudefs to the monitor function. I think it'll be more clear to both of us which approach is better once we see how the host / hypervisor CPU will be stored. > > I have only pushed the qmp JSON functions to libvirt-list so far. > (In fact I just pushed v2 if you have a moment to look again.) I'll take a look at them. > > However I have the rest of the code for baseline, including launching the qemu instance, working and nearly ready to push. > > I guess at this point I think it might be best to just finish pushing the rest of the code for baseline and see what the feedback is and to make it available for you to look at. > > I am especially interested in getting feedback from community on skipping the virCpuDef step in the XML to JSON translations. > > Then we could revisit and address any delta between baseline and cpu-comparison. > > If straight XML to JSON is sufficient we might want to leverage more of what I have. > If the virCpuDef step is needed then leverage more of yours. > > Either way try and make the QEMU spin up as clean as possible. Agreed. > > That seem good to you? Perfectly fine with me :) At this point, it seems like my role in this is better suited as a reviewer -- which is fine. I'll be keeping a close eye on the forthcoming patches and provide my 2cents. > Chris > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- Respectfully, - Collin Walling -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
