On 2024/5/16 06:42, Stefano Stabellini wrote:
> On Wed, 15 May 2024, Jiqian Chen wrote:
>> 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 fr
On 14.05.2024 11:25, 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" leave open?
>>
>>> The claim is false, and the commit broke lsevtch
On Wed, May 15, 2024 at 02:40:31PM +0100, Kelly Choi wrote:
>
> As explained previously, we are happy to help resolve issues and provide
> advice where necessary. However, to do this, our developers need the
> relevant information to provide accurate resolutions. Given that our
> developers have r
flight 186009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186009/
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
From: Jason Andryuk
From: Jason Andryuk
backendtype=phy using the blktap kernel module needs to use write_dev,
but tapback can't support that. tapback should perform better, but make
the script compatible with the old kernel module again.
Signed-off-by: Jason Andryuk
---
This is tested with
From: Jason Andryuk
From: Jason Andryuk
Add entry for backendtype=tap support in libxl. blktap needs some
changes to work with libxl, which haven't been merged. They are
available from this PR: https://github.com/xapi-project/blktap/pull/394
Signed-off-by: Jason Andryuk
---
CHANGELOG.md |
From: Jason Andryuk
From: Jason Andryuk
To change the cd-rom medium, libxl will:
- QMP eject the medium from QEMU
- block-detach the old PV disk
- block-attach the new PV disk
- QMP change the medium to the new PV disk by fdset-id
The QMP code is reused, and remove and attach are implement
Hi Stefano,
On 5/16/2024 6:30 AM, Stefano Stabellini wrote:
On Wed, 15 May 2024, Henry Wang wrote:
Currently, the late XenStore init protocol is only triggered properly
for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
case that XenStore interface is allocated but not ready (the
flight 186005 linux-linus real [real]
flight 186008 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186005/
http://logs.test-lab.xenproject.org/osstest/logs/186008/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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 su
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
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
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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: Sergi
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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: Sergi
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
Question to the x86 maintainers: are we sure we want to s
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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 extr
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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 altp
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
On Wed, 15 May 2024, 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 puspose of that is the possiblity to disable altp2m support and exclude
> its
> code from the build completely, when i
On Wed, 15 May 2024, Sergiy Kibrik wrote:
> 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
On Sat, 4 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Use the generic xen/linkage.h macros to annotate code symbols
> and add missing annotations.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/mmu/head.S | 29
On Sat, 4 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Use the generic xen/linkage.h macros to annotate code symbols
> and add missing annotations.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/entry.S | 78 +++
On Sat, 4 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Use the generic xen/linkage.h macros to annotate code symbols
> and add missing annotations.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/bpi.S | 20 -
On Sat, 4 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Use the generic xen/linkage.h macros to annotate code symbols
> and add missing annotations.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/head.S | 51
On Wed, 15 May 2024, Nicola Vetrini wrote:
> 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
On Wed, 15 May 2024, Nicola Vetrini wrote:
> 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
On Wed, 15 May 2024, Nicola Vetrini wrote:
> 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
On Wed, 15 May 2024, Nicola Vetrini wrote:
> 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
On Fri, 3 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a second mapcache for grant mappings. The mapcache for
> grants needs to work with XC_PAGE_SIZE granularity since
> we can't map larger ranges than what has been granted to us.
>
> Like with foreign mappings (xen_me
On Fri, 3 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Pass the ram_addr offset to xen_map_cache.
> This is in preparation for adding grant mappings that need
> to compute the address within the RAMBlock.
>
> No functional changes.
>
> Signed-off-by: Edgar E. Iglesias
> -
flight 186006 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186006/
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
The value returned by __toupper is used in arithmetic operations causing
MISRA C 10.2 violations. Cast to plain char in the toupper macro. Also
do the same in tolower for consistency.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- fix the toupper macro instead
diff --git a/xen/include/xe
On Wed, 15 May 2024, Jan Beulich wrote:
> 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
On Wed, 15 May 2024, Jiqian Chen wrote:
> 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
On Wed, 15 May 2024, Henry Wang wrote:
> Currently, the late XenStore init protocol is only triggered properly
> for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
> case that XenStore interface is allocated but not ready (the connection
> status is not XENSTORE_CONNECTED), Linux sho
On Wed, 15 May 2024, Jan Beulich wrote:
> 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 function
On Wed, 15 May 2024, Nicola Vetrini wrote:
> 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 an
On Tue, May 14, 2024, Mickaël Salaün wrote:
> On Fri, May 10, 2024 at 10:07:00AM +, Nicolas Saenz Julienne wrote:
> > Development happens
> > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next
> > branch, but I'd advice against looking into it until we add some order
> > to
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
processors
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
test-amd64-amd64-xl-qemut-win7-amd64
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.
Signed-off-by:
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
> > > > * generic__
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
---
tools/examples/li
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, resp
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 = &idle_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
>>> * generic__test_an
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")
> Sign
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 | 3
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 100
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 specificatio
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 intr
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 of
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:[]
co
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 3bc4bb55082a..31e9e1d20751
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 ma
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 __builtin_ctzl(x)
? It's independent of the rest of
this series, and it fixes a real issue observed on both Arm and x86. The
Linux counterpart has already been merged in linux-next [0].
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240515&id=b272722511d5e8ae580f01830687b8a6b2717f01
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
n
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 befo
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 feature
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 allocate_bank_me
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, mo
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
Review
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, specifical
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 a
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) )
> ret
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 carryi
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 a/xen/arch/x86/include/asm/fix
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 p.
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 MEM_ACCESS_ALWAYS_ON
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 ...
>
> > --- a/xen/arch/arm
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 underlyi
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 migrate-s
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. */
>>
>> +idle_pg_table[l4_table_o
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 iss
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:[]
common/sch
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: Initi
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 O
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:[]
>>> common/sched/credit.c#csched_loa
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. To
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: 000
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: 82d040
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 language
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 t
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: J
1 - 100 of 135 matches
Mail list logo
