[Qemu-devel] qemu build fails on xen

[Qemu-devel] qemu build fails on xen

[Michael S. Tsirkin]

The following error triggers on Fedora 22:

In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
                 from hw/block/xen_disk.c:39:
/scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’
 typedef uint32_t ioservid_t;
                  ^
In file included from /usr/include/xen/hvm/params.h:24:0,
                 from /usr/include/xenctrl.h:46,
                 from /scm/qemu/include/hw/xen/xen_common.h:9,
                 from /scm/qemu/include/hw/xen/xen_backend.h:4,
                 from hw/block/xen_disk.c:39:
/usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of ‘ioservid_t’ was here
 typedef uint16_t ioservid_t;
                  ^
/scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
make: *** [hw/block/xen_disk.o] Error 1
make: *** Waiting for unfinished jobs....

Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
Author: Paul Durrant <paul.durrant@citrix.com>
Date:   Tue Jan 20 11:06:19 2015 +0000

    Xen: Use the ioreq-server API when available


Looking at that header:

#ifndef HVM_PARAM_BUFIOREQ_EVTCHN
#define HVM_PARAM_BUFIOREQ_EVTCHN 26
#endif

#define IOREQ_TYPE_PCI_CONFIG 2


typedef uint32_t ioservid_t;


Are all polluting the global namespace, not to mention, violate the coding
style. Why not prefix them with Xen_, xen_ etc?


-- 
MST

Re: [Qemu-devel] qemu build fails on xen

[Michael S. Tsirkin]

On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
> The following error triggers on Fedora 22:
> 
> In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
>                  from hw/block/xen_disk.c:39:
> /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’
>  typedef uint32_t ioservid_t;
>                   ^
> In file included from /usr/include/xen/hvm/params.h:24:0,
>                  from /usr/include/xenctrl.h:46,
>                  from /scm/qemu/include/hw/xen/xen_common.h:9,
>                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
>                  from hw/block/xen_disk.c:39:
> /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of ‘ioservid_t’ was here
>  typedef uint16_t ioservid_t;
>                   ^
> /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> make: *** [hw/block/xen_disk.o] Error 1
> make: *** Waiting for unfinished jobs....
> 
> Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d

Sorry - I meant reverting this commit fixes the problem.



> Author: Paul Durrant <paul.durrant@citrix.com>
> Date:   Tue Jan 20 11:06:19 2015 +0000
> 
>     Xen: Use the ioreq-server API when available
> 
> 
> Looking at that header:
> 
> #ifndef HVM_PARAM_BUFIOREQ_EVTCHN
> #define HVM_PARAM_BUFIOREQ_EVTCHN 26
> #endif
> 
> #define IOREQ_TYPE_PCI_CONFIG 2
> 
> 
> typedef uint32_t ioservid_t;
> 
> 
> Are all polluting the global namespace, not to mention, violate the coding
> style. Why not prefix them with Xen_, xen_ etc?
> 
> 
> -- 
> MST

Re: [Qemu-devel] qemu build fails on xen

[Paul Durrant]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: 07 July 2015 09:48
> To: Stefano Stabellini
> Cc: Chen, Tiejun; pbonzini@redhat.com; rth@twiddle.net;
> ehabkost@redhat.com; qemu-devel@nongnu.org; Paul Durrant; Peter
> Maydell
> Subject: Re: qemu build fails on xen
> 
> On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
> > The following error triggers on Fedora 22:
> >
> > In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
> >                  from hw/block/xen_disk.c:39:
> > /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting
> types for ‘ioservid_t’
> >  typedef uint32_t ioservid_t;
> >                   ^
> > In file included from /usr/include/xen/hvm/params.h:24:0,
> >                  from /usr/include/xenctrl.h:46,
> >                  from /scm/qemu/include/hw/xen/xen_common.h:9,
> >                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
> >                  from hw/block/xen_disk.c:39:
> > /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of
> ‘ioservid_t’ was here
> >  typedef uint16_t ioservid_t;
> >                   ^
> > /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> > make: *** [hw/block/xen_disk.o] Error 1
> > make: *** Waiting for unfinished jobs....
> >
> > Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
> 
> Sorry - I meant reverting this commit fixes the problem.

Hmm. I'm not sure why the definition in xen_common.h is there. I guess it's probably for compatibility. It's clearly wrong though.

  Paul
 
> 
> 
> > Author: Paul Durrant <paul.durrant@citrix.com>
> > Date:   Tue Jan 20 11:06:19 2015 +0000
> >
> >     Xen: Use the ioreq-server API when available
> >
> >
> > Looking at that header:
> >
> > #ifndef HVM_PARAM_BUFIOREQ_EVTCHN
> > #define HVM_PARAM_BUFIOREQ_EVTCHN 26
> > #endif
> >
> > #define IOREQ_TYPE_PCI_CONFIG 2
> >
> >
> > typedef uint32_t ioservid_t;
> >
> >
> > Are all polluting the global namespace, not to mention, violate the coding
> > style. Why not prefix them with Xen_, xen_ etc?
> >
> >
> > --
> > MST

Re: [Qemu-devel] qemu build fails on xen

[Peter Maydell]

On 7 July 2015 at 10:26, Paul Durrant <Paul.Durrant@citrix.com> wrote:
>> -----Original Message-----
>> From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> Sent: 07 July 2015 09:48
>> To: Stefano Stabellini
>> Cc: Chen, Tiejun; pbonzini@redhat.com; rth@twiddle.net;
>> ehabkost@redhat.com; qemu-devel@nongnu.org; Paul Durrant; Peter
>> Maydell
>> Subject: Re: qemu build fails on xen
>>
>> On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
>> > The following error triggers on Fedora 22:
>> >
>> > In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
>> >                  from hw/block/xen_disk.c:39:
>> > /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting
>> types for ‘ioservid_t’
>> >  typedef uint32_t ioservid_t;
>> >                   ^
>> > In file included from /usr/include/xen/hvm/params.h:24:0,
>> >                  from /usr/include/xenctrl.h:46,
>> >                  from /scm/qemu/include/hw/xen/xen_common.h:9,
>> >                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
>> >                  from hw/block/xen_disk.c:39:
>> > /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of
>> ‘ioservid_t’ was here
>> >  typedef uint16_t ioservid_t;
>> >                   ^
>> > /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
>> > make: *** [hw/block/xen_disk.o] Error 1
>> > make: *** Waiting for unfinished jobs....
>> >
>> > Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
>>
>> Sorry - I meant reverting this commit fixes the problem.
>
> Hmm. I'm not sure why the definition in xen_common.h is there. I guess it's probably for compatibility. It's clearly wrong though.

Reminder: today is hardfreeze day -- a fix for this within the
next few hours would be nice, or rc0 won't build on these hosts
with xen enabled...

thanks
-- PMM

Re: [Qemu-devel] qemu build fails on xen

[Paul Durrant]

