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

[Markus Armbruster]

Eric Blake  writes:

> On 03/24/2017 09:10 AM, Jeff Cody wrote:
>> On Fri, Mar 24, 2017 at 08:49:20AM -0500, Eric Blake wrote:
>>> On 03/24/2017 07:42 AM, Jeff Cody wrote:
>>>
 Agree.  My preference is to leave it as an array of methods, so long as 
 that
 is tenable to libvirt.
>>>
>>> The -drive syntax should remain unchanged (that's an absolute must for
>>> libvirt).  But the QMP syntax being an array of methods sounds best to
>>> me, and I think password-secret should be part of the array.  So my vote
>>> would be for:
>>>
>>> { "driver": "rbd", "image": "foo",
>>>   "auth": [ { "type": "cephx", "password-secret": "sec0" },
>>> { "type": "none" } ],
>>>   "pool": "bar" }
>>>
>>> It makes mapping -drive arguments into QMP form a bit trickier, but the
>>> QMP form is then easily extensible if we add another auth method down
>>> the road.
>>>
>> 
>> In that case, what about adding user as well, and not just password-secret?
>
> Makes sense - anything that is associated solely with cephx should
> belong to the same flat-union branch for cephx, rather than at the top
> level.

I've thought about this some more and have come to the conclusion that
this design is clumsy and overly complex.  Moreover, I suspect our
testing has been poor.  Let me explain.

= Overview =

What we're trying to configure is authentication methods the client is
to offer to the server.

This is not a list, it's a set: the order doesn't matter, and multiple
entries of the same type make no sense.  We could reject multiple
entries, or let the last one win silently, but this is just unnecessary
complexity.

Type "cephx" uses a user name and a key.

Type "none" uses neither (it could theoretically use the user name, but
I've been assured it doesn't).

The user name defaults to "admin".

The key defaults to the user name's entry in a keyring.  There is a
configurable list of key ring files, with a default.  The default
commonly includes /etc/ceph/client.keyring.

= Librados configuration =

Librados takes these configuration bits as follows:

* The user name is to be passed to rados_create().  NULL means default
  to "admin".

* The key may be passed to rados_conf_set() with key "key" (value is the
  key) or "keyfile" (value is name of the file containing the key).
  Documentation discourages use of "key".

* The list of keyrings may passed to rados_conf_set() with key
  "keyring" and a value listing file names separated by ','.  At least
  according to the documentation; the source looks like any non-empty
  sequence of [;,= \t]* serves as separator.

* The offered authentication methods may be passed to rados_conf_set()
  with key "auth_supported" (deprecated) or "auth_client_required", and
  a value listing methods separated by "," (or maybe [;,= \t]*, see
  above).  The methods are "cephx" and "none".  Default is "cephx,none".

= Command line -drive =

With -drive file=rbd:pool/image[@snapshot][:key=value...], the
key=value... part lets you specify arbitrary rados_conf_set() settings,
except pseudo-key "id" is mapped to the user name instead, and
pseudo-key "conf" names a rados configuration file.  This overloading of
rados_conf_set() keys and our own pseudo-keys isn't pretty, but it's a
done deal.  The full set of authentication configuration discussed above
is available as keys "id", "key", "keyfile", "keyring", "auth_supported"
and "auth_client_required".  Also via "conf", of course.

These -drive rbd:...:key=value settings are also available in -drive
QemuOpts syntax -drive driver=rbd,key=value:

* Pseudo-key "id" is "user" in QemuOpts.

* Pseudo-key "conf" is "conf" in QemuOpts, too

* Any other keys together become "keyvalue-pairs" in QemuOpts, with
  the same key=value:... syntax.

Additionally, QemuOpts-only "password-secret" lets you set
rados_conf_set() key "key" to a value obtained from the QCryptoSecret
interface.

Note that @password-secret is a misnomer: this is *not* a password, it's
a *key*.  Calling it a password is confusing, and makes it harder to
mentally connect QMP and Ceph configuration.

The settings in file=rbd:... override the ones in QemuOpts (that's how
->bdrv_parse_filename() works), which in turn override (I think)
settings from a config file.  Note that *any* key other than "id" and
"conf" in file=rbd:... completely overrides *all* keys in
"keyvalue-pairs".

Except "password-secret" works the other way: it overrides "key" set in
file=rbd:... or "keyvalue-pairs".

As so often with syntactic sugar, once you actually explain how it
works, you realize what a bloody mess it is.

It's not quite clear whether "keyvalue-pairs" is really meant for the
user, or just for internal use to implement file=rbd:...  I posted a
patch to hide it from the user.

= QMP blockdev-add and command line -blockdev =

The current QAPI/QMP schema lets you specify only a few settings
directly: pseudo-keys "id" and "conf" (optional members @user and
@conf), keys "key" and "auth_supported" 

Re: [Qemu-devel] Problems with native Mingw-w64 build

[Mark Cave-Ayland]

On 26/03/17 20:54, Stefan Weil wrote:

> Am 26.03.2017 um 14:57 schrieb Peter Maydell:
>> On 26 March 2017 at 11:30, Mark Cave-Ayland
>>  wrote:
>>> In order to do some testing on a Windows box, I've spent a bit of time
>>> this weekend setting up a mingw-w64 build environment on Windows 10
>>> using http://wiki.qemu-project.org/Hosts/W32 as a guideline.
>>
>> I think most people prefer to use the cross-compile.
>> Stefan might do native compiles.
> 
> All installers on https://qemu.weilnetz.de/ are cross built
> on Debian GNU Linux, but from time to time I also build on
> Windows.
> 
> Setting up a build environment based on Cygwin works pretty
> well because Cygwin includes most needed packages to cross
> compile for Mingw-w64, both for 32 bit (mingw64-i686-*)
> and 64 bit (mingw64-x86_64-*), see
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-=x86_64.
> 
> I also use the Cygwin packages on Debian GNU Linux,
> because Debian includes cross tools (compiler, linker)
> for Mingw-w64, but nearly no libraries.

Right, I see cygwin has a much newer version of glib available which
explains how the builds are produced.

What was the exact issue with global symbols which prevents the
pre-built Win64 binaries from glib > 2.22 being used? Or is that
information now obsolete?


ATB,

Mark.

Re: [Qemu-devel] [PATCH RESEND] xen: limit pkg-config to PKG_CONFIG_PATH for xen libraries

[Juergen Gross]

On 24/03/17 20:34, Paul Durrant wrote:
>> -Original Message-
>> From: Qemu-devel [mailto:qemu-devel-
>> bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant
>> Sent: 24 March 2017 19:18
>> To: 'Stefano Stabellini' ; Juergen Gross
>> 
>> Cc: Anthony Perard ; xen-
>> de...@lists.xenproject.org; qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] [PATCH RESEND] xen: limit pkg-config to
>> PKG_CONFIG_PATH for xen libraries
>>
>>> -Original Message-
>>> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
>>> Sent: 24 March 2017 19:12
>>> To: Juergen Gross 
>>> Cc: Paul Durrant ; qemu-devel@nongnu.org;
>> xen-
>>> de...@lists.xenproject.org; Anthony Perard
>> ;
>>> Stefano Stabellini 
>>> Subject: Re: [PATCH RESEND] xen: limit pkg-config to PKG_CONFIG_PATH
>> for
>>> xen libraries
>>>
>>> On Fri, 24 Mar 2017, Juergen Gross wrote:
 On 24/03/17 18:20, Paul Durrant wrote:
> The Xen tools Makefile has been modified to set PKG_CONFIG_PATH
>>> such that
> use of pkg-config in QEMU configure finds the newly built Xen libraries.
> However, because older versions of Xen do not set
>> PKG_CONFIG_PATH
>>> in the
> Makefile, the QEMU configure script will pick up any Xen libraries that
>>> may
> be installed in the build system rather than the newly built ones. Thus,
> if Xen 4.9 is built and installed it becomes impossible to build tools for
> an older version of Xen on the same system (without manual de-
>>> installtion).
>
> This patch modifies configure to set PKG_CONFIG_LIBDIR to empty
>> when
> looking for Xen libraries to ensure the search is limited only to
> PKG_CONFIG_PATH. This makes sure that, for versions of Xen prior to
>>> 4.9,
> pkg-config fails to find the Xen libraries an approriately falls back to
> previous methods of probing.
>
> Signed-off-by: Paul Durrant 
>>>
>>> Paul, thanks for spotting this. I didn't spot it because I don't have
>>> Xen installed in my build environment, but we should not rely on that.
>>>
>>>
 NAK. You are breaking normal qemu build with installed Xen pkg-config
 files.
