[Qemu-devel] Question to prefered

[Qemu-devel] Question to prefered

[Sander Eikelenboom]

Hi Paolo / Anthony,

I have 2 questions:

1) Since Paolo has cleaned up the qemu tree by splitting out the /hw dir.
   I was considering to make the Xen file naming a bit more consistent.
   At the moment it's a mismatch with the xen prefix and the rest of the filename, separated by a hyphen, underscore or nothing at all.

   Is there a preference or guideline to file naming from the qemu point of view (especially regarding the separation ?

2) Qemu seems to have the possibility to make a debug enabled build by specifing --enable-debug option to ./configure,
   that sets CONFIG_DEBUG_EXEC=y, but a grep on CONFIG_DEBUG_EXEC seems to indicate it's not in widespread use ..
   - Why is it not named CONFIG_DEBUG ?
   - Is it the right config to use to swith on verbose debugging in the xen files.

   That would make it possible for xen to build a qemu binary with verbose debugging enabled, when building xen as a debug build

Regards,

--
Sander

Re: [Qemu-devel] Question to prefered

[Peter Maydell]

On 11 April 2013 20:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hi Paolo / Anthony,
> 2) Qemu seems to have the possibility to make a debug enabled build by specifing --enable-debug option to ./configure,
>    that sets CONFIG_DEBUG_EXEC=y, but a grep on CONFIG_DEBUG_EXEC seems to indicate it's not in widespread use ..

--enable-debug does several things:
 * turns on --enable-debug-tcg
 * does not compile with optimization
 * does not strip the binaries
 * turns on the CONFIG_DEBUG_EXEC flag to enable '-d exec'

>    - Why is it not named CONFIG_DEBUG ?

Because CONFIG_DEBUG_EXEC is not a general purpose 'turn on debug logs'
switch. It has a specific meaning: "make the '-d exec' debug log command
line option work". Note that it does not cause QEMU to emit any
extra logging unless requested at runtime.

In fact, since the only overhead of CONFIG_DEBUG_EXEC is a single
qemu_log_mask() call I think I might submit a patch to drop it
entirely and just always have -d exec work...

>    - Is it the right config to use to swith on verbose debugging
> in the xen files.

No. It depends a bit what you mean by "verbose debugging",
incidentally. QEMU has several commonly used logging options:

(1) per-source file #defines which you can turn on as a developer
to get a lot of debug printf output
(2) the -d command line option, which lets the user enable
certain classes of logging by category (for example, this is
the best way to log "the guest did something weird which is
probably a guest bug" or "the guest tried to access something
we don't implement")
(3) tracepoints (see docs/tracing.txt)

-- PMM

Re: [Qemu-devel] Question to prefered

[Sander Eikelenboom]

Thursday, April 11, 2013, 9:50:09 PM, you wrote:

> On 11 April 2013 20:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hi Paolo / Anthony,
>> 2) Qemu seems to have the possibility to make a debug enabled build by specifing --enable-debug option to ./configure,
>>    that sets CONFIG_DEBUG_EXEC=y, but a grep on CONFIG_DEBUG_EXEC seems to indicate it's not in widespread use ..

> --enable-debug does several things:
>  * turns on --enable-debug-tcg
>  * does not compile with optimization
>  * does not strip the binaries
>  * turns on the CONFIG_DEBUG_EXEC flag to enable '-d exec'

>>    - Why is it not named CONFIG_DEBUG ?

> Because CONFIG_DEBUG_EXEC is not a general purpose 'turn on debug logs'
> switch. It has a specific meaning: "make the '-d exec' debug log command
> line option work". Note that it does not cause QEMU to emit any
> extra logging unless requested at runtime.

> In fact, since the only overhead of CONFIG_DEBUG_EXEC is a single
> qemu_log_mask() call I think I might submit a patch to drop it
> entirely and just always have -d exec work...

>>    - Is it the right config to use to swith on verbose debugging
>> in the xen files.

> No. It depends a bit what you mean by "verbose debugging",
> incidentally. QEMU has several commonly used logging options:

Well since Xen has the option to be build with "make debug=y" which also disables optimizations, enables extra asserts and makes it more verbose.
It could be handy to propagate that to the qemu-binary that is built in the xen-tree to also be more verbose if it's built as part of a debug build.

That way you can ask a user to build a debug build, and not have a user edit to much source to enable all the defines.

Apart from that the current xen-files in upstream qemu are much less verbose than the old forked in tree qemu-traditional was, so that will also require some adjustment.

Would a "--enable-debug-xen" config option be acceptable ?

> (1) per-source file #defines which you can turn on as a developer
> to get a lot of debug printf output
> (2) the -d command line option, which lets the user enable
> certain classes of logging by category (for example, this is
> the best way to log "the guest did something weird which is
> probably a guest bug" or "the guest tried to access something
> we don't implement")
> (3) tracepoints (see docs/tracing.txt)

> -- PMM

Re: [Qemu-devel] Question to prefered

[Stefano Stabellini]

On Thu, 11 Apr 2013, Sander Eikelenboom wrote:
> > No. It depends a bit what you mean by "verbose debugging",
> > incidentally. QEMU has several commonly used logging options:
> 
> Well since Xen has the option to be build with "make debug=y" which also disables optimizations, enables extra asserts and makes it more verbose.
> It could be handy to propagate that to the qemu-binary that is built in the xen-tree to also be more verbose if it's built as part of a debug build.
> 
> That way you can ask a user to build a debug build, and not have a user edit to much source to enable all the defines.
> 
> Apart from that the current xen-files in upstream qemu are much less verbose than the old forked in tree qemu-traditional was, so that will also require some adjustment.
> 
> Would a "--enable-debug-xen" config option be acceptable ?

I think that's not actually needed.
We should make better use of the following:


> > (2) the -d command line option, which lets the user enable
> > certain classes of logging by category (for example, this is
> > the best way to log "the guest did something weird which is
> > probably a guest bug" or "the guest tried to access something
> > we don't implement")
> > (3) tracepoints (see docs/tracing.txt)