Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER

[Dor Laor <dlaor@redhat.com>]

Mark McLoughlin wrote:
> On Sun, 2009-05-31 at 17:47 +0300, Dor Laor wrote:
>   
>> Mark McLoughlin wrote:
>>     
>>> On Fri, 2009-05-29 at 10:43 +0100, Mark McLoughlin wrote:
>>>
>>>   
>>>       
>>>> The more I think about it, no matter how much linear ABI versioning
>>>> sucks, it's possibly the only way to solve this in a reasonably usable
>>>> manners. Distros would just have to suck it up and agree that if they
>>>> cherry-pick an ABI changing patch, they must update the entire ABI to
>>>> the newer upstream ABI version.
>>>>     
>>>>         
>>> Okay, how about this:
>>>
>>>   - Add a saveabi monitor command
>>>
>>>   - Whenever libvirt starts a guest or hotplugs a device, it executes
>>>     saveabi and retains the output
>>>
>>>   - The abi can be restored with qemu -loadabi or the loadabi monitor 
>>>     command
>>>
>>>   - The abi file doesn't describe the device model, it merely gives 
>>>     hints for building the device model which is described on the
>>>     command line
>>>
>>>   - If the abi file contains details of a device which is not listed on 
>>>     the command line, it's just ignored and not included in the next 
>>>     saveabi
>>>
>>>   - If the abi file is missing details of a device which is listed on 
>>>     the command line, the device is constructed using the defaults and 
>>>     included in the next saveabi
>>>
>>>   - This means the abi file is opaque to the management tools - unlike 
>>>     the machine config file, libvirt would not need to modify it when
>>>     devices are added or removed by the user
>>>   
>>>       
>> IMO it shouldn't be opaque
>>     
>
> The important requirement is that management tools should never need to
> modify saveabi output.
>
>   
>> and we might use the same config file for the abi too.
>>     
>
> What we don't want is:
>
>   $> qemu -config guest.config
>
> where guest.config contains both details of which devices are needed
> *and* what their ABI should be.
>
> We want:
>
>   $> qemu -loadabi guest.abi -config guest.confg
>
> or:
>
>   $> qemu -loadabi guest.abi -drive ... -net ... -serial ...
>
> The idea being that we should not mix up ABI requirements with device
> configuration.
>
> The management tools do not need to know the details of the ABI
> provided, they just want to request qemu to use the same ABI as was used
> previously.
>
> Put more simply - with saveabi/loadabi, the management tools would not
> need to know that older versions of qemu's virtio-console used
> PCI_CLASS_DISPLAY_OTHER.
>
>   
Since -loadabi  and -config are far away in the future (hope few months) and
the 2 pci class issues are a real problem now, can qemu accept current 
patches?
My patch gave a config option for setting the value of the block class.

Current guest abi is not kept anyway since there is not way for static 
pci slots and
there is no migration working with older qemu's.

IMHO since there is not good way to allow have a real stable guest abi, 
these patches
should be committed (with a cmdline option).

Regards, dor
>> The notion of abi config is indeed required and most of the times, mgmt 
>> tools won't need to deal with it.
>>
>> But, let's say for instance that the user with certain abi configs, now 
>> change some existence of pci device, bios memory mapping, etc. In the
>> case mgmt should automatically adjust both config files to minimize
>> the effect on the guest and not to create a conflict.
>>     
>
> I think that would defeat a lot of the value of this. It adds an awful
> lot of complexity to the management tools.
>
> The device config file should always just take precedence and the abi
> file should just be used as hints to allow the same ABI to be used. If
> e.g. a device is removed, the hints for that device can be ignored and
> dropped in the next saveabi.
>
> Cheers,
> Mark.
>
>
>
>