Re: x86: Question regarding the reset value of LINT0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:

> On 2015-04-08 19:40, Nadav Amit wrote:
>> Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>> 
>>> On 2015-04-08 18:59, Nadav Amit wrote:
>>>> Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>>>> 
>>>>> On 2015-04-08 18:40, Nadav Amit wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during
>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local
>>>>>> Vector Table” that says all LVT registers are reset to 0x10000.
>>>>>> 
>>>>>> In kvm_lapic_reset, I see:
>>>>>> 
>>>>>> 	apic_set_reg(apic, APIC_LVT0,
>>>>>> 		SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
>>>>>> 
>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common:
>>>>>> 
>>>>>>  if (bsp) {
>>>>>>      /*
>>>>>>       * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization
>>>>>>       * time typically by BIOS, so PIC interrupt can be delivered to the
>>>>>>       * processor when local APIC is enabled.
>>>>>>       */
>>>>>>      s->lvt[APIC_LVT_LINT0] = 0x700;
>>>>>>  }
>>>>>> 
>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS,
>>>>>> why does QEMU or KVM enable it?
>>>>>> 
>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me
>>>>>> problems in certain cases.
>>>>> 
>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find
>>>>> more information in the git logs of both code bases? Or something that
>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization?
>>>> Thanks. I found no indication of such thing.
>>>> 
>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says:
>>>> 
>>>>   Don't route PIC interrupts through the local APIC if the local APIC
>>>>   config says so. By Ari Kivity.
>>>> 
>>>> Maybe Avi Kivity knows this guy.
>>> 
>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed
>>> the code back then (and is no longer with us, sadly).
>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke
>> about Avi knowing “Ari”).
> 
> Ah. No problem. My brain apparently fixed that typo up unnoticed.
> 
>>> But if that commit went in without any BIOS changes around it, QEMU
>>> simply had to do the job of the latter to keep things working.
>> So should I leave it as is? Can I at least disable in KVM during INIT (and
>> leave it as is for RESET)?
> 
> No, I don't think there is a need to leave this inaccurate for QEMU if
> our included BIOS gets it right. I don't know what the backward
> bug-compatibility of KVM is, though. Maybe you can identify since when
> our BIOS is fine so that we can discuss time frames.

I think that it was addressed in commit
19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the
local APIC of the BSP.”) So it should be included in seabios 0.5.0, which
means qemu 0.12 - so we are talking about the end of 2009 or start of 2010.

What is the verdict?

Nadav--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux