From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: LAPIC soft-disable vs. LVT masking Date: Mon, 20 Oct 2008 14:21:52 +0200 Message-ID: <48FC77E0.9030606@siemens.com> References: <48FC4607.10803@siemens.com> <200810201746.35506.sheng.yang@intel.com> <20081020113158.GA30536@yukikaze> <48FC724B.7030604@siemens.com> <20081020121609.GE30536@yukikaze> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-devel To: "Yang, Sheng" Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:21915 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751617AbYJTMV5 (ORCPT ); Mon, 20 Oct 2008 08:21:57 -0400 In-Reply-To: <20081020121609.GE30536@yukikaze> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > On Mon, Oct 20, 2008 at 01:58:03PM +0200, Jan Kiszka wrote: >> Sheng Yang wrote: >>> On Mon, Oct 20, 2008 at 05:46:35PM +0800, Yang, Sheng wrote: >>>> On Monday 20 October 2008 16:49:11 Jan Kiszka wrote: >>>>> Hi Sheng, >>>>> >>>>> obviously, I meditated too long over the APIC specs and VAPIC code of >>>>> KVM: When the guest resets the soft-enable bit in SVR, the in-kernel >>>>> APIC implementation also set the LVT masked bits - so far, so fine >>>>> (according to specs). But I failed to read out of that doc if those mask >>>>> bits are permanently set (until the guest clears them again) or only >>>>> until the soft-disabling ends (ie. they are restored to their previous >>>>> state - QEMU goes this way). Can you clarify? >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>> Hi Jan >>>> >>>> I also can't find related info in the spec. But I think, when software enable >>>> bit is cleaned, the spec said the mask bits are set, which means the content >>>> of register is changed. And no words for what happen if set software enable >>>> bit, so I think it maybe retain the mask state after software enable (a >>>> little more possibility). >>>> >>>> I will give a update if I got more infos. >>> Find some info: >>> >>> SDM 3A 8.5.1 Local Vector Table >>> Mask: >>> [...] This flag would remain set until software clears it. >>> >>> I think this can explain it. >> If you cut out this sentence allow, maybe. But when looking at the full >> paragraph... >> >> "Interrupt mask: (0) enables reception of the interrupt and (1) inhibits >> reception of the interrupt. When the local APIC handles a >> performance-monitoring counters interrupt, it automatically sets the >> mask flag in the corresponding LVT entry. This flag will remain set >> until software clears it." >> >> At least I put the last sentence in the context of the last-but-one. So, >> do I have to apply an "extended" interpretation here? > > Well, indeed... >>> If you got some interesting circumstance, please share with us. :) >> Well, I guess someone has to "ask" the real hardware (or someone who >> regularly implements it in silicon ;) )... > > Still one concern for asking the real hardware, what if it's implement > specific? For there is indeed no word about it except the one above... > > For software, it's better to not to assume anything in such a condition... Hmm... Considering this thing as "undefined" would allows us to declare both implementations as correct - also fine. Well, then close this topic (until some unfixable OS actually stumbles here :) ). Thanks, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux