From nobody Mon Apr 29 07:39:59 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511374317483657.3787836670192; Wed, 22 Nov 2017 10:11:57 -0800 (PST) Received: from localhost ([::1]:40776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHZUk-0007ij-0K for importer@patchew.org; Wed, 22 Nov 2017 13:11:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHZTf-0007OX-1q for qemu-devel@nongnu.org; Wed, 22 Nov 2017 13:10:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHZTe-0005sY-2K for qemu-devel@nongnu.org; Wed, 22 Nov 2017 13:10:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49826) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHZTd-0005ru-LH for qemu-devel@nongnu.org; Wed, 22 Nov 2017 13:10:25 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E1405C047B69; Wed, 22 Nov 2017 18:10:23 +0000 (UTC) Received: from flask (ovpn-204-21.brq.redhat.com [10.40.204.21]) by smtp.corp.redhat.com (Postfix) with SMTP id 1BA9F5D6A5; Wed, 22 Nov 2017 18:10:20 +0000 (UTC) Received: by flask (sSMTP sendmail emulation); Wed, 22 Nov 2017 19:10:20 +0100 From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= To: qemu-devel@nongnu.org Date: Wed, 22 Nov 2017 19:09:08 +0100 Message-Id: <20171122180908.31389-1-rkrcmar@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 22 Nov 2017 18:10:23 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] kvm: apic: save and restore x2APIC LDR X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Eduardo Habkost , "Dr . David Alan Gilbert" , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" QEMU saves only 8 bits of APIC LDR, which means that it does not support x2APIC. The correct way of fixing this would be to save and restore the full 32 bit register, but because x2APIC LDR is a function of x2APIC ID, we can also compute it and keep the migration format untouched. KVM always expected the LDR format to follow the xAPIC/x2APIC standard, but pre 4.1 KVMs used non-standard x2APIC ID in case the OS changed xAPIC ID before switching to x2APIC, which means that QEMU has to use the kvm_x2apic_api feature to derive the x2APIC ID. This bug has also been addressed on the KVM side with patch 5849d75a5c9b ("KVM: lapic: Fixup LDR on load in x2apic"). Reported-by: Dr. David Alan Gilbert Reported-by: Yiqian Wei Signed-off-by: Radim Kr=C4=8Dm=C3=A1=C5=99 --- I haven't tested that it actually fixes the bug, https://bugzilla.redhat.com/show_bug.cgi?id=3D1502591. =20 hw/i386/kvm/apic.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c index 1df6d26816f9..89df165a04bf 100644 --- a/hw/i386/kvm/apic.c +++ b/hw/i386/kvm/apic.c @@ -30,6 +30,13 @@ static inline uint32_t kvm_apic_get_reg(struct kvm_lapic= _state *kapic, return *((uint32_t *)(kapic->regs + (reg_id << 4))); } =20 +static inline uint32_t kvm_apic_calc_x2apic_ldr(APICCommonState *s) +{ + uint32_t id =3D kvm_has_x2apic_api() ? s->initial_apic_id : s->id; + + return ((id >> 4) << 16) | (1 << (id & 0xf)); +} + static void kvm_put_apic_state(APICCommonState *s, struct kvm_lapic_state = *kapic) { int i; @@ -41,7 +48,11 @@ static void kvm_put_apic_state(APICCommonState *s, struc= t kvm_lapic_state *kapic kvm_apic_set_reg(kapic, 0x2, s->id << 24); } kvm_apic_set_reg(kapic, 0x8, s->tpr); - kvm_apic_set_reg(kapic, 0xd, s->log_dest << 24); + if (s->apicbase & MSR_IA32_APICBASE_EXTD) { + kvm_apic_set_reg(kapic, 0xd, kvm_apic_calc_x2apic_ldr(s)); + } else { + kvm_apic_set_reg(kapic, 0xd, s->log_dest << 24); + } kvm_apic_set_reg(kapic, 0xe, s->dest_mode << 28 | 0x0fffffff); kvm_apic_set_reg(kapic, 0xf, s->spurious_vec); for (i =3D 0; i < 8; i++) { @@ -71,7 +82,11 @@ void kvm_get_apic_state(DeviceState *dev, struct kvm_lap= ic_state *kapic) } s->tpr =3D kvm_apic_get_reg(kapic, 0x8); s->arb_id =3D kvm_apic_get_reg(kapic, 0x9); - s->log_dest =3D kvm_apic_get_reg(kapic, 0xd) >> 24; + if (s->apicbase & MSR_IA32_APICBASE_EXTD) { + assert(kvm_apic_get_reg(kapic, 0xd) =3D=3D kvm_apic_calc_x2apic_ld= r(s)); + } else { + s->log_dest =3D kvm_apic_get_reg(kapic, 0xd) >> 24; + } s->dest_mode =3D kvm_apic_get_reg(kapic, 0xe) >> 28; s->spurious_vec =3D kvm_apic_get_reg(kapic, 0xf); for (i =3D 0; i < 8; i++) { --=20 2.14.2