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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
