On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich wrote:
> On 16.01.2024 01:22, Patrick Plenefisch wrote:
> > I managed to set up serial access and saved the output with the requested
> > flags as the attached logs
>
> Thanks. While you didn't ...
>
>
> ... fiddle with the Linux message, ...
>
I last
flight 184370 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 184339
Tests which did not s
On 1/9/24 16:51, Stewart Hildebrand wrote:
> Move iomem_caps initialization earlier (before arch_domain_create()).
>
> Signed-off-by: Stewart Hildebrand
Since the iomem_access_permitted() check over in ("vpci/header: program p2m
with guest BAR view") was changed to use MFNs (it used GFNs in an
On 1/15/24 14:44, Stewart Hildebrand wrote:
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index feccd070ddd0..8483404c5e91 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -41,13 +42,24 @@ static int cf_check map_range(
> unsigned long s,
flight 184379 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184379/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 59f024c76ee57c2bec84794536302fc770cd6ec2
baseline version:
ovmf 9971b99461e930008e3d3
flight 184368 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 debian-install fail REGR. vs. 184270
test-arm64-arm64-xl
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 even when directmap=no, since guest cr3s
copy idle domain's
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/fixmap.h
b/xen/arch/x86/include/asm/fixmap.h
index a7ac365fc6..904bee0
Until directmap gets completely removed, we'd still need to
keep some calls to mfn_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to mfn_to_directmap_virt() to flag them and
prevent further use of mfn_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git a/xen/a
From: Julien Grall
Implement the same command line option as x86 to enable/disable the
directmap. By default this is kept enabled.
Also modify setup_directmap_mappings() to populate the L0 entries
related to the directmap area.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
---
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 a new node is in a different node, slowing down heap
allo
From: Julien Grall
The arm32 version of init_secondary_pagetables() will soon be re-used
for arm64 as well where the root table starts at level 0 rather than level 1.
So rename 'first' to 'root'.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changelog in v2:
Until directmap gets completely removed, we'd still need to
keep some calls to mmaddr_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to maddr_to_directmap_virt() to flag them and
prevent further use of maddr_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git
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
I have left the call to map_pages_to_xen() and destroy_xen_mappings
From: Hongyan Xia
When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the h
From: Julien Grall
At the moment, on arm64, map_domain_page() is implemented using
virt_to_mfn(). Therefore it is relying on the directmap.
In a follow-up patch, we will allow the admin to remove the directmap.
Therefore we want to implement a mapcache.
Thanksfully there is already one for arm3
From: Julien Grall
At the moment, on Arm64, every pCPU is sharing the same page-tables.
In a follow-up patch, we will allow the possibility to remove the
direct map and therefore it will be necessary to have a mapcache.
While we have plenty of spare virtual address space to reserve part
for eac
From: Hongyan Xia
When mfn is not in direct map, never use mfn_to_virt for any mappings.
We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
extra comparison in arch_mfns_in_direct_map() looks different but b
From: Hongyan Xia
Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
to check this option before returning.
This is added as a Kconfig option as well as a boot command line option.
While being generic, the Kconfig option is only usable for x86 at the moment.
Signed-off-by
From: Wei Liu
It is going to be needed by HVM and idle domain as well, because without
the direct map, both need a mapcache to map pages.
This only lifts the mapcache variable up. Whether we populate the
mapcache for a domain is unchanged in this patch.
Signed-off-by: Wei Liu
Signed-off-by: We
From: Hongyan Xia
In order to use the mapcache in the idle domain, we also have to
populate its page tables in the PERDOMAIN region, and we need to move
mapcache_domain_init() earlier in arch_domain_create().
Note, commit 'x86: lift mapcache variable to the arch level' has
initialised the mapcac
From: Julien Grall
At the moment the fixmap slots are prefixed differently between arm and
x86.
Some of them (e.g. the PMAP slots) are used in common code. So it would
be better if they are named the same way to avoid having to create
aliases.
I have decided to use the x86 naming because they a
From: Hongyan Xia
Also, introduce a wrapper around vmap that maps a contiguous range for
boot allocations. Unfortunately, the new helper cannot be a static inline
because the dependencies are a mess. We would need to re-include
asm/page.h (was removed in aa4b9d1ee653 "include: don't use asm/page.
From: Hongyan Xia
This avoids the assumption that boot pages are in the direct map.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
There was a discussion with Jan regarding early failure vs
disable NUMA. I am strongly in favor of the lat
From: Hongyan Xia
Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. Use the pages as they should be.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V2:
* Clarify the commit message
* B
From: Hongyan Xia
This avoids the assumption that there is a direct map and boot pages
fall inside the direct map.
Clean up the variables so that mfn actually stores a type-safe mfn.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
See the di
From: Julien Grall
PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.
The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.
Signed-off-by: Julien Grall
Signed
From: Wei Liu
Xen shouldn't use domheap page as if they were xenheap pages. Map and
unmap pages accordingly.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V2:
* Get rid of mfn_to_virt
* Don't
Hi all,
A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].
I will start with thanking both Wei and Hongyan for the initial work
to upstream the feature. A lot of patches already went in and this is
the last few patches missin
From: Hongyan Xia
Before, it assumed the pv cr3 could be accessed via a direct map. This
is no longer true.
Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
From: Julien Grall
vunmap() and vfree() currently duplicate the (small) logic to find the
size of an vmap area. In a follow-up patch, we will want to introduce
another one (this time externally).
So introduce a new helper vmap_size() that will return the number of
pages in the area starting at t
From: Wei Liu
After the direct map removal, pages from the boot allocator are not
going to be mapped in the direct map. Although we have map_domain_page,
they are ephemeral and are less helpful for mappings that are more than a
page, so we want a mechanism to globally map a range of pages, which
From: Hongyan Xia
The root page table is allocated from the domheap and isn't
mapped by default. Map it on demand to build pv shim domain.
Signed-off-by: Hongyan Xia
Signed-off-by: Elias El Yandouzi
Changes in v2:
* New patch
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/
From: Julien Grall
The function map_pages_to_xen() could fail if it can't allocate the
underlying page tables or (at least on Arm) if the area was already
mapped.
The first error is caught by clear_page() because it would fault.
However, the second error while very unlikely is not caught at all.
Hi,
Newbie mistake, I didn't number the patches, I'll resend the series.
Sorry for the noise.
On 16/01/2024 18:50, Elias El Yandouzi wrote:
Hi all,
A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].
I will start with tha
From: Hongyan Xia
When mfn is not in direct map, never use mfn_to_virt for any mappings.
We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
extra comparison in arch_mfns_in_direct_map() looks different but b
From: Hongyan Xia
When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the h
From: Julien Grall
At the moment, on Arm64, every pCPU is sharing the same page-tables.
In a follow-up patch, we will allow the possibility to remove the
direct map and therefore it will be necessary to have a mapcache.
While we have plenty of spare virtual address space to reserve part
for eac
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 even when directmap=no, since guest cr3s
copy idle domain's
From: Julien Grall
At the moment, on arm64, map_domain_page() is implemented using
virt_to_mfn(). Therefore it is relying on the directmap.
In a follow-up patch, we will allow the admin to remove the directmap.
Therefore we want to implement a mapcache.
Thanksfully there is already one for arm3
From: Hongyan Xia
In order to use the mapcache in the idle domain, we also have to
populate its page tables in the PERDOMAIN region, and we need to move
mapcache_domain_init() earlier in arch_domain_create().
Note, commit 'x86: lift mapcache variable to the arch level' has
initialised the mapcac
From: Julien Grall
Implement the same command line option as x86 to enable/disable the
directmap. By default this is kept enabled.
Also modify setup_directmap_mappings() to populate the L0 entries
related to the directmap area.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
---
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
I have left the call to map_pages_to_xen() and destroy_xen_mappings
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 a new node is in a different node, slowing down heap
allo
Until directmap gets completely removed, we'd still need to
keep some calls to mmaddr_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to maddr_to_directmap_virt() to flag them and
prevent further use of maddr_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git
From: Wei Liu
It is going to be needed by HVM and idle domain as well, because without
the direct map, both need a mapcache to map pages.
This only lifts the mapcache variable up. Whether we populate the
mapcache for a domain is unchanged in this patch.
Signed-off-by: Wei Liu
Signed-off-by: We
From: Julien Grall
The arm32 version of init_secondary_pagetables() will soon be re-used
for arm64 as well where the root table starts at level 0 rather than level 1.
So rename 'first' to 'root'.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changelog in v2:
Until directmap gets completely removed, we'd still need to
keep some calls to mfn_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to mfn_to_directmap_virt() to flag them and
prevent further use of mfn_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git a/xen/a
From: Hongyan Xia
Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
to check this option before returning.
This is added as a Kconfig option as well as a boot command line option.
While being generic, the Kconfig option is only usable for x86 at the moment.
Signed-off-by
From: Hongyan Xia
The root page table is allocated from the domheap and isn't
mapped by default. Map it on demand to build pv shim domain.
Signed-off-by: Hongyan Xia
Signed-off-by: Elias El Yandouzi
Changes in v2:
* New patch
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/
From: Julien Grall
PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.
The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.
Signed-off-by: Julien Grall
Signed
From: Hongyan Xia
Before, it assumed the pv cr3 could be accessed via a direct map. This
is no longer true.
Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
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/fixmap.h
b/xen/arch/x86/include/asm/fixmap.h
index a7ac365fc6..904bee0
From: Hongyan Xia
Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. Use the pages as they should be.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V2:
* Clarify the commit message
* B
From: Julien Grall
At the moment the fixmap slots are prefixed differently between arm and
x86.
Some of them (e.g. the PMAP slots) are used in common code. So it would
be better if they are named the same way to avoid having to create
aliases.
I have decided to use the x86 naming because they a
From: Wei Liu
Xen shouldn't use domheap page as if they were xenheap pages. Map and
unmap pages accordingly.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V2:
* Get rid of mfn_to_virt
* Don't
From: Hongyan Xia
This avoids the assumption that there is a direct map and boot pages
fall inside the direct map.
Clean up the variables so that mfn actually stores a type-safe mfn.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
See the di
From: Hongyan Xia
This avoids the assumption that boot pages are in the direct map.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
There was a discussion with Jan regarding early failure vs
disable NUMA. I am strongly in favor of the lat
From: Wei Liu
After the direct map removal, pages from the boot allocator are not
going to be mapped in the direct map. Although we have map_domain_page,
they are ephemeral and are less helpful for mappings that are more than a
page, so we want a mechanism to globally map a range of pages, which
From: Hongyan Xia
Also, introduce a wrapper around vmap that maps a contiguous range for
boot allocations. Unfortunately, the new helper cannot be a static inline
because the dependencies are a mess. We would need to re-include
asm/page.h (was removed in aa4b9d1ee653 "include: don't use asm/page.
From: Julien Grall
The function map_pages_to_xen() could fail if it can't allocate the
underlying page tables or (at least on Arm) if the area was already
mapped.
The first error is caught by clear_page() because it would fault.
However, the second error while very unlikely is not caught at all.
From: Julien Grall
vunmap() and vfree() currently duplicate the (small) logic to find the
size of an vmap area. In a follow-up patch, we will want to introduce
another one (this time externally).
So introduce a new helper vmap_size() that will return the number of
pages in the area starting at t
Hi all,
A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].
I will start with thanking both Wei and Hongyan for the initial work
to upstream the feature. A lot of patches already went in and this is
the last few patches missin
Hi all,
I have not had any further feedback opposing this proposal and will go
ahead with the changes.
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Thu, Dec 21, 2023 at 1:00 PM Kelly Choi wrote:
> Hi all,
>
> I am proposing a small change in how we update non-trivial matters in o
On 16/01/2024 4:58 pm, Jan Beulich wrote:
> This way we can arrange for ioemul_handle_proliant_quirk()'s ENDBR to
> also be zapped. Utilize existing data rather than introducing another
> otherwise unused static variable (array); eventually (if any new quirk
> was in need of adding) we may want to
flight 184367 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184367/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184337
test-armhf-armhf-libvirt-qcow2 15 saveres
Hi Oleksii,
On 16/01/2024 09:44, Oleksii wrote:
On Mon, 2024-01-15 at 12:01 +0100, Jan Beulich wrote:
On 15.01.2024 11:35, Oleksii wrote:
Hi Julien,
On Fri, 2024-01-12 at 10:39 +, Julien Grall wrote:
Hi Oleksii,
On 22/12/2023 15:13, Oleksii Kurochko wrote:
Signed-off-by: Oleksii Kuroch
On 16/01/2024 4:56 pm, Jan Beulich wrote:
> When this code was written, indirect branches still weren't considered
> much of a problem (besides being a little slower). Instead of a function
> pointer, pass a boolean to _disable_pit_irq(), thus allowing to
> eliminate two ENDBR (one of them in .text
This way we can arrange for ioemul_handle_proliant_quirk()'s ENDBR to
also be zapped. Utilize existing data rather than introducing another
otherwise unused static variable (array); eventually (if any new quirk
was in need of adding) we may want to use .callback and .driver_data
anyway.
For the de
When this code was written, indirect branches still weren't considered
much of a problem (besides being a little slower). Instead of a function
pointer, pass a boolean to _disable_pit_irq(), thus allowing to
eliminate two ENDBR (one of them in .text).
Signed-off-by: Jan Beulich
--- a/xen/arch/x8
While altcall is already used for them, the functions want announcing in
.init.rodata.cf_clobber, even if the resulting static variables aren't
otherwise used.
While doing this also move ctxt_switch_masking to .data.ro_after_init.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/amd.c
+++ b/xe
(reducing Cc list)
On 16.01.2024 17:32, Oleksii wrote:
> Please reply with items you would like to see in 4.19 so that people
> know what is happening and prioritize accordingly.
> You're welcome to provide a description and use cases of the feature
> you're working on.
The "annotate entry points
Hello everyone,
I would like to start tracking which features and changes are expected
in Xen 4.19 for each architecture.
Please reply with items you would like to see in 4.19 so that people
know what is happening and prioritize accordingly.
You're welcome to provide a description and use cases o
Hi all,
A reminder to fill out the Xen Project Annual survey!
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Tue, Jan 9, 2024 at 1:21 PM Kelly Choi wrote:
> Happy New Year Xen Community,
>
> As we start the New Year, I'd like to ask you to reflect on how the
> project went in 2023.
On 16.01.2024 16:52, Sébastien Chaumat wrote:
> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
> écrit :
>
>>
>> output of gpioinfo
>>>
>>> kernel alone :
>>>
>>> line 5: unnamed input active-low consumer=interrupt
>>> line 84: unnamed input active-low consu
On 16.01.2024 16:20, Oleksii wrote:
> On Mon, 2024-01-15 at 17:57 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:12, Oleksii Kurochko wrote:
>>> +/*
>>> + * Unordered I/O memory access primitives. These are even more
>>> relaxed than
>>> + * the relaxed versions, as they don't even order accesses b
Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
écrit :
>
> output of gpioinfo
>>
>> kernel alone :
>>
>> line 5: unnamed input active-low consumer=interrupt
>> line 84: unnamed input active-low consumer=interrupt
>>
>> xen:
>>
>> line 5: unnamed
On Mon, 2024-01-15 at 17:57 +0100, Jan Beulich wrote:
> On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/io.h
> > @@ -0,0 +1,142 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * {read,write}{b,w,l,q} based on arch/arm64/include/a
flight 184365 xen-unstable real [real]
flight 184373 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184365/
http://logs.test-lab.xenproject.org/osstest/logs/184373/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to work out where each piece of Xen reside.
An easy way to solve the issue is to have all code/data accessed
by the seco
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to work out where each piece of Xen reside.
An easy way to solve the issue is to have all code/data accessed
by the seco
From: Julien Grall
In order to confirm the early boot code is self-contained, allocate a
separate trampoline region for secondary to boot from it.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/mmu/mm.c | 7 +++
xen/arch/arm/mmu/smpboot.c | 4 +++-
xen/arch/arm/psci.c | 5 +
From: Julien Grall
Hi all,
Right now, the MMU-off code will access may access data that are either
in .rodata or .data. With the enablement of cache coloring, Xen may
not be physcally contiguous anymore when secondary CPUs are brought up.
There are multiple way to solve this problem. The first
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to work out where each piece of Xen reside.
An easy way to solve the issue is to have all code/data accessed
by the seco
On 16/01/2024 14:24, Carlo Nonato wrote:
Hi Julien,
On Tue, Jan 16, 2024 at 12:55 PM Julien Grall wrote:
From: Julien Grall
In order to confirm the early boot code is self-contained, allocate a
separate trampoline region for secondary to boot from it.
Signed-off-by: Julien Grall
---
On Thu, Jan 11, 2024 at 6:13 PM Andrew Cooper wrote:
>
> Right now, vvmx will blindly copy L12's ACTIVITY_STATE into the L02 VMCS and
> enter the vCPU. Luckily for us, nested-virt is explicitly unsupported for
> security bugs.
>
> The inactivity states are HLT, SHUTDOWN and WAIT-FOR-SIPI, and as
Hi Julien,
On Tue, Jan 16, 2024 at 12:55 PM Julien Grall wrote:
>
> From: Julien Grall
>
> In order to confirm the early boot code is self-contained, allocate a
> separate trampoline region for secondary to boot from it.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/arm64/mmu/mm.c | 7
On 16/01/24 14:02, Jan Beulich wrote:
On 16.01.2024 12:58, Andrew Cooper wrote:
Fixes MISRA XXX
Rule 5.5 if I'm not mistaken; had to look it up for the patch sent
earlier in the day. As to "fixes" - when it's not an actual bug, I had
(successfully) asked the bugseng guys to avoid that term, an
On 16/01/2024 1:02 pm, Jan Beulich wrote:
> On 16.01.2024 12:58, Andrew Cooper wrote:
>> Fixes MISRA XXX
> Rule 5.5 if I'm not mistaken; had to look it up for the patch sent
> earlier in the day. As to "fixes" - when it's not an actual bug, I had
> (successfully) asked the bugseng guys to avoid tha
From: Peng Fan
xen_invalidate_map_cache_entry is not expected to run in a
coroutine. Without this, there is crash:
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
threadid=) at pthread_kill.c:78
at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/raise.c:26
fmt=0xf
On 1/8/24 21:26, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/arm/aspeed.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index cc59176563..bed5e4f40b 100644
--- a/hw/arm/aspeed.c
+++ b/hw/
On 08/01/2024 21.27, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/s390x/s390-virtio-ccw.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 1169e20b94..202c37813
On 16.01.2024 14:06, Oleksii wrote:
> On Mon, 2024-01-15 at 17:44 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:12, Oleksii Kurochko wrote:
>>> +#define test_and_set_bit __test_and_set_bit
>>> +#define test_and_clear_bit __test_and_clear_bit
>>
>> I realize test-and-change have no present users,
On Mon, 2024-01-15 at 17:44 +0100, Jan Beulich wrote:
> On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/bitops.h
> > @@ -0,0 +1,267 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2012 Regents of the University of California *
On 16.01.2024 12:58, Andrew Cooper wrote:
> Fixes MISRA XXX
Rule 5.5 if I'm not mistaken; had to look it up for the patch sent
earlier in the day. As to "fixes" - when it's not an actual bug, I had
(successfully) asked the bugseng guys to avoid that term, and instead
use "addresses" or "eliminates
flight 184371 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184371/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9971b99461e930008e3d35bc0a4a310b6afa57f6
baseline version:
ovmf a4b8944e27f497b0f4dbf
On Mon, 2024-01-15 at 15:37 +0100, Jan Beulich wrote:
> Use the generic framework in xen/linkage.h. No change in generated
> code
> except of course the converted symbols change to be hidden ones and
> gain
> a valid size.
>
> Signed-off-by: Jan Beulich
> ---
> Probably count_args_exp() should mo
Fixes MISRA XXX
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Roberto Bagnara
CC: Federico Serafini
CC: consult...@bugseng.co
Hi,
On 15/01/2024 16:16, Julien Grall wrote:
On 15/01/2024 15:43, Carlo Nonato wrote:
Hi Julien,
Hi Carlo,
On Mon, Jan 15, 2024 at 12:18 PM Julien Grall wrote:
On 15/01/2024 10:11, Carlo Nonato wrote:
I understand what you're talking about, and it seems reasonable to
get rid of
xen_color
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to work out where each piece of Xen reside.
An easy way to solve the issue is to have all code/data accessed
by the seco
1 - 100 of 114 matches
Mail list logo
