[PULL 0/3] qemu-ga patches

[PULL 0/3] qemu-ga patches

[Konstantin Kostiuk]

The following changes since commit 3757b0d08b399c609954cf57f273b1167e5d7a8d:

  Merge tag 'pull-request-2022-05-18' of https://gitlab.com/thuth/qemu into staging (2022-05-20 08:04:30 -0700)

are available in the Git repository at:

  git@github.com:kostyanf14/qemu.git tags/qga-win32-pull-2022-05-23

for you to fetch changes up to cb69e5d06bb8ba4929f277daa87160bf2f54c51e:

  trivial: qga: Log version on start (2022-05-23 22:27:15 +0300)

----------------------------------------------------------------
qga-win32-pull-2022-05-23

----------------------------------------------------------------
Konstantin Kostiuk (2):
      qga-win32: Add support for NVME but type
      trivial: qga: Log version on start

luzhipeng (1):
      qga: add guest-get-diskstats command for Linux guests

 qga/commands-posix.c | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 qga/commands-win32.c |  11 +++++++++++
 qga/main.c           |   2 ++
 qga/qapi-schema.json |  86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 222 insertions(+)


--
2.25.1

[PULL 1/3] qga: add guest-get-diskstats command for Linux guests

[Konstantin Kostiuk]

From: luzhipeng <luzhipeng@cestc.cn>

Add a new 'guest-get-diskstats' command for report disk io statistics
for Linux guests. This can be useful for getting io flow or handling
IO fault, no need to enter guests.

Signed-off-by: luzhipeng <luzhipeng@cestc.cn>
Message-Id: <20220520021935.676-1-luzhipeng@cestc.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
---
 qga/commands-posix.c | 123 +++++++++++++++++++++++++++++++++++++++++++
 qga/commands-win32.c |   6 +++
 qga/qapi-schema.json |  86 ++++++++++++++++++++++++++++++
 3 files changed, 215 insertions(+)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 69f209af87..12b50b7124 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -2783,6 +2783,122 @@ GuestMemoryBlockInfo *qmp_guest_get_memory_block_info(Error **errp)
     return info;
 }
 
+#define MAX_NAME_LEN 128
+static GuestDiskStatsInfoList *guest_get_diskstats(Error **errp)
+{
+#ifdef CONFIG_LINUX
+    GuestDiskStatsInfoList *head = NULL, **tail = &head;
+    const char *diskstats = "/proc/diskstats";
+    FILE *fp;
+    size_t n;
+    char *line = NULL;
+
+    fp = fopen(diskstats, "r");
+    if (fp  == NULL) {
+        error_setg_errno(errp, errno, "open(\"%s\")", diskstats);
+        return NULL;
+    }
+
+    while (getline(&line, &n, fp) != -1) {
+        g_autofree GuestDiskStatsInfo *diskstatinfo = NULL;
+        g_autofree GuestDiskStats *diskstat = NULL;
+        char dev_name[MAX_NAME_LEN];
+        unsigned int ios_pgr, tot_ticks, rq_ticks, wr_ticks, dc_ticks, fl_ticks;
+        unsigned long rd_ios, rd_merges_or_rd_sec, rd_ticks_or_wr_sec, wr_ios;
+        unsigned long wr_merges, rd_sec_or_wr_ios, wr_sec;
+        unsigned long dc_ios, dc_merges, dc_sec, fl_ios;
+        unsigned int major, minor;
+        int i;
+
+        i = sscanf(line, "%u %u %s %lu %lu %lu"
+                   "%lu %lu %lu %lu %u %u %u %u"
+                   "%lu %lu %lu %u %lu %u",
+                   &major, &minor, dev_name,
+                   &rd_ios, &rd_merges_or_rd_sec, &rd_sec_or_wr_ios,
+                   &rd_ticks_or_wr_sec, &wr_ios, &wr_merges, &wr_sec,
+                   &wr_ticks, &ios_pgr, &tot_ticks, &rq_ticks,
+                   &dc_ios, &dc_merges, &dc_sec, &dc_ticks,
+                   &fl_ios, &fl_ticks);
+
+        if (i < 7) {
+            continue;
+        }
+
+        diskstatinfo = g_new0(GuestDiskStatsInfo, 1);
+        diskstatinfo->name = g_strdup(dev_name);
+        diskstatinfo->major = major;
+        diskstatinfo->minor = minor;
+
+        diskstat = g_new0(GuestDiskStats, 1);
+        if (i == 7) {
+            diskstat->has_read_ios = true;
+            diskstat->read_ios = rd_ios;
+            diskstat->has_read_sectors = true;
+            diskstat->read_sectors = rd_merges_or_rd_sec;
+            diskstat->has_write_ios = true;
+            diskstat->write_ios = rd_sec_or_wr_ios;
+            diskstat->has_write_sectors = true;
+            diskstat->write_sectors = rd_ticks_or_wr_sec;
+        }
+        if (i >= 14) {
+            diskstat->has_read_ios = true;
+            diskstat->read_ios = rd_ios;
+            diskstat->has_read_sectors = true;
+            diskstat->read_sectors = rd_sec_or_wr_ios;
+            diskstat->has_read_merges = true;
+            diskstat->read_merges = rd_merges_or_rd_sec;
+            diskstat->has_read_ticks = true;
+            diskstat->read_ticks = rd_ticks_or_wr_sec;
+            diskstat->has_write_ios = true;
+            diskstat->write_ios = wr_ios;
+            diskstat->has_write_sectors = true;
+            diskstat->write_sectors = wr_sec;
+            diskstat->has_write_merges = true;
+            diskstat->write_merges = wr_merges;
+            diskstat->has_write_ticks = true;
+            diskstat->write_ticks = wr_ticks;
+            diskstat->has_ios_pgr = true;
+            diskstat->ios_pgr = ios_pgr;
+            diskstat->has_total_ticks = true;
+            diskstat->total_ticks = tot_ticks;
+            diskstat->has_weight_ticks = true;
+            diskstat->weight_ticks = rq_ticks;
+        }
+        if (i >= 18) {
+            diskstat->has_discard_ios = true;
+            diskstat->discard_ios = dc_ios;
+            diskstat->has_discard_merges = true;
+            diskstat->discard_merges = dc_merges;
+            diskstat->has_discard_sectors = true;
+            diskstat->discard_sectors = dc_sec;
+            diskstat->has_discard_ticks = true;
+            diskstat->discard_ticks = dc_ticks;
+        }
+        if (i >= 20) {
+            diskstat->has_flush_ios = true;
+            diskstat->flush_ios = fl_ios;
+            diskstat->has_flush_ticks = true;
+            diskstat->flush_ticks = fl_ticks;
+        }
+
+        diskstatinfo->stats = g_steal_pointer(&diskstat);
+        QAPI_LIST_APPEND(tail, diskstatinfo);
+        diskstatinfo = NULL;
+    }
+    free(line);
+    fclose(fp);
+    return head;
+#else
+    g_debug("disk stats reporting available only for Linux");
+    return NULL;
+#endif
+}
+
+GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error **errp)
+{
+    return guest_get_diskstats(errp);
+}
+
 #else /* defined(__linux__) */
 
 void qmp_guest_suspend_disk(Error **errp)
