[Qemu-devel] Should we have a 2.0-rc3 ?

[Qemu-devel] Should we have a 2.0-rc3 ?

[Peter Maydell]

So far I know of at least three fixes which should probably
go into 2.0:
 * my fix for the configure stack-protector checks on MacOSX
 * MST's pull request updating the ACPI test blobs
 * MST says we need to update the hex files for ACPI too
   (otherwise you get a different ACPI blob depending on whether
    your build system had iasl or not, if I understand correctly)

Are there any others?

So we have two choices:

(A) get those fixes into git today, and tag an rc3; that
would then need some testing time and presumably we'd hope
to tag it as the 2.0 release on Monday or Tuesday next week

(B) say that the above are not worth fixing in 2.0 proper
and plan to do a 2.0.1 in a few weeks with the above plus
any other breakage that people find.

Opinions?

thanks
-- PMM

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

On 10.04.14 13:17, Peter Maydell wrote:
> So far I know of at least three fixes which should probably
> go into 2.0:
>   * my fix for the configure stack-protector checks on MacOSX
>   * MST's pull request updating the ACPI test blobs
>   * MST says we need to update the hex files for ACPI too
>     (otherwise you get a different ACPI blob depending on whether
>      your build system had iasl or not, if I understand correctly)
>
> Are there any others?
>
> So we have two choices:
>
> (A) get those fixes into git today, and tag an rc3; that
> would then need some testing time and presumably we'd hope
> to tag it as the 2.0 release on Monday or Tuesday next week
>
> (B) say that the above are not worth fixing in 2.0 proper
> and plan to do a 2.0.1 in a few weeks with the above plus
> any other breakage that people find.
>
> Opinions?

I think the best way forward is to do both. Do an rc3 with _only_ those 
patches. Wait until Tuesday and do the final GA tag there.

Then schedule a 2.0.1 in a few weeks. There will be bug fixes.

And don't apply last-minute fixes from mst in the future :).


Alex

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Michael S. Tsirkin]

On Thu, Apr 10, 2014 at 01:24:51PM +0200, Alexander Graf wrote:
> 
> On 10.04.14 13:17, Peter Maydell wrote:
> >So far I know of at least three fixes which should probably
> >go into 2.0:
> >  * my fix for the configure stack-protector checks on MacOSX
> >  * MST's pull request updating the ACPI test blobs
> >  * MST says we need to update the hex files for ACPI too
> >    (otherwise you get a different ACPI blob depending on whether
> >     your build system had iasl or not, if I understand correctly)
> >
> >Are there any others?
> >
> >So we have two choices:
> >
> >(A) get those fixes into git today, and tag an rc3; that
> >would then need some testing time and presumably we'd hope
> >to tag it as the 2.0 release on Monday or Tuesday next week
> >
> >(B) say that the above are not worth fixing in 2.0 proper
> >and plan to do a 2.0.1 in a few weeks with the above plus
> >any other breakage that people find.
> >
> >Opinions?
> 
> I think the best way forward is to do both. Do an rc3 with _only_
> those patches. Wait until Tuesday and do the final GA tag there.
> 
> Then schedule a 2.0.1 in a few weeks. There will be bug fixes.
> 
> And don't apply last-minute fixes from mst in the future :).
> 
> 
> Alex

Sorry about that.
Though my last minute patches didn't actually break any stuff, they just
weren't complete :)

-- 
MST

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Kevin Wolf]

Am 10.04.2014 um 13:17 hat Peter Maydell geschrieben:
> So far I know of at least three fixes which should probably
> go into 2.0:
>  * my fix for the configure stack-protector checks on MacOSX
>  * MST's pull request updating the ACPI test blobs
>  * MST says we need to update the hex files for ACPI too
>    (otherwise you get a different ACPI blob depending on whether
>     your build system had iasl or not, if I understand correctly)
> 
> Are there any others?

I have three fixes in my queue, though none of them is bad enough
to delay the release. However, if you're going to do an -rc3 anyway,
let me know and I'll send a pull request for them.

The bugs fixed are:
* iscsi has an error path where the return value is undefined.
* The bochs block driver has a buggy input validation check that can
  cause an out-of-bounds array read with corrupt images.

> So we have two choices:
> 
> (A) get those fixes into git today, and tag an rc3; that
> would then need some testing time and presumably we'd hope
> to tag it as the 2.0 release on Monday or Tuesday next week
> 
> (B) say that the above are not worth fixing in 2.0 proper
> and plan to do a 2.0.1 in a few weeks with the above plus
> any other breakage that people find.
> 
> Opinions?

Either way is fine with me.

Kevin

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On 04/10/2014 05:17 AM, Peter Maydell wrote:
> So far I know of at least three fixes which should probably
> go into 2.0:
>  * my fix for the configure stack-protector checks on MacOSX
>  * MST's pull request updating the ACPI test blobs
>  * MST says we need to update the hex files for ACPI too
>    (otherwise you get a different ACPI blob depending on whether
>     your build system had iasl or not, if I understand correctly)
> 
> Are there any others?

Yes.  The libvirt team is a bit annoyed that the pci bus naming was
changed for PPC but not all architectures, but without a proper QMP
command to probe which naming scheme is in effect.  We thought that the
naming scheme was going to be universally supplied for all arches, not
just PPC.

https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html

Is this something that can be quickly fixed (perhaps by reverting the
PPC patch until a more complete solution is ready), and if so, is it
worth doing for 2.0 proper, rather than waiting for 2.0.1?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]


On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:

> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>> So far I know of at least three fixes which should probably
>> go into 2.0:
>> * my fix for the configure stack-protector checks on MacOSX
>> * MST's pull request updating the ACPI test blobs
>> * MST says we need to update the hex files for ACPI too
>>   (otherwise you get a different ACPI blob depending on whether
>>    your build system had iasl or not, if I understand correctly)
>> 
>> Are there any others?
> 
> Yes.  The libvirt team is a bit annoyed that the pci bus naming was
> changed for PPC but not all architectures, but without a proper QMP
> command to probe which naming scheme is in effect.  We thought that the
> naming scheme was going to be universally supplied for all arches, not
> just PPC.
> 
> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
> 
> Is this something that can be quickly fixed (perhaps by reverting the
> PPC patch until a more complete solution is ready), and if so, is it
> worth doing for 2.0 proper, rather than waiting for 2.0.1?

Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.


Alex


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On 04/10/2014 06:46 AM, Alexander Graf wrote:
> 
> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:
> 
>> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>>> So far I know of at least three fixes which should probably
>>> go into 2.0:
>>> * my fix for the configure stack-protector checks on MacOSX
>>> * MST's pull request updating the ACPI test blobs
>>> * MST says we need to update the hex files for ACPI too
>>>   (otherwise you get a different ACPI blob depending on whether
>>>    your build system had iasl or not, if I understand correctly)
>>>
>>> Are there any others?
>>
>> Yes.  The libvirt team is a bit annoyed that the pci bus naming was
>> changed for PPC but not all architectures, but without a proper QMP
>> command to probe which naming scheme is in effect.  We thought that the
>> naming scheme was going to be universally supplied for all arches, not
>> just PPC.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
>>
>> Is this something that can be quickly fixed (perhaps by reverting the
>> PPC patch until a more complete solution is ready), and if so, is it
>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
> 
> Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.

Given the shortness of the timing, reverting for 2.0, and fixing it
properly after the release, may be the best path forward (that is, 2.0
will be no different than 1.7 for what libvirt has to special case,
whereas all future versions can be properly introspectable, so that
libvirt has less special casing than what it would need if 2.0 is a
one-off for PPC).

> 
> 
> Alex
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

On 10.04.14 14:51, Eric Blake wrote:
> On 04/10/2014 06:46 AM, Alexander Graf wrote:
>> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:
>>
>>> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>>>> So far I know of at least three fixes which should probably
>>>> go into 2.0:
>>>> * my fix for the configure stack-protector checks on MacOSX
>>>> * MST's pull request updating the ACPI test blobs
>>>> * MST says we need to update the hex files for ACPI too
>>>>    (otherwise you get a different ACPI blob depending on whether
>>>>     your build system had iasl or not, if I understand correctly)
>>>>
>>>> Are there any others?
>>> Yes.  The libvirt team is a bit annoyed that the pci bus naming was
>>> changed for PPC but not all architectures, but without a proper QMP
>>> command to probe which naming scheme is in effect.  We thought that the
>>> naming scheme was going to be universally supplied for all arches, not
>>> just PPC.
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
>>>
>>> Is this something that can be quickly fixed (perhaps by reverting the
>>> PPC patch until a more complete solution is ready), and if so, is it
>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>> Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.
> Given the shortness of the timing, reverting for 2.0, and fixing it
> properly after the release, may be the best path forward (that is, 2.0
> will be no different than 1.7 for what libvirt has to special case,
> whereas all future versions can be properly introspectable, so that
> libvirt has less special casing than what it would need if 2.0 is a
> one-off for PPC).

Works well for me.


Alex

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Ján Tomko]

[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]

On 04/10/2014 02:46 PM, Alexander Graf wrote:
> 
> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:
> 
>> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>>> So far I know of at least three fixes which should probably
>>> go into 2.0:
>>> * my fix for the configure stack-protector checks on MacOSX
>>> * MST's pull request updating the ACPI test blobs
>>> * MST says we need to update the hex files for ACPI too
>>>   (otherwise you get a different ACPI blob depending on whether
>>>    your build system had iasl or not, if I understand correctly)
>>>
>>> Are there any others?
>>
>> Yes.  The libvirt team is a bit annoyed that the pci bus naming was
>> changed for PPC but not all architectures, but without a proper QMP
>> command to probe which naming scheme is in effect.  We thought that the
>> naming scheme was going to be universally supplied for all arches, not
>> just PPC.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
>>
>> Is this something that can be quickly fixed (perhaps by reverting the
>> PPC patch until a more complete solution is ready), and if so, is it
>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
> 
> Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.
> 

If I read the git history correctly, there were two patches changing pci bus
names for ppc in this release, not just one:

commit 1b8601b0ea0b91467561e0bbddd52a833e4b2b1a
Author:     Alexey Kardashevskiy <aik@ozlabs.ru>
AuthorDate: 2014-03-06 14:11:00 +1100
Commit:     Andreas Färber <afaerber@suse.de>
CommitDate: 2014-03-12 20:13:02 +0100

    spapr-pci: Change the default PCI bus naming

    Previously libvirt required the first/default PCI bus to have name "pci".
    Since QEMU can support multiple buses now, libvirt wants "pci.0" now.

    This removes custom bus name and lets QEMU make up default names.

    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Andreas Färber <afaerber@suse.de>

commit 8a0e11045d5f50d300e0ab1ba05f4c8217fb5dcb
Author:     Alexander Graf <agraf@suse.de>
AuthorDate: 2013-12-04 12:42:32 +0100
Commit:     Alexander Graf <agraf@suse.de>
CommitDate: 2013-12-20 01:58:01 +0100

    PPC: Use default pci bus name for grackle and heathrow

    There's no good reason to call our bus "pci" rather than let the default
    bus name take over ("pci.0").

    The big downside to calling it different from anyone else is that tools
    that pass -device get confused. They are looking for a bus "pci.0" rather
    than "pci".

    To make life easier for everyone, let's just drop the name override.

    Signed-off-by: Alexander Graf <agraf@suse.de>

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

On 10.04.14 15:41, Ján Tomko wrote:
> On 04/10/2014 02:46 PM, Alexander Graf wrote:
>> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:
>>
>>> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>>>> So far I know of at least three fixes which should probably
>>>> go into 2.0:
>>>> * my fix for the configure stack-protector checks on MacOSX
>>>> * MST's pull request updating the ACPI test blobs
>>>> * MST says we need to update the hex files for ACPI too
>>>>    (otherwise you get a different ACPI blob depending on whether
>>>>     your build system had iasl or not, if I understand correctly)
>>>>
>>>> Are there any others?
>>> Yes.  The libvirt team is a bit annoyed that the pci bus naming was
>>> changed for PPC but not all architectures, but without a proper QMP
>>> command to probe which naming scheme is in effect.  We thought that the
>>> naming scheme was going to be universally supplied for all arches, not
>>> just PPC.
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
>>>
>>> Is this something that can be quickly fixed (perhaps by reverting the
>>> PPC patch until a more complete solution is ready), and if so, is it
>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>> Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.
>>
> If I read the git history correctly, there were two patches changing pci bus
> names for ppc in this release, not just one:

The main difference is that the g3beige and mac99 targets are not 
supported by libvirt FWIW :).

But I agree that this is messy. And a pretty intrusive change pretty 
late in the game. Eric, how hard would a special case for this be in 
libvirt code? Are we talking about a 2 line patch?


Alex

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

On 04/10/2014 07:45 AM, Alexander Graf wrote:

>>>>
>>>> Is this something that can be quickly fixed (perhaps by reverting the
>>>> PPC patch until a more complete solution is ready), and if so, is it
>>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>>> Which way works better for you? I'd be perfectly fine with reverting
>>> the patch. Libvirt is the only reason that path is there in the first
>>> place.
>>>
>> If I read the git history correctly, there were two patches changing
>> pci bus
>> names for ppc in this release, not just one:
> 
> The main difference is that the g3beige and mac99 targets are not
> supported by libvirt FWIW :).
> 
> But I agree that this is messy. And a pretty intrusive change pretty
> late in the game. Eric, how hard would a special case for this be in
> libvirt code? Are we talking about a 2 line patch?

Here's the current libvirt patch proposal:

https://www.redhat.com/archives/libvir-list/2014-April/msg00444.html

a bit more than a 2-line patch:

 src/qemu/qemu_capabilities.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

We already have to special case on machine type for all qemu older than
the point where we introduce sane names; but it would be nicer if that
were the ONLY special casing (rather than having the _additional_
special casing that for 2.0, ppc, but not other machines, behave
differently).  The IDEAL situation is to have a QMP command that can
query which naming convention is in use for a given machine; even if
such command is not introduced until 2.1, the logic will look something
like:

if (probe exists)
  use results of probe to set QEMU_CAPS_PCI_MULTIBUS
else if (machine with sane handling)
  assume QEMU_CAPS_PCI_MULTIBUS
else
  assume no QEMU_CAPS_PCI_MULTIBUS

and is completely independent of version checks, which means it is
portable even to downstream backports where the version number is not as
large as upstream, without any modification when backporting this hunk.

Without a QMP command to probe it, but with all machines switched to
sane naming in the same version of qemu, the logic looks more like:

if (x86 or 686)
  assume QEMU_CAPS_PCI_MULTIBUS
else if (version check) // evil for downstream backports
  set QEMU_CAPS_PCI_MULTIBUS if new enough

which looks shorter, but plays havoc with downstream ports, which now
have to patch the version check to play nicely with downstream.

Furthermore, if qemu 2.0 is released with PPC being a special case, the
logic expands:

if (x86 or 686)
  assume QEMU_CAPS_PCI_MULTIBUS
else if (PPC)
  if (version check for 2.0) // evil for downstream
    set QEMU_CAPS_PCI_MULTIBUS
else if (version check for 2.1) // evil for downstream
  set QEMU_CAPS_PCI_MULTIBUS

and now there are two version checks instead of one that downstream has
to worry about.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

