On 14/05/2024 3:43 pm, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 02:50:18PM +0100, Andrew Cooper wrote:
>> On 14/05/2024 12:09 pm, Andrew Cooper wrote:
>>> On 13/05/2024 9:59 am, Roger Pau Monne wrote:
There's no point in forcing a system wide update of the MTRRs on all
flight 186004 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186004/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 8 xen-boot fail like 185983
Hi Jan,
On 14/05/2024 15:51, Jan Beulich wrote:
On 13.05.2024 15:40, Elias El Yandouzi wrote:
From: Hongyan Xia
Create a per-domain mapping of PV guest_root_pt as direct map is being
removed.
Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.
On 15/05/2024 4:30 pm, Leigh Brown wrote:
> Hi Jason,
>
> On 2024-05-15 01:57, Jason Andryuk wrote:
>> On Wed, May 8, 2024 at 5:39 PM Leigh Brown wrote:
>>>
>>> Document the new `vlan' keyword in xl-network-configuration(5).
>>>
>>> Signed-off-by: Leigh Brown
>>
>> Reviewed-by: Jason Andryuk
>>
On Wed, 2024-05-15 at 17:41 +0200, Jan Beulich wrote:
> On 15.05.2024 17:29, Oleksii K. wrote:
> > On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
> > > On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > > > The following generic functions were introduced:
> > > > * test_bit
> > > > *
Hi Jason,
On 2024-05-15 01:58, Jason Andryuk wrote:
On Wed, May 8, 2024 at 6:08 PM Leigh Brown
wrote:>
Add a new directory linux-bridge-vlan with examples files showing
how to configure systemd-networkd to support a bridge VLAN
configuration.
Signed-off-by: Leigh Brown
---
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -799,6 +799,18 @@ that enabling this option cannot guarantee anything
> beyond what underlying
> hardware guarantees (with, where available and known to Xen,
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Create empty mappings in the second e820 pass. Also, destroy existing
> direct map mappings created in the first pass.
>
> To make xenheap pages visible in guests, it is necessary to create empty
> L3 tables in the direct map
On 14.05.2024 17:39, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:40PM +, Elias El Yandouzi wrote:
>> +{
>> +l4_pgentry_t *pl4e = _pg_table[l4_table_offset(vaddr)];
>> +
>> +if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
>> +{
>> +
On 15.05.2024 17:29, Oleksii K. wrote:
> On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
>> On 06.05.2024 12:15, Oleksii Kurochko wrote:
>>> The following generic functions were introduced:
>>> * test_bit
>>> * generic__test_and_set_bit
>>> * generic__test_and_clear_bit
>>> *
On Wed, May 15, 2024 at 03:35:15PM +0200, Jan Beulich wrote:
> The function itself properly handles and hands onwards failure from
> create_perdomain_mapping(). Therefore its caller should respect possible
> failure, too.
>
> Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al")
>
On Wed, 2024-05-15 at 16:07 +0200, Jan Beulich wrote:
> On 15.05.2024 15:55, Oleksii K. wrote:
> > On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> > > On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > > > Changes in V9:
> > > > - update return type of fls and flsl() to unsigned int to be
>
Hi Jason,
On 2024-05-15 01:57, Jason Andryuk wrote:
On Wed, May 8, 2024 at 5:39 PM Leigh Brown wrote:
Document the new `vlan' keyword in xl-network-configuration(5).
Signed-off-by: Leigh Brown
Reviewed-by: Jason Andryuk
One nit below
---
docs/man/xl-network-configuration.5.pod.in |
On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
> bitfields.
>
> Signed-off-by: Roger Pau Monné
Ha - I was going to write exactly the same patch, but you beat me to it.
Acked-by: Andrew Cooper
Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
bitfields.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/irq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 80ba8d9fe912..3b951d81bd6d
Hi Jason,
On 2024-05-15 01:57, Jason Andryuk wrote:
On Wed, May 8, 2024 at 6:55 PM Leigh Brown wrote:
Update add_to_bridge shell function to read the vlan parameter
from xenstore and set the bridge VLAN configuration for the VID.
Add additional helper functions to parse the vlan
On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > The following generic functions were introduced:
> > * test_bit
> > * generic__test_and_set_bit
> > * generic__test_and_clear_bit
> > * generic__test_and_change_bit
> >
> > Also, the patch
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When we do not have a direct map, archs_mfn_in_direct_map() will always
> return false, thus init_node_heap() will allocate xenheap pages from an
> existing node for the metadata of a new node. This means that the
> metadata
On 15/05/2024 4:25 pm, Juergen Gross wrote:
> When adding a cpu to a scheduler, set all data items of struct
> sched_resource inside the locked region, as otherwise a race might
> happen (e.g. when trying to access the cpupool of the cpu):
>
> (XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted:
When adding a cpu to a scheduler, set all data items of struct
sched_resource inside the locked region, as otherwise a race might
happen (e.g. when trying to access the cpupool of the cpu):
(XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted: H ]
(XEN) CPU:45
(XEN) RIP:e008:[]
On 5/15/24 02:32, Jan Beulich wrote:
> On 14.05.2024 22:31, Stewart Hildebrand wrote:
>> Here's what the patch ("arm/vpci: honor access size when returning an
>> error") now looks like based on staging:
>>
>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>> index
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1751,6 +1751,22 @@ void asmlinkage __init noreturn __start_xen(unsigned
> long mbi_p)
>
> numa_initmem_init(0, raw_max_page);
>
> +/*
> + * When we do not have a direct
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When there is not an always-mapped direct map, xenheap allocations need
> to be mapped and unmapped on-demand.
>
> Signed-off-by: Hongyan Xia
> Signed-off-by: Julien Grall
> Signed-off-by: Elias El Yandouzi
>
>
>
>
Hi Oleksii,
> On 6 May 2024, at 11:15 AM, Oleksii Kurochko
> wrote:
>
> The mentioned macros exist only because of Linux compatible purpose.
>
> The patch defines __ffs() in terms of Xen bitops and it is safe
> to define in this way ( as __ffs() - 1 ) as considering that __ffs()
> was defined
On 06/05/2024 12:15, Oleksii Kurochko wrote:
>
>
> The mentioned macros exist only because of Linux compatible purpose.
>
> The patch defines __ffs() in terms of Xen bitops and it is safe
> to define in this way ( as __ffs() - 1 ) as considering that __ffs()
> was defined as
On 4/18/24 23:53, Jiqian Chen wrote:
> When a device has been reset on dom0 side, the vpci on Xen
> side won't get notification, so the cached state in vpci is
> all out of date compare with the real device state.
> To solve that problem, add a new hypercall to clear all vpci
> device state. When
This commit implements the logic to have the static shared memory banks
from the Xen heap instead of having the host physical address passed from
the user.
When the host physical address is not supplied, the physical memory is
taken from the Xen heap using allocate_domheap_memory, the allocation
Handle the parsing of the 'xen,shared-mem' property when the host physical
address is not provided, this commit is introducing the logic to parse it,
but the functionality is still not implemented and will be part of future
commits.
Rework the logic inside process_shm_node to check the shm_id
This serie is a partial rework of this other serie:
https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/
The original serie is addressing an issue of the static shared memory feature
that impacts the memory footprint of other component when the
The function allocate_bank_memory allocates pages from the heap and
maps them to the guest using guest_physmap_add_page.
As a preparation work to support static shared memory bank when the
host physical address is not provided, Xen needs to allocate memory
from the heap, so rework
Wrap the code and logic that is calling assign_shared_memory
and map_regions_p2mt into a new function 'handle_shared_mem_bank',
it will become useful later when the code will allow the user to
don't pass the host physical address.
Signed-off-by: Luca Fancellu
---
v2 changes:
- add blank line,
From: Penny Zheng
This commit describe the new scenario where host address is not provided
in "xen,shared-mem" property and a new example is added to the page to
explain in details.
Take the occasion to fix some typos in the page.
Signed-off-by: Penny Zheng
Signed-off-by: Luca Fancellu
From: Penny Zheng
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could be super mapped.
But today, p2m_put_l3_page could not handle superpages.
This commits implements a new function p2m_put_l2_superpage to handle
2MB superpages,
The current static shared memory code is using bootinfo banks when it
needs to find the number of borrowers, so every time assign_shared_memory
is called, the bank is searched in the bootinfo.shmem structure.
There is nothing wrong with it, however the bank can be used also to
retrieve the start
On 15/05/2024 2:38 pm, Jürgen Groß wrote:
> On 15.05.24 15:22, Andrew Cooper wrote:
>> On 15/05/2024 1:39 pm, Jan Beulich wrote:
>>> On 15.05.2024 13:58, Andrew Cooper wrote:
Just so it doesn't get lost. In XenRT, we've found:
> (XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted:
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> @@ -77,18 +80,24 @@ void *map_domain_page(mfn_t mfn)
> struct vcpu_maphash_entry *hashent;
>
> #ifdef NDEBUG
> -if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
> +if ( arch_mfns_in_directmap(mfn_x(mfn), 1) )
>
On 15.05.2024 15:55, Oleksii K. wrote:
> On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
>> On 06.05.2024 12:15, Oleksii Kurochko wrote:
>>> Changes in V9:
>>> - update return type of fls and flsl() to unsigned int to be
>>> aligned with other
>>> bit ops.
>>
>> But this then needs
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> The early fixed addresses must all fit into the static L1 table.
> Introduce a build assertion to this end.
>
> Signed-off-by: Elias El Yandouzi
>
>
>
> Changes in v2:
> * New patch
>
> diff --git
On Wed, 2024-05-15 at 11:49 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > Changes in V9:
> > - update the defintion of write_atomic macros:
> > drop the return value as this macros isn't expeceted to return
> > something
> > drop unnessary parentheses around
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -80,12 +80,29 @@ config HAS_PMAP
> config HAS_SCHED_GRANULARITY
> bool
>
> +config HAS_SECRET_HIDING
> + bool
> +
> config HAS_UBSAN
> bool
>
> config
On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > Changes in V9:
> > - update return type of fls and flsl() to unsigned int to be
> > aligned with other
> > bit ops.
>
> But this then needs carrying through to ...
>
> > ---
On 14.05.2024 11:20, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:33PM +, Elias El Yandouzi wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -799,6 +799,18 @@ that enabling this option cannot guarantee anything
>> beyond what
flight 186003 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186003/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185994
test-amd64-amd64-libvirt 15
Hi Kelly,
On Wed, 2024-05-15 at 14:27 +0100, Kelly Choi wrote:
> Hi Oleksii,
>
> If there are no objections by tomorrow, let's assume by lazy
> consensus that we will extend the timeline by a week.
> If anyone objects to this, please reply to this email.
I will send a separate email tomorrow if
On 14.05.2024 10:42, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:32PM +, Elias El Yandouzi wrote:
>> @@ -771,6 +778,9 @@ int arch_domain_create(struct domain *d,
>>
>> d->arch.cpu_policy = ZERO_BLOCK_PTR; /* Catch stray misuses. */
>>
>> +
Hello Elliott,
Most of our developers are based in the EU timezone, however we are a
worldwide community.
The Xen Project is an open source community that everyone contributes to
and we do not divide how we provide help, based on location.
As explained previously, we are happy to help resolve
On 15.05.24 15:22, Andrew Cooper wrote:
On 15/05/2024 1:39 pm, Jan Beulich wrote:
On 15.05.2024 13:58, Andrew Cooper wrote:
Just so it doesn't get lost. In XenRT, we've found:
(XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted: H ]
(XEN) CPU: 45
(XEN) RIP: e008:[]
The function itself properly handles and hands onwards failure from
create_perdomain_mapping(). Therefore its caller should respect possible
failure, too.
Fixes: 4b28bf6ae90b ("x86: re-introduce map_domain_page() et al")
Signed-off-by: Jan Beulich
---
Effectively split off of "x86/mapcache:
Hi Oleksii,
If there are no objections by tomorrow, let's assume by lazy consensus that
we will extend the timeline by a week.
If anyone objects to this, please reply to this email.
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Wed, May 15, 2024 at 4:13 AM Henry Wang wrote:
> Hi
On 15/05/2024 1:39 pm, Jan Beulich wrote:
> On 15.05.2024 13:58, Andrew Cooper wrote:
>> Just so it doesn't get lost. In XenRT, we've found:
>>
>>> (XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted: H ]
>>> (XEN) CPU: 45
>>> (XEN) RIP: e008:[]
>>>
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -851,6 +851,8 @@ int arch_domain_create(struct domain *d,
>
> psr_domain_init(d);
>
> +mapcache_domain_init(d);
This new placement is re-done right away in the next patch.
On Tue, May 14, 2024 at 10:51 AM Andrew Cooper
wrote:
>
> On 14/05/2024 10:25 am, Jan Beulich wrote:
> > On 03.04.2024 08:16, Jan Beulich wrote:
> >> On 02.04.2024 19:06, Andrew Cooper wrote:
> >>> The commit makes a claim without any kind of justification.
> >> Well, what does "have no business"
flight 186002 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186002/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185996
test-amd64-amd64-xl-qemuu-win7-amd64
On 15.05.2024 13:58, Andrew Cooper wrote:
> Just so it doesn't get lost. In XenRT, we've found:
>
>> (XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted: H ]
>> (XEN) CPU: 45
>> (XEN) RIP: e008:[]
>> common/sched/credit.c#csched_load_balance+0x41/0x877
>> (XEN) RFLAGS:
Just so it doesn't get lost. In XenRT, we've found:
> (XEN) [ Xen-4.19.0-1-d x86_64 debug=y Tainted: H ]
> (XEN) CPU: 45
> (XEN) RIP: e008:[]
> common/sched/credit.c#csched_load_balance+0x41/0x877
> (XEN) RFLAGS: 00010092 CONTEXT: hypervisor
> (XEN) rax:
Hi all,
As Stefano has mentioned, we have the maintainers and committers call later
today.
Let's use this time to better collaborate and discuss any differences in
opinions we have. It will also give everyone a chance to explain their
viewpoints.
Andy, please can I remind you to keep the
On 06.05.2024 15:38, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:16:11AM +0100, Jan Beulich wrote:
>> When the flag is set, permit Dom0 to control the device (no worse than
>> what we had before and in line with other "best effort" behavior we use
>> when it comes to Dom0),
>
> I think we
On 06.05.2024 15:53, Roger Pau Monné wrote:
> On Mon, May 06, 2024 at 03:20:38PM +0200, Jan Beulich wrote:
>> On 06.05.2024 14:42, Roger Pau Monné wrote:
>>> On Thu, Feb 15, 2024 at 11:15:39AM +0100, Jan Beulich wrote:
Make the variable a tristate, with (as done elsewhere) a negative value
> On 14 May 2024, at 22:06, Julien Grall wrote:
>
> Hi,
>
> On 14/05/2024 08:53, Luca Fancellu wrote:
>> Hi Julien,
>> Thanks for having a look on the patch,
>>> On 13 May 2024, at 22:54, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 25/04/2024 14:11, Luca Fancellu wrote:
Currently
On 06.05.2024 12:15, Oleksii Kurochko wrote:
> Changes in V9:
> - update the defintion of write_atomic macros:
>drop the return value as this macros isn't expeceted to return something
>drop unnessary parentheses around p.
Yet then what about add_sized()? With that also tidied
Acked-by:
On 15.05.2024 11:38, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 06:22:59PM +0200, Jan Beulich wrote:
>> On 14.05.2024 17:45, Roger Pau Monné wrote:
>>> On Mon, May 13, 2024 at 01:40:41PM +, Elias El Yandouzi wrote:
Until directmap gets completely removed, we'd still need to
On Tue, May 14, 2024 at 06:22:59PM +0200, Jan Beulich wrote:
> On 14.05.2024 17:45, Roger Pau Monné wrote:
> > On Mon, May 13, 2024 at 01:40:41PM +, Elias El Yandouzi wrote:
> >> Until directmap gets completely removed, we'd still need to
> >> keep some calls to mfn_to_virt() for xenheap pages
On 06.05.2024 12:15, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> @@ -0,0 +1,239 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (C) 2014 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_CMPXCHG_H
> +#define
On 06.05.2024 12:15, Oleksii Kurochko wrote:
> Changes in V9:
> - add Acked-by: Jan Beulich
> - drop redefinition of bitop_uint_t in asm/types.h as some operation in Xen
> common code expects
>to work with 32-bit quantities.
> - s/BITS_PER_LONG/BITOP_BITS_PER_WORD in asm/bitops.h around
From: Xenia Ragiadakou
Provide the user with configuration control over the cpu virtualization support
in Xen by making SVM and VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to value of HVM.
To prevent users from unknowingly
VMX posted interrupts support can now be excluded from x86 build along with
VMX code itself, but still we may want to keep the possibility to use
VT-d IOMMU driver in non-HVM setups.
So we guard vmx_pi_hooks_{assign/deassign} with some checks for such a case.
No functional change intended here.
From: Xenia Ragiadakou
VIO_realmode_completion is specific to vmx realmode, so guard the completion
handling code with CONFIG_VMX. Also, guard VIO_realmode_completion itself by
CONFIG_VMX, instead of generic CONFIG_X86.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
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:
From: Xenia Ragiadakou
The symbol svm_stgi_label is AMD-V specific so guard its usage in common code
with CONFIG_SVM.
Since SVM depends on HVM, it can be used alone.
Also, use #ifdef instead of #if.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
Remove preprocessor checks for CONFIG_HVM option, because expressions covered
by these checks are already guarded by cpu_has_svm, which itself depends
on CONFIG_HVM option (via CONFIG_SVM).
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/domain.c | 4 +---
1 file
Remove preprocessor checks for CONFIG_HVM option, because expressions covered
by these checks are already guarded by cpu_has_vmx, which itself depends
on CONFIG_HVM option (via CONFIG_VMX).
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/traps.c | 4
1 file
If VMX/SVM disabled in the build, we may still want to have vPMU drivers for
PV guests. Yet some calls to vmx/svm-related routines needs to be guarded then.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/vpmu_amd.c | 8
xen/arch/x86/cpu/vpmu_intel.c | 20 ++--
2
As we now have SVM/VMX config options for enabling/disabling these features
completely in the build, it may be feasible to add build-time checks to
cpu_has_{svm,vmx} macros. These are used extensively thoughout HVM code, so
we won't have to add extra #ifdef-s to check whether svm/vmx has been
Instead of using generic CONFIG_HVM option switch to a bit more specific
CONFIG_ALTP2M option for altp2m support. Also guard altp2m routines, so that
they can be disabled completely in the build -- when target platform does not
actually support altp2m (AMD-V & ARM as of now).
Signed-off-by:
On 06.05.2024 12:15, Oleksii Kurochko wrote:
> Changes in V9:
> - update return type of fls and flsl() to unsigned int to be aligned with
> other
>bit ops.
But this then needs carrying through to ...
> --- a/xen/arch/arm/include/asm/arm64/bitops.h
> +++
Add new option to make altp2m code inclusion optional.
Currently altp2m support provided for VT-d only, so option is dependant on VMX.
No functional change intended.
Signed-off-by: Sergiy Kibrik
CC: Tamas K Lengyel
---
xen/arch/x86/Kconfig | 5 +
1 file changed, 5 insertions(+)
diff
Move altp2m code from generic p2m.c file to altp2m.c, so it is kept separately
and can possibly be disabled in the build. We may want to disable it when
building for specific platform only, that doesn't support alternate p2m.
No functional change intended.
Signed-off-by: Sergiy Kibrik
CC: Tamas
On Tue, May 14, 2024 at 06:15:57PM +0100, Elias El Yandouzi wrote:
> Hi Roger,
>
> On 13/05/2024 16:27, Roger Pau Monné wrote:
> > > diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> > > index 2a445bb17b..1b025986f7 100644
> > > --- a/xen/arch/x86/pv/domain.c
> > > +++
Initialize and bring down altp2m only when it is supported by the platform,
e.g. VMX. Also guard p2m_altp2m_propagate_change().
The puspose of that is the possiblity to disable altp2m support and exclude its
code from the build completely, when it's not supported by the target platform.
Explicitly check whether altp2m is on for domain when getting altp2m index.
If explicit call to altp2m_active() always returns false, DCE will remove
call to altp2m_vcpu_idx().
The puspose of that is later to be able to disable altp2m support and
exclude its code from the build completely, when
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 platforms that
implement the AMD Virtualization
This is yet another attempt to provide a means to render the cpu virtualization
technology support in Xen configurable.
Currently, irrespectively of the target platform, both AMD-V and Intel VT-x
drivers are built.
The series adds three new Kconfig controls, ALT2PM, SVM and VMX, that can be
used
On 06.05.2024 12:15, Oleksii Kurochko wrote:
> The following generic functions were introduced:
> * test_bit
> * generic__test_and_set_bit
> * generic__test_and_clear_bit
> * generic__test_and_change_bit
>
> Also, the patch introduces the following generics which are
> used by the functions
flight 186001 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185993
test-armhf-armhf-libvirt 16
These rules are concerned with the use of facilities provided by the
C Standard Library (qsort, bsearch for rule 21.9, and those provided
by for rule 21.10).
Xen provides in its source code its own implementation of some of these
functions and macros, therefore a justification is provided for
Oleksii,
On 15.05.2024 09:34, Nicola Vetrini wrote:
> Hi all,
>
> this series aims to refactor some macros that cause violations of MISRA C Rule
> 20.7 ("Expressions resulting from the expansion of macro parameters shall be
> enclosed in parentheses"). All the macros touched by these patches are
On 15.05.2024 01:15, Stefano Stabellini wrote:
> Add D4.12 with the same explanation as the rules of the R21 series.
> D4.12 refers to the standard library memory allocation functions and
> similar third party libraries with memory allocation functions. It
> doesn't refer to the in-tree
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
On 14.05.2024 23:35, Stefano Stabellini wrote:
> On Tue, 14 May 2024, Julien Grall wrote:
>> On 14/05/2024 11:03, Jan Beulich wrote:
>>> On 14.05.2024 11:51, Andrew Cooper wrote:
You tried defending breaking a utility with "well it shouldn't exist
then".
You don't have a leg to
On 15.05.2024 09:09, Nicola Vetrini wrote:
> On 2024-05-01 21:54, Stefano Stabellini wrote:
>> On Mon, 29 Apr 2024, Nicola Vetrini wrote:
>>> On 2024-04-25 02:28, Stefano Stabellini wrote:
On Tue, 23 Apr 2024, Nicola Vetrini wrote:
> The count_args_ macro violates Rule 20.7, but it can't
On 2024-05-01 21:54, Stefano Stabellini wrote:
On Mon, 29 Apr 2024, Nicola Vetrini wrote:
On 2024-04-25 02:28, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Nicola Vetrini wrote:
> > The count_args_ macro violates Rule 20.7, but it can't be made
> > compliant with Rule 20.7 without breaking
Hi All,
This is v7 series to support passthrough on Xen when dom0 is PVH.
v6->v7 change:
* the first patch of v6 was already merged into branch linux_next.
* patch#1: is the patch#2 of v6. move the implementation of function
xen_acpi_get_gsi_info to
file drivers/xen/acpi.c, that
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi 28,
it causes
In PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.
When assign a device to passthrough, proactively setup the gsi
of the device during that process.
Co-developed-by: Huang Rui
Signed-off-by: Jiqian Chen
On 14.05.2024 22:31, Stewart Hildebrand wrote:
> Here's what the patch ("arm/vpci: honor access size when returning an
> error") now looks like based on staging:
>
> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
> index 3bc4bb55082a..31e9e1d20751 100644
> --- a/xen/arch/arm/vpci.c
> +++
On 15.05.2024 00:52, Stefano Stabellini wrote:
> On Tue, 14 May 2024, Jan Beulich wrote:
>> On 14.05.2024 02:32, Stefano Stabellini wrote:
>>> Fix last violation of R10.2 by casting the result of toupper to plain
>>> char. Note that we don't want to change toupper itself as it is a legacy
>>>
1 - 100 of 167068 matches
Mail list logo
