Re: [Qemu-devel] [PATCH v3 00/26] q35 qemu support

[Anthony Liguori]

"Michael S. Tsirkin" <address@hidden> writes:

> On Mon, Oct 22, 2012 at 12:37:39PM +0200, Gerd Hoffmann wrote:
>> On 10/22/12 12:08, Michael S. Tsirkin wrote:
>> > On Mon, Oct 22, 2012 at 07:58:32AM +0200, Gerd Hoffmann wrote:
>> >>   Hi,
>> >>
>> >>> Would it make sense to temporarily rename the machine type e.g.
>> >>> pc-q35-experimental to stress it's not fully supported?
>> >>
>> >> I don't think this is needed as piix will continue to be the default.
>> > 
>> > Well q35 is not yet 100% ready.
>> 
>> I know.
>> 
>> > The point was to hide it from libvirt.
>> > libvirt should support pc-q35 not pc-q35-experimental, then
>> > it will not cause trouble.
>> 
>> You'll not going to hide it that way.  Libvirt will just 'qemu -M ?'
>> where q35 will show up even if you rename it to be postfixed -experimental.
>> 
>> But as long as 'pc' continues to be the default the causal user will
>> never ever notice q35 is there, at least not with virt-manager (dunno
>> about boxes) as there is simply no gui way to pick the machine type.
>> You'll have to explicitly "virsh edit $guest" to switch it to q35.
>> 
>> So I'm not sure what you are worryed about.
>
> I worry about need to maintain  bug for bug compatibility on the
> unlikely chance that the work to complete it gets delayed and we release
> it in an unready state.
>
>> But in any case this needs
>> discussion with the libvirt folks to make sure it will actually work as
>> intended.  /me tends to think a experimental bit in machine_info (which
>> is then printed by 'qemu -M ?' and the QOM-version of that) is more
>> useful than playing tricks with the name.
>> 
>> cheers,
>>   Gerd
>
> I agree it's best to ask libvirt folks what's the right way to hide
> a machine type from it. Add a flag so it's not listed in -M ?  ?
> Jason, do you know?

We don't need to hide it from libvirt.

What I'd suggest is that for q35, we don't introduce QEMU versioned
machine types but instead provide a machine-level version.

IOW:

q35-next <- bleeding edge version of code.  No compatibility guarantee
q35-0.1  <- if we decide we want to have a "tech preview" of q35 that's
            incomplete but will be supported for compat
q35-1.0  <- the first "complete" release of q35 with full compat support

I think we should also alias 'q35' to 'q35-next'.

Regards,

Anthony Liguori

>
> -- 
> MST