On 10.04.14 17:02, Eric Blake wrote:
> On 04/10/2014 07:45 AM, Alexander Graf wrote:
>
>>>>> Is this something that can be quickly fixed (perhaps by reverting the
>>>>> PPC patch until a more complete solution is ready), and if so, is it
>>>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>>>> Which way works better for you? I'd be perfectly fine with reverting
>>>> the patch. Libvirt is the only reason that path is there in the first
>>>> place.
>>>>
>>> If I read the git history correctly, there were two patches changing
>>> pci bus
>>> names for ppc in this release, not just one:
>> The main difference is that the g3beige and mac99 targets are not
>> supported by libvirt FWIW :).
>>
>> But I agree that this is messy. And a pretty intrusive change pretty
>> late in the game. Eric, how hard would a special case for this be in
>> libvirt code? Are we talking about a 2 line patch?
> Here's the current libvirt patch proposal:
>
> https://www.redhat.com/archives/libvir-list/2014-April/msg00444.html
>
> a bit more than a 2-line patch:
>
>   src/qemu/qemu_capabilities.c | 26 ++++++++++++++++----------
>   1 file changed, 16 insertions(+), 10 deletions(-)
>
> We already have to special case on machine type for all qemu older than
> the point where we introduce sane names; but it would be nicer if that
> were the ONLY special casing (rather than having the _additional_
> special casing that for 2.0, ppc, but not other machines, behave
> differently).  The IDEAL situation is to have a QMP command that can
> query which naming convention is in use for a given machine; even if
> such command is not introduced until 2.1, the logic will look something
> like:
>
> if (probe exists)
>    use results of probe to set QEMU_CAPS_PCI_MULTIBUS
> else if (machine with sane handling)
>    assume QEMU_CAPS_PCI_MULTIBUS
> else
>    assume no QEMU_CAPS_PCI_MULTIBUS
>
> and is completely independent of version checks, which means it is
> portable even to downstream backports where the version number is not as
> large as upstream, without any modification when backporting this hunk.
>
> Without a QMP command to probe it, but with all machines switched to
> sane naming in the same version of qemu, the logic looks more like:
>
> if (x86 or 686)
>    assume QEMU_CAPS_PCI_MULTIBUS
> else if (version check) // evil for downstream backports
>    set QEMU_CAPS_PCI_MULTIBUS if new enough
>
> which looks shorter, but plays havoc with downstream ports, which now
> have to patch the version check to play nicely with downstream.
>
> Furthermore, if qemu 2.0 is released with PPC being a special case, the
> logic expands:
>
> if (x86 or 686)
>    assume QEMU_CAPS_PCI_MULTIBUS
> else if (PPC)
>    if (version check for 2.0) // evil for downstream
>      set QEMU_CAPS_PCI_MULTIBUS
> else if (version check for 2.1) // evil for downstream
>    set QEMU_CAPS_PCI_MULTIBUS
>
> and now there are two version checks instead of one that downstream has
> to worry about.

Hrm, so what if we just ditch pre-2.0 support for PPC in libvirt? Then 
it'd become

if (machine_type == pc || machine_type == pseries || machine_type == 
ppce500)
   assume QEMU_CAPS_PCI_MULTIBUS
else ...

and everyone is happy, no? :)

(note that I prefer to base machine specific bits on machine types, but 
if you like to commonalize all PPC machines I'm fine with that too)


Alex

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On 04/10/2014 09:27 AM, Alexander Graf wrote:
> 
> Hrm, so what if we just ditch pre-2.0 support for PPC in libvirt? Then
> it'd become
> 
> if (machine_type == pc || machine_type == pseries || machine_type ==
> ppce500)
>   assume QEMU_CAPS_PCI_MULTIBUS
> else ...
> 
> and everyone is happy, no? :)

No, because there (may be) people clamoring for (at least some specific
machine types of) PPC support to be backported to pre-2.0 versions.

The point is that the pre-2.0 behavior is a mess of special casing,
which can't be helped, but what CAN be helped is no NEW special casing
without introspection.  We failed at adding the introspection in time,
and the only other alternative to adding introspection is to change ALL
machines at the same time; since neither of those can happen in time for
2.0, it leaves reverting the PPC change and letting 2.0 behave like
pre-2.0 as the path with the fewest special casing requirements.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

On 10.04.14 17:38, Eric Blake wrote:
> On 04/10/2014 09:27 AM, Alexander Graf wrote:
>> Hrm, so what if we just ditch pre-2.0 support for PPC in libvirt? Then
>> it'd become
>>
>> if (machine_type == pc || machine_type == pseries || machine_type ==
>> ppce500)
>>    assume QEMU_CAPS_PCI_MULTIBUS
>> else ...
>>
>> and everyone is happy, no? :)
> No, because there (may be) people clamoring for (at least some specific
> machine types of) PPC support to be backported to pre-2.0 versions.

Then I'm happy if they die a painful death :).

> The point is that the pre-2.0 behavior is a mess of special casing,
> which can't be helped, but what CAN be helped is no NEW special casing
> without introspection.  We failed at adding the introspection in time,
> and the only other alternative to adding introspection is to change ALL
> machines at the same time; since neither of those can happen in time for
> 2.0, it leaves reverting the PPC change and letting 2.0 behave like
> pre-2.0 as the path with the fewest special casing requirements.

I really don't see how you would even remotely want to use pre-2.0 QEMU 
in production environments for PPC. Heck, we even get patch sets today 
that try to fix migration with libvirt that aren't even upstream yet :).


Alex

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Markus Armbruster]

Eric Blake <eblake@redhat.com> writes:

> On 04/10/2014 07:45 AM, Alexander Graf wrote:
>
>>>>>
>>>>> Is this something that can be quickly fixed (perhaps by reverting the
>>>>> PPC patch until a more complete solution is ready), and if so, is it
>>>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>>>> Which way works better for you? I'd be perfectly fine with reverting
>>>> the patch. Libvirt is the only reason that path is there in the first
>>>> place.
>>>>
>>> If I read the git history correctly, there were two patches changing
>>> pci bus
>>> names for ppc in this release, not just one:
>> 
>> The main difference is that the g3beige and mac99 targets are not
>> supported by libvirt FWIW :).
>> 
>> But I agree that this is messy. And a pretty intrusive change pretty
>> late in the game. Eric, how hard would a special case for this be in
>> libvirt code? Are we talking about a 2 line patch?
>
> Here's the current libvirt patch proposal:
>
> https://www.redhat.com/archives/libvir-list/2014-April/msg00444.html
>
> a bit more than a 2-line patch:
>
>  src/qemu/qemu_capabilities.c | 26 ++++++++++++++++----------
>  1 file changed, 16 insertions(+), 10 deletions(-)
>
> We already have to special case on machine type for all qemu older than
> the point where we introduce sane names; but it would be nicer if that
> were the ONLY special casing (rather than having the _additional_
> special casing that for 2.0, ppc, but not other machines, behave
> differently).  The IDEAL situation is to have a QMP command that can
> query which naming convention is in use for a given machine; even if
> such command is not introduced until 2.1, the logic will look something
> like:
>
> if (probe exists)
>   use results of probe to set QEMU_CAPS_PCI_MULTIBUS
> else if (machine with sane handling)
>   assume QEMU_CAPS_PCI_MULTIBUS
> else
>   assume no QEMU_CAPS_PCI_MULTIBUS
>
> and is completely independent of version checks, which means it is
> portable even to downstream backports where the version number is not as
> large as upstream, without any modification when backporting this hunk.
>
> Without a QMP command to probe it, but with all machines switched to
> sane naming in the same version of qemu, the logic looks more like:
>
> if (x86 or 686)
>   assume QEMU_CAPS_PCI_MULTIBUS
> else if (version check) // evil for downstream backports
>   set QEMU_CAPS_PCI_MULTIBUS if new enough
>
> which looks shorter, but plays havoc with downstream ports, which now
> have to patch the version check to play nicely with downstream.

I understand why libvirt needs to know how PCI buses a named.  I'm not
sure a "multibus?" flag can cover more than the present problem, though.

Doesn't libvirt need to know how *any* kind of bus is named?

Would it suffice if libvirt could introspect the names of all available
buses?  And perhaps control the names of all buses it creates itself?

[...]

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Daniel P. Berrange]

