From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "Jim Mattson" <jmattson@google.com>,
"kvm list" <kvm@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in x2APIC mode
Date: Thu, 2 Aug 2018 13:54:51 +0200 [thread overview]
Message-ID: <ee1f404c-75d5-eee2-d2fc-014df3a7d01d@redhat.com> (raw)
In-Reply-To: <87sh41nkz5.fsf@vitty.brq.redhat.com>
On 30/07/2018 11:14, Vitaly Kuznetsov wrote:
> Paolo Bonzini <pbonzini@redhat.com> 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
next prev parent reply other threads:[~2018-08-02 11:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 14:44 [PATCH RFC] x86/kvm/lapic: always disable MMIO interface in x2APIC mode Vitaly Kuznetsov
2018-07-27 16:48 ` Jim Mattson
2018-07-27 17:00 ` Paolo Bonzini
2018-07-30 9:14 ` Vitaly Kuznetsov
2018-08-02 11:54 ` Paolo Bonzini [this message]
2018-08-02 13:30 ` Vitaly Kuznetsov
2018-08-02 13:34 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee1f404c-75d5-eee2-d2fc-014df3a7d01d@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rkrcmar@redhat.com \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox