Am 2015-04-30 um 00:21 schrieb Bandan Das: > Jan Kiszka <jan.kiszka@xxxxxxxxxxx> writes: > ... >>> >>> And I can verify on a SandyBridge and Haswell system that it's RO there too. >> >> So the APIC just ignores the writes, it doesn't through #GP at least. >> >>> >>> In fact, that was one of the reasons I had submitted a patch to remove >>> verify_local_APIC() from x86/kernel/apic.c (4399c03c678) If I am wrong we need to >>> revert atleast the associated commit message :) >> >> Well, we can't remove APIC ID modification support from KVM, though, >> because older CPU types we may want to emulate correctly had that >> feature. But we may have to make it configurable to ensure accurate >> behaviour. > > IMO we should just mark it as read-only. 10.4.6 2nd para says - > > "In MP systems, the local APIC ID is also used as a processor ID by the > BIOS and the operating system. Some processors permit software to modify > the APIC ID. However, the ability of software to modify the APIC ID is > processor model specific. Because of this, operating system software should > avoid writing to the local APIC ID register." > > Not that marking it read-only has any huge benefit, but a r/w ID reg > could be a source of bugs with misbehaving guests. Or at the least, a The current code has been there for quite a while, accepting writes even for CPU models that don't do this on real hw, and nothing apparently broke - or do you know stories? > printk_once warning message when userspace attempts to modify it. Moreover, > we do make an exception with enabling x2apic for guests. The situation is different with x2apic because we even have to raise #GP in case the guest attempts a write. That's mandated by the spec. > > Setting r/w permissions on a per-model is little overkill, don't you think ? If we want accurate behaviour, we should do this. If not, we probably better leave the code alone to avoid surprises for preexisting host/guest setups. Modern OSes do not care anyway, but special ones may get unhappy. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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