[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 00/14] x86/hvm: {svm,vmx} {c,h} cleanup
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 27 Feb 2023 11:46:50 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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; bh=oE41pJpNyFuLR2pR7p7MmSNHYwgMf2SNOMpvUGq9vis=; b=VBsiDATK1fYCQocknlV/pjo1fUZJy0wE55gtkDyasXKD+H6VbVLyyQR9SnGpSUJEqDktmJ+qTMTQ5uvF1sohLjlsdpmDXpkSKiJvOnbBJKrbJObLMa89/xs73pBUd/0sRn9hogOVCbVxu7h//UepvgTcS/jEPOYcaelZaE1VfCRXJfIxqUUTBqYNxflXzUk5YXyWqNuqEykK7DhF4UgKmXkh7nmkPSWzn/AJ5ES4J8nIakAErXmv4u1s66fHJcvyhxs3bezucnbL5WzPewKteogAADRpkRnbwtpls9M1yqKH0dNavqHfaMfuZT048CuRWqbhODaY+2Rf/PjcWiQEjA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VmdSjd/tl8Li714jTZ1Zo92GSPmnUzoFrLqDOyY2SkQT5QDJHdX7nRV2RYxpDMwIWqsv3onCLMzdXTJ2je6J6KwtwdYxNm6n+GsMawZdo9nrV20Fol9wCbwdEJwmJpgZHPvx6Dss0gRxM4pqRyL99hNEntlbRp5NfKms79AKDjicjKpDYCOnv6qkcAFQXO1vqfLTPNu4Rd2y2TBtmEoduZuOHrRJ+6eZZfQT0QtH4BfJl23sFOQgQpJ+Yr7W1ysNXs4WD11FmJKD2+lt2TFirJ7qaWUy20pW2OA4r5EQRo0sTjpxYO43ppQ+6nH+eJW5pWnmHLLGGqm9R17SRSAbFQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 27 Feb 2023 10:47:11 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 24.02.2023 22:33, Andrew Cooper wrote:
> But I think we want to change tact slightly at this point, so I'm not
> going to do any further tweaking on commit.
>
> Next, I think we want to rename asm/hvm/svm/svm.h to asm/hvm/svm.h,
> updating the non-SVM include paths as we go. Probably best to
> chain-include the other svm/hvm/svm/*.h headers temporarily, so we've
> only got one tree-wide cleanup of the external include paths.
>
> Quick tangent - I will be making all of that cpu_has_svm_*
> infrastructure disappear by moving it into the normal CPUID handling,
> but I've not had sufficient time to finish that yet.
>
> Next, hvm/svm/nestedsvm.h can merge straight into hvm/svm.h, and
> disappear (after my decoupling patch has gone in).
Why would you want to fold hvm/svm/nestedsvm.h into hvm/svm/svm.h?
The latter doesn't use anything from the former, does it? And it
also doesn't include it right now. Since nested is still far from
being properly functional, and since most guests don't use it, I'd
rather see struct nestedvcpu's union to become a union of two
pointers, which get space allocated only for nested-enabled guests.
Yet it's only the use there which makes it necessary to globally
expose the struct right now.
Jan
|
