From: Thomas Gleixner <tglx@linutronix.de>
To: Bandan Das <bsd@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/apic: reset LDR in clear_local_APIC
Date: Wed, 21 Aug 2019 20:22:21 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1908212008500.1983@nanos.tec.linutronix.de> (raw)
In-Reply-To: <jpgwof6plkv.fsf@linux.bootlegged.copy>
Bandan,
On Wed, 21 Aug 2019, Bandan Das wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> So, in KVM: if we make sure that the logical destination map isn't filled up if the virtual
> apic is not enabled by software, it really doesn't matter whether the LDR for an inactive CPU
> has a stale value.
>
> In x86/apic: if we make sure that the LDR is 0 or reset,
> recalculate_apic_map() will never consider including this cpu in the
> logical map.
?
> In short, as I mentioned in the patch description, this is really a KVM
> bug but it doesn't hurt to clear out the LDR in the guest and then, it
> wouldn't need a hypervisor fix.
I still needs a hypervisor fix. Taking disabled APICs into account is a bug
which has also other consequeces than that particular one. So please don't
claim that. It's wrong.
If that prevents the APIC bug from triggering on unfixed hypervisors, then
this is a nice side effect, but not a solution.
> Is this better ?
That's way better.
So can you please create two patches:
1) Make that bogus bigsmp ldr init empty
That one wants a changelog along these lines:
- Setting LDR for physical destination mode is pointless
- Setting multiple bits in the LDR is wrong
Mention how this was discovered and caused the KVM APIC bug to be
triggered. Also mention that the change is not there to paper over
the KVM APIC bug. The change fixes a bug in the bigsmp APIC code.
2) Clear LDR in in that apic reset function
That one wants a changelog along these lines:
- Except for x2apic the LDR should be cleared as any other APIC
register
Mention how this was discovered. Again the change is not there to
paper over the KVM APIC bug. It's for correctness sake and valid on
its own.
Thanks,
tglx
next prev parent reply other threads:[~2019-08-21 18:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 4:00 Bandan Das
2019-08-19 21:07 ` Thomas Gleixner
2019-08-19 22:05 ` Bandan Das
2019-08-19 23:09 ` Thomas Gleixner
2019-08-21 15:47 ` Bandan Das
2019-08-21 18:22 ` Thomas Gleixner [this message]
2019-08-21 19:54 ` Bandan Das
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=alpine.DEB.2.21.1908212008500.1983@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=bsd@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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
all inboxes | Powered by JetHome®