Yes it did.
** Changed in: qemu
Status: Fix Committed => 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/1319100
Title:
qemu-arm-static bug in signal handling causes mono and ja
Paolo Bonzini writes:
> Do not use the somewhat mysterious atomic_mb_read/atomic_mb_set,
> instead make sure that the operations on QemuEvent are annotated
> with the desired acquire and release semantics.
>
> In particular, qemu_event_set wakes up the waiting thread, so it must
> be a release f
Max,
Just a common question for this case, if sshx block driver wasn't built
into qemu-img, this case would fail as below:
exec /home/haoqf/KVMonz/qemu/tests/qemu-iotests/../../qemu-img info
--image-opts driver=ssh,host=localhost,port=0.42,path=/foo
qemu-img: Could not open
'driver=ssh,host=
On 11 October 2016 at 16:51, Taylor Edward Heimbichner
wrote:
> I'm a student researcher with the University of Arizona's Computer Science
> Department. I'm writing to ask if any executable that you use to test QEMU
> systematically tests all, or at least a large portion, of the x86
> instruction
Am 11.10.2016 um 18:50 hat Markus Armbruster geschrieben:
> Eric Blake writes:
>
> > On 10/11/2016 09:57 AM, Kevin Wolf wrote:
> >> Should we introduce a new, clean blockdev-stream command that fixes this
> >> and matches the common name pattern? Of course, block-stream vs.
> >> blockdev-stream c
Hi Pranith,
I was curious about the status of your MTTCG GSoC work:
I saw your fence series which implements the noop memory barrier/fence
instructions on various architectures, but I wasn't sure if that also
covers the case where a strong target is emulated on a weak host.
Did you make TCG autom
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v1 0/3] POWER9 TCG enablements - part6
Message-id: 1476248933-25562-1-git-send-email-nik...@linux.vnet.ibm.com
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=ba
From: Prasad J Pandit
Rocker network switch emulator has test registers to help debug
DMA operations. While testing host DMA access, a buffer address
is written to register 'TEST_DMA_ADDR' and its size is written to
register 'TEST_DMA_SIZE'. When performing TEST_DMA_CTRL_INVERT
test, if DMA buffe
From: "Daniel P. Berrange"
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.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Lluís Vilanova
Signed-off-by: Daniel P. Berrange
Message
From: "Daniel P. Berrange"
The _read_events method is used by callers outside of
its module, so should be a public method, not private.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Lluís Vilanova
Signed-off-by: Daniel P. Berrange
Message-id: 1475588159-30598-18-git-send-email-berra...@redhat.com
From: "Daniel P. Berrange"
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 symb
From: "Daniel P. Berrange"
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 compellin
On 10/11/2016 12:24 PM, David Gibson wrote:
> On Mon, Oct 10, 2016 at 02:56:25PM +0200, Cédric Le Goater wrote:
>>
@@ -227,11 +227,44 @@ static void ppc_powernv_init(MachineState *machine)
snprintf(chip_name, sizeof(chip_name), "chip[%d]", CHIP_HWID(i));
object_prop
From: "Daniel P. Berrange"
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.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Lluís Vilanova
Sign
From: "Daniel P. Berrange"
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_VCPU_
From: "Daniel P. Berrange"
Remove the notion of there being a single global array
of trace events, by introducing a method for registering
groups of events.
The module_call_init() needs to be invoked at the start
of any program that wants to make use of the trace
support. Currently this covers s
From: Lluís Vilanova
Add missing execution mode documentation for the 'guest_cpu_enter' and
'guest_cpu_reset' events.
Signed-off-by: Lluís Vilanova
Message-id: 147566900921.7708.656450813307396468.st...@fimbulvetr.bsc.es
Signed-off-by: Stefan Hajnoczi
---
trace-events | 2 ++
1 file changed,
From: "Daniel P. Berrange"
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
From: "Daniel P. Berrange"
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 _EVENT suffix.
Reviewed-by: Lluís Vilanova
Reviewed-by: Stefan Hajnoczi
Si
From: "Daniel P. Berrange"
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 simpletra
From: "Daniel P. Berrange"
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 code to be generated from
individual trace-events without having to figure out
globally unique numbering at build time.
Revi
From: "Daniel P. Berrange"
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: Stefan Hajnoczi
Reviewed-by: Llu
From: "Daniel P. Berrange"
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.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Lluís Vilanova
Signed-off-by: Daniel P. Berrange
Message-id: 1475588159-30598
From: "Daniel P. Berrange"
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
From: "Daniel P. Berrange"
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
From: "Daniel P. Berrange"
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
Reviewed-by: Lluís Vilanova
Message-id: 1475588159-30598-5-git-send
From: "Daniel P. Berrange"
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
The following changes since commit 627eae7d729277c84f8e0ac07a8caab39c92c38d:
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
(2016-10-10 16:23:40 +0100)
are available in the git repository at:
git://github.com/stefanha/qemu.git tags/tracing-pull-request
for you to
From: "Daniel P. Berrange"
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/tracing_on.
Add a fallback into the code so that it connects up the
trace_marker_fd variable to /dev/null when getting
From: "Daniel P. Berrange"
The colo patch series added various trace events to the top
level trace-events file, despite the files using them being
in a sub-dir.
commit 30656b097e9dd7978d3fe9416cb9f5a421a9e63e
Author: Zhang Chen
Date: Tue Sep 27 10:22:34 2016 +0800
filter-rewriter:
* Markus Armbruster (arm...@redhat.com) wrote:
> Marc-André Lureau writes:
>
> > This option does nothing since commit 06ac27f. Deprecate it.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > vl.c | 11 +++
> > include/monitor/monitor.h | 2 +-
> > qemu-options
Paolo Bonzini writes:
> There is a data race if the variable is written concurrently to the
> read. In C11 this has undefined behavior. Use atomic_read. The
> write side does not need atomic_set, because it is protected by a
> mutex.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Alex Bennée
> I received a mail saying my series failed the automatic build test but
> it builds completely fine (after applying Dan's patch obviously) in my
> local environment.
>
> Going through the config output of the test script, I see that the
> supporting library for SSH which is "libssh2" seems to be d
Am 12.10.2016 um 10:37 hat Ashijeet Acharya geschrieben:
> On Wed, Oct 12, 2016 at 1:52 PM, Kevin Wolf wrote:
> > Am 12.10.2016 um 10:09 hat Ashijeet Acharya geschrieben:
>
> > Of course, we must be able to build qemu correctly both with ssh enabled
> > and disabled, so if you can indeed see a (d
Am 12.10.2016 um 03:14 hat Fam Zheng geschrieben:
> On Wed, 09/28 15:04, Fam Zheng wrote:
> > Handling this is similar to what is done to the L2 entry in the case of
> > compressed clusters.
>
> Kevin, Max, is there anything else I need to do before this patch can be
> applied?
Hm, actually, it l
> From: Kirti Wankhede
> Sent: Tuesday, October 11, 2016 4:29 AM
>
[...]
> +
> +/*
> + * mdev_unregister_device : Unregister a parent device
> + * @dev: device structure representing parent device.
> + *
> + * Remove device from list of registered parent devices. Give a chance to
> free
> + * ex
On Wed, Oct 12, 2016 at 1:52 PM, Kevin Wolf wrote:
> Am 12.10.2016 um 10:09 hat Ashijeet Acharya geschrieben:
> Of course, we must be able to build qemu correctly both with ssh enabled
> and disabled, so if you can indeed see a (different) build error with
> disabled libssh2, that needs to be fix
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Message-id: 1476247497-6976-1-git-send-email-da...@gibson.dropbear.id.au
Subject: [Qemu-devel] [PATCHv2 0/7] Improve PCI IO window orgnaization for
pseries
Type: series
=== TEST SCRIPT BEGIN ===
#!/
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH 0/7] Improve PCI IO window orgnaization for pseries
Message-id: 1476246592-24228-1-git-send-email-da...@gibson.dropbear.id.au
Type: series
=== TEST SCRIPT BEGIN ===
#!/bi
On 10/11/2016 07:49 PM, Igor Mammedov wrote:
On Mon, 10 Oct 2016 21:09:30 +0800
Xiao Guangrong wrote:
On 10/10/2016 08:51 PM, Igor Mammedov wrote:
On Sat, 8 Oct 2016 15:17:14 +0800
Xiao Guangrong wrote:
On 09/30/2016 09:14 PM, Igor Mammedov wrote:
On Fri, 12 Aug 2016 14:54:05 +0800
Xiao
Am 12.10.2016 um 10:09 hat Ashijeet Acharya geschrieben:
> I received a mail saying my series failed the automatic build test but
> it builds completely fine (after applying Dan's patch obviously) in my
> local environment.
The reason why patchew fails to build your series is because it doesn't
un
On 12/10/2016 06:44, David Gibson wrote:
> Currently the functions in pci-spapr.c (like pci-pc.c on which it's based)
> don't distinguish between 32-bit and 64-bit PCI MMIO. At the moment, the
> qemu side implementation is a bit weird and has a single MMIO window
> straddling 32-bit and 64-bit r
On 12/10/2016 09:54, Gonglei (Arei) wrote:
>
>> -Original Message-
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
>> Bonzini
>> Sent: Wednesday, October 12, 2016 3:41 PM
>> To: Gonglei (Arei); Michael Tokarev; qemu-devel@nongnu.org
>> Cc: qemu-triv...@nongnu.o
On 12/10/2016 07:58, P J P wrote:
> From: Prasad J Pandit
>
> 16550A UART device uses an oscillator to generate frequencies
> (baud base), which decide communication speed. This speed could
> be changed by dividing it by a divider. If the divider is
> greater than the baud base, speed is set to
On Tue, Oct 11, 2016 at 1:07 PM, Ashijeet Acharya
wrote:
> This series adds blockdev-add support for SSH block driver.
>
> Patch 1 prepares the code for the addition of a new option prefix,
> which is "server.". This is accomplished by adding a
> ssh_has_filename_options_conflict() function which
"Daniel P. Berrange" writes:
> Instead of requiring all callers to go through the mutli-step
multi-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 replacement for
On 12/10/2016 06:44, David Gibson wrote:
> In pci-spapr.c (as in pci-pc.c from which it was derived), the
> pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1]
> essentially define the region of PCI (not CPU) addresses in which MMIO
> or PIO BARs respectively will be alloca
On 12/10/2016 06:44, David Gibson wrote:
> The libqos code for accessing PCI on the spapr machine type uses IOBASE()
> and MMIOBASE() macros to determine the address in the CPU memory map of
> the windows to PCI address space.
>
> This is a detail of the implementation of PCI in the machine type
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Wednesday, October 12, 2016 3:41 PM
> To: Gonglei (Arei); Michael Tokarev; qemu-devel@nongnu.org
> Cc: qemu-triv...@nongnu.org; Herongguang (Stephen)
> Subject: Re: [PATCH] mmap
On Fri, Oct 07, 2016 at 02:51:17PM +0100, Daniel P. Berrange wrote:
> The bsd-user/linux-user programs make use of the CPU emulation
> code and this now requires that the trace events subsystem
> is enabled, otherwise it'll crash trying to allocate an empty
> trace events bitmap for the CPU object.
On 12/10/2016 09:37, Gonglei (Arei) wrote:
>> -Original Message-
>> From: Michael Tokarev [mailto:m...@tls.msk.ru]
>> Sent: Wednesday, October 12, 2016 2:46 PM
>> Subject: Re: [PATCH] mmap-alloc: check before use for ptr pointer
>>
>> 12.10.2016 05:05, Gonglei wrote:
>>> If ptr mmap faile
> -Original Message-
> From: Michael Tokarev [mailto:m...@tls.msk.ru]
> Sent: Wednesday, October 12, 2016 2:46 PM
> Subject: Re: [PATCH] mmap-alloc: check before use for ptr pointer
>
> 12.10.2016 05:05, Gonglei wrote:
> > If ptr mmap failed, we don't need to do a superfluous
> > calculati
This was found with test-i386. The issue is that instructions
such as
addr32 lea (%eax), %rax
did not perform a 32-bit extension, because the LEA translation
skipped the gen_lea_v_seg step. That step does not just add
segments, it also takes care of extending from address size to
pointer si
From: Li Qiang
In v9fs_link dispatch function, it doesn't put the 'oldfidp'
fid object, this will make the 'oldfidp->ref' never reach to 0,
thus leading a memory leak issue. This patch fix this.
Signed-off-by: Li Qiang
---
hw/9pfs/9p.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/9pf
On 12/10/2016 01:51, Taylor Edward Heimbichner wrote:
> I'm writing to ask if any executable that you use to test QEMU
> systematically tests all, or at least a large portion, of the x86
> instruction set? We're working on a project that involves dynamic taint
> analysis and would like to use an
301 - 355 of 355 matches
Mail list logo