On Fri, Apr 11, 2014 at 10:01:37AM +0200, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
> 
> > On 04/10/2014 07:45 AM, Alexander Graf wrote:
> >
> >>>>>
> >>>>> Is this something that can be quickly fixed (perhaps by reverting the
> >>>>> PPC patch until a more complete solution is ready), and if so, is it
> >>>>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
> >>>> Which way works better for you? I'd be perfectly fine with reverting
> >>>> the patch. Libvirt is the only reason that path is there in the first
> >>>> place.
> >>>>
> >>> If I read the git history correctly, there were two patches changing
> >>> pci bus
> >>> names for ppc in this release, not just one:
> >> 
> >> The main difference is that the g3beige and mac99 targets are not
> >> supported by libvirt FWIW :).
> >> 
> >> But I agree that this is messy. And a pretty intrusive change pretty
> >> late in the game. Eric, how hard would a special case for this be in
> >> libvirt code? Are we talking about a 2 line patch?
> >
> > Here's the current libvirt patch proposal:
> >
> > https://www.redhat.com/archives/libvir-list/2014-April/msg00444.html
> >
> > a bit more than a 2-line patch:
> >
> >  src/qemu/qemu_capabilities.c | 26 ++++++++++++++++----------
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > We already have to special case on machine type for all qemu older than
> > the point where we introduce sane names; but it would be nicer if that
> > were the ONLY special casing (rather than having the _additional_
> > special casing that for 2.0, ppc, but not other machines, behave
> > differently).  The IDEAL situation is to have a QMP command that can
> > query which naming convention is in use for a given machine; even if
> > such command is not introduced until 2.1, the logic will look something
> > like:
> >
> > if (probe exists)
> >   use results of probe to set QEMU_CAPS_PCI_MULTIBUS
> > else if (machine with sane handling)
> >   assume QEMU_CAPS_PCI_MULTIBUS
> > else
> >   assume no QEMU_CAPS_PCI_MULTIBUS
> >
> > and is completely independent of version checks, which means it is
> > portable even to downstream backports where the version number is not as
> > large as upstream, without any modification when backporting this hunk.
> >
> > Without a QMP command to probe it, but with all machines switched to
> > sane naming in the same version of qemu, the logic looks more like:
> >
> > if (x86 or 686)
> >   assume QEMU_CAPS_PCI_MULTIBUS
> > else if (version check) // evil for downstream backports
> >   set QEMU_CAPS_PCI_MULTIBUS if new enough
> >
> > which looks shorter, but plays havoc with downstream ports, which now
> > have to patch the version check to play nicely with downstream.
> 
> I understand why libvirt needs to know how PCI buses a named.  I'm not
> sure a "multibus?" flag can cover more than the present problem, though.
> 
> Doesn't libvirt need to know how *any* kind of bus is named?

Yes, you are right - in theory libvirt needs to know the name of any
default bus which is pre-created due to the machine type. For ones
we create ourselvs, obviously we already have ability to choose the
name.

Now in practice, I believe the default PCI bus is the only one that
actually causes us trouble today. USB buses are all fully created by
libvirt self.  The default SCSI/IDE/etc disk buses are not a problem
since we just refer to them by bus number. While there are other buses
on non-x86 our support for those in libvirt pretty much doesn't exist
so we don't currently hit that.

> Would it suffice if libvirt could introspect the names of all available
> buses?  And perhaps control the names of all buses it creates itself?

'info qtree' provides a way to introspect that, but of course we
probe capabilities using '-M none' so we case use that, and we
don't particularly want to have to invoke QEMU many more times to
probe the machine types.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Michael S. Tsirkin]

On Thu, Apr 10, 2014 at 12:17:55PM +0100, Peter Maydell wrote:
> So far I know of at least three fixes which should probably
> go into 2.0:
>  * my fix for the configure stack-protector checks on MacOSX
>  * MST's pull request updating the ACPI test blobs
>  * MST says we need to update the hex files for ACPI too
>    (otherwise you get a different ACPI blob depending on whether
>     your build system had iasl or not, if I understand correctly)
> 
> Are there any others?

If we do rc3 anyway, maybe
[PATCH 1/2] pci-assign: Fix a bug when map MSI-X table memory failed
which is an error-handling bugfix.

I'd like Alex to weight in about this one though.


> So we have two choices:
> 
> (A) get those fixes into git today, and tag an rc3; that
> would then need some testing time and presumably we'd hope
> to tag it as the 2.0 release on Monday or Tuesday next week
> 
> (B) say that the above are not worth fixing in 2.0 proper
> and plan to do a 2.0.1 in a few weeks with the above plus
> any other breakage that people find.
> 
> Opinions?
> 
> thanks
> -- PMM

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Cole Robinson]

On 04/10/2014 07:17 AM, Peter Maydell wrote:
> So far I know of at least three fixes which should probably
> go into 2.0:
>  * my fix for the configure stack-protector checks on MacOSX
>  * MST's pull request updating the ACPI test blobs
>  * MST says we need to update the hex files for ACPI too
>    (otherwise you get a different ACPI blob depending on whether
>     your build system had iasl or not, if I understand correctly)
> 
> Are there any others?
> 

https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00217.html

Relative mode with sdl2.c is completely busted. Patch 1 is safe and makes the
mouse actually move, but with the cruddy 'invisible wall' behavior. Patch 2
fixes that, but I haven't tested it enough to know if there are side effects.

Gerd, can you take a look at patch #1 and consider sending a 2.0 pull request?

