Re: APIC_ID in apic_reg_write()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux