iated.
yes, sure
On 9/2/25 05:41, Jan Beulich wrote:
On 01.09.2025 12:52, Sergiy Kibrik wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
If unsure, say Y.
+config XSM_FLASK_SIDTABLE_ORDER
+ int "Maximum number o
decent and predictable amounts. This patch provides a configuration
option to impose such a limit.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
changes in v2:
- use one config option instead of 2
- use base 2 exponent
patch v1 here:
https://lore.kernel.org/xen-devel/20250822095123.998313
29.08.25 14:44, Jan Beulich:
On 29.08.2025 13:33, Sergiy Kibrik wrote:
25.08.25 15:00, Jan Beulich:
On 22.08.2025 11:51, Sergiy Kibrik wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
file th
25.08.25 15:00, Jan Beulich:
On 22.08.2025 11:51, Sergiy Kibrik wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
I wonder whether we wouldn't better move XSM's controls to a dedicated Kconfig
file there.
you mean something like Kconfig.xsm in the same common/ directory
decent and predictable amounts. This patch provides a configuration
option to impose such a limit.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
After RFC patch discussion it's been suggested to use Kconfig option
instead of estimation of sidtable size at build time:
https://lore.kerne
15.08.25 15:20, Jan Beulich:
On 15.08.2025 12:23, Sergiy Kibrik wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -238,6 +238,15 @@ loops for Queued Invalidation completions.**
Specify a maximum amount of available memory, to which Xen will clamp
the
15.08.25 14:43, Andrew Cooper:
On 15/08/2025 12:21 pm, Andrew Cooper wrote:
On 15/08/2025 11:23 am, Sergiy Kibrik wrote:
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index a75b6c9301..9044827e78 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs
some performance penalty here.
Signed-off-by: Sergiy Kibrik
---
This RFC presents one possible way to hard limit the memory AVC can consume.
With current implementation of AV cache threshold reclaim of memory only starts
after threshold has been reached, and we only reclaim up to AVC_CACHE_RECLAIM=16
nodes
01.07.25 13:42, Jan Beulich:
On 30.06.2025 10:55, Sergiy Kibrik wrote:
Currently Xen lacks a defined largest number of security IDs it can potentially
use. The number of SIDs are naturally limited by number of security contexts
provided by a given security policy, i.e. how many combination of
ement
of UINT_MAX limit. Also it can be used later to pre-allocate sidtable at boot
and avoid runtime entries allocation altogether.
Signed-off-by: Sergiy Kibrik
---
This RFC presents a concept of estimating a max possible sidtable size.
Can we discuss how valid this concept is? Currently it yield
Add config option HVM_VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related macros.
Having this option may be beneficial by reducing code footprint for systems
that are not using Hyper-V.
Signed-off-by: Sergiy Kibrik
CC: Alejandro
Check whether nested HVM is enabled for domain before calling nestedhvm_vcpu_*()
and other not already guarded nestedhvm functions.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/hvm.c | 6 --
xen/arch/x86/hvm/svm/asid.c | 2 +-
xen/arch/x86/hvm/svm/svm.c | 6 +++---
3 files
Introduce NESTEDHVM config option that controls nested virtualization in both
SVM & VMX code. The option is for reduction of dead code on systems that
aren't intended to run in nested mode.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Kconfig | 5 +
xen/arc
This is private header for SVM code, comment in header and file's changelog
suggest that intended name was svm/nestedsvm.h, so perhaps a small mistake here.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/svm/intr.c | 2 +-
xen/arch/x86/hvm/svm/{nested
There's a macro for this, might improve readability a bit & save a bit of space.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
xen/arch/x86/hvm/svm/svm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/nest
modify the same code I've decided to include them too.
-Sergiy
Sergiy Kibrik (4):
x86:svm: use nsvm_efer_svm_enabled() to check guest's EFER.SVME
x86:svm: rename svm/nestedhvm.h -> svm/nestedsvm.h
x86:hvm: guard calls to nestedhvm routines
x86:hvm: make nestedhvm support
hi Alejandro,
17.03.25 11:19, Alejandro Vallejo:
[..]
endif
+config HVM_VIRIDIAN
+ bool "Viridian enlightenments support" if EXPERT
+ depends on HVM
+ default y
+
I don't see why this should be gated by EXPERT, provided a
suitable (now absent) help
Add config option HVM_VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related macros.
Having this option may be beneficial by reducing code footprint for systems
that are not using Hyper-V.
Signed-off-by: Sergiy Kibrik
---
xen/arch
14.03.25 13:11, Jan Beulich:
On 14.03.2025 06:23, Sergiy Kibrik wrote:
Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.
No functional change here, as
Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
feature, with mem_access & monitor depending on it.
Suggested-by: Tamas K Lengyel
Acked-by: Tamas K Lengyel
Signed-off-by: Sergiy Kibrik
---
change
abled.
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
Reviewed-by: Ayan Kumar Halder
CC: Jan Beulich
CC: Tamas K Lengyel
---
changes in v4:
- vm_event_domctl stub returns -EOPNOTSUPP
changes in v3:
- add dependency MEM_PAGING -> VM_EVENT
- monitor_domctl() stub
Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.
No functional change here, as VM_EVENT depends on HVM.
Acked-by: Jan Beulich
Signed-off-by: Sergiy Kibrik
onfig option begins to extend beyond actual
mem_access code it has been suggested to rename it into VM_EVENT, as a more
general option controlling mem_access, vm_event and monitor code.
v3 series:
https://lore.kernel.org/xen-devel/cover.1741687645.git.sergiy_kib...@epam.com/
-Sergiy
Sergiy Kibr
11.03.25 15:39, Tamas K Lengyel:
On Tue, Mar 11, 2025 at 7:59 AM Jan Beulich wrote:
On 11.03.2025 11:27, Sergiy Kibrik wrote:
From: Stefano Stabellini
Extend coverage of CONFIG_VM_EVENT option and make the build of VM events
and monitoring support optional. Also make MEM_PAGING option depend
11.03.25 14:01, Jan Beulich:
On 11.03.2025 11:23, Sergiy Kibrik wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -92,7 +92,7 @@ config HAS_VMAP
config MEM_ACCESS_ALWAYS_ON
bool
-config MEM_ACCESS
+config VM_EVENT
def_bool MEM_ACCESS_ALWAYS_ON
prompt
Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.
No functional change here, as VM_EVENT depends on HVM.
Acked-by: Jan Beulich
Signed-off-by: Sergiy Kibrik
abled.
CC: Jan Beulich
CC: Tamas K Lengyel
Reviewed-by: Ayan Kumar Halder
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
---
changes in v3:
- add dependency MEM_PAGING -> VM_EVENT
- monitor_domctl() stub returns -EOPNOTSUPP
changes in v2:
- rename CONFIG_ME
Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
feature, with mem_access & monitor depending on it.
CC: Jan Beulich
Suggested-by: Tamas K Lengyel
Acked-by: Tamas K Lengyel
Signed-off-by: Se
https://lore.kernel.org/xen-devel/cover.1737452864.git.sergiy_kib...@epam.com/
-Sergiy
Sergiy Kibrik (2):
xen: kconfig: rename MEM_ACCESS -> VM_EVENT
x86:monitor: control monitor.c build with CONFIG_VM_EVENT option
Stefano Stabellini (1):
xen: mem_access: conditionally compile vm_event.c &am
efano Stabellini
Signed-off-by: Sergiy Kibrik
---
changes in v2:
- rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT
- tags
---
xen/arch/arm/Makefile | 4 ++--
xen/arch/arm/vsmc.c| 3 ++-
xen/common/Makefile| 4 ++--
xen/include/xen/monitor.h | 9 +
xen/include/xen/vm
Following the renaming of Xen build option.
Signed-off-by: Sergiy Kibrik
---
automation/eclair_analysis/xen_arm_config | 2 +-
automation/eclair_analysis/xen_x86_config | 2 +-
automation/gitlab-ci/build.yaml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a
Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.
No functional change here, as VM_EVENT depends on HVM.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86
Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
feature, with mem_access & monitor depending on it.
Suggested-by: Jan Beulich
Suggested-by: Tamas K Lengyel
Signed-off-by: Sergiy Kibrik
---
op
onfig option begins to extend beyond actual
mem_access code it has been suggested to rename it into VM_EVENT, as a more
general option controlling mem_access, vm_event and monitor code.
v1 patch here:
https://lore.kernel.org/xen-devel/20241230063051.3332332-1-sergiy_kib...@epam.com/
-Sergiy
S
07.01.25 10:46, Jan Beulich:
On 06.01.2025 19:09, Tamas K Lengyel wrote:
On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich wrote:
On 06.01.2025 15:05, Tamas K Lengyel wrote:
On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
On 30.12.2024 07:30, Sergiy Kibrik wrote:
From: Stefano Stabellini
From: Stefano Stabellini
Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
and monitoring support optional.
This is to reduce code size on Arm when this option isn't enabled.
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
---
xen/arch/arm/Mak
19.12.24 09:55, Jan Beulich:
On 18.12.2024 11:00, Sergiy Kibrik wrote:
17.12.24 15:02, Jan Beulich:
On 17.12.2024 12:47, Sergiy Kibrik wrote:
Allow to build ARM configuration with support for initializing hardware domain.
On ARM it is only possible to start hardware domain in multiboot mode
18.12.24 12:38, Julien Grall:
Are you sure this patch is sufficient to use the late hwdom feature?
Looking at the code, to enable the late hwdom, the user needs to
provide a domid on the command line. But AFAICT, there is no way to
provide a domain ID in the DOM0LESS case...
I append "har
18.12.24 12:05, Julien Grall:
On 18/12/2024 09:52, Sergiy Kibrik wrote:
hi Julien,
17.12.24 14:42, Julien Grall:
Hi,
Can you clarify why this is an RFC?
The code for LATE_HWDOM support on ARM seems to be already in place
and working, yet I'm not sure that such configuration is rea
Signed-off-by: Sergiy Kibrik
---
This change has been suggested by Jan some time ago during review of another
series, here's link to discussion:
https://lore.kernel.org/xen-devel/952701cd-83d8-4c1f-9f38-ee63ba582...@suse.com/
---
xen/arch/x86/hvm/ioreq.c | 2 +-
xen/include/xen/ioreq.h | 2
It should be CONFIG_ARCH_VCPU_IOREQ_COMPLETION (as in Kconfig) and not
misspelled CONFIG_VCPU_ARCH_IOREQ_COMPLETION.
Bug introduced by:
979cfdd3e5 ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX
configurations
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/ioreq.c | 2 +-
xen
ig
option, so this is reflected by a dependency in kconfig and Makefiles are
changed accordingly.
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
CC: Andrew Cooper
CC: Jan Beulich
---
changes in v2:
- SYSCTL & DOMCTL config option dependency on !PV_SHIM_EXCLUSIVE
- replace
18.12.24 03:17, Daniel P. Smith:
On 17/12/2024 11:47, Sergiy Kibrik wrote:
Allow to build ARM configuration with support for initializing
hardware domain.
On ARM it is only possible to start hardware domain in multiboot
mode, so
dom0less support is required. This is reflected by dependency on
17.12.24 15:02, Jan Beulich:
On 17.12.2024 12:47, Sergiy Kibrik wrote:
Allow to build ARM configuration with support for initializing hardware domain.
On ARM it is only possible to start hardware domain in multiboot mode, so
dom0less support is required.
I don't follow this. Late hwd
iel's comments
regarding XSM later in this thread).
On 17/12/2024 11:47, Sergiy Kibrik wrote:
Allow to build ARM configuration with support for initializing
hardware domain.
On ARM it is only possible to start hardware domain in multiboot mode, so
dom0less support is required. This is re
17.12.24 15:00, Jan Beulich:
On 16.12.2024 12:43, Sergiy Kibrik wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -516,4 +516,31 @@ config TRACEBUFFER
to be collected at run time for debugging or performance analysis.
Memory and execution overhead when not active
-by: Sergiy Kibrik
---
xen/common/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..7368ca8208 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -374,7 +374,7 @@ endchoice
config LATE_HWDOM
bool
able hypercalls:
- domctl, sysctl
- hvm
- physdev
- platform
Some of these options are forced to be configurable only when DOM0LESS is
enabled, so that system won't become accidentally un-bootable when any hypercall
is disabled.
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
C
Introduce config option X86_HVM_STDVGA and make stdvga emulation driver
configurable so it can be disabled on systems that don't need it.
Suggested-by: Roger Pau Monné # approach
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
CC: Jan Beulich
---
changes in v3:
- changed c
Roger Pau Monné # approach
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
CC: Jan Beulich
---
changes in v3:
- changed config option's description
- fixed bug in emulation_flags_ok()
- modified build-time checks of X86_EMU_ALL vs XEN_X86_EMU_ALL
- tags
changes in v2:
- updated de
created if it requires devices that had been
disabled.
Minor changes since previous series, details provided in per-patch changelogs.
v2 series here:
https://lore.kernel.org/xen-devel/cover.1730887415.git.sergiy_kib...@epam.com/
-Sergiy
Sergiy Kibrik (2):
x86/hvm: introduce config option f
11.11.24 14:05, Jan Beulich:
[..]>>> What exactly was it that Roger suggested? I don't think it was
what the patch
does overall, but just _how_ it is being done? That makes quite a bit of a
difference, as the former could be read as kind of an implicit ack to what is
being done here (and also in
11.11.24 11:51, Jan Beulich:
On 06.11.2024 11:14, Sergiy Kibrik wrote:
Introduce config option X86_HVM_PMTIMER and make pmtimer emulation driver
configurable and possible to disable on systems that don't need it.
Option X86_X86_HVM_PMTIMER depends on HVM option, because this driver is pa
Introduce config option X86_HVM_STDVGA and make stdvga emulation driver
configurable so it can be disabled on systems that don't need it.
Suggested-by: Roger Pau Monné
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
changes in v2:
- updated description
- renamed config option X86_S
06.11.24 12:14, Sergiy Kibrik:
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 78a13e6812..b340818ee2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -742,11 +742,16 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
static bool
u Monné
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
changes in v2:
- updated description
- renamed config option X86_PMTIMER -> X86_HVM_PMTIMER & moved related
Kconfig changes to this patch
- define X86_EMU_PM to 0 when !X86_HVM_PMTIMER
- reverted changes to has_vpm() macro
- mo
created if it requires devices that had been
disabled.
Since previous series one patch merged into 2 others and review comments have
been addressed (details are in per-patch changelogs).
v1 series here:
https://lore.kernel.org/xen-devel/cover.1728032664.git.sergiy_kib...@epam.com/
-Sergiy
Ser
option, because these
drivers are part of HVM support code.
Suggested-by: Roger Pau Monné
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Kconfig | 21 +++--
xen/arch/x86/domain.c | 6 ++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/Kconfig
Introduce config option X86_STDVGA so that stdvga emulation driver can later be
made configurable and be disabled on systems that don't need it.
As a first step the option is hidden from user. No functional changes intended.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
xen/arc
Introduce config option X86_PMTIMER so that pmtimer emulation driver can later
be made configurable and be disabled on systems that don't need it.
As a first step the option is hidden from user, thus not making any functional
changes here.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
sergiy_kib...@epam.com/
2.
https://lore.kernel.org/xen-devel/20240916063757.990070-1-sergiy_kib...@epam.com/
Sergiy Kibrik (3):
x86/hvm: introduce config option for ACPI PM timer
x86/hvm: introduce config option for stdvga emulation
x86/hvm: make ACPI PM & stdvga emulation optional
30.09.24 14:33, Andrew Cooper:
Options are dependant on HVM option, because pmtimer & stdvga drivers
are part of HVM support code.
At the same time these options are allowed to be de-selected when PV/PVH
enabled, because only PV/PVH domains can be created when stdvga or
pmtimer are disabled
But
27.09.24 12:44, Jan Beulich:
(probably with X86_PMTIMER option depending on PV)
HVM you mean?
I wanted to do it like this:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -386,7 +386,7 @@ config ALTP2M
If unsure, stay with defaults.
config X86_PMTIMER
- bool "AC
23.09.24 13:01, Jan Beulich:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -758,6 +758,9 @@ static bool emulation_flags_ok(const struct domain
*d, uint32_t emflags)
(X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
emflags != X86_EMU_LAPIC )
lated sysctls XEN_SYSCTL_psr_cmt_op &
XEN_SYSCTL_psr_alloc are off as well.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
CC: Andrew Cooper
---
v5 patch here:
https://lore.kernel.org/xen-devel/20240918091517.1200080-1-sergiy_kib...@epam.com/
changes in v6:
- rename option PSR -> X86_PSR
calls:
- domctl, sysctl
- hvm
- physdev
- platform
Options are forced to be configurable only when DOM0LESS is enabled, so that
system won't become accidentally un-bootable when any hypercall is disabled.
Signed-off-by: Stefano Stabellini
Signed-off-by: Sergiy Kibrik
---
xen/arch/ar
18.09.24 12:41, Roger Pau Monné:
On Wed, Sep 18, 2024 at 12:29:39PM +0300, Sergiy Kibrik wrote:
16.09.24 22:57, Stefano Stabellini:
On Mon, 16 Sep 2024, Roger Pau Monné wrote:
On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
Introduce config option X86_PMTIMER so that pmtimer
16.09.24 22:57, Stefano Stabellini:
On Mon, 16 Sep 2024, Roger Pau Monné wrote:
On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
Introduce config option X86_PMTIMER so that pmtimer driver can be disabled on
systems that don't need it.
Same comment as in the VGA patch, you
Currently mwait_idle driver in Xen only implements support for Intel CPUs.
Thus in order to reduce dead code in non-Intel build configurations it can
be made explicitly dependant on CONFIG_INTEL option.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
v1 patch here:
https://lore.kernel.org/xen
sctls XEN_SYSCTL_psr_cmt_op &
XEN_SYSCTL_psr_alloc are off as well.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
CC: Andrew Cooper
---
v4 patch here:
https://lore.kernel.org/xen-devel/20240903072614.291048-1-sergiy_kib...@epam.com/
changes in v5:
- simplify psr_cmt_enabled()
- move P
Introduce config option X86_PMTIMER so that pmtimer driver can be disabled on
systems that don't need it.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Kconfig | 9 +
xen/arch/x86/hvm/Makefile | 2 +-
xen/arch/x86/include/asm/acpi.h| 5 +
xen/arc
12.09.24 12:14, Roger Pau Monné:
Shouldn't Xen report an error if a user attempts to create a domain
with X86_EMU_VGA set in emulation_flags, but stdvga has been built
time disabled?
I'm afraid this can accidentally render the system unbootable, because
it looks like toolstack always sets X86_
09.09.24 17:28, Jan Beulich:
--- a/xen/arch/x86/include/asm/cpuidle.h
+++ b/xen/arch/x86/include/asm/cpuidle.h
@@ -15,7 +15,14 @@ extern void (*lapic_timer_on)(void);
extern uint64_t (*cpuidle_get_tick)(void);
+#ifdef CONFIG_INTEL
int mwait_idle_init(struct notifier_block *nfb);
+#else
09.09.24 17:24, Jan Beulich:
On 03.09.2024 09:26, Sergiy Kibrik wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -284,6 +284,9 @@ endchoice
config GUEST
bool
+config PSR
+ bool
+
config XEN_GUEST
bool "Xen Guest"
select GUEST
In
Introduce config option X86_STDVGA so that stdvga driver can be disabled on
systems that don't need it.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Kconfig | 10 ++
xen/arch/x86/hvm/Makefile | 2 +-
xen/arch/x86/include/asm/hvm/io.h | 5 +
3 files ch
Currently mwait_idle driver in Xen only implements support for Intel CPUs.
Thus in order to reduce dead code in non-Intel build configurations it can
be made explicitly dependant on CONFIG_INTEL option.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/Makefile | 2 +-
xen/arch/x86
Make the Intel-specific Trusted Boot implementation dependant on general Intel
CPU support.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index d0aaf359eb..89d17e7f2c 100644
CONFIG_PSR introduced, which selected by CONFIG_INTEL.
When !PSR then PSR-related sysctls XEN_SYSCTL_psr_cmt_op &
XEN_SYSCTL_psr_alloc are off as well.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
CC: Andrew Cooper
---
v3 patch here:
https://lore.kernel.org/xen-devel/20240829090559.14924
19.08.24 15:36, Jan Beulich:
On 16.08.2024 13:19, Sergiy Kibrik wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -919,7 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v)
* Possibly clear previous guest selection of SSBD if set. Note that
19.08.24 11:53, Jan Beulich:
On 16.08.2024 13:10, Sergiy Kibrik wrote:
--- a/xen/arch/x86/Kconfig.cpu
+++ b/xen/arch/x86/Kconfig.cpu
@@ -10,6 +10,25 @@ config AMD
May be turned off in builds targetting other vendors. Otherwise,
must be enabled for Xen to work suitably on
Platform Shared Resource feature is available for certain Intel's CPUs only,
hence can be put under CONFIG_INTEL build option.
When !INTEL then PSR-related sysctls XEN_SYSCTL_psr_cmt_op &
XEN_SYSCTL_psr_alloc are off as well.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
v2 p
unknowingly disabling virtualization support, make the
controls user selectable only if EXPERT is enabled.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
changes in v6:
- "default y"
version of arch_vcpu_ioreq_completion() moved to common
header).
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
Acked-by: Jan Beulich
CC: Julien Grall
---
changes in v7:
- comment in Kconfig adjusted
- fixed patch description
- updated tags
changes in v6:
- ren
These are final 2 patches of the series for making VMX/SVM support in Xen
configurable:
https://lore.kernel.org/xen-devel/cover.1723110344.git.sergiy_kib...@epam.com/
Minor changes comparing to v6, changelogs are provided per-patch.
-Sergiy
Xenia Ragiadakou (2):
ioreq: do not build arch_vc
Similar to making Intel CPU support optional -- as we've got CONFIG_AMD option
now, we can put arch/x86/cpu/amd.c under it and make it possible to build
Xen without AMD CPU support. One possible use case is to dispose of dead code
in Intel-only systems.
Signed-off-by: Sergiy Kibrik
CC
With specific config option INTEL in place and most of the code that depends
on intel.c now can be optionally enabled/disabled it's now possible to put
the whole intel.c under INTEL option as well. This will allow for a Xen build
without Intel CPU support.
Signed-off-by: Sergiy Kibri
iables or feature bits it should be
safe to do.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
xen/arch/x86/spec_ctrl.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 75a4177a75..ba6c3e80d2 100644
Do not compile handlers of guest access to AMD-specific MSRs when CONFIG_AMD=n.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
xen/arch/x86/msr.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 289cf10b78..4567de7fc8 100644
--- a/xen/arch
These options aim to represent what's currently supported by Xen, and later
to allow tuning for specific platform(s) only.
HYGON and SHANGHAI options depend on AMD and INTEL as there're build
dependencies on support code for AMD and Intel CPUs respectively.
Signed-off-by: Sergiy
ssion here:
https://lore.kernel.org/xen-devel/cover.1723196909.git.sergiy_kib...@epam.com/
Changelogs are provided per-patch.
-Sergiy
Sergiy Kibrik (5):
x86/Kconfig: introduce CENTAUR, HYGON & SHANGHAI config options
x86/amd: configurable handling of AMD-specific MSRs access
13.08.24 10:31, Jan Beulich:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -111,7 +111,17 @@ void ioreq_domain_init(struct domain *d);
int ioreq_server_dm_op(struct xen_dm_op *op, struct domain *d, bool
*const_op);
bool arch_ioreq_complete_mmio(void);
+
+#ifdef CONFIG_VC
13.08.24 10:40, Jan Beulich:
I'm okay-ish with the simple stubbing out for update_mcu_opt_ctrl(), but
set_in_mcu_opt_ctrl() imo requires more work. The call sites in spec_ctrl.c
shouldn't give the wrong impression of having some effect. Imo in
init_speculation_mitigations() an #endif wants to mov
13.08.24 10:50, Jan Beulich:
On 09.08.2024 12:11, Sergiy Kibrik wrote:
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -158,13 +158,21 @@
#define is_zen4_uarch() boot_cpu_has(X86_FEATURE_AUTO_IBRS)
struct cpuinfo_x86;
+#ifdef CONFIG_AMD
int
12.08.24 15:24, Alejandro Vallejo:
On Mon Aug 12, 2024 at 10:58 AM BST, Jan Beulich wrote:
On 12.08.2024 11:40, Sergiy Kibrik wrote:
09.08.24 13:36, Alejandro Vallejo:
On Fri Aug 9, 2024 at 11:09 AM BST, Sergiy Kibrik wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
09.08.24 13:36, Alejandro Vallejo:
On Fri Aug 9, 2024 at 11:09 AM BST, Sergiy Kibrik wrote:
With specific config option INTEL in place and most of the code that depends
on intel.c now can be optionally enabled/disabled it's now possible to put
the whole intel.c under INTEL option as well.
Similar to making Intel CPU support optional -- as we've got CONFIG_AMD option
now, we can put arch/x86/cpu/amd.c under it and make it possible to build
Xen without AMD CPU support. One possible use case is to dispose of dead code
in Intel-only systems.
Signed-off-by: Sergiy Kibrik
---
xen
With specific config option INTEL in place and most of the code that depends
on intel.c now can be optionally enabled/disabled it's now possible to put
the whole intel.c under INTEL option as well. This will allow for a Xen build
without Intel CPU support.
Signed-off-by: Sergiy Kibrik
---
tuned for specific platform -- by reducing dead
code that won't ever be executed on that platform anyway.
Note: this series (namely its Intel part) depends on optional PSR support patch:
https://lore.kernel.org/xen-devel/20240801084453.1163506-1-sergiy_kib...@epam.com/
-Sergiy
Sergiy Kibr
unknowingly disabling virtualization support, make the
controls user selectable only if EXPERT is enabled.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
changes in v6:
- "default y"
version of arch_vcpu_ioreq_completion() moved to common header).
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
CC: Julien Grall
CC: Jan Beulich
---
changes in v6:
- rename option ARCH_IOREQ_COMPLETION -> ARCH_VCPU_IOREQ_COMPLETION
- put a comment with brief option's descrip
1 - 100 of 295 matches
Mail list logo
