Re: [Xen-devel] [PATCH v2 4/5] libxl: change xs path for pv qemu

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/06/15 11:25, Wei Liu wrote:
> On Thu, Jun 04, 2015 at 12:28:18PM +0100, Stefano Stabellini wrote:
>> If QEMU is ran just to provide PV backends, change the xenstore path to
>> /local/domain/0/device-model/$DOMID/pv.
>>
>> Add a parameter to libxl__device_model_xs_path to distinguish the device
>> model from the pv backends provider.
>>
>> Store the device model binary path under
>> /local/domain/$DOMID/device-model on xenstore, so that we can fetch it
>> later and retrieve the list of supported options from
>> /local/domain/0/libxl/$device_model_binary, introduce in the previous
>> path.
>>
> TBH this protocol works, but it is not very extensible.
>
> I envisaged we need to assign $emulator_id to different device models
> when I fixed stubdom, but I never got to that since there weren't need
> for multiple emulators.
>
> That is, as an example:
>
> /local/domain/$backend_domid/device-model/$domid/$emulator_id/xxx
>
> That way we can:
>
> 1. Have something like multidev in libxl to wait for several device
>    models to be ready without writing tedious code for every single one.
> 2. Fit into libxl migration stream, which naturally uses $emulator_id to
>    distinguish different emulators. 
>
> The downside of this is we need to add an extra option to QEMU to accept
> the emulator id assigned by toolstack.
>
> Just my two cents.
>
> Wei.

From the XenServer point of view, we already use multiple device models
in certain cirumstances, and libxl support is one of the many tasks on
the xenopsd/libxl integration todo list.

If a change is going to be made, lets go the full way to getting
multiple emulators working properly.

FWIW, Wei's design looks to be sufficient.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel