Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Thomas Huth]

On 04.04.2017 08:53, Alexander Graf wrote:
> 
> 
> On 03.04.17 23:00, Eduardo Habkost wrote:
>> On Mon, Apr 03, 2017 at 10:15:44PM +0200, Alexander Graf wrote:
>>>
>>>
>>> On 03.04.17 22:10, Eduardo Habkost wrote:
 On Mon, Apr 03, 2017 at 08:49:16PM +0100, Peter Maydell wrote:
> On 1 April 2017 at 01:46, Eduardo Habkost  wrote:
>> commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
>> cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
>> all kinds of untested devices available to -device and
>> device_add.
>>
>> The problem with that is: setting has_dynamic_sysbus on a
>> machine-type lets it accept all the 288 sysbus device types we
>> have in QEMU, and most of them were never meant to be used with
>> -device. That's a lot of untested code.
>>
>> Fortunately today we have just a few has_dynamic_sysbus=1
>> machines: virt, pc-q35-*, ppce500, and spapr.
>>
>> virt, ppce500, and spapr have extra checks to ensure just a few
>> device types can be instantiated:
>>
>> * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
>> * ppce500 supports only TYPE_ETSEC_COMMON.
>> * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.
>>
>> q35 has no code to block unsupported sysbus devices, however, and
>> accepts all device types. Fortunately, only the following 20
>> device types are compiled into the qemu-system-x86_64 and
>> qemu-system-i386 binaries:
>>
>> * allwinner-ahci
>> * amd-iommu
>> * cfi.pflash01
>> * esp
>> * fw_cfg_io
>> * fw_cfg_mem
>> * generic-sdhci
>> * hpet
>> * intel-iommu
>> * ioapic
>> * isabus-bridge
>> * kvmclock
>> * kvm-ioapic
>> * kvmvapic
>> * SUNW,fdtwo
>> * sysbus-ahci
>> * sysbus-fdc
>> * sysbus-ohci
>> * unimplemented-device
>> * virtio-mmio
>>
>> Instead of requiring each machine-type with has_dynamic_sysbus=1
>> to implement its own mechanism to block unsupported devices, we
>> can use the user_creatable flag to ensure we won't let the user
>> plug anything that will never work.
>
> How does this work? Which devices can be dynamically
> plugged is machine dependent. You can't dynamically-plug
> an intel-iommu on the ARM virt board, and you can't
> dynamically-plug the vfio-calxeda-xgmac on the spapr
> board, and so on. So I don't see how we can just have
> a flag on the device itself that controls whether
> it can be dynamically plugged.
>
> So I'm definitely coming around to the opinion that
> it's just a bug in the q35 board that it doesn't have
> any device whitelisting, and we should fix that.

 OK, let's assume q35 must implement a whitelist:

 To build that whitelist, we need to be able to know what should
 be in the whitelist, or not. And nobody knew for sure what was
 user-creatable in q35 by accident, and what was really supposed
 to be user-creatable in q35. See the "q35 and sysbus devices"
 thread I started ~2 weeks ago.

 Building a q35 whitelist will be much easier if make
 sys-bus-devices non-user-creatable by default.
>>>
>>> So why are they user creatable in the first place?
>>>
>>> We used to have boards that were dynamic sysbus aware (ppce500, virt)
>>> that
>>> allowed dynamic creation and every other board did not. I don't
>>> remember the
>>> exact mechanism behind it though.
>>>
>>> When did that behavior change? It sounds like a regression somewhere.
>>
>> See patch description:
>>
>> commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
>> cannot_instantiate_with_device_add_yet in TYPE_SYSBUS,
>>
>> Note that the commit above is not a regression[1] (because q35
>> didn't have has_dynamic_sysbus=1 yet), but having sysbus devices
>> have cannot_instantiate_with_device_add_yet=false/user_creatable=true
>> by default makes it harder to build the whitelist for q35 (or
>> other machines that will have has_dynamic_sysbus=1 in the
>> future).
> 
> I seem to miss the bigger picture.
> 
> Why would anyone set has_dynamic_sysbus=1 in a board file without an
> explicit whitelist? The whitelist is *not* device specific. It's board
> specific, because your board needs to know how to wire up a device and
> how to expose the fact that it exists to the OS.
> 
> So the real bug is that someone set has_dynamic_sysbus=1 in q35 without
> implementing all of the dynamic sysbus logic, no?

According to commit bf8d492405feaee2c1685b3b9d5e03228ed3e47f this was
just introduced for allowing the "intel-iommu" device, so I guess this
is the device that we want to have in a whitelist there?

 Thomas

Re: [Qemu-devel] [PATCH v5] qga: Add `guest-get-timezone` command

[Vinzenz Feenstra]

Ping

> On Mar 23, 2017, at 12:39 PM, Vinzenz 'evilissimo' Feenstra 
>  wrote:
> 
> From: Vinzenz Feenstra 
> 
> Adds a new command `guest-get-timezone` reporting the currently
> configured timezone on the system. The information on what timezone is
> currently is configured is useful in case of Windows VMs where the
> offset of the hardware clock is required to have the same offset. This
> can be used for management systems like `oVirt` to detect the timezone
> difference and warn administrators of the misconfiguration.
> 
> Signed-off-by: Vinzenz Feenstra 
> ---
> qga/commands.c   | 29 +
> qga/qapi-schema.json | 26 ++
> 2 files changed, 55 insertions(+)
> 
> diff --git a/qga/commands.c b/qga/commands.c
> index 4d92946..3b5789c 100644
> --- a/qga/commands.c
> +++ b/qga/commands.c
> @@ -499,3 +499,32 @@ int ga_parse_whence(GuestFileWhence *whence, Error 
> **errp)
> error_setg(errp, "invalid whence code %"PRId64, whence->u.value);
> return -1;
> }
> +
> +GuestTimezone *qmp_guest_get_timezone(Error **errp)
> +{
> +GuestTimezone *info = g_new0(GuestTimezone, 1);
> +GTimeZone *tz = g_time_zone_new_local();
> +if (tz == NULL) {
> +error_setg(errp, QERR_QGA_COMMAND_FAILED,
> +   "Couldn't retrieve local timezone");
> +goto error;
> +}
> +
> +gint64 now = g_get_real_time() / G_USEC_PER_SEC;
> +gint32 intv = g_time_zone_find_interval(tz, G_TIME_TYPE_UNIVERSAL, now);
> +info->offset = g_time_zone_get_offset(tz, intv);
> +gchar const *name = g_time_zone_get_abbreviation(tz, intv);
> +if (name != NULL) {
> +info->has_zone = true;
> +info->zone = g_strdup(name);
> +}
> +g_time_zone_unref(tz);
> +
> +return info;
> +
> +error:
> +g_time_zone_unref(tz);
> +g_free(info);
> +return NULL;
> +}
> +
> diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
> index a02dbf2..5183ea2 100644
> --- a/qga/qapi-schema.json
> +++ b/qga/qapi-schema.json
> @@ -1042,3 +1042,29 @@
>   'data':{ 'path': 'str', '*arg': ['str'], '*env': ['str'],
>'*input-data': 'str', '*capture-output': 'bool' },
>   'returns': 'GuestExec' }
> +
> +
> +##
> +# @GuestTimezone:
> +#
> +# @zone:Timezone name
> +# @offset:  Offset to UTC in seconds, negative numbers for time zones west of
> +#   GMT, positive numbers for east
> +#
> +# Since: 2.10
> +##
> +{ 'struct': 'GuestTimezone',
> +  'data':   { '*zone': 'str', 'offset': 'int' } }
> +
> +
> +##
> +# @guest-get-timezone:
> +#
> +# Retrieves the timezone information from the guest.
> +#
> +# Returns: A GuestTimezone dictionary.
> +#
> +# Since: 2.10
> +##
> +{ 'command': 'guest-get-timezone',
> +  'returns': 'GuestTimezone' }
> -- 
> 2.9.3
> 

--
Vinzenz Feenstra
Senior Software Developer
Red Hat Czech

Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Alexander Graf]

On 03.04.17 23:00, Eduardo Habkost wrote:

On Mon, Apr 03, 2017 at 10:15:44PM +0200, Alexander Graf wrote:



On 03.04.17 22:10, Eduardo Habkost wrote:

On Mon, Apr 03, 2017 at 08:49:16PM +0100, Peter Maydell wrote:

On 1 April 2017 at 01:46, Eduardo Habkost  wrote:

commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
all kinds of untested devices available to -device and
device_add.

The problem with that is: setting has_dynamic_sysbus on a
machine-type lets it accept all the 288 sysbus device types we
have in QEMU, and most of them were never meant to be used with
-device. That's a lot of untested code.

Fortunately today we have just a few has_dynamic_sysbus=1
machines: virt, pc-q35-*, ppce500, and spapr.

virt, ppce500, and spapr have extra checks to ensure just a few
device types can be instantiated:

* virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
* ppce500 supports only TYPE_ETSEC_COMMON.
* spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.

q35 has no code to block unsupported sysbus devices, however, and
accepts all device types. Fortunately, only the following 20
device types are compiled into the qemu-system-x86_64 and
qemu-system-i386 binaries:

* allwinner-ahci
* amd-iommu
* cfi.pflash01
* esp
* fw_cfg_io
* fw_cfg_mem
* generic-sdhci
* hpet
* intel-iommu
* ioapic
* isabus-bridge
* kvmclock
* kvm-ioapic
* kvmvapic
* SUNW,fdtwo
* sysbus-ahci
* sysbus-fdc
* sysbus-ohci
* unimplemented-device
* virtio-mmio

Instead of requiring each machine-type with has_dynamic_sysbus=1
to implement its own mechanism to block unsupported devices, we
can use the user_creatable flag to ensure we won't let the user
plug anything that will never work.


How does this work? Which devices can be dynamically
plugged is machine dependent. You can't dynamically-plug
an intel-iommu on the ARM virt board, and you can't
dynamically-plug the vfio-calxeda-xgmac on the spapr
board, and so on. So I don't see how we can just have
a flag on the device itself that controls whether
it can be dynamically plugged.

So I'm definitely coming around to the opinion that
it's just a bug in the q35 board that it doesn't have
any device whitelisting, and we should fix that.


OK, let's assume q35 must implement a whitelist:

To build that whitelist, we need to be able to know what should
be in the whitelist, or not. And nobody knew for sure what was
user-creatable in q35 by accident, and what was really supposed
to be user-creatable in q35. See the "q35 and sysbus devices"
thread I started ~2 weeks ago.

Building a q35 whitelist will be much easier if make
sys-bus-devices non-user-creatable by default.


So why are they user creatable in the first place?

We used to have boards that were dynamic sysbus aware (ppce500, virt) that
allowed dynamic creation and every other board did not. I don't remember the
exact mechanism behind it though.

When did that behavior change? It sounds like a regression somewhere.


See patch description:


commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
cannot_instantiate_with_device_add_yet in TYPE_SYSBUS,


Note that the commit above is not a regression[1] (because q35
didn't have has_dynamic_sysbus=1 yet), but having sysbus devices
have cannot_instantiate_with_device_add_yet=false/user_creatable=true
by default makes it harder to build the whitelist for q35 (or
other machines that will have has_dynamic_sysbus=1 in the
future).


I seem to miss the bigger picture.

Why would anyone set has_dynamic_sysbus=1 in a board file without an 
explicit whitelist? The whitelist is *not* device specific. It's board 
specific, because your board needs to know how to wire up a device and 
how to expose the fact that it exists to the OS.


So the real bug is that someone set has_dynamic_sysbus=1 in q35 without 
implementing all of the dynamic sysbus logic, no?



Alex

[Qemu-devel] [PATCH v2 0/1] qga: Add 'guest-get-host-name' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

Since v1:
- Renamed from FQDN to hostname and expanded documentation

Vinzenz Feenstra (1):
  qga: Add 'guest-get-host-name' command

 qga/commands.c   | 11 +++
 qga/qapi-schema.json | 29 +
 2 files changed, 40 insertions(+)

-- 
2.9.3

[Qemu-devel] [PATCH v2 1/1] qga: Add 'guest-get-host-name' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

Retrieving the guest host name is a very useful feature for virtual management
systems. This information can help to have more user friendly VM access
details, instead of an IP there would be the host name. Also the host name
reported can be used to have automated checks for valid SSL certificates.

virsh # qemu-agent-command F25 '{ "execute": "guest-get-host-name" }'
{"return":{"host-name":"F25.lab.evilissimo.net"}}

Signed-off-by: Vinzenz Feenstra 
---
 qga/commands.c   | 11 +++
 qga/qapi-schema.json | 29 +
 2 files changed, 40 insertions(+)

diff --git a/qga/commands.c b/qga/commands.c
index 4d92946..57a31bb 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -499,3 +499,14 @@ int ga_parse_whence(GuestFileWhence *whence, Error **errp)
 error_setg(errp, "invalid whence code %"PRId64, whence->u.value);
 return -1;
 }
+
+GuestHostName *qmp_guest_get_host_name(Error **err)
+{
+GuestHostName *result = NULL;
+gchar const *hostname = g_get_host_name();
+if (hostname != NULL) {
+result = g_new0(GuestHostName, 1);
+result->host_name = g_strdup(hostname);
+}
+return result;
+}
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index a02dbf2..b9f99ae 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -1042,3 +1042,32 @@
   'data':{ 'path': 'str', '*arg': ['str'], '*env': ['str'],
'*input-data': 'str', '*capture-output': 'bool' },
   'returns': 'GuestExec' }
+
+
+
+##
+# @GuestHostName:
+# @host-name: Fully qualified domain name of the guest OS
+#
+# Since: 2.10
+##
+{ 'struct': 'GuestHostName',
+  'data':   { 'host-name': 'str' } }
+
+
+##
+# @guest-get-host-name:
+#
+# Return a name for the machine.
+#
+# The returned name is not necessarily a fully-qualified domain name, or even
+# present in DNS or some other name service at all. It need not even be unique
+# on your local network or site, but usually it is.
+#
+# Returns: the host name of the machine on success
+#
+# Since: 2.10
+##
+{ 'command': 'guest-get-host-name',
+  'returns': 'GuestHostName' }
+
-- 
2.9.3

Re: [Qemu-devel] [RFC 02/19] s390: Add FIXME for unexplained user_creatable=false line

[Cornelia Huck]

On Mon, 3 Apr 2017 16:20:11 -0300
Eduardo Habkost  wrote:

> On Mon, Apr 03, 2017 at 10:55:38AM +0200, Cornelia Huck wrote:
> > On Fri, 31 Mar 2017 21:46:07 -0300
> > Eduardo Habkost  wrote:
> > 
> > > TYPE_S390_PCI_HOST_BRIDGE has user_creatable=false but has
> > > no comment explaining why. Add a FIXME to document that.
> > > 
> > > Cc: Frank Blaschka 
> > > Cc: Cornelia Huck 
> > > Cc: Christian Borntraeger 
> > > Cc: Alexander Graf 
> > > Cc: Richard Henderson 
> > > Signed-off-by: Eduardo Habkost 
> > > ---
> > >  hw/s390x/s390-pci-bus.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> > > index 1ec30c45ce..2c3b960bdf 100644
> > > --- a/hw/s390x/s390-pci-bus.c
> > > +++ b/hw/s390x/s390-pci-bus.c
> > > @@ -867,7 +867,7 @@ static void s390_pcihost_class_init(ObjectClass 
> > > *klass, void *data)
> > >  DeviceClass *dc = DEVICE_CLASS(klass);
> > >  HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
> > >  
> > > -dc->user_creatable = false;
> > > +dc->user_creatable = false; /*FIXME: explain why */
> > >  dc->reset = s390_pcihost_reset;
> > >  k->init = s390_pcihost_init;
> > >  hc->plug = s390_pcihost_hot_plug;
> > 
> > (adding some more possibly interested parties)
> > 
> > We currently have one master s390 phb (and it's been that way since
> > s390 pci was introduced). Recently, there has been some remodelling
> > going on to make this more similar to what sPAPR does. I think we could
> > make this even more similar to sPAPR and have this user createable; but
> > I'm currently not sure it's worth the effort. Opinions?
> 
> It looks -device s390-pcihost was never possible, anyway, because
> no s390x machine has has_dynamic_sysbus=1, and TYPE_PCI_HOST_BRIDGE
> is a sys-bus-device.

Yes.

> 
> Also, patch 03/19 on this series would make the explicit
> user_creatable=false assignment in s390_pcihost_class_init()
> unnecessary.

If we switch to "sysbus devices are never user creatable, except for a
select few" anyway, I think we can just get rid of this.

> 
> I don't think it is worth the effort to change that, unless you
> have a specific use case that would benefit from it.

Not really. We're building a highly artificical "topology" that does
not exist on real hardware (and is not seen by the guest) here, so we
can basically do whatever works best. We _might_ want to be more
similar to sPAPR, so that we're not the complete oddball, but it seems
that we can make everything work with the current setup already.

Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

[Cornelia Huck]

On Mon, 3 Apr 2017 18:12:34 +
Andrew Baumann  wrote:

> > From: Cornelia Huck [mailto:cornelia.h...@de.ibm.com]
> > Sent: Monday, 3 April 2017 7:20
> > 
> > On Fri, 24 Mar 2017 15:01:41 -0700
> > Andrew Baumann  wrote:
> > 
> > > From: Andrey Shedel 
> > >
> > > The multithreaded TCG implementation exposed deadlocks in the win32
> > > condition variables: as implemented, qemu_cond_broadcast waited on
> > > receivers, whereas the pthreads API it was intended to emulate does
> > > not. This was causing a deadlock because broadcast was called while
> > > holding the IO lock, as well as all possible waiters blocked on the
> > > same lock.
> > >
> > > This patch replaces all the custom synchronisation code for mutexes
> > > and condition variables with native Windows primitives (SRWlocks and
> > > condition variables) with the same semantics as their POSIX
> > > equivalents. To enable that, it requires a Windows Vista or newer host
> > > OS.
> > >
> > > [AB: edited commit message]
> > > Signed-off-by: Andrew Baumann 
> > > ---
> > > The major implication of this patch is that it drops support for
> > > pre-Vista versions of Windows. However, those OSes are past their end
> > > of life, and other OSS projects have dropped support. e.g.; the last
> > > Cygwin release supporting XP was in Jun 2016. It doesn't seem like a
> > > good tradeoff to invest effort in fixing broken code needed to support
> > > them, so hopefully this isn't too controversial.
> > 
> > Just a quick question:
> > 
> > I noticed that this breaks builds on an old fc20-based installation I
> > run some mingw cross builds on (getting an undefined reference to
> > `_imp__TryAcquireSRWLockExclusive@4'). I should probably take that as a
> > trigger to update that installation ;), but wanted to confirm that this
> > is expected.
> 
> Yes, please try updating your mingw headers. I've done x64 cross-builds from 
> Ubuntu 16.04 (WSL) using mingw-w64 4.0.4.

Yes, another, more modern cross-build setup works fine. I just was a
bit surprised that this mingw setup did not go back to Vista level.

Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.

[Gerd Hoffmann]

On Mo, 2017-04-03 at 19:02 +0200, Paolo Bonzini wrote:
> 
> On 03/04/2017 14:03, Gerd Hoffmann wrote:
> > We might clear some more bits, but these are
> > outsize the visible area so they should cause visible corruption (and if
> > the visible area changes the display code needs to do a full refresh
> > anyway).
> 
> True, though this makes the snapshot abstraction a little more
> specialized.  Please add a FIXME comment with the explanation, at least.

Sure, I'll add a note to the (to be written) docs.

cheers,
  Gerd

Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.

[Gerd Hoffmann]

  Hi,

> -unsigned long align = 1 << (TARGET_PAGE_BITS + BITS_PER_LEVEL);
> +unsigned long align = 1UL << (TARGET_PAGE_BITS + BITS_PER_LEVEL);

> There were 2 issues here: without the UL suffix on align I was getting
> incorrect first/last addresses since the high bits of align weren't
> being cleared,

Ah, thanks, I'll add that.

> and then offset appeared to be shifted twice.

Yep, noticed that too meanwhile, fixed in the branch pushed half an hour
ago.  I've dropped the other shift though ;)

cheers,
  Gerd

[Qemu-devel] [PATCH v3 1/1] qga: Add 'guest-get-users' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

A command that will list all currently logged in users, and the time
since when they are logged in.

Examples:

virsh # qemu-agent-command F25 '{ "execute": "guest-get-users" }'
{"return":[{"login-time":1490622289.903835,"user":"root"}]}

virsh # qemu-agent-command Win2k12r2 '{ "execute": "guest-get-users" }'
{"return":[{"login-time":1490351044.670552,"domain":"LADIDA",
"user":"Administrator"}]}

Signed-off-by: Vinzenz Feenstra 
---
 configure |  2 +-
 include/glib-compat.h |  5 +++
 qga/commands-posix.c  | 54 +++
 qga/commands-win32.c  | 89 +++
 qga/qapi-schema.json  | 24 ++
 5 files changed, 173 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d1ce33b..779ebfd 100755
--- a/configure
+++ b/configure
@@ -737,7 +737,7 @@ if test "$mingw32" = "yes" ; then
   sysconfdir="\${prefix}"
   local_statedir=
   confsuffix=""
-  libs_qga="-lws2_32 -lwinmm -lpowrprof -liphlpapi -lnetapi32 $libs_qga"
+  libs_qga="-lws2_32 -lwinmm -lpowrprof -lwtsapi32 -liphlpapi -lnetapi32 
$libs_qga"
 fi
 
 werror=""
diff --git a/include/glib-compat.h b/include/glib-compat.h
index 863c8cf..f8ee9dc 100644
--- a/include/glib-compat.h
+++ b/include/glib-compat.h
@@ -217,6 +217,11 @@ static inline void g_hash_table_add(GHashTable 
*hash_table, gpointer key)
 {
 g_hash_table_replace(hash_table, key, key);
 }
+
+static gboolean g_hash_table_contains(GHashTable *hash_table, gpointer key)
+{
+return g_hash_table_lookup_extended(hash_table, key, NULL, NULL);
+}
 #endif
 
 #ifndef g_assert_true
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 73d93eb..3081ee7 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "qga/guest-agent-core.h"
 #include "qga-qmp-commands.h"
 #include "qapi/qmp/qerror.h"
@@ -2515,3 +2516,56 @@ void ga_command_state_init(GAState *s, GACommandState 
*cs)
 ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
 #endif
 }
+
+#ifndef QGA_MICRO_SECOND_TO_SECOND
+#   define QGA_MICRO_SECOND_TO_SECOND 100
+#endif
+
+static double ga_get_login_time(struct utmpx *user_info)
+{
+double seconds = (double)user_info->ut_tv.tv_sec;
+double useconds = (double)user_info->ut_tv.tv_usec;
+useconds /= QGA_MICRO_SECOND_TO_SECOND;
+return seconds + useconds;
+}
+
+GuestUserList *qmp_guest_get_users(Error **err)
+{
+GHashTable *cache = g_hash_table_new(g_str_hash, g_str_equal);
+GuestUserList *head = NULL, *cur_item = NULL;
+setutxent();
+for (;;) {
+struct utmpx *user_info = getutxent();
+if (user_info == NULL) {
+break;
+} else if (user_info->ut_type != USER_PROCESS) {
+continue;
+} else if (g_hash_table_contains(cache, user_info->ut_user)) {
+gpointer value = g_hash_table_lookup(cache, user_info->ut_user);
+GuestUser *user = (GuestUser *)value;
+double login_time = ga_get_login_time(user_info);
+/* We're ensuring the earliest login time to be sent */
+if (login_time < user->login_time) {
+user->login_time = login_time;
+}
+continue;
+}
+
+GuestUserList *item = g_new0(GuestUserList, 1);
+item->value = g_new0(GuestUser, 1);
+item->value->user = g_strdup(user_info->ut_user);
+item->value->login_time = ga_get_login_time(user_info);
+
+g_hash_table_insert(cache, item->value->user, item->value);
+
+if (!cur_item) {
+head = cur_item = item;
+} else {
+cur_item->next = item;
+cur_item = item;
+}
+}
+endutxent();
+g_hash_table_destroy(cache);
+return head;
+}
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 19d72b2..8b84a90 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -11,6 +11,9 @@
  * See the COPYING file in the top-level directory.
  */
 
+#ifndef _WIN32_WINNT
+#   define _WIN32_WINNT 0x0600
+#endif
 #include "qemu/osdep.h"
 #include 
 #include 
@@ -25,6 +28,7 @@
 #include 
 #endif
 #include 
+#include 
 
 #include "qga/guest-agent-core.h"
 #include "qga/vss-win32.h"
@@ -1536,3 +1540,88 @@ void ga_command_state_init(GAState *s, GACommandState 
*cs)
 ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
 }
 }
+
+/* MINGW is missing two fields: IncomingFrames & OutgoingFrames */
+typedef struct _GA_WTSINFOA {
+WTS_CONNECTSTATE_CLASS State;
+DWORD SessionId;
+DWORD IncomingBytes;
+DWORD OutgoingBytes;
+DWORD IncomingFrames;
+DWORD OutgoingFrames;
+DWORD IncomingCompressedBytes;
+DWORD OutgoingCompressedBy;
+CHAR WinStationName[WINSTATIONNAME_LENGTH];
+CHAR Domain[DOMAIN_LENGTH];
+CHAR UserName[USERNAME_LENGTH + 1];
+LARGE_INTEGER ConnectTime;
+LARGE_INTEGER DisconnectTime;
+LARGE_INTEGER 

[Qemu-devel] [PATCH v3 0/1] qga: Add 'guest-get-users' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

Changes since v2:
- Updated the documentation of login-time to be more precise what the value
  contains and what time is actually reported and in which format.

Changes since v1:
- fixed spelling issues in the commit message and schema
- added login-time field which specifies the time the users logged on
- applied changes suggested for glib hash table usage
- added new link time library dependency for wtsapi32
- setting now _WIN32_WINNT to 0x0600 if not defined globally, which is Windows
  Vista and/or Windows 2008 Server and higher

Vinzenz Feenstra (1):
  qga: Add 'guest-get-users' command

 configure |  2 +-
 include/glib-compat.h |  5 +++
 qga/commands-posix.c  | 54 +++
 qga/commands-win32.c  | 89 +++
 qga/qapi-schema.json  | 24 ++
 5 files changed, 173 insertions(+), 1 deletion(-)

-- 
2.9.3

Re: [Qemu-devel] [PATCH v3] qemu-ga: add guest-get-osrelease command

[Vinzenz Feenstra]

Hi Michael,

It’d be really great to get your opinion on this matter. Thanks!

> On Apr 3, 2017, at 5:17 PM, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> On Fri, Mar 31, 2017 at 3:41 PM Eric Blake  > wrote:
> On 03/31/2017 05:19 AM, Vinzenz 'evilissimo' Feenstra wrote:
> > From: Vinzenz Feenstra mailto:vfeen...@redhat.com>>
> >
> > Add a new 'guest-get-osrelease' command to report OS information in the
> > os-release format. As documented here:
> > https://www.freedesktop.org/software/systemd/man/os-release.html 
> > 
> >
> > The win32 implementation generates the information.
> > On POSIX systems the /etc/os-release or /usr/lib/os-release files
> > content is returned when available and gets extended with the fields:
> > - QGA_UNAME_RELEASE which is the content of `uname -r`
> > - QGA_UNAME_VERSION which is the content of `uname -v`
> > - QGA_UNAME_MACHINE which is the content of `uname -m`
> >
> > Here an example for a Fedora 25 VM:
> >
> > virsh # qemu-agent-command F25 '{ "execute": "guest-get-osrelease" }'
> > {"return":{"content":"NAME=Fedora\nVERSION=\"25 (Server Edition)\"\n
> > ID=fedora\nVERSION_ID=25\nPRETTY_NAME=\"Fedora 25 (Server Edition)\"\n
> > ANSI_COLOR=\"0;34\"\nCPE_NAME=\"cpe:/o:fedoraproject:fedora:25\"\n
> > HOME_URL=\"https://fedoraproject.org/\ "\n
> > BUG_REPORT_URL=\"https://bugzilla.redhat.com/\ 
> > "\n
> > REDHAT_BUGZILLA_PRODUCT=\"Fedora\"\n
> > REDHAT_BUGZILLA_PRODUCT_VERSION=25\nREDHAT_SUPPORT_PRODUCT=\"Fedora\"\n
> > REDHAT_SUPPORT_PRODUCT_VERSION=25\n
> > PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy\n 
> > 
> > VARIANT=\"Server Edition\"\nVARIANT_ID=server\n\n
> > QGA_UNAME_RELEASE=\"4.8.6-300.fc25.x86_64\"\n
> > QGA_UNAME_VERSION=\"#1 SMP Tue Nov 1 12:36:38 UTC 2016\"\n
> > QGA_UNAME_MACHINE=\"x86_64\"\n"}}
> 
> Uggh. This is a step backwards.  Now you are requiring the end user to
> parse a raw string, instead of giving them the information already
> broken out as a JSON dictionary.
> 
> yes otoh, it uses an existing standard to retrieve various guest os release 
> informations, which existing tool may know how to handle.
> 
> (I feel partially guilty about it since I suggested it, mainly in a 
> discussion over irc and Vinzenz adopted it)
> 
> The format is fairly straightforward to parse, but perhaps it should be sent 
> as a JSON dict instead? However, that would mean that the list of keys is 
> limited by what QGA protocol defines, and the agent would have to parse the 
> file himself. And we would have to duplicate the documentation etc..
> 
> I would rely on the XDG format instead, given its simplicity, extensibility 
> and documentation that fits the job nicely imho.
>  
> -- 
> Marc-André Lureau

--
Vinzenz Feenstra
Senior Software Developer
Red Hat Czech

Re: [Qemu-devel] [RFC PATCH v1 7/9] cpus: move icount preparation out of tcg_exec_cpu

[Pavel Dovgalyuk]

I guess you are trying to fix the sympthoms of the case
when iothread is trying to access instruction count.

Maybe the solution is providing access to current_cpu for the iothread
coupled with your patch 8?

Pavel Dovgalyuk


> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: Monday, April 03, 2017 3:45 PM
> To: dovga...@ispras.ru; r...@twiddle.net; pbonz...@redhat.com
> Cc: peter.mayd...@linaro.org; qemu-devel@nongnu.org; 
> mt...@listserver.greensocs.com;
> fred.kon...@greensocs.com; a.r...@virtualopensystems.com; c...@braap.org;
> bobby.pr...@gmail.com; nik...@linux.vnet.ibm.com; Alex Bennée; Peter 
> Crosthwaite
> Subject: [RFC PATCH v1 7/9] cpus: move icount preparation out of tcg_exec_cpu
> 
> As icount is only supported for single-threaded execution due to the
> requirement for determinism let's remove it from the common
> tcg_exec_cpu path.
> 
> Also remove the additional fiddling which shouldn't be required as the
> icount counters should all be rectified as you enter the loop.
> 
> Signed-off-by: Alex Bennée 
> ---
>  cpus.c | 67 
> +-
>  1 file changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 18b1746770..87638a75d2 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1179,47 +1179,66 @@ static void handle_icount_deadline(void)
>  }
>  }
> 
> -static int tcg_cpu_exec(CPUState *cpu)
> +static void prepare_icount_for_run(CPUState *cpu)
>  {
> -int ret;
> -#ifdef CONFIG_PROFILER
> -int64_t ti;
> -#endif
> -
> -#ifdef CONFIG_PROFILER
> -ti = profile_getclock();
> -#endif
>  if (use_icount) {
>  int64_t count;
>  int decr;
> -timers_state.qemu_icount -= (cpu->icount_decr.u16.low
> -+ cpu->icount_extra);
> -cpu->icount_decr.u16.low = 0;
> -cpu->icount_extra = 0;
> +
> +/* These should always be cleared by process_icount_data after
> + * each vCPU execution. However u16.high can be raised
> + * asynchronously by cpu_exit/cpu_interrupt/tcg_handle_interrupt
> + */
> +g_assert(cpu->icount_decr.u16.low == 0);
> +g_assert(cpu->icount_extra == 0);
> +
> +
>  count = tcg_get_icount_limit();
> +
>  timers_state.qemu_icount += count;
>  decr = (count > 0x) ? 0x : count;
>  count -= decr;
>  cpu->icount_decr.u16.low = decr;
>  cpu->icount_extra = count;
>  }
> -qemu_mutex_unlock_iothread();
> -cpu_exec_start(cpu);
> -ret = cpu_exec(cpu);
> -cpu_exec_end(cpu);
> -qemu_mutex_lock_iothread();
> -#ifdef CONFIG_PROFILER
> -tcg_time += profile_getclock() - ti;
> -#endif
> +}
> +
> +static void process_icount_data(CPUState *cpu)
> +{
>  if (use_icount) {
>  /* Fold pending instructions back into the
> instruction counter, and clear the interrupt flag.  */
>  timers_state.qemu_icount -= (cpu->icount_decr.u16.low
>  + cpu->icount_extra);
> +
> +/* We must be under BQL here as cpu_exit can tweak
> +   icount_decr.u32 */
> +g_assert(qemu_mutex_iothread_locked());
>  cpu->icount_decr.u32 = 0;
>  cpu->icount_extra = 0;
>  replay_account_executed_instructions();
>  }
> +}
> +
> +
> +static int tcg_cpu_exec(CPUState *cpu)
> +{
> +int ret;
> +#ifdef CONFIG_PROFILER
> +int64_t ti;
> +#endif
> +
> +#ifdef CONFIG_PROFILER
> +ti = profile_getclock();
> +#endif
> +qemu_mutex_unlock_iothread();
> +cpu_exec_start(cpu);
> +ret = cpu_exec(cpu);
> +cpu_exec_end(cpu);
> +qemu_mutex_lock_iothread();
> +#ifdef CONFIG_PROFILER
> +tcg_time += profile_getclock() - ti;
> +#endif
>  return ret;
>  }
> 
> @@ -1306,7 +1325,13 @@ static void *qemu_tcg_rr_cpu_thread_fn(void *arg)
> 
>  if (cpu_can_run(cpu)) {
>  int r;
> +
> +prepare_icount_for_run(cpu);
> +
>  r = tcg_cpu_exec(cpu);
> +
> +process_icount_data(cpu);
> +
>  if (r == EXCP_DEBUG) {
>  cpu_handle_guest_debug(cpu);
>  break;
> --
> 2.11.0

Re: [Qemu-devel] [RFC PATCH v1 8/9] cpus: don't credit executed instructions before they have run

[Pavel Dovgalyuk]

> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Outside of the vCPU thread icount time will only be tracked against
> timers_state.qemu_icount. We no longer credit cycles until they have
> completed the run. Inside the vCPU thread we adjust for passage of
> time by looking at how many have run so far. This is only valid inside
> the vCPU thread while it is running.
> 
> Signed-off-by: Alex Bennée 
> ---
>  cpus.c| 27 +--
>  include/qom/cpu.h |  1 +
>  2 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 87638a75d2..3d18374b0e 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -223,6 +223,15 @@ void qemu_tcg_configure(QemuOpts *opts, Error **errp)
>  }
>  }
> 
> +/* The current number of executed instructions is based on what we
> + * originally budgeted minus the current state of the decrementing
> + * icount counters in extra/u16.low.
> + */
> +static int64_t cpu_get_icount_executed(CPUState *cpu)
> +{
> +return cpu->icount_budget - (cpu->icount_decr.u16.low + 
> cpu->icount_extra);
> +}
> +
>  int64_t cpu_get_icount_raw(void)
>  {
>  int64_t icount;
> @@ -234,7 +243,8 @@ int64_t cpu_get_icount_raw(void)
>  fprintf(stderr, "Bad icount read\n");
>  exit(1);
>  }
> -icount -= (cpu->icount_decr.u16.low + cpu->icount_extra);
> +/* Take into account what has run */
> +icount += cpu_get_icount_executed(cpu);
>  }
>  return icount;

As far, as I understand, this one will return the same value in iothread
until vCPU thread finishes cpu_exec?
This value will not jump forward and backward, but still will not allow
making execution deterministic.

Consider the following scenarios:

First:
vCPUiothread
access HW   
... access HW in timer

Second:
vCPUiothread
... access HW in timer
access HW   

These scenarios will generate the same order of events in the log.
Synchronization checkpoint in iothread will try to write already
executed instructions, but it does not have access to current_cpu
and the icount value will point to the "past" - it will have less
instructions than already executed.

That is why you see "negative" instruction count event.

>  }
> @@ -1195,7 +1205,10 @@ static void prepare_icount_for_run(CPUState *cpu)
> 
>  count = tcg_get_icount_limit();
> 
> -timers_state.qemu_icount += count;
> +/* To calculate what we have executed so far we need to know
> + * what we originally budgeted to run this cycle */
> +cpu->icount_budget = count;
> +
>  decr = (count > 0x) ? 0x : count;
>  count -= decr;
>  cpu->icount_decr.u16.low = decr;
> @@ -1206,16 +1219,18 @@ static void prepare_icount_for_run(CPUState *cpu)
>  static void process_icount_data(CPUState *cpu)
>  {
>  if (use_icount) {
> -/* Fold pending instructions back into the
> -   instruction counter, and clear the interrupt flag.  */
> -timers_state.qemu_icount -= (cpu->icount_decr.u16.low
> -+ cpu->icount_extra);
> +/* Account for executed instructions */
> +timers_state.qemu_icount += cpu_get_icount_executed(cpu);
> 
>  /* We must be under BQL here as cpu_exit can tweak
> icount_decr.u32 */
>  g_assert(qemu_mutex_iothread_locked());
> +
> +/* Reset the counters */
>  cpu->icount_decr.u32 = 0;
>  cpu->icount_extra = 0;
> +cpu->icount_budget = 0;
> +
>  replay_account_executed_instructions();
>  }
>  }
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index c3292efe1c..5d10359c8f 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -332,6 +332,7 @@ struct CPUState {
>  /* updates protected by BQL */
>  uint32_t interrupt_request;
>  int singlestep_enabled;
> +int64_t icount_budget;
>  int64_t icount_extra;
>  sigjmp_buf jmp_env;
> 
> --
> 2.11.0


Pavel Dovgalyuk

[Qemu-devel] [Bug 1678466] Re: using x-vga=on with vfio-pci leads to segfault

[Alex Williamson]

Does this resolve the segfault?

diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index e9b493b939db..349085ea12bc 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -660,7 +660,7 @@ static void vfio_probe_nvidia_bar5_quirk(VFIOPCIDevice *vdev
 VFIOConfigWindowQuirk *window;
 
 if (!vfio_pci_is(vdev, PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID) ||
-!vdev->vga || nr != 5) {
+!vdev->vga || nr != 5 || !vdev->bars[5].ioport) {
 return;
 }

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1678466

Title:
  using x-vga=on with vfio-pci leads to segfault

Status in QEMU:
  New

Bug description:
  bug occures at least with qemu 2.8.0 and 2.8.1 in 64bit-system

  stripped cmd for minimal config:
  qemu-system-i386 -m 2048 -M q35  -enable-kvm -nodefaults -nodefconfig -device 
ioh3420,bus=pcie.0,addr=0x9,multifunction=on,port=1,chassis=1,id=root.1 -device 
vfio-pci,host=01:00.0,bus=root.1,addr=01.0,x-vga=on

  Backtrace is:
  #0  0x557ca836 in memory_region_update_container_subregions 
(subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2030
  #1  0x557ca9dc in memory_region_add_subregion_common (mr=0x0, 
offset=8, subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2049
  #2  0x557caa9a in memory_region_add_subregion_overlap (mr=0x0, 
offset=8, subregion=0x5828f2f0, priority=1) at qemu-2.8.1/memory.c:2066
  #3  0x55832e48 in vfio_probe_nvidia_bar5_quirk (vdev=0x5805aef0, 
nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:689
  #4  0x55835433 in vfio_bar_quirk_setup (vdev=0x5805aef0, nr=5) at 
qemu-2.8.1/hw/vfio/pci-quirks.c:1652
  #5  0x5582f122 in vfio_realize (pdev=0x5805aef0, 
errp=0x7fffdc78) at qemu-2.8.1/hw/vfio/pci.c:2777
  #6  0x55a86195 in pci_qdev_realize (qdev=0x5805aef0, 
errp=0x7fffdcf0) at hw/pci/pci.c:1966
  #7  0x559be7b7 in device_set_realized (obj=0x5805aef0, 
value=true, errp=0x7fffdeb0) at hw/core/qdev.c:918
  #8  0x55bb017f in property_set_bool (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", opaque=0x57f15860, 
errp=0x7fffdeb0) at qom/object.c:1854
  #9  0x55bae2e6 in object_property_set (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1088
  #10 0x55bb184f in object_property_set_qobject (obj=0x5805aef0, 
value=0x5805cd70, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/qom-qobject.c:27
  #11 0x55bae637 in object_property_set_bool (obj=0x5805aef0, 
value=true, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1157
  #12 0x558fee4b in qdev_device_add (opts=0x56b15160, 
errp=0x7fffdf28) at qdev-monitor.c:623
  #13 0x559142c1 in device_init_func (opaque=0x0, opts=0x56b15160, 
errp=0x0) at vl.c:2373
  #14 0x55cc3bb7 in qemu_opts_foreach (list=0x56548b80 
, func=0x55914283 , opaque=0x0, 
errp=0x0) at util/qemu-option.c:1116
  #15 0x559198aa in main (argc=12, argv=0x7fffe388, 
envp=0x7fffe3f0) at vl.c:4574

  as I can see, it happens during initialization of the device-option.

  seems that the code tries to loop over a memory-region mr, which is
  null from at least three calls before it crashes.

  because there seems to be special handling for nvidia-cards, here're the 
pci-infos of the card:
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 
7300 GS] [10de:01df] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device [1458:342a]
Flags: fast devsel, IRQ 16
Memory at de00 (32-bit, non-prefetchable) [disabled] [size=16M]
Memory at c000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at dd00 (64-bit, non-prefetchable) [disabled] [size=16M]
Expansion ROM at df00 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Kernel driver in use: vfio-pci

  at least with a similar card in another slot the crash does not occure.
  (sorry, can't change the slots at the moment)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1678466/+subscriptions

[Qemu-devel] [Bug 740895] Re: qemu freeze when loading msdos with EMM386.EXE NOEMS HIGHSCAN

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/740895

Title:
  qemu freeze when loading msdos with EMM386.EXE NOEMS HIGHSCAN

Status in QEMU:
  Expired

Bug description:
  Qemu version used : 0.11.2 and 0.14.0
  Guest : Ms-Dos 6.2
  Host : Ubuntu 10.04 with 2.6.32-29-generic SMP i686
  Starting Qemu with command : qemu -hda dos.img -cpu 486 -m 16

  When I start msDos under Qemu with the option (in CONFIG.SYS) 
  DEVICE=C:\DOS\EMM386.EXE NOEMS HIGHSCAN
  the guest freeze.
  If I remove "HIGHSCAN" system is booting (but my software is not working).

  The whole thing is working on a real computer with a 486 with 16Mb ram
  or a PII.

  "HIGHSCAN switch allows EMM386.EXE to map expanded memory pages or
  upper memory blocks (UMBs) over portions of the upper memory area
  (UMA) used by system read-only memory " from
  http://support.microsoft.com/kb/96522/en-us

  I add some traces inside "default_ioport_read" in ioport.c, but I
  don't see any access to F000h-F7FFh like said in ms help.

  Before the system hung, there is access to dma1, dma page register and
  dma2 :

  inb : 0087 00
  outb: 000c 00
  inb :  00
  inb :  00
  inb : 0001 00
  inb : 0001 00
  inb : 0083 00
  outb: 000c 00
  inb : 0002 00
  inb : 0002 00
  inb : 0003 00
  inb : 0003 00
  inb : 0081 00
  outb: 000c 00
  inb : 0004 00
  inb : 0004 00
  inb : 0005 00
  inb : 0005 00
  inb : 0082 00
  outb: 000c 00
  inb : 0006 00
  inb : 0006 00
  inb : 0007 00
  inb : 0007 00
  inb : 008b 00
  outb: 00d8 00
  inb : 00c4 00
  inb : 00c4 00
  inb : 00c6 00
  inb : 00c6 00
  inb : 0089 00
  outb: 00d8 00
  inb : 00c8 00
  inb : 00c8 00
  inb : 00ca 00
  inb : 00ca 00
  inb : 008a 00
  outb: 00d8 00
  inb : 00cc 00
  inb : 00cc 00
  inb : 00ce 00
  inb : 00ce 00
  outb: 000c 00
  outb: 00d8 00

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/740895/+subscriptions

[Qemu-devel] [Bug 1679358] [NEW] ARM: SCTLR fields not being preserved

[Yifan]

Public bug reported:

There are fields in SCTLR that are RAO/SBOP or WI or in the case of the
RR field, accessible only in secure mode. Currently it seems that qemu
just propagates any write to SCTLR to the register and this screwed up
in a bootloader that I am debugging.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1679358

Title:
  ARM: SCTLR fields not being preserved

Status in QEMU:
  New

Bug description:
  There are fields in SCTLR that are RAO/SBOP or WI or in the case of
  the RR field, accessible only in secure mode. Currently it seems that
  qemu just propagates any write to SCTLR to the register and this
  screwed up in a bootloader that I am debugging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1679358/+subscriptions

[Qemu-devel] [Bug 1678466] Re: using x-vga=on with vfio-pci leads to segfault

[Alex Williamson]

It's highly likely that a 7-series GeForce has a different BAR layout
than a modern card and should be considered unsupported.  Is the
"similar card in another slot" also a 7-series or older card?  Out of
curiosity, add another -v to the lspci output (lspci -vv) so that it
identifies which BARs are which.  A more modern card looks like this:

Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at f000 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at e000 [size=128]
Expansion ROM at f700 [disabled] [size=512K]

Thus the quirk should be triggered on the I/O port BAR, which your card
doesn't seem to have.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1678466

Title:
  using x-vga=on with vfio-pci leads to segfault

Status in QEMU:
  New

Bug description:
  bug occures at least with qemu 2.8.0 and 2.8.1 in 64bit-system

  stripped cmd for minimal config:
  qemu-system-i386 -m 2048 -M q35  -enable-kvm -nodefaults -nodefconfig -device 
ioh3420,bus=pcie.0,addr=0x9,multifunction=on,port=1,chassis=1,id=root.1 -device 
vfio-pci,host=01:00.0,bus=root.1,addr=01.0,x-vga=on

  Backtrace is:
  #0  0x557ca836 in memory_region_update_container_subregions 
(subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2030
  #1  0x557ca9dc in memory_region_add_subregion_common (mr=0x0, 
offset=8, subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2049
  #2  0x557caa9a in memory_region_add_subregion_overlap (mr=0x0, 
offset=8, subregion=0x5828f2f0, priority=1) at qemu-2.8.1/memory.c:2066
  #3  0x55832e48 in vfio_probe_nvidia_bar5_quirk (vdev=0x5805aef0, 
nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:689
  #4  0x55835433 in vfio_bar_quirk_setup (vdev=0x5805aef0, nr=5) at 
qemu-2.8.1/hw/vfio/pci-quirks.c:1652
  #5  0x5582f122 in vfio_realize (pdev=0x5805aef0, 
errp=0x7fffdc78) at qemu-2.8.1/hw/vfio/pci.c:2777
  #6  0x55a86195 in pci_qdev_realize (qdev=0x5805aef0, 
errp=0x7fffdcf0) at hw/pci/pci.c:1966
  #7  0x559be7b7 in device_set_realized (obj=0x5805aef0, 
value=true, errp=0x7fffdeb0) at hw/core/qdev.c:918
  #8  0x55bb017f in property_set_bool (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", opaque=0x57f15860, 
errp=0x7fffdeb0) at qom/object.c:1854
  #9  0x55bae2e6 in object_property_set (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1088
  #10 0x55bb184f in object_property_set_qobject (obj=0x5805aef0, 
value=0x5805cd70, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/qom-qobject.c:27
  #11 0x55bae637 in object_property_set_bool (obj=0x5805aef0, 
value=true, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1157
  #12 0x558fee4b in qdev_device_add (opts=0x56b15160, 
errp=0x7fffdf28) at qdev-monitor.c:623
  #13 0x559142c1 in device_init_func (opaque=0x0, opts=0x56b15160, 
errp=0x0) at vl.c:2373
  #14 0x55cc3bb7 in qemu_opts_foreach (list=0x56548b80 
, func=0x55914283 , opaque=0x0, 
errp=0x0) at util/qemu-option.c:1116
  #15 0x559198aa in main (argc=12, argv=0x7fffe388, 
envp=0x7fffe3f0) at vl.c:4574

  as I can see, it happens during initialization of the device-option.

  seems that the code tries to loop over a memory-region mr, which is
  null from at least three calls before it crashes.

  because there seems to be special handling for nvidia-cards, here're the 
pci-infos of the card:
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 
7300 GS] [10de:01df] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device [1458:342a]
Flags: fast devsel, IRQ 16
Memory at de00 (32-bit, non-prefetchable) [disabled] [size=16M]
Memory at c000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at dd00 (64-bit, non-prefetchable) [disabled] [size=16M]
Expansion ROM at df00 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Kernel driver in use: vfio-pci

  at least with a similar card in another slot the crash does not occure.
  (sorry, can't change the slots at the moment)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1678466/+subscriptions

[Qemu-devel] [PATCH v11 2/2] block/vxhs.c: Add qemu-iotests for new block device type "vxhs"

[Ashish Mittal]

These changes use a vxhs test server that is a part of the following
repository:
https://github.com/VeritasHyperScale/libqnio.git

Signed-off-by: Ashish Mittal 
Reviewed-by: Stefan Hajnoczi 
---
v11 changelog:
(1) No changes.

v10 changelog:
(1) Redirect o/p of "$QEMU_VXHS -d  $TEST_DIR" to /dev/null

v9 changelog:
(1) Dropped second argument to set_prog_path(). We will pick up the test
server location from the user's PATH env setting.

v8/v7 changelog:
(1) No changes.

v6 changelog:
(1) Added iotests for VxHS block device.

 tests/qemu-iotests/common|  6 ++
 tests/qemu-iotests/common.config | 13 +
 tests/qemu-iotests/common.filter |  1 +
 tests/qemu-iotests/common.rc | 19 +++
 4 files changed, 39 insertions(+)

diff --git a/tests/qemu-iotests/common b/tests/qemu-iotests/common
index 4d5650d..9c6f972 100644
--- a/tests/qemu-iotests/common
+++ b/tests/qemu-iotests/common
@@ -157,6 +157,7 @@ check options
 -sshtest ssh
 -nfstest nfs
 -luks   test luks
+-vxhs   test vxhs
 -xdiff  graphical mode diff
 -nocacheuse O_DIRECT on backing file
 -misalign   misalign memory allocations
@@ -260,6 +261,11 @@ testlist options
 xpand=false
 ;;
 
+-vxhs)
+IMGPROTO=vxhs
+xpand=false
+;;
+
 -ssh)
 IMGPROTO=ssh
 xpand=false
diff --git a/tests/qemu-iotests/common.config b/tests/qemu-iotests/common.config
index 55527aa..c4b51b3 100644
--- a/tests/qemu-iotests/common.config
+++ b/tests/qemu-iotests/common.config
@@ -105,6 +105,10 @@ if [ -z "$QEMU_NBD_PROG" ]; then
 export QEMU_NBD_PROG="`set_prog_path qemu-nbd`"
 fi
 
+if [ -z "$QEMU_VXHS_PROG" ]; then
+export QEMU_VXHS_PROG="`set_prog_path qnio_server`"
+fi
+
 _qemu_wrapper()
 {
 (
@@ -156,10 +160,19 @@ _qemu_nbd_wrapper()
 )
 }
 
+_qemu_vxhs_wrapper()
+{
+(
+echo $BASHPID > "${TEST_DIR}/qemu-vxhs.pid"
+exec "$QEMU_VXHS_PROG" $QEMU_VXHS_OPTIONS "$@"
+)
+}
+
 export QEMU=_qemu_wrapper
 export QEMU_IMG=_qemu_img_wrapper
 export QEMU_IO=_qemu_io_wrapper
 export QEMU_NBD=_qemu_nbd_wrapper
+export QEMU_VXHS=_qemu_vxhs_wrapper
 
 QEMU_IMG_EXTRA_ARGS=
 if [ "$IMGOPTSSYNTAX" = "true" ]; then
diff --git a/tests/qemu-iotests/common.filter b/tests/qemu-iotests/common.filter
index 1040013..c9a2d5c 100644
--- a/tests/qemu-iotests/common.filter
+++ b/tests/qemu-iotests/common.filter
@@ -122,6 +122,7 @@ _filter_img_info()
 -e "s#$TEST_DIR#TEST_DIR#g" \
 -e "s#$IMGFMT#IMGFMT#g" \
 -e 's#nbd://127.0.0.1:10810$#TEST_DIR/t.IMGFMT#g' \
+-e 's#json.*vdisk-id.*vxhs"}}#TEST_DIR/t.IMGFMT#' \
 -e "/encrypted: yes/d" \
 -e "/cluster_size: [0-9]\\+/d" \
 -e "/table_size: [0-9]\\+/d" \
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index 7d4781d..62529ee 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -85,6 +85,9 @@ else
 elif [ "$IMGPROTO" = "nfs" ]; then
 TEST_DIR="nfs://127.0.0.1/$TEST_DIR"
 TEST_IMG=$TEST_DIR/t.$IMGFMT
+elif [ "$IMGPROTO" = "vxhs" ]; then
+TEST_IMG_FILE=$TEST_DIR/t.$IMGFMT
+TEST_IMG="vxhs://127.0.0.1:/t.$IMGFMT"
 else
 TEST_IMG=$IMGPROTO:$TEST_DIR/t.$IMGFMT
 fi
@@ -171,6 +174,12 @@ _make_test_img()
 eval "$QEMU_NBD -v -t -b 127.0.0.1 -p 10810 -f $IMGFMT  $TEST_IMG_FILE 
>/dev/null &"
 sleep 1 # FIXME: qemu-nbd needs to be listening before we continue
 fi
+
+# Start QNIO server on image directory for vxhs protocol
+if [ $IMGPROTO = "vxhs" ]; then
+eval "$QEMU_VXHS -d  $TEST_DIR > /dev/null &"
+sleep 1 # Wait for server to come up.
+fi
 }
 
 _rm_test_img()
@@ -197,6 +206,16 @@ _cleanup_test_img()
 fi
 rm -f "$TEST_IMG_FILE"
 ;;
+vxhs)
+if [ -f "${TEST_DIR}/qemu-vxhs.pid" ]; then
+local QEMU_VXHS_PID
+read QEMU_VXHS_PID < "${TEST_DIR}/qemu-vxhs.pid"
+kill ${QEMU_VXHS_PID} >/dev/null 2>&1
+rm -f "${TEST_DIR}/qemu-vxhs.pid"
+fi
+rm -f "$TEST_IMG_FILE"
+;;
+
 file)
 _rm_test_img "$TEST_DIR/t.$IMGFMT"
 _rm_test_img "$TEST_DIR/t.$IMGFMT.orig"
-- 
2.5.5

[Qemu-devel] [PATCH v11 0/2] block/vxhs.c: Add support for a new block device type called "vxhs"

[Ashish Mittal]

- Veritas HyperScale block driver in QEMU is designed to provide an accelerated
  IO path from KVM virtual machines to Veritas HyperScale storage service.

- A network IO transfer library that translates block IO from HyperScale block
  driver to a network IO format to send it to Veritas HyperScale storage
  service. This library (libvxhs) has been open sourced and is available on
  github here:  https://github.com/VeritasHyperScale/libqnio.git

Ashish Mittal (2):
  block/vxhs.c: Add support for a new block device type called "vxhs"
  block/vxhs.c: Add qemu-iotests for new block device type "vxhs"

 block/Makefile.objs  |   2 +
 block/trace-events   |  17 ++
 block/vxhs.c | 575 +++
 configure|  39 +++
 qapi/block-core.json |  23 +-
 tests/qemu-iotests/common|   6 +
 tests/qemu-iotests/common.config |  13 +
 tests/qemu-iotests/common.filter |   1 +
 tests/qemu-iotests/common.rc |  19 ++
 9 files changed, 693 insertions(+), 2 deletions(-)
 create mode 100644 block/vxhs.c

-- 
2.5.5

[Qemu-devel] [PATCH v11 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

[Ashish Mittal]

Source code for the qnio library that this code loads can be downloaded from:
https://github.com/VeritasHyperScale/libqnio.git

Sample command line using JSON syntax:
./x86_64-softmmu/qemu-system-x86_64 -name instance-0008 -S -vnc 0.0.0.0:0
-k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
-msg timestamp=on
'json:{"driver":"vxhs","vdisk-id":"c3e9095a-a5ee-4dce-afeb-2a59fb387410",
"server":{"host":"172.172.17.4","port":""}}'

Sample command line using URI syntax:
qemu-img convert -f raw -O raw -n
/var/lib/nova/instances/_base/0c5eacd5ebea5ed914b6a3e7b18f1ce734c386ad
vxhs://192.168.0.1:/c6718f6b-0401-441d-a8c3-1f0064d75ee0

Sample command line using TLS credentials (run in secure mode):
./qemu-io --object
tls-creds-x509,id=tls0,dir=/etc/pki/qemu/vxhs,endpoint=client -c 'read
-v 66000 2.5k' 'json:{"server.host": "127.0.0.1", "server.port": "",
"vdisk-id": "/test.raw", "driver": "vxhs", "tls-creds":"tls0"}'

Signed-off-by: Ashish Mittal 
---
v11 changelog:
(1) Replaced InetSocketAddress with InetSocketAddressBase.
(2) Removed access to qemu_uuid.
(3) Removed unnecessary g_strdup()/g_free().
(4) Removed unused acb->qiov.
(5) Changed vxhs_init_and_ref() and vxhs_unref() per suggestion.
(6) Removed unnecessary initializations from local variables.

v10 changelog:
(1) Implemented accepting TLS creds per block device via the CLI
(see 3rd e.g in commit log). Corresponding changes made to the
libqnio library.
(2) iio_open() changed to accept TLS creds and use these internally
to set up SSL connections.
(3) Got rid of hard-coded VXHS_UUID_DEF. qemu_uuid is no longer used
for authentication in any way.
(4) Removed unnecessary qdict_del(backing_options, str).
(5) Added '*tls-creds' to BlockdevOptionsVxHS.

v9 changelog:
(1) Fixes for all the review comments from v8. I have left the definition
of VXHS_UUID_DEF unchanged pending a better suggestion.
(2) qcow2 tests now pass on the vxhs test server.
(3) Packaging changes for libvxhs will be checked in to the git repo soon.
(4) I have not moved extern QemuUUID qemu_uuid to a separate header file.

v8 changelog:
(1) Security implementation for libqnio present in branch 'securify'.
Please use 'securify' branch for building libqnio and testing
with this patch.
(2) Renamed libqnio to libvxhs.
(3) Pass instance ID to libvxhs for SSL authentication.

v7 changelog:
(1) IO failover code has moved out to the libqnio library.
(2) Fixes for issues reported by Stefan on v6.
(3) Incorporated the QEMUBH patch provided by Stefan.
This is a replacement for the pipe mechanism used earlier.
(4) Fixes to the buffer overflows reported in libqnio.
(5) Input validations in vxhs.c to prevent any buffer overflows for 
arguments passed to libqnio.

v6 changelog:
(1) Added qemu-iotests for VxHS as a new patch in the series.
(2) Replaced release version from 2.8 to 2.9 in block-core.json.

v5 changelog:
(1) Incorporated v4 review comments.

v4 changelog:
(1) Incorporated v3 review comments on QAPI changes.
(2) Added refcounting for device open/close.
Free library resources on last device close.

v3 changelog:
(1) Added QAPI schema for the VxHS driver.

v2 changelog:
(1) Changes done in response to v1 comments.

 block/Makefile.objs  |   2 +
 block/trace-events   |  17 ++
 block/vxhs.c | 575 +++
 configure|  39 
 qapi/block-core.json |  23 ++-
 5 files changed, 654 insertions(+), 2 deletions(-)
 create mode 100644 block/vxhs.c

diff --git a/block/Makefile.objs b/block/Makefile.objs
index de96f8e..ea95530 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -19,6 +19,7 @@ block-obj-$(CONFIG_LIBNFS) += nfs.o
 block-obj-$(CONFIG_CURL) += curl.o
 block-obj-$(CONFIG_RBD) += rbd.o
 block-obj-$(CONFIG_GLUSTERFS) += gluster.o
+block-obj-$(CONFIG_VXHS) += vxhs.o
 block-obj-$(CONFIG_LIBSSH2) += ssh.o
 block-obj-y += accounting.o dirty-bitmap.o
 block-obj-y += write-threshold.o
@@ -38,6 +39,7 @@ rbd.o-cflags   := $(RBD_CFLAGS)
 rbd.o-libs := $(RBD_LIBS)
 gluster.o-cflags   := $(GLUSTERFS_CFLAGS)
 gluster.o-libs := $(GLUSTERFS_LIBS)
+vxhs.o-libs:= $(VXHS_LIBS)
 ssh.o-cflags   := $(LIBSSH2_CFLAGS)
 ssh.o-libs := $(LIBSSH2_LIBS)
 block-obj-$(if $(CONFIG_BZIP2),m,n) += dmg-bz2.o
diff --git a/block/trace-events b/block/trace-events
index 0bc5c0a..7758ec3 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -110,3 +110,20 @@ qed_aio_write_data(void *s, void *acb, int ret, uint64_t 
offset, size_t len) "s
 qed_aio_write_prefill(void *s, void *acb, uint64_t start, size_t len, uint64_t 
offset) "s %p acb %p start %"PRIu64" len %zu offset %"PRIu64
 qed_aio_write_postfill(void *s, void *acb, uint64_t start, size_t len, 
uint64_t offset) "s %p acb %p start %"PRIu64" len %zu offset %"PRIu64
 qed_aio_write_main(void *s, void *acb, int ret, uint64_t offset, size_t len) 
"s %p acb %p ret %d offset %"PRIu64" len %zu"
+
+# b

Re: [Qemu-devel] [PATCH v1 2/3] applesmc: consolidate port i/o into single contiguous region

[Gabriel L. Somlo]

On Mon, Apr 03, 2017 at 12:27:15PM +0200, Paolo Bonzini wrote:
> 
> 
> On 03/04/2017 11:32, Alexander Graf wrote:
> > 
> >> Newer AppleSMC revisions support an error status (read) port
> >> in addition to the data and command ports currently supported.
> >>
> >> Register the full 32-bit region at once, and handle individual
> >> ports at various offsets within the region from the top-level
> >> applesmc_io_[write|read]() methods (ctual support for reading
> >> the error status port to be added by a subsequent patch).
> >>
> >> Originally proposed by Eric Shelton 
> >>
> >> Signed-off-by: Gabriel Somlo 
> > 
> > I would prefer if we could leave the multiplexing to the layer that
> > knows how to do that the best: Memory Regions.
> > 
> > Why don't you just define a big region that ecompasses all of the IO
> > space (with fallback I/O handlers for warnings) and then just sprinkle
> > the ones we handle on top with higher prio?
> 
> You don't need priority at all, "contained" regions always win over the
> container (docs/memory.txt just before "Region names").
> 
> Both what you propose and what Gabriel did makes sense.  In general QEMU
> does things more like in this patch, but there are exceptions (e.g. ACPI).

So, option 1 would be:

Leave the region covering the entire AppleSMC port range (APPLESMC_NUM_PORTS)
as-is:

static const MemoryRegionOps applesmc_io_ops = {
.write = applesmc_io_write,
.read = applesmc_io_read,
.endianness = DEVICE_NATIVE_ENDIAN,
.impl = {
.min_access_size = 1,
.max_access_size = 1,
},
};

but modify applesmc_io_write() and applesmc_io_read() to do nothing or
return 0xff, respectively. Then, add three separate regions covering 1
byte, for each of the three ports, with their own methods pointing at
the existing port-specific read/write methods.


Option 2 would be to leave everything as-is, per Paolo's suggestion
that it's the more common way of doing things. I personally find this
one easier to follow, but really don't mind doing either.


If I end up going with #1, I'd probably be bringing back
applesmc_data_io_ops and applesmc_cmd_io_ops, in which case I'd like
to know why the access size was set to 4 bytes to begin with:

-memory_region_init_io(&s->io_data, OBJECT(s), &applesmc_data_io_ops, s,
-  "applesmc-data", 4);
-isa_register_ioport(&s->parent_obj, &s->io_data,
-s->iobase + APPLESMC_DATA_PORT);
-
-memory_region_init_io(&s->io_cmd, OBJECT(s), &applesmc_cmd_io_ops, s,
-  "applesmc-cmd", 4);
-isa_register_ioport(&s->parent_obj, &s->io_cmd,
-s->iobase + APPLESMC_CMD_PORT);

Each port is 8-bits wide only, so why 4 and not 1, above ?

I guess that doesn't matter if we stick with option #2... :)

Any further advice on which way to go much appreciated!

Thanks,
--Gabriel

[Qemu-devel] [PATCH v3 1/1] slirp: add SOCKS5 support

[Laurent Vivier]

When the VM is used behind a firewall, This allows
the use of a SOCKS5 proxy server to connect the VM IP stack
directly to the Internet.

This implementation doesn't manage UDP packets, so they
are simply dropped (as with restrict=on), except for
the localhost as we need it for DNS.

Signed-off-by: Laurent Vivier 
---
 net/slirp.c |  39 ++-
 qapi-schema.json|   9 ++
 qemu-options.hx |  11 ++
 slirp/Makefile.objs |   2 +-
 slirp/ip_icmp.c |   2 +-
 slirp/libslirp.h|   3 +
 slirp/slirp.c   |  68 ++-
 slirp/slirp.h   |   6 +
 slirp/socket.h  |   4 +
 slirp/socks5.c  | 328 
 slirp/socks5.h  |  24 
 slirp/tcp_subr.c|  22 +++-
 slirp/udp.c |   9 ++
 slirp/udp6.c|   8 ++
 14 files changed, 524 insertions(+), 11 deletions(-)
 create mode 100644 slirp/socks5.c
 create mode 100644 slirp/socks5.h

diff --git a/net/slirp.c b/net/slirp.c
index f97ec23..8a5dc3f 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -41,6 +41,7 @@
 #include "sysemu/sysemu.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "crypto/secret.h"
 
 static int get_str_sep(char *buf, int buf_size, const char **pp, int sep)
 {
@@ -139,6 +140,33 @@ static void net_slirp_cleanup(NetClientState *nc)
 QTAILQ_REMOVE(&slirp_stacks, s, entry);
 }
 
+static int net_slirp_add_proxy(SlirpState *s, const char *proxy_server,
+   const char *proxy_user,
+   const char *proxy_secretid)
+{
+InetSocketAddress *addr;
+char *password = NULL;
+int ret;
+
+if (proxy_server == NULL) {
+return 0;
+}
+
+if (proxy_secretid) {
+password = qcrypto_secret_lookup_as_utf8(proxy_secretid, &error_fatal);
+}
+
+addr = inet_parse(proxy_server, &error_fatal);
+
+ret = slirp_add_proxy(s->slirp, addr->host, atoi(addr->port),
+  proxy_user, password);
+
+qapi_free_InetSocketAddress(addr);
+g_free(password);
+
+return ret;
+}
+
 static NetClientInfo net_slirp_info = {
 .type = NET_CLIENT_DRIVER_USER,
 .size = sizeof(SlirpState),
@@ -155,7 +183,8 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
   const char *bootfile, const char *vdhcp_start,
   const char *vnameserver, const char *vnameserver6,
   const char *smb_export, const char *vsmbserver,
-  const char **dnssearch)
+  const char **dnssearch, const char *proxy_server,
+  const char *proxy_user, const char *proxy_secretid)
 {
 /* default settings according to historic slirp */
 struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -361,6 +390,11 @@ static int net_slirp_init(NetClientState *peer, const char 
*model,
 }
 #endif
 
+if (net_slirp_add_proxy(s, proxy_server,
+proxy_user, proxy_secretid) < 0) {
+goto error;
+}
+
 s->exit_notifier.notify = slirp_smb_exit;
 qemu_add_exit_notifier(&s->exit_notifier);
 return 0;
@@ -878,7 +912,8 @@ int net_init_slirp(const Netdev *netdev, const char *name,
  user->ipv6_host, user->hostname, user->tftp,
  user->bootfile, user->dhcpstart,
  user->dns, user->ipv6_dns, user->smb,
- user->smbserver, dnssearch);
+ user->smbserver, dnssearch, user->proxy_server,
+ user->proxy_user, user->proxy_secretid);
 
 while (slirp_configs) {
 config = slirp_configs;
diff --git a/qapi-schema.json b/qapi-schema.json
index b921994..1799ae2 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3658,6 +3658,12 @@
 #
 # @guestfwd: forward guest TCP connections
 #
+# @proxy-server: address of the SOCKS5 proxy server to use (since 2.10)
+#
+# @proxy-user: username to use with the proxy server (since 2.10)
+#
+# @proxy-secretid: secret id to use for the proxy server password (since 2.10)
+#
 # Since: 1.2
 ##
 { 'struct': 'NetdevUserOptions',
@@ -3680,6 +3686,9 @@
 '*ipv6-dns': 'str',
 '*smb':   'str',
 '*smbserver': 'str',
+'*proxy-server': 'str',
+'*proxy-user':   'str',
+'*proxy-secretid': 'str',
 '*hostfwd':   ['String'],
 '*guestfwd':  ['String'] } }
 
diff --git a/qemu-options.hx b/qemu-options.hx
index 99af8ed..e625d1a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1645,6 +1645,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
 #ifndef _WIN32
  "[,smb=dir[,smbserver=addr]]\n"
 #endif
+" [,proxy-server=addr:port[,proxy-user=user,proxy-secretid=id]]\n"
 "configure a user mode network backend with ID 'str',\n"
 "its DHCP server and optional services\n"
 #endif
@@ -1883,6 +1884,16

[Qemu-devel] [PATCH v3 0/1] slirp: add SOCKS5 support

[Laurent Vivier]

This patch implements the SOCKS5 client part for "-net user" backend.

It allows to route all internet traffic of the virtual machine
to a SOCKS5 server.

But all the local traffic (to the host) is sent to the host.
It is needed because this SOCKS5 client doesn't route UDP traffic,
and this allows to use the host DNS server.

I've tested this using public SOCKS5 proxy list found on the WEB, and
using TOR server on my host.

Used with TOR, all the TCP connections are sent to the TOR network and
this allows to insert a virtual machine directly in the TOR network
without needing more configuration in the virtual machine.

But be aware that all DNS requests will be sent to the host that can
forward them to internet with its own IP address. So confidentiality
will not be as good as with the TOR browser which hides in the TOR
network all the DNS requests.

If you want to test this:

- with a public SOCKS5 server, ask google for "socks5 proxy address"
  and start QEMU with, for instance:

  qemu-system-x86_64 -net nic,model=e1000 -net 
user,proxy-server=46.105.121.37:63066 ...

  if needed, you can provide user/password using secret objects framework:
  "-object secret,id=sec0,data=password,format=raw \
   -net user,...,proxy-user=user,proxy-secretid=sec0"

- with a local TOR proxy:

  sudo systemctl start tor
  qemu-system-x86_64 -net nic,model=e1000 -net user,proxy-server=localhost:9050 
...

You can check your IP address is the one of the proxy by connecting
to http://check.torproject.org with a browser inside the VM.

v3:
  - rewrite SOCKS5 functions from scratch and drop code from nmap/ncat
  - don't drop the IPv6 UDP local traffic
  - don't pass to the proxy the IPv6 TCP local traffic
  - add some comments...

v2:
  - use secret objects framework to provide password
  - add documentation for new parameters in qapi-schema.json
  - s/passwd/password/g
  - I didn't move proxy paramaters to a substruct as I didn't
find a way to set them from the command line :(

Laurent Vivier (1):
  slirp: add SOCKS5 support

 net/slirp.c |  39 ++-
 qapi-schema.json|   9 ++
 qemu-options.hx |  11 ++
 slirp/Makefile.objs |   2 +-
 slirp/ip_icmp.c |   2 +-
 slirp/libslirp.h|   3 +
 slirp/slirp.c   |  68 ++-
 slirp/slirp.h   |   6 +
 slirp/socket.h  |   4 +
 slirp/socks5.c  | 328 
 slirp/socks5.h  |  24 
 slirp/tcp_subr.c|  22 +++-
 slirp/udp.c |   9 ++
 slirp/udp6.c|   8 ++
 14 files changed, 524 insertions(+), 11 deletions(-)
 create mode 100644 slirp/socks5.c
 create mode 100644 slirp/socks5.h

-- 
2.9.3

[Qemu-devel] [Bug 1678466] Re: using x-vga=on with vfio-pci leads to segfault

[sh-dvl]

well but even if it's unsupported it shouldn't segfault...

the other card is nearly the same
this one is a GeForce 7300 GS, the other a GeForce 7300 GT

I think, the above output was done with "lspci -vv", but I've do it again:
lspci -vv for the "bad card" is:

01:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 GS] 
(rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device 342a
Flags: fast devsel, IRQ 16
Memory at de00 (32-bit, non-prefetchable) [disabled] [size=16M]
Memory at c000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at dd00 (64-bit, non-prefetchable) [disabled] [size=16M]
Expansion ROM at df00 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Kernel driver in use: vfio-pci


and for the "good" card:
07:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7300 GT] 
(rev a1) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology Device 1401
Flags: fast devsel, IRQ 16
Memory at db00 (32-bit, non-prefetchable) [disabled] [size=16M]
Memory at b000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at da00 (64-bit, non-prefetchable) [disabled] [size=16M]
I/O ports at e000 [disabled] [size=128]
Expansion ROM at dc00 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Kernel driver in use: vfio-pci

your're right that the I/O-Port is not shown for the "bad" card, even I
don't know why. Maybe because the card's bios-routine saw the other or
vice versa.

nevertheless, segfaults are not nice...

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1678466

Title:
  using x-vga=on with vfio-pci leads to segfault

Status in QEMU:
  New

Bug description:
  bug occures at least with qemu 2.8.0 and 2.8.1 in 64bit-system

  stripped cmd for minimal config:
  qemu-system-i386 -m 2048 -M q35  -enable-kvm -nodefaults -nodefconfig -device 
ioh3420,bus=pcie.0,addr=0x9,multifunction=on,port=1,chassis=1,id=root.1 -device 
vfio-pci,host=01:00.0,bus=root.1,addr=01.0,x-vga=on

  Backtrace is:
  #0  0x557ca836 in memory_region_update_container_subregions 
(subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2030
  #1  0x557ca9dc in memory_region_add_subregion_common (mr=0x0, 
offset=8, subregion=0x5828f2f0) at qemu-2.8.1/memory.c:2049
  #2  0x557caa9a in memory_region_add_subregion_overlap (mr=0x0, 
offset=8, subregion=0x5828f2f0, priority=1) at qemu-2.8.1/memory.c:2066
  #3  0x55832e48 in vfio_probe_nvidia_bar5_quirk (vdev=0x5805aef0, 
nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:689
  #4  0x55835433 in vfio_bar_quirk_setup (vdev=0x5805aef0, nr=5) at 
qemu-2.8.1/hw/vfio/pci-quirks.c:1652
  #5  0x5582f122 in vfio_realize (pdev=0x5805aef0, 
errp=0x7fffdc78) at qemu-2.8.1/hw/vfio/pci.c:2777
  #6  0x55a86195 in pci_qdev_realize (qdev=0x5805aef0, 
errp=0x7fffdcf0) at hw/pci/pci.c:1966
  #7  0x559be7b7 in device_set_realized (obj=0x5805aef0, 
value=true, errp=0x7fffdeb0) at hw/core/qdev.c:918
  #8  0x55bb017f in property_set_bool (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", opaque=0x57f15860, 
errp=0x7fffdeb0) at qom/object.c:1854
  #9  0x55bae2e6 in object_property_set (obj=0x5805aef0, 
v=0x5805ced0, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1088
  #10 0x55bb184f in object_property_set_qobject (obj=0x5805aef0, 
value=0x5805cd70, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/qom-qobject.c:27
  #11 0x55bae637 in object_property_set_bool (obj=0x5805aef0, 
value=true, name=0x56071b56 "realized", errp=0x7fffdeb0) at 
qom/object.c:1157
  #12 0x558fee4b in qdev_device_add (opts=0x56b15160, 
errp=0x7fffdf28) at qdev-monitor.c:623
  #13 0x559142c1 in device_init_func (opaque=0x0, opts=0x56b15160, 
errp=0x0) at vl.c:2373
  #14 0x55cc3bb7 in qemu_opts_foreach (list=0x56548b80 
, func=0x55914283 , opaque=0x0, 
errp=0x0) at util/qemu-option.c:1116
  #15 0x559198aa in main (argc=12, argv=0x7fffe388, 
envp=0x7fffe3f0) at vl.c:4574

  as I can see, it happens during initialization of the device-option.

  seems that the code tries to loop over a memory-region mr, which is
  null 

Re: [Qemu-devel] [PATCH v1 1/3] applesmc: cosmetic whitespace and indentation cleanup

[Philippe Mathieu-Daudé]

On 04/03/2017 06:12 PM, Gabriel L. Somlo wrote:

On Mon, Apr 03, 2017 at 10:34:09AM -0300, Philippe Mathieu-Daudé wrote:

Hi Gabriel,

On 03/31/2017 01:48 PM, Gabriel L. Somlo wrote:

Signed-off-by: Gabriel Somlo 
---
 hw/misc/applesmc.c | 100 +++--
 1 file changed, 51 insertions(+), 49 deletions(-)

diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
index 77fab5b..986f2ac 100644
--- a/hw/misc/applesmc.c
+++ b/hw/misc/applesmc.c
@@ -39,24 +39,27 @@
 /* #define DEBUG_SMC */

 #define APPLESMC_DEFAULT_IOBASE0x300
-/* data port used by Apple SMC */
-#define APPLESMC_DATA_PORT 0x0
-/* command/status port used by Apple SMC */
-#define APPLESMC_CMD_PORT  0x4
-#define APPLESMC_NR_PORTS  32

-#define APPLESMC_READ_CMD  0x10
-#define APPLESMC_WRITE_CMD 0x11
-#define APPLESMC_GET_KEY_BY_INDEX_CMD  0x12
-#define APPLESMC_GET_KEY_TYPE_CMD  0x13
+enum {
+APPLESMC_DATA_PORT   = 0x00,
+APPLESMC_CMD_PORT= 0x04,
+APPLESMC_NUM_PORTS   = 0x20,
+};
+
+enum {
+APPLESMC_READ_CMD= 0x10,
+APPLESMC_WRITE_CMD   = 0x11,
+APPLESMC_GET_KEY_BY_INDEX_CMD= 0x12,
+APPLESMC_GET_KEY_TYPE_CMD= 0x13,
+};

 #ifdef DEBUG_SMC
 #define smc_debug(...) fprintf(stderr, "AppleSMC: " __VA_ARGS__)
 #else
-#define smc_debug(...) do { } while(0)
+#define smc_debug(...) do { } while (0)
 #endif

-static char default_osk[64] = "This is a dummy key. Enter the real key "
+static char default_osk[65] = "This is a dummy key. Enter the real key "


Here is more than a cosmetic change.


You're right, that was my mistake (should have left it 64.


Since this array is initialized you can declare it without specify the size:
static char default_osk[] = ...


It's initialized to something that's not necessarily 64 characters, so
(I assume) the size specification is there to reserve the appropriate
amount of space, which is precisely 64 bytes.


Since 'default_osk' is used read-only, it could be 'const' but since it 
is assigned as `s->osk = default_osk` which is a PROP_STRING it can not 
be const. For this read-only reason I think it is safer to let the cpp 
calculate the size to allocate to this buffer (without specifying 64 
which lead to confusion).





OSK0 + OSK1 is 64, why need an extra byte?


Right, I undid that part of the patch, will resubmit everything minus
that hunk as part of v2.


Can yoy add some self-explanatory #define and use them later in this file:

applesmc_add_key(s, "OSK0", 32, s->osk);
applesmc_add_key(s, "OSK1", 32, s->osk + 32);

and

if (!s->osk || (strlen(s->osk) != 64)) {
fprintf(stderr, "WARNING: Using AppleSMC with invalid key\n");


Do I have to, now that I'm staying away from touching that bit in the
first place ? :)

The original patch Eric Shelton proposed (inspired by FakeSMC)
completely reworks how keys are initialized, adds write support (and
access permissions) for select keys, and generally implements a much
more complete emulation of the AppleSMC. Since this is just about
getting OS X to keep working, I figured I'd keep changes to a minimum.

Reworking key initialization, adding write support, etc. could
(should?) be part of a separate series, if we decide we want a more
realistically emulated AppleSMC. In that case, minimizing churn and
leaving things as-is in this particular case would be preferable.

Let me know what you think.


Let keep it simple enough for this serie :)

Either with the 64B array size back or without:
Reviewed-by: Philippe Mathieu-Daudé 



Thanks,
--Gabriel




   "using the -osk parameter";

 struct AppleSMCData {
@@ -77,12 +80,11 @@ struct AppleSMCState {
 uint32_t iobase;
 uint8_t cmd;
 uint8_t status;
-uint8_t key[4];
+char key[4];
 uint8_t read_pos;
 uint8_t data_len;
 uint8_t data_pos;
 uint8_t data[255];
-uint8_t charactic[4];
 char *osk;
 QLIST_HEAD(, AppleSMCData) data_def;
 };
@@ -93,10 +95,10 @@ static void applesmc_io_cmd_write(void *opaque, hwaddr 
addr, uint64_t val,
 AppleSMCState *s = opaque;

 smc_debug("CMD Write B: %#x = %#x\n", addr, val);
-switch(val) {
-case APPLESMC_READ_CMD:
-s->status = 0x0c;
-break;
+switch (val) {
+case APPLESMC_READ_CMD:
+s->status = 0x0c;
+break;
 }
 s->cmd = val;
 s->read_pos = 0;
@@ -123,54 +125,54 @@ static void applesmc_io_data_write(void *opaque, hwaddr 
addr, uint64_t val,
 AppleSMCState *s = opaque;

 smc_debug("DATA Write B: %#x = %#x\n", addr, val);
-switch(s->cmd) {
-case APPLESMC_READ_CMD:
-if(s->read_pos < 4) {
-s->key[s->read_pos] = val;
-s->status = 0x04;
-} else if(s->read_pos == 4) {
-s->data_len = val;
-s->status = 0x05;
-  

Re: [Qemu-devel] [PATCH v1 1/3] applesmc: cosmetic whitespace and indentation cleanup

[Gabriel L. Somlo]

On Mon, Apr 03, 2017 at 10:34:09AM -0300, Philippe Mathieu-Daudé wrote:
> Hi Gabriel,
> 
> On 03/31/2017 01:48 PM, Gabriel L. Somlo wrote:
> > Signed-off-by: Gabriel Somlo 
> > ---
> >  hw/misc/applesmc.c | 100 
> > +++--
> >  1 file changed, 51 insertions(+), 49 deletions(-)
> > 
> > diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
> > index 77fab5b..986f2ac 100644
> > --- a/hw/misc/applesmc.c
> > +++ b/hw/misc/applesmc.c
> > @@ -39,24 +39,27 @@
> >  /* #define DEBUG_SMC */
> > 
> >  #define APPLESMC_DEFAULT_IOBASE0x300
> > -/* data port used by Apple SMC */
> > -#define APPLESMC_DATA_PORT 0x0
> > -/* command/status port used by Apple SMC */
> > -#define APPLESMC_CMD_PORT  0x4
> > -#define APPLESMC_NR_PORTS  32
> > 
> > -#define APPLESMC_READ_CMD  0x10
> > -#define APPLESMC_WRITE_CMD 0x11
> > -#define APPLESMC_GET_KEY_BY_INDEX_CMD  0x12
> > -#define APPLESMC_GET_KEY_TYPE_CMD  0x13
> > +enum {
> > +APPLESMC_DATA_PORT   = 0x00,
> > +APPLESMC_CMD_PORT= 0x04,
> > +APPLESMC_NUM_PORTS   = 0x20,
> > +};
> > +
> > +enum {
> > +APPLESMC_READ_CMD= 0x10,
> > +APPLESMC_WRITE_CMD   = 0x11,
> > +APPLESMC_GET_KEY_BY_INDEX_CMD= 0x12,
> > +APPLESMC_GET_KEY_TYPE_CMD= 0x13,
> > +};
> > 
> >  #ifdef DEBUG_SMC
> >  #define smc_debug(...) fprintf(stderr, "AppleSMC: " __VA_ARGS__)
> >  #else
> > -#define smc_debug(...) do { } while(0)
> > +#define smc_debug(...) do { } while (0)
> >  #endif
> > 
> > -static char default_osk[64] = "This is a dummy key. Enter the real key "
> > +static char default_osk[65] = "This is a dummy key. Enter the real key "
> 
> Here is more than a cosmetic change.

You're right, that was my mistake (should have left it 64.
> 
> Since this array is initialized you can declare it without specify the size:
> static char default_osk[] = ...

It's initialized to something that's not necessarily 64 characters, so
(I assume) the size specification is there to reserve the appropriate
amount of space, which is precisely 64 bytes.

> OSK0 + OSK1 is 64, why need an extra byte?

Right, I undid that part of the patch, will resubmit everything minus
that hunk as part of v2.

> Can yoy add some self-explanatory #define and use them later in this file:
> 
> applesmc_add_key(s, "OSK0", 32, s->osk);
> applesmc_add_key(s, "OSK1", 32, s->osk + 32);
> 
> and
> 
> if (!s->osk || (strlen(s->osk) != 64)) {
> fprintf(stderr, "WARNING: Using AppleSMC with invalid key\n");

Do I have to, now that I'm staying away from touching that bit in the
first place ? :)

The original patch Eric Shelton proposed (inspired by FakeSMC)
completely reworks how keys are initialized, adds write support (and
access permissions) for select keys, and generally implements a much
more complete emulation of the AppleSMC. Since this is just about
getting OS X to keep working, I figured I'd keep changes to a minimum.

Reworking key initialization, adding write support, etc. could
(should?) be part of a separate series, if we decide we want a more
realistically emulated AppleSMC. In that case, minimizing churn and
leaving things as-is in this particular case would be preferable.

Let me know what you think.

Thanks,
--Gabriel
 
> 
> >"using the -osk parameter";
> > 
> >  struct AppleSMCData {
> > @@ -77,12 +80,11 @@ struct AppleSMCState {
> >  uint32_t iobase;
> >  uint8_t cmd;
> >  uint8_t status;
> > -uint8_t key[4];
> > +char key[4];
> >  uint8_t read_pos;
> >  uint8_t data_len;
> >  uint8_t data_pos;
> >  uint8_t data[255];
> > -uint8_t charactic[4];
> >  char *osk;
> >  QLIST_HEAD(, AppleSMCData) data_def;
> >  };
> > @@ -93,10 +95,10 @@ static void applesmc_io_cmd_write(void *opaque, hwaddr 
> > addr, uint64_t val,
> >  AppleSMCState *s = opaque;
> > 
> >  smc_debug("CMD Write B: %#x = %#x\n", addr, val);
> > -switch(val) {
> > -case APPLESMC_READ_CMD:
> > -s->status = 0x0c;
> > -break;
> > +switch (val) {
> > +case APPLESMC_READ_CMD:
> > +s->status = 0x0c;
> > +break;
> >  }
> >  s->cmd = val;
> >  s->read_pos = 0;
> > @@ -123,54 +125,54 @@ static void applesmc_io_data_write(void *opaque, 
> > hwaddr addr, uint64_t val,
> >  AppleSMCState *s = opaque;
> > 
> >  smc_debug("DATA Write B: %#x = %#x\n", addr, val);
> > -switch(s->cmd) {
> > -case APPLESMC_READ_CMD:
> > -if(s->read_pos < 4) {
> > -s->key[s->read_pos] = val;
> > -s->status = 0x04;
> > -} else if(s->read_pos == 4) {
> > -s->data_len = val;
> > -s->status = 0x05;
> > -s->data_pos = 0;
> > -smc_debug("Key = %c%c%c%c Len = %d\n", s->key[0],
> > -

Re: [Qemu-devel] [PATCH v10 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

[ashish mittal]

On Mon, Apr 3, 2017 at 8:11 AM, Stefan Hajnoczi  wrote:
> On Fri, Mar 31, 2017 at 11:25:02AM -0700, ashish mittal wrote:
>> On Mon, Mar 27, 2017 at 6:04 PM, ashish mittal  wrote:
>> > On Mon, Mar 27, 2017 at 10:27 AM, Stefan Hajnoczi  
>> > wrote:
>> >> On Sun, Mar 26, 2017 at 07:50:35PM -0700, Ashish Mittal wrote:
>> >>
>> >> Have you tested live migration?
>> >>
>> >> If live migration is not supported then a migration blocker should be
>> >> added using migrate_add_blocker().
>> >>
>> >
>> > We do support live migration. We have been testing a fork of this code
>> > (slightly different version) with live migration.
>
> The reason I ask is because this patch doesn't implement the
> BlockDriver bdrv_invalidate_cache()/bdrv_inactivate() callbacks.  These
> functions are invoked during live migration so that the block driver can
> ensure data consistency.
>
> Since the destination QEMU process is launched while the source QEMU is
> still running and making changes to the disk, some block drivers need to
> discard metadata at migration handover time that was read upon opening
> the image on the destination.  The guarantees that they see the latest
> metadata.
>

Thanks! During live migration, we point the vdisks to the same host as
the migration source (specified on the vxhs command line), thereby
insuring consistent view of data.

> Not sure if libvxhs caches anything that might get stale during live
> migration, but I wanted to raise this question?
>
> Regarding a fork of this code that you haven't posted to the mailing
> list, it doesn't exist as far as anyone here is concerned :).  Therefore
> either the code on the mailing list needs to support migration or it
> must register a migration blocker to prevent migration.
>

The code on the mailing list does support live migration. Live
migration requires the support of proprietary vxhs bits and also our
orchestration code within OpenStack. We have been testing live
migration and it works without any data consistency issues.

>> >>> +static BlockDriver bdrv_vxhs = {
>> >>> +.format_name  = "vxhs",
>> >>> +.protocol_name= "vxhs",
>> >>> +.instance_size= sizeof(BDRVVXHSState),
>> >>> +.bdrv_file_open   = vxhs_open,
>> >>> +.bdrv_parse_filename  = vxhs_parse_filename,
>> >>> +.bdrv_close   = vxhs_close,
>> >>> +.bdrv_getlength   = vxhs_getlength,
>> >>> +.bdrv_aio_readv   = vxhs_aio_readv,
>> >>> +.bdrv_aio_writev  = vxhs_aio_writev,
>> >>
>> >> Missing .bdrv_aio_flush().  Does VxHS promise that every completed write
>> >> request is persistent?
>> >>
>> >
>> > Yes, every acknowledged write request is persistent.
>> >
>> >> In that case it may be better to disable the emulated disk write cache
>> >> so the guest operating system and application know not to send flush
>> >> commands.
>> >
>> > We do pass "cache=none" on the qemu command line for every block
>> > device. Are there any other code changes necessary? Any pointers will
>> > help.
>> >
>>
>> Upon further reading, I now understand that cache=none will not
>> disable the emulated disk write cache. I am trying to understand if -
>> (1) It should still not be a problem since flush will just be a no-op for us.
>
> The guest operating system and applications may take different code
> paths depending on the state of the disk write cache.
>
> Useless vmexits can be eliminated if the guest doesn't need to send
> flush commands.  Hence the file system and applications may perform
> better.
>
>> (2) Is there a way, or reason, to disable the emulated disk write
>> cache in the code for vxhs? I think passing WCE=0 to the guest has
>> something to do with this, although I have yet to figure out what that
>> means.
>
> Right, WCE == "Write Cache Enable".  If you disable the write cache then
> the guest's SCSI disk or virtio-blk drivers will notice that the disk
> does not require flush commands.
>
> Try launching a guest with -drive if=none,id=drive0,cache=directsync,...
> and you should see that the write cache is disabled:
>
>   # cat /sys/block/vda/queue/write_cache
>

Thanks! Will try this. As you mentioned, this might give us a slightly
better performance as it will avoid unnecessary flush from the guest
OS/app. I was wondering if there was a separate command line option
(other than cache=directsync) for passing WCE=0? Reading some of the
articles out there almost suggested as if there was! Maybe I was just
confused.

>> (3) Is this a must for merge?
>
> This doesn't affect the block driver code so no change is necessary.

Re: [Qemu-devel] MTD timeout on bootup

[Alistair Francis]

> -Original Message-
> From: James Hanley [mailto:jhan...@dgtlrift.com]
> Sent: Friday, 31 March 2017 8:29 AM
> To: Alistair Francis ; Peter Crosthwaite
> ; qemu-devel 
> Subject: MTD timeout on bootup
>
> When trying to bootup a pristine zync image from the zc702 tarball, it would 
> always
> fail with the MTD detection of the serial flash device type command over the 
> SPI.  I
> believe this section of code may have the logic flipped.  Once I changed it 
> to the
> following, I was able to detect the flash type when booting the pristine 
> image from
> Xilinx.

Hey Jim,

First off, thanks for the patch.

In the future do you mind following the guidelines here:
http://wiki.qemu-project.org/Contribute/SubmitAPatch

If you use git format-patch and git send-email to generate the patch and send 
the result
to the mailing list it is much easier for people to review and apply.

Looking at the Xilinx Zynq-700 TRM (page 1754) I see that the Man_start_com bit
specifies to manually start the transmission of data, so it looks like the 
logic already in
the QEMU model is correct. What issue are you seeing that this fixes? Maybe the 
logic
somewhere else is incorrect.

PS: Sorry about the footer, I had to reply from my corporate email account.

Thanks,

Alistair

> -Jim
>
>
> From bcca370c13526fd2b8c7b33c7d9e8a6d7b8d Mon Sep 17 00:00:00 2001
> From: Jim Hanley 
> Date: Thu, 23 Mar 2017 10:29:34 -0400
> Subject: [PATCH] MTD writes from the SPI were never being dequeue...
> Signed-off-by:
>
> ---
>  hw/ssi/xilinx_spips.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
> index da8adfa..a3af1f7 100644
> --- a/hw/ssi/xilinx_spips.c
> +++ b/hw/ssi/xilinx_spips.c
> @@ -482,8 +482,8 @@ static void xilinx_spips_write(void *opaque, hwaddr addr,
>  s->regs[addr] = (s->regs[addr] & ~mask) | (value & mask);
>  no_reg_update:
>  xilinx_spips_update_cs_lines(s);
> -if ((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> -(fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] & 
> MAN_START_EN)) {
> +if (!((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> +(fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] & 
> MAN_START_EN))) {
>  xilinx_spips_flush_txfifo(s);
>  }
>  xilinx_spips_update_cs_lines(s);
> --
> 2.7.4



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Eduardo Habkost]

On Mon, Apr 03, 2017 at 10:15:44PM +0200, Alexander Graf wrote:
> 
> 
> On 03.04.17 22:10, Eduardo Habkost wrote:
> > On Mon, Apr 03, 2017 at 08:49:16PM +0100, Peter Maydell wrote:
> > > On 1 April 2017 at 01:46, Eduardo Habkost  wrote:
> > > > commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
> > > > cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
> > > > all kinds of untested devices available to -device and
> > > > device_add.
> > > > 
> > > > The problem with that is: setting has_dynamic_sysbus on a
> > > > machine-type lets it accept all the 288 sysbus device types we
> > > > have in QEMU, and most of them were never meant to be used with
> > > > -device. That's a lot of untested code.
> > > > 
> > > > Fortunately today we have just a few has_dynamic_sysbus=1
> > > > machines: virt, pc-q35-*, ppce500, and spapr.
> > > > 
> > > > virt, ppce500, and spapr have extra checks to ensure just a few
> > > > device types can be instantiated:
> > > > 
> > > > * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
> > > > * ppce500 supports only TYPE_ETSEC_COMMON.
> > > > * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.
> > > > 
> > > > q35 has no code to block unsupported sysbus devices, however, and
> > > > accepts all device types. Fortunately, only the following 20
> > > > device types are compiled into the qemu-system-x86_64 and
> > > > qemu-system-i386 binaries:
> > > > 
> > > > * allwinner-ahci
> > > > * amd-iommu
> > > > * cfi.pflash01
> > > > * esp
> > > > * fw_cfg_io
> > > > * fw_cfg_mem
> > > > * generic-sdhci
> > > > * hpet
> > > > * intel-iommu
> > > > * ioapic
> > > > * isabus-bridge
> > > > * kvmclock
> > > > * kvm-ioapic
> > > > * kvmvapic
> > > > * SUNW,fdtwo
> > > > * sysbus-ahci
> > > > * sysbus-fdc
> > > > * sysbus-ohci
> > > > * unimplemented-device
> > > > * virtio-mmio
> > > > 
> > > > Instead of requiring each machine-type with has_dynamic_sysbus=1
> > > > to implement its own mechanism to block unsupported devices, we
> > > > can use the user_creatable flag to ensure we won't let the user
> > > > plug anything that will never work.
> > > 
> > > How does this work? Which devices can be dynamically
> > > plugged is machine dependent. You can't dynamically-plug
> > > an intel-iommu on the ARM virt board, and you can't
> > > dynamically-plug the vfio-calxeda-xgmac on the spapr
> > > board, and so on. So I don't see how we can just have
> > > a flag on the device itself that controls whether
> > > it can be dynamically plugged.
> > > 
> > > So I'm definitely coming around to the opinion that
> > > it's just a bug in the q35 board that it doesn't have
> > > any device whitelisting, and we should fix that.
> > 
> > OK, let's assume q35 must implement a whitelist:
> > 
> > To build that whitelist, we need to be able to know what should
> > be in the whitelist, or not. And nobody knew for sure what was
> > user-creatable in q35 by accident, and what was really supposed
> > to be user-creatable in q35. See the "q35 and sysbus devices"
> > thread I started ~2 weeks ago.
> > 
> > Building a q35 whitelist will be much easier if make
> > sys-bus-devices non-user-creatable by default.
> 
> So why are they user creatable in the first place?
> 
> We used to have boards that were dynamic sysbus aware (ppce500, virt) that
> allowed dynamic creation and every other board did not. I don't remember the
> exact mechanism behind it though.
> 
> When did that behavior change? It sounds like a regression somewhere.

See patch description:

> > > > commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
> > > > cannot_instantiate_with_device_add_yet in TYPE_SYSBUS,

Note that the commit above is not a regression[1] (because q35
didn't have has_dynamic_sysbus=1 yet), but having sysbus devices
have cannot_instantiate_with_device_add_yet=false/user_creatable=true
by default makes it harder to build the whitelist for q35 (or
other machines that will have has_dynamic_sysbus=1 in the
future).

[1] Well, it was a regression on the "info qdm" HMP command
output, which is a minor bug. But it's still a bug we still
want to fix anyway.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 01/51] ram: Update all functions comments

[Juan Quintela]

"Dr. David Alan Gilbert"  wrote:
> * Peter Xu (pet...@redhat.com) wrote:
>> Hi, Juan,
>> 
>> Got several nitpicks below... (along with some questions)
>> 
>> On Thu, Mar 23, 2017 at 09:44:54PM +0100, Juan Quintela wrote:
>> 
>> [...]
>
>> > @@ -1157,11 +1186,12 @@ static bool get_queued_page(MigrationState
>> > *ms, PageSearchStatus *pss,
>> >  }
>> >  
>> >  /**
>> > - * flush_page_queue: Flush any remaining pages in the ram request queue
>> > - *it should be empty at the end anyway, but in error cases there may 
>> > be
>> > - *some left.
>> > + * flush_page_queue: flush any remaining pages in the ram request queue
>> 
>> Here the comment says (just like mentioned in function name) that we
>> will "flush any remaining pages in the ram request queue", however in
>> the implementation, we should be only freeing everything in
>> src_page_requests. The problem is "flush" let me think about "flushing
>> the rest of the pages to the other side"... while it's not.
>> 
>> Would it be nice we just rename the function into something else, like
>> migration_page_queue_free()? We can tune the comments correspondingly
>> as well.
>
> Yes that probably would be a better name.

done
>> > - * Allocate data structures etc needed by incoming migration with 
>> > postcopy-ram
>> > - * postcopy-ram's similarly names postcopy_ram_incoming_init does the work
>> > +/**
>> > + * ram_postococpy_incoming_init: allocate postcopy data structures
>> > + *
>> > + * Returns 0 for success and negative if there was one error
>> > + *
>> > + * @mis: current migration incoming state
>> > + *
>> > + * Allocate data structures etc needed by incoming migration with
>> > + * postcopy-ram postcopy-ram's similarly names
>> > + * postcopy_ram_incoming_init does the work
>> 
>> This sentence is slightly hard to understand... But I think the
>> function name explained itself enough though. :)
>
> A '.' after the first 'postcopy-ram' would make it more readable.
>
> Dave

Done.  Once there, I spelled postcopy correctly O:-)

Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable

[Eric Blake]

On 04/03/2017 03:29 PM, John Snow wrote:
> 
> 
> On 03/24/2017 08:34 AM, Kashyap Chamarthy wrote:
>> While debugging some other issue, I happened to stumble across an old
>> libvirt commit[*] that adds support for pivot (whether QEMU should
>> switch to a target copy or not) operation as a result of issuing QMP
>> 'block-job-cancel' to a 'drive-mirror' (in libvirt parlance, "block
>> copy").
>>
>> In the libvirt commit message[*] Eric Blake writes:
>>
>> "[...] There may be potential improvements to the snapshot code to
>> exploit block copy over multiple disks all at one point in time.
>> And, if 'block-job-cancel' were made part of 'transaction', you
>> could copy multiple disks at the same point in time without pausing
>> the domain. [...]"
>>
> 
> Oh, you want a transactional cancel to basically capitalize on the
> second completion mode of the mirror job.
> 
> I have never really cared for the way this job works, because I don't
> think "canceling" a ready job is semantically valid (it's not canceled!
> We completed successfully, just using a different completion mode) --
> but if I am in the minority here I would cede that a transactional
> cancel would be a worthwhile thing to have.
> 
> I think at other points we have discussed the concept of having a
> configurable completion mode that jobs could have (and allowing this
> setting to be adjusted at runtime) that changes which completion mode
> they'll pursue.

Indeed, having a runtime-adjustable completion mode would allow what
libvirt wants: libvirt doesn't know what mode the user wants until they
request virDomainBlockJobAbort() (the name is scary, but it merely means
that they are stopping what is otherwise an unending job), and pass a
flag that says whether they want pivot or end-point-in-time copy
semantics.  If they request pivot semantics, libvirt invokes
block-job-complete to do its default completion mode, if they request
copy semantics, libvirt then switches the completion mode and still
calls block-job-complete (which _is_ valid in a transaction).

> 
> This would make a cancel unambiguously a cancellation. It would make a
> non-pivot completion to a mirror action an unambiguous success, too.
> 
> Minor nit, perhaps, but I want to be sure before we cement the semantics
> of how mirror can be "successful."

Minor or not, it is a useful viewpoint. Either way, as long as the new
way of getting a transactional non-pivot successful completion is
something that libvirt can learn via introspection, it should solve what
we are hoping for here.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-block] Making QMP 'block-job-cancel' transactionable

[John Snow]

On 03/24/2017 08:34 AM, Kashyap Chamarthy wrote:
> While debugging some other issue, I happened to stumble across an old
> libvirt commit[*] that adds support for pivot (whether QEMU should
> switch to a target copy or not) operation as a result of issuing QMP
> 'block-job-cancel' to a 'drive-mirror' (in libvirt parlance, "block
> copy").
> 
> In the libvirt commit message[*] Eric Blake writes:
> 
> "[...] There may be potential improvements to the snapshot code to
> exploit block copy over multiple disks all at one point in time.
> And, if 'block-job-cancel' were made part of 'transaction', you
> could copy multiple disks at the same point in time without pausing
> the domain. [...]"
> 

Oh, you want a transactional cancel to basically capitalize on the
second completion mode of the mirror job.

I have never really cared for the way this job works, because I don't
think "canceling" a ready job is semantically valid (it's not canceled!
We completed successfully, just using a different completion mode) --
but if I am in the minority here I would cede that a transactional
cancel would be a worthwhile thing to have.

I think at other points we have discussed the concept of having a
configurable completion mode that jobs could have (and allowing this
setting to be adjusted at runtime) that changes which completion mode
they'll pursue.

This would make a cancel unambiguously a cancellation. It would make a
non-pivot completion to a mirror action an unambiguous success, too.

Minor nit, perhaps, but I want to be sure before we cement the semantics
of how mirror can be "successful."

--js

> I realize that 'block-job-cancel' is currently not part of the
> @TransactionAction.  Is it worthwhile to do so?
> 
> Given the current behavior of QMP 'drive-mirror':
> 
>   - Upon 'block-job-complete', synchronization will end, and live QEMU
> pivots to the target (i.e. the copy)
> 
>   - Upon 'block-job-cancel', a point-in-time (at the time of cancel)
> copy gets created, and live QEMU will _not_ pivot.
> 
> I realize that it is not possible to perform a "block copy" of multiple
> disks at the same point in time without pausing QEMU.  From a brief chat
> with Stefan Hajnoczi on IRC, he does confirm that there's no current API
> for doing it atomically across multiple disks.
> 
> Since Stefan asked if a bug exists for adding 'transaction' support to
> 'block-job-cancel', thought I might bring it up here first.
> 
> 
> [*] https://libvirt.org/git/?p=libvirt.git;a=commit;h=eaba79d --
> blockjob: support pivot operation on cancel
> 

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.9 0/2] block/mirror: Fix use-after-free

[John Snow]

On 04/03/2017 01:51 PM, Max Reitz wrote:
> And the exciting 2.9 ride continues!
> 
> When mirroring from a BDS with no parents at all (such as those added
> with -blockdev or blockdev-add), we have a use-after-free in mirror's
> error path. The first patch of this series fixes that, the other adds a
> patch so we don't regress.
> 
> What issue will we find next? Stay tuned!
> 

Reviewed-by: John Snow 

> 
> Max Reitz (2):
>   block/mirror: Fix use-after-free
>   iotests: Add mirror tests for orphaned source
> 
>  block/mirror.c| 12 +--
>  tests/qemu-iotests/041| 46 
> +++
>  tests/qemu-iotests/041.out|  4 ++--
>  tests/qemu-iotests/iotests.py | 15 ++
>  4 files changed, 73 insertions(+), 4 deletions(-)
> 

Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Alexander Graf]

On 03.04.17 22:10, Eduardo Habkost wrote:

On Mon, Apr 03, 2017 at 08:49:16PM +0100, Peter Maydell wrote:

On 1 April 2017 at 01:46, Eduardo Habkost  wrote:

commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
all kinds of untested devices available to -device and
device_add.

The problem with that is: setting has_dynamic_sysbus on a
machine-type lets it accept all the 288 sysbus device types we
have in QEMU, and most of them were never meant to be used with
-device. That's a lot of untested code.

Fortunately today we have just a few has_dynamic_sysbus=1
machines: virt, pc-q35-*, ppce500, and spapr.

virt, ppce500, and spapr have extra checks to ensure just a few
device types can be instantiated:

* virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
* ppce500 supports only TYPE_ETSEC_COMMON.
* spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.

q35 has no code to block unsupported sysbus devices, however, and
accepts all device types. Fortunately, only the following 20
device types are compiled into the qemu-system-x86_64 and
qemu-system-i386 binaries:

* allwinner-ahci
* amd-iommu
* cfi.pflash01
* esp
* fw_cfg_io
* fw_cfg_mem
* generic-sdhci
* hpet
* intel-iommu
* ioapic
* isabus-bridge
* kvmclock
* kvm-ioapic
* kvmvapic
* SUNW,fdtwo
* sysbus-ahci
* sysbus-fdc
* sysbus-ohci
* unimplemented-device
* virtio-mmio

Instead of requiring each machine-type with has_dynamic_sysbus=1
to implement its own mechanism to block unsupported devices, we
can use the user_creatable flag to ensure we won't let the user
plug anything that will never work.


How does this work? Which devices can be dynamically
plugged is machine dependent. You can't dynamically-plug
an intel-iommu on the ARM virt board, and you can't
dynamically-plug the vfio-calxeda-xgmac on the spapr
board, and so on. So I don't see how we can just have
a flag on the device itself that controls whether
it can be dynamically plugged.

So I'm definitely coming around to the opinion that
it's just a bug in the q35 board that it doesn't have
any device whitelisting, and we should fix that.


OK, let's assume q35 must implement a whitelist:

To build that whitelist, we need to be able to know what should
be in the whitelist, or not. And nobody knew for sure what was
user-creatable in q35 by accident, and what was really supposed
to be user-creatable in q35. See the "q35 and sysbus devices"
thread I started ~2 weeks ago.

Building a q35 whitelist will be much easier if make
sys-bus-devices non-user-creatable by default.


So why are they user creatable in the first place?

We used to have boards that were dynamic sysbus aware (ppce500, virt) 
that allowed dynamic creation and every other board did not. I don't 
remember the exact mechanism behind it though.


When did that behavior change? It sounds like a regression somewhere.


Alex

Re: [Qemu-devel] [PATCH v2 1/1] qga: Add 'guest-get-users' command

[Eric Blake]

On 04/03/2017 03:08 PM, Vinzenz 'evilissimo' Feenstra wrote:
> From: Vinzenz Feenstra 
> 
> A command that will list all currently logged in users, and the time
> since when they are logged in.
> 
> Examples:
> 
> virsh # qemu-agent-command F25 '{ "execute": "guest-get-users" }'
> {"return":[{"login-time":1490622289.903835,"user":"root"}]}
> 
> virsh # qemu-agent-command Win2k12r2 '{ "execute": "guest-get-users" }'
> {"return":[{"login-time":1490351044.670552,"domain":"LADIDA",
> "user":"Administrator"}]}
> 
> Signed-off-by: Vinzenz Feenstra 
> ---

I'll leave the code reviews for others (I'm not comfortable enough with
Windows API programming), but focus on the interface here:

> +++ b/qga/qapi-schema.json
> @@ -1042,3 +1042,25 @@
>'data':{ 'path': 'str', '*arg': ['str'], '*env': ['str'],
> '*input-data': 'str', '*capture-output': 'bool' },
>'returns': 'GuestExec' }
> +
> +##
> +# @GuestUser:
> +# @user:   Username
> +# @domain: Logon domain (windows only)
> +# @login-time: Unix timestamp of login

In what unit? (Fractional) seconds since 1 Jan 1970?

So this is when they connected, and not a duration of how long they have
been logged on since then.

> +#
> +# Since: 2.10
> +##
> +{ 'struct': 'GuestUser',
> +  'data': { 'user': 'str', 'login-time': 'number', '*domain': 'str' } }
> +
> +##
> +# @guest-get-users:
> +# Retrieves a list of currently active users on the VM.
> +#
> +# Returns: A unique list of users.
> +#
> +# Since: 2.10
> +##
> +{ 'command': 'guest-get-users',
> +  'returns': ['GuestUser'] }
> 

The API looks good once you add that additional documentation.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Eduardo Habkost]

On Mon, Apr 03, 2017 at 08:49:16PM +0100, Peter Maydell wrote:
> On 1 April 2017 at 01:46, Eduardo Habkost  wrote:
> > commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
> > cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
> > all kinds of untested devices available to -device and
> > device_add.
> >
> > The problem with that is: setting has_dynamic_sysbus on a
> > machine-type lets it accept all the 288 sysbus device types we
> > have in QEMU, and most of them were never meant to be used with
> > -device. That's a lot of untested code.
> >
> > Fortunately today we have just a few has_dynamic_sysbus=1
> > machines: virt, pc-q35-*, ppce500, and spapr.
> >
> > virt, ppce500, and spapr have extra checks to ensure just a few
> > device types can be instantiated:
> >
> > * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
> > * ppce500 supports only TYPE_ETSEC_COMMON.
> > * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.
> >
> > q35 has no code to block unsupported sysbus devices, however, and
> > accepts all device types. Fortunately, only the following 20
> > device types are compiled into the qemu-system-x86_64 and
> > qemu-system-i386 binaries:
> >
> > * allwinner-ahci
> > * amd-iommu
> > * cfi.pflash01
> > * esp
> > * fw_cfg_io
> > * fw_cfg_mem
> > * generic-sdhci
> > * hpet
> > * intel-iommu
> > * ioapic
> > * isabus-bridge
> > * kvmclock
> > * kvm-ioapic
> > * kvmvapic
> > * SUNW,fdtwo
> > * sysbus-ahci
> > * sysbus-fdc
> > * sysbus-ohci
> > * unimplemented-device
> > * virtio-mmio
> >
> > Instead of requiring each machine-type with has_dynamic_sysbus=1
> > to implement its own mechanism to block unsupported devices, we
> > can use the user_creatable flag to ensure we won't let the user
> > plug anything that will never work.
> 
> How does this work? Which devices can be dynamically
> plugged is machine dependent. You can't dynamically-plug
> an intel-iommu on the ARM virt board, and you can't
> dynamically-plug the vfio-calxeda-xgmac on the spapr
> board, and so on. So I don't see how we can just have
> a flag on the device itself that controls whether
> it can be dynamically plugged.
> 
> So I'm definitely coming around to the opinion that
> it's just a bug in the q35 board that it doesn't have
> any device whitelisting, and we should fix that.

OK, let's assume q35 must implement a whitelist:

To build that whitelist, we need to be able to know what should
be in the whitelist, or not. And nobody knew for sure what was
user-creatable in q35 by accident, and what was really supposed
to be user-creatable in q35. See the "q35 and sysbus devices"
thread I started ~2 weeks ago.

Building a q35 whitelist will be much easier if make
sys-bus-devices non-user-creatable by default.

-- 
Eduardo

[Qemu-devel] [PATCH v2 1/1] qga: Add 'guest-get-users' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

A command that will list all currently logged in users, and the time
since when they are logged in.

Examples:

virsh # qemu-agent-command F25 '{ "execute": "guest-get-users" }'
{"return":[{"login-time":1490622289.903835,"user":"root"}]}

virsh # qemu-agent-command Win2k12r2 '{ "execute": "guest-get-users" }'
{"return":[{"login-time":1490351044.670552,"domain":"LADIDA",
"user":"Administrator"}]}

Signed-off-by: Vinzenz Feenstra 
---
 configure |  2 +-
 include/glib-compat.h |  5 +++
 qga/commands-posix.c  | 54 +++
 qga/commands-win32.c  | 89 +++
 qga/qapi-schema.json  | 22 +
 5 files changed, 171 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d1ce33b..779ebfd 100755
--- a/configure
+++ b/configure
@@ -737,7 +737,7 @@ if test "$mingw32" = "yes" ; then
   sysconfdir="\${prefix}"
   local_statedir=
   confsuffix=""
-  libs_qga="-lws2_32 -lwinmm -lpowrprof -liphlpapi -lnetapi32 $libs_qga"
+  libs_qga="-lws2_32 -lwinmm -lpowrprof -lwtsapi32 -liphlpapi -lnetapi32 
$libs_qga"
 fi
 
 werror=""
diff --git a/include/glib-compat.h b/include/glib-compat.h
index 863c8cf..f8ee9dc 100644
--- a/include/glib-compat.h
+++ b/include/glib-compat.h
@@ -217,6 +217,11 @@ static inline void g_hash_table_add(GHashTable 
*hash_table, gpointer key)
 {
 g_hash_table_replace(hash_table, key, key);
 }
+
+static gboolean g_hash_table_contains(GHashTable *hash_table, gpointer key)
+{
+return g_hash_table_lookup_extended(hash_table, key, NULL, NULL);
+}
 #endif
 
 #ifndef g_assert_true
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 73d93eb..3081ee7 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "qga/guest-agent-core.h"
 #include "qga-qmp-commands.h"
 #include "qapi/qmp/qerror.h"
@@ -2515,3 +2516,56 @@ void ga_command_state_init(GAState *s, GACommandState 
*cs)
 ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
 #endif
 }
+
+#ifndef QGA_MICRO_SECOND_TO_SECOND
+#   define QGA_MICRO_SECOND_TO_SECOND 100
+#endif
+
+static double ga_get_login_time(struct utmpx *user_info)
+{
+double seconds = (double)user_info->ut_tv.tv_sec;
+double useconds = (double)user_info->ut_tv.tv_usec;
+useconds /= QGA_MICRO_SECOND_TO_SECOND;
+return seconds + useconds;
+}
+
+GuestUserList *qmp_guest_get_users(Error **err)
+{
+GHashTable *cache = g_hash_table_new(g_str_hash, g_str_equal);
+GuestUserList *head = NULL, *cur_item = NULL;
+setutxent();
+for (;;) {
+struct utmpx *user_info = getutxent();
+if (user_info == NULL) {
+break;
+} else if (user_info->ut_type != USER_PROCESS) {
+continue;
+} else if (g_hash_table_contains(cache, user_info->ut_user)) {
+gpointer value = g_hash_table_lookup(cache, user_info->ut_user);
+GuestUser *user = (GuestUser *)value;
+double login_time = ga_get_login_time(user_info);
+/* We're ensuring the earliest login time to be sent */
+if (login_time < user->login_time) {
+user->login_time = login_time;
+}
+continue;
+}
+
+GuestUserList *item = g_new0(GuestUserList, 1);
+item->value = g_new0(GuestUser, 1);
+item->value->user = g_strdup(user_info->ut_user);
+item->value->login_time = ga_get_login_time(user_info);
+
+g_hash_table_insert(cache, item->value->user, item->value);
+
+if (!cur_item) {
+head = cur_item = item;
+} else {
+cur_item->next = item;
+cur_item = item;
+}
+}
+endutxent();
+g_hash_table_destroy(cache);
+return head;
+}
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 19d72b2..8b84a90 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -11,6 +11,9 @@
  * See the COPYING file in the top-level directory.
  */
 
+#ifndef _WIN32_WINNT
+#   define _WIN32_WINNT 0x0600
+#endif
 #include "qemu/osdep.h"
 #include 
 #include 
@@ -25,6 +28,7 @@
 #include 
 #endif
 #include 
+#include 
 
 #include "qga/guest-agent-core.h"
 #include "qga/vss-win32.h"
@@ -1536,3 +1540,88 @@ void ga_command_state_init(GAState *s, GACommandState 
*cs)
 ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
 }
 }
+
+/* MINGW is missing two fields: IncomingFrames & OutgoingFrames */
+typedef struct _GA_WTSINFOA {
+WTS_CONNECTSTATE_CLASS State;
+DWORD SessionId;
+DWORD IncomingBytes;
+DWORD OutgoingBytes;
+DWORD IncomingFrames;
+DWORD OutgoingFrames;
+DWORD IncomingCompressedBytes;
+DWORD OutgoingCompressedBy;
+CHAR WinStationName[WINSTATIONNAME_LENGTH];
+CHAR Domain[DOMAIN_LENGTH];
+CHAR UserName[USERNAME_LENGTH + 1];
+LARGE_INTEGER ConnectTime;
+LARGE_INTEGER DisconnectTime;
+LARGE_INTEGER L

[Qemu-devel] [PATCH v2 0/1] qga: Add 'guest-get-users' command

[Vinzenz 'evilissimo' Feenstra]

From: Vinzenz Feenstra 

Changes since v1:
- fixed spelling issues in the commit message and schema
- added login-time field which specifies the time the users logged on
- applied changes suggested for glib hash table usage
- added new link time library dependency for wtsapi32
- setting now _WIN32_WINNT to 0x0600 if not defined globally, which is Windows
  Vista and/or Windows 2008 Server and higher

Vinzenz Feenstra (1):
  qga: Add 'guest-get-users' command

 configure |  2 +-
 include/glib-compat.h |  5 +++
 qga/commands-posix.c  | 54 +++
 qga/commands-win32.c  | 89 +++
 qga/qapi-schema.json  | 22 +
 5 files changed, 171 insertions(+), 1 deletion(-)

-- 
2.9.3

Re: [Qemu-devel] [RFC 13/19] unimplemented-device: Remove user_creatable flag

[Eduardo Habkost]

On Mon, Apr 03, 2017 at 08:42:12PM +0100, Peter Maydell wrote:
> On 3 April 2017 at 19:30, Eduardo Habkost  wrote:
> > On Mon, Apr 03, 2017 at 03:08:06PM +0100, Peter Maydell wrote:
> >> On 3 April 2017 at 14:54, Eduardo Habkost  wrote:
> >> > This, on the other hand, currently works:
> >> >   $ qemu-system-x86_64 -M q35 -device 
> >> > unimplemented-device,size=1024,name=foo
> >>
> >> That's a bug in the q35 machine or the handling of -device
> >> on non-platform-bus systems, though, isn't it? The default
> >> for all sysbus devices has always been "you can't use
> >> -device with this", [...]
> >
> > This was true until 2014, only. commit
> > 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 changed sys-bus-device
> > to have cannot_instantiate_with_device_add_yet=false. See patch
> > 03/19 for more detailed info.
> 
> That commit shouldn't cause this problem -- unless the
> machine sets has_dynamic_sysbus then the machine_init_notify()
> that commit adds will cause it to complain.
> 
> I think the bug was introduced much later, in bf8d4924 in 2016,
> when q35 had the has_dynamic_sysbus flag added but without
> any code to restruct this to a whitelist of working
> devices. (In fact you can see in that commit a very
> minimal attempt to blacklist a few devices.)

It's true that the problem happened when q35 set
has_dynamic_sysbus=1 without a whitelist. The point of this
series is to make a per-machine-type whitelist unnecessary.

> 
> The commit message says only intel-iommu was supposed to
> be -device creatable, so it should have been the only
> thing on the whitelist.

There was a thread about it (Subject: "q35 and sysbus devices"),
and nobody knew for sure if the q35 whitelist was supposed to
have *-iommu only, or not.

The conclusion of that thread is that we can simply use
cannot_instantiate_with_device_add_yet to build the whitelist, if
the field was set consistently. This series renames
cannot_instantiate_with_device_add_yet to user_creatable, and
sets it consistently.

> Commit 9e3f9733 shows how this
> should be done (that's where spapr got has_dynamic_sysbus).
> 
> Maybe we should just fix the q35 bug first?

This fixes the q35 bug by setting user_creatable correctly on
sys-bus-devices, and makes a q35-specific whitelist unnecessary.

> 
> >>   [...] there's never been a requirement to
> >> mark them as such separately (because it would require
> >> touching the files for a huge number of devices for no
> >> particularly good reason when you can default the whole
> >> set of devices subclassing SysBusDevice).
> >
> > Yes, and this is the whole point of this series. At the end of
> > this series, only the few devices that are actually usable with
> > some machine will have an explicit user_creatable=true
> > assignment. See cover letter for details.
> 
> ...OK, but in that case why not just set that where it should
> be set, rather than having a big long patchset that touches
> a lot of devices that in the end are right back where
> they started? I think a lot of why I'm confused by
> this patchset is that it seems like it's changing
> behaviour on devices like this one which don't need
> any changes...

The devices don't get back right where they started: they start
with cannot_instantiate_with_device_add_yet=false (meaning they
are user-creatable in q35), and end up with user_creatable=false
(meaning they become non-user-creatable in all machines).

I could squash patches 04/19 to 19/19 into patch 03/19, it's
true. But then I would probably not get confirmation from you
(and other developers) that unimplemented-device (and other
devices) is really not supposed to be user-creatable. I wouldn't
know if I am breaking a valid q35 use case, or not.

-- 
Eduardo

[Qemu-devel] [PULL 4/6] nbd: fix memory leak on socket_connect failed

[Paolo Bonzini]

From: yaolujing 

When TCP connection fails between nbd server and client,
the local var, sioc, memory leak.

This patch fixes the memory leak.

Signed-off-by: yaolujing 
Reviewed-by: Eric Blake 
Message-Id: <1491005709-29989-1-git-send-email-yaoluj...@huawei.com>
Signed-off-by: Paolo Bonzini 
---
 block/nbd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/block/nbd.c b/block/nbd.c
index 1b832c2..3150712 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -311,6 +311,7 @@ static QIOChannelSocket 
*nbd_establish_connection(SocketAddress *saddr,
 saddr,
 &local_err);
 if (local_err) {
+object_unref(OBJECT(sioc));
 error_propagate(errp, local_err);
 return NULL;
 }
-- 
1.8.3.1

Re: [Qemu-devel] [RFC 03/19] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

[Peter Maydell]

On 1 April 2017 at 01:46, Eduardo Habkost  wrote:
> commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset
> cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making
> all kinds of untested devices available to -device and
> device_add.
>
> The problem with that is: setting has_dynamic_sysbus on a
> machine-type lets it accept all the 288 sysbus device types we
> have in QEMU, and most of them were never meant to be used with
> -device. That's a lot of untested code.
>
> Fortunately today we have just a few has_dynamic_sysbus=1
> machines: virt, pc-q35-*, ppce500, and spapr.
>
> virt, ppce500, and spapr have extra checks to ensure just a few
> device types can be instantiated:
>
> * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
> * ppce500 supports only TYPE_ETSEC_COMMON.
> * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.
>
> q35 has no code to block unsupported sysbus devices, however, and
> accepts all device types. Fortunately, only the following 20
> device types are compiled into the qemu-system-x86_64 and
> qemu-system-i386 binaries:
>
> * allwinner-ahci
> * amd-iommu
> * cfi.pflash01
> * esp
> * fw_cfg_io
> * fw_cfg_mem
> * generic-sdhci
> * hpet
> * intel-iommu
> * ioapic
> * isabus-bridge
> * kvmclock
> * kvm-ioapic
> * kvmvapic
> * SUNW,fdtwo
> * sysbus-ahci
> * sysbus-fdc
> * sysbus-ohci
> * unimplemented-device
> * virtio-mmio
>
> Instead of requiring each machine-type with has_dynamic_sysbus=1
> to implement its own mechanism to block unsupported devices, we
> can use the user_creatable flag to ensure we won't let the user
> plug anything that will never work.

How does this work? Which devices can be dynamically
plugged is machine dependent. You can't dynamically-plug
an intel-iommu on the ARM virt board, and you can't
dynamically-plug the vfio-calxeda-xgmac on the spapr
board, and so on. So I don't see how we can just have
a flag on the device itself that controls whether
it can be dynamically plugged.

So I'm definitely coming around to the opinion that
it's just a bug in the q35 board that it doesn't have
any device whitelisting, and we should fix that.

thanks
-- PMM

[Qemu-devel] [PULL 5/6] exec: revert MemoryRegionCache

[Paolo Bonzini]

MemoryRegionCache did not know about virtio support for IOMMUs (because the
two features were developed at the same time).  Revert MemoryRegionCache
to "normal" address_space_* operations for 2.9, as it is simpler than
undoing the virtio patches.

Signed-off-by: Paolo Bonzini 
---
 exec.c| 64 +--
 include/exec/memory.h | 10 
 2 files changed, 15 insertions(+), 59 deletions(-)

diff --git a/exec.c b/exec.c
index e57a8a2..c97ef4a 100644
--- a/exec.c
+++ b/exec.c
@@ -3236,75 +3236,33 @@ int64_t address_space_cache_init(MemoryRegionCache 
*cache,
  hwaddr len,
  bool is_write)
 {
-hwaddr l, xlat;
-MemoryRegion *mr;
-void *ptr;
-
-assert(len > 0);
-
-l = len;
-mr = address_space_translate(as, addr, &xlat, &l, is_write);
-if (!memory_access_is_direct(mr, is_write)) {
-return -EINVAL;
-}
-
-l = address_space_extend_translation(as, addr, len, mr, xlat, l, is_write);
-ptr = qemu_ram_ptr_length(mr->ram_block, xlat, &l);
-
-cache->xlat = xlat;
-cache->is_write = is_write;
-cache->mr = mr;
-cache->ptr = ptr;
-cache->len = l;
-memory_region_ref(cache->mr);
-
-return l;
+cache->len = len;
+cache->as = as;
+cache->xlat = addr;
+return len;
 }
 
 void address_space_cache_invalidate(MemoryRegionCache *cache,
 hwaddr addr,
 hwaddr access_len)
 {
-assert(cache->is_write);
-invalidate_and_set_dirty(cache->mr, addr + cache->xlat, access_len);
 }
 
 void address_space_cache_destroy(MemoryRegionCache *cache)
 {
-if (!cache->mr) {
-return;
-}
-
-if (xen_enabled()) {
-xen_invalidate_map_cache_entry(cache->ptr);
-}
-memory_region_unref(cache->mr);
-cache->mr = NULL;
-}
-
-/* Called from RCU critical section.  This function has the same
- * semantics as address_space_translate, but it only works on a
- * predefined range of a MemoryRegion that was mapped with
- * address_space_cache_init.
- */
-static inline MemoryRegion *address_space_translate_cached(
-MemoryRegionCache *cache, hwaddr addr, hwaddr *xlat,
-hwaddr *plen, bool is_write)
-{
-assert(addr < cache->len && *plen <= cache->len - addr);
-*xlat = addr + cache->xlat;
-return cache->mr;
+cache->as = NULL;
 }
 
 #define ARG1_DECLMemoryRegionCache *cache
 #define ARG1 cache
 #define SUFFIX   _cached
-#define TRANSLATE(...)   address_space_translate_cached(cache, 
__VA_ARGS__)
+#define TRANSLATE(addr, ...) \
+address_space_translate(cache->as, cache->xlat + (addr), __VA_ARGS__)
 #define IS_DIRECT(mr, is_write)  true
-#define MAP_RAM(mr, ofs) (cache->ptr + (ofs - cache->xlat))
-#define INVALIDATE(mr, ofs, len) ((void)0)
-#define RCU_READ_LOCK()  ((void)0)
-#define RCU_READ_UNLOCK()((void)0)
+#define MAP_RAM(mr, ofs) qemu_map_ram_ptr((mr)->ram_block, ofs)
+#define INVALIDATE(mr, ofs, len) invalidate_and_set_dirty(mr, ofs, len)
+#define RCU_READ_LOCK()  rcu_read_lock()
+#define RCU_READ_UNLOCK()rcu_read_unlock()
 #include "memory_ldst.inc.c"
 
 /* virtual memory access for debug (includes writing to ROM) */
diff --git a/include/exec/memory.h b/include/exec/memory.h
index e39256a..f20b191 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1426,13 +1426,11 @@ void stq_be_phys(AddressSpace *as, hwaddr addr, 
uint64_t val);
 
 struct MemoryRegionCache {
 hwaddr xlat;
-void *ptr;
 hwaddr len;
-MemoryRegion *mr;
-bool is_write;
+AddressSpace *as;
 };
 
-#define MEMORY_REGION_CACHE_INVALID ((MemoryRegionCache) { .mr = NULL })
+#define MEMORY_REGION_CACHE_INVALID ((MemoryRegionCache) { .as = NULL })
 
 /* address_space_cache_init: prepare for repeated access to a physical
  * memory region
@@ -1688,7 +1686,7 @@ address_space_read_cached(MemoryRegionCache *cache, 
hwaddr addr,
   void *buf, int len)
 {
 assert(addr < cache->len && len <= cache->len - addr);
-memcpy(buf, cache->ptr + addr, len);
+address_space_read(cache->as, cache->xlat + addr, MEMTXATTRS_UNSPECIFIED, 
buf, len);
 }
 
 /**
@@ -1704,7 +1702,7 @@ address_space_write_cached(MemoryRegionCache *cache, 
hwaddr addr,
void *buf, int len)
 {
 assert(addr < cache->len && len <= cache->len - addr);
-memcpy(cache->ptr + addr, buf, len);
+address_space_write(cache->as, cache->xlat + addr, MEMTXATTRS_UNSPECIFIED, 
buf, len);
 }
 
 #endif
-- 
1.8.3.1

Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

[Eric Blake]

On 04/03/2017 08:00 AM, Kevin Wolf wrote:
>> The question remains whether it is practical not to make an exception.
>> As far as I know, libvirt is only guaranteed to support older qemu
>> versions, not necessarily future ones. So we should be allowed to break
>> existing use cases here until libvirt is updated (assuming it is
>> possible for libvirt to express "guest device allows shared writes" as
>> an option for its next release).
> 
> If I understand correctly, this is a case of incoming live migration,
> i.e. the virtio-blk device which is blocking the writes to the image
> doesn't really belong to a running guest yet.
> 
> So if we need to make an exception (and actually reading the context
> makes it appear so), I guess it would have to be that devices actually
> can share the write permission during incoming migration, but not any
> more later (unless the share-rw flag is set).

That sounds like the right approach - if nbd-server-add can detect that
it is being invoked during the window between 'qemu -S' and before
'migrate', and allow the shared-rw at that time, then revoke it at the
time the migrate command hits.

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 1/6] iscsi: drop unused IscsiAIOCB.qiov field

[Paolo Bonzini]

From: Stefan Hajnoczi 

The IscsiAIOCB.qiov field has been unused since commit
063c3378a9e3c25cc0afac3c72e4823d0621e352 ("block/iscsi: introduce
bdrv_co_{readv, writev, flush_to_disk}") back in 2013.

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20170327165005.22038-1-stefa...@redhat.com>
Reviewed-by: Eric Blake 
Signed-off-by: Paolo Bonzini 
---
 block/iscsi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index 75d8905..716e74a 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -103,7 +103,6 @@ typedef struct IscsiTask {
 
 typedef struct IscsiAIOCB {
 BlockAIOCB common;
-QEMUIOVector *qiov;
 QEMUBH *bh;
 IscsiLun *iscsilun;
 struct scsi_task *task;
-- 
1.8.3.1

Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

[Eric Blake]

On 04/03/2017 07:39 AM, Max Reitz wrote:
>>> As for just allowing the NBD server write access to the device... To me
>>> that appears pretty difficult from an implementation perspective. We
>>> assert that nobody can write without having requested write access and
>>> we make sure that nobody can request write access without it being
>>> allowed. Making an exception for NBD seems very difficult and would
>>> probably mean we'd have to drop the assertion for write accesses altogether.
>>
>> Making an exception would simply be wrong.
> 
> Indeed. That is why it would be so difficult.
> 
> The question remains whether it is practical not to make an exception.
> As far as I know, libvirt is only guaranteed to support older qemu
> versions, not necessarily future ones. So we should be allowed to break
> existing use cases here until libvirt is updated (assuming it is
> possible for libvirt to express "guest device allows shared writes" as
> an option for its next release).

In general, we support:

old qemu, old libvirt (well, as long as those versions are supported)
old qemu, new libvirt
new qemu, new libvirt

but we do NOT make any guarantees of supporting

new qemu, old libvirt

In other words, this may be a failure where new qemu requires extra care
and thus a new libvirt for it to be useful.  It's not nice to break qemu
back-compat if any other solution is possible (new qemu and old libvirt
should work more often than not), but it is the one scenario that no one
supports (whether here, upstream libvirt, or in downstream backports).

Or, put another way, it's perfectly fine if we require that the use of
qemu 2.9 requires that you also use libvirt 3.3.0 or newer (since we
missed the boat on fixing libvirt 3.2 to pass shared-rw or any other
handshaking we come up with), although it's also nice if we figure out
how to make qemu work with what existing libvirt wants to do (the NBD
export needs to be writable by the source pre-migration, and by the
destination post-migration; so there is that aspect of two clients both
wanting to write - but the destination doesn't need to write until after
the source no longer has anything to write, so if we have a clean way to
turn writes off for the source, then turn writes on for the destination,
all before migrating which host is writing, that would be even cleaner).

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 3/6] ipmi: Fix macro issues

[Paolo Bonzini]

From: Corey Minyard 

Macro parameters should almost always have () around them when used.
llvm reported an error on this.

Remove redundant parenthesis and put parenthesis around the entire
macros with assignments in case they are used in an expression.

Remove some unused macros.

Reported in https://bugs.launchpad.net/bugs/1651167

Signed-off-by: Corey Minyard 
Reviewed-by: Eric Blake 
Message-Id: <1490894892-8055-1-git-send-email-miny...@acm.org>
Signed-off-by: Paolo Bonzini 
---
 hw/ipmi/isa_ipmi_bt.c | 34 --
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c
index 1c69cb3..2fcc3d2 100644
--- a/hw/ipmi/isa_ipmi_bt.c
+++ b/hw/ipmi/isa_ipmi_bt.c
@@ -37,40 +37,30 @@
 #define IPMI_BT_HBUSY_BIT  6
 #define IPMI_BT_BBUSY_BIT  7
 
-#define IPMI_BT_CLR_WR_MASK(1 << IPMI_BT_CLR_WR_BIT)
 #define IPMI_BT_GET_CLR_WR(d)  (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1)
-#define IPMI_BT_SET_CLR_WR(d, v)   (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \
-   (((v & 1) << IPMI_BT_CLR_WR_BIT)))
 
-#define IPMI_BT_CLR_RD_MASK(1 << IPMI_BT_CLR_RD_BIT)
 #define IPMI_BT_GET_CLR_RD(d)  (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1)
-#define IPMI_BT_SET_CLR_RD(d, v)   (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \
-   (((v & 1) << IPMI_BT_CLR_RD_BIT)))
 
-#define IPMI_BT_H2B_ATN_MASK   (1 << IPMI_BT_H2B_ATN_BIT)
 #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1)
-#define IPMI_BT_SET_H2B_ATN(d, v)  (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \
-(((v & 1) << IPMI_BT_H2B_ATN_BIT)))
 
 #define IPMI_BT_B2H_ATN_MASK   (1 << IPMI_BT_B2H_ATN_BIT)
 #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1)
-#define IPMI_BT_SET_B2H_ATN(d, v)  (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \
-(((v & 1) << IPMI_BT_B2H_ATN_BIT)))
+#define IPMI_BT_SET_B2H_ATN(d, v)  ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \
+(((v) & 1) << IPMI_BT_B2H_ATN_BIT)))
 
 #define IPMI_BT_SMS_ATN_MASK   (1 << IPMI_BT_SMS_ATN_BIT)
 #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1)
-#define IPMI_BT_SET_SMS_ATN(d, v)  (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \
-(((v & 1) << IPMI_BT_SMS_ATN_BIT)))
+#define IPMI_BT_SET_SMS_ATN(d, v)  ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \
+(((v) & 1) << IPMI_BT_SMS_ATN_BIT)))
 
 #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT)
 #define IPMI_BT_GET_HBUSY(d)   (((d) >> IPMI_BT_HBUSY_BIT) & 0x1)
-#define IPMI_BT_SET_HBUSY(d, v)(d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \
-   (((v & 1) << IPMI_BT_HBUSY_BIT)))
+#define IPMI_BT_SET_HBUSY(d, v)((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \
+   (((v) & 1) << IPMI_BT_HBUSY_BIT)))
 
 #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT)
-#define IPMI_BT_GET_BBUSY(d)   (((d) >> IPMI_BT_BBUSY_BIT) & 0x1)
-#define IPMI_BT_SET_BBUSY(d, v)(d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \
-   (((v & 1) << IPMI_BT_BBUSY_BIT)))
+#define IPMI_BT_SET_BBUSY(d, v)((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \
+   (((v) & 1) << IPMI_BT_BBUSY_BIT)))
 
 
 /* Mask register */
@@ -79,13 +69,13 @@
 
 #define IPMI_BT_B2H_IRQ_EN_MASK  (1 << IPMI_BT_B2H_IRQ_EN_BIT)
 #define IPMI_BT_GET_B2H_IRQ_EN(d)(((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1)
-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | 
\
-(((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT)))
+#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) 
|\
+(((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT)))
 
 #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT)
 #define IPMI_BT_GET_B2H_IRQ(d)   (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1)
-#define IPMI_BT_SET_B2H_IRQ(d, v)(d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \
-(((v & 1) << IPMI_BT_B2H_IRQ_BIT)))
+#define IPMI_BT_SET_B2H_IRQ(d, v)((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \
+(((v) & 1) << IPMI_BT_B2H_IRQ_BIT)))
 
 typedef struct IPMIBT {
 IPMIBmc *bmc;
-- 
1.8.3.1

[Qemu-devel] [PULL 6/6] main-loop: Acquire main_context lock around os_host_main_loop_wait.

[Paolo Bonzini]

From: "Richard W.M. Jones" 

When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle.  With virt-rescue >= 1.37 you may be able to observe the
hang by doing:

  $ virt-rescue -e ^] --scratch
  > while true; do ls -l /usr/bin; done

The hang in virt-rescue can be resolved by pressing a key on the
serial console.

Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console.  Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:

  $ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done

(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)

During investigation of this bug, Paolo Bonzini wrote:

> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext.  However QEMU is not doing that, instead it is taking its
> own mutex.  So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.

This patch exactly implements Paolo's suggestion in that paragraph.

This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing.  I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones 
Tested-by: Richard W.M. Jones 
Signed-off-by: Richard W.M. Jones 
Message-Id: <20170331205133.23906-1-rjo...@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini 
---
 util/main-loop.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/util/main-loop.c b/util/main-loop.c
index 4534c89..19cad6b 100644
--- a/util/main-loop.c
+++ b/util/main-loop.c
@@ -218,9 +218,12 @@ static void glib_pollfds_poll(void)
 
 static int os_host_main_loop_wait(int64_t timeout)
 {
+GMainContext *context = g_main_context_default();
 int ret;
 static int spin_counter;
 
+g_main_context_acquire(context);
+
 glib_pollfds_fill(&timeout);
 
 /* If the I/O thread is very busy or we are incorrectly busy waiting in
@@ -256,6 +259,9 @@ static int os_host_main_loop_wait(int64_t timeout)
 }
 
 glib_pollfds_poll();
+
+g_main_context_release(context);
+
 return ret;
 }
 #else
@@ -412,12 +418,15 @@ static int os_host_main_loop_wait(int64_t timeout)
 fd_set rfds, wfds, xfds;
 int nfds;
 
+g_main_context_acquire(context);
+
 /* XXX: need to suppress polling by better using win32 events */
 ret = 0;
 for (pe = first_polling_entry; pe != NULL; pe = pe->next) {
 ret |= pe->func(pe->opaque);
 }
 if (ret != 0) {
+g_main_context_release(context);
 return ret;
 }
 
@@ -472,6 +481,8 @@ static int os_host_main_loop_wait(int64_t timeout)
 g_main_context_dispatch(context);
 }
 
+g_main_context_release(context);
+
 return select_ret || g_poll_ret;
 }
 #endif
-- 
1.8.3.1

[Qemu-devel] [PULL 0/6] Misc patches for QEMU 2.9.0-rc3

[Paolo Bonzini]

The following changes since commit 95b31d709ba343ad237c3630047ee7438bac4065:

  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-updates-20170331.0' 
into staging (2017-03-31 18:06:13 +0100)

are available in the git repository at:


  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to ecbddbb106114f90008024b4e6c3ba1c38d7ca0e:

  main-loop: Acquire main_context lock around os_host_main_loop_wait. 
(2017-04-03 19:13:12 +0200)


* MemoryRegionCache revert
* glib optimization workaround
* fix "info lapic" segfault on isapc
* fix QIOChannel memory leak


Corey Minyard (1):
  ipmi: Fix macro issues

Paolo Bonzini (1):
  exec: revert MemoryRegionCache

Richard W.M. Jones (1):
  main-loop: Acquire main_context lock around os_host_main_loop_wait.

Stefan Hajnoczi (1):
  iscsi: drop unused IscsiAIOCB.qiov field

Tejaswini Poluri (1):
  target-i386: fix "info lapic" segfault on isapc

yaolujing (1):
  nbd: fix memory leak on socket_connect failed

 block/iscsi.c |  1 -
 block/nbd.c   |  1 +
 exec.c| 64 +--
 hw/ipmi/isa_ipmi_bt.c | 34 ++-
 include/exec/memory.h | 10 
 target/i386/helper.c  |  4 
 util/main-loop.c  | 11 +
 7 files changed, 43 insertions(+), 82 deletions(-)
-- 
1.8.3.1

[Qemu-devel] [PULL 2/6] target-i386: fix "info lapic" segfault on isapc

[Paolo Bonzini]

From: Tejaswini Poluri 

Start QEMU with
"qemu-system-x86_64 -nographic -M isapc -serial none-monitor stdio"
and enter "info lapic" at the monitor prompt ⇒
Segmentation fault

Signed-off-by: Tejaswini Poluri 
Message-Id: <1490685583-16987-1-git-send-email-tejaswinipolu...@gmail.com>
Signed-off-by: Paolo Bonzini 
---
 target/i386/helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/i386/helper.c b/target/i386/helper.c
index e2af340..f11cac6 100644
--- a/target/i386/helper.c
+++ b/target/i386/helper.c
@@ -326,6 +326,10 @@ void x86_cpu_dump_local_apic_state(CPUState *cs, FILE *f,
 {
 X86CPU *cpu = X86_CPU(cs);
 APICCommonState *s = APIC_COMMON(cpu->apic_state);
+if (!s) {
+cpu_fprintf(f, "local apic state not available\n");
+return;
+}
 uint32_t *lvt = s->lvt;
 
 cpu_fprintf(f, "dumping local APIC state for CPU %-2u\n\n",
-- 
1.8.3.1

Re: [Qemu-devel] [RFC 13/19] unimplemented-device: Remove user_creatable flag

[Peter Maydell]

On 3 April 2017 at 19:30, Eduardo Habkost  wrote:
> On Mon, Apr 03, 2017 at 03:08:06PM +0100, Peter Maydell wrote:
>> On 3 April 2017 at 14:54, Eduardo Habkost  wrote:
>> > This, on the other hand, currently works:
>> >   $ qemu-system-x86_64 -M q35 -device 
>> > unimplemented-device,size=1024,name=foo
>>
>> That's a bug in the q35 machine or the handling of -device
>> on non-platform-bus systems, though, isn't it? The default
>> for all sysbus devices has always been "you can't use
>> -device with this", [...]
>
> This was true until 2014, only. commit
> 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 changed sys-bus-device
> to have cannot_instantiate_with_device_add_yet=false. See patch
> 03/19 for more detailed info.

That commit shouldn't cause this problem -- unless the
machine sets has_dynamic_sysbus then the machine_init_notify()
that commit adds will cause it to complain.

I think the bug was introduced much later, in bf8d4924 in 2016,
when q35 had the has_dynamic_sysbus flag added but without
any code to restruct this to a whitelist of working
devices. (In fact you can see in that commit a very
minimal attempt to blacklist a few devices.)

The commit message says only intel-iommu was supposed to
be -device creatable, so it should have been the only
thing on the whitelist. Commit 9e3f9733 shows how this
should be done (that's where spapr got has_dynamic_sysbus).

Maybe we should just fix the q35 bug first?

>>   [...] there's never been a requirement to
>> mark them as such separately (because it would require
>> touching the files for a huge number of devices for no
>> particularly good reason when you can default the whole
>> set of devices subclassing SysBusDevice).
>
> Yes, and this is the whole point of this series. At the end of
> this series, only the few devices that are actually usable with
> some machine will have an explicit user_creatable=true
> assignment. See cover letter for details.

...OK, but in that case why not just set that where it should
be set, rather than having a big long patchset that touches
a lot of devices that in the end are right back where
they started? I think a lot of why I'm confused by
this patchset is that it seems like it's changing
behaviour on devices like this one which don't need
any changes...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Patrick Ohly]

On Mon, 2017-04-03 at 18:38 +0100, Dr. David Alan Gilbert wrote:
> Or you could just remove the spawning code and use existing sockets; less 
> code!

That would be harder to use reliably in the automated testing that this
feature is targeting.

With this mechanism, it is guaranteed that both processes notice when
the other dies because the connection gets disconnected. There's never a
time period where one process listens for a connection from a process
that might have died already, or never got started.

It's also easier that the scripts calling qemu only need to deal with
one process, as before, and just need to pass some additional
parameters.

Can we agree that both usage models are valid and thus support both?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Qemu-devel] [PATCH for-2.9 2/2] iotests: Add mirror tests for orphaned source

[Eric Blake]

On 04/03/2017 12:51 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/041| 46 
> +++
>  tests/qemu-iotests/041.out|  4 ++--
>  tests/qemu-iotests/iotests.py | 15 ++
>  3 files changed, 63 insertions(+), 2 deletions(-)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1679126] Re: null pointer access on migration resume of systemrescuecd boot menu with qxl-vga

[Dr. David Alan Gilbert]

I think this is actually anything that's in text mode grub; I've had a
RHEL5 and 6 VM do it as well.

Thanks for reporting it.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1679126

Title:
  null pointer access on migration resume of systemrescuecd boot menu
  with qxl-vga

Status in QEMU:
  Confirmed

Bug description:
  With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when
  resuming from a migration state file created from a VM suspended while
  showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA
  device, I get a null point access in pixman_image_get_data called from
  qemu_spice_create_update (spice-display.c:215).  When I added
  assert(ssd->mirror != NULL) above that line, assert failed.  I don't
  get the crash when using standard VGA or cirrus-vga.  I am using
  gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel:
  4.9.15-gentoo.

  Here is the valgrind trace from the git version:
  ==2634== Thread 1:
  ==2634== Invalid read of size 4
  ==3516==at 0x65F3050: pixman_image_get_data (in 
/usr/lib64/libpixman-1.so.0.34.0)
  ==3516==by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215)
  ==3516==by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502)
  ==3516==by 0x58CF77: display_refresh (qxl.c:1948)
  ==3516==by 0x6E8084: do_safe_dpy_refresh (console.c:1591)
  ==3516==by 0x6E80D5: dpy_refresh (console.c:1604)
  ==3516==by 0x6E4508: gui_update (console.c:201)
  ==3516==by 0x81898E: timerlist_run_timers (qemu-timer.c:536)
  ==3516==by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547)
  ==3516==by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662)
  ==3516==by 0x81952A: main_loop_wait (main-loop.c:514)
  ==3516==by 0x4ADD29: main_loop (vl.c:1898)

  Minimal steps to reproduce:

  Compile (debug compile flags are just so valgrind works, the crash occurs 
with non-debug compile flags as well):
  CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure 
--target-list=i386-softmmu,x86_64-softmmu
  ./configure
  make

  Start VM and leave it on the System Rescue CD graphical boot menu:
  x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive 
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device 
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor 
unix:monitor.sock,server,nowait -display gtk

  Suspend VM and save state:
  socat - unix:monitor.sock
stop
migrate "exec:cat > vm.state"
quit

  Attempt to resume VM (but this crashes):
  x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive 
file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device 
ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor 
unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state"

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1679126/+subscriptions

Re: [Qemu-devel] [PATCH 7/7] Added support for TPM emulator

[Eric Blake]

On 03/31/2017 08:10 AM, Amarnath Valluri wrote:
> This change introduces a new TPM backend driver that can communicates with
> swtpm(software TPM emulator) using unix domain socket interface.
> 
> Swtpm uses two unix sockets, one for plain TPM commands and responses, and one
> for out-of-band control messages.
> 
> The swtpm and associated tools can be found here:
> https://github.com/stefanberger/swtpm
> 
> Usage:
> # setup TPM state directory
> mkdir /tmp/mytpm
> chown -R tss:root /tmp/mytpm
> /usr/bin/swtpm_setup --tpm-state /tmp/mytpm --createek
> 
> # Ask qeum to use TPM emulator with given tpm state directory
> qemu-system-x86_64 \
> [...] \
> -tpmdev 
> emulator,id=tpm0,tpmstatedir=/tmp/mytpm,logfile=/tmp/swtpm.log \
> -device tpm-tis,tpmdev=tpm0 \
> [...]
> 
> Signed-off-by: Amarnath Valluri 
> ---

Just an interface review for now:


> +++ b/qapi-schema.json
> @@ -5117,10 +5117,11 @@
>  # An enumeration of TPM types
>  #
>  # @passthrough: TPM passthrough type
> +# @emulator: Software Emulator TPM type

Missing a '(since 2.10)' designator on @emulator

>  #
>  # Since: 1.5
>  ##
> -{ 'enum': 'TpmType', 'data': [ 'passthrough' ] }
> +{ 'enum': 'TpmType', 'data': [ 'passthrough', 'emulator' ] }
>  
>  ##
>  # @query-tpm-types:
> @@ -5163,6 +5164,22 @@
>'data': { '*path' : 'str', '*cancel-path' : 'str'} }
>  
>  ##
> +# @TPMEmulatorOptions:
> +#
> +# Information about the TPM emulator
> +#
> +# @tpmstatedir: TPM emilator state dir

s/emilator/emulator/

> +# @path: TPM emulator binary path to use
> +# @logfile: file to use to place TPM emulator logs

What's the default when logfile is omitted?

> +# @loglevel: log level number

What's the default, or even the valid range of values? Is a larger
number noisier?

> +#
> +# Since: 2.6

You've missed 2.6 by a long shot. We are now working on 2.10 interfaces.

> +##
> +{ 'struct': 'TPMEmulatorOptions', 'base': 'TPMOptions',

Okay, the base class you added in 5/7 makes a bit more sense now, even
if it remains empty.  But then that means you need to update the commit
message to call it out as intentional that it is empty and a second
derived class will be added later.

> +  'data': { 'tpmstatedir' : 'str', '*path': 'str',
> +'*logfile' : 'str', '*loglevel' : 'int' } }
> +
> +##
>  # @TpmTypeOptions:
>  #
>  # A union referencing different TPM backend types' configuration options
> @@ -5172,7 +5189,8 @@
>  # Since: 1.5
>  ##
>  { 'union': 'TpmTypeOptions',
> -   'data': { 'passthrough' : 'TPMPassthroughOptions' } }
> +  'data': { 'passthrough' : 'TPMPassthroughOptions',
> +'emulator' : 'TPMEmulatorOptions' } }
>  
>  ##
>  # @TPMInfo:

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 5/7] tmp backend: Add new api to read backend tpm options

[Eric Blake]

On 03/31/2017 08:10 AM, Amarnath Valluri wrote:
> TPM configuration options are backend implementation details and shall not be
> part of base TPMBackend object, and these shall not be accessed directly 
> outside
> of the class, hence added a new tpm backend api, tpm_backend_get_tpm_options()
> to read the backend configured options.
> 
> Added new method, get_tpm_options() to TPMDriverOps., which shall be 
> implemented
> by the derived classes to return configured tpm options.
> 
> Signed-off-by: Amarnath Valluri 
> ---

Just an interface review for now:


> +++ b/qapi-schema.json
> @@ -5140,6 +5140,14 @@
>  { 'command': 'query-tpm-types', 'returns': ['TpmType'] }
>  
>  ##
> +# @TPMOptions:
> +#
> +# Base type for TPM options
> +##

Missing a 'Since: 2.10' designation

> +{ 'struct': 'TPMOptions',
> +  'data': { } }

This class feels pointless (at least for now; I haven't checked if you
expand it later in the series - but if so, define it where you first
need it). It has no members, and you are only using it...

> +
> +##
>  # @TPMPassthroughOptions:
>  #
>  # Information about the TPM passthrough type
> @@ -5151,8 +5159,8 @@
>  #
>  # Since: 1.5
>  ##
> -{ 'struct': 'TPMPassthroughOptions', 'data': { '*path' : 'str',
> - '*cancel-path' : 'str'} }
> +{ 'struct': 'TPMPassthroughOptions', 'base': 'TPMOptions',

...as a base class. A base class makes sense only if it is consolidating
common members, or if it is the base to at least two different
structures where having a common C type to pass around is handy.

> +  'data': { '*path' : 'str', '*cancel-path' : 'str'} }
>  

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC 02/19] s390: Add FIXME for unexplained user_creatable=false line

[Eduardo Habkost]

On Mon, Apr 03, 2017 at 10:55:38AM +0200, Cornelia Huck wrote:
> On Fri, 31 Mar 2017 21:46:07 -0300
> Eduardo Habkost  wrote:
> 
> > TYPE_S390_PCI_HOST_BRIDGE has user_creatable=false but has
> > no comment explaining why. Add a FIXME to document that.
> > 
> > Cc: Frank Blaschka 
> > Cc: Cornelia Huck 
> > Cc: Christian Borntraeger 
> > Cc: Alexander Graf 
> > Cc: Richard Henderson 
> > Signed-off-by: Eduardo Habkost 
> > ---
> >  hw/s390x/s390-pci-bus.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> > index 1ec30c45ce..2c3b960bdf 100644
> > --- a/hw/s390x/s390-pci-bus.c
> > +++ b/hw/s390x/s390-pci-bus.c
> > @@ -867,7 +867,7 @@ static void s390_pcihost_class_init(ObjectClass *klass, 
> > void *data)
> >  DeviceClass *dc = DEVICE_CLASS(klass);
> >  HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
> >  
> > -dc->user_creatable = false;
> > +dc->user_creatable = false; /*FIXME: explain why */
> >  dc->reset = s390_pcihost_reset;
> >  k->init = s390_pcihost_init;
> >  hc->plug = s390_pcihost_hot_plug;
> 
> (adding some more possibly interested parties)
> 
> We currently have one master s390 phb (and it's been that way since
> s390 pci was introduced). Recently, there has been some remodelling
> going on to make this more similar to what sPAPR does. I think we could
> make this even more similar to sPAPR and have this user createable; but
> I'm currently not sure it's worth the effort. Opinions?

It looks -device s390-pcihost was never possible, anyway, because
no s390x machine has has_dynamic_sysbus=1, and TYPE_PCI_HOST_BRIDGE
is a sys-bus-device.

Also, patch 03/19 on this series would make the explicit
user_creatable=false assignment in s390_pcihost_class_init()
unnecessary.

I don't think it is worth the effort to change that, unless you
have a specific use case that would benefit from it.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 for-2.10 09/16] block/qcow2: Generalize preallocate()

[Philippe Mathieu-Daudé]

Hi Max,

On 04/03/2017 01:09 PM, Max Reitz wrote:

This patch adds two new parameters to the preallocate() function so we
will be able to use it not just for preallocating a new image but also
for preallocated image growth.

The offset parameter allows the caller to specify a virtual offset from
which to start preallocating. For newly created images this is always 0,
but for preallocating growth this will be the old image length.

The new_length parameter specifies the supposed new length of the image
(basically the "end offset" for preallocation). During image truncation,
bdrv_getlength() will return the old image length so we cannot rely on
its return value then.

Signed-off-by: Max Reitz 
---
 block/qcow2.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 9fd220ec34..163d51ec65 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2034,17 +2034,23 @@ static int qcow2_change_backing_file(BlockDriverState 
*bs,
 return qcow2_update_header(bs);
 }

-static int preallocate(BlockDriverState *bs)
+/**
+ * Preallocates metadata structures for data clusters between @offset (in the
+ * guest disk) and @new_length (which is thus generally the new guest disk
+ * size).
+ *
+ * Returns: 0 on success, -errno on failure.
+ */
+static int preallocate(BlockDriverState *bs, int64_t offset, int64_t 
new_length)
 {
 uint64_t bytes;
-uint64_t offset;
 uint64_t host_offset = 0;
 unsigned int cur_bytes;
 int ret;
 QCowL2Meta *meta;

-bytes = bdrv_getlength(bs);
-offset = 0;


why use `int64_t`? is it ok to have a negative offset?
preallocate a negative length sound weird... even `bytes` is unsigned.


+assert(offset <= new_length);
+bytes = new_length - offset;

 while (bytes) {
 cur_bytes = MIN(bytes, INT_MAX);
@@ -2314,7 +2320,7 @@ static int qcow2_create2(const char *filename, int64_t 
total_size,
 if (prealloc != PREALLOC_MODE_OFF) {
 BDRVQcow2State *s = blk_bs(blk)->opaque;
 qemu_co_mutex_lock(&s->lock);
-ret = preallocate(blk_bs(blk));
+ret = preallocate(blk_bs(blk), 0, total_size);
 qemu_co_mutex_unlock(&s->lock);
 if (ret < 0) {
 error_setg_errno(errp, -ret, "Could not preallocate metadata");

Re: [Qemu-devel] [PATCH v2 2/3] libqtest: Add a generic function to run a callback function for every machine

[Philippe Mathieu-Daudé]

On 03/30/2017 04:50 AM, Thomas Huth wrote:

Some tests need to run single tests for every available machine of the
current QEMU binary. To avoid code duplication, let's extract this
code that deals with 'query-machines' into a separate function.

Signed-off-by: Thomas Huth 


Reviewed-by: Philippe Mathieu-Daudé 


---
 tests/libqtest.c| 30 +
 tests/libqtest.h|  8 +
 tests/pc-cpu-test.c | 95 -
 tests/qom-test.c| 36 
 4 files changed, 80 insertions(+), 89 deletions(-)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index c9b2d76..d8b8066 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -938,3 +938,33 @@ bool qtest_big_endian(QTestState *s)
 {
 return s->big_endian;
 }
+
+void qtest_cb_for_every_machine(void (*cb)(const char *machine))
+{
+QDict *response, *minfo;
+QList *list;
+const QListEntry *p;
+QObject *qobj;
+QString *qstr;
+const char *mname;
+
+qtest_start("-machine none");
+response = qmp("{ 'execute': 'query-machines' }");
+g_assert(response);
+list = qdict_get_qlist(response, "return");
+g_assert(list);
+
+for (p = qlist_first(list); p; p = qlist_next(p)) {
+minfo = qobject_to_qdict(qlist_entry_obj(p));
+g_assert(minfo);
+qobj = qdict_get(minfo, "name");
+g_assert(qobj);
+qstr = qobject_to_qstring(qobj);
+g_assert(qstr);
+mname = qstring_get_str(qstr);
+cb(mname);
+}
+
+qtest_end();
+QDECREF(response);
+}
diff --git a/tests/libqtest.h b/tests/libqtest.h
index 2c9962d..43ffadd 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -917,4 +917,12 @@ void qmp_fd_send(int fd, const char *fmt, ...);
 QDict *qmp_fdv(int fd, const char *fmt, va_list ap);
 QDict *qmp_fd(int fd, const char *fmt, ...);

+/**
+ * qtest_cb_for_every_machine:
+ * @cb: Pointer to the callback function
+ *
+ *  Call a callback function for every name of all available machines.
+ */
+void qtest_cb_for_every_machine(void (*cb)(const char *machine));
+
 #endif
diff --git a/tests/pc-cpu-test.c b/tests/pc-cpu-test.c
index c3a2633..c4211a4 100644
--- a/tests/pc-cpu-test.c
+++ b/tests/pc-cpu-test.c
@@ -79,69 +79,46 @@ static void test_data_free(gpointer data)
 g_free(pc);
 }

-static void add_pc_test_cases(void)
+static void add_pc_test_case(const char *mname)
 {
-QDict *response, *minfo;
-QList *list;
-const QListEntry *p;
-QObject *qobj;
-QString *qstr;
-const char *mname;
 char *path;
 PCTestData *data;

-qtest_start("-machine none");
-response = qmp("{ 'execute': 'query-machines' }");
-g_assert(response);
-list = qdict_get_qlist(response, "return");
-g_assert(list);
-
-for (p = qlist_first(list); p; p = qlist_next(p)) {
-minfo = qobject_to_qdict(qlist_entry_obj(p));
-g_assert(minfo);
-qobj = qdict_get(minfo, "name");
-g_assert(qobj);
-qstr = qobject_to_qstring(qobj);
-g_assert(qstr);
-mname = qstring_get_str(qstr);
-if (!g_str_has_prefix(mname, "pc-")) {
-continue;
-}
-data = g_malloc(sizeof(PCTestData));
-data->machine = g_strdup(mname);
-data->cpu_model = "Haswell"; /* 1.3+ theoretically */
-data->sockets = 1;
-data->cores = 3;
-data->threads = 2;
-data->maxcpus = data->sockets * data->cores * data->threads * 2;
-if (g_str_has_suffix(mname, "-1.4") ||
-(strcmp(mname, "pc-1.3") == 0) ||
-(strcmp(mname, "pc-1.2") == 0) ||
-(strcmp(mname, "pc-1.1") == 0) ||
-(strcmp(mname, "pc-1.0") == 0) ||
-(strcmp(mname, "pc-0.15") == 0) ||
-(strcmp(mname, "pc-0.14") == 0) ||
-(strcmp(mname, "pc-0.13") == 0) ||
-(strcmp(mname, "pc-0.12") == 0) ||
-(strcmp(mname, "pc-0.11") == 0) ||
-(strcmp(mname, "pc-0.10") == 0)) {
-path = g_strdup_printf("cpu/%s/init/%ux%ux%u&maxcpus=%u",
-   mname, data->sockets, data->cores,
-   data->threads, data->maxcpus);
-qtest_add_data_func_full(path, data, test_pc_without_cpu_add,
- test_data_free);
-g_free(path);
-} else {
-path = g_strdup_printf("cpu/%s/add/%ux%ux%u&maxcpus=%u",
-   mname, data->sockets, data->cores,
-   data->threads, data->maxcpus);
-qtest_add_data_func_full(path, data, test_pc_with_cpu_add,
- test_data_free);
-g_free(path);
-}
+if (!g_str_has_prefix(mname, "pc-")) {
+return;
+}
+data = g_malloc(sizeof(PCTestData));
+data->machine = g_strdup(mname);
+data->cpu_model = "Haswell"; /* 1.3+ theoretically */
+data->sockets = 1;

Re: [Qemu-devel] hitting intermittent issue with live migration from qemu-kvm-ev 2.3.0 to qemu-kvm-ev 2.6.0

[Stefan Hajnoczi]

On Fri, Mar 31, 2017 at 02:12:36PM -0600, Chris Friesen wrote:
> I'm running into an issue with live-migrating a guest from a host running
> qemu-kvm-ev 2.3.0-31 to a host running qemu-kvm-ev 2.6.0-27.1.  This is a
> libvirt-tunnelled migration, in the context of upgrading an OpenStack
> install to newer software.  The source host is running CentOS 7.2.1511,
> while the dest host is running CentOS 7.3.1611.
> 
> I'll include the qemu commandlines for the source/dest at the bottom.
> 
> Initially we have a bunch of guests running on compute-2 (which is running
> qemu-kvm-ev 2.3.0).  We then started live-migrating them one at a time to
> compute-0 (which is running qemu-kvm-ev 2.6.0).  Three of them migrated
> successfully.  The fourth (which was essentially identical in configuration
> to the first three) failed, as per the following logs in
> /var/log/libvirt/qemu/instance-000e.log:
> 
> 
> 2017-03-29T06:38:37.886940Z qemu-kvm: VQ 2 size 0x80 < last_avail_idx 0x47b
> - used_idx 0x47c
> 2017-03-29T06:38:37.886974Z qemu-kvm: error while loading state for instance
> 0x0 of device ':00:07.0/virtio-balloon'
> 2017-03-29T06:38:37.888684Z qemu-kvm: load of migration failed: Operation
> not permitted
> 2017-03-29 06:38:37.896+: shutting down
> 
> 
> Does anyone know of an existing bug report covering this issue?  (I took a
> look and didn't see anything obviously related.)

This is the virtio-balloon device.  If you remove the device the live
migration should work reliably.

Alternatively, you can temporarily rmmod virtio_balloon inside the guest
for live migration.  After migration you can modprobe virtio_balloon
again.

last_avail_idx 0x47b with used_idx 0x47c is an invalid device state.
I've diffed qemu-kvm-ev 2.6.0-27.1 hw/virtio/virtio-balloon.c against
qemu.git/master and do not see an obvious bug.  I also compared
qemu-kvm-ev 2.3.0-31 with qemu-kvm-ev 2.6.0-27.1.

> 
> 
> The qemu commandline on the source compute node is:
> 
> 
> /usr/libexec/qemu-kvm -c 0x0001 -n 4
> --proc-type=secondary --file-prefix=vs -- -enable-dpdk -name
> instance-000e -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off -m 512
> -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object 
> memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/mnt/huge-2048kB/libvirt/qemu,share=yes,size=536870912,host-nodes=1,policy=bind
> -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid
> 57ae849f-aa66-422a-90a2-62db6c59db29 -smbios type=1,manufacturer=Fedora
> Project,product=OpenStack 
> Nova,version=13.0.0-0.tis.4,serial=4c8121f1-d927-424e-8712-88b1de45be37,uuid=57ae849f-aa66-422a-90a2-62db6c59db29,family=Virtual
> Machine -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-000e/monitor.sock,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew
> -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot
> reboot-timeout=5000,strict=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
> file=/dev/disk/by-path/ip-192.168.205.6:3260-iscsi-iqn.2010-10.org.openstack:volume-ac57fcaa-7ecd-4d3b-8671-3bc740337a42-lun-0,if=none,id=drive-virtio-disk0,format=raw,serial=ac57fcaa-7ecd-4d3b-8671-3bc740337a42,cache=none,aio=native
> -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> -chardev 
> socket,id=charnet0,path=/var/run/vswitch/usvhost-9e574d3c-32dd-4d39-97e6-447b15fb00b4
> -netdev type=vhost-user,id=hostnet0,chardev=charnet0 -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:b0:59:a9,bus=pci.0,addr=0x3
> -chardev 
> socket,id=charnet1,path=/var/run/vswitch/usvhost-7bc48d91-f215-4394-99ff-eb7f20d9ff1e
> -netdev type=vhost-user,id=hostnet1,chardev=charnet1 -device 
> virtio-net-pci,netdev=hostnet1,id=net1,mac=fa:16:3e:8b:6f:09,bus=pci.0,addr=0x4
> -chardev 
> socket,id=charnet2,path=/var/run/vswitch/usvhost-c32e2d0d-9ed4-4f4b-abc9-539a12a86008
> -netdev type=vhost-user,id=hostnet2,chardev=charnet2 -device 
> virtio-net-pci,netdev=hostnet2,id=net2,mac=fa:16:3e:07:ca:a0,bus=pci.0,addr=0x5
> -chardev 
> file,id=charserial0,path=/etc/nova/instances/57ae849f-aa66-422a-90a2-62db6c59db29/console.log
> -device isa-serial,chardev=charserial0,id=serial0 -chardev
> pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device
> usb-tablet,id=input0 -vnc 0.0.0.0:11 -k en-us -device
> cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming fd:25 -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on
> 
> 
> 
> The complete instance-000e.log file on the destination is:
> 
> 2017-03-29 06:38:35.962+: starting up libvirt version: 2.0.0, package:
> 10.el7_3.2.tis.24 (Unknown, 2017-03-15-14:59:22,
> yow-dsulliva-lx-vm1.wrs.com), qemu version: 2.6.0
> (qemu-kvm-ev-2.6.0-27.1.el7.tis.31), hostname: compute-0
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> QEMU_AUDIO_DRV=none /usr/l

Re: [Qemu-devel] [PATCH v2 for-2.10 07/16] block/file-posix: Generalize raw_regular_truncate

[Philippe Mathieu-Daudé]

On 04/03/2017 01:09 PM, Max Reitz wrote:

Currently, raw_regular_truncate() is intended for setting the size of a
newly created file. However, we also want to use it for truncating an
existing file in which case only the newly added space (when growing)
should be preallocated.

This also means that if resizing failed, we should try to restore the
original file size. This is important when using preallocation.

Signed-off-by: Max Reitz 


Reviewed-by: Philippe Mathieu-Daudé 


---
 block/file-posix.c | 61 --
 1 file changed, 50 insertions(+), 11 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index e6b6fa30ce..d99ca3d6e8 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1407,11 +1407,31 @@ static void raw_close(BlockDriverState *bs)
 }
 }

+/**
+ * Truncates the given regular file @fd to @offset and, when growing, fills the
+ * new space according to @prealloc.
+ *
+ * Returns: 0 on success, -errno on failure.
+ */
 static int raw_regular_truncate(int fd, int64_t offset, PreallocMode prealloc,
 Error **errp)
 {
 int result = 0;
-char *buf;
+int64_t current_length = 0;
+char *buf = NULL;
+struct stat st;
+
+if (fstat(fd, &st) < 0) {
+result = -errno;
+error_setg_errno(errp, -result, "Could not stat file");
+return result;
+}
+
+current_length = st.st_size;
+if (current_length > offset && prealloc != PREALLOC_MODE_OFF) {
+error_setg(errp, "Cannot use preallocation for shrinking files");
+return -ENOTSUP;
+}

 switch (prealloc) {
 #ifdef CONFIG_POSIX_FALLOCATE
@@ -1421,17 +1441,17 @@ static int raw_regular_truncate(int fd, int64_t offset, 
PreallocMode prealloc,
  * file systems that do not support fallocate(), trying to check if a
  * block is allocated before allocating it, so don't do that here.
  */
-result = -posix_fallocate(fd, 0, offset);
+result = -posix_fallocate(fd, current_length, offset - current_length);
 if (result != 0) {
 /* posix_fallocate() doesn't set errno. */
 error_setg_errno(errp, -result,
- "Could not preallocate data for the new file");
+ "Could not preallocate new data");
 }
-return result;
+goto out;
 #endif
 case PREALLOC_MODE_FULL:
 {
-int64_t num = 0, left = offset;
+int64_t num = 0, left = offset - current_length;

 /*
  * Knowing the final size from the beginning could allow the file
@@ -1441,19 +1461,27 @@ static int raw_regular_truncate(int fd, int64_t offset, 
PreallocMode prealloc,
 if (ftruncate(fd, offset) != 0) {
 result = -errno;
 error_setg_errno(errp, -result, "Could not resize file");
-return result;
+goto out;
 }

 buf = g_malloc0(65536);

+result = lseek(fd, current_length, SEEK_SET);
+if (result < 0) {
+result = -errno;
+error_setg_errno(errp, -result,
+ "Failed to seek to the old end of file");
+goto out;
+}
+
 while (left > 0) {
 num = MIN(left, 65536);
 result = write(fd, buf, num);
 if (result < 0) {
 result = -errno;
 error_setg_errno(errp, -result,
- "Could not write to the new file");
-break;
+ "Could not write zeros for preallocation");
+goto out;
 }
 left -= result;
 }
@@ -1462,11 +1490,11 @@ static int raw_regular_truncate(int fd, int64_t offset, 
PreallocMode prealloc,
 if (result < 0) {
 result = -errno;
 error_setg_errno(errp, -result,
- "Could not flush new file to disk");
+ "Could not flush file to disk");
+goto out;
 }
 }
-g_free(buf);
-return result;
+goto out;
 }
 case PREALLOC_MODE_OFF:
 if (ftruncate(fd, offset) != 0) {
@@ -1480,6 +1508,17 @@ static int raw_regular_truncate(int fd, int64_t offset, 
PreallocMode prealloc,
PreallocMode_lookup[prealloc]);
 return result;
 }
+
+out:
+if (result < 0) {
+if (ftruncate(fd, current_length) < 0) {
+error_report("Failed to restore old file length: %s",
+ strerror(errno));
+}
+}
+
+g_free(buf);
+return result;
 }

 static int raw_truncate(BlockDriverState *bs, int64_t offset,

Re: [Qemu-devel] [PATCH v2 1/3] libqtest: Ignore QMP events when parsing the response for HMP commands

[John Snow]

On 03/30/2017 03:50 AM, Thomas Huth wrote:
> When running certain HMP commands (like "device_del") via QMP, we
> can sometimes get a QMP event in the response first, so that the
> "g_assert(ret)" statement in qtest_hmp() triggers and the test
> fails. Fix this by ignoring such QMP events while looking for the
> real return value from QMP.
> 
> Signed-off-by: Thomas Huth 
> ---
>  tests/libqtest.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index a5c3d2b..c9b2d76 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -580,6 +580,12 @@ char *qtest_hmpv(QTestState *s, const char *fmt, va_list 
> ap)
>   " 'arguments': {'command-line': %s}}",
>   cmd);
>  ret = g_strdup(qdict_get_try_str(resp, "return"));
> +while (ret == NULL && qdict_get_try_str(resp, "event")) {
> +/* Ignore asynchronous QMP events */
> +QDECREF(resp);
> +resp = qtest_qmp_receive(s);
> +ret = g_strdup(qdict_get_try_str(resp, "return"));
> +}
>  g_assert(ret);
>  QDECREF(resp);
>  g_free(cmd);
> 

You've probably been asked this, but can you just shove the QMP response
you don't want into the event queue for consumption by other calls?

--js

Re: [Qemu-devel] [PATCH for-2.9 4/5] rbd: Peel off redundant RbdAuthMethod wrapper struct

[Eric Blake]

On 04/03/2017 06:25 AM, Daniel P. Berrange wrote:
> On Mon, Mar 27, 2017 at 07:58:51AM +0200, Markus Armbruster wrote:
>> = What to do for 2.9 =
>>
>> I propose to
>>
>> * drop both "auth_supported" and "password-secret" from the QAPI schema
>>
>> * drop "password-secret" from QemuOpts
>>
>> * hide "keyvalue-pairs" in QemuOpts
>>
>> No existing usage is affected, since all these things are new in 2.9.
> 
> Maybe I'm mis-understanding what you're suggesting wrt QemuOpts, but
> 'password-secret' with RBD is not new in 2.9.0

We updated things in the respin of this series; the actual committed
version (ending in commit d1c13688) did NOT kill password-secret from
QemuOpts, but merely removed it from QMP (it was the QMP portion that
was attempted to be new in 2.9).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 for-2.10 06/16] block/file-posix: Extract raw_regular_truncate()

[Philippe Mathieu-Daudé]

On 04/03/2017 01:09 PM, Max Reitz wrote:

This functionality is part of raw_create() which we will be able to
reuse nicely in raw_truncate().

Signed-off-by: Max Reitz 
Reviewed-by: Stefan Hajnoczi 


Reviewed-by: Philippe Mathieu-Daudé 


---
 block/file-posix.c | 144 +
 1 file changed, 78 insertions(+), 66 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index cab77db963..e6b6fa30ce 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1407,6 +1407,81 @@ static void raw_close(BlockDriverState *bs)
 }
 }

+static int raw_regular_truncate(int fd, int64_t offset, PreallocMode prealloc,
+Error **errp)
+{
+int result = 0;
+char *buf;
+
+switch (prealloc) {
+#ifdef CONFIG_POSIX_FALLOCATE
+case PREALLOC_MODE_FALLOC:
+/*
+ * Truncating before posix_fallocate() makes it about twice slower on
+ * file systems that do not support fallocate(), trying to check if a
+ * block is allocated before allocating it, so don't do that here.
+ */
+result = -posix_fallocate(fd, 0, offset);
+if (result != 0) {
+/* posix_fallocate() doesn't set errno. */
+error_setg_errno(errp, -result,
+ "Could not preallocate data for the new file");
+}
+return result;
+#endif
+case PREALLOC_MODE_FULL:
+{
+int64_t num = 0, left = offset;
+
+/*
+ * Knowing the final size from the beginning could allow the file
+ * system driver to do less allocations and possibly avoid
+ * fragmentation of the file.
+ */
+if (ftruncate(fd, offset) != 0) {
+result = -errno;
+error_setg_errno(errp, -result, "Could not resize file");
+return result;
+}
+
+buf = g_malloc0(65536);
+
+while (left > 0) {
+num = MIN(left, 65536);
+result = write(fd, buf, num);
+if (result < 0) {
+result = -errno;
+error_setg_errno(errp, -result,
+ "Could not write to the new file");
+break;
+}
+left -= result;
+}
+if (result >= 0) {
+result = fsync(fd);
+if (result < 0) {
+result = -errno;
+error_setg_errno(errp, -result,
+ "Could not flush new file to disk");
+}
+}
+g_free(buf);
+return result;
+}
+case PREALLOC_MODE_OFF:
+if (ftruncate(fd, offset) != 0) {
+result = -errno;
+error_setg_errno(errp, -result, "Could not resize file");
+}
+return result;
+default:
+result = -ENOTSUP;
+error_setg(errp, "Unsupported preallocation mode: %s",
+   PreallocMode_lookup[prealloc]);
+return result;
+}
+}
+
 static int raw_truncate(BlockDriverState *bs, int64_t offset,
 PreallocMode prealloc, Error **errp)
 {
@@ -1675,72 +1750,9 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 #endif
 }

-switch (prealloc) {
-#ifdef CONFIG_POSIX_FALLOCATE
-case PREALLOC_MODE_FALLOC:
-/*
- * Truncating before posix_fallocate() makes it about twice slower on
- * file systems that do not support fallocate(), trying to check if a
- * block is allocated before allocating it, so don't do that here.
- */
-result = -posix_fallocate(fd, 0, total_size);
-if (result != 0) {
-/* posix_fallocate() doesn't set errno. */
-error_setg_errno(errp, -result,
- "Could not preallocate data for the new file");
-}
-break;
-#endif
-case PREALLOC_MODE_FULL:
-{
-int64_t num = 0, left = total_size;
-
-/*
- * Knowing the final size from the beginning could allow the file
- * system driver to do less allocations and possibly avoid
- * fragmentation of the file.
- */
-if (ftruncate(fd, total_size) != 0) {
-result = -errno;
-error_setg_errno(errp, -result, "Could not resize file");
-goto out_close;
-}
-
-buf = g_malloc0(65536);
-
-while (left > 0) {
-num = MIN(left, 65536);
-result = write(fd, buf, num);
-if (result < 0) {
-result = -errno;
-error_setg_errno(errp, -result,
- "Could not write to the new file");
-break;
-}
-left -= result;
-}
-if (result >= 0) {
-result = fsync(fd);
-if (result < 0) {
-result = -errno;
-error_setg_errno(errp, -result,
- "

Re: [Qemu-devel] [PATCH v2 for-2.10 05/16] block/file-posix: Small fixes in raw_create()

[Philippe Mathieu-Daudé]

On 04/03/2017 01:09 PM, Max Reitz wrote:

Variables should be declared at the start of a block, and if a certain
parameter value is not supported it may be better to return -ENOTSUP
instead of -EINVAL.

Signed-off-by: Max Reitz 
Reviewed-by: Stefan Hajnoczi 


Reviewed-by: Philippe Mathieu-Daudé 


---
 block/file-posix.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 3e9c416668..cab77db963 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1693,6 +1693,8 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 #endif
 case PREALLOC_MODE_FULL:
 {
+int64_t num = 0, left = total_size;
+
 /*
  * Knowing the final size from the beginning could allow the file
  * system driver to do less allocations and possibly avoid
@@ -1704,7 +1706,6 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 goto out_close;
 }

-int64_t num = 0, left = total_size;
 buf = g_malloc0(65536);

 while (left > 0) {
@@ -1736,7 +1737,7 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 }
 break;
 default:
-result = -EINVAL;
+result = -ENOTSUP;
 error_setg(errp, "Unsupported preallocation mode: %s",
PreallocMode_lookup[prealloc]);
 break;

Re: [Qemu-devel] [PATCH v4] Allow setting NUMA distance for different NUMA nodes

[Eric Blake]

On 04/03/2017 03:38 AM, Andrew Jones wrote:
> On Sat, Apr 01, 2017 at 06:25:26PM +0800, He Chen wrote:
>> Current, QEMU does not provide a clear command to set vNUMA distance for
>> guest although we already have `-numa` command to set vNUMA nodes.
>>

>> +++ b/qapi-schema.json
>> @@ -5644,10 +5644,14 @@
>>  ##
>>  # @NumaOptionsType:
>>  #
>> +# @node: NUMA nodes configuration
>> +#
>> +# @dist: NUMA distance configuration
>> +#

Missing a '(since 2.10)' tag on @dist.


>>  ##
>> +# @NumaDistOptions:
>> +#
>> +# Set the distance between 2 NUMA nodes.
>> +#
>> +# @src: source NUMA node.
>> +#
>> +# @dst: destination NUMA node.
>> +#
>> +# @val: NUMA distance from source node to destination node.

Missing mention of the magic of 255.

>> +#
>> +# Since: 2.10
>> +##
>> +{ 'struct': 'NumaDistOptions',
>> +  'data': {
>> +   'src': 'uint16',
>> +   'dst': 'uint16',
>> +   'val': 'uint8' }}
>> +

Is a user allowed to pass { "src":0, "dst":0, "val":11 }, or do you
hard-validate that the diagonal of the matrix is always 10 (the user can
omit it, but if specified it must be 10).  Do you enforce that no
distance is less than 10?

>> +@var{source} and @var{destination} are NUMA node IDs.
>> +@var{distance} is the NUMA distance from @var{source} to @var{destination}.
>> +The distance from node A to node B may be different from the distance from
>> +node B to node A as the distance can to be asymmetrical. If a node is
>> +unreachable, set 255 as distance.
> 
> The distance from a node to itself is always 10.  If no distance values
> are given for node pairs, then the default distance of 20 is used for each
> pair.  If any pair of nodes is given a distance, then all pairs must be
> given distances.  Although, when distances are only given in one direction
> for each pair of nodes, then the distances in the opposite directions are
> assumed to be the same.  If, however, an asymmetrical pair of distances is
> given for even one node pair, then all node pairs must be provided
> distance values for both directions, even when they are symmetrical.  When
> a node is unreachable from another node, set the pair's distance to 255.

I don't like duplication where it is not necessary, but don't know if
there's an easy way to make the .json file and qemu-options.hx refer to
one another, since they both feed separate user-visible documentation.
So you may have to repeat some of this in the .json file (such as my
mention above that at least documenting that 255 is special).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

[Kashyap Chamarthy]

On Fri, Mar 31, 2017 at 05:49:52PM +, Ciprian Barbu wrote:
> Hi,

[...]

> We also use libvirt v1.3.4, which might be a problem, but at least we
> want to understand if the commit in question introduced an obvious
> problem or if it's all in the details.

A tangential question -- Just curious, your environment
seems...interesting: given you are using a bit old (but above the
MIN_LIBVIRT_VERSION for Nova, which is currently 1.2.1) libvirt version,
with *RC2* of QEMU 2.9 with Nova, and testing live migration.  Me
wonders if this some kind of a custom OpenStack environment, or an
official upstream release that you're simply testing with a newer
version of QEMU...


[1]
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=068d851#n198

> 
> Btw, the qemu command generated by libvirt is this one, sorry about that:
> 
> 2017-03-31 17:40:10.956+: starting up libvirt version: 1.3.4, package: 
> 0+amos3~u16.04 (Enea Armband Devops Team  Fri, 13 Jan 2017 
> 02:06:05 +0100), qemu version: 2.8.50(Debian 1:2.9+amos2~u16.04), hostname: 
> node-2.domain.tld
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
> QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-0076,debug-threads=on -S 
> -object 
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-14-instance-0076/master-key.aes
>  -machine virt-2.8,accel=kvm,usb=off,gic-version=3 -cpu host -m 256 -realtime 
> mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
> 2812f3c9-f564-499b-a8c7-e9e7ccf24143 -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-14-instance-0076/monitor.sock,server,nowait
>  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
> -no-shutdown -boot strict=on -kernel 
> /var/lib/nova/instances/2812f3c9-f564-499b-a8c7-e9e7ccf24143/kernel -initrd 
> /var/lib/nova/instances/2812f3c9-f564-499b-a8c7-e9e7ccf24143/ramdisk -append 
> 'root=/dev/vda1 rw rootwait console=tty0 console=ttyS0 console=ttyAMA0' 
> -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 -device 
> pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -usb -drive 
> file=/var/lib/nova/instances/2812f3c9-f564-499b-a8c7-e9e7ccf24143/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,aio=native
>  -device 
> virtio-blk-device,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
>  -drive 
> file=/var/lib/nova/instances/2812f3c9-f564-499b-a8c7-e9e7ccf24143/disk.config,format=raw,if=none,id=drive-virtio-disk1,cache=none,aio=native
>  -device virtio-blk-device,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1 
> -netdev tap,fd=27,id=hostnet0 -device 
> virtio-net-device,netdev=hostnet0,id=net0,mac=fa:16:3e:82:0a:2b -serial 
> file:/var/lib/nova/instances/2812f3c9-f564-499b-a8c7-e9e7ccf24143/console.log 
> -serial pty -vnc 0.0.0.0:0 -k en-us -device 
> VGA,id=video0,vgamem_mb=16,bus=pci.2,addr=0x1 -device 
> virtio-balloon-device,id=balloon0 -msg timestamp=on
> Domain id=14 is tainted: high-privileges

[...]


-- 
/kashyap

Re: [Qemu-devel] [PATCH v5 3/5] slirp: Common lhost/fhost union

[Philippe Mathieu-Daudé]

On 04/03/2017 02:18 PM, Dr. David Alan Gilbert (git) wrote:

From: "Dr. David Alan Gilbert" 

The socket structure has a pair of unions for lhost and fhost
addresses; the unions are identical so split them out into
a separate union declaration.

Signed-off-by: Dr. David Alan Gilbert 


Reviewed-by: Philippe Mathieu-Daudé 


---
 slirp/socket.h | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/slirp/socket.h b/slirp/socket.h
index 8feed2a..c1be77e 100644
--- a/slirp/socket.h
+++ b/slirp/socket.h
@@ -15,6 +15,12 @@
  * Our socket structure
  */

+union slirp_sockaddr {
+struct sockaddr_storage ss;
+struct sockaddr_in sin;
+struct sockaddr_in6 sin6;
+};
+
 struct socket {
   struct socket *so_next,*so_prev;  /* For a linked list of sockets */

@@ -31,22 +37,14 @@ struct socket {
   struct tcpiphdr *so_ti; /* Pointer to the original ti within
* so_mconn, for non-blocking connections */
   int so_urgc;
-  union {   /* foreign host */
-  struct sockaddr_storage ss;
-  struct sockaddr_in sin;
-  struct sockaddr_in6 sin6;
-  } fhost;
+  union slirp_sockaddr fhost;  /* Foreign host */
 #define so_faddr fhost.sin.sin_addr
 #define so_fport fhost.sin.sin_port
 #define so_faddr6 fhost.sin6.sin6_addr
 #define so_fport6 fhost.sin6.sin6_port
 #define so_ffamily fhost.ss.ss_family

-  union {   /* local host */
-  struct sockaddr_storage ss;
-  struct sockaddr_in sin;
-  struct sockaddr_in6 sin6;
-  } lhost;
+  union slirp_sockaddr lhost;  /* Local host */
 #define so_laddr lhost.sin.sin_addr
 #define so_lport lhost.sin.sin_port
 #define so_laddr6 lhost.sin6.sin6_addr

Re: [Qemu-devel] [PATCH for-2.9 1/2] block/mirror: Fix use-after-free

[Philippe Mathieu-Daudé]

nice analysis/catch

On 04/03/2017 02:51 PM, Max Reitz wrote:

If @bs does not have any parents, the only reference to @mirror_top_bs
will be held by the BlockJob object after the bdrv_unref() following
block_job_create(). However, if block_job_create() fails, this reference
will not exist and @mirror_top_bs will have been deleted when we
goto fail.

The issue comes back at all later entries to the fail label: We delete
the BlockJob object before rolling back our changes to the node graph.
This means that we will delete @mirror_top_bs in the process.

All in all, whenever @bs does not have any parents and we go down the
fail path we will dereference @mirror_top_bs after it has been deleted.

Fix this by invoking bdrv_unref() only when block_job_create() was
successful and by bdrv_ref()'ing @mirror_top_bs in the fail path before
deleting the BlockJob object. Finally, bdrv_unref() it at the end of the
fail path after we actually no longer need it.

Signed-off-by: Max Reitz 


Reviewed-by: Philippe Mathieu-Daudé 


---
 block/mirror.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index 9e2fecc15e..46ecd38ef0 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1150,7 +1150,7 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
 mirror_top_bs->total_sectors = bs->total_sectors;

 /* bdrv_append takes ownership of the mirror_top_bs reference, need to keep
- * it alive until block_job_create() even if bs has no parent. */
+ * it alive until block_job_create() succeeds even if bs has no parent. */
 bdrv_ref(mirror_top_bs);
 bdrv_drained_begin(bs);
 bdrv_append(mirror_top_bs, bs, &local_err);
@@ -1168,10 +1168,12 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
  BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
  BLK_PERM_WRITE | BLK_PERM_GRAPH_MOD, speed,
  creation_flags, cb, opaque, errp);
-bdrv_unref(mirror_top_bs);
 if (!s) {
 goto fail;
 }
+/* The block job now has a reference to this node */
+bdrv_unref(mirror_top_bs);
+
 s->source = bs;
 s->mirror_top_bs = mirror_top_bs;

@@ -1242,6 +1244,10 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,

 fail:
 if (s) {
+/* Make sure this BDS does not go away until we have completed the 
graph
+ * changes below */
+bdrv_ref(mirror_top_bs);
+
 g_free(s->replaces);
 blk_unref(s->target);
 block_job_unref(&s->common);
@@ -1250,6 +1256,8 @@ fail:
 bdrv_child_try_set_perm(mirror_top_bs->backing, 0, BLK_PERM_ALL,
 &error_abort);
 bdrv_replace_node(mirror_top_bs, backing_bs(mirror_top_bs), &error_abort);
+
+bdrv_unref(mirror_top_bs);
 }

 void mirror_start(const char *job_id, BlockDriverState *bs,

Re: [Qemu-devel] [RFC 13/19] unimplemented-device: Remove user_creatable flag

[Eduardo Habkost]

On Mon, Apr 03, 2017 at 03:08:06PM +0100, Peter Maydell wrote:
> On 3 April 2017 at 14:54, Eduardo Habkost  wrote:
> > On Mon, Apr 03, 2017 at 02:38:15PM +0100, Peter Maydell wrote:
> >> On 3 April 2017 at 14:34, Eduardo Habkost  wrote:
> >> >> Wouldn't it be better to just not add that, rather than
> >> >> add it and then delete it?
> >> >
> >> > The device was already user-creatable
> >>
> >> It doesn't seem to be:
> >>
> >>  ./build/x86/arm-softmmu/qemu-system-arm -M virt -device
> >> unimplemented-device,size=1024,name=foo
> >> qemu-system-arm: Device unimplemented-device can not be dynamically 
> >> instantiated
> >
> > This restriction is implemented by the "virt" machine, not by the
> > device type itself.
> >
> > This, on the other hand, currently works:
> >   $ qemu-system-x86_64 -M q35 -device 
> > unimplemented-device,size=1024,name=foo
> 
> That's a bug in the q35 machine or the handling of -device
> on non-platform-bus systems, though, isn't it? The default
> for all sysbus devices has always been "you can't use
> -device with this", [...]

This was true until 2014, only. commit
33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 changed sys-bus-device
to have cannot_instantiate_with_device_add_yet=false. See patch
03/19 for more detailed info.

>   [...] there's never been a requirement to
> mark them as such separately (because it would require
> touching the files for a huge number of devices for no
> particularly good reason when you can default the whole
> set of devices subclassing SysBusDevice).

Yes, and this is the whole point of this series. At the end of
this series, only the few devices that are actually usable with
some machine will have an explicit user_creatable=true
assignment. See cover letter for details.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives

[Andrew Baumann via Qemu-devel]

> From: Cornelia Huck [mailto:cornelia.h...@de.ibm.com]
> Sent: Monday, 3 April 2017 7:20
> 
> On Fri, 24 Mar 2017 15:01:41 -0700
> Andrew Baumann  wrote:
> 
> > From: Andrey Shedel 
> >
> > The multithreaded TCG implementation exposed deadlocks in the win32
> > condition variables: as implemented, qemu_cond_broadcast waited on
> > receivers, whereas the pthreads API it was intended to emulate does
> > not. This was causing a deadlock because broadcast was called while
> > holding the IO lock, as well as all possible waiters blocked on the
> > same lock.
> >
> > This patch replaces all the custom synchronisation code for mutexes
> > and condition variables with native Windows primitives (SRWlocks and
> > condition variables) with the same semantics as their POSIX
> > equivalents. To enable that, it requires a Windows Vista or newer host
> > OS.
> >
> > [AB: edited commit message]
> > Signed-off-by: Andrew Baumann 
> > ---
> > The major implication of this patch is that it drops support for
> > pre-Vista versions of Windows. However, those OSes are past their end
> > of life, and other OSS projects have dropped support. e.g.; the last
> > Cygwin release supporting XP was in Jun 2016. It doesn't seem like a
> > good tradeoff to invest effort in fixing broken code needed to support
> > them, so hopefully this isn't too controversial.
> 
> Just a quick question:
> 
> I noticed that this breaks builds on an old fc20-based installation I
> run some mingw cross builds on (getting an undefined reference to
> `_imp__TryAcquireSRWLockExclusive@4'). I should probably take that as a
> trigger to update that installation ;), but wanted to confirm that this
> is expected.

Yes, please try updating your mingw headers. I've done x64 cross-builds from 
Ubuntu 16.04 (WSL) using mingw-w64 4.0.4.

Andrew

Re: [Qemu-devel] Project idea

[Stefan Hajnoczi]

On Fri, Mar 31, 2017 at 09:20:31PM +0300, Mihai-Drosi Caju wrote:
> I'd be interested in submitting the following ideas:
> I'd like to enchance qemu's debugging capabilities.
> I was thinking to add an option to qemu to disable cpu reset on
> tripple-fault.
> Or adding support for breakpoints in the GDB stub while using kvm or
> another accelerator.
> Or emulating a JTAG port on a pty that would interface with the virtual
> CPU.

If you wanted to propose a custom project idea for Google Summer of Code
I'm afraid the application deadline has passed.

Custom project ideas require finding a mentor.  It usually takes at
least 2 weeks and also requires discussing the details of the project
idea.

You are welcome to contribute to QEMU outside of GSoC.  Guidelines on
submitting a patch are here:
http://wiki.qemu-project.org/Contribute/SubmitAPatch

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] Raspberry PI

[John Snow]

On 04/02/2017 03:59 PM, John Bradley via Qemu-devel wrote:
> Hi,
> I've just pulled together a collection of patches from various sources to get 
> the Raspberry PI emulation working on the March 27 source. Is it worth 
> sending it in as a patch for inclusion. It allows some of the Circle low 
> level demo to run.
> 
> 
>  John BradleyTel: 07896 839635Skype: flypie125 125B Grove StreetEdge Hill 
> Liverpool L7 7AF
> 

If you are willing to commit to the review process of upstreaming this
code and creating revisions and so on, please do send patches!

If you're feeling like you're already done with the project, it may
still be useful to get a link to a git tree so others can at least see
the code, but without a steward they'll almost certainly not get merged.

--js

Re: [Qemu-devel] [PATCH] tests/libqtest.c: Delete possible stale unix sockets

[Stefan Hajnoczi]

On Fri, Mar 31, 2017 at 01:36:41PM +0100, Peter Maydell wrote:
> Occasionally if a test crashes or is interrupted by the user
> at the wrong moment it could leave behind a stale UNIX
> socket in /tmp/. This will then cause a subsequent test
> run to fail spuriously with
>  tests/libqtest.c:70:init_socket: assertion failed (ret != -1): (-1 != -1)
> if it happens to reuse the same PID.
> 
> Defend against this by deleting any stray stale socket before
> trying to open the new ones for this test.
> 
> Signed-off-by: Peter Maydell 
> ---
> This seems like an easy way to shut up this infrequent but irritating
> error case...
> 
>  tests/libqtest.c | 8 
>  1 file changed, 8 insertions(+)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH for-2.9 1/2] block/mirror: Fix use-after-free

[Max Reitz]

If @bs does not have any parents, the only reference to @mirror_top_bs
will be held by the BlockJob object after the bdrv_unref() following
block_job_create(). However, if block_job_create() fails, this reference
will not exist and @mirror_top_bs will have been deleted when we
goto fail.

The issue comes back at all later entries to the fail label: We delete
the BlockJob object before rolling back our changes to the node graph.
This means that we will delete @mirror_top_bs in the process.

All in all, whenever @bs does not have any parents and we go down the
fail path we will dereference @mirror_top_bs after it has been deleted.

Fix this by invoking bdrv_unref() only when block_job_create() was
successful and by bdrv_ref()'ing @mirror_top_bs in the fail path before
deleting the BlockJob object. Finally, bdrv_unref() it at the end of the
fail path after we actually no longer need it.

Signed-off-by: Max Reitz 
---
 block/mirror.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index 9e2fecc15e..46ecd38ef0 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1150,7 +1150,7 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
 mirror_top_bs->total_sectors = bs->total_sectors;
 
 /* bdrv_append takes ownership of the mirror_top_bs reference, need to keep
- * it alive until block_job_create() even if bs has no parent. */
+ * it alive until block_job_create() succeeds even if bs has no parent. */
 bdrv_ref(mirror_top_bs);
 bdrv_drained_begin(bs);
 bdrv_append(mirror_top_bs, bs, &local_err);
@@ -1168,10 +1168,12 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
  BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
  BLK_PERM_WRITE | BLK_PERM_GRAPH_MOD, speed,
  creation_flags, cb, opaque, errp);
-bdrv_unref(mirror_top_bs);
 if (!s) {
 goto fail;
 }
+/* The block job now has a reference to this node */
+bdrv_unref(mirror_top_bs);
+
 s->source = bs;
 s->mirror_top_bs = mirror_top_bs;
 
@@ -1242,6 +1244,10 @@ static void mirror_start_job(const char *job_id, 
BlockDriverState *bs,
 
 fail:
 if (s) {
+/* Make sure this BDS does not go away until we have completed the 
graph
+ * changes below */
+bdrv_ref(mirror_top_bs);
+
 g_free(s->replaces);
 blk_unref(s->target);
 block_job_unref(&s->common);
@@ -1250,6 +1256,8 @@ fail:
 bdrv_child_try_set_perm(mirror_top_bs->backing, 0, BLK_PERM_ALL,
 &error_abort);
 bdrv_replace_node(mirror_top_bs, backing_bs(mirror_top_bs), &error_abort);
+
+bdrv_unref(mirror_top_bs);
 }
 
 void mirror_start(const char *job_id, BlockDriverState *bs,
-- 
2.12.1

[Qemu-devel] [PATCH for-2.9 2/2] iotests: Add mirror tests for orphaned source

[Max Reitz]

Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/041| 46 +++
 tests/qemu-iotests/041.out|  4 ++--
 tests/qemu-iotests/iotests.py | 15 ++
 3 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/041 b/tests/qemu-iotests/041
index bc6cf782fe..2f54986434 100755
--- a/tests/qemu-iotests/041
+++ b/tests/qemu-iotests/041
@@ -966,5 +966,51 @@ class TestRepairQuorum(iotests.QMPTestCase):
 #   to check that this file is really driven by quorum
 self.vm.shutdown()
 
+# Test mirroring with a source that does not have any parents (not even a
+# BlockBackend)
+class TestOrphanedSource(iotests.QMPTestCase):
+def setUp(self):
+blk0 = { 'node-name': 'src',
+ 'driver': 'null-co' }
+
+blk1 = { 'node-name': 'dest',
+ 'driver': 'null-co' }
+
+blk2 = { 'node-name': 'dest-ro',
+ 'driver': 'null-co',
+ 'read-only': 'on' }
+
+self.vm = iotests.VM()
+self.vm.add_blockdev(self.qmp_to_opts(blk0))
+self.vm.add_blockdev(self.qmp_to_opts(blk1))
+self.vm.add_blockdev(self.qmp_to_opts(blk2))
+self.vm.launch()
+
+def tearDown(self):
+self.vm.shutdown()
+
+def test_no_job_id(self):
+self.assert_no_active_block_jobs()
+
+result = self.vm.qmp('blockdev-mirror', device='src', sync='full',
+ target='dest')
+self.assert_qmp(result, 'error/class', 'GenericError')
+
+def test_success(self):
+self.assert_no_active_block_jobs()
+
+result = self.vm.qmp('blockdev-mirror', job_id='job', device='src',
+ sync='full', target='dest')
+self.assert_qmp(result, 'return', {})
+
+self.complete_and_wait('job')
+
+def test_failing_permissions(self):
+self.assert_no_active_block_jobs()
+
+result = self.vm.qmp('blockdev-mirror', device='src', sync='full',
+ target='dest-ro')
+self.assert_qmp(result, 'error/class', 'GenericError')
+
 if __name__ == '__main__':
 iotests.main(supported_fmts=['qcow2', 'qed'])
diff --git a/tests/qemu-iotests/041.out b/tests/qemu-iotests/041.out
index b67d0504a6..e30fd3b05b 100644
--- a/tests/qemu-iotests/041.out
+++ b/tests/qemu-iotests/041.out
@@ -1,5 +1,5 @@
-
+...
 --
-Ran 76 tests
+Ran 79 tests
 
 OK
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index bec8eb4b8d..abcf3c10e2 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -177,6 +177,14 @@ class VM(qtest.QEMUQtestMachine):
 self._num_drives += 1
 return self
 
+def add_blockdev(self, opts):
+self._args.append('-blockdev')
+if isinstance(opts, str):
+self._args.append(opts)
+else:
+self._args.append(','.join(opts))
+return self
+
 def pause_drive(self, drive, event=None):
 '''Pause drive r/w operations'''
 if not event:
@@ -235,6 +243,13 @@ class QMPTestCase(unittest.TestCase):
 output[basestr[:-1]] = obj # Strip trailing '.'
 return output
 
+def qmp_to_opts(self, obj):
+obj = self.flatten_qmp_object(obj)
+output_list = list()
+for key in obj:
+output_list += [key + '=' + obj[key]]
+return ','.join(output_list)
+
 def assert_qmp_absent(self, d, path):
 try:
 result = self.dictpath(d, path)
-- 
2.12.1

[Qemu-devel] [PATCH for-2.9 0/2] block/mirror: Fix use-after-free

[Max Reitz]

And the exciting 2.9 ride continues!

When mirroring from a BDS with no parents at all (such as those added
with -blockdev or blockdev-add), we have a use-after-free in mirror's
error path. The first patch of this series fixes that, the other adds a
patch so we don't regress.

What issue will we find next? Stay tuned!


Max Reitz (2):
  block/mirror: Fix use-after-free
  iotests: Add mirror tests for orphaned source

 block/mirror.c| 12 +--
 tests/qemu-iotests/041| 46 +++
 tests/qemu-iotests/041.out|  4 ++--
 tests/qemu-iotests/iotests.py | 15 ++
 4 files changed, 73 insertions(+), 4 deletions(-)

-- 
2.12.1

Re: [Qemu-devel] [PATCH v5 0/5 for 2.10] SLIRP VMStatification

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 20170403171843.3363-1-dgilb...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH v5 0/5 for 2.10] SLIRP VMStatification

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20170401004624.30886-1-ehabk...@redhat.com -> 
patchew/20170401004624.30886-1-ehabk...@redhat.com
 * [new tag] patchew/20170403171843.3363-1-dgilb...@redhat.com -> 
patchew/20170403171843.3363-1-dgilb...@redhat.com
Switched to a new branch 'test'
b85f0d0 slirp: VMStatify remaining except for loop
6664e5e slirp: VMStatify socket level
b735a98 slirp: Common lhost/fhost union
049836c slirp: VMStatify sbuf
43cbd18 slirp: VMState conversion; tcpcb

=== OUTPUT BEGIN ===
Checking PATCH 1/5: slirp: VMState conversion; tcpcb...
ERROR: code indent should never use tabs
#211: FILE: slirp/tcp_var.h:51:
+^Iuint8_t t_force;^I^I/* 1 if forcing out a byte */$

ERROR: code indent should never use tabs
#221: FILE: slirp/tcp_var.h:112:
+^Iuint8_t^It_oobflags;^I^I/* have some */$

ERROR: code indent should never use tabs
#222: FILE: slirp/tcp_var.h:113:
+^Iuint8_t^It_iobc;^I^I^I/* input character */$

total: 3 errors, 0 warnings, 195 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/5: slirp: VMStatify sbuf...
ERROR: code indent should never use tabs
#26: FILE: slirp/sbuf.h:15:
+^Iuint32_t sb_cc;^I^I/* actual chars in buffer */$

ERROR: code indent should never use tabs
#27: FILE: slirp/sbuf.h:16:
+^Iuint32_t sb_datalen;^I/* Length of data  */$

total: 2 errors, 0 warnings, 155 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/5: slirp: Common lhost/fhost union...
Checking PATCH 4/5: slirp: VMStatify socket level...
ERROR: if this code is redundant consider removing it
#148: FILE: slirp/slirp.c:1352:
+#if 0

total: 1 errors, 0 warnings, 269 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 5/5: slirp: VMStatify remaining except for loop...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Dr. David Alan Gilbert]

* Patrick Ohly (patrick.o...@intel.com) wrote:
> On Mon, 2017-04-03 at 18:07 +0100, Daniel P. Berrange wrote:
> > On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > > Briefly, Theses set of patches introduces:
> > >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> > >  - and few supported fixes/enhancements/cleanup to existing tpm backend 
> > > code.
> > > 
> > > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with 
> > > slightly
> > > different approach, using CUSE. As swtpm has excellent support for unix 
> > > domain
> > > sockets, hence this implementation uses unix domain sockets to 
> > > communicate with
> > > swtpm.
> > > 
> > > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm' and
> > > communicates its via Unix domain sockets.
> > 
> > I'm not convinced that having QEMU spawning swtpm itself is a desirable
> > approach, as it means QEMU needs to have all the privileges that swtpm
> > will need, so that swtpm can inherit them.
> 
> The intended usage is for emulating a TPM in software, for example to do
> automated testing of an OS which requires a TPM or to do software
> development in an environment were it is easy to reset the TPM. That
> doesn't require any privileges, because swtpm just reads and writes
> files owned by the user who calls qemu.

Being able to do fancier permissions would let you use it in a real VM
situation so that the virtual guest sees it's own TPM; you would then
want to protect the TPM data files pretty carefully - for example stop
one compromised guest sniffing around the TPM data for another.

> >  At the very least I think we
> > need to have a way to disable this spawning, so it can connect to a
> > pre-existing swtpm process that's been spawned ahead of time. This will
> > let us have stricter privilege separation.
> 
> Which privileges and use cases did you have in mind?
> 
> swtpm already can be started so that it listens on a Unix domain socket,
> instead of inheriting something from the parent. It shouldn't be hard to
> add that as an alternative to the existing spawning code.
> 
> I can think of one use case: spawning swtpm in advance under debugging
> tools like gdb or valgrind. Is that enough justification for adding more
> code?

Or you could just remove the spawning code and use existing sockets; less code!

Dave

> -- 
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
> 
> 
> 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > Briefly, Theses set of patches introduces:
> >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> >  - and few supported fixes/enhancements/cleanup to existing tpm backend 
> > code.
> > 
> > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with 
> > slightly
> > different approach, using CUSE. As swtpm has excellent support for unix 
> > domain
> > sockets, hence this implementation uses unix domain sockets to communicate 
> > with
> > swtpm.
> > 
> > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm' and
> > communicates its via Unix domain sockets.
> 
> I'm not convinced that having QEMU spawning swtpm itself is a desirable
> approach, as it means QEMU needs to have all the privileges that swtpm
> will need, so that swtpm can inherit them. At the very least I think we
> need to have a way to disable this spawning, so it can connect to a
> pre-existing swtpm process that's been spawned ahead of time. This will
> let us have stricter privilege separation.

I agree, just letting something external start the swtpm and using
a chardev to talk to it would seem to work wouldn't it?

However, generally I prefer this mechanism of avoiding CUSE.

Dave


> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Patrick Ohly]

On Mon, 2017-04-03 at 18:07 +0100, Daniel P. Berrange wrote:
> On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > Briefly, Theses set of patches introduces:
> >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> >  - and few supported fixes/enhancements/cleanup to existing tpm backend 
> > code.
> > 
> > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with 
> > slightly
> > different approach, using CUSE. As swtpm has excellent support for unix 
> > domain
> > sockets, hence this implementation uses unix domain sockets to communicate 
> > with
> > swtpm.
> > 
> > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm' and
> > communicates its via Unix domain sockets.
> 
> I'm not convinced that having QEMU spawning swtpm itself is a desirable
> approach, as it means QEMU needs to have all the privileges that swtpm
> will need, so that swtpm can inherit them.

The intended usage is for emulating a TPM in software, for example to do
automated testing of an OS which requires a TPM or to do software
development in an environment were it is easy to reset the TPM. That
doesn't require any privileges, because swtpm just reads and writes
files owned by the user who calls qemu.

>  At the very least I think we
> need to have a way to disable this spawning, so it can connect to a
> pre-existing swtpm process that's been spawned ahead of time. This will
> let us have stricter privilege separation.

Which privileges and use cases did you have in mind?

swtpm already can be started so that it listens on a Unix domain socket,
instead of inheriting something from the parent. It shouldn't be hard to
add that as an alternative to the existing spawning code.

I can think of one use case: spawning swtpm in advance under debugging
tools like gdb or valgrind. Is that enough justification for adding more
code?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [Qemu-devel] [RFC 16/19] generic-sdhci: Remove user_creatable flag

[Alistair Francis]

On Fri, Mar 31, 2017 at 5:46 PM, Eduardo Habkost  wrote:
> generic-sdhci needs to be wired by other devices' code, so it
> can't be used with -device. Remove the user_creatable flag from
> the device class.
>
> Cc: Peter Maydell 
> Cc: "Edgar E. Iglesias" 
> Cc: David Gibson 
> Cc: Alexander Graf 
> Cc: "Michael S. Tsirkin" 
> Cc: Marcel Apfelbaum 
> Cc: Prasad J Pandit 
> Cc: Alistair Francis 
> Signed-off-by: Eduardo Habkost 

Reviewed-by: Alistair Francis 

Thanks,

Alistair

> ---
>  hw/sd/sdhci.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index 186555188b..6d6a791ee9 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -1360,11 +1360,6 @@ static void sdhci_sysbus_class_init(ObjectClass 
> *klass, void *data)
>  dc->props = sdhci_sysbus_properties;
>  dc->realize = sdhci_sysbus_realize;
>  dc->reset = sdhci_poweron_reset;
> -/*
> - * FIXME: Set only for compatibility on q35 machine-type.
> - * Probably never meant to be user-creatable
> - */
> -dc->user_creatable = true;
>  }
>
>  static const TypeInfo sdhci_sysbus_info = {
> --
> 2.11.0.259.g40922b1
>
>

[Qemu-devel] [PATCH v5 4/5] slirp: VMStatify socket level

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Working up the stack, this replaces the slirp_socket_load/save
with VMState definitions.

A place holder for IPv6 support is added as a comment; it needs
testing once the rest of the IPv6 code is there.

Signed-off-by: Dr. David Alan Gilbert 
---
 slirp/slirp.c  | 219 +
 slirp/socket.h |   6 +-
 2 files changed, 145 insertions(+), 80 deletions(-)

diff --git a/slirp/slirp.c b/slirp/slirp.c
index 2b834af..2de97b6 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -1250,40 +1250,154 @@ static const VMStateDescription vmstate_slirp_sbuf = {
 }
 };
 
+static bool slirp_older_than_v4(void *opaque, int version_id)
+{
+return version_id < 4;
+}
 
-static void slirp_socket_save(QEMUFile *f, struct socket *so)
+static bool slirp_family_inet(void *opaque, int version_id)
 {
-qemu_put_be32(f, so->so_urgc);
-qemu_put_be16(f, so->so_ffamily);
-switch (so->so_ffamily) {
-case AF_INET:
-qemu_put_be32(f, so->so_faddr.s_addr);
-qemu_put_be16(f, so->so_fport);
-break;
-default:
-error_report("so_ffamily unknown, unable to save so_faddr and"
- " so_fport");
+union slirp_sockaddr *ssa = (union slirp_sockaddr *)opaque;
+return ssa->ss.ss_family == AF_INET;
+}
+
+static int slirp_socket_pre_load(void *opaque)
+{
+struct socket *so = opaque;
+if (tcp_attach(so) < 0) {
+return -ENOMEM;
 }
-qemu_put_be16(f, so->so_lfamily);
-switch (so->so_lfamily) {
-case AF_INET:
-qemu_put_be32(f, so->so_laddr.s_addr);
-qemu_put_be16(f, so->so_lport);
+/* Older versions don't load these fields */
+so->so_ffamily = AF_INET;
+so->so_lfamily = AF_INET;
+return 0;
+}
+
+#ifndef _WIN32
+#define VMSTATE_SIN4_ADDR(f, s, t) VMSTATE_UINT32_TEST(f, s, t)
+#else
+/* Win uses u_long rather than uint32_t - but it's still 32bits long */
+#define VMSTATE_SIN4_ADDR(f, s, t) VMSTATE_SINGLE_TEST(f, s, t, 0, \
+   vmstate_info_uint32, u_long)
+#endif
+
+/* The OS provided ss_family field isn't that portable; it's size
+ * and type varies (16/8 bit, signed, unsigned)
+ * and the values it contains aren't fully portable.
+ */
+typedef struct SS_FamilyTmpStruct {
+union slirp_sockaddr*parent;
+uint16_t portable_family;
+} SS_FamilyTmpStruct;
+
+#define SS_FAMILY_MIG_IPV4   2  /* Linux, BSD, Win... */
+#define SS_FAMILY_MIG_IPV6  10  /* Linux */
+#define SS_FAMILY_MIG_OTHER 0x
+
+static void ss_family_pre_save(void *opaque)
+{
+SS_FamilyTmpStruct *tss = opaque;
+
+tss->portable_family = SS_FAMILY_MIG_OTHER;
+
+if (tss->parent->ss.ss_family == AF_INET) {
+tss->portable_family = SS_FAMILY_MIG_IPV4;
+} else if (tss->parent->ss.ss_family == AF_INET6) {
+tss->portable_family = SS_FAMILY_MIG_IPV6;
+}
+}
+
+static int ss_family_post_load(void *opaque, int version_id)
+{
+SS_FamilyTmpStruct *tss = opaque;
+
+switch (tss->portable_family) {
+case SS_FAMILY_MIG_IPV4:
+tss->parent->ss.ss_family = AF_INET;
+break;
+case SS_FAMILY_MIG_IPV6:
+case 23: /* compatibility: AF_INET6 from mingw */
+case 28: /* compatibility: AF_INET6 from FreeBSD sys/socket.h */
+tss->parent->ss.ss_family = AF_INET6;
 break;
 default:
-error_report("so_ffamily unknown, unable to save so_laddr and"
- " so_lport");
+error_report("invalid ss_family type %x", tss->portable_family);
+return -EINVAL;
 }
-qemu_put_byte(f, so->so_iptos);
-qemu_put_byte(f, so->so_emu);
-qemu_put_byte(f, so->so_type);
-qemu_put_be32(f, so->so_state);
-/* TODO: Build vmstate at this level */
-vmstate_save_state(f, &vmstate_slirp_sbuf, &so->so_rcv, 0);
-vmstate_save_state(f, &vmstate_slirp_sbuf, &so->so_snd, 0);
-vmstate_save_state(f, &vmstate_slirp_tcp, so->so_tcpcb, 0);
+
+return 0;
 }
 
+static const VMStateDescription vmstate_slirp_ss_family = {
+.name = "slirp-socket-addr/ss_family",
+.pre_save  = ss_family_pre_save,
+.post_load = ss_family_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT16(portable_family, SS_FamilyTmpStruct),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_slirp_socket_addr = {
+.name = "slirp-socket-addr",
+.version_id = 4,
+.fields = (VMStateField[]) {
+VMSTATE_WITH_TMP(union slirp_sockaddr, SS_FamilyTmpStruct,
+vmstate_slirp_ss_family),
+VMSTATE_SIN4_ADDR(sin.sin_addr.s_addr, union slirp_sockaddr,
+slirp_family_inet),
+VMSTATE_UINT16_TEST(sin.sin_port, union slirp_sockaddr,
+slirp_family_inet),
+
+#if 0
+/* Untested: Needs checking by someone with IPv6 test */
+VMSTATE_BUFFER_TEST(sin6.sin6_addr, union slirp_sockaddr,
+ 

[Qemu-devel] [PATCH v5 0/5 for 2.10] SLIRP VMStatification

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Hi,
  Another crack at slirp vmstatification; v5 fixes the type and
value portability issues in the ss_family field.

  It now always sends this as a 16bit field and always uses Linux's
AF_INET or AF_INET6 value on writing.  It'll also accept Windows and
FreeBSDs values as inet6 to keep compatibility with incoming migrations
from previous versions.

Dave

v5
  Fix ss_family portability

Dr. David Alan Gilbert (5):
  slirp: VMState conversion; tcpcb
  slirp: VMStatify sbuf
  slirp: Common lhost/fhost union
  slirp: VMStatify socket level
  slirp: VMStatify remaining except for loop

 slirp/sbuf.h|   4 +-
 slirp/slirp.c   | 494 +++-
 slirp/socket.h  |  24 ++-
 slirp/tcp_var.h |   6 +-
 4 files changed, 288 insertions(+), 240 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH v5 5/5] slirp: VMStatify remaining except for loop

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

This converts the remaining components, except for the top level
loop, to VMState.

Signed-off-by: Dr. David Alan Gilbert 
---
 slirp/slirp.c | 48 +++-
 1 file changed, 19 insertions(+), 29 deletions(-)

diff --git a/slirp/slirp.c b/slirp/slirp.c
index 2de97b6..701eb7e 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -1398,15 +1398,25 @@ static const VMStateDescription vmstate_slirp_socket = {
 }
 };
 
-static void slirp_bootp_save(QEMUFile *f, Slirp *slirp)
-{
-int i;
+static const VMStateDescription vmstate_slirp_bootp_client = {
+.name = "slirp_bootpclient",
+.fields = (VMStateField[]) {
+VMSTATE_UINT16(allocated, BOOTPClient),
+VMSTATE_BUFFER(macaddr, BOOTPClient),
+VMSTATE_END_OF_LIST()
+}
+};
 
-for (i = 0; i < NB_BOOTP_CLIENTS; i++) {
-qemu_put_be16(f, slirp->bootp_clients[i].allocated);
-qemu_put_buffer(f, slirp->bootp_clients[i].macaddr, 6);
+static const VMStateDescription vmstate_slirp = {
+.name = "slirp",
+.version_id = 4,
+.fields = (VMStateField[]) {
+VMSTATE_UINT16_V(ip_id, Slirp, 2),
+VMSTATE_STRUCT_ARRAY(bootp_clients, Slirp, NB_BOOTP_CLIENTS, 3,
+ vmstate_slirp_bootp_client, BOOTPClient),
+VMSTATE_END_OF_LIST()
 }
-}
+};
 
 static void slirp_state_save(QEMUFile *f, void *opaque)
 {
@@ -1426,22 +1436,10 @@ static void slirp_state_save(QEMUFile *f, void *opaque)
 }
 qemu_put_byte(f, 0);
 
-qemu_put_be16(f, slirp->ip_id);
-
-slirp_bootp_save(f, slirp);
+vmstate_save_state(f, &vmstate_slirp, slirp, NULL);
 }
 
 
-static void slirp_bootp_load(QEMUFile *f, Slirp *slirp)
-{
-int i;
-
-for (i = 0; i < NB_BOOTP_CLIENTS; i++) {
-slirp->bootp_clients[i].allocated = qemu_get_be16(f);
-qemu_get_buffer(f, slirp->bootp_clients[i].macaddr, 6);
-}
-}
-
 static int slirp_state_load(QEMUFile *f, void *opaque, int version_id)
 {
 Slirp *slirp = opaque;
@@ -1476,13 +1474,5 @@ static int slirp_state_load(QEMUFile *f, void *opaque, 
int version_id)
 so->extra = (void *)ex_ptr->ex_exec;
 }
 
-if (version_id >= 2) {
-slirp->ip_id = qemu_get_be16(f);
-}
-
-if (version_id >= 3) {
-slirp_bootp_load(f, slirp);
-}
-
-return 0;
+return vmstate_load_state(f, &vmstate_slirp, slirp, version_id);
 }
-- 
2.9.3

[Qemu-devel] [PATCH v5 3/5] slirp: Common lhost/fhost union

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

The socket structure has a pair of unions for lhost and fhost
addresses; the unions are identical so split them out into
a separate union declaration.

Signed-off-by: Dr. David Alan Gilbert 
---
 slirp/socket.h | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/slirp/socket.h b/slirp/socket.h
index 8feed2a..c1be77e 100644
--- a/slirp/socket.h
+++ b/slirp/socket.h
@@ -15,6 +15,12 @@
  * Our socket structure
  */
 
+union slirp_sockaddr {
+struct sockaddr_storage ss;
+struct sockaddr_in sin;
+struct sockaddr_in6 sin6;
+};
+
 struct socket {
   struct socket *so_next,*so_prev;  /* For a linked list of sockets */
 
@@ -31,22 +37,14 @@ struct socket {
   struct tcpiphdr *so_ti; /* Pointer to the original ti within
* so_mconn, for non-blocking connections */
   int so_urgc;
-  union {   /* foreign host */
-  struct sockaddr_storage ss;
-  struct sockaddr_in sin;
-  struct sockaddr_in6 sin6;
-  } fhost;
+  union slirp_sockaddr fhost;  /* Foreign host */
 #define so_faddr fhost.sin.sin_addr
 #define so_fport fhost.sin.sin_port
 #define so_faddr6 fhost.sin6.sin6_addr
 #define so_fport6 fhost.sin6.sin6_port
 #define so_ffamily fhost.ss.ss_family
 
-  union {   /* local host */
-  struct sockaddr_storage ss;
-  struct sockaddr_in sin;
-  struct sockaddr_in6 sin6;
-  } lhost;
+  union slirp_sockaddr lhost;  /* Local host */
 #define so_laddr lhost.sin.sin_addr
 #define so_lport lhost.sin.sin_port
 #define so_laddr6 lhost.sin6.sin6_addr
-- 
2.9.3

Re: [Qemu-devel] [RFC 10/19] sysbus-ahci: Remove user_creatable flag

[Alistair Francis]

On Fri, Mar 31, 2017 at 5:46 PM, Eduardo Habkost  wrote:
> The sysbus-ahci devices are supposed to be created and wired by
> code from other devices, like calxeda_init() and
> xlnx_zynqmp_realize(), and won't work with -device. Remove the
> user_creatable flag from the device class.
>
> Cc: John Snow 
> Cc: qemu-bl...@nongnu.org
> Cc: Rob Herring 
> Cc: Peter Maydell 
> Cc: Alistair Francis 
> Cc: "Edgar E. Iglesias" 
> Signed-off-by: Eduardo Habkost 
> ---
>  hw/ide/ahci.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index b1b7780d56..68f2ce09ee 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1721,11 +1721,6 @@ static void sysbus_ahci_class_init(ObjectClass *klass, 
> void *data)
>  dc->props = sysbus_ahci_properties;
>  dc->reset = sysbus_ahci_reset;
>  set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
> -/*
> - * FIXME: Set only for compatibility on q35 machine-type.
> - * Probably never meant to be user-creatable
> - */
> -dc->user_creatable = true;

Part of me thinks this is a step backwards by marking it unsupported.
On the other hand I don't see how this could usefully be connected any
other way.

Reviewed-by: Alistair Francis 

Thanks,

Alistair

>  }
>
>  static const TypeInfo sysbus_ahci_info = {
> --
> 2.11.0.259.g40922b1
>
>

[Qemu-devel] [PATCH v5 1/5] slirp: VMState conversion; tcpcb

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Convert the migration of the struct tcpcb to use a VMStateDescription,
the rest of it will come later.

Mostly mechanical, except for conversion of some 'char' to uint8_t
to ensure portability.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Samuel Thibault 
Reviewed-by: Juan Quintela 
---
 slirp/slirp.c   | 149 
 slirp/tcp_var.h |   6 +--
 2 files changed, 57 insertions(+), 98 deletions(-)

diff --git a/slirp/slirp.c b/slirp/slirp.c
index 5a94b06..86eefc3 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -1129,53 +1129,62 @@ void slirp_socket_recv(Slirp *slirp, struct in_addr 
guest_addr, int guest_port,
 tcp_output(sototcpcb(so));
 }
 
-static void slirp_tcp_save(QEMUFile *f, struct tcpcb *tp)
+static int slirp_tcp_post_load(void *opaque, int version)
 {
-int i;
+tcp_template((struct tcpcb *)opaque);
 
-qemu_put_sbe16(f, tp->t_state);
-for (i = 0; i < TCPT_NTIMERS; i++)
-qemu_put_sbe16(f, tp->t_timer[i]);
-qemu_put_sbe16(f, tp->t_rxtshift);
-qemu_put_sbe16(f, tp->t_rxtcur);
-qemu_put_sbe16(f, tp->t_dupacks);
-qemu_put_be16(f, tp->t_maxseg);
-qemu_put_sbyte(f, tp->t_force);
-qemu_put_be16(f, tp->t_flags);
-qemu_put_be32(f, tp->snd_una);
-qemu_put_be32(f, tp->snd_nxt);
-qemu_put_be32(f, tp->snd_up);
-qemu_put_be32(f, tp->snd_wl1);
-qemu_put_be32(f, tp->snd_wl2);
-qemu_put_be32(f, tp->iss);
-qemu_put_be32(f, tp->snd_wnd);
-qemu_put_be32(f, tp->rcv_wnd);
-qemu_put_be32(f, tp->rcv_nxt);
-qemu_put_be32(f, tp->rcv_up);
-qemu_put_be32(f, tp->irs);
-qemu_put_be32(f, tp->rcv_adv);
-qemu_put_be32(f, tp->snd_max);
-qemu_put_be32(f, tp->snd_cwnd);
-qemu_put_be32(f, tp->snd_ssthresh);
-qemu_put_sbe16(f, tp->t_idle);
-qemu_put_sbe16(f, tp->t_rtt);
-qemu_put_be32(f, tp->t_rtseq);
-qemu_put_sbe16(f, tp->t_srtt);
-qemu_put_sbe16(f, tp->t_rttvar);
-qemu_put_be16(f, tp->t_rttmin);
-qemu_put_be32(f, tp->max_sndwnd);
-qemu_put_byte(f, tp->t_oobflags);
-qemu_put_byte(f, tp->t_iobc);
-qemu_put_sbe16(f, tp->t_softerror);
-qemu_put_byte(f, tp->snd_scale);
-qemu_put_byte(f, tp->rcv_scale);
-qemu_put_byte(f, tp->request_r_scale);
-qemu_put_byte(f, tp->requested_s_scale);
-qemu_put_be32(f, tp->ts_recent);
-qemu_put_be32(f, tp->ts_recent_age);
-qemu_put_be32(f, tp->last_ack_sent);
+return 0;
 }
 
+static const VMStateDescription vmstate_slirp_tcp = {
+.name = "slirp-tcp",
+.version_id = 0,
+.post_load = slirp_tcp_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_INT16(t_state, struct tcpcb),
+VMSTATE_INT16_ARRAY(t_timer, struct tcpcb, TCPT_NTIMERS),
+VMSTATE_INT16(t_rxtshift, struct tcpcb),
+VMSTATE_INT16(t_rxtcur, struct tcpcb),
+VMSTATE_INT16(t_dupacks, struct tcpcb),
+VMSTATE_UINT16(t_maxseg, struct tcpcb),
+VMSTATE_UINT8(t_force, struct tcpcb),
+VMSTATE_UINT16(t_flags, struct tcpcb),
+VMSTATE_UINT32(snd_una, struct tcpcb),
+VMSTATE_UINT32(snd_nxt, struct tcpcb),
+VMSTATE_UINT32(snd_up, struct tcpcb),
+VMSTATE_UINT32(snd_wl1, struct tcpcb),
+VMSTATE_UINT32(snd_wl2, struct tcpcb),
+VMSTATE_UINT32(iss, struct tcpcb),
+VMSTATE_UINT32(snd_wnd, struct tcpcb),
+VMSTATE_UINT32(rcv_wnd, struct tcpcb),
+VMSTATE_UINT32(rcv_nxt, struct tcpcb),
+VMSTATE_UINT32(rcv_up, struct tcpcb),
+VMSTATE_UINT32(irs, struct tcpcb),
+VMSTATE_UINT32(rcv_adv, struct tcpcb),
+VMSTATE_UINT32(snd_max, struct tcpcb),
+VMSTATE_UINT32(snd_cwnd, struct tcpcb),
+VMSTATE_UINT32(snd_ssthresh, struct tcpcb),
+VMSTATE_INT16(t_idle, struct tcpcb),
+VMSTATE_INT16(t_rtt, struct tcpcb),
+VMSTATE_UINT32(t_rtseq, struct tcpcb),
+VMSTATE_INT16(t_srtt, struct tcpcb),
+VMSTATE_INT16(t_rttvar, struct tcpcb),
+VMSTATE_UINT16(t_rttmin, struct tcpcb),
+VMSTATE_UINT32(max_sndwnd, struct tcpcb),
+VMSTATE_UINT8(t_oobflags, struct tcpcb),
+VMSTATE_UINT8(t_iobc, struct tcpcb),
+VMSTATE_INT16(t_softerror, struct tcpcb),
+VMSTATE_UINT8(snd_scale, struct tcpcb),
+VMSTATE_UINT8(rcv_scale, struct tcpcb),
+VMSTATE_UINT8(request_r_scale, struct tcpcb),
+VMSTATE_UINT8(requested_s_scale, struct tcpcb),
+VMSTATE_UINT32(ts_recent, struct tcpcb),
+VMSTATE_UINT32(ts_recent_age, struct tcpcb),
+VMSTATE_UINT32(last_ack_sent, struct tcpcb),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static void slirp_sbuf_save(QEMUFile *f, struct sbuf *sbuf)
 {
 uint32_t off;
@@ -1218,7 +1227,7 @@ static void slirp_socket_save(QEMUFile *f, struct socket 
*so)
 qemu_put_be32(f, so->so_state);
 slirp_sbuf_save(f, &so->so_rcv);
 slirp_sbuf_save(f, &so->so_snd);
-slirp_tcp_save(f, so->so_tcpcb);
+

[Qemu-devel] [PATCH v5 2/5] slirp: VMStatify sbuf

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Convert the sbuf structure to a VMStateDescription.
Note this uses the VMSTATE_WITH_TMP mechanism to calculate
and reload the offsets based on the pointers.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: David Gibson 
Reviewed-by: Juan Quintela 
Acked-by: Samuel Thibault 
---
 slirp/sbuf.h  |   4 +-
 slirp/slirp.c | 116 ++
 2 files changed, 78 insertions(+), 42 deletions(-)

diff --git a/slirp/sbuf.h b/slirp/sbuf.h
index efcec39..a722ecb 100644
--- a/slirp/sbuf.h
+++ b/slirp/sbuf.h
@@ -12,8 +12,8 @@
 #define sbspace(sb) ((sb)->sb_datalen - (sb)->sb_cc)
 
 struct sbuf {
-   u_int   sb_cc;  /* actual chars in buffer */
-   u_int   sb_datalen; /* Length of data  */
+   uint32_t sb_cc; /* actual chars in buffer */
+   uint32_t sb_datalen;/* Length of data  */
char*sb_wptr;   /* write pointer. points to where the next
 * bytes should be written in the sbuf */
char*sb_rptr;   /* read pointer. points to where the next
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 86eefc3..2b834af 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -1185,19 +1185,72 @@ static const VMStateDescription vmstate_slirp_tcp = {
 }
 };
 
-static void slirp_sbuf_save(QEMUFile *f, struct sbuf *sbuf)
+/* The sbuf has a pair of pointers that are migrated as offsets;
+ * we calculate the offsets and restore the pointers using
+ * pre_save/post_load on a tmp structure.
+ */
+struct sbuf_tmp {
+struct sbuf *parent;
+uint32_t roff, woff;
+};
+
+static void sbuf_tmp_pre_save(void *opaque)
+{
+struct sbuf_tmp *tmp = opaque;
+tmp->woff = tmp->parent->sb_wptr - tmp->parent->sb_data;
+tmp->roff = tmp->parent->sb_rptr - tmp->parent->sb_data;
+}
+
+static int sbuf_tmp_post_load(void *opaque, int version)
 {
-uint32_t off;
-
-qemu_put_be32(f, sbuf->sb_cc);
-qemu_put_be32(f, sbuf->sb_datalen);
-off = (uint32_t)(sbuf->sb_wptr - sbuf->sb_data);
-qemu_put_sbe32(f, off);
-off = (uint32_t)(sbuf->sb_rptr - sbuf->sb_data);
-qemu_put_sbe32(f, off);
-qemu_put_buffer(f, (unsigned char*)sbuf->sb_data, sbuf->sb_datalen);
+struct sbuf_tmp *tmp = opaque;
+uint32_t requested_len = tmp->parent->sb_datalen;
+
+/* Allocate the buffer space used by the field after the tmp */
+sbreserve(tmp->parent, tmp->parent->sb_datalen);
+
+if (tmp->parent->sb_datalen != requested_len) {
+return -ENOMEM;
+}
+if (tmp->woff >= requested_len ||
+tmp->roff >= requested_len) {
+error_report("invalid sbuf offsets r/w=%u/%u len=%u",
+ tmp->roff, tmp->woff, requested_len);
+return -EINVAL;
+}
+
+tmp->parent->sb_wptr = tmp->parent->sb_data + tmp->woff;
+tmp->parent->sb_rptr = tmp->parent->sb_data + tmp->roff;
+
+return 0;
 }
 
+
+static const VMStateDescription vmstate_slirp_sbuf_tmp = {
+.name = "slirp-sbuf-tmp",
+.post_load = sbuf_tmp_post_load,
+.pre_save  = sbuf_tmp_pre_save,
+.version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(woff, struct sbuf_tmp),
+VMSTATE_UINT32(roff, struct sbuf_tmp),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_slirp_sbuf = {
+.name = "slirp-sbuf",
+.version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(sb_cc, struct sbuf),
+VMSTATE_UINT32(sb_datalen, struct sbuf),
+VMSTATE_WITH_TMP(struct sbuf, struct sbuf_tmp, vmstate_slirp_sbuf_tmp),
+VMSTATE_VBUFFER_UINT32(sb_data, struct sbuf, 0, NULL, sb_datalen),
+VMSTATE_END_OF_LIST()
+}
+};
+
+
 static void slirp_socket_save(QEMUFile *f, struct socket *so)
 {
 qemu_put_be32(f, so->so_urgc);
@@ -1225,8 +1278,9 @@ static void slirp_socket_save(QEMUFile *f, struct socket 
*so)
 qemu_put_byte(f, so->so_emu);
 qemu_put_byte(f, so->so_type);
 qemu_put_be32(f, so->so_state);
-slirp_sbuf_save(f, &so->so_rcv);
-slirp_sbuf_save(f, &so->so_snd);
+/* TODO: Build vmstate at this level */
+vmstate_save_state(f, &vmstate_slirp_sbuf, &so->so_rcv, 0);
+vmstate_save_state(f, &vmstate_slirp_sbuf, &so->so_snd, 0);
 vmstate_save_state(f, &vmstate_slirp_tcp, so->so_tcpcb, 0);
 }
 
@@ -1263,31 +1317,9 @@ static void slirp_state_save(QEMUFile *f, void *opaque)
 slirp_bootp_save(f, slirp);
 }
 
-static int slirp_sbuf_load(QEMUFile *f, struct sbuf *sbuf)
-{
-uint32_t off, sb_cc, sb_datalen;
-
-sb_cc = qemu_get_be32(f);
-sb_datalen = qemu_get_be32(f);
-
-sbreserve(sbuf, sb_datalen);
-
-if (sbuf->sb_datalen != sb_datalen)
-return -ENOMEM;
-
-sbuf->sb_cc = sb_cc;
-
-off = qemu_get_sbe32(f);
-sbuf->sb_wptr = sbuf->sb_data + off;
-off = qemu_get_sbe32(f);
-sbuf->sb_rptr = sbuf->sb_data + off;
-qemu_get_buffer(f, (unsigned char*)sbuf->sb_data, sbuf->sb_datalen);
-
-

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Marc-André Lureau]

Hi

On Mon, Apr 3, 2017 at 7:08 PM Daniel P. Berrange 
wrote:

> On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > Briefly, Theses set of patches introduces:
> >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> >  - and few supported fixes/enhancements/cleanup to existing tpm backend
> code.
> >
> > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with
> slightly
> > different approach, using CUSE. As swtpm has excellent support for unix
> domain
> > sockets, hence this implementation uses unix domain sockets to
> communicate with
> > swtpm.
> >
> > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm'
> and
> > communicates its via Unix domain sockets.
>
> I'm not convinced that having QEMU spawning swtpm itself is a desirable
> approach, as it means QEMU needs to have all the privileges that swtpm
> will need, so that swtpm can inherit them. At the very least I think we
> need to have a way to disable this spawning, so it can connect to a
> pre-existing swtpm process that's been spawned ahead of time. This will
> let us have stricter privilege separation.
>

Could the security contexts be given as arguments to qemu for the
subprocesses? The reason to have qemu spawn its own subprocess is that it
would leave more flexibility on how and when to do it, or even to use
multiple subprcesses if some day that makes sense. If there is no reason to
make this interface public or shared by various other processes, I would
rather see it as internal to qemu rather than managed by other tools. It
also makes command line & testing easier.

Similarly, I think the swtpm protocol must offer enough guarantee about
stability, versionning / capabilities, that we can later extend it. swtpm
could likely be implemented in qemu (by using libswtpm), using a private
protocol. It's hard to estimate how much code that represents, but I think
by reusing glib & qemu common it should be fairly small & simple. I haven't
looked in details.

thanks
-- 
Marc-André Lureau

Re: [Qemu-devel] [RFC 01/19] qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable

[Alistair Francis]

On Fri, Mar 31, 2017 at 5:46 PM, Eduardo Habkost  wrote:
> cannot_instantiate_with_device_add_yet was introduced by commit
> 837d37167dc446af8a91189108b363c04609e296 to replace no_user. It
> was supposed to be a temporary measure.
>
> When it was introduced, we had 54
> cannot_instantiate_with_device_add_yet=true lines in the code.
> Today (3 years later) this number has not shrinked: we now have
> 57 cannot_instantiate_with_device_add_yet=true lines. I think it
> is safe to say it is not a temporary measure, and we won't see
> the flag go away soon.
>
> Instead of a long field name that misleads people to believe it
> is temporary, replace it a shorter and less misleading field:
> user_creatable.

I haven't tested this, but I do like the new name and think it makes
more sense then what we have now.

Acked-by: Alistair Francis 

Thanks,

Alistair

>
> Except for code comments, changes were generated using the
> following Coccinelle patch:
>
>   @@
>   expression DC;
>   @@
>   (
>   -DC->cannot_instantiate_with_device_add_yet = false;
>   +DC->user_creatable = true;
>   |
>   -DC->cannot_instantiate_with_device_add_yet = true;
>   +DC->user_creatable = false;
>   )
>
>   @@
>   typedef ObjectClass;
>   expression dc;
>   identifier class, data;
>   @@
>static void device_class_init(ObjectClass *class, void *data)
>{
>...
>dc->hotpluggable = true;
>   +dc->user_creatable = true;
>...
>}
>
>   @@
>   @@
>struct DeviceClass {
>...
>   -bool cannot_instantiate_with_device_add_yet;
>   +bool user_creatable;
>...
>   }
>
>   @@
>   expression DC;
>   @@
>   (
>   -!DC->cannot_instantiate_with_device_add_yet
>   +DC->user_creatable
>   |
>   -DC->cannot_instantiate_with_device_add_yet
>   +!DC->user_creatable
>   )
>
> Cc: Markus Armbruster 
> Cc: Laszlo Ersek 
> Cc: Marcel Apfelbaum 
> Cc: Peter Maydell 
> Cc: Thomas Huth 
> Signed-off-by: Eduardo Habkost 
> ---
>  include/hw/qdev-core.h  | 10 +-
>  include/hw/qdev-properties.h|  4 ++--
>  hw/acpi/piix4.c |  2 +-
>  hw/arm/spitz.c  |  2 +-
>  hw/audio/marvell_88w8618.c  |  2 +-
>  hw/audio/pcspk.c|  2 +-
>  hw/core/or-irq.c|  2 +-
>  hw/core/qdev.c  |  1 +
>  hw/core/register.c  |  2 +-
>  hw/dma/i8257.c  |  2 +-
>  hw/dma/sparc32_dma.c|  2 +-
>  hw/gpio/omap_gpio.c |  4 ++--
>  hw/i2c/omap_i2c.c   |  2 +-
>  hw/i2c/smbus_eeprom.c   |  2 +-
>  hw/i2c/smbus_ich9.c |  2 +-
>  hw/i386/pc.c|  2 +-
>  hw/input/vmmouse.c  |  2 +-
>  hw/intc/apic_common.c   |  2 +-
>  hw/intc/etraxfs_pic.c   |  2 +-
>  hw/intc/grlib_irqmp.c   |  2 +-
>  hw/intc/i8259_common.c  |  2 +-
>  hw/intc/nios2_iic.c |  2 +-
>  hw/intc/omap_intc.c |  4 ++--
>  hw/isa/lpc_ich9.c   |  2 +-
>  hw/isa/piix4.c  |  2 +-
>  hw/isa/vt82c686.c   |  2 +-
>  hw/mips/gt64xxx_pci.c   |  2 +-
>  hw/misc/vmport.c|  2 +-
>  hw/net/dp8393x.c|  2 +-
>  hw/net/etraxfs_eth.c|  2 +-
>  hw/net/lance.c  |  2 +-
>  hw/pci-bridge/dec.c |  2 +-
>  hw/pci-bridge/pci_expander_bridge.c |  2 +-
>  hw/pci-host/apb.c   |  2 +-
>  hw/pci-host/bonito.c|  2 +-
>  hw/pci-host/gpex.c  |  2 +-
>  hw/pci-host/grackle.c   |  2 +-
>  hw/pci-host/piix.c  |  6 +++---
>  hw/pci-host/ppce500.c   |  2 +-
>  hw/pci-host/prep.c  |  2 +-
>  hw/pci-host/q35.c   |  4 ++--
>  hw/pci-host/uninorth.c  |  8 
>  hw/pci-host/versatile.c |  2 +-
>  hw/pci-host/xilinx-pcie.c   |  2 +-
>  hw/ppc/ppc4xx_pci.c |  2 +-
>  hw/ppc/spapr_drc.c  |  2 +-
>  hw/s390x/s390-pci-bus.c |  2 +-
>  hw/sd/milkymist-memcard.c   |  2 +-
>  hw/sd/pl181.c   |  2 +-
>  hw/sh4/sh_pci.c |  2 +-
>  hw/timer/i8254_common.c |  2 +-
>  hw/timer/mc146818rtc.c  |  2 +-
>  monitor.c   |  2 +-
>  qdev-monitor.c  |  6 +++---
>  qom/cpu.c   |  2 +-
>  target/i386/cpu.c   |  2 +-
>  56 files changed, 71 insertions(+), 70 deletions(-)
>
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index b44b476765..bc4e6f0486 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -103,16 +103,16 @@ typedef struct DeviceClass {
>  Property *props;
>
>  /*
> - * Shall we hide this device model from -device / device_add?
> + * Can this device be instan

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Daniel P. Berrange]

On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> Briefly, Theses set of patches introduces:
>  - new TPM backend driver to support software TPM emulators(swtpm(1)).
>  - and few supported fixes/enhancements/cleanup to existing tpm backend code.
> 
> The similar idea was initiated earliar(2) by Stefan Berger(CCed) with slightly
> different approach, using CUSE. As swtpm has excellent support for unix domain
> sockets, hence this implementation uses unix domain sockets to communicate 
> with
> swtpm.
> 
> When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm' and
> communicates its via Unix domain sockets.

I'm not convinced that having QEMU spawning swtpm itself is a desirable
approach, as it means QEMU needs to have all the privileges that swtpm
will need, so that swtpm can inherit them. At the very least I think we
need to have a way to disable this spawning, so it can connect to a
pre-existing swtpm process that's been spawned ahead of time. This will
let us have stricter privilege separation.

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

Re: [Qemu-devel] [RFC PATCH v1 0/9] MTTCG and record/replay fixes for rc3

[Paolo Bonzini]

On 03/04/2017 14:45, Alex Bennée wrote:
>   cpus: check cpu->running in cpu_get_icount_raw()
> 
>   I'm not sure the race happens and once outside of cpu->running the
>   icount counters should be zero. However it seems a sensible
>   precaution.

Yeah, I think this is unnecessary with patch 7's new assertions.

> I think the cpus: patches should probably go into the next
> pull-request while we see if we can come up with a better final
> solution for fixing record/replay. However given how long this
> regression has run during the release candidate process I wanted to
> update everyone on the current status and get feedback ASAP.

I agree.  I'm not sure exactly how the final race happens, but if it
causes divergence it would be caught later by the record/replay
mechanism, I think.

Paolo

Re: [Qemu-devel] [RFC PATCH v1 8/9] cpus: don't credit executed instructions before they have run

[Paolo Bonzini]

On 03/04/2017 14:45, Alex Bennée wrote:
> Outside of the vCPU thread icount time will only be tracked against
> timers_state.qemu_icount. We no longer credit cycles until they have
> completed the run. Inside the vCPU thread we adjust for passage of
> time by looking at how many have run so far. This is only valid inside
> the vCPU thread while it is running.
> 
> Signed-off-by: Alex Bennée 

I suspect icount_budget and icount_extra could be merged into one, but
not for 2.9.  For now this looks nice!

Paolo

> ---
>  cpus.c| 27 +--
>  include/qom/cpu.h |  1 +
>  2 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 87638a75d2..3d18374b0e 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -223,6 +223,15 @@ void qemu_tcg_configure(QemuOpts *opts, Error **errp)
>  }
>  }
>  
> +/* The current number of executed instructions is based on what we
> + * originally budgeted minus the current state of the decrementing
> + * icount counters in extra/u16.low.
> + */
> +static int64_t cpu_get_icount_executed(CPUState *cpu)
> +{
> +return cpu->icount_budget - (cpu->icount_decr.u16.low + 
> cpu->icount_extra);
> +}
> +
>  int64_t cpu_get_icount_raw(void)
>  {
>  int64_t icount;
> @@ -234,7 +243,8 @@ int64_t cpu_get_icount_raw(void)
>  fprintf(stderr, "Bad icount read\n");
>  exit(1);
>  }
> -icount -= (cpu->icount_decr.u16.low + cpu->icount_extra);
> +/* Take into account what has run */
> +icount += cpu_get_icount_executed(cpu);
>  }
>  return icount;
>  }
> @@ -1195,7 +1205,10 @@ static void prepare_icount_for_run(CPUState *cpu)
>  
>  count = tcg_get_icount_limit();
>  
> -timers_state.qemu_icount += count;
> +/* To calculate what we have executed so far we need to know
> + * what we originally budgeted to run this cycle */
> +cpu->icount_budget = count;
> +
>  decr = (count > 0x) ? 0x : count;
>  count -= decr;
>  cpu->icount_decr.u16.low = decr;
> @@ -1206,16 +1219,18 @@ static void prepare_icount_for_run(CPUState *cpu)
>  static void process_icount_data(CPUState *cpu)
>  {
>  if (use_icount) {
> -/* Fold pending instructions back into the
> -   instruction counter, and clear the interrupt flag.  */
> -timers_state.qemu_icount -= (cpu->icount_decr.u16.low
> -+ cpu->icount_extra);
> +/* Account for executed instructions */
> +timers_state.qemu_icount += cpu_get_icount_executed(cpu);
>  
>  /* We must be under BQL here as cpu_exit can tweak
> icount_decr.u32 */
>  g_assert(qemu_mutex_iothread_locked());
> +
> +/* Reset the counters */
>  cpu->icount_decr.u32 = 0;
>  cpu->icount_extra = 0;
> +cpu->icount_budget = 0;
> +
>  replay_account_executed_instructions();
>  }
>  }
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index c3292efe1c..5d10359c8f 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -332,6 +332,7 @@ struct CPUState {
>  /* updates protected by BQL */
>  uint32_t interrupt_request;
>  int singlestep_enabled;
> +int64_t icount_budget;
>  int64_t icount_extra;
>  sigjmp_buf jmp_env;
>  
> 

Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.

[Paolo Bonzini]

On 03/04/2017 14:03, Gerd Hoffmann wrote:
> We might clear some more bits, but these are
> outsize the visible area so they should cause visible corruption (and if
> the visible area changes the display code needs to do a full refresh
> anyway).

True, though this makes the snapshot abstraction a little more
specialized.  Please add a FIXME comment with the explanation, at least.

Paolo

Re: [Qemu-devel] [PATCH 1/7] tpm-backend: Remove unneeded member variable from backend class

[Marc-André Lureau]

Hi

On Fri, Mar 31, 2017 at 4:58 PM Amarnath Valluri 
wrote:

> TPMDriverOps inside TPMBackend is not required, as it is supposed to be a
> class
> member. The only possible reason for keeping in TPMBackend was, to get the
> backend type in tpm.c where dedicated backend api, tpm_backend_get_type()
> is
> present.
>
> Signed-off-by: Amarnath Valluri 
>


Reviewed-by: Marc-André Lureau 


---
>  hw/tpm/tpm_passthrough.c | 4 
>  include/sysemu/tpm_backend.h | 1 -
>  tpm.c| 2 +-
>  3 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/hw/tpm/tpm_passthrough.c b/hw/tpm/tpm_passthrough.c
> index 9234eb3..a0baf5f 100644
> --- a/hw/tpm/tpm_passthrough.c
> +++ b/hw/tpm/tpm_passthrough.c
> @@ -46,8 +46,6 @@
>  #define TPM_PASSTHROUGH(obj) \
>  OBJECT_CHECK(TPMPassthruState, (obj), TYPE_TPM_PASSTHROUGH)
>
> -static const TPMDriverOps tpm_passthrough_driver;
> -
>  /* data structures */
>  typedef struct TPMPassthruThreadParams {
>  TPMState *tpm_state;
> @@ -462,8 +460,6 @@ static TPMBackend *tpm_passthrough_create(QemuOpts
> *opts, const char *id)
>  /* let frontend set the fe_model to proper value */
>  tb->fe_model = -1;
>
> -tb->ops = &tpm_passthrough_driver;
> -
>  if (tpm_passthrough_handle_device_opts(opts, tb)) {
>  goto err_exit;
>  }
> diff --git a/include/sysemu/tpm_backend.h b/include/sysemu/tpm_backend.h
> index b58f52d..e7f590d 100644
> --- a/include/sysemu/tpm_backend.h
> +++ b/include/sysemu/tpm_backend.h
> @@ -50,7 +50,6 @@ struct TPMBackend {
>  enum TpmModel fe_model;
>  char *path;
>  char *cancel_path;
> -const TPMDriverOps *ops;
>
>  QLIST_ENTRY(TPMBackend) list;
>  };
> diff --git a/tpm.c b/tpm.c
> index 9a7c711..0ee021a 100644
> --- a/tpm.c
> +++ b/tpm.c
> @@ -258,7 +258,7 @@ static TPMInfo *qmp_query_tpm_inst(TPMBackend *drv)
>  res->model = drv->fe_model;
>  res->options = g_new0(TpmTypeOptions, 1);
>
> -switch (drv->ops->type) {
> +switch (tpm_backend_get_type(drv)) {
>  case TPM_TYPE_PASSTHROUGH:
>  res->options->type = TPM_TYPE_OPTIONS_KIND_PASSTHROUGH;
>  tpo = g_new0(TPMPassthroughOptions, 1);
> --
> 2.7.4
>
>
> --
Marc-André Lureau

Re: [Qemu-devel] [Qemu-block] New iotest repros failures on virtio external snapshot with iothread

[Stefan Hajnoczi]

On Wed, Mar 29, 2017 at 07:01:38PM -0700, Ed Swierk wrote:
> Parts of qemu's block code have changed a lot in recent months but are
> not well exercised by current tests.
> 
> Subtle bugs have crept in causing assertion failures, hangs and other
> crashes in a variety of situations: immediately on start, on first
> guest activity, on external snapshot create or commit, on qmp quit
> command.
> 
> Reproducing these bugs has proved tricky, as each may occur only with
> a specific combination of qemu version, block device type (virtio-blk
> or virtio-scsi) and iothread enabled or not. In some cases the bug
> occurs only after several external snapshot operations. And in some
> cases the bug only manifests when a guest is accessing the block
> device simultaneously.
> 
> I've written an iotest (number 176, for now) that attempts to cover
> many of these configurations. Currently it only exercises the external
> snapshot create and commit lifted from iotest 118. The new iotest does
> this repeatedly in each of 16 combinations:
> - no guest / guest
> - virtio-blk / virtio-scsi
> - no iothread / iothread
> - single / repeated external snapshot create+commit

Thanks Ed!  This is has a lot of potential.  I see three different
issues that can be discussed separately:

1. Urgent 2.9 bug fix for `ctx->external_disable_cnt > 0' failed
assertion.  I believe you've already started a separate email thread
about it called "Assertion failure taking external snapshot with virtio
drive + iothread".

2. QEMU 2.8 stable hang.  Less urgent but worth understanding, perhaps
via git-bisect against QEMU 2.9.

3. Minor iotest enhancements.  Please send a separate patch series.

4. How to automate tests with real Linux guests?  This is a complex
topic and probably what we should discuss in this email thread.

The buildroot + busybox approach is good for a small set of sanity
tests.  There was a similar attempt here:
https://github.com/stsquad/qemu-jeos

Building from source becomes a challenge when other people want to add
software to test other areas of QEMU.  The process also requires
attention to maintain the image over time (e.g. as host build
environments change).

There are image builder tools like virt-builder and mkosi for building
bootable virtual machine images based on standard Linux distros:
http://libguestfs.org/virt-builder.1.html
https://github.com/systemd/mkosi

This eliminates the build-from-source hassles and gives us a full Linux
guest environment.  Booting is very fast with mkosi so the advantage to
custom building a minimal image is negligible.

My suggestion is:

Let's pick an image builder tool like virt-builder and keep a single
build script per guest architecture (e.g.  build-test-os-x86_64.sh).
All tests for that architecture run against the same disk image.

It's easy to add additional software to the disk image by modifying the
build script.

A Makefile ensures that the image file gets rebuilt if the build script
has changed.

> 
> I made some minor changes to the test infrastructure so the new iotest
> can deal gracefully with qemu hanging--the test script itself
> shouldn't hang. And in all failure modes the test needs to expose
> enough console output and other information to diagnose the problem.
> 
> The main departure from existing iotests is running a real guest. I
> used buildroot to generate a small (~4 MB) Linux kernel with built-in
> initrd containing a busybox-based userland. After the iotest launches
> qemu, the guest loops writing to the block device, while the test
> performs snapshot operations.
> 
> I ran the new iotest on 3 qemu versions: 2.7.1, stable-2.8-staging and
> 2.9.0-rc2. The latter two fail several test cases, all
> iothread-enabled. Only 2.7.1 passes all the cases.
> 
> Here is the code for the new iotest (I didn't dare email patches with
> a 4 MB blob):
> https://github.com/skyportsystems/qemu-1/commits/eswierk-iotests-2.7
> https://github.com/skyportsystems/qemu-1/commits/eswierk-iotests-2.8
> https://github.com/skyportsystems/qemu-1/commits/eswierk-iotests-2.9
> 
> And here is the buildroot I used to generate the guest Linux kernel+initrd:
> https://github.com/skyportsystems/buildroot-1/commits/qemu-iotests
> 
> Please check out the code and try the new test--particularly anyone
> who can also help figure out these failures. (Note that since half the
> test cases use an iothread, /dev/kvm must be readable and writable.)
> 
> * stable-2.8-staging
> - guest, virtio-blk, iothread, single snapshot create+commit: hang on
> quit (intermittent)
> - guest, virtio-blk, iothread, repeated snapshot create+commit: hang
> after 1 iteration
> - guest, virtio-scsi, iothread, single snapshot create+commit: hang on
> quit (intermittent)
> - guest, virtio-scsi, iothread, repeated snapshot create+commit: hang
> after 1 iteration
> 
> * 2.9.0-rc2
> - guest, virtio-blk, iothread, single snapshot create+commit:
> "include/block/aio.h:457: aio_enable_external: Assertion
> `ctx->external_disable_cnt

Re: [Qemu-devel] [PATCH for-2.9] configure: on Windows minimum glib version must be 2.30

[Stefan Weil]

Am 03.04.2017 um 15:04 schrieb Peter Maydell:

In the 2.7 release we stated in the ChangeLog that the
minimum glib version for Windows hosts was 2.30, but we
didn't update configure to enforce this because we were
very close to the release at the point where we noticed
the issue, and it only affected building the test suite.
We then forgot that we needed to do it. Fix the omission.

(The reason for the 2.30 requirement is use of
g_dir_make_tmp() -- our fallback implementation uses
mkdtemp(), which isn't available on Windows.)

Reported-by: Mark Cave-Ayland 
Signed-off-by: Peter Maydell 
---
 configure | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 4b3b5cd..be4d326 100755
--- a/configure
+++ b/configure
@@ -3073,7 +3073,11 @@ fi
 ##
 # glib support probe

-glib_req_ver=2.22
+if test "$mingw32" = yes; then
+glib_req_ver=2.30
+else
+glib_req_ver=2.22
+fi
 glib_modules=gthread-2.0
 if test "$modules" = yes; then
 glib_modules="$glib_modules gmodule-2.0"



Reviewed-by: Stefan Weil 

Thanks
Stefan

Re: [Qemu-devel] LEON3 timer patch

[Fabien Chouteau]

On 30/03/2017 21:30, Gabriele Galeotti wrote:
> 
> Hi all.
> According to "GR712RC Dual-Core LEON3FT SPARC V8 Processor User’s Manual",
> "11.3 Registers", pg 87-88, Table 55 Timer control register, the IP 
> "interrupt pending"
> bit:
> 
> Interrupt Pending (IP): The core sets this bit to ‘1’ when an interrupt is 
> signalled. This bit remains ‘1’
> until cleared by writing ‘0’ to this bit.
> 
> Thus  the code handling should changed so that the pending bit is mantained 
> when "value" has a 1
> in that position.

Thanks Gabriele,

I think my implementation is based on the "GRLIB IP Core User' Manual"
which says "Interrupt Pending (IP): The core sets this bit to "1" when
an interrupt is signalled. This bit remains "1" until cleared by writing
"1" to this bit, writes of "0" have no effect."

Do you know why the two docs are different on that aspect?


> 
> Signed-off-by: Gabriele Galeotti 
> ---
>  hw/timer/grlib_gptimer.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/hw/timer/grlib_gptimer.c b/hw/timer/grlib_gptimer.c
> index 4ed96e9..c555ae8 100644
> --- a/hw/timer/grlib_gptimer.c
> +++ b/hw/timer/grlib_gptimer.c
> @@ -276,9 +276,6 @@ static void grlib_gptimer_write(void *opaque, hwaddr addr,
>  trace_grlib_gptimer_writel(id, addr, value);
> .
>  if (value & GPTIMER_INT_PENDING) {
> -/* clear pending bit */
> -value &= ~GPTIMER_INT_PENDING;
> -} else {
>  /* keep pending bit */
>  value |= unit->timers[id].config & GPTIMER_INT_PENDING;
>  }

My understanding is that with your modifications, users can set the
pending bit by writing one to it.


I suggest something like this:

diff --git a/hw/timer/grlib_gptimer.c b/hw/timer/grlib_gptimer.c
index a05304d..4344787 100644
--- a/hw/timer/grlib_gptimer.c
+++ b/hw/timer/grlib_gptimer.c
@@ -275,11 +275,14 @@ static void grlib_gptimer_write(void *opaque, hwaddr addr,
 case CONFIG_OFFSET:
 trace_grlib_gptimer_writel(id, addr, value);

+/* Interrupt pending. Remains 1 until cleared by writing 0 to this
+ * bit.
+ */
 if (value & GPTIMER_INT_PENDING) {
-/* clear pending bit */
+/* Clear pending bit in value */
 value &= ~GPTIMER_INT_PENDING;
-} else {
-/* keep pending bit */
+
+/* Read current pending bit from register */
 value |= unit->timers[id].config & GPTIMER_INT_PENDING;
 }


Regards,

Re: [Qemu-devel] [PULL 00/15] Block patches for rc3

[Peter Maydell]

On 3 April 2017 at 16:33, Max Reitz  wrote:
> The following changes since commit 102a3d847891f48c0b13cace19d189217b05a725:
>
>   usb-host: switch to LIBUSB_API_VERSION (2017-04-03 14:41:23 +0100)
>
> are available in the git repository at:
>
>   git://github.com/XanClic/qemu.git tags/pull-block-2017-04-03
>
> for you to fetch changes up to 86d1bd70987cd11d85d01f52aa5824c63d910471:
>
>   block/parallels: Avoid overflows (2017-04-03 17:11:40 +0200)
>
> 
> Block patches for 2.9-rc3
>

Applied, thanks.

-- PMM