Paolo Bonzini writes:
> On 01/10/19 10:42, Alex Bennée wrote:
>>
>> Paolo Bonzini writes:
>>
>>> On 30/09/19 21:20, Alex Bennée wrote:
Does seem to imply the vCPU CPUState is where the queue is. That's not
to say there shouldn't be a single work queue for thread=single.
>>>
>>> Indee
On Mon, 30 Sep 2019 at 18:47, Paolo Bonzini wrote:
> On 30/09/19 17:37, Peter Maydell wrote:
> > Side note -- this use of run_on_cpu() means that we now drop
> > the iothread lock within memory_region_snapshot_and_clear_dirty(),
> > which we didn't before. This means that a vCPU thread can now
> >
On 01/10/19 10:42, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
>> On 30/09/19 21:20, Alex Bennée wrote:
>>> Does seem to imply the vCPU CPUState is where the queue is. That's not
>>> to say there shouldn't be a single work queue for thread=single.
>>
>> Indeed it doesn't. I confused this wit
Paolo Bonzini writes:
> On 30/09/19 21:20, Alex Bennée wrote:
>> Does seem to imply the vCPU CPUState is where the queue is. That's not
>> to say there shouldn't be a single work queue for thread=single.
>
> Indeed it doesn't. I confused this with commit a8efa60633 ("cpus: run
> work items for
On 30/09/19 21:20, Alex Bennée wrote:
> Does seem to imply the vCPU CPUState is where the queue is. That's not
> to say there shouldn't be a single work queue for thread=single.
Indeed it doesn't. I confused this with commit a8efa60633 ("cpus: run
work items for all vCPUs if single-threaded", 201
Paolo Bonzini writes:
> On 30/09/19 17:37, Peter Maydell wrote:
>> Not sure currently what the best fix is here.
>
> Since thread=single uses just one queued work list, could it be as
> simple as
Does it? I thought this was the case but:
static void queue_work_on_cpu(CPUState *cpu, struct q
On 30/09/19 17:37, Peter Maydell wrote:
> Not sure currently what the best fix is here.
Since thread=single uses just one queued work list, could it be as simple as
diff --git a/cpus.c b/cpus.c
index d2c61ff..314f9aa 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1539,7 +1539,7 @@ static void *qemu_tcg_rr_
Peter Maydell writes:
> On Mon, 30 Sep 2019 at 14:17, Doug Gale wrote:
>>
>> I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
>>
>> qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
>> /usr/share/ovmf/OVMF.fd
>>
>> Using Ubuntu 18.04 LTS, default gnome desktop. T
On Mon, 30 Sep 2019 at 14:17, Doug Gale wrote:
>
> I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
>
> qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
> /usr/share/ovmf/OVMF.fd
>
> Using Ubuntu 18.04 LTS, default gnome desktop. There is no guest OS,
> there is no
I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
/usr/share/ovmf/OVMF.fd
Using Ubuntu 18.04 LTS, default gnome desktop. There is no guest OS,
there is no hard drive, just the OVMF firmware locks it up. (I
narrowed it
I found a lockup in single threaded TCG, with OVMF bios, 16 CPUs.
qemu-system-x86_64 --accel tcg,thread=single -smp cpus=16 -bios
/usr/share/ovmf/OVMF.fd
Using Ubuntu 18.04 LTS, default gnome desktop. There is no guest OS, there
is no hard drive, just the OVMF firmware locks it up. (I narrowed it
11 matches
Mail list logo