>>>
>>> The normal QEMU build, done as part of the xen-unstable build, is
>>> actually done without Xen being installed in the system. So, if I am not
>>> mistaken, the current mechanism also breaks the following entirely
>>> legitimate scenario:
>>>
>>> - user has 4.9 installed on her system
>>> - user git clones xen 4.10
>>> - user build xen 4.10
>>>   - as part of the xen build, qemu is cloned and built
>>>   - the qemu configure script picks up the pkgconfig file from
>>> /usr/share and misconfigure the xen version, setting it to 4.9
>>> instead of 4.10
>>>   - the qemu build fails
>>> - the xen build fails
>>>
>>> Am I right?
>>>
>>
>> I think the above would actually work because the 4.10 files would be found
>> before the 4.9 files. What fails is installing 4.9 and then trying to build 
>> 4.8.
> 
> I should qualify that with saying 'trying to build 4.8 with a newer QEMU 
> (i.e. one that has a configure which knows about pkg-config).
> I still think that's a legitimate use-case though.

To sum it up we have to care about the following scenarios:

a) Xen in-tree build, Xen >= 4.9
b) Xen in-tree build, Xen < 4.9
c) build out-of-Xen-tree

combined with any of:

1) no Xen installed on build machine
2) Xen >= 4.9 installed
3) Xen < 4.9 installed

1) + c) is not supported, all other combinations should work.

I suggest the following modifications of my patch:

- keep the test program for detection of Xen 4.9
- scan the extra ldflags for special mentioning of tools/libxc
  to detect Xen in-tree build < 4.9 (will detect 4.9, too, but
  this is no problem), set xen_in_tree_old if found
- if xen_in_tree_old found, don't use pkg-config for Xen version
  detection and flags
- otherwise try pkg-config first

This should cover all cases we need.


Juergen

Re: [Qemu-devel] [PATCH-for-2.9] replay/replay.c: bump REPLAY_VERSION

[Pavel Dovgalyuk]

Reviewed-by: Pavel Dovgalyuk 


> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: Friday, March 24, 2017 6:26 PM
> To: pavel.dovga...@ispras.ru
> Cc: qemu-devel@nongnu.org; Alex Bennée
> Subject: [PATCH-for-2.9] replay/replay.c: bump REPLAY_VERSION
> 
> A previous commit (3d4d16f4) added support for audio record/playback.
> However this breaks the logfile ABI due to the re-ordering of the
> ReplayEvents enum. The REPLAY_VERSION check is meant to prevent you
> from using old log files in newer QEMUs but this is currently broken.
> 
> Signed-off-by: Alex Bennée 
> ---
>  replay/replay.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/replay/replay.c b/replay/replay.c
> index 78e2a7e570..9e0724e756 100644
> --- a/replay/replay.c
> +++ b/replay/replay.c
> @@ -22,7 +22,7 @@
> 
>  /* Current version of the replay mechanism.
> Increase it when file format changes. */
> -#define REPLAY_VERSION  0xe02005
> +#define REPLAY_VERSION  0xe02006
>  /* Size of replay log header */
>  #define HEADER_SIZE (sizeof(uint32_t) + sizeof(uint64_t))
> 
> --
> 2.11.0

Re: [Qemu-devel] [PULL v3 1/3] replay: add record/replay for audio passthrough

[Pavel Dovgalyuk]

> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> > From: Pavel Dovgalyuk 
> >
> > This patch adds recording and replaying audio data. Is saves synchronization
> > information for audio out and inputs from the microphone.
> >
> > v2: removed unneeded whitespace change
> >
> > Signed-off-by: Pavel Dovgalyuk 
> > Message-id: 20170202055054.4848.94901.st...@pasha-isp.lan02.inno
> >
> > [ kraxel: add qemu/error-report.h include to fix osx build failure ]
> >
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  audio/audio.c|  9 --
> >  audio/audio.h|  5 +++
> >  audio/mixeng.c   | 32 
> >  docs/replay.txt  |  7 +
> >  include/sysemu/replay.h  |  7 +
> >  replay/Makefile.objs |  1 +
> >  replay/replay-audio.c| 79 
> > 
> >  replay/replay-internal.h |  4 +++
> >  8 files changed, 142 insertions(+), 2 deletions(-)
> >  create mode 100644 replay/replay-audio.c
> >
> 
> > diff --git a/replay/replay-internal.h b/replay/replay-internal.h
> > index c26d079..ed66ed8 100644
> > --- a/replay/replay-internal.h
> > +++ b/replay/replay-internal.h
> > @@ -29,6 +29,10 @@ enum ReplayEvents {
> >  /* for character device read all event */
> >  EVENT_CHAR_READ_ALL,
> >  EVENT_CHAR_READ_ALL_ERROR,
> > +/* for audio out event */
> > +EVENT_AUDIO_OUT,
> > +/* for audio in event */
> > +EVENT_AUDIO_IN,
> >  /* for clock read/writes */
> >  /* some of greater codes are reserved for clocks */
> >  EVENT_CLOCK,
> 
> Well one thing I noticed while I was trying to work out the difference
> between pre/post mttcg replay problems is the log format ABI has
> changed. REPLAY_VERSION needs to be bumped to prevent confusion.

Right, I missed that while sending the patches.

Pavel Dovgalyuk

[Qemu-devel] [PATCH qemu] target-ppc/kvm: Enable in-kernel TCE acceleration for multi-tce

[Alexey Kardashevskiy]

This enables in-kernel handling of H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls. The host kernel support is there since v4.6,
in particular d3695aa4f452
("KVM: PPC: Add support for multiple-TCE hcalls").

H_PUT_TCE is already accelerated and does not need any special enablement.

Signed-off-by: Alexey Kardashevskiy 
---
 target/ppc/kvm_ppc.h |  6 ++
 hw/ppc/spapr.c   |  4 +++-
 target/ppc/kvm.c | 14 ++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index 4b2fd9a609..f48243d13f 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -39,6 +39,7 @@ target_ulong kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
 #ifndef CONFIG_USER_ONLY
 off_t kvmppc_alloc_rma(void **rma);
 bool kvmppc_spapr_use_multitce(void);
+int kvmppc_spapr_enable_inkernel_multitce(void);
 void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t page_shift,
   uint64_t bus_offset, uint32_t nb_table,
   int *pfd, bool need_vfio);
@@ -180,6 +181,11 @@ static inline bool kvmppc_spapr_use_multitce(void)
 return false;
 }
 
+static inline int kvmppc_spapr_enable_inkernel_multitce(void)
+{
+return -1;
+}
+
 static inline void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
page_shift,
 uint64_t bus_offset,
 uint32_t nb_table,
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 0e1c29bcf8..8027716f73 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2360,10 +2360,12 @@ static void ppc_spapr_init(MachineState *machine)
 
 qemu_register_boot_set(spapr_boot_set, spapr);
 
-/* to stop and start vmclock */
 if (kvm_enabled()) {
+/* to stop and start vmclock */
 qemu_add_vm_change_state_handler(cpu_ppc_clock_vm_state_change,
  >tb);
+
+kvmppc_spapr_enable_inkernel_multitce();
 }
 }
 
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 6dc39623e5..560ce655c7 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2194,6 +2194,20 @@ bool kvmppc_spapr_use_multitce(void)
 return cap_spapr_multitce;
 }
 
+int kvmppc_spapr_enable_inkernel_multitce(void)
+{
+int ret;
+
+ret = kvm_vm_enable_cap(kvm_state, KVM_CAP_PPC_ENABLE_HCALL, 0,
+H_PUT_TCE_INDIRECT, 1);
+if (!ret) {
+ret = kvm_vm_enable_cap(kvm_state, KVM_CAP_PPC_ENABLE_HCALL, 0,
+H_STUFF_TCE, 1);
+}
+
+return ret;
+}
+
 void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t page_shift,
   uint64_t bus_offset, uint32_t nb_table,
   int *pfd, bool need_vfio)
-- 
2.11.0

Re: [Qemu-devel] [PATCH 03/51] ram: Create RAMState

[Peter Xu]

On Thu, Mar 23, 2017 at 09:44:56PM +0100, Juan Quintela wrote:
> We create a struct where to put all the ram state
> 
> Start with the following fields:
> 
> last_seen_block, last_sent_block, last_offset, last_version and
> ram_bulk_stage are globals that are really related together.
> 
> Signed-off-by: Juan Quintela 
> Reviewed-by: Dr. David Alan Gilbert 

Reviewed-by: Peter Xu 

-- peterx

[Qemu-devel] [PATCH qemu] pci: Add missing drop of bus master AS reference

[Alexey Kardashevskiy]

The recent introduction of a bus master container added
memory_region_add_subregion() into the PCI device registering path but
missed memory_region_del_subregion() in the unregistering path leaving
a reference to the root memory region of the new container.

This adds missing memory_region_del_subregion().

Fixes: 3716d5902d743 ("pci: introduce a bus master container")
Signed-off-by: Alexey Kardashevskiy 
---
 hw/pci/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e6b08e1988..bd8043c460 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -869,6 +869,8 @@ static void do_pci_unregister_device(PCIDevice *pci_dev)
 pci_dev->bus->devices[pci_dev->devfn] = NULL;
 pci_config_free(pci_dev);
 
+memory_region_del_subregion(_dev->bus_master_container_region,
+_dev->bus_master_enable_region);
 address_space_destroy(_dev->bus_master_as);
 }
 
-- 
2.11.0

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

[ashish mittal]

On Wed, Mar 22, 2017 at 5:03 PM, ashish mittal  wrote:
> On Mon, Mar 20, 2017 at 5:55 AM, Daniel P. Berrange  
> wrote:
>> On Fri, Mar 17, 2017 at 06:44:56PM -0700, ashish mittal wrote:
>>> On Thu, Mar 16, 2017 at 5:29 PM, ashish mittal  wrote:
>>> > On Mon, Mar 13, 2017 at 2:57 AM, Daniel P. Berrange  
>>> > wrote:
>>> >> On Tue, Mar 07, 2017 at 05:27:55PM -0800, ashish mittal wrote:
>>> >>> Thanks! There is one more input I need some help with!
>>> >>>
>>> >>> VxHS network library opens a fixed number of connection channels to a
>>> >>> given host, and all the vdisks (that connect to the same host) share
>>> >>> these connection channels.
>>> >>>
>>> >>> Therefore, we need to open secure channels to a specific target host
>>> >>> only once for the first vdisk that connects to that host. All the
>>> >>> other vdisks that connect to the same target host will share the same
>>> >>> set of secure communication channels.
>>> >>>
>>> >>> I hope the above scheme is acceptable?
>>> >>>
>>> >>> If yes, then we have a couple of options to implement this:
>>> >>>
>>> >>> (1) Accept the TLS credentials per vdisk using the previously
>>> >>> discussed --object tls-creds-x509 mechanism. In this case, if more
>>> >>> than one vdisk have the same host info, then we will use only the
>>> >>> first one's creds to set up the secure connection, and ignore the
>>> >>> others. vdisks that connect to different target hosts will use their
>>> >>> individual tls-creds-x509 to set up the secure channels. This is, of
>>> >>> course, not relevant for qemu-img/qemu-io as they can open only one
>>> >>> vdisk at a time.
>>> >>
>>> >> It looks like option 1 here is the way to go. Just report an error if
>>> >> there are multiple creds provided for the same host and they don't
>>> >> match.
>>> >>
>>> >
>>> > I have made changes to implement option 1 in the library (branch
>>> > per_channel_ssl).
>>> > Can you please help review it?
>>> > https://github.com/VeritasHyperScale/libqnio/compare/per_channel_ssl
>>> >
>>> > Here's the changelog:
>>> > (1) Changed code to not use instance UUID for setting up SSL context.
>>> > (2) User is supposed to pass the cacert, client_key and client_cert
>>> > files to iio_open(). These will be used to set up a per-channel 
>>> > secure SSL
>>> > connection to the server. All three values are needed to set up a
>>> > secure connection.
>>> > (3) If the secure channel to a particular host is already open, other
>>> > block device connections to the same host will have to provide
>>> > TLS/SSL credentials that match the original one.
>>> > (4) Set default locations for trusted client CA certificates
>>> >  based on user specified cacert file.
>>> >
>>> > NB - I have given steps to test SSL communication (using the supplied
>>> > test client/server programs) in the commit log. I have not tested
>>> > using qemu binary yet. Will run more tests in the days to come.
>>> >
>>> > qemu vxhs patch changes should be pretty straightforward, given that
>>> > we have already discussed how to implement passing --object
>>> > tls-creds-x509 per block device.
>>> >
>>> > Thanks!
>>> >
>>>
>>> Update -
>>> (1) Successfully tested SSL communication using qemu-io and the test server.
>>> (2) Minor changes to per_channel_ssl branch.
>>> (3) Created a pull request.
>>>
>>> Please review per convenience. Thanks!
>>
>> IIUC, on that branch the 'is_secure()' method is still looking for the
>> directory /var/lib/libvxhs/secure to exist on the host. If that is not
>> present, then it appears to be silently ignoring the SSL certs passed
>> in from QEMU.
>>
>> IMHO it should enable TLS when 'cacert' passed to iio_open is not NULL,
>> not relying on a magic directory to exist.
>>
>
> I have made changes per above to the library. Please see commits -
>
> https://github.com/VeritasHyperScale/libqnio/commit/6c3261e9c9bb1350f4433a1ae4fcd98f7692cf39
> https://github.com/VeritasHyperScale/libqnio/commit/502c74278457e6ac86a4ee4ad9102e56ff3be5d4
>
> Commit log: Enable secure mode based on the SSL/TLS args passed in iio_open()
>
> (1) Do not use /var/lib/libvxhs/secure to enable secure SSL mode on
> the client side.
> (2) Instead, enable SSL mode if the user passes TLS/SSL creds for
> the block device on the qemu CLI.
>
> Will be posting v10 qemu vxhs patch soon. v10 will work with the
> latest library changes, and will support passing tls-creds-x509 creds
> for every vxhs block device.
>

I have posted v10 patches today. I've had to make one change in
addition to what has been discussed. Basically I cannot use
qcrypto_tls_creds_get_path() because its definition is under a #ifdef
CONFIG_GNUTLS. Therefore my builds were failing whenever "gnutls" was
not configured. I've replaced it as below -


diff --git a/block/vxhs.c b/block/vxhs.c
index 0aa7849..44c0ecd 100644
--- a/block/vxhs.c
+++ b/block/vxhs.c
@@ -19,7 +19,6 @@
 #include 

[Qemu-devel] [PATCH RFC v2 1/1] block: pass the right options for BlockDriver.bdrv_open

[Dong Jia Shi]

raw_open() expects the caller always passing in the right actual
@options parameter. But when trying to applying snapshot on a RBD
image, bdrv_snapshot_goto() calls raw_open() (by calling the
bdrv_open callback on the BlockDriver) with a NULL @options, and
that will result in a Segmentation fault.

For the other non-raw format drivers, it also make sense to passing
in the actual options, althought they don't trigger the problem so
far.

Let's prepare a @options by adding the "file" key-value pair to a
copy of the actual options that were given for the node (i.e.
bs->options), and pass it to the callback.

Signed-off-by: Dong Jia Shi 
---
 block/snapshot.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/block/snapshot.c b/block/snapshot.c
index bf5c2ca..dfec139 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -27,6 +27,7 @@
 #include "block/block_int.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qerror.h"
+#include "qapi/qmp/qstring.h"
 
 QemuOptsList internal_snapshot_opts = {
 .name = "snapshot",
@@ -189,9 +190,14 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
 }
 
 if (bs->file) {
+QDict *options = qdict_clone_shallow(bs->options);
+qdict_put(options, "file",
+  qstring_from_str(bdrv_get_node_name(bs->file->bs)));
+
 drv->bdrv_close(bs);
 ret = bdrv_snapshot_goto(bs->file->bs, snapshot_id);
-open_ret = drv->bdrv_open(bs, NULL, bs->open_flags, NULL);
+open_ret = drv->bdrv_open(bs, options, bs->open_flags, NULL);
+QDECREF(options);
 if (open_ret < 0) {
 bdrv_unref(bs->file->bs);
 bs->drv = NULL;
-- 
2.8.4

[Qemu-devel] [PATCH RFC v2 0/1] block: pass the right options for BlockDriver.bdrv_open

[Dong Jia Shi]

Trying to restore rbd image on ceph cluster from snapshot with
qemu-img could trigger a calling to raw_open with a NULL @options,
and that will lead to a failure of the snapshot applying.

[root@s8345007 ~]# gdb --args qemu-img snapshot -a snap1 rbd:test_pool/dj_image
... ...
Program received signal SIGSEGV, Segmentation fault.
0x801395a8 in qdict_next_entry (qdict=0x0, first_bucket=0) at 
qobject/qdict.c:327
327 if (!QLIST_EMPTY(>table[i])) {
(gdb) bt
#0  0x801395a8 in qdict_next_entry (qdict=0x0, first_bucket=0) at 
qobject/qdict.c:327
#1  0x80139626 in qdict_first (qdict=0x0) at qobject/qdict.c:340
#2  0x8013a00c in qdict_extract_subqdict (src=0x0, dst=0x3ffec50, 
start=0x80698260 "file.")
at qobject/qdict.c:576
#3  0x80019c26 in bdrv_open_child_bs (filename=0x0, options=0x0, 
bdref_key=0x8017ab38 "file", 
parent=0x80630300, child_role=0x80176108 , allow_none=false, 
errp=0x0) at block.c:2018
#4  0x80019dfa in bdrv_open_child (filename=0x0, options=0x0, 
bdref_key=0x8017ab38 "file", 
parent=0x80630300, child_role=0x80176108 , allow_none=false, 
errp=0x0) at block.c:2065
#5  0x8002b9a0 in raw_open (bs=0x80630300, options=0x0, flags=8194, 
errp=0x0) at block/raw-format.c:387
#6  0x80087516 in bdrv_snapshot_goto (bs=0x80630300, 
snapshot_id=0x3fff75c "snap1")
at block/snapshot.c:194
#7  0x80010b8c in img_snapshot (argc=4, argv=0x3fff4c0) at 
qemu-img.c:2937
#8  0x800140e4 in main (argc=4, argv=0x3fff4c0) at qemu-img.c:4373

