From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azmnV-0005WG-Nw for qemu-devel@nongnu.org; Mon, 09 May 2016 11:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azmnR-0001sV-LG for qemu-devel@nongnu.org; Mon, 09 May 2016 11:08:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azmnR-0001sI-GK for qemu-devel@nongnu.org; Mon, 09 May 2016 11:08:33 -0400 Date: Mon, 9 May 2016 17:08:28 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20160509150828.GA12472@potion> References: <1462568028-31037-1-git-send-email-rkrcmar@redhat.com> <1462568028-31037-5-git-send-email-rkrcmar@redhat.com> <572DF5C8.7070105@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <572DF5C8.7070105@web.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: support MSI_X2APIC capability List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, Paolo Bonzini , "Lan, Tianyu" , Igor Mammedov , Peter Xu , Eduardo Habkost , Richard Henderson 2016-05-07 16:03+0200, Jan Kiszka: > On 2016-05-06 22:53, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> The capability alows us to express x2APIC destinations. >=20 > "allows" Thanks. :) > Will the possibility to create >254 CPUs be indirectly coupled to this > capability, or should userland check for it explicitly then? Yes, for now, so I would prefer if userspace checked explicitly. Greater amount of VCPUs needs to be checked with KVM_CAP_MAX_VCPUS, but it's not guaranteed that all kernels with maximum above 255 will have KVM_CAP_MSI_X2APIC as there are other methods of sending an interrupt. > Will the kernel handle the case gracefully that AMD CPUs will report th= e > capability as well, although there is no x2APIC (at least so far) with > those CPU types, and we still inject MSI messages with that flag set > (just to double-check if the case was thought through)? Yes, it's perfectly backward compatible. We allowed x2APIC on emulated AMD cpus in the past and this just extends the address space to 32 bits. Maybe the capability should be called MSI_EXTENDED? (I though about using the same GSI type and just using those upper bits + notifiing QEMU with a capability, but userspace could have passed garbage in those bits, so it had non-zero risk.)