From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: x86: Question regarding the reset value of LINT0 Date: Thu, 09 Apr 2015 21:28:09 +0300 Message-ID: <5526C4B9.6030101@gmail.com> 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> <06DCB70D-52E7-457B-BEEF-051F20136D7A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kiszka , Paolo Bonzini , kvm list To: Nadav Amit , Bandan Das Return-path: Received: from mail-wg0-f41.google.com ([74.125.82.41]:34586 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932927AbbDIS2N (ORCPT ); Thu, 9 Apr 2015 14:28:13 -0400 Received: by wgso17 with SMTP id o17so17179721wgs.1 for ; Thu, 09 Apr 2015 11:28:12 -0700 (PDT) In-Reply-To: <06DCB70D-52E7-457B-BEEF-051F20136D7A@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/09/2015 09:21 PM, Nadav Amit wrote: > Bandan Das wrote: > >> Nadav Amit writes: >> >>> Jan Kiszka wrote: >>> >>>> On 2015-04-08 19:40, Nadav Amit wrote: >>>>> Jan Kiszka wrote: >>>>> >>>>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>>>> Jan Kiszka wrote: >>>>>>> >>>>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I would appreciate if someone explains the reason for enablin= g 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 t= o 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=E2=80=99s apic_reset= _common: >>>>>>>>> >>>>>>>>> if (bsp) { >>>>>>>>> /* >>>>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at ini= tialization >>>>>>>>> * time typically by BIOS, so PIC interrupt can be deliv= ered to the >>>>>>>>> * processor when local APIC is enabled. >>>>>>>>> */ >>>>>>>>> s->lvt[APIC_LVT_LINT0] =3D 0x700; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Yet, in both cases, I miss the point - if it is typically don= e 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 someth= ing that >>>>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initiali= zation? >>>>>>> Thanks. I found no indication of such thing. >>>>>>> >>>>>>> QEMU=E2=80=99s commit message (0e21e12bb311c4c1095d0269dc2ef811= 96ccb60a) says: >>>>>>> >>>>>>> Don't route PIC interrupts through the local APIC if the loca= l APIC >>>>>>> config says so. By Ari Kivity. >>>>>>> >>>>>>> Maybe Avi Kivity knows this guy. >>>>>> ths? That should have been Thiemo Seufer (IIRC), but he just com= mitted >>>>>> 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 tr= ied to make an unfunny joke >>>>> about Avi knowing =E2=80=9CAri=E2=80=9D). >>>> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>>> >>>>>> But if that commit went in without any BIOS changes around it, Q= EMU >>>>>> 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 QEM= U 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.=E2=80=9D) So it should be included in seabio= s 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= something >> as old as 0.12 is probably minimal. I think it's ok to change it wit= h a comment >> indicating the reason. To be on the safe side, however, a user chang= eable switch >> is something worth considering. > I don=E2=80=99t see any existing mechanism for KVM to be aware of its= user type and > version. I do see another case of KVM hacks that are intended for fix= ing > very old QEMU bugs (see 3a624e29c75 changes in vmx_set_segment, which= are > from pretty much the same time-frame of the issue I try to fix). > > Since this is something which would follow around, please advise what= would > be the format. A new ioctl that would supply the userspace =E2=80=9Ct= ype=E2=80=9D (according > to predefined constants) and version? That would be madness. KVM shouldn't even know that qemu exists, let=20 alone track its versions. Simply add a new toggle KVM_USE_STANDARD_LAPIC_LVT_INIT and document=20 that userspace MUST use it. Old userspace won't, and will get the old=20 buggy behavior.