The problematic code is /block/snapshot.c:194:
178 int bdrv_snapshot_goto(BlockDriverState *bs,
179const char *snapshot_id)
180 {
181 BlockDriver *drv = bs->drv;
182 int ret, open_ret;
183 
184 if (!drv) {
185 return -ENOMEDIUM;
186 }
187 if (drv->bdrv_snapshot_goto) {
188 return drv->bdrv_snapshot_goto(bs, snapshot_id);
189 }
190 
191 if (bs->file) {
192 drv->bdrv_close(bs);
193 ret = bdrv_snapshot_goto(bs->file->bs, snapshot_id);
194 open_ret = drv->bdrv_open(bs, NULL, bs->open_flags, NULL);
195 if (open_ret < 0) {
196 bdrv_unref(bs->file->bs);
197 bs->drv = NULL;
198 return open_ret;
199 }
200 return ret;
201 }
202 
203 return -ENOTSUP;
204 }

After a chat with Kevin, now my understanding is that's because
NULL @options is not a valid parameter value for the bdrv_open
callback of the BlockDriver.
We shoule prepare a @options by adding the "file" key-value pair
to the actual options that were given for the node (i.e.
bs->options), and pass it to the callback.

Dong Jia Shi (1):
  block: pass the right options for BlockDriver.bdrv_open

 block/snapshot.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.8.4

[Qemu-devel] [PATCH v10 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 
---
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 v10 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 
---

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 | 595 +++
 configure|  39 
 qapi/block-core.json |  22 +-
 5 files changed, 673 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"
+
+# block/vxhs.c
+vxhs_iio_callback(int error) "ctx is NULL: error %d"
+vxhs_iio_callback_chnfail(int err, int error) "QNIO channel failed, no i/o %d, 
%d"
+vxhs_iio_callback_unknwn(int opcode, int err) "unexpected opcode %d, errno %d"
+vxhs_aio_rw_invalid(int req) "Invalid I/O request 

Re: [Qemu-devel] [PATCH v2] migration: Fix colo hang in socket_accept_incoming_migration

[Hailiang Zhang]

Hi,

It seems that there is no difference from your previous version.
You don't have to re-send it if there are no changes.
This patch has been reviewed, so you can just wait until maintainers process it 
:)

Thanks.

On 2017/3/27 9:58, Guang Wang wrote:

From: Wang guang 

The channel socket was initialized manually,
but forgot to set QIO_CHANNEL_FEATURE_SHUTDOWN.
Thus, the colo_process_incoming_thread would hang at recvmsg.
This patch just call qio_channel_socket_new to get channel,
Which set QIO_CHANNEL_FEATURE_SHUTDOWN already.

Signed-off-by: Wang Guang
Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
---
  io/channel-socket.c | 8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/io/channel-socket.c b/io/channel-socket.c
index f546c68..64b36f5 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -331,16 +331,10 @@ qio_channel_socket_accept(QIOChannelSocket *ioc,
  {
  QIOChannelSocket *cioc;
  
-cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET));

-cioc->fd = -1;
+cioc = qio_channel_socket_new();
  cioc->remoteAddrLen = sizeof(ioc->remoteAddr);
  cioc->localAddrLen = sizeof(ioc->localAddr);
  
-#ifdef WIN32

