From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Hogan Subject: Re: [PATCH 11/32] KVM: MIPS: Add VZ capability Date: Fri, 3 Mar 2017 12:37:24 +0000 Message-ID: <20170303123724.GD2878@jhogan-linux.le.imgtec.org> References: <17827db14f848b69e8184ae80b5d63ba01b4b106.1488447004.git-series.james.hogan@imgtec.com> <20170302113923.GC2878@jhogan-linux.le.imgtec.org> <1a071956-a897-a2f9-4523-e6da074568b6@redhat.com> <20170302223407.GQ996@jhogan-linux.le.imgtec.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fOHHtNG4YXGJ0yqR" Cc: , , Radim =?utf-8?B?S3LEjW3DocWZ?= , Ralf Baechle , Jonathan Corbet , To: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: <20170302223407.GQ996@jhogan-linux.le.imgtec.org> Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: List-Id: kvm.vger.kernel.org --fOHHtNG4YXGJ0yqR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 02, 2017 at 10:34:07PM +0000, James Hogan wrote: > I suppose the exception is T&E. It shouldn't assume that just because VZ > is available that T&E isn't (even if that is the case right now). It > could always just try KVM_CREATE_VM with kvm type 0 and detect the error > I suppose, but capabilities are nicer. >=20 > Maybe I'll redefine KVM_CAP_MIPS_VZ a bit, such that the value returned > + 1 is a bitmask of supported kvm types: > has T&E =3D !!( (v + 1) & BIT(KVM_VM_MIPS_TE) ) > has VZ =3D !!( (v + 1) & BIT(KVM_VM_MIPS_VZ) ) >=20 > That way old kernels which return 0 are consistent, and other > implementations could be added if really necessary without confusing > userland (but fingers crossed it'll never ever be necessary). Actually I think the way I had designed KVM_CAP_MIPS_VZ is fine. I had defined it as an enumeration rather than a mask because it isn't expected you'd have more than one hardware virtualisation type able to run on a particular core. Whether T&E is still supported is I think better exposed by a new KVM_CAP_MIPS_TE capability, indicating whether T&E is exposed when KVM_CAP_MIPS_VZ is also set. It would be set to 1 on new kernels whenever T&E is supported. For compatibility with older kernels, userland would be expected to determine whether T&E is present by: check(KVM_CAP_MIPS_VZ) =3D=3D 0 || check(KVM_CAP_MIPS_TE) !=3D 0 Old userland that doesn't check KVM_CAP_MIPS_TE would just hit an EINVAL =66rom KVM_CREATE_VM if T&E isn't supported. Cheers James --fOHHtNG4YXGJ0yqR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYuWN9AAoJEGwLaZPeOHZ66QQP/2h5QTmXXCNWhX56jpnNxgg5 ThVsfufExbMt/LNU8IMTNcPbApYLbq8eLOtAxP8dC0F3Mhhq4C1paFvcQBf9xe+K hbBfkQMC+AgclCozgOssMLsq3l+/UImmQkd9U6oLp30a6KMrqDdyMXQzWAqDDmB/ esdPsHkIo2nxDaWq3RVZfvxeI8dbtqkkOtF8NVLKg6kTUCUPLXAk5xc7sed8fpKQ rUXbb9NSmFTypuRimkh7hG4CuOh7lhHCNjAA+3jHtI4RNFIIA1NxgK2hozEudB/2 1wJabu9QuH/AgHxI5Y8UqdZeE8yM75gVnkFzHKBNOEnh+vkqOwimHhlNglsML1aC yltiUixi/ocY+z4F6QU9dfbYQ3+HHN0xgoz0+Q2ztKVvaF4SVYT70EBa/5+ae8op EoXumZcr5R0d+i++P1XYgBbZ9zckFWpChLK7BcsWhmKg+qwa4f1+2PoAuP9ihpzh FvxtZere4Z6H0aj9Zr7aqLvo84WP0slEzfNUL3Y/2XV7NUnG9TtMjoLeDOUJrroj Re0h0Du44YT7LIZbABCRHMTVtOlPRdOGc8aI4AEYDgNE/bRfkjCvvUJ5xWV0+2vx u2q2PcwIZ6BLlwDSMRWSyRPINOeLLH0ymWHQUgF7D1yu6T+pJZ74Bp6Fgf9I9BjF p6xtOqPMWYmS3X6Ji2Mr =lkZI -----END PGP SIGNATURE----- --fOHHtNG4YXGJ0yqR--