From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: x86: Question regarding the reset value of LINT0 Date: Wed, 08 Apr 2015 18:11:20 -0400 Message-ID: References: <2B474EEE-85C9-47C3-89FF-C56754CFEC0D@gmail.com> <55255AF2.2070706@siemens.com> <06513D06-1629-4AC0-9014-C6D13C29A1FC@gmail.com> <55256004.8030403@siemens.com> <55256A89.3030100@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kiszka , Paolo Bonzini , Avi Kivity , kvm list To: Nadav Amit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54824 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754010AbbDHWLX convert rfc822-to-8bit (ORCPT ); Wed, 8 Apr 2015 18:11:23 -0400 In-Reply-To: (Nadav Amit's message of "Thu, 9 Apr 2015 00:49:47 +0300") Sender: kvm-owner@vger.kernel.org List-ID: Nadav Amit writes: > Jan Kiszka wrote: > >> On 2015-04-08 19:40, Nadav Amit wrote: >>> Jan Kiszka wrote: >>>=20 >>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>> Jan Kiszka wrote: >>>>>=20 >>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> I would appreciate if someone explains the reason for enabling = LINT0 during >>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8= : =E2=80=9CLocal >>>>>>> Vector Table=E2=80=9D that says all LVT registers are reset to = 0x10000. >>>>>>>=20 >>>>>>> In kvm_lapic_reset, I see: >>>>>>>=20 >>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>>=20 >>>>>>> Which is actually pretty similar to QEMU=E2=80=99s apic_reset_c= ommon: >>>>>>>=20 >>>>>>> if (bsp) { >>>>>>> /* >>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initi= alization >>>>>>> * time typically by BIOS, so PIC interrupt can be deliver= ed to the >>>>>>> * processor when local APIC is enabled. >>>>>>> */ >>>>>>> s->lvt[APIC_LVT_LINT0] =3D 0x700; >>>>>>> } >>>>>>>=20 >>>>>>> Yet, in both cases, I miss the point - if it is typically done = by the BIOS, >>>>>>> why does QEMU or KVM enable it? >>>>>>>=20 >>>>>>> BTW: KVM seems to run fine without it, and I think setting it c= auses me >>>>>>> problems in certain cases. >>>>>>=20 >>>>>> I suspect it has some historic BIOS backgrounds. Already tried t= o find >>>>>> more information in the git logs of both code bases? Or somethin= g that >>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initializa= tion? >>>>> Thanks. I found no indication of such thing. >>>>>=20 >>>>> QEMU=E2=80=99s commit message (0e21e12bb311c4c1095d0269dc2ef81196= ccb60a) says: >>>>>=20 >>>>> Don't route PIC interrupts through the local APIC if the local = APIC >>>>> config says so. By Ari Kivity. >>>>>=20 >>>>> Maybe Avi Kivity knows this guy. >>>>=20 >>>> ths? That should have been Thiemo Seufer (IIRC), but he just commi= tted >>>> the code back then (and is no longer with us, sadly). >>> Oh=E2=80=A6 I am sorry - I didn=E2=80=99t know about that.. (I trie= d to make an unfunny joke >>> about Avi knowing =E2=80=9CAri=E2=80=9D). >>=20 >> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>=20 >>>> But if that commit went in without any BIOS changes around it, QEM= U >>>> 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 IN= IT (and >>> leave it as is for RESET)? >>=20 >> 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 wh= en >> our BIOS is fine so that we can discuss time frames. > > I think that it was addressed in commit > 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs o= n the > local APIC of the BSP.=E2=80=9D) 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. The probability that someone will use a newer version of kernel with so= mething as old as 0.12 is probably minimal. I think it's ok to change it with a= comment indicating the reason. To be on the safe side, however, a user changeab= le switch is something worth considering. > What is the verdict? > > Nadav-- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html