When enabling the sanitizer build it will complain about control
reaching a non-void function. Normally the compiler should detect that
there is only one possible exit given a static VNC_SERVER_FB_BYTES.
As we should never get here I added an abort() rather than a default
return value.
Signed-off
On Fri 16 Sep 2016 10:33:36 AM CEST, Pradeep Jagadeesh wrote:
Hi,
first of all, sorry for the late reply! Here are my comments:
> --- a/fsdev/qemu-fsdev-opts.c
> +++ b/fsdev/qemu-fsdev-opts.c
> @@ -37,6 +37,82 @@ static QemuOptsList qemu_fsdev_opts = {
> }, {
> .name = "soc
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 just ensure that we
don't get torn-updates from two
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v3 00/18] Refactor trace to allow modular build
Message-id: 1474296549-29171-1-git-send-email-berra...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE
Hi,
As a precursor to next set of MTTCG reviews in my inbox I had a quick
look at the current state of using ThreadSanitizer with QEMU. There
are a number of patches here:
1,2,3: workarounds for the compiler when tsan enabled
4,5,6,7: various fixes using atomic_set/read()
8: defend the buil
ThreadSanitizer picks up potential races although we already use
barriers to ensure things are in the correct order when processing exit
requests. For now we just use the relaxed atomic_set/atomic_read semantics
to reassure tsan that we can't tear the value.
Signed-off-by: Alex Bennée
---
cpu-ex
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v2 0/8] Merge qcrypto 2016/09/19
Message-id: 1474299237-1054-1-git-send-email-berra...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$
On 09/19/2016 09:48 AM, Daniel P. Berrange wrote:
> Instead of having a global dstate array, declare a single
> 'uint16 TRACE_${EVENT_NAME}_DSTATE' variable for each
> trace event. Record a pointer to this variable in the
> TraceEvent struct too.
>
> By turning trace_event_get_state_dynamic_by_id
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.
Signed-off-by: Alex Bennée
---
.travis.yml | 16
1 file changed, 16 insertions(+)
diff --git a/.tra
This is to appease sanitizer builds which complain that:
"error: control reaches end of non-void function"
Signed-off-by: Alex Bennée
---
tcg/optimize.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tcg/optimize.c b/tcg/optimize.c
index 9998ac7..0f13490 100644
--- a/tc
As protection against bruteforcing passphrases, the PBKDF
algorithm is tuned by counting the number of iterations
needed to produce 1 second of running time. If the machine
that the image will be used on is much faster than the
machine where the image is created, it can be desirable
to raise the nu
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" writes:
> >>
> >> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> >> "Dr. David Alan Gilbert (git)" writes:
> >> >>
> >> >
It is very useful to know about TLS cert verification
status when debugging, so add a trace point for it.
Signed-off-by: Daniel P. Berrange
---
crypto/tlssession.c | 10 --
crypto/trace-events | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/crypto/tlssession.c b/cr
Currently pbkdf is only supported with SHA1 and SHA256. Expand
this to support all algorithms known to QEMU.
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrange
---
crypto/pbkdf-gcrypt.c | 12 -
crypto/pbkdf-nettle.c | 63 ---
te
The qcrypto_pbkdf_count_iters method uses a 64 bit int
but then checks its value against INT32_MAX before
returning it. This bounds check is premature, because
the calling code may well scale the iteration count
by some value. It is thus better to return a 64-bit
integer and let the caller do range
When calculating iterations for pbkdf of the key slot
data, we had a /= 2, which was copied from identical
code in cryptsetup. It was always unclear & undocumented
why cryptsetup had this division and it was recently
removed there, too.
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrange
-
cryptsetup recently increased the default pbkdf2 time to 2 seconds
to partially mitigate improvements in hardware performance wrt
brute-forcing the pbkdf algorithm. This updates QEMU defaults to
match.
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrange
---
crypto/block-luks.c | 2 +-
qap
Currently when timing the pbkdf algorithm a fixed key
size of 32 bytes is used. This results in inaccurate
timings for certain hashes depending on their digest
size. For example when using sha1 with aes-256, this
causes us to measure time for the master key digest
doing 2 sha1 operations per iterat
The 'out' buffer will hold a key derived from master
password, so it is best practice to clear this buffer
when no longer required.
At this time, the code isn't worrying about locking
buffers into RAM to prevent swapping sensitive data
to disk.
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Be
The following changes since commit 0f2fa73ba0ca19ebdaccf0d1785583d6601411b6:
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
(2016-09-19 11:23:20 +0100)
are available in the git repository at:
git://github.com/berrange/qemu tags/pull-qcrypto-2016-09-19-2
for you t
On Mon, Sep 19, 2016 at 03:36:38PM +0100, Peter Maydell wrote:
> On 19 September 2016 at 12:44, Daniel P. Berrange wrote:
> > The following changes since commit 0f2fa73ba0ca19ebdaccf0d1785583d6601411b6:
> >
> > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
> > (2016-
Remove the notion of there being a single global array
of trace events, by introducing a method for registering
groups of events.
Signed-off-by: Daniel P. Berrange
---
include/qemu/module.h| 2 ++
qemu-img.c | 1 +
qemu-io.c
Move the reading of events out of the 'tracetool.generate'
method and into tracetool.main, so that the latter is not
tied to generating from a single source of events.
Signed-off-by: Daniel P. Berrange
---
scripts/tracetool.py | 4 +++-
scripts/tracetool/__init__.py | 8 +++-
2 file
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>> > * Markus Armbruster (arm...@redhat.com) wrote:
>> >> "Dr. David Alan Gilbert (git)" writes:
>> >>
>> >> > From: "Dr. David Alan Gilbert"
>> >> >
>> >> > Avoid a segfa
The _read_events method is used by callers outside of
its module, so should be a public method, not private.
Signed-off-by: Daniel P. Berrange
---
scripts/simpletrace.py| 6 +++---
scripts/tracetool/__init__.py | 14 --
2 files changed, 15 insertions(+), 5 deletions(-)
diff
Currently simpletrace assumes that events are given IDs
starting from 0, based on the order in which they appear
in the trace-events file, with no gaps. When the
trace-events file is split up, this assumption becomes
problematic.
To deal with this, extend the simpletrace format so that
it outputs
Am 15.09.2016 um 17:51 hat Eric Blake geschrieben:
> On 09/15/2016 03:35 AM, Kevin Wolf wrote:
>
> >>>
> >>> -- "device": block device name (json-string)
> >>> +- "device": block device name (deprecated, use @id instead)
> >>> +(json-string, optional)
> >>> +- "id": the name or QOM p
Instead of having the code generator assign event IDs and
event VCPU IDs, assign them when the events are registered
at runtime. This will allow us allow code to be generated
from individual trace-events without having to figure out
globally unique numbering at build time.
Signed-off-by: Daniel P.
If the ftrace backend is compiled into QEMU, any attempt
to start QEMU while non-root will fail due to the
inability to open /sys/kernel/debug/tracing/trace_on.
Add a fallback into the code so that it connects up the
trace_marker_fd variable to /dev/null when setting
EACCESS on the 'trace_on' file
The CPUState struct has a bitmap tracking which VCPU
events are currently active. This is indexed based on
the event ID values, and sized according the maximum
TraceEventVCPUID enum value.
When we start dynamically assigning IDs at runtime,
we can't statically declare a bitmap without making
an as
The declarations in the generated-tracers.h file are
assuming there's only ever going to be one instance
of this header, as they are not namespaced. When we
have one header per event group, if a single source
file needs to include multiple sets of trace events,
the symbols will all clash.
This cha
The TraceEventID and TraceEventVCPUID enums constants are
no longer actually used for anything critical.
The TRACE_EVENT_COUNT limit is used to determine the size
of the TraceEvents array, and can be removed if we just
NULL terminate the array instead.
The TRACE_EVENT_VCPU_COUNT limit is used as
Instead of having a global dstate array, declare a single
'uint16 TRACE_${EVENT_NAME}_DSTATE' variable for each
trace event. Record a pointer to this variable in the
TraceEvent struct too.
By turning trace_event_get_state_dynamic_by_id into a
macro, this still hits the fast path, and cache affinit
Currently event-internal.h includes generated-events.h,
while generated-events.h includes event-internal.h
causing a circular dependency.
event-internal.h requires that the content of
generated-events.h comes first, so that it can see
the typedefs for TraceEventID and TraceEventVCPUID.
Switching
Currently we only expose a TraceEvent array, which must
be indexed via the TraceEventID enum constants. This
changes the generator to expose a named TraceEvent
instance for each event, with an _EV suffix.
Signed-off-by: Daniel P. Berrange
---
scripts/tracetool/format/events_c.py | 20 +++
The trace_event_count, trace_event_id and
trace_event_pattern methods are no longer required
now that everything is using the iterator APIs
The trace_event_set_state and trace_event_set_vcpu_state
macros were also unused.
Reviewed-by: Lluís Vilanova
Signed-off-by: Daniel P. Berrange
---
trace/
These patches were previously posted as part of my giant
trace events modular build series
v1: https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg01714.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg03335.html
This series does all the refactoring required to support a
Currently the generated-events.[ch] files contain the
event dstates, constants and TraceEvent structs, while the
generated-tracers.[ch] files contain the actual trace
probe logic. With the removal of usage of the event enums
from the API there is no longer any compelling reason for
the separation b
Currently methods which want to iterate over trace events,
do so using the trace_event_count() and trace_event_id()
methods. This leaks the concept of a single ID enum to
the callers. There is an alternative trace_event_pattern()
method which can be used in an iteration context, but its
design is s
Instead of reading the contents of 'trace-events' from stdin,
accept the filename as a positional parameter. This also
allows for reading from multiple files, though this facility
is not used at this time.
Signed-off-by: Daniel P. Berrange
---
Makefile.target | 6 +++---
scripts/tracetool.
The format/h.py file adds an include for control.h to
generated-tracers.h. ftrace, log and syslog, then
add more duplicate includes for control.h.
Signed-off-by: Daniel P. Berrange
---
scripts/tracetool/backend/ftrace.py | 1 -
scripts/tracetool/backend/log.py| 3 +--
scripts/tracetool/backe
This converts the HMP/QMP monitor API implementations
and some internal trace control methods to use the new
trace event iterator APIs.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Daniel P. Berrange
---
monitor.c | 26
trace/control.c | 92
Public bug reported:
When I remote-debug a qemu-guest and attempt to write to a memory mapped
location, the
write-handler for the concerned device will not be called. All write-requiests
from
gdb are delegated to cpu_physical_memory_write_rom(...). a function that writes
to the
underlying ram-
On 19 September 2016 at 12:44, Daniel P. Berrange wrote:
> The following changes since commit 0f2fa73ba0ca19ebdaccf0d1785583d6601411b6:
>
> Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
> (2016-09-19 11:23:20 +0100)
>
> are available in the git repository at:
>
> g
On 09/19/2016 08:29 AM, Nikunj A Dadhania wrote:
> From: Benjamin Herrenschmidt
>
> The existing implementation remains same and ics-base is introduced. The
> type name "ics" is retained, and all the related functions renamed as
> ics_simple_*
>
> This will allow different implementations for th
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert (git)" writes:
> >>
> >> > From: "Dr. David Alan Gilbert"
> >> >
> >> > Avoid a segfault when visiting, e.g., the QOM rtc-time pro
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert (git)" writes:
>>
>> > From: "Dr. David Alan Gilbert"
>> >
>> > Avoid a segfault when visiting, e.g., the QOM rtc-time property,
>> > by implementing the struct callbacks and raising an
Hi Michael,
Long time ago debugged one problem with embARC and I remember I was also
puzzled with itss interrupt handling approach.
The board itself can fit only prebootloader in the ROM, and interrupt handling
is kept in embARC itself.
But, the projects is aimed to support several different RT
On 19 September 2016 at 14:10, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 02:01:59PM +0100, Peter Maydell wrote:
>> But in general I think that
>> "#if 0" should be an error because there's not really any
>> good reason for it. For instance in this case there's no
>> explanation anywhere
On 19 September 2016 at 11:04, Greg Kurz wrote:
> Hi Peter,
>
> This is a respin of v2 with the very same patches, except the one with the
> endianness problems which gets dropped. I hence only post the cover letter.
>
> Cheers.
>
> --
> Greg
>
> The following changes since commit 5f473241ac595452
On 11 September 2016 at 15:54, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> As the migration framework is not included in user mode this needs to be a
> new file.
>
> V7:
> - Use the standard QEMU init/realise functions
> V6:
> - Make the OR IRQ device a TYPE_DEVICE
> - Ad
Hi Igor,
I will try to compile this example and test my implementations.
Thank you,
Michael
On Mon, Sep 19, 2016 at 3:55 PM, Igor Guryanov
wrote:
> Hi Michael,
>
>
>
> Long time ago debugged one problem with embARC and I remember I was also
> puzzled with itss interrupt handling approach.
>
>
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert (git)" writes:
>
> > From: "Dr. David Alan Gilbert"
> >
> > Avoid a segfault when visiting, e.g., the QOM rtc-time property,
> > by implementing the struct callbacks and raising an Error.
> >
> > Signed-off-by: Andreas Färb
Adds events to track vCPU hot-(un)plugging and reset.
As a bonus, first patch fixes per-vCPU dynamic event state initialization,
making the current late initialization code obsolete.
NOTE: This series is missing CPU hot-unplug, since I could not find a generic
point to hook the event.
Sign
"Dr. David Alan Gilbert (git)" writes:
> From: "Dr. David Alan Gilbert"
>
> Reimplement it based on qmp_qom_get() to avoid converting QObjects back
> to strings.
It's not using qmp_qom_get(), though. That's a sign our abstractions
aren't quite right. HMP command handlers should be implemented
Ports enter a "throttled" state when writing to the chardev would block.
The current output VirtQueueElement is kept around until the chardev
becomes writable again.
There are several places in the virtio-serial lifecycle where the
VirtQueueElement should be thrown away. For example, if the virti
On Mon, 09/19 14:01, Peter Maydell wrote:
> On 19 September 2016 at 13:47, Daniel P. Berrange wrote:
> > On Mon, Sep 19, 2016 at 05:33:57AM -0700,
> > no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> >> Hi,
> >>
> >> Your series seems to have some coding style problems. See output below
Make sure to unmap the scatter-gather list and decrement vq->inuse
before freeing requests in virtio_blk_reset().
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 3a6112f..c7ca4d6 1006
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v7 00/16] cpu-exec: Safe work in quiescent state
Message-id: 1474289459-15242-1-git-send-email-pbonz...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BAS
virtio-blk and virtio-serial need to free VirtQueueElements during device
reset. Simply calling g_free(elem) is not enough because the scatter-gather
list should be unmapped and vq->inuse must be decremented.
These patches address the issue. I am not including a patch that changes
vq->inuse = 0
During device reset or similar situations a VirtQueueElement needs to be
freed without pushing it onto the used ring or rewinding the virtqueue.
Extract a new function to do this.
Later patches add virtio_detach_element() calls to existing device so
that scatter-gather lists are unmapped and vq->i
On Mon, Sep 19, 2016 at 02:01:59PM +0100, Peter Maydell wrote:
> On 19 September 2016 at 13:47, Daniel P. Berrange wrote:
> > On Mon, Sep 19, 2016 at 05:33:57AM -0700,
> > no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> >> Hi,
> >>
> >> Your series seems to have some coding style probl
"Dr. David Alan Gilbert (git)" writes:
> From: "Dr. David Alan Gilbert"
>
> Avoid a segfault when visiting, e.g., the QOM rtc-time property,
> by implementing the struct callbacks and raising an Error.
>
> Signed-off-by: Andreas Färber
>
> Updated for changed interface:
> Signed-off-by: Dr. Dav
"Dr. David Alan Gilbert" writes:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> On Mon, Sep 19, 2016 at 10:54:49AM +0100, Daniel P. Berrange wrote:
>> > On Mon, Sep 19, 2016 at 11:18:05AM +0200, Markus Armbruster wrote:
>> > > "Daniel P. Berrange" writes:
>> > >
>> > > > On Wed, Sep 14,
async_run_on_cpu is only called from the I/O thread, not from CPU threads,
so it doesn't make any difference. It will make a difference however
for async_safe_run_on_cpu.
Reviewed-by: Alex Bennée
Signed-off-by: Paolo Bonzini
---
cpus-common.c | 5 -
1 file changed, 5 deletions(-)
diff --g
On 9 September 2016 at 17:22, Cédric Le Goater wrote:
> The AST2500 SoC being very close to the AST2400 SoC, the goal of the
> changes below is to modify the existing platform palmetto-bmc and the
> AST2400 SoC to take into account the small differences and avoid code
> duplication. This is mostly
Signed-off-by: Paolo Bonzini
---
cpus-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpus-common.c b/cpus-common.c
index a739e66..4232255 100644
--- a/cpus-common.c
+++ b/cpus-common.c
@@ -88,8 +88,7 @@ struct qemu_work_item {
struct qemu_work_item *next;
On 19 September 2016 at 13:47, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 05:33:57AM -0700,
> no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
>> Hi,
>>
>> Your series seems to have some coding style problems. See output below for
>> more information:
>>
>> Type: series
>> Subjec
Signals the hot-plugging of a new virtual (guest) CPU.
Signed-off-by: Lluís Vilanova
---
trace-events |8
trace/control-target.c |3 +++
2 files changed, 11 insertions(+)
diff --git a/trace-events b/trace-events
index 616cc52..16a1cb4 100644
--- a/trace-events
+++ b/t
From: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Reviewed-by: Alex Bennée
Signed-off-by: Alex Bennée
Message-Id: <1470158864-17651-9-git-send-email-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini
---
linux-user/main.c | 10 ++
1 file changed, 10
Every time a vCPU is hot-plugged, it will "inherit" its tracing state
from the global state array. That is, if *any* existing vCPU has an
event enabled, new vCPUs will have too.
Signed-off-by: Lluís Vilanova
---
bsd-user/main.c|1 -
linux-user/main.c |1 -
qom/cpu.c
Set cpu->running without taking the cpu_list lock, only look at it if
there is a concurrent exclusive section. This requires adding a new
field to CPUState, which records whether a running CPU is being counted
in pending_cpus. When an exclusive section is started concurrently with
cpu_exec_start,
From: Sergey Fedorov
Move the code common between run_on_cpu() and async_run_on_cpu() into a
new function queue_work_on_cpu().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Reviewed-by: Alex Bennée
Signed-off-by: Alex Bennée
Message-Id: <1470158864-17651-4-git-send-email-alex.b
We have to run safe work items outside the BQL; for now keep other
work items within the BQL, though this can be changed relatively
easily as a follow-up.
Signed-off-by: Paolo Bonzini
---
cpus-common.c | 33 +++--
include/qom/cpu.h | 14 ++
2 files cha
No need to call exclusive_idle() from cpu_exec_end since it is done
immediately afterwards in cpu_exec_start. Any exclusive section could
run as soon as cpu_exec_end leaves, because cpu->running is false and the
mutex is not taken, so the call does not add any protection either.
Signed-off-by: Pa
From: Sergey Fedorov
To avoid possible confusion, rename flush_queued_work() to
process_queued_cpu_work().
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Reviewed-by: Alex Bennée
Signed-off-by: Alex Bennée
Message-Id: <1470158864-17651-6-git-send-email-alex.ben...@linaro.org>
Si
Signals the reset of the state a virtual (guest) CPU.
Signed-off-by: Lluís Vilanova
---
qom/cpu.c|3 +++
trace-events |5 +
2 files changed, 8 insertions(+)
diff --git a/qom/cpu.c b/qom/cpu.c
index 7e2e523..5f0ec6e 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -29,6 +29,7 @@
#inclu
Signed-off-by: Paolo Bonzini
---
docs/tcg-exclusive.promela | 176 +
1 file changed, 176 insertions(+)
create mode 100644 docs/tcg-exclusive.promela
diff --git a/docs/tcg-exclusive.promela b/docs/tcg-exclusive.promela
new file mode 100644
index 00
From: Sergey Fedorov
Make CPU work core functions common between system and user-mode
emulation. User-mode does not use run_on_cpu, so do not implement it.
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Reviewed-by: Alex Bennée
Signed-off-by: Alex Bennée
Message-Id: <1470158864-
In addition to fixing some of the issues found by Alex, safe work items
need not run anymore with a mutex taken. Of course, cpu_exec_start/end
and start_exclusive/end_exclusive are essentially the read and write
side of a specialized rwlock, so there is still a lock in disguise looming
to cause de
It is not necessary to hold qemu_cpu_list_mutex throughout the
exclusive section, because no other exclusive section can run
while pending_cpus != 0.
exclusive_idle() is called in cpu_exec_start(), and that prevents
any CPUs created after start_exclusive() from entering cpu_exec()
during an exclus
This will serve as the base for async_safe_run_on_cpu.
Reviewed-by: Alex Bennée
Signed-off-by: Paolo Bonzini
---
bsd-user/main.c | 17 ---
cpus-common.c | 82 +++
cpus.c| 2 ++
include/qom/cpu.h | 44
From: Sergey Fedorov
Convert pthread_mutex_t and pthread_cond_t to QemuMutex and QemuCond.
This will allow to make some locks and conditional variables common
between user and system mode emulation.
Signed-off-by: Sergey Fedorov
Signed-off-by: Sergey Fedorov
Reviewed-by: Alex Bennée
Signed-of
From: Sergey Fedorov
Use async_safe_run_on_cpu() to make tb_flush() thread safe. This is
possible now that code generation does not happen in the middle of
execution.
It can happen that multiple threads schedule a safe work to flush the
translation buffer. To keep statistics and debugging outpu
On Mon, Sep 19, 2016 at 05:33:57AM -0700,
no-re...@ec2-52-6-146-230.compute-1.amazonaws.com wrote:
> Hi,
>
> Your series seems to have some coding style problems. See output below for
> more information:
>
> Type: series
> Subject: [Qemu-devel] [PULL v1 0/8] Merge qcrypto 2016/09/19
> Message-id
Add a mutex for the CPU list to system emulation, as it will be used to
manage safe work. Abstract manipulation of the CPU list in new functions
cpu_list_add and cpu_list_remove.
Signed-off-by: Paolo Bonzini
---
Makefile.objs | 2 +-
bsd-user/main.c | 9 +
cpus-commo
From: Alex Bennée
CPUState is a fairly common pointer to pass to these helpers. This means
if you need other arguments for the async_run_on_cpu case you end up
having to do a g_malloc to stuff additional data into the routine. For
the current users this isn't a massive deal but for MTTCG this get
On 6 September 2016 at 19:07, Andrey Yurovsky wrote:
> Add the "cortex-a7" CPU with features and registers matching the Cortex-A7
> MPCore Technical Reference Manual and the Cortex-A7 Floating-Point Unit
> Technical Reference Manual. The A7 is very similar to the A15.
>
> Signed-off-by: Andrey Yur
On 14/09/2016 10:25, Peter Xu wrote:
> (Note: we still have pending discussions on how IOMMU notifier
> interface should be, assuming that is not a blocker for posting v5 of
> this one)
>
> V5:
> - squash spapr_tce_notify_{started|stopped} into
> spapr_tce_notify_flag_changed [David]
> - in
On Sep 19, 2016, at 2:24 AM, Benjamin Herrenschmidt wrote:
On Sat, 2016-09-17 at 23:31 -0400, G 3 wrote:
Add the ability to add resolutions from the command-line. This
patch
works by
looking for a property called 'resolutions' in the options node of
OpenBIOS.
If it is found all the resolutions
On 19/09/2016 14:29, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 02:19:19PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 19/09/2016 14:12, Daniel P. Berrange wrote:
>>> On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange wrote:
The current -object command line syntax only allows
ble in the git repository at:
>
> git://github.com/cohuck/qemu tags/s390x-20160919
>
> for you to fetch changes up to 4d4ccabdd22153bd19e0c4bbb6fbfe8402a7b845:
>
> QMP: fixup typos and whitespace damage (2016-09-19 11:05:51 +0200)
>
> --
Hi Michael,
I'm pretty sure embARC was not meant to be run on ARCompact (AKA ISAv1 cores
like ARC600 & ARC700) instead targets were ARCv2 cores like ARC EM and ARC HS.
Unfortunately I have no experience with embARC so adding more experienced
person in the thread (Igor Guryanov) who may shed som
Excellent news; thanks for testing!
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1618431
Title:
windows hangs after live migration with virt
On 19/09/2016 14:12, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange wrote:
>> The current -object command line syntax only allows for
>> creation of objects with scalar properties, or a list
>> with a fixed scalar element type. Objects which have
>> prope
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v1 0/8] Merge qcrypto 2016/09/19
Message-id: 1474285452-6166-1-git-send-email-berra...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$
Thank I test the 2 patches and they worked for me.
It works also if you apply only the qemu patch,
in combination the ubuntu kernel 4.4.0-38.57 and qemu 2.6.1.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
** Changed in: qemu
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1618431
Title:
windows hangs after live migration with virtio
Status in QEMU:
Fix C
On Mon, Sep 19, 2016 at 02:19:19PM +0200, Paolo Bonzini wrote:
>
>
> On 19/09/2016 14:12, Daniel P. Berrange wrote:
> > On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange wrote:
> >> The current -object command line syntax only allows for
> >> creation of objects with scalar properties,
On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange wrote:
> The current -object command line syntax only allows for
> creation of objects with scalar properties, or a list
> with a fixed scalar element type. Objects which have
> properties that are represented as structs in the QAPI
> sch
201 - 300 of 405 matches
Mail list logo
