[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2 12/15] x86/vmx: guard access to cpu_has_vmx_* in common code


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>
  • Date: Wed, 29 May 2024 13:58:06 +0300
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=X9ZdFziTF2PFL+iFVJdyZyFKsVyqu0l3iLUiWDYqcVE=; b=TrPbaWvigwsta+TbVRokoJbsfY4WEVbjQu+EeYu/Wqbgs1eHzsHgFVa6PoiIFDckwBquxQkcdzvRFk80ZJW1Ku4J0ClGUM6r2tGlcbhmFofirLRnKVylznTDrwjqcpSJCxhi90jdGkCJaIm1Dx58zxDCDtKUJPoKkgyPETqGjL/IAahv9n5o79n1bv02sUvfp7noYwsMku7HALCJHT0mkJNjzXAI+m89YoYpDwFSmABuX4yt9bbdoSbnCa1FXvKSYtF2e0pTiGHnuEOngDrooRfJZVMcONFtMB+o4hkDL8d+iLQod8VXkJGC32ldO5rHR3ryJfzgTWHrfbgQk4T1+w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZkD5/7oeVDZ9rHxeW6bDTYfDrWv+Jum0kzvmRX+ujoyAUj/rgA8HseLH6dwo1hqp6hjhwZIP7o14rNSjRzqja+7cuvE+RrkUrCsYRWPmYK4fD8X2YxYcrCnoWoAt0oIHSeE19DkdklUrs1orIp8dvwyK+E13vjEvWH4X2gUWFdc8ezn8sWfq36Y713Vo8KQM5o9kO7XcNPYOYWL1lQtGuPbrVemCl3cHOkcWC4bzxJoUWjN04GxmrXVyAvv98lbvyoVy0mwZoIu5Z5Plw5zvqr7kJtQ4Cz5kXABQ3WhoM20R9MvIg+ig8B2VBrA4jRTDNXBEQkfLFEJdtoYJc71v0w==
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Wed, 29 May 2024 10:58:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

16.05.24 10:32, Jan Beulich:
On 16.05.2024 02:50, Stefano Stabellini wrote:
On Wed, 15 May 2024, Sergiy Kibrik wrote:
There're several places in common code, outside of arch/x86/hvm/vmx,
where cpu_has_vmx_* get accessed without checking if VMX present first.
We may want to guard these macros, as they read global variables defined
inside vmx-specific files -- so VMX can be made optional later on.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>
CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Jan Beulich <jbeulich@xxxxxxxx>
---
Here I've tried a different approach from prev.patches [1,2] -- instead of
modifying whole set of cpu_has_{svm/vmx}_* macros, we can:
  1) do not touch SVM part at all, because just as Andrew pointed out they're
used inside arch/x86/hvm/svm only.
  2) track several places in common code where cpu_has_vmx_* features are
checked out and guard them using cpu_has_vmx condition
  3) two of cpu_has_vmx_* macros being used in common code are checked in a bit
more tricky way, so instead of making complex conditionals even more 
complicated,
we can instead integrate cpu_has_vmx condition inside these two macros.

This patch aims to replace [1,2] from v1 series by doing steps above.

[..]

I am missing some of the previous discussions but why can't we just fix
all of the cpu_has_vmx_* #defines in vmcs.h to also check for
cpu_has_vmx?

That seems easier and simpler than to add add-hoc checks at the invocations?

I'd like to take the question on step further: Following 0b5f149338e3
("x86/HVM: hide SVM/VMX when their enabling is prohibited by firmware"),
is this change needed at all? IOW is there a path left where cpu_has_vmx
may be false, by any cpu_has_vmx_* may still yield true?


This change is about exec control variables (vmx_secondary_exec_control, vmx_pin_based_exec_control etc) not been built, because they're in vmx code, but accessed in common code. The description is probably unclear about that. Also build issues related to VMX can be solved differently, without touching cpu_has_vmx_* macros and related logic at all. I can move exec control variables from vmcs.c to common hvm.c, this would be simpler change and directly related to problem that I'm having.

  -Sergiy



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.