{"id":2237944,"url":"http://patchwork.ozlabs.org/api/covers/2237944/?format=json","web_url":"http://patchwork.ozlabs.org/project/qemu-devel/cover/20260513163356.3033159-1-shaju.abraham@nutanix.com/","project":{"id":14,"url":"http://patchwork.ozlabs.org/api/projects/14/?format=json","name":"QEMU Development","link_name":"qemu-devel","list_id":"qemu-devel.nongnu.org","list_email":"qemu-devel@nongnu.org","web_url":"","scm_url":"","webscm_url":"","list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260513163356.3033159-1-shaju.abraham@nutanix.com>","list_archive_url":null,"date":"2026-05-13T16:33:43","name":"[RFC,v1,00/13] named CPU models for ARM64 on KVM","submitter":{"id":77003,"url":"http://patchwork.ozlabs.org/api/people/77003/?format=json","name":"Shaju Abraham","email":"shaju.abraham@nutanix.com"},"mbox":"http://patchwork.ozlabs.org/project/qemu-devel/cover/20260513163356.3033159-1-shaju.abraham@nutanix.com/mbox/","series":[{"id":504187,"url":"http://patchwork.ozlabs.org/api/series/504187/?format=json","web_url":"http://patchwork.ozlabs.org/project/qemu-devel/list/?series=504187","date":"2026-05-13T16:33:48","name":"named CPU models for ARM64 on KVM","version":1,"mbox":"http://patchwork.ozlabs.org/series/504187/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2237944/comments/","headers":{"Return-Path":"<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nutanix.com header.i=@nutanix.com header.a=rsa-sha256\n header.s=proofpoint20171006 header.b=prXIhkw/;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=nutanix.com header.i=@nutanix.com header.a=rsa-sha256\n header.s=selector1 header.b=TZc041Tl;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4gFzcC3lYXz1y5L\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 14 May 2026 02:36:11 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1wNCYf-0003u7-Pq; Wed, 13 May 2026 12:35:41 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <shaju.abraham@nutanix.com>)\n id 1wNCY5-0003PD-V7; Wed, 13 May 2026 12:35:09 -0400","from mx0b-002c1b01.pphosted.com ([148.163.155.12])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <shaju.abraham@nutanix.com>)\n id 1wNCXx-0000uR-OP; Wed, 13 May 2026 12:35:00 -0400","from pps.filterd (m0127842.ppops.net [127.0.0.1])\n by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 64DGKvem2443069; Wed, 13 May 2026 09:34:08 -0700","from ch1pr05cu001.outbound.protection.outlook.com\n (mail-northcentralusazon11020081.outbound.protection.outlook.com\n [52.101.193.81])\n by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4e3nv6x8yf-1\n (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);\n Wed, 13 May 2026 09:34:08 -0700 (PDT)","from PH7PR02MB10160.namprd02.prod.outlook.com\n (2603:10b6:510:2e7::19) by CH3PR02MB9564.namprd02.prod.outlook.com\n (2603:10b6:610:120::21) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.23; Wed, 13 May\n 2026 16:34:06 +0000","from PH7PR02MB10160.namprd02.prod.outlook.com\n ([fe80::4ed7:5c74:48e0:ff23]) by PH7PR02MB10160.namprd02.prod.outlook.com\n ([fe80::4ed7:5c74:48e0:ff23%7]) with mapi id 15.20.9891.021; Wed, 13 May 2026\n 16:34:06 +0000"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h=\n cc:content-transfer-encoding:content-type:date:from:message-id\n :mime-version:subject:to; s=proofpoint20171006; bh=yYRoHBgTKlzLw\n yduYLvJ7rzsLRR7sR8DTkLfZSHzcgo=; b=prXIhkw/0d3+VAv5BMgjBYx8+jVuB\n i3zT+4D1EZcBfmJeb5/+UkQQ1k5ejpVq+co+LCjk7fP8tL+PKQ0FPOxGEFAQyo+Y\n JSdM/iPfP0y5bUtuYb9xofi5iz04E85mcd29q3yMu0b2vYBLdm6MTeLBwFv6Cibp\n UYbjCNcwojToJpEF4fgPPUOcyT8TChnIiJ1v0fsbdKPdtMViaRRDrytPZSyjXBHY\n WnGGysQWnYUgwuXPl0ZnEed/Yn/JGxokvcNt5cMivloEfgXs+Pc1PeWxwmHymn19\n +8dJf93B9qMhOUf4tkQmAQEDgXS3LcNPTGWMsGWc85eE9P87/kDT0Gnsg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com;\n s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=yYRoHBgTKlzLwyduYLvJ7rzsLRR7sR8DTkLfZSHzcgo=;\n b=TZc041TlOegXaEgXPhcweB9KGomSSaXoYalzgUyWqn5A/A7QQmm3SqqlXuq23gxZ3rCbQuNdhXUguGICHFk7Z4owjIsgWzo1Pe/cBEqGaYbVbTmnk4sHiJFBM/immW5JukaIx56octn1U7nqVoBQlcMLLqMQR3dJogn1GmEFJrWFppf7Gtw2ZjGmKlo0eSEp1Wy9jHLE+NrsxRAx0y6xHosjUqw03U8y//I72+Sb6e8E3kdAca3IklLB5h8sQItdYpe7W8MNaCVD4eHFF7LTBoON7iAbXY9er0U6dDeUXty/cK9eKrwTvXPJVfLvqXdFJP5xvG1fUjgs23l6PAN1gA=="],"ARC-Seal":"i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=nO3+JMb/Tb5odOKBFqLrmJVf8p/rcAbl/NGeVuOknkec1luQfYdOu2IUhzEdwvePK7eq+gOeno2Vd89nCnhxXNLbXpmaBpGDHM+FXlg+aaBdgH9dHuljbbqfhnjJqYGXXxYXpvwtCJOfGtgt4B6dl13lzF33q+/D8QMmqR0W8NVFtyoJ/rDN8ipvFm9CTQpIXAE1y/MTApHs34woi0ev+Hd0TGIWPptohgM8GeHd7BHnD+HuvqB43boSlNDrmIzbNKaLZcJQFfaRVHAGGRMG9Np9lTg/G08SriTZqRwDcOfYJr2kKXdDg2uLwzv2QDseECEN9hzEaLmDtUfdQHeqqg==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=yYRoHBgTKlzLwyduYLvJ7rzsLRR7sR8DTkLfZSHzcgo=;\n b=dXiJBXruweEmoZCuQOiwnNCvoqk5eKZBPF9LNdxA6SPzVuOBfGBJDiRvABYfP9Schsrn5NXX3P4S7iWTS09F2OP26skIrHf2/HIjhQ9nrIL04ol3Ri3CYska4XyN4YzruYr/08/rB88+1YGP3hY1r9Lfse6zY6eVs/z5Y7daI0hwk4D4TvL7+MJj0sI9klpDGdPNBwx/g8ysUTrXAlPinNejpr8OjkmJRFOzoiOGviWbsXb8qzBu3SCugxmNnyLgsfD7sIsePeZFySOB6M3YHeZhPwF8ujD8cNObAF3k2OYDhq4aRyLw66mBuxkjc9cQG5E40fC3EO2mx7hpKhwiOg==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com;\n dkim=pass header.d=nutanix.com; arc=none","From":"Shaju Abraham <shaju.abraham@nutanix.com>","To":"eric.auger@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org,\n kvmarm@lists.linux.dev, peter.maydell@linaro.org,\n richard.henderson@linaro.org, cohuck@redhat.com, sebott@redhat.com,\n skolothumtho@nvidia.com, philmd@linaro.org","Cc":"maz@kernel.org, oliver.upton@linux.dev, pbonzini@redhat.com,\n prerna.saxena@nutanix.com, jon@nutanix.com, jond@nutanix.com,\n Shaju Abraham <shaju.abraham@nutanix.com>","Subject":"[RFC PATCH v1 00/13] named CPU models for ARM64 on KVM","Date":"Wed, 13 May 2026 16:33:43 +0000","Message-ID":"<20260513163356.3033159-1-shaju.abraham@nutanix.com>","X-Mailer":"git-send-email 2.43.0","Content-Transfer-Encoding":"8bit","Content-Type":"text/plain","X-ClientProxiedBy":"CY5PR10CA0003.namprd10.prod.outlook.com\n (2603:10b6:930:1c::30) To PH7PR02MB10160.namprd02.prod.outlook.com\n (2603:10b6:510:2e7::19)","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"PH7PR02MB10160:EE_|CH3PR02MB9564:EE_","X-MS-Office365-Filtering-Correlation-Id":"6f9e65ac-ee69-44d8-5818-08deb10d7348","x-proofpoint-crosstenant":"true","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"BCL:0;\n ARA:13230040|7416014|376014|366016|1800799024|18002099003|921020|56012099003|3023799003;","X-Microsoft-Antispam-Message-Info":"\n wOxLR2DRRSyWSXESIUAKgcaUfLWOVSYvAyIEsXrrfSO+xs/q37eAOCKKBDiIDhGmP0J2nshkb022hadV/o+a2yJLGYVGlTNw7cfW8wJqrKVESi2TVyKRJg+Gp+4jRo24f2OuGsu5b6jg+IuA7SToQ17JnvJ3M3NmoLxXJscl2/wRBm2hUDhKJkSmFI23w/wQNuTpnTR8MutPCfRxBN1VQKxxIFkaKYNeB9LYiTRG+q/b8U01OG7tk5Rvu7A4O+Zm7Fs7x8XPWjNx9T5BwZBe1RgD7ySfeI6+XC2Qlxjr6+/6GVnHuemiwrD9ogea6bM4s9gtHo/1mth6dWeJSzoByDC/Oisv/Qz02RyV5uyPb5zNCkv/1K0cwVnZ0VLVvVuFaeYNF/8DZDcdwC8vQkYOCHktbgPhNPhIPgE2HQgNQ2Ii+yZE2msiD1i0Z+5oRGNNhUjbPbTViJINowKf/HqD73m1PtzLSouJDMJNefJB1Csmp7cmMDYBWUcAfPlwF0bBHe390u6mWKOjQKb3LRZRWN79FHBxWRCwQKtgpr+cdFeFMZO9TaH5wkVa1IN/XFvFymQKT2J0EJmqxrwW7S8xt0LVzBMDTJU6ZjYE5Zm5QmJYot19JGds2YPQaEx/82ywLNDFhHJgJ+K4I63x2sV+f8XVykQ8mgYAchIM1H/bHbHyzdM+XMkbt6nGWqIQ20OPmvSv0jcnr5O6xW1MWDl1jEfKV+PVwFxpDWjFH2OZdV2Ea2ADwQ0QaBW8xI6+O2+4","X-Forefront-Antispam-Report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:PH7PR02MB10160.namprd02.prod.outlook.com; PTR:;\n CAT:NONE;\n SFS:(13230040)(7416014)(376014)(366016)(1800799024)(18002099003)(921020)(56012099003)(3023799003);\n DIR:OUT; SFP:1102;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"\n 96VCwLnewk1Ypy1qTd1ifREdXicF4c81fpLmc4DudAUavYJ+f11pY3ZzG/smtDm99X9QqU2BQ5XTWkFu7+GgVVUI3hKL1H0y/oqJpNIesYb2ehLKA0aDrzNd7L3pOopiRmXQ382ImOPCNHTLjxWcUM9hzZ+cp6l2fAaySGW4XZV4K9Lcxf9k1uOn/fLuad7FmpIgzCggricFPQ/e2nCueuvHd4XkjRMSIRn75zoipg8yKkY+y/JgUXQ1Oqu0TycrgeqXkIOEqLPFyHFtQKmLoqzL1HZeLXXuUtR3hVqlqUajf4ZSEGMemlppjnMv//qO/RCsqn2T6V0qGyLnnF4JN1XK6xqSWogoOSCkJMcXo0Pjo0G7HwIMbUX1z2VW0VokJKfvWm10ZsYjDYY/Gy9jMTUCLlx7SLgiNHpSVbw0A+rin+7WrO3fVp1L/hztSOl83b5GHAx/lc1t5FNeI6e4DJiI6q/bMRYXIDEbb33zOUgcOeUrMzYHHLCjnojTgpTwX9BnHKa/SRGftfSK4CVcAoWO3vkHLFuKP6U7Z5thFblAD/10W+0T+mkiUWBB6aE9xg2NVftgWhz+qEs7vIkPNbBB+7h5xgSnOWe5F5xBeeKDxC1VgwWaAQrrPq1vlZ/2kF+zs9ywvto5FrR6S4LJEDkJNAHZ/kyBt+MtJ7I8Mjn2XVDXT0wgfXSbYrjiz4Kz7oQ2M5QgFY+MIyJCt+Kh8gaY8Uc4dsmomYlw9vU55VsUGeqDudK46k7KOiDOyACCBZERXptZzyFZOGjEhTFNHjHuQTRm+ABx3wvV8B6nKWB2uEDoNJVdqn9mxVeV0ikEfkoFZTU4FCJavlGEGB3DfIA/gTsASh9zwOycjnLHrhG59AmqjOV9ttj2h7dz3w2Zyp2UZU2L7azrKNjyf8Oh8lMA+N1gbmj83nQ3igOCTaVscw0muZUf/d/m11y4bBWu47ztKzL1BGIj5zxtx4uRSvPzvMUiAC/zrHKBGLxlG4u8DQBHtt5uvgXNnldxrt1jh55pT6pnyeAPg445lFUGpDNNLO6LERKwmN+8X8RfSG/CezJs1uwhZZOUn3lbAlT2v/j8vWMFBinN8o79JDm0dZCmJmWYJK1n7WyqmVm3XwF6oZZImw1nCIGVueeqJyWg+NdPLgZYg5W7tvZbnDH4RitFfsONZxg3bmTpjuhfmk1hVh3Tu7AjzFG9Keyl9+n8urvbcAhEH7W35AESpvdyTnOoG/P1W9Z5dQ4DlYafVHruVDgWv0kOHhgDfH7YLgV3D+FBYvf8oY4mPGzuanwLCKkosjZZdtL9djY/5jHEqqqeQWnAHkmRUvxCtu11ltDf6smavhhccXHtTrFITN+sKa37tgAxQIesrz6SfEypygdaL1y7VOGP7NMzvuOZkVKTW1W7ZWEXBeqV6p6KSnXipe2zCYH0MbdvWDC7N9r+INPXp1DLjkVBRxrD6LpDwnGlahPQoHuzr+wu2Yu/hQnYHi7RDFKANybx+XdILdCqhEnMKEt+gO8RKs/X/HhM6j59TDyrr4GO1tEvzlaFgiTV9RgX7QaIXnkTGpGY13rhAGCRtJpCMdRj7yuNHm0B3pVJzSPfeZBaTXutISJpOCJxz62ZA9lotfQAZXVfPVsk2NzbBh2E3WAN1AkgsGzPT0Lekl3L31lAXRVmY8FlTOj+k8xeRjrNiJmDchvoTIOHdAm+O9l+S3kY0a01yh29fl7iYOruNSdNa5dDC2ZCseIWWHlgCGmuBt5opVbFApMTufw=","X-Exchange-RoutingPolicyChecked":"\n hm5YSNQm9XU6viLcWyJsRYuOyG5BpsatLU9l4QLGSOj+3EzMLzKN/T9c5mXvJmlSysToVuGhiylMcjIxdTrE6HK1zXbpa97zj27T+jEjlpMlLLkKSbGRpciTVwQc8+rwWOV1asJvUxRdls1J+F9ZFID9yH4T+6SYDwDR93XmkLFCvYuUz3LIkKQsZ3APTeh9Z2PIwfjMlpBi5BpDH0uoapwYATseQA4m3ge18zZwe+RSdJ0b8SI/bYBu08EkX0ORYBg/E2055zzri233lEkhgSCvrsEm7fnZGl2Df95ZLaiFky2jfE91nZx0C0E3vHaONzqCa0EBoMwdx8U1TwZHLw==","X-OriginatorOrg":"nutanix.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 6f9e65ac-ee69-44d8-5818-08deb10d7348","X-MS-Exchange-CrossTenant-AuthSource":"PH7PR02MB10160.namprd02.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"13 May 2026 16:34:06.1557 (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"bb047546-786f-4de1-bd75-24e5b6f79043","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n F/FRi/dJcqLWTMOe9oHpGmKBXcnbhyaQVLRmLIvmDRHcxeTuGalouRJovCpattA/b53+DbialjLfqi/bvcaXpIXQslukurWfSMJWnjg8LiI=","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"CH3PR02MB9564","X-Proofpoint-ORIG-GUID":"OAc2w5S-ur-iUOv7Xd44cZOIqXp7jyjw","X-Authority-Analysis":"v=2.4 cv=P7QKQCAu c=1 sm=1 tr=0 ts=6a04a800 cx=c_pps\n a=6CsdduS81u+lxnadr1BEog==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19\n a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19\n a=xqWC_Br6kY4A:10 a=NGcC8JguVDcA:10 a=0kUYKlekyDsA:10\n a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22\n a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8 a=CtIQ0sTlcfwyWDQDvTIA:9","X-Proofpoint-GUID":"OAc2w5S-ur-iUOv7Xd44cZOIqXp7jyjw","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNTEzMDE2OCBTYWx0ZWRfX5u0GRSU/dWrE\n /JjuScJ1RDXV+fHtTGwEDkrcMl6TfrSFH0vhB0OSLWezPSjhGzh8lBFhxu6nhgh3kDZ1n4/47Lv\n QPLq61+Bz5zyHWiKwtlmOyaBVYFLouWG21fDI5tYDc5VQPqTaqT/JasAZ/4ctiTNFqJpbQPjfQz\n 7KKDjuVnwjoPNWuxUDfGaew+O6KRgh2pJ5sgSCYMJHg/PdYfrclNVys/F2sQdFtD3llZSgJWwTd\n 9Ee+0CwSx0MLuJ4SXdBrqOGt75gCXtzuhfBfF0V1eBtjQYL004UnkSJzbjqlYUjeyb/fdRKZEua\n uqbff1aLBGCK8mD4o5ouoE/687JiTpMZD3yjnWqiAkDoZRNrNBg9KSsf47Oc6ZN8Xv3QNwUZt51\n 2mNI8N1YVz9/KG99e+t93ADOP2josQxFjirjQQRpuzhegeek0Ft793AS7iB6HYj6a4WZ8Ce03iD\n OyzTRWpSx0/4pgcTvZA==","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-05-13_01,2026-05-13_01,2025-10-01_01","X-Proofpoint-Spam-Reason":"safe","Received-SPF":"pass client-ip=148.163.155.12;\n envelope-from=shaju.abraham@nutanix.com; helo=mx0b-002c1b01.pphosted.com","X-Spam_score_int":"-31","X-Spam_score":"-3.2","X-Spam_bar":"---","X-Spam_report":"(-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.445,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development <qemu-devel.nongnu.org>","List-Unsubscribe":"<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>","List-Archive":"<https://lists.nongnu.org/archive/html/qemu-devel>","List-Post":"<mailto:qemu-devel@nongnu.org>","List-Help":"<mailto:qemu-devel-request@nongnu.org?subject=help>","List-Subscribe":"<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"},"content":"Hi All,\n\nThis RFC introduces \"named\" CPU models for ARM64 KVM guests. This\nis foundational for cross-host live migration and management-stack\ncontrol over individual CPU features exposed to the guest.\n\nTL;DR Examples:\n  # Boot with Grace CPU model\n  qemu-system-aarch64 -cpu grace-v1 -machine virt,accel=kvm ...\n\n  # Grace with a feature disabled\n  qemu-system-aarch64 -cpu grace-v1,feat_SHA1=off ...\n\n  # Host passthrough with individual feature control\n  qemu-system-aarch64 -cpu host,feat_AES=aes ...\n\n  # Neoverse v2 on Grace.\n  qemu-system-aarch64 -cpu neoverse-v2-v1\n\n  # Migration from Grace to Graviton3 (TBD)\n  qemu-system-aarch64 -cpu neoverse-v1-v1 ...\n\nRelationship with Auger/Huck's customizable host model [1]:\nWe have been working on this series in parallel with [1]. Eric Auger and\nCornelia Huck's series [1] exposes raw SYSREG_<REG>_<FIELD> uint64\nproperties on -cpu host, providing the essential low-level knobs for ID\nregister customization. This RFC builds on the same KVM capability\nand can be layered on top of [1]:\n  - Human-readable property names: feat_AES=pmull instead of\n    SYSREG_ID_AA64ISAR0_EL1_AES=2, with arch-defined named values\n    validated at set time.\n  - Default values and forward compatibility: CPU models start from a\n    known-zero baseline rather than the host view, so new fields/registers\n    introduced in future kernels do not silently leak into existing models.\n  - Named CPU models with hierarchical inheritance: grace-v1,\n    neoverse-v2-v1, etc.\n\nThe two series can coexist; this series can be rebased on top of [1].\n\n[1] https://lore.kernel.org/qemu-devel/20260503073541.790215-1-eric.auger@redhat.com/\n\nProblems with defining \"named\" CPU models for ARM64 KVM guests:\n  * Features are not single CPUID bits. They are mostly multi-bit fields\n    encoding version/level instead of just presence. A single field encodes\n\tmultiple ARM ARM defined features (FEAT_s) at different thresholds.\n  * KVM does not allow all registers and fields to be modified for a guest.\n    Some fields KVM does not virtualise at all (SME) or only support host\n\tvalues (BRPs, CWG, etc.). This is evolving and differs between kernel\n\tversions.\n  * ARM does not have a single natural granularity for CPU models unlike\n    x86. ARM has architecture, reference core and SoC levels each becoming\n\tmore granular.\n  * ARM has dozens of vendors and it will be tricky to maintain models for\n    all of them.\n  * Previous designs started from the host values and then subtracted\n    undesirable features. This is not forward-compatible; the design\n    should work when a new ID register or field is introduced.\n\nWith the above problems in mind, the design has 3 layers:\n\n1. ARM ID Register Field Table:\n   - This layer maintains all architecturally defined ID registers and\n     ID register fields. It includes:\n\t\t* Field name\n\t\t* Field shift\n\t\t* Field length\n\t\t* Safe-value tag: LOWER, HIGHER, HIGHER_OR_ZERO, SIGNED_LOWER,\n\t\t\t\t\t\t  EXACT, ANY\n\t\t\tThis will be used to validate user-provided values during\n\t\t\tCPU realization time against the host's value. I.e., if the\n\t\t\thost only supports \"aes\", a CPU model that sets \"pmull\"\n\t\t\tshould be rejected.\n\t\t* Default value: The value to which the field is reset. This gives\n\t\t\tCPU models a clean cpu.isar.idregs[] baseline instead of the\n\t\t\thost view provided by the kernel, as in previous designs.\n\t\t\tThis also complements the forward-compatibility story. Given\n\t\t\tthe \"default\" values, higher levels need not worry about new\n\t\t\tfields/registers being introduced.\n\t\t* Architecturally defined named values like \"off\", \"aes\", \"pmull\",\n\t\t\tetc.\n\t\t* These values are derived from the kernel's ftr_bits array and\n\t\t  tools/sysreg file.\n    E.g:\n\n     IDREG_START(ID_AA64ISAR0)\n     IDREG_FIELD_START(ID_AA64ISAR0, AES, 4, 4, LOWER, 0)\n     IDREG_FIELD_ARCH_VAL(0b0000, \"off\")\n     IDREG_FIELD_ARCH_VAL(0b0001, \"aes\")\n     IDREG_FIELD_ARCH_VAL(0b0010, \"pmull\")\n     IDREG_FIELD_END(ID_AA64ISAR0, AES)\n\t ....\n\t IDREG_END(ID_AA64ISAR0)\n\n   - This layer is the single source of truth for ARM64 ID registers.\n     The default values and safe-value tags are manually derived from the\n\t kernel's ftr_bits array. Other boilerplate and arch-defined values are\n\t script-generated.\n\n   - AArch32 ID registers are added with a single field so they can be\n     zeroed out on hosts that support AArch32.\n\n   - This layer also defines helpers for higher layers to extract and\n     manipulate ID register fields.\n       * arm_idregs_reset_to_defaults(): Reset all ID registers to their\n\t     default values.\n\t   * arm_idreg_field_read/write(): Read the value of an ID register\n\t     field.\n\t   * arm_arch_val_name/from_name(): Look up the arch-defined name for\n\t     a numeric field value.\n\t   * ...\n\n\t- This layer creates the following tables using X-macro expansion:\n\t   * arm_idregs[]: Array of ID register descriptors.\n\t   * arm_field_locs[]: Array of field location descriptors.\n\t        (fieldIDx -> registerIndex, fieldIndex)\n\t   * ...\n\n    - The ArmIdReg struct also includes a writable_mask to track which\n      bits are writable by KVM. This is populated at runtime during\n      scratch VM creation, and is further used to validate that only\n      the writable bits are modified by the CPU model.\n\n2. ARM Properties Layer:\n   A small property layer on top of the ID Register Field table is defined.\n   This series defines two types of properties with plans for one more\n   in the future:\n      - Single field properties: These represent ARM FEAT_X features\n\t    that correspond to a single ID register field. Example: feat_AES,\n\t    feat_SHA2, etc.\n\n\t\tThe property name is set as \"feat_<FieldName>\" and possible values\n\t\tare the arch-defined named values. This can be further categorized\n\t\tinto:\n\t\t\t* STRING: multi-bit fields (>=2 bits) with arch-defined named\n\t\t\t          values, example: feat_AES, feat_SHA2, etc.\n\t\t\t* BOOLEAN: 1-bit fields only (true/false)\n\t\t\t          example: hw_prop_IDC, hw_prop_DIC, etc.\n\t\t\t* NUMERIC: IDREG_ANY fields with no named values (raw integer)\n\t\t\t          example: hw_prop_BS, hw_prop_DZP, etc.\n\n\t\tString property values are validated against the arch-defined named\n\t\tvalues.\n\n\t\tID register fields that are not covered by single field properties\n\t\tare also exposed as a property named hw_prop_FieldName. These are\n\t\tusually implementation-defined values like cache geometry, debug\n\t\tcounter widths, etc. (CTR_EL0.*, DCZID_EL0.*, etc.)\n\t\tExample: hw_prop_BS, hw_prop_DZP, etc.\n\n\t\tSingle field properties are defined as:\n\n\t\tARM_PROP(\"prop_name\", type, reg, field)\n\t\tExample:\n\t\tARM_PROP(\"feat_AES\", STRING, ID_AA64ISAR0, AES)\n\n\t\t* Validation based on safe-value tags is yet to be implemented.\n\n     - Fractional properties: These represent ARM FEAT_X features that\n\t    use two fields (base + frac) across registers. Example: feat_CSV2,\n\t    feat_MPAM, etc.\n\n\t\tThe property name is set as \"feat_<BaseFieldName>\" and possible\n\t\tvalues are the arch-defined string values like \"0.0\", \"1.0\", \"1.1\",\n\t\tetc.\n\n\t\tFractional properties are defined as:\n\t\tARM_FRACTIONAL_PROP(\"prop_name\", base_reg, base_field, frac_reg, frac_field)\n\t\tExample:\n\t\tARM_FRACTIONAL_PROP(\"feat_CSV2\", ID_AA64PFR0, CSV2, ID_AA64PFR1, CSV2_FRAC)\n\n\n\t\tWhen a fractional property is set, both the base field and frac\n\t\tfield values are set to the corresponding values.\n\t\tE.g: feat_CSV2=1.1 will set ID_AA64PFR0.CSV2=1 and ID_AA64PFR1.CSV2_FRAC=1.\n\n\t- Composite properties (planned for v2):\n\t   These will act as master boolean switches that control a list of\n\t   fields. Example: pauth, sve, etc. Setting sve=on with a named model\n\t   will set all the SVE-related fields (ID_AA64ZFR0_EL1.*) along with\n\t   sveNNN vector-length. Similarly, setting pauth=on will set APA, GPA,\n\t   API, GPA3, GPI, GPA3 fields based on the named model.\n\n\t- cpu_revision, cpu_partnum, etc. properties are introduced to expose\n\t  MIDR, REVIDR, AIDR fields.\n\n\tExceptions to the property naming are made for ID_AA64PFR0_EL1.ELx\n\tfields, which are named elx_mode.\n\n\tThis series defines over 130 single field properties plus 4\n\tfractional properties. All properties work with -cpu host also.\n\n\tAll properties change the cpu.isar.idregs[] values which are later\n\twritten back to KVM at the end of kvm_arch_init_vcpu().\n\n\t* The arch-defined named values and property names can be iterated\n\t  until they make sense.\n\n3. ARM CPU Model Hierarchy:\n\nA small named model layer is defined on top of the properties. An ARM named\nCPU model defines a list of property values and a parent model. A child\nmodel naturally inherits all the properties from its parent and can\noverride them when needed.\n\nThe initial model hierarchy shipped here is:\n    kvm-base-v1                  KVM-imposed quirks\n      arm-v8_4-a-v1              ARMv8.4-A architectural mandate\n          neoverse-v1-v1         Neoverse V1\n\t\t    graviton3-v1         AWS Graviton3\n\t\tarm-v9_0-a-v1            ARMv9.0-A architectural deltas on top of ARM-v8_4-a-v1\n          neoverse-v2-v1         Neoverse V2\n            grace-v1             NVIDIA Grace\n\n(kvm-base-v1 and arm-vX are not meant to be realizable unless the\n user provides values for implementation-defined fields)\n\nSo for example, grace-v1 defines Crypto fields and CTR_EL0.IDC/DIC on top\nof neoverse-v2-v1, which leaves those fields vendor-configurable.\n\nThe hierarchy reflects a deliberate trade-off:\n  - Architecture-level models (arm-v8_4-a-v1) maximize migration\n    compatibility but lack implementation-defined values.\n  - Reference-core models (neoverse-v2-v1) enable migration across\n    SoCs sharing the same core design.\n  - SoC models (grace-v1) expose the full hardware feature set but\n    limit migration to hosts with the same SoC.\n\nAt model realization time,\n    1. a clean slate of cpu.isar.idregs[] is created using\n\t   arm_idregs_reset_to_defaults().\n\t2. Then, a model's full parent-chain is walked and all properties are\n\t   applied in order from parent to child.\n\t3. Finally, kvm_arm_writeback_idregs() compares the model's desired\n\t   ID-register values against the host-provided cpreg snapshot and\n\t   writes back the writable bits, warning on any non-writable difference.\n\nModels will follow a monotonic versioning convention (grace-v1, grace-v2,\n...) mirroring x86's scheme.\n\n* Please take the CPU model property values with a grain of salt.\n  They are added based on what the guest-visible values are with \"host\"\n  model on available hardware.\n\nBenefits of this design:\n\t- General benefits that come with properties and named CPU models,\n\t  like cross-host live migration, management-stack control over\n\t  feature exposure, etc.\n\t- Forward compatibility: when a new ID register or field is\n\t  introduced, CPU models need not change; during realization they\n\t  will be populated with the default values. Only ID register/field\n\t  information needs to be added to the field table.\n\t- As CPU models are hierarchical, defining a new model is much easier.\n\t- The property names and values are self-documenting.\n\nNOTE: ~2200 of the ~3300 added lines are declarative (field table,\nmodel definitions, properties, etc.)\n\nTested with KVM on an NVIDIA Grace host.\n\nRelationship with existing code base:\n - It does not change any TCG-based code paths.\n - For KVM host passthrough it just adds property support.\n - Does not change any existing properties or other code paths.\n - Can layer on top of the SYSREG_ property series [1].\n\nPlanned Follow-ups:\n    - Composite properties with handling of sve, pauth for named models.\n    - CLIDR_EL1 and CCSIDR_EL1 handling.\n\t- Safe-value based validation logic.\n\t- QMP commands like query-cpu-model-expansion are not hooked yet.\n\t  Blockers and supported values (calculated using safe-value tags\n\t  and runtime KVM writable masks) will be reported through them.\n\t  E.g. libvirt could report:\n\t    <property name='feat_AES' type='string' value='pmull'\n\t              supports='off,aes,pmull'/>\n\t  and:\n\t    <cpu type='kvm' name='nvidia-grace-v1'\n\t\t\ttypename='arm-nvidia-grace-v1-arm-cpu' usable='no'>\n\t      <blocker name='feat_AES'/>\n\t    </cpu>\n\n\t- DCZID_EL0 handling.\n\nOut of Scope:\n\t- Inter-feature dependencies like FP <--> AdvSIMD, SM3 <--> SM4, etc.\n\nAppendix: KVM Non-writable fields (kernel 6.18):\n\nThese fields pass the host value through to the guest unmodified on\n6.18; trying to override them get a warning from kvm_arm_writeback_idregs()\nand the slot retains the host value:\n\n   #   Field                       #   Field\n  ---  -----------------------    ---  -----------------------\n   1   ID_AA64PFR0.FP              10  ID_AA64MMFR2.NV\n   2   ID_AA64PFR0.AdvSIMD         11  ID_AA64MMFR2.CCIDX\n   3   ID_AA64MMFR0.ASIDBITS       12  ID_AA64MMFR4.E2H0\n   4   ID_AA64MMFR1.XNX            13  ID_AA64DFR0.CTX_CMPs\n   5   ID_AA64MMFR1.VH             14  ID_AA64DFR0.BRPs\n   6   ID_AA64MMFR1.VMIDBits       15  CTR_EL0.CWG\n   7   ID_AA64MMFR2.EVT            16  CTR_EL0.ERG\n   8   ID_AA64MMFR2.FWB            17  DCZID_EL0.*\n   9   ID_AA64MMFR2.IDS\n\nThis list shifts with the kernel version. The runtime probe via\nKVM_ARM_GET_REG_WRITABLE_MASKS is authoritative.\n\nWarm Regards,\n Shaju, Khushit\n\nKhushit Shah (1):\n  target/arm/kvm: enable writable implementation ID registers\n\nShaju Abraham (12):\n  target/arm: named_cpu_model: define containers for ID registers and\n    fields\n  target/arm: named_cpu_model: Add ID Register Fields\n  target/arm: named_cpu_model: initialise additional sysregs\n  target/arm: named_cpu_model: generate tables for Arm64 ID registers\n    and fields\n  target/arm: named_cpu_model: replace FIELD macro with IDREG_FIELD\n  target/arm: named_cpu_model: data-structures required for the ARM\n    property layer.\n  target/arm: named_cpu_model: define ARM properties\n  target/arm: named_cpu_model: generate arm_cpu_props[] table\n  target/arm: named_cpu_model: Add ID register field helper functions\n  target/arm: named_cpu_model: Register Arm64 properties for host model\n  target/arm: named_cpu_model: introduce named CPU models for selected\n    CPUs\n  target/arm: named_cpu_model: writeback modified ID registers to KVM\n\n hw/arm/virt.c                   |    8 +\n target/arm/arm-cpu-frac.inc.h   |   34 +\n target/arm/arm-cpu-models.c     |  214 ++++\n target/arm/arm-cpu-models.h     |   43 +\n target/arm/arm-cpu-props.c      |  259 +++++\n target/arm/arm-cpu-props.h      |   36 +\n target/arm/arm-cpu-props.inc.h  |  180 ++++\n target/arm/arm-v8_4-a-v1.inc.h  |   22 +\n target/arm/arm-v9_0-a-v1.inc.h  |   28 +\n target/arm/cpu-features.h       |  232 +----\n target/arm/cpu-idregs.c         |  232 +++++\n target/arm/cpu-idregs.h         |  132 +++\n target/arm/cpu-idregs.h.inc     | 1724 +++++++++++++++++++++++++++++++\n target/arm/cpu-sysregs.h.inc    |    5 +\n target/arm/cpu64.c              |    3 +-\n target/arm/grace-v1.inc.h       |   17 +\n target/arm/graviton3-v1.inc.h   |   16 +\n target/arm/kvm-base-v1.inc.h    |   13 +\n target/arm/kvm.c                |  167 ++-\n target/arm/meson.build          |    7 +-\n target/arm/neoverse-v1-v1.inc.h |   64 ++\n target/arm/neoverse-v2-v1.inc.h |   64 ++\n target/arm/trace-events         |    1 +\n 23 files changed, 3284 insertions(+), 217 deletions(-)\n create mode 100644 target/arm/arm-cpu-frac.inc.h\n create mode 100644 target/arm/arm-cpu-models.c\n create mode 100644 target/arm/arm-cpu-models.h\n create mode 100644 target/arm/arm-cpu-props.c\n create mode 100644 target/arm/arm-cpu-props.h\n create mode 100644 target/arm/arm-cpu-props.inc.h\n create mode 100644 target/arm/arm-v8_4-a-v1.inc.h\n create mode 100644 target/arm/arm-v9_0-a-v1.inc.h\n create mode 100644 target/arm/cpu-idregs.c\n create mode 100644 target/arm/cpu-idregs.h\n create mode 100644 target/arm/cpu-idregs.h.inc\n create mode 100644 target/arm/grace-v1.inc.h\n create mode 100644 target/arm/graviton3-v1.inc.h\n create mode 100644 target/arm/kvm-base-v1.inc.h\n create mode 100644 target/arm/neoverse-v1-v1.inc.h\n create mode 100644 target/arm/neoverse-v2-v1.inc.h\n\n--\n2.52.0"}