@@ -3131,6 +3247,13 @@ GuestDiskInfoList *qmp_guest_get_disks(Error **errp)
     return NULL;
 }
 
+GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error **errp)
+{
+    error_setg(errp, QERR_UNSUPPORTED);
+    return NULL;
+}
+
+
 #endif /* CONFIG_FSFREEZE */
 
 #if !defined(CONFIG_FSTRIM)
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index d56b5fd2a7..dcdeb76a68 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -2532,3 +2532,9 @@ char *qga_get_host_name(Error **errp)
 
     return g_utf16_to_utf8(tmp, size, NULL, NULL, NULL);
 }
+
+GuestDiskStatsInfoList *qmp_guest_get_diskstats(Error **errp)
+{
+    error_setg(errp, QERR_UNSUPPORTED);
+    return NULL;
+}
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index f989597b0c..9fa20e791b 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -1490,3 +1490,89 @@
 { 'command': 'guest-ssh-remove-authorized-keys',
   'data': { 'username': 'str', 'keys': ['str'] },
   'if': 'CONFIG_POSIX' }
+
+##
+# @GuestDiskStats:
+#
+# @read-sectors: sectors read
+#
+# @read-ios: reads completed successfully
+#
+# @read-merges: read requests merged
+#
+# @write-sectors: sectors written
+#
+# @write-ios: writes completed
+#
+# @write-merges: write requests merged
+#
+# @discard-sectors: sectors discarded
+#
+# @discard-ios: discards completed successfully
+#
+# @discard-merges: discard requests merged
+#
+# @flush-ios: flush requests completed successfully
+#
+# @read-ticks: time spent reading(ms)
+#
+# @write-ticks: time spent writing(ms)
+#
+# @discard-ticks: time spent discarding(ms)
+#
+# @flush-ticks: time spent flushing(ms)
+#
+# @ios-pgr: number of I/Os currently in flight
+#
+# @total-ticks: time spent doing I/Os (ms)
+#
+# @weight-ticks: weighted time spent doing I/Os since the last update of this field(ms)
+#
+# Since: 7.1
+##
+{ 'struct': 'GuestDiskStats',
+  'data': {'*read-sectors': 'uint64',
+           '*read-ios': 'uint64',
+           '*read-merges': 'uint64',
+           '*write-sectors': 'uint64',
+           '*write-ios': 'uint64',
+           '*write-merges': 'uint64',
+           '*discard-sectors': 'uint64',
+           '*discard-ios': 'uint64',
+           '*discard-merges': 'uint64',
+           '*flush-ios': 'uint64',
+           '*read-ticks': 'uint64',
+           '*write-ticks': 'uint64',
+           '*discard-ticks': 'uint64',
+           '*flush-ticks': 'uint64',
+           '*ios-pgr': 'uint64',
+           '*total-ticks': 'uint64',
+           '*weight-ticks': 'uint64'
+           } }
+
+##
+# @GuestDiskStatsInfo:
+#
+# @name disk name
+#
+# @major major device number of disk
+#
+# @minor minor device number of disk
+##
+{ 'struct': 'GuestDiskStatsInfo',
+  'data': {'name': 'str',
+           'major': 'uint64',
+           'minor': 'uint64',
+           'stats': 'GuestDiskStats' } }
+
+##
+# @guest-get-diskstats:
+#
+# Retrieve information about disk stats.
+# Returns: List of disk stats of guest.
+#
+# Since: 7.1
+##
+{ 'command': 'guest-get-diskstats',
+  'returns': ['GuestDiskStatsInfo']
+}
-- 
2.25.1

