Saw the Alex's patches has been merged, rebase mine onto his.
v3:
1. rename seqlock_read_check as seqlock_read_retry
2. Document timerlist were protected by BQL, and discard private lock around
"qemu_event_wait(tl->ev)".
v2:
1. fix comment in commit and code
2. fix race issue for qemu_cl
From: Paolo Bonzini
This lets the read-side access run outside the BQL.
Signed-off-by: Paolo Bonzini
---
include/qemu/seqlock.h | 72 ++
1 file changed, 72 insertions(+)
create mode 100644 include/qemu/seqlock.h
diff --git a/include/qemu/seqloc
The vm_clock may be read outside BQL. This will make timers_state
--the foundation of vm_clock exposed to race condition.
Using private lock to protect it.
Note in tcg mode, vm_clock still read inside BQL, so icount is
left without private lock's protection. As for cpu_ticks_* in
timers_state, it
From: Paolo Bonzini
This emulates Win32 manual-reset events using futexes or conditional
variables. Typical ways to use them are with multi-producer,
single-consumer data structures, to test for a complex condition whose
elements come from different threads:
for (;;) {
qemu_event_re
After disabling the QemuClock, we should make sure that no QemuTimers
are still in flight. To implement that with light overhead, we resort
to QemuEvent. The caller of disabling will wait on QemuEvent of each
timerlist.
Note, qemu_clock_enable(foo,false) can _not_ be called from timer's cb.
And th
On Tue, 2013-08-27 at 03:48 +0200, Andreas Färber wrote:
> Also, QEMU is definitely not the only project that has higher
> acceptance
> criteria than patch-works-for-the-patch-author. :)
There's a difference between high acceptance criteria and systematic
bike shed painting including in some case
On 08/12/2013 07:02 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 12, 2013 at 12:36:57AM +1000, Alexey Kardashevskiy wrote:
>> On 08/11/2013 11:58 PM, Michael S. Tsirkin wrote:
>>> On Sat, Aug 10, 2013 at 01:09:08AM +1000, Alexey Kardashevskiy wrote:
A PCI device's DMA address space (possibly an
Paolo Bonzini writes:
> Il 26/08/2013 11:06, Nikunj A Dadhania ha scritto:
+fprintf(stderr, "vscsi_send_capabilities: size out of bound !\n");
+goto error_out;
+}
>>>
>>> I am not 100% familiar with the protocol, could it be that we should
>>> just read sizeof(c
Alexander Graf writes:
+rc = spapr_vio_dma_read(&s->vdev, buffer, &cap, len);
+if (rc) {
+fprintf(stderr, "vscsi_send_capabilities: DMA read failure !\n");
>>>
>>> At this point cap contains random host data, no?
>>
>> Yes, and we zero it out in this case.
>
> The
On Tue, Aug 27, 2013 at 03:01:03PM +1000, Alexey Kardashevskiy wrote:
> On 08/12/2013 07:02 PM, Michael S. Tsirkin wrote:
> > On Mon, Aug 12, 2013 at 12:36:57AM +1000, Alexey Kardashevskiy wrote:
> >> On 08/11/2013 11:58 PM, Michael S. Tsirkin wrote:
> >>> On Sat, Aug 10, 2013 at 01:09:08AM +1000,
Alexander Graf writes:
> On 26.08.2013, at 13:46, Nikunj A Dadhania wrote:
>
>> Alexander Graf writes:
>>
>>> On 26.08.2013, at 12:58, Nikunj A Dadhania wrote:
>>>
This implements capabilities exchange between host and client.
As at the moment no capability is supported, put zero fla
Currently if gluster AIO callback thread fails to notify the QEMU thread about
AIO completion, we try graceful recovery by marking the disk drive as
inaccessible. This error recovery code is race-prone as found by Asias and
Stefan. However as found out by Paolo, this kind of error is impossible and
On Mon, Aug 26, 2013 at 09:12:41AM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Aug 22, 2013 at 01:24:50PM +0200, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Thu, Aug 22, 2013 at 10:39:34AM +0200, Markus Armbruster wrote:
> >> >> "Mi
its in the first sentence. let me rephrase: the (windows) guest can select some
screen resolution which SDL cannot
provide. what happens is that qemu quits without giving the quest a chance to
shut down. thats like having a monitor
that crashes windows when it doesnt support the video mode.
--
On 08/27/2013 01:29 AM, David Gibson wrote:
> On Mon, Aug 26, 2013 at 02:24:49PM +0200, Alexander Graf wrote:
>>
>> On 23.08.2013, at 13:30, Alexey Kardashevskiy wrote:
>>
>>> PAPR+ requires two RTAS calls to be supported by the hypervisor in
>>> order to allow hotplugging VCPUs from the guest. The
Il 27/08/2013 07:53, Bharata B Rao ha scritto:
> Currently if gluster AIO callback thread fails to notify the QEMU thread about
> AIO completion, we try graceful recovery by marking the disk drive as
> inaccessible. This error recovery code is race-prone as found by Asias and
> Stefan. However as f
201 - 216 of 216 matches
Mail list logo
