Peter Maydell wrote:
> On 30 September 2016 at 16:41, Felix Janda wrote:
> > This fixes a compilation error with the musl c library.
> > ---
> > I don't really understand the purpose of the hack, which was
> > introduced in
> >
> > http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d
Peter Maydell wrote:
> On 30 September 2016 at 16:39, Felix Janda wrote:
> > The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
> > F_WRLCK and F_RDLCK.
>
> This seems unlikely, since on for instance Alpha F_EXLCK is
> 16, F_SHLCK is 32, F_RDLCK is 1 and F_WRLCK is 2, so they'
Hi Stefan, others,
Thank you for all the review comments.
On Wed, Sep 28, 2016 at 4:13 AM, Stefan Hajnoczi wrote:
> On Tue, Sep 27, 2016 at 09:09:49PM -0700, Ashish Mittal wrote:
>> +vxhs_bdrv_init(const char c) "Registering VxHS AIO driver%c"
>
> Why do several trace events have a %c format spe
On 30 September 2016 at 16:39, Felix Janda wrote:
> The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
> F_WRLCK and F_RDLCK.
This seems unlikely, since on for instance Alpha F_EXLCK is
16, F_SHLCK is 32, F_RDLCK is 1 and F_WRLCK is 2, so they're
all distinct:
http://lxr.free-
On 30 September 2016 at 16:39, Felix Janda wrote:
> This commit essentially reverts commit
> 3af72a4d98dca033492102603734cbc63cd2694a, which has replaced
> five-argument calls to mremap() by direct mremap syscalls for
> compatibility with glibc older than version 2.4.
>
> The direct syscall was bu
On 30 September 2016 at 16:41, Felix Janda wrote:
> This fixes a compilation error with the musl c library.
> ---
> I don't really understand the purpose of the hack, which was
> introduced in
>
> http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
>
> but musl does
Thanks :-)
Edgar
---
Sent from my phone
Original Message
Subject: Re: [Qemu-devel] [PATCH v1 1/1] target-arm: A64: Fix decoding of
iss_sf in disas_ld_lit
From: Peter Maydell
Date: 1 Oct 2016, 01:20
To: Edgar Iglesias
On 30 September 2016 at 14:42, Edgar Iglesias wrote
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20160930234101.GD5887@nyan
Subject: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when
__SIGRTMIN is defined
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=b
This removes the last usage of in the code base.
Signed-off-by: Felix Janda
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 3d1f694..4bfb671 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.
This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was
introduced in
http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
but musl does not have a separate thread library (it is included in
libc.so),
The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
F_WRLCK and F_RDLCK. Include to fix compilation with
the musl c library, which does not expose these constants.
Signed-off-by: Felix Janda
---
linux-user/syscall.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-us
This commit essentially reverts commit
3af72a4d98dca033492102603734cbc63cd2694a, which has replaced
five-argument calls to mremap() by direct mremap syscalls for
compatibility with glibc older than version 2.4.
The direct syscall was buggy for 64bit targets on 32bit hosts
because of the default in
On 30 September 2016 at 15:46, Tom Hanson wrote:
> On 09/29/2016 07:27 PM, Peter Maydell wrote:
> ...
>>> This work was not done at this time since the changes could not be tested
>>> with current CPU models. Comments have been added to flag the locations
>>> where this will need to be fixed once
On 30 September 2016 at 14:42, Edgar Iglesias wrote:
> Peter, feel free to change the syntax to whatever you feel is best.
Applied to target-arm.next, thanks. I picked "iss_sf = opc != 0;"
-- PMM
On 30 September 2016 at 03:47, Christian Borntraeger
wrote:
> Peter,
>
> The following changes since commit 25930ed60aad49f1fdd7de05272317c86ce1275b:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
> staging (2016-09-27 23:10:12 +0100)
>
> are available in the git
Peter, feel free to change the syntax to whatever you feel is best.
Cheers,
Edgar
---
Sent from my phone
Original Message
Subject: Re: [Qemu-devel] [PATCH v1 1/1] target-arm: A64: Fix decoding of
iss_sf in disas_ld_lit
From: Peter Maydell
Date: 30 Sep 2016, 19:34
To: "E
On Fri, Sep 30, 2016 at 11:45:19PM +0100, Alex Bennée wrote:
>
> Jonathan Neuschäfer writes:
>
> > On Fri, Sep 30, 2016 at 10:30:56PM +0100, Alex Bennée wrote:
> >> From: Paolo Bonzini
> >>
> >> There is a data race if the sequence is written concurrently to the
> >> read. In C11 this has unde
On 09/29/2016 07:27 PM, Peter Maydell wrote:
...
>> This work was not done at this time since the changes could not be tested
>> with current CPU models. Comments have been added to flag the locations
>> where this will need to be fixed once a model is available.
>
> This is *not* why we haven't
On 30 September 2016 at 01:16, Yongbok Kim wrote:
>>
>> Your GPG key hasn't been signed by anybody -- are you in a position
>> to get it signed by somebody else who can in-person verify your identity
>> (eg Leon)?
>
> Hi Peter,
>
> We have just arranged the key signing and Leon has signed my key.
Jonathan Neuschäfer writes:
> On Fri, Sep 30, 2016 at 10:30:56PM +0100, Alex Bennée wrote:
>> From: Paolo Bonzini
>>
>> There is a data race if the sequence is written concurrently to the
>> read. In C11 this has undefined behavior. Use atomic_set; the
>> read side is already using atomic_rea
On Fri, Sep 30, 2016 at 10:30:56PM +0100, Alex Bennée wrote:
> From: Paolo Bonzini
>
> There is a data race if the sequence is written concurrently to the
> read. In C11 this has undefined behavior. Use atomic_set; the
> read side is already using atomic_read.
>
> Reported-by: Alex Bennée
> S
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1475272849-19990-1-git-send-email-js...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/11] blockjobs: Fix transactional race
condition
=== TEST SCRIPT BEGIN ===
#!/bin/bash
Refactor backup_start as backup_job_create, which only creates the job,
but does not automatically start it. The old interface, 'backup_start',
is not kept in favor of limiting the number of nearly-identical iterfaces
that would have to be edited to keep up with QAPI changes in the future.
Callers
Add an explicit start field to specify the entrypoint. We already have
ownership of the coroutine itself AND managing the lifetime of the
coroutine, let's take control of creation of the coroutine, too.
This will allow us to delay creation of the actual coroutine until we
know we'll actually start
To make it a little more obvious which functions are intended to be
public interface and which are intended to be for use only by jobs
themselves, split the interface into "public" and "private" files.
Convert blockjobs (e.g. block/backup) to using the private interface.
Leave blockdev and others
Cleaning up after we have deferred to the main thread but before the
transaction has converged can be dangerous and result in deadlocks
if the job cleanup invokes any BH polling loops.
A job may attempt to begin cleaning up, but may induce another job to
enter its cleanup routine. The second job,
---
cpu-exec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 0e6b3d3..8b8be25 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -291,7 +291,8 @@ static inline TranslationBlock *tb_find(CPUState *cpu,
is executed. */
cpu_get_tb_cpu_state(
Wrong function names in documentation.
Signed-off-by: John Snow
---
include/block/blockjob_int.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/block/blockjob_int.h b/include/block/blockjob_int.h
index 0a2d41e..c6da7e4 100644
--- a/include/block/blockjob_int.h
There are a few places where we're fishing it out for ourselves.
Let's not do that and instead use the helper.
Signed-off-by: John Snow
---
block/io.c | 4 ++--
blockdev.c | 4 ++--
blockjob.c | 2 +-
include/block/blockjob.h | 9 +
qemu-img.c
There are a few problems with transactional job completion right now.
First, if jobs complete so quickly they complete before remaining jobs
get a chance to join the transaction, the completion mode can leave well
known state and the QLIST can get corrupted and the transactional jobs
can complete
On 30 September 2016 at 14:48, Tom Hanson wrote:
> On 09/29/2016 07:37 PM, Peter Maydell wrote:
>>
>> On 16 September 2016 at 10:34, Thomas Hanson
>> wrote:
>>>
>>> If tagged addresses are enabled, then addresses being loaded into
>>> the
>>> PC must be cleaned up by overwriting the tag
BlockJobs will begin hiding their state in preparation for some
refactorings anyway, so let's internalize the user_pause mechanism
instead of leaving it to callers to correctly manage.
Signed-off-by: John Snow
---
block/io.c | 2 +-
blockdev.c | 10 --
blockj
Add a regression test for the case found by Vladimir.
Reported-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: John Snow
---
tests/qemu-iotests/124 | 91 ++
tests/qemu-iotests/124.out | 4 +-
2 files changed, 93 insertions(+), 2 deletions(-)
dif
Instead of automatically starting jobs at creation time via backup_start
et al, we'd like to return a job object pointer that can be started
manually at later point in time.
For now, add the block_job_start mechanism and start the jobs
automatically as we have been doing, with conversions job-by-j
From: Vladimir Sementsov-Ogievskiy
Though it is not intended to be reached through normal circumstances,
if we do not gracefully deconstruct the transaction QLIST, we may wind
up with stale pointers in the list.
The rest of this series attempts to address the underlying issues,
but this should f
There's no reason to leave this to blockdev; we can do it in blockjobs
directly and get rid of an extra callback for most users.
Signed-off-by: John Snow
---
blockdev.c | 37 ++---
blockjob.c | 16 ++--
2 files changed, 20 insertions(+), 33 deletions(-
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20160930213106.20186-1-alex.ben...@linaro.org
Subject: [Qemu-devel] [PATCH v3 00/15] A number of fixes for ThreadSanitizer
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=
On 09/29/2016 07:37 PM, Peter Maydell wrote:
On 16 September 2016 at 10:34, Thomas Hanson wrote:
If tagged addresses are enabled, then addresses being loaded into the
PC must be cleaned up by overwriting the tag bits with either all 0's
or all 1's as specified in the ARM ARM spec
The TranslationBuffer is one of those heavily accessed across threads.
To meet defined C11 behaviour across threads we update the accesses to
use the relaxed atomic helpers. Care is still taken with locking and
barriers for when flags are updated and when newly generated buffers are
made visible to
To meet C11 semantics for shared data access we need to use relaxed
atomic accesses. While the completion of data writes w.r.t reads is
ensured by QHT's explicit barriers when a newly generated TB is inserted
ThreadSanitizer will still complain. By using the relaxed accesses the
same code gets gene
As it seems easy to break the ThreadSanitizer build we should defend it to
ensure that fixes get applied when it breaks. We use the Ubuntu GCC PPA
to get the latest GCC goodness.
As we need to use the -fuse-ld=gold work around we have to disable the
linux-user targets as these trip up the linker.
From: Paolo Bonzini
There is a data race if the sequence is written concurrently to the
read. In C11 this has undefined behavior. Use atomic_set; the
read side is already using atomic_read.
Reported-by: Alex Bennée
Signed-off-by: Paolo Bonzini
Signed-off-by: Alex Bennée
---
include/qemu/se
The guest client's use of the glib's g_atomic primitives causes newer
GCC's to barf when built on Travis. As QEMU has its own primitives with
well understood semantics we might as well use them.
The use of atomics was a little inconsistent so I've also ensure the
values are correctly set with atom
Paolo Bonzini writes:
> On 22/09/2016 12:13, Alex Bennée wrote:
>> Hi,
>>
>
> Queued patches 2-8 (1 is already in and 9 is outside my knowledge), thanks.
Actually could you take them from the v3 I've just posted? I've cleaned
up a bunch of the commit messages and dropped the blacklist patch.
ThreadSanitizer detects a possible race between reading/writing the
hashes. The ordering semantics are already documented for QHT however
for true C11 compliance we should use relaxed atomic primitives for
accesses that are done across threads. On x86 this slightly changes to
the code to not do a l
Add some notes on the use of the relaxed atomic access helpers and their
importance for defined behaviour in C11's multi-threaded memory model.
Signed-off-by: Alex Bennée
---
include/qemu/atomic.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/qemu/atomic.h b/include/qemu/atom
The ThreadSanitizer rightly complains that something initialised with a
normal access is later updated and read atomically.
Signed-off-by: Alex Bennée
---
qom/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 484c493..ef905da 100644
--- a/
Commit b480d9b74 converted tb_page_addr_t to abi_ulong which while the
right size imposes additional alignment restrictions on the type. This
gets in the way of using atomic accesses on certain guest platforms
which allow finer alignments. As tb_page_addr_t isn't actually visible
to the guest we ca
Hi,
This is v3 of the ThreadSanitizer fixes. Changes from the last
version:
- added some more review tags
- made clear C11 undefined behaviour is the main issue
- added two minor fixes to atomic.h
- change type of tb_page_addr_t back to target_ulong
- dropped ui/vnc-enc-tight patch (alr
ThreadSanitizer picks up potential races although we already use
barriers to ensure things are in the correct order when processing exit
requests. For true C11 defined behaviour across threads we need to use
relaxed atomic_set/atomic_read semantics to reassure tsan.
Signed-off-by: Alex Bennée
---
Updates to the internal page table are protected by the mmap_lock.
However for defined C11 semantics things that are access across threads
need to accessed using at least relaxed atomics.
Signed-off-by: Alex Bennée
---
translate-all.c | 67 +---
Only very modern GCC's actually set this define when building with the
ThreadSanitizer so this little typo slipped though.
Signed-off-by: Alex Bennée
---
include/qemu/atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index
There is a potential race if several threads exit at once. To serialise
the exits extend the lock above the initial checking of the CPU list.
Signed-off-by: Alex Bennée
---
linux-user/syscall.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux
This is to appease sanitizer builds which complain that:
"error: control reaches end of non-void function"
Signed-off-by: Alex Bennée
Reviewed-by: Marc-André Lureau
---
tcg/optimize.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tcg/optimize.c b/tcg/optimize.c
index
The idiom CPU_GET_CLASS(cpu) is fairly extensively used in various
threads and trips of ThreadSanitizer due to the fact it updates
obj->class->object_cast_cache behind the scenes. As this is just a
fast-path cache there is no need to lock updates.
However to ensure defined C11 behaviour across thr
On 30/09/2016 20:33, Eduardo Habkost wrote:
> On Fri, Sep 30, 2016 at 09:55:33AM +0200, Paolo Bonzini wrote:
>>
>>
>> On 29/09/2016 23:14, Eduardo Habkost wrote:
>>> + * "-foo" overrides "+foo"
>>> + * "[+-]foo" overrides "foo=..."
>>
>> Is this something that people are actually using?
On Fri, Sep 30, 2016 at 02:56:42PM -0500, Eric Blake wrote:
> On 09/30/2016 01:49 PM, Eduardo Habkost wrote:
> > Registering the actual names containing underscores as aliases
> > will allow management software to be aware that the old
> > compatibility names are suported, and will make feat2prop()
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> If given an option string such as
>
> size=1024,nodes=10,nodes=4-5,nodes=1-2,policy=bind
>
> the qemu_opts_to_qdict() method will currently overwrite
> the values for repeated option keys, so only the last
> value is in the returned dict:
>
>
On 09/30/2016 01:49 PM, Eduardo Habkost wrote:
> Registering the actual names containing underscores as aliases
> will allow management software to be aware that the old
> compatibility names are suported, and will make feat2prop() calls
s/suported/supported/
> unnecessary when using feature name
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> The traditional CLI arg syntax allows two ways to specify
> integer lists, either one value per key, or a range of
> values per key. eg the following are identical:
>
> -arg foo=5,foo=6,foo=7
> -arg foo=5-7
>
> This extends the QObjectInputV
This tests the different supported methods to create floppy drives and
how they interact.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/172 | 242 +
tests/qemu-iotests/172.out | 1205
tests/qemu-iotests/group |1 +
3 files change
This makes the FloppyDrive qdev object actually useful: Now that it has
all properties that don't belong to the controller, you can actually
use '-device floppy' and get a working result.
Command line semantics is consistent with CD-ROM drives: By default you
get a single empty floppy drive. You c
This adds a qbus to the floppy controller that should contain the floppy
drives eventually. At the moment it just exists and is empty.
Signed-off-by: Kevin Wolf
---
hw/block/fdc.c | 40 +++-
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/hw/blo
We have been complaining for a long time about how the floppy controller and
floppy drives are combined in a single qdev device and how this makes the
device awkward to work with because it behaves different from all other block
devices.
The latest reason to complain was when I noticed that using
Floppy controllers automatically create two floppy drive devices in qdev
now. (They always created two drives, but managed them only internally.)
Signed-off-by: Kevin Wolf
---
hw/block/fdc.c | 151 +
1 file changed, 120 insertions(+), 31 de
On 09/28/2016 03:55 PM, Max Reitz wrote:
> Instead of not emitting the port in nbd_refresh_filename(), just set it
> to the default if the user did not specify it. This makes the logic a
> bit simpler.
>
> Signed-off-by: Max Reitz
> ---
> block/nbd.c | 19 ++-
> 1 file changed, 6
On Fri, Sep 30, 2016 at 02:05:10PM +0200, Maxime Coquelin wrote:
>
>
> On 09/29/2016 11:23 PM, Maxime Coquelin wrote:
> >
> >
> > On 09/29/2016 10:21 PM, Michael S. Tsirkin wrote:
> > > On Thu, Sep 29, 2016 at 10:05:22PM +0200, Maxime Coquelin wrote:
> > > >
> > > >
> > > > On 09/29/2016 07:5
On 09/30/2016 10:45 AM,
no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> Hi,
>
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce
> it
> locally.
>
> CCqapi/string-output-
On 09/30/2016 08:13 AM, Lluís Vilanova wrote:
(2) an internal state change
to DisasContext, reflected in INDEX_op_insn_start, with no changes to any TCG
registers. So you'll not actually be tracking eflags at all.
I don't follow what you mean. AFAIK INDEX_op_insn_start does not change the
gues
Add a new optional field to query-cpu-definitions schema:
"unavailable-features". It will contain a list of QOM properties
that prevent the CPU model from running in the current host.
Cc: David Hildenbrand
Cc: Michael Mueller
Cc: Christian Borntraeger
Cc: Cornelia Huck
Cc: Jiri Denemark
Cc: l
Fill the "unavailable-features" field on the x86 implementation
of query-cpu-definitions.
Cc: Jiri Denemark
Cc: libvir-l...@redhat.com
Signed-off-by: Eduardo Habkost
---
Changes v3 -> v4:
* Handle missing XSAVE components cleanly, but looking up
the original feature that required it
* Use x86_
When probing for CPU model information, we need to reuse the code
that initializes CPUID fields, but not the remaining side-effects
of x86_cpu_realizefn(). Move that code to a separate function
that can be reused later.
Signed-off-by: Eduardo Habkost
---
Changes v4 -> v5:
* Fix typo on x86_cpu_lo
On 30.09.2016 20:11, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Please, can somebody explain me, why we fail guest request in case of
io error in write notifier? I think guest consistency is more
important than success of unfinished backup. Or, what am I missing?
I'm saying about this code:
Instead of treating the FP and SSE bits as special cases, add
them to the x86_ext_save_areas array. This will simplify the code
that calculates the supported xsave components and the size of
the xsave area.
Signed-off-by: Eduardo Habkost
---
Changes series v3 -> v4:
* New patch added to series
--
Instead of keeping the aliases inside the feature name arrays and
require parsing the strings, just register alias properties
manually. This simplifies the code for property registration and
lookup.
Signed-off-by: Eduardo Habkost
---
Changes v4 -> v5:
* Refresh after the previous patches were cha
Instead of translating the feature name entries when adding
property names, store the actual property names in the feature
name array.
For reference, here is the full list of functions that use
FeatureWordInfo::feat_names:
* x86_cpu_get_migratable_flags(): not affected, as it just
check for non
VME is already disabled automatically when using TCG. So, instead
of pretending it is there when reporting CPU model data on
query-cpu-* QMP commands (making every CPU model to be reported
as not runnable), we can disable it by default on all CPU models
when using TCG.
Do that by adding a tcg_defa
This series extends query-cpu-definitions to include an extra
field: "unavailable-features". The new field can be used to find
out reasons that prevent the CPU model from running in the
current host.
This will return information based on the current machine and
accelerator only. In the future we m
x86_cpu_filter_features() will be reused by code that shouldn't
print any warning. Move the warning code to a new
x86_cpu_report_filtered_features() function, and call it from
x86_cpu_realizefn().
Signed-off-by: Eduardo Habkost
---
Changes v3 -> v4:
* Made x86_cpu_filter_features() void, make
x
Instead of using custom feature name lookup code for
plus_features/minus_features, save the property names used in
"[+-]feature" and use object_property_set_bool() to set them.
We don't need a feat2prop() call because we now have alias
properties for the old names containing underscores.
Signed-o
Registering the actual names containing underscores as aliases
will allow management software to be aware that the old
compatibility names are suported, and will make feat2prop() calls
unnecessary when using feature names.
Also, this will help us avoid making the code support underscores
on featur
Add a new test case to ensure the existing behavior of the
feature parsing code will be kept.
Signed-off-by: Eduardo Habkost
---
Changes series v4 -> v5:
* Fix typo on commit message
Reported-by: Jonathan Neuschäfer
* Add comment noting that the "[+-]feature" compatibility mode
will be remov
Instead of using the builtin_x86_defs array, use the QOM subclass
list to list CPU models on "-cpu ?" and "query-cpu-definitions".
Signed-off-by: Andreas Färber
[ehabkost: copied code from a patch by Andreas:
"target-i386: QOM'ify CPU", from March 2012]
Signed-off-by: Eduardo Habkost
---
targe
On 09/30/2016 12:51 PM, Akanksha Srivastava wrote:
> The *_exitfn functions cannot fail and should not be
> returning int.
> Suggested as a Bite-sized task
> Signed-off-by: Akanksha Srivastava
> ---
> hw/usb/ccid-card-emulated.c | 4 ++--
> hw/usb/ccid-card-passthru.c | 4 ++--
> 2 files changed,
On 09/28/2016 03:55 PM, Max Reitz wrote:
> Currently, a port that is passed along with a UNIX socket path is
> silently ignored. That is not exactly ideal, it should be an error
> instead.
>
> Signed-off-by: Max Reitz
> ---
> block/nbd.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletion
On 09/30/2016 10:16 AM, Daniel P. Berrange wrote:
> The GSource object has ability to have a name, which is useful
> when debugging performance problems with the mainloop event
> callbacks that take too long. By associating a name with an
> QIOChannel object, we can then set the name on any GSource
On 09/30/2016 02:30 PM, Eric Blake wrote:
On 09/30/2016 11:35 AM, John Snow wrote:
Hi Eric (as a proxy for Libvirt);
I want to make a change to transactions such that they do not actually
start the jobs until the entire transaction is error-checked for validity.
This would be a change from t
On 09/30/2016 12:34 PM, Peter Maydell wrote:
+bool iss_sf = opc == 0 ? false : true;
Feels like a double negative.
>>>
>>> You could simplify that to:
>>>
>>> bool iss_sf = !(opc == 0);
>>
>> I don't really see how that is simpler/clearer.
>>
>> I considered:
>> bool iss_sf = o
On Fri, Sep 30, 2016 at 09:55:33AM +0200, Paolo Bonzini wrote:
>
>
> On 29/09/2016 23:14, Eduardo Habkost wrote:
> > + * "-foo" overrides "+foo"
> > + * "[+-]foo" overrides "foo=..."
>
> Is this something that people are actually using? Can we detect it and
> deprecate it in 2.8, and dr
On 09/30/2016 11:35 AM, John Snow wrote:
> Hi Eric (as a proxy for Libvirt);
>
> I want to make a change to transactions such that they do not actually
> start the jobs until the entire transaction is error-checked for validity.
>
> This would be a change from the current setup where:
>
> - Some
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> Some of the historical command line opts that had their
> keys in in a completely flat namespace are now represented
> by QAPI schemas that use a nested structs. When converting
singular/plural mismatch; either s/a // or s/structs/struct/
> the
* Markus Armbruster (arm...@redhat.com) wrote:
> Alex Williamson writes:
>
> > On Thu, 29 Sep 2016 15:11:27 +0200
> > Markus Armbruster wrote:
> >
> >> Alex Williamson writes:
> >>
> >> > On Tue, 13 Sep 2016 08:16:20 +0200
> >> > Markus Armbruster wrote:
> >> >
> >> >> Cc: Alex for device a
On Fri, Sep 30, 2016 at 11:21:35PM +0530, Akanksha Srivastava wrote:
> Subject: [Qemu-devel] [PATCH] usb: Change *_exitfn return type from void to
> int
This should read "from int to void", I guess.
> The *_exitfn functions cannot fail and should not be
> returning int.
> Suggested as a Bite-siz
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> Instead of requiring all callers to go through the mutli-step
> process of turning QemuOpts into a suitable QObject for visiting,
> add a new constructor that encapsulates this logic. This will
> allow QObjectInputVisitor to be a drop-in replaceme
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> When converting QemuOpts to a QObject, there is no information
> about compound types available, so when visiting a list, the
> corresponding QObject is not guaranteed to be a QList. We
> therefore need to be able to auto-create a single element Q
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> Currently the QObjectInputVisitor assumes that all scalar
> values are directly represented as the final types declared
> by the thing being visited. ie it assumes an 'int' is using
> QInt, and a 'bool' is using QBool, etc. This is good when
> QO
The *_exitfn functions cannot fail and should not be
returning int.
Suggested as a Bite-sized task
Signed-off-by: Akanksha Srivastava
---
hw/usb/ccid-card-emulated.c | 4 ++--
hw/usb/ccid-card-passthru.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/usb/ccid-card-emu
On 09/30/2016 09:45 AM, Daniel P. Berrange wrote:
> The input_visitor_test_add() method was accepting an instance
> of 'TestInputVisitorData' and passing it as the 'user_data'
> parameter to test functions. The main 'TestInputVisitorData'
> instance that was actually used, was meanwhile being alloc
On 09/28/2016 03:55 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> block/nbd.c | 4 ++--
> tests/qemu-iotests/051.out| 4 ++--
> tests/qemu-iotests/051.pc.out | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Eric Blake
--
Eric Blake
On 30 September 2016 at 03:49, Edgar E. Iglesias
wrote:
> On Fri, Sep 30, 2016 at 12:42:27PM +0200, Thomas Huth wrote:
>> On 30.09.2016 12:19, Edgar E. Iglesias wrote:
>> > From: "Edgar E. Iglesias"
>> >
>> > Fix the decoding of iss_sf in disas_ld_lit.
>> > The SF (Sixty-Four) field in the ISS (I
1 - 100 of 352 matches
Mail list logo