[PULL 2/3] qga-win32: Add support for NVME but type

[Konstantin Kostiuk]

Bus type spaces (Indicates a storage spaces bus) is not
supported, so return it as unknown.

Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
---
 qga/commands-win32.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index dcdeb76a68..36f94c0f9c 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = {
 #if (_WIN32_WINNT >= 0x0601)
     [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL,
     [BusTypeFileBackedVirtual] = GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL,
+    /*
+     * BusTypeSpaces currently is not suported
+     */
+    [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
+    [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
 #endif
 };
 
-- 
2.25.1

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Richard Henderson]

On 5/23/22 12:41, Konstantin Kostiuk wrote:
> Bus type spaces (Indicates a storage spaces bus) is not
> supported, so return it as unknown.
> 
> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
> Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
> ---
>   qga/commands-win32.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index dcdeb76a68..36f94c0f9c 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = {
>   #if (_WIN32_WINNT >= 0x0601)
>       [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL,
>       [BusTypeFileBackedVirtual] = GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL,
> +    /*
> +     * BusTypeSpaces currently is not suported
> +     */
> +    [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
> +    [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
>   #endif
>   };
>   

Build fails:

../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here (not in a function); 
did you mean 'BusTypeSas'?
   496 |     [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
       |      ^~~~~~~~~~~~~
       |      BusTypeSas
../qga/commands-win32.c:496:6: error: array index in initializer not of integer type
../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu')
../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not in a function); 
did you mean 'BusTypeMmc'?
   497 |     [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
       |      ^~~~~~~~~~~
       |      BusTypeMmc
../qga/commands-win32.c:497:6: error: array index in initializer not of integer type
../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu')


r~

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Konstantin Kostiuk]

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

Thanks for the report. I will think about how to fix the build with old
mingw-headers.
BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0


On Mon, May 23, 2022 at 11:55 PM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 5/23/22 12:41, Konstantin Kostiuk wrote:
> > Bus type spaces (Indicates a storage spaces bus) is not
> > supported, so return it as unknown.
> >
> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
> > Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com>
> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
> > ---
> >   qga/commands-win32.c | 5 +++++
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> > index dcdeb76a68..36f94c0f9c 100644
> > --- a/qga/commands-win32.c
> > +++ b/qga/commands-win32.c
> > @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = {
> >   #if (_WIN32_WINNT >= 0x0601)
> >       [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL,
> >       [BusTypeFileBackedVirtual] =
> GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL,
> > +    /*
> > +     * BusTypeSpaces currently is not suported
> > +     */
> > +    [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
> > +    [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
> >   #endif
> >   };
> >
>
> Build fails:
>
> ../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here (not
> in a function);
> did you mean 'BusTypeSas'?
>    496 |     [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
>        |      ^~~~~~~~~~~~~
>        |      BusTypeSas
> ../qga/commands-win32.c:496:6: error: array index in initializer not of
> integer type
> ../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu')
> ../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not
> in a function);
> did you mean 'BusTypeMmc'?
>    497 |     [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
>        |      ^~~~~~~~~~~
>        |      BusTypeMmc
> ../qga/commands-win32.c:497:6: error: array index in initializer not of
> integer type
> ../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu')
>
>

> r~
>
>

[-- Attachment #2: Type: text/html, Size: 3288 bytes --]

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Konstantin Kostiuk]

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

Hi Richard and Marc-André

I looked into the compilation problem and have 2 solutions:
1. We can add some conditions to the win2qemu definition and
skip NVME support when old mingw-headers are used.
2. We can bump the version of the Fedora docker image to 36 or 37
that is used for cross-compilation tests.

I think the second option is more valuable because we remove
pregenerated qga-vss.tlb file and now we can check VSS build only
at Fedora 37.

What do you think?

Best Regards,
Konstantin Kostiuk.


On Tue, May 24, 2022 at 12:26 PM Konstantin Kostiuk <kkostiuk@redhat.com>
wrote:

> Thanks for the report. I will think about how to fix the build with old
> mingw-headers.
> BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0
>
>
> On Mon, May 23, 2022 at 11:55 PM Richard Henderson <
> richard.henderson@linaro.org> wrote:
>
>> On 5/23/22 12:41, Konstantin Kostiuk wrote:
>> > Bus type spaces (Indicates a storage spaces bus) is not
>> > supported, so return it as unknown.
>> >
>> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
>> > Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com>
>> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
>> > ---
>> >   qga/commands-win32.c | 5 +++++
>> >   1 file changed, 5 insertions(+)
>> >
>> > diff --git a/qga/commands-win32.c b/qga/commands-win32.c
>> > index dcdeb76a68..36f94c0f9c 100644
>> > --- a/qga/commands-win32.c
>> > +++ b/qga/commands-win32.c
>> > @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = {
>> >   #if (_WIN32_WINNT >= 0x0601)
>> >       [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL,
>> >       [BusTypeFileBackedVirtual] =
>> GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL,
>> > +    /*
>> > +     * BusTypeSpaces currently is not suported
>> > +     */
>> > +    [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
>> > +    [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
>> >   #endif
>> >   };
>> >
>>
>> Build fails:
>>
>> ../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here
>> (not in a function);
>> did you mean 'BusTypeSas'?
>>    496 |     [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN,
>>        |      ^~~~~~~~~~~~~
>>        |      BusTypeSas
>> ../qga/commands-win32.c:496:6: error: array index in initializer not of
>> integer type
>> ../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu')
>> ../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not
>> in a function);
>> did you mean 'BusTypeMmc'?
>>    497 |     [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME,
>>        |      ^~~~~~~~~~~
>>        |      BusTypeMmc
>> ../qga/commands-win32.c:497:6: error: array index in initializer not of
>> integer type
>> ../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu')
>>
>>
>
>> r~
>>
>>

[-- Attachment #2: Type: text/html, Size: 4825 bytes --]

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Marc-André Lureau]

Hi

On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote:
>
> Hi Richard and Marc-André
>
> I looked into the compilation problem and have 2 solutions:
> 1. We can add some conditions to the win2qemu definition and
> skip NVME support when old mingw-headers are used.
> 2. We can bump the version of the Fedora docker image to 36 or 37
> that is used for cross-compilation tests.
>
> I think the second option is more valuable because we remove
> pregenerated qga-vss.tlb file and now we can check VSS build only
> at Fedora 37.
>
> What do you think?

I'd try to do both: fix compilation with older headers, and bump our
CI to f36. I don't know if our windows build environment has strict
requirements like the unix/distro (build on old-stable for 2y). The
resulting win32 build is often shipped with all the dependencies (like
the installer from Stefan Weil). But there are also rolling "native"
distros, like msys2...

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Thomas Huth]

On 24/05/2022 12.14, Marc-André Lureau wrote:
> Hi
> 
> On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote:
>>
>> Hi Richard and Marc-André
>>
>> I looked into the compilation problem and have 2 solutions:
>> 1. We can add some conditions to the win2qemu definition and
>> skip NVME support when old mingw-headers are used.
>> 2. We can bump the version of the Fedora docker image to 36 or 37
>> that is used for cross-compilation tests.
>>
>> I think the second option is more valuable because we remove
>> pregenerated qga-vss.tlb file and now we can check VSS build only
>> at Fedora 37.
>>
>> What do you think?
> 
> I'd try to do both: fix compilation with older headers, and bump our
> CI to f36. I don't know if our windows build environment has strict
> requirements like the unix/distro (build on old-stable for 2y).

See https://www.qemu.org/docs/master/about/build-platforms.html#windows :

"The project supports building QEMU with current versions of the MinGW 
toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows."

Since Fedora 35 is still a supported build host, I think you should make 
sure that it works with the MinGW toolchain from that distro, too.

  Thomas

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Konstantin Kostiuk]

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

On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com> wrote:

> On 24/05/2022 12.14, Marc-André Lureau wrote:
> > Hi
> >
> > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com>
> wrote:
> >>
> >> Hi Richard and Marc-André
> >>
> >> I looked into the compilation problem and have 2 solutions:
> >> 1. We can add some conditions to the win2qemu definition and
> >> skip NVME support when old mingw-headers are used.
> >> 2. We can bump the version of the Fedora docker image to 36 or 37
> >> that is used for cross-compilation tests.
> >>
> >> I think the second option is more valuable because we remove
> >> pregenerated qga-vss.tlb file and now we can check VSS build only
> >> at Fedora 37.
> >>
> >> What do you think?
> >
> > I'd try to do both: fix compilation with older headers, and bump our
> > CI to f36. I don't know if our windows build environment has strict
> > requirements like the unix/distro (build on old-stable for 2y).
>
> See https://www.qemu.org/docs/master/about/build-platforms.html#windows :
>
> "The project supports building QEMU with current versions of the MinGW
> toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows."
>
> Since Fedora 35 is still a supported build host, I think you should make
> sure that it works with the MinGW toolchain from that distro, too.
>

Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated
mingw-headers and the current version of code compiles without any errors.
So if we want to support only Fedora 35+, we can just bump the CI docker
image.


>
>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 2629 bytes --]

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Thomas Huth]

On 24/05/2022 15.00, Konstantin Kostiuk wrote:
> 
> 
> 
> 
> On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com>> wrote:
> 
>     On 24/05/2022 12.14, Marc-André Lureau wrote:
>      > Hi
>      >
>      > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk
>     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote:
>      >>
>      >> Hi Richard and Marc-André
>      >>
>      >> I looked into the compilation problem and have 2 solutions:
>      >> 1. We can add some conditions to the win2qemu definition and
>      >> skip NVME support when old mingw-headers are used.
>      >> 2. We can bump the version of the Fedora docker image to 36 or 37
>      >> that is used for cross-compilation tests.
>      >>
>      >> I think the second option is more valuable because we remove
>      >> pregenerated qga-vss.tlb file and now we can check VSS build only
>      >> at Fedora 37.
>      >>
>      >> What do you think?
>      >
>      > I'd try to do both: fix compilation with older headers, and bump our
>      > CI to f36. I don't know if our windows build environment has strict
>      > requirements like the unix/distro (build on old-stable for 2y).
> 
>     See https://www.qemu.org/docs/master/about/build-platforms.html#windows
>     <https://www.qemu.org/docs/master/about/build-platforms.html#windows> :
> 
>     "The project supports building QEMU with current versions of the MinGW
>     toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows."
> 
>     Since Fedora 35 is still a supported build host, I think you should make
>     sure that it works with the MinGW toolchain from that distro, too.
> 
> 
> Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated
> mingw-headers and the current version of code compiles without any errors.
> So if we want to support only Fedora 35+, we can just bump the CI docker image.

Ah, right, I was looking at the wrong file. So yes, in that case, please 
simply update the docker image.

What about Debian (since this is mentioned on the support page, too)? I 
think we don't have to worry about Debian 10 anymore, since Debian 10 will 
already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do the 
MinGW packages there contain the updated headers, too?

  Thomas

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Konstantin Kostiuk]

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

On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com> wrote:

> On 24/05/2022 15.00, Konstantin Kostiuk wrote:
> >
> >
> >
> >
> > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com
> > <mailto:thuth@redhat.com>> wrote:
> >
> >     On 24/05/2022 12.14, Marc-André Lureau wrote:
> >      > Hi
> >      >
> >      > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk
> >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote:
> >      >>
> >      >> Hi Richard and Marc-André
> >      >>
> >      >> I looked into the compilation problem and have 2 solutions:
> >      >> 1. We can add some conditions to the win2qemu definition and
> >      >> skip NVME support when old mingw-headers are used.
> >      >> 2. We can bump the version of the Fedora docker image to 36 or 37
> >      >> that is used for cross-compilation tests.
> >      >>
> >      >> I think the second option is more valuable because we remove
> >      >> pregenerated qga-vss.tlb file and now we can check VSS build only
> >      >> at Fedora 37.
> >      >>
> >      >> What do you think?
> >      >
> >      > I'd try to do both: fix compilation with older headers, and bump
> our
> >      > CI to f36. I don't know if our windows build environment has
> strict
> >      > requirements like the unix/distro (build on old-stable for 2y).
> >
> >     See
> https://www.qemu.org/docs/master/about/build-platforms.html#windows
> >     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>
> :
> >
> >     "The project supports building QEMU with current versions of the
> MinGW
> >     toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on
> Windows."
> >
> >     Since Fedora 35 is still a supported build host, I think you should
> make
> >     sure that it works with the MinGW toolchain from that distro, too.
> >
> >
> > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated
> > mingw-headers and the current version of code compiles without any
> errors.
> > So if we want to support only Fedora 35+, we can just bump the CI docker
> image.
>
> Ah, right, I was looking at the wrong file. So yes, in that case, please
> simply update the docker image.
>
> What about Debian (since this is mentioned on the support page, too)? I
> think we don't have to worry about Debian 10 anymore, since Debian 10 will
> already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do
> the
> MinGW packages there contain the updated headers, too?
>

As I know we do not test cross-compilation at Debian. Debian does not have
even mingw-glib2. Debian only has the mingw-gcc toolkit.


>
>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 4120 bytes --]

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Thomas Huth]

On 24/05/2022 15.17, Konstantin Kostiuk wrote:
> 
> 
> On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com>> wrote:
> 
>     On 24/05/2022 15.00, Konstantin Kostiuk wrote:
>      >
>      >
>      >
>      >
>      > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com
>     <mailto:thuth@redhat.com>
>      > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote:
>      >
>      >     On 24/05/2022 12.14, Marc-André Lureau wrote:
>      >      > Hi
>      >      >
>      >      > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk
>      >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
>     <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
>      >      >>
>      >      >> Hi Richard and Marc-André
>      >      >>
>      >      >> I looked into the compilation problem and have 2 solutions:
>      >      >> 1. We can add some conditions to the win2qemu definition and
>      >      >> skip NVME support when old mingw-headers are used.
>      >      >> 2. We can bump the version of the Fedora docker image to 36 or 37
>      >      >> that is used for cross-compilation tests.
>      >      >>
>      >      >> I think the second option is more valuable because we remove
>      >      >> pregenerated qga-vss.tlb file and now we can check VSS build only
>      >      >> at Fedora 37.
>      >      >>
>      >      >> What do you think?
>      >      >
>      >      > I'd try to do both: fix compilation with older headers, and
>     bump our
>      >      > CI to f36. I don't know if our windows build environment has
>     strict
>      >      > requirements like the unix/distro (build on old-stable for 2y).
>      >
>      >     See
>     https://www.qemu.org/docs/master/about/build-platforms.html#windows
>     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>
>      >   
>       <https://www.qemu.org/docs/master/about/build-platforms.html#windows
>     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> :
>      >
>      >     "The project supports building QEMU with current versions of the
>     MinGW
>      >     toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on
>     Windows."
>      >
>      >     Since Fedora 35 is still a supported build host, I think you
>     should make
>      >     sure that it works with the MinGW toolchain from that distro, too.
>      >
>      >
>      > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated
>      > mingw-headers and the current version of code compiles without any
>     errors.
>      > So if we want to support only Fedora 35+, we can just bump the CI
>     docker image.
> 
>     Ah, right, I was looking at the wrong file. So yes, in that case, please
>     simply update the docker image.
> 
>     What about Debian (since this is mentioned on the support page, too)? I
>     think we don't have to worry about Debian 10 anymore, since Debian 10 will
>     already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do
>     the
>     MinGW packages there contain the updated headers, too?
> 
> 
> As I know we do not test cross-compilation at Debian. Debian does not have
> even mingw-glib2. Debian only has the mingw-gcc toolkit.

Oh, interesting! Then I wonder why Debian is mentioned there ... seems like 
it has been added here:

  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823

Daniel, do you remember whether we supported Debian for MinGW 
cross-compilation in the past?

  Thomas

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Thomas Huth]

On 24/05/2022 15.28, Thomas Huth wrote:
> On 24/05/2022 15.17, Konstantin Kostiuk wrote:
>>
>>
>> On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com 
>> <mailto:thuth@redhat.com>> wrote:
>>
>>     On 24/05/2022 15.00, Konstantin Kostiuk wrote:
>>      >
>>      >
>>      >
>>      >
>>      > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com
>>     <mailto:thuth@redhat.com>
>>      > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote:
>>      >
>>      >     On 24/05/2022 12.14, Marc-André Lureau wrote:
>>      >      > Hi
>>      >      >
>>      >      > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk
>>      >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
>>     <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
>>      >      >>
>>      >      >> Hi Richard and Marc-André
>>      >      >>
>>      >      >> I looked into the compilation problem and have 2 solutions:
>>      >      >> 1. We can add some conditions to the win2qemu definition and
>>      >      >> skip NVME support when old mingw-headers are used.
>>      >      >> 2. We can bump the version of the Fedora docker image to 36 
>> or 37
>>      >      >> that is used for cross-compilation tests.
>>      >      >>
>>      >      >> I think the second option is more valuable because we remove
>>      >      >> pregenerated qga-vss.tlb file and now we can check VSS 
>> build only
>>      >      >> at Fedora 37.
>>      >      >>
>>      >      >> What do you think?
>>      >      >
>>      >      > I'd try to do both: fix compilation with older headers, and
>>     bump our
>>      >      > CI to f36. I don't know if our windows build environment has
>>     strict
>>      >      > requirements like the unix/distro (build on old-stable for 2y).
>>      >
>>      >     See
>>     https://www.qemu.org/docs/master/about/build-platforms.html#windows
>>     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>
>>      >      
>>  <https://www.qemu.org/docs/master/about/build-platforms.html#windows
>>     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> :
>>      >
>>      >     "The project supports building QEMU with current versions of the
>>     MinGW
>>      >     toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on
>>     Windows."
>>      >
>>      >     Since Fedora 35 is still a supported build host, I think you
>>     should make
>>      >     sure that it works with the MinGW toolchain from that distro, too.
>>      >
>>      >
>>      > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has 
>> updated
>>      > mingw-headers and the current version of code compiles without any
>>     errors.
>>      > So if we want to support only Fedora 35+, we can just bump the CI
>>     docker image.
>>
>>     Ah, right, I was looking at the wrong file. So yes, in that case, please
>>     simply update the docker image.
>>
>>     What about Debian (since this is mentioned on the support page, too)? I
>>     think we don't have to worry about Debian 10 anymore, since Debian 10 
>> will
>>     already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do
>>     the
>>     MinGW packages there contain the updated headers, too?
>>
>>
>> As I know we do not test cross-compilation at Debian. Debian does not have
>> even mingw-glib2. Debian only has the mingw-gcc toolkit.
> 
> Oh, interesting! Then I wonder why Debian is mentioned there ... seems like 
> it has been added here:
> 
>   https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823
> 
> Daniel, do you remember whether we supported Debian for MinGW 
> cross-compilation in the past?

Ah, well, stupid me, we did use it, and I was even the one who once removed 
the container:

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e3755276d1f54

... but since this was using a third party repository, I think we don't have 
to worry about this here anymore.

  Thomas

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Daniel P. Berrangé]

On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote:
> On 24/05/2022 15.17, Konstantin Kostiuk wrote:
> > 
> > 
> > On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com
> > <mailto:thuth@redhat.com>> wrote:
> > 
> >     On 24/05/2022 15.00, Konstantin Kostiuk wrote:
> >      >
> >      >
> >      >
> >      >
> >      > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com
> >     <mailto:thuth@redhat.com>
> >      > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote:
> >      >
> >      >     On 24/05/2022 12.14, Marc-André Lureau wrote:
> >      >      > Hi
> >      >      >
> >      >      > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk
> >      >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
> >     <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
> >      >      >>
> >      >      >> Hi Richard and Marc-André
> >      >      >>
> >      >      >> I looked into the compilation problem and have 2 solutions:
> >      >      >> 1. We can add some conditions to the win2qemu definition and
> >      >      >> skip NVME support when old mingw-headers are used.
> >      >      >> 2. We can bump the version of the Fedora docker image to 36 or 37
> >      >      >> that is used for cross-compilation tests.
> >      >      >>
> >      >      >> I think the second option is more valuable because we remove
> >      >      >> pregenerated qga-vss.tlb file and now we can check VSS build only
> >      >      >> at Fedora 37.
> >      >      >>
> >      >      >> What do you think?
> >      >      >
> >      >      > I'd try to do both: fix compilation with older headers, and
> >     bump our
> >      >      > CI to f36. I don't know if our windows build environment has
> >     strict
> >      >      > requirements like the unix/distro (build on old-stable for 2y).
> >      >
> >      >     See
> >     https://www.qemu.org/docs/master/about/build-platforms.html#windows
> >     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>
> >      >
> >  <https://www.qemu.org/docs/master/about/build-platforms.html#windows
> >     <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> :
> >      >
> >      >     "The project supports building QEMU with current versions of the
> >     MinGW
> >      >     toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on
> >     Windows."
> >      >
> >      >     Since Fedora 35 is still a supported build host, I think you
> >     should make
> >      >     sure that it works with the MinGW toolchain from that distro, too.
> >      >
> >      >
> >      > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated
> >      > mingw-headers and the current version of code compiles without any
> >     errors.
> >      > So if we want to support only Fedora 35+, we can just bump the CI
> >     docker image.
> > 
> >     Ah, right, I was looking at the wrong file. So yes, in that case, please
> >     simply update the docker image.
> > 
> >     What about Debian (since this is mentioned on the support page, too)? I
> >     think we don't have to worry about Debian 10 anymore, since Debian 10 will
> >     already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do
> >     the
> >     MinGW packages there contain the updated headers, too?
> > 
> > 
> > As I know we do not test cross-compilation at Debian. Debian does not have
> > even mingw-glib2. Debian only has the mingw-gcc toolkit.
> 
> Oh, interesting! Then I wonder why Debian is mentioned there ... seems like
> it has been added here:
> 
>  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823
> 
> Daniel, do you remember whether we supported Debian for MinGW
> cross-compilation in the past?

At one time we used to have Debian with the 3rd party 'mxe' builds
of mingw added. It broke periodically and we deleted it in the
end. It wasn't adding value over what Fedora mingw could provide
as both more or less tracked the same versions of software in
their mingw packages.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

[Thomas Huth]

On 24/05/2022 15.38, Daniel P. Berrangé wrote:
> On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote:
...
>>
>> Daniel, do you remember whether we supported Debian for MinGW
>> cross-compilation in the past?
> 
> At one time we used to have Debian with the 3rd party 'mxe' builds
> of mingw added. It broke periodically and we deleted it in the
> end. It wasn't adding value over what Fedora mingw could provide
> as both more or less tracked the same versions of software in
> their mingw packages.

I wonder whether anybody still tried to compile with this mxe repo in recent 
times...?
Should we adjust our support statement and just mention Fedora there? 
Otherwise we should maybe explicitly mention MXE there next to "Debian", 
too, so that people don't get the impression that QEMU can be compiled with 
a vanilla MinGW installation on Debian?

  Thomas

Re: Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

[Stefan Weil via]

Am 03.06.22 um 14:56 schrieb Thomas Huth:

> On 24/05/2022 15.38, Daniel P. Berrangé wrote:
>> On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote:
> ...
>>>
>>> Daniel, do you remember whether we supported Debian for MinGW
>>> cross-compilation in the past?
>>
>> At one time we used to have Debian with the 3rd party 'mxe' builds
>> of mingw added. It broke periodically and we deleted it in the
>> end. It wasn't adding value over what Fedora mingw could provide
>> as both more or less tracked the same versions of software in
>> their mingw packages.
>
> I wonder whether anybody still tried to compile with this mxe repo in 
> recent times...?
> Should we adjust our support statement and just mention Fedora there? 
> Otherwise we should maybe explicitly mention MXE there next to 
> "Debian", too, so that people don't get the impression that QEMU can 
> be compiled with a vanilla MinGW installation on Debian?
>
>  Thomas


My QEMU for Windows builds are all done on Debian. They use the cross 
tools which are provided in the normal Debian distribution. I don't use 
the (few) cross libraries from Debian.

Until end of last year, I added library packages from Cygwin (plus a few 
self compiled libraries, for example for braille support). See 
https://qemu.weilnetz.de/debian/.

In 2022 I switched to using the library packages from msys (I still have 
to write some documentation for that).

Stefan

Re: Debian MinGW cross compilation (was: Re: [PULL 2/3] qga-win32: Add support for NVME but type)

[Thomas Huth]

On 03/06/2022 15.09, Stefan Weil wrote:
> Am 03.06.22 um 14:56 schrieb Thomas Huth:
> 
>> On 24/05/2022 15.38, Daniel P. Berrangé wrote:
>>> On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote:
>> ...
>>>>
>>>> Daniel, do you remember whether we supported Debian for MinGW
>>>> cross-compilation in the past?
>>>
>>> At one time we used to have Debian with the 3rd party 'mxe' builds
>>> of mingw added. It broke periodically and we deleted it in the
>>> end. It wasn't adding value over what Fedora mingw could provide
>>> as both more or less tracked the same versions of software in
>>> their mingw packages.
>>
>> I wonder whether anybody still tried to compile with this mxe repo in 
>> recent times...?
>> Should we adjust our support statement and just mention Fedora there? 
>> Otherwise we should maybe explicitly mention MXE there next to "Debian", 
>> too, so that people don't get the impression that QEMU can be compiled 
>> with a vanilla MinGW installation on Debian?
>>
>>  Thomas
> 
> 
> My QEMU for Windows builds are all done on Debian. They use the cross tools 
> which are provided in the normal Debian distribution. I don't use the (few) 
> cross libraries from Debian.
> 
> Until end of last year, I added library packages from Cygwin (plus a few 
> self compiled libraries, for example for braille support). See 
> https://qemu.weilnetz.de/debian/.
> 
> In 2022 I switched to using the library packages from msys (I still have to 
> write some documentation for that).

Ok, thanks for the info. Seems like there are multiple ways to get the 
missing packages for the MinGW installation on Debian, so let's simply keep 
the support statement in the current shape.

  Thomas

Re: [PULL 2/3] qga-win32: Add support for NVME but type

[Peter Maydell]

On Tue, 24 May 2022 at 10:26, Konstantin Kostiuk <kkostiuk@redhat.com> wrote:
>
> Thanks for the report. I will think about how to fix the build with old mingw-headers.
> BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0

If you need to respin anyway you could fix the typo in the
patch subject (s/but/bus/ I assume) :-)

-- PMM

[PULL 3/3] trivial: qga: Log version on start

[Konstantin Kostiuk]

Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220523191644.823726-2-kkostiuk@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
---
 qga/main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/qga/main.c b/qga/main.c
index 3b9546c185..c373fec3ee 100644
--- a/qga/main.c
+++ b/qga/main.c
@@ -1271,6 +1271,8 @@ static GAState *initialize_agent(GAConfig *config, int socket_activation)
     g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
     ga_enable_logging(s);
 
+    g_debug("Guest agent version %s started", QEMU_FULL_VERSION);
+
 #ifdef _WIN32
     /* On win32 the state directory is application specific (be it the default
      * or a user override). We got past the command line parsing; let's create
-- 
2.25.1