On Mon, Dec 19, 2011 at 1:15 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 12/11/2011 11:25 AM, Christoffer Dall wrote:
WARNING: This code is in development and guests do not fully boot on SMP
hosts yet.
Hello,
What would still be needed to fully booted SMP? For example,
On 19/12/11 14:57, Christoffer Dall wrote:
On Mon, Dec 19, 2011 at 1:15 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 12/11/2011 11:25 AM, Christoffer Dall wrote:
WARNING: This code is in development and guests do not fully boot on SMP
hosts yet.
Hello,
What would still
On 12/19/2011 04:19 PM, Marc Zyngier wrote:
On 19/12/11 14:57, Christoffer Dall wrote:
You should simply start booting a UP guest on an SMP host, see where
it crashes and start tracking it down.
For the time being, I've yet to see UP guest crashing on SMP host. On
the model, that is...
On 19/12/11 15:30, Antonios Motakis wrote:
On 12/19/2011 04:19 PM, Marc Zyngier wrote:
On 19/12/11 14:57, Christoffer Dall wrote:
You should simply start booting a UP guest on an SMP host, see where
it crashes and start tracking it down.
For the time being, I've yet to see UP guest crashing
On Mon, Dec 19, 2011 at 10:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
On 19/12/11 15:30, Antonios Motakis wrote:
On 12/19/2011 04:19 PM, Marc Zyngier wrote:
On 19/12/11 14:57, Christoffer Dall wrote:
You should simply start booting a UP guest on an SMP host, see where
it crashes and
On 12/19/2011 04:40 PM, Christoffer Dall wrote:
On Mon, Dec 19, 2011 at 10:37 AM, Marc Zyngiermarc.zyng...@arm.com wrote:
On 19/12/11 15:30, Antonios Motakis wrote:
On 12/19/2011 04:19 PM, Marc Zyngier wrote:
On 19/12/11 14:57, Christoffer Dall wrote:
You should simply start booting a UP
On 19/12/11 15:42, Antonios Motakis wrote:
On 12/19/2011 04:40 PM, Christoffer Dall wrote:
On Mon, Dec 19, 2011 at 10:37 AM, Marc Zyngiermarc.zyng...@arm.com wrote:
On 19/12/11 15:30, Antonios Motakis wrote:
On 12/19/2011 04:19 PM, Marc Zyngier wrote:
On 19/12/11 14:57, Christoffer Dall
2011/12/19 Christoffer Dall cd...@cs.columbia.edu:
ok, just reproduced.
Using the AEM v7 model, 2 cores, attached guest and host config.
Host running on the v5 of the KVM/ARM branch, found here:
https://github.com/virtualopensystems/linux-kvm-arm
Guest kernel revision:
On Dec 19, 2011, at 12:19 PM, Peter Maydell peter.mayd...@linaro.org wrote:
2011/12/19 Christoffer Dall cd...@cs.columbia.edu:
ok, just reproduced.
Using the AEM v7 model, 2 cores, attached guest and host config.
Host running on the v5 of the KVM/ARM branch, found here:
On 19 December 2011 17:24, Christoffer Dall
christofferd...@christofferdall.dk wrote:
On Dec 19, 2011, at 12:19 PM, Peter Maydell peter.mayd...@linaro.org wrote:
2011/12/19 Christoffer Dall cd...@cs.columbia.edu:
ok, just reproduced.
Using the AEM v7 model, 2 cores, attached guest and host
the problem so far is SMP hosts, but I used this revision:
c3ea1e4ac8b2ff0f13d86289562a477f0ae3fd6b
On Mon, Dec 19, 2011 at 12:36 PM, Peter Maydell
peter.mayd...@linaro.org wrote:
On 19 December 2011 17:24, Christoffer Dall
christofferd...@christofferdall.dk wrote:
On Dec 19, 2011, at 12:19
On Tue, Dec 13, 2011 at 4:37 AM, Avi Kivity a...@redhat.com wrote:
On 12/12/2011 09:36 PM, Christoffer Dall wrote:
something like this:
if (irq_level-level) {
set_bit(vcpu-arch.irq_lines, bit_nr);
smp_mb();
wake_up_interruptible(vcpu-wq);
or,
On 12/13/2011 03:36 PM, Christoffer Dall wrote:
if (new_virt_intr == IRQ | FIQ virt_intr == FIQ) {
/* IRQ raised, FIQ already set */
return;
}
hmm, so what you want to avoid here is sending an IPI to the other CPU
in case we already have FIQ raised? But I think we have to
On 13/12/11 13:36, Christoffer Dall wrote:
On Tue, Dec 13, 2011 at 4:37 AM, Avi Kivity a...@redhat.com wrote:
if (new_virt_intr == IRQ | FIQ virt_intr == FIQ) {
/* IRQ raised, FIQ already set */
return;
}
hmm, so what you want to avoid here is sending an IPI to the other CPU
On Dec 13, 2011, at 9:17 AM, Avi Kivity a...@redhat.com wrote:
On 12/13/2011 03:36 PM, Christoffer Dall wrote:
if (new_virt_intr == IRQ | FIQ virt_intr == FIQ) {
/* IRQ raised, FIQ already set */
return;
}
hmm, so what you want to avoid here is sending an IPI to the other CPU
in
On Mon, Dec 12, 2011 at 12:56 PM, Avi Kivity a...@redhat.com wrote:
On 12/12/2011 07:37 PM, Christoffer Dall wrote:
This looks overly complicated with two levels of locks. x86 gets by
with no locks, and a much more complicated interrupt architecture.
My recommendation is:
16 matches
Mail list logo
