On 10/21/15 17:11, Paolo Bonzini wrote:
>
>
> On 21/10/2015 17:04, Laszlo Ersek wrote:
>> Now, on TCG, reading the APIC ID register (for device "apic") happens in:
>>
>> apic_mem_readl() [hw/intc/apic.c]
>> val = s->id << 24
>>
>> Whereas on KVM, the same occurs in:
>>
>> kvm_apic_mem_read() [hw/i386/kvm/apic.c]
>> return ~(uint64_t)0;
>>
>> However, such reads don't seem to reach QEMU (and the above read stub);
>> they are handled within KVM (I don't know where the distinction is made
>> in KVM).
>
> It's here:
>
> static u32 __apic_read(struct kvm_lapic *apic, unsigned int offset)
> {
> u32 val = 0;
>
> if (offset >= LAPIC_MMIO_LENGTH)
> return 0;
>
> switch (offset) {
> case APIC_ID:
> if (apic_x2apic_mode(apic))
> val = kvm_apic_id(apic);
> else
> val = kvm_apic_id(apic) << 24;
> break;
Sorry, I don't understand -- is this the distinction between normal and
x2apic mode, or the distinction whether the read access will be
forwarded to userspace vs. handled in KVM? My statement was about the
latter question.
> I'll try following the equally dizzying chains in OVMF
(not contesting that! :))
> and see why KVM
> is in x2apic mode.
I don't think KVM is in x2apic mode. I have no proof either way, but I
saw nothing implying x2apic. FWIW, LocalApicLib has two instances in edk2:
UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
("supports xAPIC mode only")
UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
("supports x2APIC capable processors which have xAPIC and x2APIC modes")
and all client modules in OVMF are linked against the former.
> In any case, "-cpu foo,-x2apic" is the next thing to
> try.
Tried it just now, no observable change.
... I gather it works on upstream or kvm/next host kernels; is that
correct? Maybe I should try a reverse bisection. *Shudder*.
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
