[libvirt] [PATCH V2 5/6] xenconfig: support bios=ovmf xl.cfg

[Jim Fehlig]

On 06/10/2016 01:47 AM, Michal Privoznik wrote:
> On 09.06.2016 19:06, Jim Fehlig wrote:
>>
>> You bring up a point here that I'm not quite sure how to handle.
>> LIBXL_FIRMWARE_DIR can certainly be different between Xen installations,
>> depending on configuration options selected when building Xen. But currently all
>> the various data files under tests/ are "hard-coded". E.g.
>> tests/xlconfigdata/test-fullvirt-ovmf.xml introduced in this patch contains
>>
>>   <loader readonly='yes' type='pflash'>/usr/lib/xen/boot/ovmf.bin</loader>
>>
>> but it should really contain
>>
>>   <loader readonly='yes' type='pflash'>LIBXL_FIRMWARE_DIR/ovmf.bin</loader>
> Yes. this is what I had in mind, thank you for writing it down.
>
>> How should test data files which depend on values discovered at build time be
>> handled?
> Good question. I don't think we have such case in our test suite yet. So
> it's up to us to walk the path for others :)
>
>> Should they be created at build time from e.g.
>> tests/xlconfigdata/test-fullvirt-ovmf.xml.in? 
> Not a bad idea. This will definitely work thus it can be our fall back
> if other approaches fail.
>
>> Is there a better trick for
>> substituting values discovered at build time in test data files?
> Well, I'm thinking of fixing the path in the testsuite. In xlconfigtest
> depending on mode either testCompareParseXML or testCompareFormatXML is
> called. For the simplicity of explanation assume just the former one,
> the latter would be similar.
>
> In the testCompareParseXML, the domain XML is parsed and xl config is
> then produced from it. What if we introduced a boolean that if set would
> mangle^Wfix the boot loader path just before we try to produce xl config
> from it? Then, testCompareHelper would merely just pass the boolean from
> testInfo struct. Thus we would need new macro, say DO_TEST_FIX_LOADER (I
> know, terrible name) which would set the boolean in the struct. All
> other macros would then leave the boolean unset (=false).
>
> I know this is not a terrific idea, because if one would open the XML,
> the corresponding config would not be its exact copy.
>
> Or even better, in the XML there would be
> <loader>LIBXL_FIRMWARE_DIR/ovmf.bin</loader> and if the boolean is set,
> it would just replace LIBXL_FIRMWARE_DIR with the actual value of the
> macro (virStringReplace).

Ah, good idea. I'll give this a shot in V3.

>
> This way it would be obvious even in the XML that some post processing
> is happening in the test.

Right. And I should be able to precede it with a comment in the XML to make it
even more clear. Thanks for the ideas!

Regards,
Jim