> -----Original Message-----
> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> Sent: 07 July 2015 13:38
> To: Paul Durrant
> Cc: Michael S. Tsirkin; Stefano Stabellini; Chen, Tiejun; pbonzini@redhat.com;
> rth@twiddle.net; ehabkost@redhat.com; qemu-devel@nongnu.org
> Subject: Re: qemu build fails on xen
> 
> On 7 July 2015 at 10:26, Paul Durrant <Paul.Durrant@citrix.com> wrote:
> >> -----Original Message-----
> >> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >> Sent: 07 July 2015 09:48
> >> To: Stefano Stabellini
> >> Cc: Chen, Tiejun; pbonzini@redhat.com; rth@twiddle.net;
> >> ehabkost@redhat.com; qemu-devel@nongnu.org; Paul Durrant; Peter
> >> Maydell
> >> Subject: Re: qemu build fails on xen
> >>
> >> On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
> >> > The following error triggers on Fedora 22:
> >> >
> >> > In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
> >> >                  from hw/block/xen_disk.c:39:
> >> > /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting
> >> types for ‘ioservid_t’
> >> >  typedef uint32_t ioservid_t;
> >> >                   ^
> >> > In file included from /usr/include/xen/hvm/params.h:24:0,
> >> >                  from /usr/include/xenctrl.h:46,
> >> >                  from /scm/qemu/include/hw/xen/xen_common.h:9,
> >> >                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
> >> >                  from hw/block/xen_disk.c:39:
> >> > /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of
> >> ‘ioservid_t’ was here
> >> >  typedef uint16_t ioservid_t;
> >> >                   ^
> >> > /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> >> > make: *** [hw/block/xen_disk.o] Error 1
> >> > make: *** Waiting for unfinished jobs....
> >> >
> >> > Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
> >>
> >> Sorry - I meant reverting this commit fixes the problem.
> >
> > Hmm. I'm not sure why the definition in xen_common.h is there. I guess
> it's probably for compatibility. It's clearly wrong though.
> 
> Reminder: today is hardfreeze day -- a fix for this within the
> next few hours would be nice, or rc0 won't build on these hosts
> with xen enabled...
> 

I will send a patch shortly.

  Paul

> thanks
> -- PMM

Re: [Qemu-devel] qemu build fails on xen

[Paul Durrant]

> -----Original Message-----
> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> Sent: 07 July 2015 13:38
> To: Paul Durrant
> Cc: Michael S. Tsirkin; Stefano Stabellini; Chen, Tiejun; pbonzini@redhat.com;
> rth@twiddle.net; ehabkost@redhat.com; qemu-devel@nongnu.org
> Subject: Re: qemu build fails on xen
> 
> On 7 July 2015 at 10:26, Paul Durrant <Paul.Durrant@citrix.com> wrote:
> >> -----Original Message-----
> >> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >> Sent: 07 July 2015 09:48
> >> To: Stefano Stabellini
> >> Cc: Chen, Tiejun; pbonzini@redhat.com; rth@twiddle.net;
> >> ehabkost@redhat.com; qemu-devel@nongnu.org; Paul Durrant; Peter
> >> Maydell
> >> Subject: Re: qemu build fails on xen
> >>
> >> On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
> >> > The following error triggers on Fedora 22:
> >> >
> >> > In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
> >> >                  from hw/block/xen_disk.c:39:
> >> > /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting
> >> types for ‘ioservid_t’
> >> >  typedef uint32_t ioservid_t;
> >> >                   ^
> >> > In file included from /usr/include/xen/hvm/params.h:24:0,
> >> >                  from /usr/include/xenctrl.h:46,
> >> >                  from /scm/qemu/include/hw/xen/xen_common.h:9,
> >> >                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
> >> >                  from hw/block/xen_disk.c:39:
> >> > /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of
> >> ‘ioservid_t’ was here
> >> >  typedef uint16_t ioservid_t;
> >> >                   ^
> >> > /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> >> > make: *** [hw/block/xen_disk.o] Error 1
> >> > make: *** Waiting for unfinished jobs....
> >> >
> >> > Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
> >>
> >> Sorry - I meant reverting this commit fixes the problem.
> >
> > Hmm. I'm not sure why the definition in xen_common.h is there. I guess
> it's probably for compatibility. It's clearly wrong though.
>

Looking more closely, if the definition in hvm_op.h is there then the one in xen_common.h should not be found since it's inside

#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450

and the code in configure sets that to 450 if xc_hvm_create_ioreq_server() is present in libxenctrl.so. That function was added in the same patch series as the typedef of ioservid_t so it suggests that there is a mismatch between the xen headers and the version of libxenctrl in the build environment.

  Paul
 
> Reminder: today is hardfreeze day -- a fix for this within the
> next few hours would be nice, or rc0 won't build on these hosts
> with xen enabled...
> 
> thanks
> -- PMM