[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824768
Title:
Qemu ARMv7
>> ./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi
I tried both, with -smp 4 and without..
In stable Qemu release, there is just a guest kernel panic, in
v4.0.0-rc3-dirty, there is also Illegal instruction error reported
> on an x-gene system, compiled for aarch32.
Yes, this should
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824768
Title:
Qemu ARMv7 TCG MultiThreading for i386 guest doesn't work
Status in QEMU:
Incomp
When you say
> ./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi
you have not created multiple cpus for the guest, so thread=multi
should have no effect.
For what it's worth, a boot of debian-9.8.0-i386-netinst.iso
(which is what I happened to have handy) works fine with
./qemu-s
Interesting, maybe that is the reason why it is not restricted to use
mttcg from the command line.
So I will be waiting here if you need :)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824768
Titl
That patch is already in QEMU (commit b32dc3370a666e23). It sounds like
we're a bit further forward with this than I thought we might be, but
clearly not everything necessary is implemented.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Yes, I can imagine that.
Unfortunately, my programming knowledge isn't so strong to help you with
it. But can help with testing if it is useful.
Alex Bennée pointed me to this patch:
[RFC,v3,4/5] mttcg: Implement implicit ordering semantics
Which maybe could help. I can try to compile it and do
Implementing a stronger guest memory model than the host has is tricky
-- we would need to emit barrier instructions after each guest load or
store, which would slow down straight-line execution speed by quite a
lot, perhaps by so much that it would outweigh the gain from being able
to run more tha
Thank you for the explanation. I found some patches a few years old, so
I thought the implementation is now complete especially when ARM is
getting more and more popular.
Does it have some priority assigned? Or does it even make sense to do
it? From my perspective, yes even with the broken support
This is expected. The warning from QEMU is telling you that MTTCG is not
supported for the combination of an Arm host and an x86 guest. It warns
that you might see "strange errors", and indeed you saw an error. Don't
try to use MTTCG here.
I think this warning should probably just be an error -- Q
10 matches
Mail list logo