-QIO_CHANNEL(cioc)->event = CreateEvent(NULL, FALSE, FALSE, NULL);
-#endif
-
-
   retry:
  trace_qio_channel_socket_accept(ioc);
  cioc->fd = qemu_accept(ioc->fd, (struct sockaddr *)>remoteAddr,

[Qemu-devel] [PATCH v2] migration: Fix colo hang in socket_accept_incoming_migration

[Guang Wang]

From: Wang guang 

The channel socket was initialized manually, 
but forgot to set QIO_CHANNEL_FEATURE_SHUTDOWN.
Thus, the colo_process_incoming_thread would hang at recvmsg.
This patch just call qio_channel_socket_new to get channel,
Which set QIO_CHANNEL_FEATURE_SHUTDOWN already.

Signed-off-by: Wang Guang
Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
---
 io/channel-socket.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/io/channel-socket.c b/io/channel-socket.c
index f546c68..64b36f5 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -331,16 +331,10 @@ qio_channel_socket_accept(QIOChannelSocket *ioc,
 {
 QIOChannelSocket *cioc;
 
-cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET));
-cioc->fd = -1;
+cioc = qio_channel_socket_new();
 cioc->remoteAddrLen = sizeof(ioc->remoteAddr);
 cioc->localAddrLen = sizeof(ioc->localAddr);
 
-#ifdef WIN32
-QIO_CHANNEL(cioc)->event = CreateEvent(NULL, FALSE, FALSE, NULL);
-#endif
-
-
  retry:
 trace_qio_channel_socket_accept(ioc);
 cioc->fd = qemu_accept(ioc->fd, (struct sockaddr *)>remoteAddr,
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH for-2.10 01/23] tests: add CPUs to numa node mapping test

[David Gibson]

On Wed, Mar 22, 2017 at 02:32:26PM +0100, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 

Reviewed-by: David Gibson 

> ---
>  tests/Makefile.include |   5 +++
>  tests/numa-test.c  | 106 
> +
>  2 files changed, 111 insertions(+)
>  create mode 100644 tests/numa-test.c
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 402e71c..4547b01 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -260,6 +260,7 @@ check-qtest-i386-y += tests/test-filter-mirror$(EXESUF)
>  check-qtest-i386-y += tests/test-filter-redirector$(EXESUF)
>  check-qtest-i386-y += tests/postcopy-test$(EXESUF)
>  check-qtest-i386-y += tests/test-x86-cpuid-compat$(EXESUF)
> +check-qtest-i386-y += tests/numa-test$(EXESUF)
>  check-qtest-x86_64-y += $(check-qtest-i386-y)
>  gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
>  gcov-files-x86_64-y = $(subst 
> i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
> @@ -300,6 +301,7 @@ check-qtest-ppc64-y += tests/test-netfilter$(EXESUF)
>  check-qtest-ppc64-y += tests/test-filter-mirror$(EXESUF)
>  check-qtest-ppc64-y += tests/test-filter-redirector$(EXESUF)
>  check-qtest-ppc64-y += tests/display-vga-test$(EXESUF)
> +check-qtest-ppc64-y += tests/numa-test$(EXESUF)
>  check-qtest-ppc64-$(CONFIG_EVENTFD) += tests/ivshmem-test$(EXESUF)
>  
>  check-qtest-sh4-y = tests/endianness-test$(EXESUF)
> @@ -324,6 +326,8 @@ gcov-files-arm-y += arm-softmmu/hw/block/virtio-blk.c
>  check-qtest-arm-y += tests/test-arm-mptimer$(EXESUF)
>  gcov-files-arm-y += hw/timer/arm_mptimer.c
>  
> +check-qtest-aarch64-y = tests/numa-test$(EXESUF)
> +
>  check-qtest-microblazeel-y = $(check-qtest-microblaze-y)
>  
>  check-qtest-xtensaeb-y = $(check-qtest-xtensa-y)
> @@ -747,6 +751,7 @@ tests/vhost-user-bridge$(EXESUF): 
> tests/vhost-user-bridge.o contrib/libvhost-use
>  tests/test-uuid$(EXESUF): tests/test-uuid.o $(test-util-obj-y)
>  tests/test-arm-mptimer$(EXESUF): tests/test-arm-mptimer.o
>  tests/test-qapi-util$(EXESUF): tests/test-qapi-util.o $(test-util-obj-y)
> +tests/numa-test$(EXESUF): tests/numa-test.o
>  
>  tests/migration/stress$(EXESUF): tests/migration/stress.o
>   $(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $< 
> ,"LINK","$(TARGET_DIR)$@")
> diff --git a/tests/numa-test.c b/tests/numa-test.c
> new file mode 100644
> index 000..f5da0c8
> --- /dev/null
> +++ b/tests/numa-test.c
> @@ -0,0 +1,106 @@
> +/*
> + * NUMA configuration test cases
> + *
> + * Copyright (c) 2017 Red Hat Inc.
> + * Authors:
> + *  Igor Mammedov 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "libqtest.h"
> +
> +static char *make_cli(const char *generic_cli, const char *test_cli)
> +{
> +return g_strdup_printf("%s %s", generic_cli ? generic_cli : "", 
> test_cli);
> +}
> +
> +static char *hmp_info_numa(void)
> +{
> +QDict *resp;
> +char *s;
> +
> +resp = qmp("{ 'execute': 'human-monitor-command', 'arguments': "
> +  "{ 'command-line': 'info numa '} }");
> +g_assert(resp);
> +g_assert(qdict_haskey(resp, "return"));
> +s = g_strdup(qdict_get_str(resp, "return"));
> +g_assert(s);
> +QDECREF(resp);
> +return s;
> +}
> +
> +static void test_mon_explicit(const void *data)
> +{
> +char *s;
> +char *cli;
> +
> +cli = make_cli(data, "-smp 8 "
> +   "-numa node,nodeid=0,cpus=0-3 "
> +   "-numa node,nodeid=1,cpus=4-7 ");
> +qtest_start(cli);
> +
> +s = hmp_info_numa();
> +g_assert(strstr(s, "node 0 cpus: 0 1 2 3"));
> +g_assert(strstr(s, "node 1 cpus: 4 5 6 7"));
> +g_free(s);
> +
> +qtest_end();
> +g_free(cli);
> +}
> +
> +static void test_mon_default(const void *data)
> +{
> +char *s;
> +char *cli;
> +
> +cli = make_cli(data, "-smp 8 -numa node -numa node");
> +qtest_start(cli);
> +
> +s = hmp_info_numa();
> +g_assert(strstr(s, "node 0 cpus: 0 2 4 6"));
> +g_assert(strstr(s, "node 1 cpus: 1 3 5 7"));
> +g_free(s);
> +
> +qtest_end();
> +g_free(cli);
> +}
> +
> +static void test_mon_partial(const void *data)
> +{
> +char *s;
> +char *cli;
> +
> +cli = make_cli(data, "-smp 8 "
> +   "-numa node,nodeid=0,cpus=0-1 "
> +   "-numa node,nodeid=1,cpus=4-5 ");
> +qtest_start(cli);
> +
> +s = hmp_info_numa();
> +g_assert(strstr(s, "node 0 cpus: 0 1 2 3 6 7"));
> +g_assert(strstr(s, "node 1 cpus: 4 5"));
> +g_free(s);
> +
> +qtest_end();
> +g_free(cli);
> +}
> +
> +int main(int argc, char **argv)
> +{
> +const char *args = NULL;
> +const char *arch = qtest_get_arch();
> +
> +if (strcmp(arch, "aarch64") == 0) {
> +args = "-machine virt";
> +}
> +

Re: [Qemu-devel] Problems with native Mingw-w64 build

[Stefan Weil]

Am 26.03.2017 um 14:57 schrieb Peter Maydell:

On 26 March 2017 at 11:30, Mark Cave-Ayland
 wrote:

In order to do some testing on a Windows box, I've spent a bit of time
this weekend setting up a mingw-w64 build environment on Windows 10
using http://wiki.qemu-project.org/Hosts/W32 as a guideline.


I think most people prefer to use the cross-compile.
Stefan might do native compiles.


All installers on https://qemu.weilnetz.de/ are cross built
on Debian GNU Linux, but from time to time I also build on
Windows.

Setting up a build environment based on Cygwin works pretty
well because Cygwin includes most needed packages to cross
compile for Mingw-w64, both for 32 bit (mingw64-i686-*)
and 64 bit (mingw64-x86_64-*), see
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-=x86_64.

I also use the Cygwin packages on Debian GNU Linux,
because Debian includes cross tools (compiler, linker)
for Mingw-w64, but nearly no libraries.

Stefan

[Qemu-devel] [PATCH 1/2] slirp: Make RA build more flexible

[Samuel Thibault]

Do not hardcode the RA size at all, use a pl_size variable which
accounts the accumulated size, and fill rip->ip_pl at the end.

This will allow to make some blocks optional.

Signed-off-by: Samuel Thibault 
---
 slirp/ip6_icmp.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/slirp/ip6_icmp.c b/slirp/ip6_icmp.c
index 298a48dd25..d0f5cc1456 100644
--- a/slirp/ip6_icmp.c
+++ b/slirp/ip6_icmp.c
@@ -143,17 +143,10 @@ void ndp_send_ra(Slirp *slirp)
 /* Build IPv6 packet */
 struct mbuf *t = m_get(slirp);
 struct ip6 *rip = mtod(t, struct ip6 *);
+size_t pl_size = 0;
 rip->ip_src = (struct in6_addr)LINKLOCAL_ADDR;
 rip->ip_dst = (struct in6_addr)ALLNODES_MULTICAST;
 rip->ip_nh = IPPROTO_ICMPV6;
-rip->ip_pl = htons(ICMP6_NDP_RA_MINLEN
-+ NDPOPT_LINKLAYER_LEN
-+ NDPOPT_PREFIXINFO_LEN
-#ifndef _WIN32
-+ NDPOPT_RDNSS_LEN
-#endif
-);
-t->m_len = sizeof(struct ip6) + ntohs(rip->ip_pl);
 
 /* Build ICMPv6 packet */
 t->m_data += sizeof(struct ip6);
@@ -171,6 +164,7 @@ void ndp_send_ra(Slirp *slirp)
 ricmp->icmp6_nra.reach_time = htonl(NDP_AdvReachableTime);
 ricmp->icmp6_nra.retrans_time = htonl(NDP_AdvRetransTime);
 t->m_data += ICMP6_NDP_RA_MINLEN;
+pl_size += ICMP6_NDP_RA_MINLEN;
 
 /* Source link-layer address (NDP option) */
 struct ndpopt *opt = mtod(t, struct ndpopt *);
@@ -178,6 +172,7 @@ void ndp_send_ra(Slirp *slirp)
 opt->ndpopt_len = NDPOPT_LINKLAYER_LEN / 8;
 in6_compute_ethaddr(rip->ip_src, opt->ndpopt_linklayer);
 t->m_data += NDPOPT_LINKLAYER_LEN;
+pl_size += NDPOPT_LINKLAYER_LEN;
 
 /* Prefix information (NDP option) */
 struct ndpopt *opt2 = mtod(t, struct ndpopt *);
@@ -192,6 +187,7 @@ void ndp_send_ra(Slirp *slirp)
 opt2->ndpopt_prefixinfo.reserved2 = 0;
 opt2->ndpopt_prefixinfo.prefix = slirp->vprefix_addr6;
 t->m_data += NDPOPT_PREFIXINFO_LEN;
+pl_size += NDPOPT_PREFIXINFO_LEN;
 
 #ifndef _WIN32
 /* Prefix information (NDP option) */
@@ -203,16 +199,14 @@ void ndp_send_ra(Slirp *slirp)
 opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
 opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
 t->m_data += NDPOPT_RDNSS_LEN;
+pl_size += NDPOPT_RDNSS_LEN;
 #endif
 
+rip->ip_pl = htons(pl_size);
+t->m_data -= sizeof(struct ip6) + pl_size;
+t->m_len = sizeof(struct ip6) + pl_size;
+
 /* ICMPv6 Checksum */
-#ifndef _WIN32
-t->m_data -= NDPOPT_RDNSS_LEN;
-#endif
-t->m_data -= NDPOPT_PREFIXINFO_LEN;
-t->m_data -= NDPOPT_LINKLAYER_LEN;
-t->m_data -= ICMP6_NDP_RA_MINLEN;
-t->m_data -= sizeof(struct ip6);
 ricmp->icmp6_cksum = ip6_cksum(t);
 
 ip6_output(NULL, t, 0);
-- 
2.11.0

[Qemu-devel] [PATCH 0/2] Fix spurious RDNSS announce

[Samuel Thibault]

Hello,

These two patches fix sending the IPv6 RDNSS announce only when
it can actually work, fixing the bug reported by Cole Robinson
.  Could somebody review them before I can send
a pull update?

Samuel Thibault (2):
  slirp: Make RA build more flexible
  slirp: Send RDNSS in RA only if host has an IPv6 DNS server

 slirp/ip6_icmp.c | 48 +++-
 1 file changed, 23 insertions(+), 25 deletions(-)

-- 
2.11.0

[Qemu-devel] [PATCH 2/2] slirp: Send RDNSS in RA only if host has an IPv6 DNS server

[Samuel Thibault]

Previously we would always send an RDNSS option in the RA, making the guest
try to resolve DNS through IPv6, even if the host does not actually have
and IPv6 DNS server available.

This makes the RDNSS option enabled only when an IPv6 DNS server is
available.

Signed-off-by: Samuel Thibault 
---
 slirp/ip6_icmp.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/slirp/ip6_icmp.c b/slirp/ip6_icmp.c
index d0f5cc1456..00183e5945 100644
--- a/slirp/ip6_icmp.c
+++ b/slirp/ip6_icmp.c
@@ -189,18 +189,22 @@ void ndp_send_ra(Slirp *slirp)
 t->m_data += NDPOPT_PREFIXINFO_LEN;
 pl_size += NDPOPT_PREFIXINFO_LEN;
 
-#ifndef _WIN32
 /* Prefix information (NDP option) */
-/* disabled for windows for now, until get_dns6_addr is implemented */
-struct ndpopt *opt3 = mtod(t, struct ndpopt *);
-opt3->ndpopt_type = NDPOPT_RDNSS;
-opt3->ndpopt_len = NDPOPT_RDNSS_LEN / 8;
-opt3->ndpopt_rdnss.reserved = 0;
-opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
-opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
-t->m_data += NDPOPT_RDNSS_LEN;
-pl_size += NDPOPT_RDNSS_LEN;
-#endif
+{
+struct in6_addr addr;
+uint32_t scope_id;
+if (get_dns6_addr(, _id) >= 0) {
+/* Host system does have an IPv6 DNS server, announce our proxy.  
*/
+struct ndpopt *opt3 = mtod(t, struct ndpopt *);
+opt3->ndpopt_type = NDPOPT_RDNSS;
+opt3->ndpopt_len = NDPOPT_RDNSS_LEN / 8;
+opt3->ndpopt_rdnss.reserved = 0;
+opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
+opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
+t->m_data += NDPOPT_RDNSS_LEN;
+pl_size += NDPOPT_RDNSS_LEN;
+}
+}
 
 rip->ip_pl = htons(pl_size);
 t->m_data -= sizeof(struct ip6) + pl_size;
-- 
2.11.0

Re: [Qemu-devel] slirp + ipxe + ipv6 dns issue

[Samuel Thibault]

Hello,

Cole Robinson, on ven. 24 mars 2017 21:17:43 -0400, wrote:
> I bisected to this commit:
> 
> slirp: Add RDNSS advertisement

Mmm, I see.  Could you try the attached patch to confirm that it fixes
the issue for you too?

Samuel
diff --git a/slirp/ip6_icmp.c b/slirp/ip6_icmp.c
index 298a48dd25..00183e5945 100644
--- a/slirp/ip6_icmp.c
+++ b/slirp/ip6_icmp.c
@@ -143,17 +143,10 @@ void ndp_send_ra(Slirp *slirp)
 /* Build IPv6 packet */
 struct mbuf *t = m_get(slirp);
 struct ip6 *rip = mtod(t, struct ip6 *);
+size_t pl_size = 0;
 rip->ip_src = (struct in6_addr)LINKLOCAL_ADDR;
 rip->ip_dst = (struct in6_addr)ALLNODES_MULTICAST;
 rip->ip_nh = IPPROTO_ICMPV6;
-rip->ip_pl = htons(ICMP6_NDP_RA_MINLEN
-+ NDPOPT_LINKLAYER_LEN
-+ NDPOPT_PREFIXINFO_LEN
-#ifndef _WIN32
-+ NDPOPT_RDNSS_LEN
-#endif
-);
-t->m_len = sizeof(struct ip6) + ntohs(rip->ip_pl);
 
 /* Build ICMPv6 packet */
 t->m_data += sizeof(struct ip6);
@@ -171,6 +164,7 @@ void ndp_send_ra(Slirp *slirp)
 ricmp->icmp6_nra.reach_time = htonl(NDP_AdvReachableTime);
 ricmp->icmp6_nra.retrans_time = htonl(NDP_AdvRetransTime);
 t->m_data += ICMP6_NDP_RA_MINLEN;
+pl_size += ICMP6_NDP_RA_MINLEN;
 
 /* Source link-layer address (NDP option) */
 struct ndpopt *opt = mtod(t, struct ndpopt *);
@@ -178,6 +172,7 @@ void ndp_send_ra(Slirp *slirp)
 opt->ndpopt_len = NDPOPT_LINKLAYER_LEN / 8;
 in6_compute_ethaddr(rip->ip_src, opt->ndpopt_linklayer);
 t->m_data += NDPOPT_LINKLAYER_LEN;
+pl_size += NDPOPT_LINKLAYER_LEN;
 
 /* Prefix information (NDP option) */
 struct ndpopt *opt2 = mtod(t, struct ndpopt *);
@@ -192,27 +187,30 @@ void ndp_send_ra(Slirp *slirp)
 opt2->ndpopt_prefixinfo.reserved2 = 0;
 opt2->ndpopt_prefixinfo.prefix = slirp->vprefix_addr6;
 t->m_data += NDPOPT_PREFIXINFO_LEN;
+pl_size += NDPOPT_PREFIXINFO_LEN;
 
-#ifndef _WIN32
 /* Prefix information (NDP option) */
-/* disabled for windows for now, until get_dns6_addr is implemented */
-struct ndpopt *opt3 = mtod(t, struct ndpopt *);
-opt3->ndpopt_type = NDPOPT_RDNSS;
-opt3->ndpopt_len = NDPOPT_RDNSS_LEN / 8;
-opt3->ndpopt_rdnss.reserved = 0;
-opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
-opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
-t->m_data += NDPOPT_RDNSS_LEN;
-#endif
+{
+struct in6_addr addr;
+uint32_t scope_id;
+if (get_dns6_addr(, _id) >= 0) {
+/* Host system does have an IPv6 DNS server, announce our proxy.  
*/
+struct ndpopt *opt3 = mtod(t, struct ndpopt *);
+opt3->ndpopt_type = NDPOPT_RDNSS;
+opt3->ndpopt_len = NDPOPT_RDNSS_LEN / 8;
+opt3->ndpopt_rdnss.reserved = 0;
+opt3->ndpopt_rdnss.lifetime = htonl(2 * NDP_MaxRtrAdvInterval);
+opt3->ndpopt_rdnss.addr = slirp->vnameserver_addr6;
+t->m_data += NDPOPT_RDNSS_LEN;
+pl_size += NDPOPT_RDNSS_LEN;
+}
+}
+
+rip->ip_pl = htons(pl_size);
+t->m_data -= sizeof(struct ip6) + pl_size;
+t->m_len = sizeof(struct ip6) + pl_size;
 
 /* ICMPv6 Checksum */
-#ifndef _WIN32
-t->m_data -= NDPOPT_RDNSS_LEN;
-#endif
-t->m_data -= NDPOPT_PREFIXINFO_LEN;
-t->m_data -= NDPOPT_LINKLAYER_LEN;
-t->m_data -= ICMP6_NDP_RA_MINLEN;
-t->m_data -= sizeof(struct ip6);
 ricmp->icmp6_cksum = ip6_cksum(t);
 
 ip6_output(NULL, t, 0);

[Qemu-devel] [Bug 1295587] Re: Temporal freeze and slowdown while using emulated sb16

[milasudril]

On Windows 98 SE:

 * SB16: System hangs as described in this bug report
 * ES1370: Causes system freeze with back screen at boot time
 * AC97 (as suggested here: 
https://smcv.pseudorandom.co.uk/2015/discworldnoir/): BSODs during the 
installation
 * GUS: Device is not even detected

Conclusion: At the moment, there is no way to get audio output from
Windows 98 se VM.

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

Title:
  Temporal freeze and slowdown while using emulated sb16

Status in QEMU:
  New

Bug description:
  I have been carrying around this bug since previous versions and on
  different machines: When I use the -soundhw sb16 option, while playing
  any sound on the virtual machine it temporally freezes the emulated
  machine and loops the last bit of such sound effect for 1-2 minutes,
  then goes back to normal speed (until a new sound is played).

  Console shows:

   sb16: warning: command 0xf9,1 is not truly understood yet
   sb16: warning: command 0xf9,1 is not truly understood yet
  (...)
  main-loop: WARNING: I/O thread spun for 1000 iterations

  -One of my emulated machines is Windows 3.11: I managed to overrun
  this bug by switching from the local 1.5 version of the sound blaster
  driver to the 1.0, although since I updated qemu it freezes that
  machine, so I can't test if it still works.

  I am using the 1.7.90 version, but I suffered this bug for over one
  year (confirmed in version 2.0.0-rc0 too)

  this bug happens anytime I use the -soundhw sb16 switch, but the full
  command I am using in this specific case is:

  qemu-system-i386 -localtime -cpu pentium -m 32 -display sdl -vga
  cirrus -hda c.img -cdrom win95stuff.iso -net nic,model=ne2k_pci -net
  user -soundhw sb16

  This bug appears on all my machines: Pentium III running Slackware
  13.0 and freeBSD 10; Dual core T2400, both in Arch, Gentoo and
  Slackware 14.1 (all 32 bits), and a Dual core T4400 64 bits with
  Gentoo and Slackware. Same problem in all of those systems after
  compiling instead of using the distro packages

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

[Qemu-devel] [Bug 1295587] Re: Temporal freeze and slowdown while using emulated sb16

[milasudril]

Addendum: Since this report is from 2014, I should mention that I am
currently on 16.04.

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

Title:
  Temporal freeze and slowdown while using emulated sb16

Status in QEMU:
  New

Bug description:
  I have been carrying around this bug since previous versions and on
  different machines: When I use the -soundhw sb16 option, while playing
  any sound on the virtual machine it temporally freezes the emulated
  machine and loops the last bit of such sound effect for 1-2 minutes,
  then goes back to normal speed (until a new sound is played).

  Console shows:

   sb16: warning: command 0xf9,1 is not truly understood yet
   sb16: warning: command 0xf9,1 is not truly understood yet
  (...)
  main-loop: WARNING: I/O thread spun for 1000 iterations

  -One of my emulated machines is Windows 3.11: I managed to overrun
  this bug by switching from the local 1.5 version of the sound blaster
  driver to the 1.0, although since I updated qemu it freezes that
  machine, so I can't test if it still works.

  I am using the 1.7.90 version, but I suffered this bug for over one
  year (confirmed in version 2.0.0-rc0 too)

  this bug happens anytime I use the -soundhw sb16 switch, but the full
  command I am using in this specific case is:

  qemu-system-i386 -localtime -cpu pentium -m 32 -display sdl -vga
  cirrus -hda c.img -cdrom win95stuff.iso -net nic,model=ne2k_pci -net
  user -soundhw sb16

  This bug appears on all my machines: Pentium III running Slackware
  13.0 and freeBSD 10; Dual core T2400, both in Arch, Gentoo and
  Slackware 14.1 (all 32 bits), and a Dual core T4400 64 bits with
  Gentoo and Slackware. Same problem in all of those systems after
  compiling instead of using the distro packages

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

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

[Peter Xu]

On Fri, Mar 24, 2017 at 12:44:06PM +0100, Juan Quintela wrote:
> Peter Xu  wrote:
> > Hi, Juan,
> >
> > Got several nitpicks below... (along with some questions)
> >
> > On Thu, Mar 23, 2017 at 09:44:54PM +0100, Juan Quintela wrote:
> >
> > [...]
> >
> >>  static void xbzrle_cache_zero_page(ram_addr_t current_addr)
> >>  {
> >> @@ -459,8 +474,8 @@ static void xbzrle_cache_zero_page(ram_addr_t 
> >> current_addr)
> >>   *  -1 means that xbzrle would be longer than normal
> >>   *
> >>   * @f: QEMUFile where to send the data
> >> - * @current_data:
> >> - * @current_addr:
> >> + * @current_data: contents of the page
> >
> > Since current_data is a double pointer, so... maybe "pointer to the
> > address of page content"?
> 
> ok. changed.
> 
> > Btw, a question not related to this series... Why here in
> > save_xbzrle_page() we need to update *current_data to be the newly
> > created page cache? I see that we have:
> >
> > /* update *current_data when the page has been
> >inserted into cache */
> > *current_data = get_cached_data(XBZRLE.cache, current_addr);
> >
> > What would be the difference if we just use the old pointer in
> > RAMBlock.host?
> 
> Its contents could have been changed since we inserted it into the
> cache.  Then we could end having "memory corruption" during transfer.

Oh yes. Hmm I noticed that the content will be changed along the way
(IIUC even before we insert the page into the cache, since we are
doing everything in migration thread, while at the same time vcpu
thread might be doing anything), but I didn't notice that we need to
make sure the cached page be exactly the same as the one sent to the
destination side, or the "diff" may not match. Thanks for pointing
out. :)

> 
> 
> > [...]
> >
> >> @@ -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.
> 
> I will let this one to dave to answer O:-)
> I agree than previous name is not perfect, but not sure that the new one
> is mucth better either.
> 
> migration_drop_page_queue()?

This is indeed a nitpick of mine... So please feel free to ignore it.
:)

But if we will keep the function name, I would slightly prefer that at
least we mention in the comment that, this is only freeing things up,
not sending anything out.

> 
> 
> >
> > [...]
> >
> >> -/*
> >> - * Helper for postcopy_chunk_hostpages; it's called twice to cleanup
> >> - *   the two bitmaps, that are similar, but one is inverted.
> >> +/**
> >> + * postcopy_chuck_hostpages_pass: canocalize bitmap in hostpages
> >   ^ should be n? ^^ canonicalize?
> 
> Fixed.
> 
> >> - * We search for runs of target-pages that don't start or end on a
> >> - * host page boundary;
> >> - * unsent_pass=true: Cleans up partially unsent host pages by searching
> >> - * the unsentmap
> >> - * unsent_pass=false: Cleans up partially dirty host pages by searching
> >> - * the main migration bitmap
> >> + * Helper for postcopy_chunk_hostpages; it's called twice to
> >> + * canonicalize the two bitmaps, that are similar, but one is
> >> + * inverted.
> >>   *
> >> + * Postcopy requires that all target pages in a hostpage are dirty or
> >> + * clean, not a mix.  This function canonicalizes the bitmaps.
> >> + *
> >> + * @ms: current migration state
> >> + * @unsent_pass: if true we need to canonicalize partially unsent host 
> >> pages
> >> + *   otherwise we need to canonicalize partially dirty host 
> >> pages
> >> + * @block: block that contains the page we want to canonicalize
> >> + * @pds: state for postcopy
> >>   */
> >>  static void postcopy_chunk_hostpages_pass(MigrationState *ms, bool 
> >> unsent_pass,
> >>RAMBlock *block,
> >
> > [...]
> >
> >> +/**
> >> + * ram_save_setup: iterative stage for migration
> >   ^^ should be ram_save_iterate()?
> 
> fixed.  Too much copy and paste.
> 
> >
> >> + *
> >> + * Returns zero to indicate success and negative for error
> >> + *
> >> + * @f: QEMUFile where to send the data
> >> + * @opaque: RAMState pointer
> >> + */
> >>  static int 

Re: [Qemu-devel] Problems with native Mingw-w64 build

[Peter Maydell]

On 26 March 2017 at 11:30, Mark Cave-Ayland
 wrote:
> In order to do some testing on a Windows box, I've spent a bit of time
> this weekend setting up a mingw-w64 build environment on Windows 10
> using http://wiki.qemu-project.org/Hosts/W32 as a guideline.

I think most people prefer to use the cross-compile.
Stefan might do native compiles.

> 2) glib-compat mkdtemp() error

> This one seems to be a genuine bug since the wiki above mentions that
> 64-bit builds cannot use versions of glib > 2.22 due to a change in the
> way global symbols are managed. Since g_dir_make_tmp() only appears in
> glib 2.30 and later, we end up using the fallback code which fails
> because mkdtemp() isn't available on Windows.

Since 2.7 the minimum version of glib has been 2.30 for Windows
(documented in http://wiki.qemu-project.org/ChangeLog/2.7),
because of this g_dir_make_tmp() dependency. Unfortunately
it looks like we forgot to update configure (we didn't for 2.7
because we noticed the issue quite late in the release cycle).

thanks
-- PMM

[Qemu-devel] Problems with native Mingw-w64 build

[Mark Cave-Ayland]

Hi all,

In order to do some testing on a Windows box, I've spent a bit of time
this weekend setting up a mingw-w64 build environment on Windows 10
using http://wiki.qemu-project.org/Hosts/W32 as a guideline.

After a few false starts, I was able to get the basic environment
working but so far I've been unable to build git master due to a couple
of failures:


1) texi2pod.pl error

  GEN qemu.1
Bareword found where operator expected at
/c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349, near "@(deftp"
  (Might be a runaway multi-line // string starting on line 337)
(Missing operator before deftp?)
Unquoted string "deftp" may clash with future reserved word at
/c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349.
Backslash found where operator expected at
/c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349, near ")\"
(Missing operator before \?)
Unrecognized escape \s passed through at
/c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349.
syntax error at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line
349, near "@(deftp"
Missing right curly or square bracket at
/c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 534, at end of line
Execution of /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl aborted due
to compilation errors.
make: *** [qemu.1] Error 255

I'm not sure what the workaround for this is, however it is possible to
get further with the build by passing --disable-docs to configure.


2) glib-compat mkdtemp() error

  CC  qga/commands.o
In file included from
c:/Users/Mark/qemu/src/qemu/include/qemu/osdep.h:107:0,
 from qga/commands.c:13:
c:/Users/Mark/qemu/src/qemu/include/glib-compat.h: In function
'qemu_g_dir_make_tmp':
c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:9: error: implicit
declaration of function 'mkdtemp' [-Werror=implicit-function-declaration]
 if (mkdtemp(path) != NULL) {
 ^~~
c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:5: error: nested
extern declaration of 'mkdtemp' [-Werror=nested-externs]
 if (mkdtemp(path) != NULL) {
 ^~
c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:23: error:
comparison between pointer and integer [-Werror]
 if (mkdtemp(path) != NULL) {
   ^~
cc1.exe: all warnings being treated as errors
make: *** [qga/commands.o] Error 1

This one seems to be a genuine bug since the wiki above mentions that
64-bit builds cannot use versions of glib > 2.22 due to a change in the
way global symbols are managed. Since g_dir_make_tmp() only appears in
glib 2.30 and later, we end up using the fallback code which fails
because mkdtemp() isn't available on Windows.


My guess would be that most people are using the Docker image to
cross-compile Windows binaries rather than attempting a native build
which is why no-one has really noticed (the mkdtemp() change went into
the tree around August last year). Do people consider native Windows
builds to still be supported?


ATB,

Mark.

[Qemu-devel] [Bug 1660599] Re: v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-protector-strong"

[Danil]

Could you provide the command you've used?
I tried `CC=gcc-4.8 ./configure --enable-stack-protector && make` in Ubuntu 
14.04 and qemu v2.8.0. It didn't set `-fstack-protector-strong` flag, only 
`-fstack-protector-all`.

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

Title:
  v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-
  protector-strong"

Status in QEMU:
  New

Bug description:
  For example, Ubuntu Trusty (LTS 14.04) uses g++ v4.8.5.
  Compilation fails with a syntax error saying that the 
""-fstack-protector-strong" option in g++ is unrecognized.
  Instead, under Ubuntu Xenial (LTS 16.04), the g++ compiler is v5.4.0 and the 
compilation goes on smoothly.

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

[Qemu-devel] [PATCH qemu-ga v3] qga: Make qemu-ga compile statically for Windows

[Sameeh Jubran]

Attempting to compile qemu-ga statically as follows for Windows causes
the following error:

Compilation:
./configure --disable-docs --target-list=x86_64-softmmu \
--cross-prefix=x86_64-w64-mingw32- --static \
--enable-guest-agent-msi --with-vss-sdk=/path/to/VSSSDK72

make -j8 qemu-ga

Error:
path/to/qemu/stubs/error-printf.c:7: undefined reference to 
`__imp_g_test_config_vars'
collect2: error: ld returned 1 exit status
Makefile:444: recipe for target 'qemu-ga.exe' failed
make: *** [qemu-ga.exe] Error 1

This is caused by a bug in the pkg-config file for glib as it doesn't define
GLIB_STATIC_COMPILATION for pkg-config --static.

Signed-off-by: Sameeh Jubran 
Reviewed-by: Stefan Hajnoczi 
---
 configure | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configure b/configure
index b9a30cf..8210494 100755
--- a/configure
+++ b/configure
@@ -3041,6 +3041,13 @@ if test "$modules" = yes; then
 glib_modules="$glib_modules gmodule-2.0"
 fi
 
+# This workaround is required due to a bug in pkg-config file for glib as it
+# doesn't define GLIB_STATIC_COMPILATION for pkg-config --static
+
+if test "$static" = yes -a "$mingw32" = yes; then
+QEMU_CFLAGS="-DGLIB_STATIC_COMPILATION $QEMU_CFLAGS"
+fi
+
 for i in $glib_modules; do
 if $pkg_config --atleast-version=$glib_req_ver $i; then
 glib_cflags=$($pkg_config --cflags $i)
-- 
2.9.3

[Qemu-devel] [PATCH v2] Fix input-linux reading from device

[Javier Celaya]

The evdev devices in input-linux.c are read in blocks of one whole
event. If there are not enough bytes available, they are discarded,
instead of being kept for the next read operation. This results in
lost events, of even non-working devices.

This patch keeps track of the number of bytes to be read to fill up
a whole event, and then handle it.

Signed-off-by: Javier Celaya 
---
 ui/input-linux.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/ui/input-linux.c b/ui/input-linux.c
index ac31f47719..02b0d4b2fe 100644
--- a/ui/input-linux.c
+++ b/ui/input-linux.c
@@ -169,6 +169,8 @@ struct InputLinux {
 boolhas_abs_x;
 int num_keys;
 int num_btns;
+struct input_event event;
+int to_be_read;
 
 QTAILQ_ENTRY(InputLinux) next;
 };
@@ -327,25 +329,30 @@ static void input_linux_handle_mouse(InputLinux *il, 
struct input_event *event)
 static void input_linux_event(void *opaque)
 {
 InputLinux *il = opaque;
-struct input_event event;
 int rc;
+int offset;
+uint8_t *p = (uint8_t *)>event;
 
 for (;;) {
-rc = read(il->fd, , sizeof(event));
-if (rc != sizeof(event)) {
+offset = sizeof(il->event) - il->to_be_read;
+rc = read(il->fd, [offset], il->to_be_read);
+if (rc != il->to_be_read) {
 if (rc < 0 && errno != EAGAIN) {
 fprintf(stderr, "%s: read: %s\n", __func__, strerror(errno));
 qemu_set_fd_handler(il->fd, NULL, NULL, NULL);
 close(il->fd);
+} else if (rc > 0){
+il->to_be_read -= rc;
 }
 break;
 }
+il->to_be_read = sizeof(il->event);
 
 if (il->num_keys) {
-input_linux_handle_keyboard(il, );
+input_linux_handle_keyboard(il, >event);
 }
 if (il->has_rel_x && il->num_btns) {
-input_linux_handle_mouse(il, );
+input_linux_handle_mouse(il, >event);
 }
 }
 }
@@ -417,6 +424,7 @@ static void input_linux_complete(UserCreatable *uc, Error 
**errp)
 }
 }
 
+il->to_be_read = sizeof(il->event);
 qemu_set_fd_handler(il->fd, input_linux_event, NULL, il);
 if (il->keycount) {
 /* delay grab until all keys are released */
-- 
2.11.0

Re: [Qemu-devel] [PATCH qemu-ga v2] qga: Make qemu-ga compile statically for Windows

[Sameeh Jubran]

On Thu, Mar 23, 2017 at 9:21 PM, Stefan Hajnoczi  wrote:

> On Thu, Mar 23, 2017 at 11:22:11AM +0200, Sameeh Jubran wrote:
> > Attempting to compile qemu-ga statically as follows for Windows causes
> > the following error:
> >
> > Compilation:
> > ./configure --disable-docs --target-list=x86_64-softmmu \
> > --cross-prefix=x86_64-w64-mingw32- --static \
> > --enable-guest-agent-msi --with-vss-sdk=/path/to/VSSSDK72
> >
> > make -j8 qemu-ga
> >
> > Error:
> > path/to/qemu/stubs/error-printf.c:7: undefined reference to
> `__imp_g_test_config_vars'
> > collect2: error: ld returned 1 exit status
> > Makefile:444: recipe for target 'qemu-ga.exe' failed
> > make: *** [qemu-ga.exe] Error 1
> >
> > This is caused by a bug in the pkg-config file for glib as it doesn't
> define
> > GLIB_STATIC_COMPILATION for pkg-config --static.
>
> >
> > Signed-off-by: Stefan Hajnoczi 
>
> Please remove this.  I didn't post my Signed-off-by.  Only add
> Signed-off-by for someone else if they ask you to do so.
>
> For details on Signed-off-by please read:
> "11) Sign your work - the Developer's Certificate of Origin"
> https://www.kernel.org/doc/Documentation/process/submitting-patches.rst

 I added your signed off to indicate that you were involved in the
development of the patch as you are the one that suggested
this workaround in the first place. No problem I will drop it.

>
>
> > Signed-off-by: Sameeh Jubran 
> > ---
> >  configure | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/configure b/configure
> > index b9a30cf..8210494 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3041,6 +3041,13 @@ if test "$modules" = yes; then
> >  glib_modules="$glib_modules gmodule-2.0"
> >  fi
> >
> > +# This workaround is required due to a bug in pkg-config file for glib
> as it
> > +# doesn't define GLIB_STATIC_COMPILATION for pkg-config --static
>
> Please add:
>
> # See https://bugzilla.gnome.org/show_bug.cgi?id=780399 for the glib bug
> # report.


> Reviewed-by: Stefan Hajnoczi 
>
I'll add them in v3, thanks for the review.


-- 
Respectfully,
*Sameeh Jubran*
*Linkedin *
*Software Engineer @ Daynix .*

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Knut Omang]

On Sat, 2017-03-25 at 21:15 +, Peter Maydell wrote:
> On 25 March 2017 at 20:49, Knut Omang  wrote:
> > 
> > Can we please keep the Sparc support in for a while still?
> 
> Yes, John Paul Adrian Glaubitz and the Debian Project have
> kindly provided me with access to a Sparc box. I'm planning
> to send a patch that puts sparc into the 'supported'
> category before 2.9 release.

good to hear!

> I would note that so far I've found a couple of TCG
> bugs of the "this just doesn't work at all" level, so
> it doesn't look like anybody using sparc has been
> doing any testing against git master...

No, I tried a while ago myself without much success so there's awareness
about this sad state. Hopefully we can get some momentum on it soon.

> > 
> > When it comes to build platforms, a legitimate need to be able to keep
> > anything
> > running, I don't have any authority to promise away hardware or other forms
> > of
> > Sparc access, but I have been told that that part can be worked out in some
> > way
> > if we get enough support for this internally.
> 
> I'd recommend trying to get a machine into the gcc compile
> farm (assuming they'd be willing to take it) -- that way
> it's accessible to developers for a range of open
> source projects.

I'll bring that suggestion forward,

Thanks,
Knut

> 
> thanks
> -- PMM