From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: APIC_ID in apic_reg_write() Date: Wed, 29 Apr 2015 18:21:50 -0400 Message-ID: References: <55412433.7080805@siemens.com> <55412C05.4090705@siemens.com> Mime-Version: 1.0 Content-Type: text/plain Cc: kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43875 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbbD2WVw (ORCPT ); Wed, 29 Apr 2015 18:21:52 -0400 In-Reply-To: <55412C05.4090705@siemens.com> (Jan Kiszka's message of "Wed, 29 Apr 2015 21:07:49 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka 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 printk_once warning message when userspace attempts to modify it. Moreover, we do make an exception with enabling x2apic for guests. Setting r/w permissions on a per-model is little overkill, don't you think ? > Jan