[libvirt] [PATCH v3 2/3] qemu : Add loadparm to qemu command line string

[Farhan Ali]

On 05/26/2017 04:03 PM, John Ferlan wrote:
>
>
> ...
>
>>> Was there ever thought to adding loadparm to the machine XML? What's the
>>> reasoning to not have it there.  If it's only valid for bootindex=1,
>>> then it's far easier to check if the machine XML has it defined rather
>>> than perusing the disk/network lists (which could be lengthy) only to
>>> fine none.  If the concern is some other arch allowing a different
>>> bootindex to have loadparm, then the simple decision there is to have a
>>> "loadparm_bootindex=#" value that would match the disk bootindex=# value.
>>>
>>
>> I am not sure what you mean here? By machine xml do you mean <os> xml?
>>
>
> Sorry I was too lazy to go make the cross reference near the end of the
> day/review. Guess I was thinking more <os> related though...
>
> I see in <os> there's a <boot> subelement which has a relationship with
> the <boot> subelement for <devices>...[<interface>|<disk>]...
>

Yes, the <os> has <boot> subelement, but it can be tricky to specify the 
order of the boot device.

> I think I was just trying to make sure that adding <loadparm> to
> <devices> would make sense "in the long run" and what other
> implementations were considered and not taken because of some drawback.
>

The per device boot subelement was added to simplify the boot device 
order. That's why I thought it made more sense to add it to the per 
device boot element. Also from a user's perspective it's easier to 
specify the loadparm when specifying the boot order.

> Given the description I've read and the implementation that searches
> either disk or network lists looking for bootIndex = 1, I wonder if the
> <os> <boot dev='xxx' > should be modified instead.  Was that considered
> - what were the drawbacks?   Can bootparm conceptually be added/used for
> a non boot disk?

>
> I'm not requesting one way or another - I'd just like to be sure the
> question is answered before perhaps someone else asks it now or much
> later when this isn't so fresh in your mind.
>
> John
>
>