On 30/07/2018 11:14, Vitaly Kuznetsov wrote:
> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
>
>> On 27/07/2018 18:48, Jim Mattson wrote:
>>> On a physical machine, I would expect the default local APIC page to
>>> fall in the PCI hole, so it would be correct to sink writes and to
>>> return all ones for reads. Does qemu implement a PCI hole, and does
>>> this address fall into it?
>>
>> It does implement a PCI hole, but when using the kernel LAPIC it expects
>> that only devices write to that range; therefore that address doesn't
>> fall into the PCI hole, and instead it generates an MSIs.
>
> Yes, and that's why I believe it's correct to never forward lapic
> reads/writes from KVM to userspace when lapic is in kernel.
>
> "RFC" was mostly about the inconsistency with the case when APIC access
> page is in use. To be 100% correct I would suggest to somehow make it
> behave like MMIO hole in case we're in x2APIC/disabled mode too.
>
FWIW it is possible to move the MSI memory region from system memory to
the PCI address space in QEMU, however I'm worried about backwards
compatibility.
Vitaly, perhaps you could resubmit this patch, and provide a
KVM_CAP_DISABLE_QUIRKS switch that would make apic_mmio_{read,write}
return -EOPNOTSUPP in this case?
Thanks,
Paolo
