On 07/04/2015 15:40, Andreas Färber wrote:
> Am 07.04.2015 um 15:29 schrieb Paolo Bonzini:
>> On 07/04/2015 15:24, Andreas Färber wrote:
> /* We hard-wire the BSP to the first CPU. */
> if (s->cpu_index == 0) {
> apic_designate_bsp(cpu->apic_state);
> }
>>> I k
On 07/04/15 16:29, Paolo Bonzini wrote:
On 07/04/2015 15:26, Denis V. Lunev wrote:
On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
If this is some issue with sync'ing state back and forth before
QEMU and
KVM then the real issue has not been explained.
Hm
Am 07.04.2015 um 15:44 schrieb Denis V. Lunev:
> On 07/04/15 16:29, Paolo Bonzini wrote:
>>
>>
>> On 07/04/2015 15:26, Denis V. Lunev wrote:
>>> On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
>>> If this is some issue with sync'ing state back a
Am 07.04.2015 um 15:29 schrieb Paolo Bonzini:
> On 07/04/2015 15:24, Andreas Färber wrote:
/* We hard-wire the BSP to the first CPU. */
if (s->cpu_index == 0) {
apic_designate_bsp(cpu->apic_state);
}
>> I know, that's what this patch is changing, and I am say
On 07/04/2015 15:24, Andreas Färber wrote:
>> > /* We hard-wire the BSP to the first CPU. */
>> > if (s->cpu_index == 0) {
>> > apic_designate_bsp(cpu->apic_state);
>> > }
> I know, that's what this patch is changing, and I am saying that by the
> same logic the CPU has no bus
On 07/04/2015 15:26, Denis V. Lunev wrote:
> On 07/04/15 16:18, Paolo Bonzini wrote:
>>
>>
>> On 07/04/2015 13:57, Andreas Färber wrote:
> If this is some issue with sync'ing state back and forth before
> QEMU and
> KVM then the real issue has not been explained.
>>> Hm, hw/intc/apic_
On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
If this is some issue with sync'ing state back and forth before QEMU and
KVM then the real issue has not been explained.
Hm, hw/intc/apic_common.c:apic_reset_common() has:
bsp = cpu_is_bsp(s->cpu);
s
Am 07.04.2015 um 15:14 schrieb Igor Mammedov:
> On Tue, 07 Apr 2015 13:57:34 +0200
> Andreas Färber wrote:
>
>> Am 07.04.2015 um 13:09 schrieb Andreas Färber:
>>> Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
On 07/04/2015 12:44, Andreas Färber wrote:
>>> It can change at runtime, though
On 07/04/2015 13:57, Andreas Färber wrote:
>> > If this is some issue with sync'ing state back and forth before QEMU and
>> > KVM then the real issue has not been explained.
> Hm, hw/intc/apic_common.c:apic_reset_common() has:
>
> bsp = cpu_is_bsp(s->cpu);
> s->apicbase = APIC_DEFAULT_AD
On Tue, 07 Apr 2015 13:57:34 +0200
Andreas Färber wrote:
> Am 07.04.2015 um 13:09 schrieb Andreas Färber:
> > Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
> >> On 07/04/2015 12:44, Andreas Färber wrote:
> > It can change at runtime, though, if you're using the KVM
> > in-kernel LAPIC.
>
Am 07.04.2015 um 13:09 schrieb Andreas Färber:
> Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
>> On 07/04/2015 12:44, Andreas Färber wrote:
> It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
>>> Got a pointer? A quick git-grep doesn't show anything in hw/ or
>>> kvm-a
Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
> On 07/04/2015 12:44, Andreas Färber wrote:
It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
>> Got a pointer? A quick git-grep doesn't show anything in hw/ or
>> kvm-all.c or target-i386/ assigning cpu_index, so it'll al
On 07/04/2015 12:44, Andreas Färber wrote:
>> > It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
> Got a pointer? A quick git-grep doesn't show anything in hw/ or
> kvm-all.c or target-i386/ assigning cpu_index, so it'll always have the
> initial value.
Not cpu_index, s
Am 07.04.2015 um 12:34 schrieb Paolo Bonzini:
> On 07/04/2015 12:15, Andreas Färber wrote:
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index b2d1c95..03b33cf 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -2714,9 +2714,7 @@ static void x86_cpu_re
On 07/04/2015 12:15, Andreas Färber wrote:
>>> >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>> >> index b2d1c95..03b33cf 100644
>>> >> --- a/target-i386/cpu.c
>>> >> +++ b/target-i386/cpu.c
>>> >> @@ -2714,9 +2714,7 @@ static void x86_cpu_reset(CPUState *s)
>>> >>
>>> >> #if !defined
+Eduardo as target-i386 maintainer
Am 02.04.2015 um 14:34 schrieb Paolo Bonzini:
>
>
> On 02/04/2015 01:58, Nadav Amit wrote:
>> Since the BSP bit is writable on real hardware, during reset all the CPUs
>> which
>> were not chosen to be the BSP should have their BSP bit cleared. This fix is
>>
On 02/04/2015 01:58, Nadav Amit wrote:
> Since the BSP bit is writable on real hardware, during reset all the CPUs
> which
> were not chosen to be the BSP should have their BSP bit cleared. This fix is
> required for KVM to work correctly when it changes the BSP bit.
>
> An additional fix is re
Since the BSP bit is writable on real hardware, during reset all the CPUs which
were not chosen to be the BSP should have their BSP bit cleared. This fix is
required for KVM to work correctly when it changes the BSP bit.
An additional fix is required for QEMU tcg to allow software to change the BS
18 matches
Mail list logo
