[...]

>> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 


-- 
Respectfully,
- Collin Walling

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to