On Sun, 02 Jun 2024 17:37:28 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/block/xen-blkback/xen-blkback.o
>
> Add the missing invocation of the MODULE_DESCRIPTION() macro.
>
>
Applied, thanks!
[1/1] xen
flight 186745 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186745/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186739
test-amd64-amd64-xl-qemuu-ws16-amd64
On Tue, Jul 09, 2024 at 09:08:18PM +0200, Petr Tesařík wrote:
> I'm confused. If you're not a big fan, why are we effectively adding
> them to more places now than before the patch?
Because I didn't want to second guess the patch author too much.
flight 186742 linux-linus real [real]
flight 186747 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186742/
http://logs.test-lab.xenproject.org/osstest/logs/186747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186746/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f91211049c1522f7db2ae8f7a509ac270868d0e9
baseline version:
ovmf 7aaee521a1966e71a51b7
Replace a comma between expression statements by a semicolon.
Signed-off-by: Chen Ni
---
arch/arm/xen/p2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 309648c17f48..9da57a5b81c7 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/
On Tue, 9 Jul 2024, Alejandro Vallejo wrote:
> On Tue Jul 9, 2024 at 1:21 PM BST, Michal Orzel wrote:
> > Switch to using https://gitlab.com/xen-project/imagebuilder.git which
> > should be considered official ImageBuilder repo.
> >
> > Signed-off-by: Michal Orzel
> > ---
> > automation/scripts/q
flight 186739 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186739/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186735
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 186743 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186743/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 6/2/2024 5:37 PM, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/block/xen-blkback/xen-blkback.o
>
> Add the missing invocation of the MODULE_DESCRIPTION() macro.
>
> Signed-off-by: Jeff Johnson
> ---
> drivers/
flight 186744 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186744/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7aaee521a1966e71a51b71b73f5e3bbddb6faa31
baseline version:
ovmf 426b69830efff788f2c17
On Tue, 9 Jul 2024 13:18:12 +0200
Christoph Hellwig wrote:
> On Tue, Jul 09, 2024 at 11:10:13AM +0200, Petr Tesařík wrote:
> > Reviewed-by: Petr Tesarik
>
> Thanks.
>
> >
> > OK, so __swiotlb_find_pool() is now always declared (so the code
> > compiles), but if CONFIG_SWIOTLB_DYNAMIC=n, it
flight 186741 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 09/07/2024 4:34 pm, Anthony PERARD wrote:
> On Tue, Jul 09, 2024 at 02:49:57PM +0100, Andrew Cooper wrote:
>> Hello,
>>
>> I'm trying to investigate why stubdom/ is fatally failing now with a
>> rebuilt ArchLinux container (GCC 14).
>>
>> It is ultimately:
>>
>>> ../../../../../newlib-1.16.0/new
On Tue, Jul 9, 2024 at 12:12 PM Jan Beulich wrote:
>
> On 09.07.2024 17:37, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 6:47 PM Tamas K Lengyel wrote:
> >>
> >> This target enables integration into oss-fuzz. Changing invalid input
> >> return
> >> to -1 as values other then 0/-1 are reser
On 09.07.2024 17:37, Tamas K Lengyel wrote:
> On Tue, Jun 25, 2024 at 6:47 PM Tamas K Lengyel wrote:
>>
>> This target enables integration into oss-fuzz. Changing invalid input return
>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
>> missing __wrap_vsnprintf wrapper
On 09.07.2024 11:34, Nicola Vetrini wrote:
> --- a/xen/include/xen/bitmap.h
> +++ b/xen/include/xen/bitmap.h
> @@ -103,18 +103,16 @@ extern int bitmap_allocate_region(unsigned long
> *bitmap, int pos, int order);
> #define bitmap_switch(nbits, zero, small, large) \
> u
I want to eventually reach a position in which the FPU state can be allocated
from the domheap and hidden via the same core mechanism proposed in Elias'
directmap removal series. Doing so is complicated by the presence of 2 aliased
pointers (v->arch.fpu_ctxt and v->arch.xsave_area) and the rather c
Making the union non-anonymous causes a lot of headaches, because a lot of code
relies on it being so, but it's possible to make a typedef of the anonymous
union so all callsites currently relying on typeof() can stop doing so directly.
This commit creates a `fpusse_t` typedef to the anonymous uni
fpu_ctxt is either a pointer to the legacy x87/SSE save area (used by FXSAVE) or
a pointer aliased with xsave_area that points to its fpu_sse subfield. Such
subfield is at the base and is identical in size and layout to the legacy
buffer.
This patch merges the 2 pointers in the arch_vcpu into a si
It's doing too many things at once and there's no clear way of defining what
it's meant to do. This patch splits the function in two.
1. A reset function, parameterized by the FCW value. FCW_RESET means to reset
the state to power-on reset values, while FCW_DEFAULT means to reset to the
Minor refactor to make xstate_all() use a helper rather than poking directly
into the XSAVE header.
No functional change
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/include/asm/xstate.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/includ
flight 186738 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-raw 8 xen-boot fail REGR. vs. 186727
test-armhf-armhf-xl
On Tue, Jun 25, 2024 at 6:47 PM Tamas K Lengyel wrote:
>
> This target enables integration into oss-fuzz. Changing invalid input return
> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz
> build.
On Tue, Jul 09, 2024 at 02:49:57PM +0100, Andrew Cooper wrote:
> Hello,
>
> I'm trying to investigate why stubdom/ is fatally failing now with a
> rebuilt ArchLinux container (GCC 14).
>
> It is ultimately:
>
> > ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
> > implicit de
On 7/9/24 8:55 AM, Jan Beulich wrote:
On 09.07.2024 15:49, Andrew Cooper wrote:
I'm trying to investigate why stubdom/ is fatally failing now with a
rebuilt ArchLinux container (GCC 14).
It is ultimately:
../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
implicit declarat
On 09/07/2024 3:55 pm, Jan Beulich wrote:
> On 09.07.2024 15:49, Andrew Cooper wrote:
>> I'm trying to investigate why stubdom/ is fatally failing now with a
>> rebuilt ArchLinux container (GCC 14).
>>
>> It is ultimately:
>>
>>> ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error
flight 186740 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186740/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 426b69830efff788f2c17a4b920a84d6e08739c8
baseline version:
ovmf 95a6892aacfef6c786205
On 09.07.2024 15:49, Andrew Cooper wrote:
> I'm trying to investigate why stubdom/ is fatally failing now with a
> rebuilt ArchLinux container (GCC 14).
>
> It is ultimately:
>
>> ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
>> implicit declaration of function ‘kill’; di
On 09.07.24 14:39, Andrew Cooper wrote:
Fixes: e536a497545f ("stubdom: Remove caml-stubdom")
Signed-off-by: Andrew Cooper
Reviewed-by: Juergen Gross
Juergen
On Tue, 2024-07-09 at 13:39 +0100, Andrew Cooper wrote:
> Fixes: e536a497545f ("stubdom: Remove caml-stubdom")
> Signed-off-by: Andrew Cooper
> ---
> CC: Juergen Gross
> CC: Oleksii Kurochko
>
> For 4.19. This is additional tidying to a removal in 4.19, which
> will
> otherwise need backportin
[Correct Anthony's email]
~Andrew
On 09/07/2024 2:49 pm, Andrew Cooper wrote:
> Hello,
>
> I'm trying to investigate why stubdom/ is fatally failing now with a
> rebuilt ArchLinux container (GCC 14).
>
> It is ultimately:
>
>> ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
Hello,
I'm trying to investigate why stubdom/ is fatally failing now with a
rebuilt ArchLinux container (GCC 14).
It is ultimately:
> ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
> implicit declaration of function ‘kill’; did you mean ‘_kill’?
> [-Wimplicit-function-dec
Hi all,
Xen 4.19-rc2 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.19.0-rc2
For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.19.0-rc2/xen-4.19.0-rc2.tar.gz
And the signature is at:
https://downloa
On 08.07.2024 13:41, Jiqian Chen wrote:
> Hypercall PHYSDEVOP_map_pirq support to map a gsi into a specific
> pirq or a free pirq, it depends on the parameter pirq(>0 or <0).
> But in current xc_physdev_map_pirq, it set *pirq=index when
> parameter pirq is <0, it causes to force all cases to be map
On 08.07.2024 13:41, Jiqian Chen wrote:
> Some type of domains don't have PIRQs, like PVH, it doesn't do
> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
> to guest base on PVH dom0, callstack
> pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
> domain_pirq_to_irq, becau
On 2024-07-09 06:56, Jürgen Groß wrote:
On 09.07.24 09:01, Jan Beulich wrote:
On 09.07.2024 08:36, Jürgen Groß wrote:
On 09.07.24 08:24, Jan Beulich wrote:
On 08.07.2024 23:30, Jason Andryuk wrote:
From the backtrace, it looks like the immediate case is just
trying to
read a 4-byte versio
On Tue Jul 9, 2024 at 1:21 PM BST, Michal Orzel wrote:
> Switch to using https://gitlab.com/xen-project/imagebuilder.git which
> should be considered official ImageBuilder repo.
>
> Signed-off-by: Michal Orzel
> ---
> automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
> automation/scripts/
Fixes: e536a497545f ("stubdom: Remove caml-stubdom")
Signed-off-by: Andrew Cooper
---
CC: Juergen Gross
CC: Oleksii Kurochko
For 4.19. This is additional tidying to a removal in 4.19, which will
otherwise need backporting if it misses 4.19.
---
config/Stubdom.mk.in | 3 ---
1 file changed, 3
Switch to using https://gitlab.com/xen-project/imagebuilder.git which
should be considered official ImageBuilder repo.
Signed-off-by: Michal Orzel
---
automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
automation/scripts/qemu-smoke-dom0-arm64.sh | 2 +-
automation/scripts/qemu-smoke
On Tue, Jul 09, 2024 at 11:48:08AM +, Michael Kelley wrote:
> Your tweaks look fine to me. Evidently I misunderstood your
> preference in our previous exchange about #ifdef vs. IS_ENABLED()
> in swiotlb_find_pool(), and the effect on dma_uses_io_tlb.
Actually I actively mislead you. Yes, I pr
From: Christoph Hellwig Sent: Monday, July 8, 2024 11:26 PM
>
> Hi Michael,
>
> I've applied this, but I've made a few changes before that directly as
> we're getting close to the end of the merge window.
>
> Most of it is very slight formatting tweaks, but I've also kept the
> dma_uses_io_tlb
On 09.07.2024 13:11, Alejandro Vallejo wrote:
> I'll pitch in, seeing as I created the GitLab ticket.
>
> On Tue Jul 9, 2024 at 7:40 AM BST, Jan Beulich wrote:
>> On 08.07.2024 17:42, Matthew Barnes wrote:
>>> Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
>>> startup.
>>>
>>> Th
On 09.07.2024 13:21, Alejandro Vallejo wrote:
> On Mon Jul 1, 2024 at 9:57 AM BST, Jan Beulich wrote:
>> On 26.06.2024 11:28, Federico Serafini wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -916,6 +916,7 @@ get_page_from_l1e(
>>> return 0;
>>> d
On Mon Jul 1, 2024 at 9:57 AM BST, Jan Beulich wrote:
> On 26.06.2024 11:28, Federico Serafini wrote:
> > Add defensive return statement at the end of an unreachable
> > default case. Other than improve safety, this meets the requirements
> > to deviate a violation of MISRA C Rule 16.3: "An uncondi
On Tue, Jul 09, 2024 at 11:10:13AM +0200, Petr Tesařík wrote:
> Reviewed-by: Petr Tesarik
Thanks.
>
> OK, so __swiotlb_find_pool() is now always declared (so the code
> compiles), but if CONFIG_SWIOTLB_DYNAMIC=n, it is never defined. The
> result still links, because the compiler optimizes away
I'll pitch in, seeing as I created the GitLab ticket.
On Tue Jul 9, 2024 at 7:40 AM BST, Jan Beulich wrote:
> On 08.07.2024 17:42, Matthew Barnes wrote:
> > Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
> > startup.
> >
> > There are efforts to support a maximum of 128 vCPUs, w
On 09.07.24 09:01, Jan Beulich wrote:
On 09.07.2024 08:36, Jürgen Groß wrote:
On 09.07.24 08:24, Jan Beulich wrote:
On 08.07.2024 23:30, Jason Andryuk wrote:
From the backtrace, it looks like the immediate case is just trying to
read a 4-byte version:
[ 44.575541] ucsi_acpi_dsm+
On 08/07/2024 10:21 pm, Shawn Anastasio wrote:
>> +do {
>> +rc = opal_cec_reboot();
>> +
>> +if ( rc == OPAL_BUSY_EVENT )
>> +opal_poll_events(NULL);
>> +
>> +} while ( rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT );
>> +
>> +for ( ;; )
>> +opal_poll_even
On 09.07.2024 12:15, Nicola Vetrini wrote:
> On 2024-07-09 11:40, Jan Beulich wrote:
>> On 09.07.2024 11:34, Nicola Vetrini wrote:
>>> As noticed in the gitlab analyses, deviating bitmap_switch
>>> for Rule 20.7 in this way does not work for ECLAIR.
>>>
>>> Instead, the deviation should be put in t
flight 186735 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186735/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186733
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 186736 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186736/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt
On 2024-07-09 11:40, Jan Beulich wrote:
On 09.07.2024 11:34, Nicola Vetrini wrote:
As noticed in the gitlab analyses, deviating bitmap_switch
for Rule 20.7 in this way does not work for ECLAIR.
Instead, the deviation should be put in the macro invocation.
Why is this? I ask in particular beca
On 09/07/2024 7:31 am, Jan Beulich wrote:
> On 08.07.2024 19:35, Andrew Cooper wrote:
>> Here is a run with these improvements in place:
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/7277624801
>>
>> Jan: I hope to backport this series to 4.18 so we can remove
>> qemu-system-ppc6
On 09.07.2024 11:13, Sergiy Kibrik wrote:
> 03.07.24 18:07, Jan Beulich:
>> On 01.07.2024 14:03, Sergiy Kibrik wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/acpi/cpufreq/acpi.c
>>> @@ -0,0 +1,622 @@
>>> +/*
>>> + * cpufreq.c - ACPI Processor P-States Driver ($Revision: 1.4 $)
>>> + *
>>> + * Co
On 09.07.2024 11:34, Nicola Vetrini wrote:
> As noticed in the gitlab analyses, deviating bitmap_switch
> for Rule 20.7 in this way does not work for ECLAIR.
>
> Instead, the deviation should be put in the macro invocation.
Why is this? I ask in particular because ...
> --- a/xen/include/xen/bit
On 09.07.24 10:36, Andrei Semenov wrote:
Hello,
As been reported by David Morel (mail 4 Jan 2024), our customers experience a
very poor virtual network performances in HVM guests on AMD EPYC platforms.
After some investigations we notices a huge performances drop (perfs divided by
factor of 5)
As noticed in the gitlab analyses, deviating bitmap_switch
for Rule 20.7 in this way does not work for ECLAIR.
Instead, the deviation should be put in the macro invocation.
No functional change.
Fixes: 0dca0f2b9a7e ("automation/eclair: address violations of MISRA C Rule
20.7")
Signed-off-by: Ni
03.07.24 18:14, Jan Beulich:
On 01.07.2024 14:19, Sergiy Kibrik wrote:
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -255,7 +255,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
flight 186734 linux-linus real [real]
flight 186737 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186734/
http://logs.test-lab.xenproject.org/osstest/logs/186737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
03.07.24 18:07, Jan Beulich:
On 01.07.2024 14:03, Sergiy Kibrik wrote:
Separate ACPI driver from generic initialization cpufreq code.
This way acpi-cpufreq can become optional in the future and be disabled
from non-Intel builds.
Other than acpi_register_driver() helper added and clean up a list
On Mon, 8 Jul 2024 12:41:00 -0700
mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> With CONFIG_SWIOTLB_DYNAMIC enabled, each round-trip map/unmap pair
> in the swiotlb results in 6 calls to swiotlb_find_pool(). In multiple
> places, the pool is found and used in one function, and then mus
03.07.24 17:58, Jan Beulich:
On 01.07.2024 10:25, Sergiy Kibrik wrote:
Transactional Synchronization Extensions are supported on certain Intel's
CPUs only, hence can be put under CONFIG_INTEL build option.
The whole TSX support, even if supported by CPU, may need to be disabled via
options, by
Hello,
As been reported by David Morel (mail 4 Jan 2024), our customers
experience a
very poor virtual network performances in HVM guests on AMD EPYC platforms.
After some investigations we notices a huge performances drop (perfs
divided by
factor of 5) starting from 5.10.88 Linux kernel version
On 09.07.2024 09:38, Alessandro Zucchelli wrote:
> On 2024-07-01 16:21, Jan Beulich wrote:
>> On 01.07.2024 15:36, Alessandro Zucchelli wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -260,17 +260,18 @@ $(objtree)/arch/x86/include/asm/asm-macros.h:
>>> $(obj)/asm-macr
On 2024-07-01 16:21, Jan Beulich wrote:
On 01.07.2024 15:36, Alessandro Zucchelli wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -260,17 +260,18 @@ $(objtree)/arch/x86/include/asm/asm-macros.h:
$(obj)/asm-macros.i $(src)/Makefil
$(call filechk,asm-macros.h)
define
On 09.07.2024 09:13, Roger Pau Monné wrote:
> On Tue, Jul 09, 2024 at 08:24:20AM +0200, Jan Beulich wrote:
>> On 08.07.2024 23:30, Jason Andryuk wrote:
>>> On 2024-07-08 05:12, Jan Beulich wrote:
On 08.07.2024 11:08, Roger Pau Monné wrote:
> On Mon, Jul 08, 2024 at 10:37:22AM +0200, Jan Be
On 09.07.2024 08:09, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/hvm/ioreq.h
> +++ b/xen/arch/x86/include/asm/hvm/ioreq.h
> @@ -13,6 +13,11 @@
> #define IOREQ_STATUS_UNHANDLED X86EMUL_UNHANDLEABLE
> #define IOREQ_STATUS_RETRY X86EMUL_RETRY
>
> +#ifdef CONFIG_VMX
> +bool arch_v
On 09.07.2024 07:56, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> Replace cpu_has_vmx check with using_vmx(), so that we do check if functions
> ept_p2m_init() and ept_p2m_uninit() can be called.
I still find this an odd way of putting it. Source code ...
> --- a/xen/arch/x86/mm/p2m-basic.
On 09.07.2024 07:54, Sergiy Kibrik wrote:
> As we now have SVM/VMX config options for enabling/disabling these features
> completely in the build, we need some build-time checks to ensure that vmx/svm
> code can be used and things compile. Macros cpu_has_{svm,vmx} used to be doing
> such checks at
On 09.07.2024 07:52, Sergiy Kibrik wrote:
> Add new option to make altp2m code inclusion optional.
> Currently altp2m implemented for Intel EPT only, so option is dependant on
> VMX.
> Also the prompt itself depends on EXPERT=y, so that option is available
> for fine-tuning, if one want to play ar
On Tue, Jul 09, 2024 at 08:24:20AM +0200, Jan Beulich wrote:
> On 08.07.2024 23:30, Jason Andryuk wrote:
> > On 2024-07-08 05:12, Jan Beulich wrote:
> >> On 08.07.2024 11:08, Roger Pau Monné wrote:
> >>> On Mon, Jul 08, 2024 at 10:37:22AM +0200, Jan Beulich wrote:
> On 08.07.2024 10:15, Jürgen
On 09.07.2024 07:45, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> Introduce two new Kconfig options, SVM and VMX, to allow code
> specific to each virtualization technology to be separated and, when not
> required, stripped.
> CONFIG_SVM will be used to enable virtual machine extensions on p
On 09.07.2024 07:48, Sergiy Kibrik wrote:
> The stub just returns 0 due to implementation of p2m_get_mem_access() for
> x86 & ARM expects it to be 0 when altp2m not active or not implemented.
>
> The separate stub is favoured over dynamic check for alt2pm availability
> inside regular altp2m_vcpu
On 09.07.2024 07:50, Sergiy Kibrik wrote:
> Initialize and bring down altp2m only when it is supported by the platform,
> e.g. VMX. Also guard p2m_altp2m_propagate_change().
> The purpose of that is the possibility to disable altp2m support and exclude
> its
> code from the build completely, when
On 09.07.2024 08:36, Jürgen Groß wrote:
> On 09.07.24 08:24, Jan Beulich wrote:
>> On 08.07.2024 23:30, Jason Andryuk wrote:
>>> From the backtrace, it looks like the immediate case is just trying to
>>> read a 4-byte version:
>>>
>>> [ 44.575541] ucsi_acpi_dsm+0x53/0x80
>>> [
76 matches
Mail list logo