Thanks,
Cole

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Peter Maydell]

On 10 April 2014 12:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> So far I know of at least three fixes which should probably
> go into 2.0:
>  * my fix for the configure stack-protector checks on MacOSX
>  * MST's pull request updating the ACPI test blobs
>  * MST says we need to update the hex files for ACPI too
>    (otherwise you get a different ACPI blob depending on whether
>     your build system had iasl or not, if I understand correctly)
>
> Are there any others?
>
> So we have two choices:
>
> (A) get those fixes into git today, and tag an rc3; that
> would then need some testing time and presumably we'd hope
> to tag it as the 2.0 release on Monday or Tuesday next week
>
> (B) say that the above are not worth fixing in 2.0 proper
> and plan to do a 2.0.1 in a few weeks with the above plus
> any other breakage that people find.

OK, consensus seems to be that we have enough
showstoppers to merit an rc3. I'm going to start
applying the fixes we have; if we can get fixes for
the others by tomorrow (Friday) we can maybe do
the rc3 tag then.

thanks
-- PMM

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Peter Maydell]

On 10 April 2014 12:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> So far I know of at least three fixes which should probably
> go into 2.0

Status update:
Applied:
 * ACPI fixes (both sets)
 * block queue
 * SDL2 relative mode fixes
 * fix for virtio-net CVE
 * fix for qom-list crash
 * my patch to stack-protector check
Patches on list but need review/ack and/or not sure whether to apply:
 * kvm_physical_sync_dirty_bitmap bug
 * my fix to my stack-protector check patch (oops)
 * vmxnet3 patches
Raised as issues but no patches:
 * PCI bus naming
 * win64 virtio-scsi regression

Assistance welcomed in moving patches in the last two
categories into either "ready to apply" or "not for 2.0" :-)

thanks
-- PMM

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Alexander Graf]

> Am 11.04.2014 um 19:37 schrieb Peter Maydell <peter.maydell@linaro.org>:
> 
>> On 10 April 2014 12:17, Peter Maydell <peter.maydell@linaro.org> wrote:
>> So far I know of at least three fixes which should probably
>> go into 2.0
> 
> Status update:
> Applied:
> * ACPI fixes (both sets)
> * block queue
> * SDL2 relative mode fixes
> * fix for virtio-net CVE
> * fix for qom-list crash
> * my patch to stack-protector check
> Patches on list but need review/ack and/or not sure whether to apply:
> * kvm_physical_sync_dirty_bitmap bug
> * my fix to my stack-protector check patch (oops)
> * vmxnet3 patches
> Raised as issues but no patches:
> * PCI bus naming

Not happening :). With 2.0 we're at least consistent across machine types on ppc.

Alex

> * win64 virtio-scsi regression
> 
> Assistance welcomed in moving patches in the last two
> categories into either "ready to apply" or "not for 2.0" :-)
> 
> thanks
> -- PMM

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Paolo Bonzini]

Il 11/04/2014 13:37, Peter Maydell ha scritto:
> Raised as issues but no patches:
>  * PCI bus naming
>  * win64 virtio-scsi regression

Stefano, can you post the patch to add the xen_enabled() check in 
address_space_translate()?

Paolo

Re: [Qemu-devel] Should we have a 2.0-rc3 ?

[Michael Tokarev]

11.04.2014 21:37, Peter Maydell wrote:
[]
> Patches on list but need review/ack and/or not sure whether to apply:
>  * kvm_physical_sync_dirty_bitmap bug

Paolo proposed to revert the change which lead to that bug, but it
seems wrong thing to do, since original code was clearly wrong.
Maybe it is a good idea to apply Hallyn's version instead of mine
(when done against the right tree), as it makes the code closer
to the original version but more correct.

>  * vmxnet3 patches

I think this is not dangerous to go in before 2.0.  We wont have more
testing even if it were applied much earlier, because this device is
rather exotic in qemu world and isn't used often.  On the other hand,
having less CVE IDs for a release is good, in my opinion.

> Raised as issues but no patches:
>  * PCI bus naming
>  * win64 virtio-scsi regression
> 
> Assistance welcomed in moving patches in the last two
> categories into either "ready to apply" or "not for 2.0" :-)
> 
> thanks
> -- PMM
>