flight 176059 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176059/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 37d3eb026a766b2405daae47e02094c2ec248646
baseline version:
ovmf 7afef31b2b17d1a8d5248
While the table is used only when HVM=y, the table entry of course needs
to be properly populated when also PV32=y. Fully removing the table
entry we therefore wrong.
Fixes: 1894049fa283 ("x86/shadow: L2H shadow type is PV32-only")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/hvm.c
++
On 21.01.23 22:39, Jason Andryuk wrote:
When a domain performs a kexec (soft reset), libxl__build_pre() is
called with the existing domid. Calling libxl__cpuid_legacy() on the
existing domain fails since the cpuid policy has already been set, and
the guest isn't rebuilt and doesn't kexec.
xc: e
On 21.01.23 22:39, Jason Andryuk wrote:
I'm observing guest kexec trigger xenstored to abort on a double free.
gdb output:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140645614258112) at
./nptl/pthread_kill.c:44
44./nptl/pthread_kill.
On 20.01.2023 19:15, Andrew Cooper wrote:
> On 18/01/2023 9:55 am, Jan Beulich wrote:
>> On 17.01.2023 23:04, Andrew Cooper wrote:
>>> On 19/10/2022 8:43 am, Jan Beulich wrote:
Noteworthy differences from map_vcpu_info():
- areas can be registered more than once (and de-registered),
>>> W
flight 176056 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-i386-xl 18 guest-localmigrate fail REGR. vs. 175994
test-amd64-i386-xl
On 20.01.2023 18:02, George Dunlap wrote:
> On Wed, Jan 11, 2023 at 1:52 PM Jan Beulich wrote:
>
>> Rather than doing a separate hash walk (and then even using the vCPU
>> variant, which is to go away), do the up-pointer-clearing right in
>> sh_unpin(), as an alternative to the (now further limit
On 20.01.2023 19:15, Andrew Cooper wrote:
> On 18/01/2023 9:55 am, Jan Beulich wrote:
>> On 17.01.2023 23:04, Andrew Cooper wrote:
>>> On 19/10/2022 8:43 am, Jan Beulich wrote:
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the
Hi Vikram,
On 07/12/2022 07:18, Vikram Garhwal wrote:
>
>
> Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_lock().
s/lock/locked/
>
> Moving spin_lock to caller was done to prevent the concurrent access to
> iommu_dt_device_is_assigned while doing add/remove/assign/deassig
On Fri, Jan 20, 2023 at 06:26:14PM +, Andrew Cooper wrote:
> On 19/01/2023 3:22 pm, Anthony PERARD wrote:
> > `fields` and `extrafields` always all the parts of a sub-struct, so
> > when there is '}', there is always a '{' before it. Also, both are
> > lists.
> >
> > Signed-off-by: Anthony PERA
On Fri, 2023-01-20 at 15:29 +, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> > Work with some registers requires csr command which is part of
> > Zicsr.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > xen/arch/riscv/arch.mk | 2 +-
> > 1 file changed, 1 insertio
On 23/01/2023 8:12 am, Jan Beulich wrote:
> While the table is used only when HVM=y, the table entry of course needs
> to be properly populated when also PV32=y. Fully removing the table
> entry we therefore wrong.
>
> Fixes: 1894049fa283 ("x86/shadow: L2H shadow type is PV32-only")
> Signed-off-by
Hi Vikram,
On 07/12/2022 07:18, Vikram Garhwal wrote:
>
>
> Remove master device from the IOMMU.
Adding some description on the purpose would be beneficial.
>
> Signed-off-by: Vikram Garhwal
> ---
> xen/drivers/passthrough/device_tree.c | 38 +++
> xen/include/xen/iom
Hi,
On 23/01/2023 10:00, Michal Orzel wrote:
Signed-off-by: Vikram Garhwal
---
xen/drivers/passthrough/device_tree.c | 38 +++
xen/include/xen/iommu.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/xen/drivers/passthrough/device_tree.c
b/xen/
On 20.01.2023 16:31, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>> Signed-off-by: Oleksii Kurochko
>
> There's some stuff in here which is not RISCV-specific. We really want
> to dedup with the other architectures and move into common.
I have to admit that I'm not ful
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> Add ability to print hex number.
> It might be useful to print register value as debug information
> in BUG(), WARN(), etc...
>
> Signed-off-by: Oleksii Kurochko
Orthogonal to Andrew's reply (following which I think would be best)
a couple of commen
On 23.01.2023 11:43, Andrew Cooper wrote:
> On 23/01/2023 8:12 am, Jan Beulich wrote:
>> While the table is used only when HVM=y, the table entry of course needs
>> to be properly populated when also PV32=y. Fully removing the table
>> entry we therefore wrong.
>>
>> Fixes: 1894049fa283 ("x86/shado
On 23/01/2023 11:00 am, Jan Beulich wrote:
> On 20.01.2023 16:31, Andrew Cooper wrote:
>> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>> There's some stuff in here which is not RISCV-specific. We really want
>> to dedup with the other architectures and move
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> +/* On stack VCPU state */
> +struct cpu_user_regs
> +{
> +register_t zero;
> +register_t ra;
> +register_t sp;
> +register_t gp;
> +register_t tp;
> +register_t t0;
> +register_t t1;
> +register_t t2;
> +register_t
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/entry.S
> @@ -0,0 +1,97 @@
> +#include
> +#include
> +#include
> +#include
> +
> +.global handle_exception
> +.align 4
> +
> +handle_exception:
> +
> +/* Exceptions from xen */
> +save_to_sta
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/bug.h
> @@ -0,0 +1,120 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2021-2023 Vates
> + *
> + */
> +
> +#ifndef
On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S
> new file mode 100644
> index 00..f7d46f42bb
> --- /dev/null
> +++ b/xen/arch/riscv/entry.S
> @@ -0,0 +1,97 @@
> +#include
> +#include
> +#include
> +#include
> +
> +.g
On Fri, 2023-01-20 at 15:54 +, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/include/asm/processor.h
> > b/xen/arch/riscv/include/asm/processor.h
> > new file mode 100644
> > index 00..5898a09ce6
> > --- /dev/null
> > +++ b/xen/arc
On Fri, 2023-01-20 at 15:39 +, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> > Add ability to print hex number.
> > It might be useful to print register value as debug information
> > in BUG(), WARN(), etc...
> >
> > Signed-off-by: Oleksii Kurochko
>
> I think it wo
On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
> index 3201b851ef..dd64f053a5 100644
> --- a/xen/arch/riscv/traps.c
> +++ b/xen/arch/riscv/traps.c
> @@ -4,8 +4,96 @@
> *
> * RISC-V Trap handlers
> */
> +#include
> +#include
> #
On 23/01/2023 10:47 am, Jan Beulich wrote:
> On 23.01.2023 11:43, Andrew Cooper wrote:
>> On 23/01/2023 8:12 am, Jan Beulich wrote:
>>> While the table is used only when HVM=y, the table entry of course needs
>>> to be properly populated when also PV32=y. Fully removing the table
>>> entry we there
On 23.01.2023 13:30, Andrew Cooper wrote:
> On 23/01/2023 10:47 am, Jan Beulich wrote:
>> On 23.01.2023 11:43, Andrew Cooper wrote:
>>> On 23/01/2023 8:12 am, Jan Beulich wrote:
While the table is used only when HVM=y, the table entry of course needs
to be properly populated when also PV3
On 23/01/2023 12:03 pm, Oleksii wrote:
> On Fri, 2023-01-20 at 15:54 +, Andrew Cooper wrote:
>> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>>> +
>>> +#define RISCV_CPU_USER_REGS_OFFSET(x) ((RISCV_CPU_USER_REGS_##x)
>>> * __SIZEOF_POINTER__)
>>> +#define RISCV_CPU_USER_REGS_SIZE
>>>
At the moment, the static-mem check relies on the way Xen exposes the
memory banks in device tree. As this might change, the check should be
modified to be generic and not to rely on device tree. In this case,
let's use /proc/iomem which exposes the memory ranges in %08x format
as follows:
- :
Th
On 23.01.2023 12:50, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>> +csrrt0, CSR_SEPC
>> +REG_S t0, RISCV_CPU_USER_REGS_OFFSET(sepc)(sp)
>> +csrrt0, CSR_SSTATUS
>> +REG_S t0, RISCV_CPU_USER_REGS_OFFSET(sstatus)(sp)
>
> So someth
1. One should use 'PRIpaddr' to display 'paddr_t' variables. However,
while creating nodes in fdt, the address (if present in the node name)
should be represented using 'PRIx64'. This is to be in conformance
with the following rule present in https://elinux.org/Device_Tree_Linux
. node names
"unit
Hi All,
These series include some patches and fixes identified during the review of
"[XEN v2 00/11] Add support for 32 bit physical address".
Patch 1/3 : The previous version causes CI to fail. This patch attempts to fix
this.
Patch 2/3 : This was pointed by Jan during the review of
"[XEN v2 05/
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
I was about to commit this, but ...
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
> @@ -0,0 +1,945 @@
> +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */
> +/*
> + * Copyright (c
One should be using simple_strtoull() ( instead of simple_strtoul() )
to assign value to 'u64' variable. The reason being u64 can be
represented by 'unsigned long long' on all the platforms (ie Arm32,
Arm64 and x86).
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1,v2 - NA (This patch is
On 23.01.2023 14:44, Ayan Kumar Halder wrote:
> One should be using simple_strtoull() ( instead of simple_strtoul() )
> to assign value to 'u64' variable. The reason being u64 can be
> represented by 'unsigned long long' on all the platforms (ie Arm32,
> Arm64 and x86).
Suggested-by: Jan Beulich
On Mon, 2023-01-23 at 14:52 +0100, Jan Beulich wrote:
> On 20.01.2023 15:59, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> I was about to commit this, but ...
>
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
> > @@ -0,0 +1,945 @@
> > +/* SPDX-License-Id
On 23.01.2023 15:04, Oleksii wrote:
> On Mon, 2023-01-23 at 14:52 +0100, Jan Beulich wrote:
>> On 20.01.2023 15:59, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>
>> I was about to commit this, but ...
>>
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h
>>> @
On 20.01.2023 15:59, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/csr.h
> @@ -0,0 +1,82 @@
> +/*
> + * Take from Linux.
This again means you want an Origin: tag. Whether the comment itself is
useful depends on how much customization you expect there to be down
the roa
On Mon, 2023-01-23 at 14:57 +0100, Jan Beulich wrote:
> On 20.01.2023 15:59, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/csr.h
> > @@ -0,0 +1,82 @@
> > +/*
> > + * Take from Linux.
>
> This again means you want an Origin: tag. Whether the comment itself
> is
> us
uart->io_size represents the size in bytes. Thus, when serial_port.bit_width
is assigned to it, it should be converted to size in bytes.
Fixes: 17b516196c55 ("ns16550: add ACPI support for ARM only")
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1, v2 - NA (New patch introduced in v3).
The original 2nd patch of v1 was split into two and extended by a 3rd
(1st one here) one.
1: move dm-mmio handling code in sh_page_fault()
2: mark more of sh_page_fault() HVM-only
3: drop dead code from HVM-only sh_page_fault() pieces
Jan
Do away with the partly mis-named "mmio" label there, which really is
only about emulated MMIO. Move the code to the place where the sole
"goto" was. Re-order steps slightly: Assertion first, perfc increment
outside of the locked region, and "gpa" calculation closer to the first
use of the variable
The types p2m_is_readonly() checks for aren't applicable to PV;
specifically get_gfn() won't ever return any such type for PV domains.
Extend the HVM-conditional block of code, also past the subsequent HVM-
only if(). This way the "emulate_readonly" also becomes unreachable when
!HVM, so move the c
The shadow_mode_refcounts() check immediately ahead of the "emulate"
label renders redundant two subsequent is_hvm_domain() checks (the
latter of which was already redundant with the former).
Also guest_mode() checks are pointless when we already know we're
dealing with a HVM domain.
Finally styl
On 1/23/23 15:10, Michal Orzel wrote:
At the moment, the static-mem check relies on the way Xen exposes the
memory banks in device tree. As this might change, the check should be
modified to be generic and not to rely on device tree. In this case,
let's use /proc/iomem which exposes the memory
On 23.01.2023 15:23, Oleksii wrote:
> On Mon, 2023-01-23 at 14:57 +0100, Jan Beulich wrote:
>> On 20.01.2023 15:59, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/csr.h
>>> @@ -0,0 +1,82 @@
>>> +/*
>>> + * Take from Linux.
>>
>> This again means you want an Origin: t
On Mon, Jan 16, 2023 at 2:47 PM Jan Beulich wrote:
>
> On 11.01.2023 15:23, Sergey Dyasli wrote:
> > --- a/xen/arch/x86/cpu/microcode/amd.c
> > +++ b/xen/arch/x86/cpu/microcode/amd.c
> > @@ -176,8 +176,13 @@ static enum microcode_match_result compare_revisions(
> > if ( new_rev > old_rev )
>
Since it was indicated that introducing specific new vCPU ops may be
beneficial independent of the introduction of a fully physical-
address-based ABI flavor, here we go. There continue to be a number of
open questions throughout the series, resolving of which is one of the
main goals of this v2 po
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary domain cleanup hooks.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
---
RFC: Zapping the areas in pv_shim_shutd
Before adding a new vCPU operation to register the runstate area by
guest-physical address, add code to actually keep such areas up-to-date.
Note that updating of the area will be done exclusively following the
model enabled by VMASST_TYPE_runstate_update_flag for virtual-address
based registered
Before adding a new vCPU operation to register the secondary time area
by guest-physical address, add code to actually keep such areas up-to-
date.
Note that pages aren't marked dirty when written to (matching the
handling of space mapped by map_vcpu_info()), on the basis that the
registrations ar
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary fork handling (with the
backing function yet to be filled in).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mem_sh
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest-user mode, and for HVM guests they may be
inaccessible when Meltdown
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in guest-user mode.
Introduce a new vCPU operation allowing to register the ru
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Introduce a new vCPU operation allowing to register the secondary time
are
Switch to using map_guest_area(). Noteworthy differences from
map_vcpu_info():
- remote vCPU-s are paused rather than checked for being down (which in
principle can change right after the check),
- the domain lock is taken for a much smaller region,
- the error code for an attempt to re-register
On 23.01.2023 15:32, Sergey Dyasli wrote:
> On Mon, Jan 16, 2023 at 2:47 PM Jan Beulich wrote:
>> On 11.01.2023 15:23, Sergey Dyasli wrote:
>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>> +++ b/xen/arch/x86/cpu/microcode/amd.c
>>> @@ -176,8 +176,13 @@ static enum microcode_match_result compare_revi
On Mon, 2023-01-23 at 12:17 +0100, Jan Beulich wrote:
> On 20.01.2023 15:59, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/entry.S
> > @@ -0,0 +1,97 @@
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > + .global handle_exception
> > + .align 4
On 23.01.2023 15:26, Jan Beulich wrote:
> Do away with the partly mis-named "mmio" label there, which really is
> only about emulated MMIO. Move the code to the place where the sole
> "goto" was. Re-order steps slightly: Assertion first, perfc increment
> outside of the locked region, and "gpa" cal
On Mon, 2023-01-23 at 11:50 +, Andrew Cooper wrote:
> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S
> > new file mode 100644
> > index 00..f7d46f42bb
> > --- /dev/null
> > +++ b/xen/arch/riscv/entry.S
> > @@ -0,0 +1,97 @@
On Mon, Jan 23, 2023 at 8:41 AM Jan Beulich wrote:
> On 20.01.2023 18:02, George Dunlap wrote:
> > On Wed, Jan 11, 2023 at 1:52 PM Jan Beulich wrote:
> >
> >> Rather than doing a separate hash walk (and then even using the vCPU
> >> variant, which is to go away), do the up-pointer-clearing right
Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent sof
From: Luca Miccio
This commit allows the user to set the cache coloring configuration for
Dom0 via a command line parameter.
Since cache coloring and static memory are incompatible, direct mapping
Dom0 isn't possible when coloring is enabled.
Here is also introduced a common configuration syntax
This commit adds the "llc-colors" Device Tree attribute that can be used
for DomUs and Dom0less color configurations. The syntax is the same used
for every color config.
Based on original work from: Luca Miccio
Signed-off-by: Carlo Nonato
Signed-off-by: Marco Solieri
---
docs/misc/arm/cache-c
Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
range
This commit implements functions declared in the LLC coloring common header
for arm64 and adds documentation. It also adds two command line options: a
runtime switch for the cache coloring feature and the LLC way size
parameter.
The feature init function consists of an auto probing of the cache la
This commit updates the domctl interface to allow the user to set cache
coloring configurations from the toolstack.
It also implements the functionality for arm64.
Based on original work from: Luca Miccio
Signed-off-by: Carlo Nonato
Signed-off-by: Marco Solieri
---
v4:
- updated XEN_DOMCTL_INT
This reverts commit 0c18fb76323bfb13615b6f13c98767face2d8097 (not clean).
This is not a clean revert since the rework of the memory layout, but it is
sufficiently similar to a clean one.
The only difference is that the BOOT_RELOC_VIRT_START must match the new
layout.
Cache coloring support for Xe
This commit adds the Last Level Cache (LLC) coloring common header,
Kconfig options and stub functions for domain coloring. Since this is an
arch specific feature, actual implementation is postponed to later patches
and Kconfig options are placed under xen/arch.
LLC colors are represented as dynam
Cache colored domains can benefit from having p2m page tables allocated
with the same coloring schema so that isolation can be achieved also for
those kind of memory accesses.
In order to do that, the domain struct is passed to the allocator and the
MEMF_no_owner flag is used.
Signed-off-by: Carlo
From: Luca Miccio
This commit adds a new memory page allocator that implements the cache
coloring mechanism. The allocation algorithm follows the given domain color
configuration and maximizes contiguity in the page selection of multiple
subsequent requests.
Pages are stored in a color-indexed a
From: Luca Miccio
This commit adds a new command line parameter to configure Xen cache
colors. These colors can be dumped with the cache coloring info debug-key.
By default, Xen uses the first color.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most la
This commit adds the cache coloring support for Xen own physical space.
It extends the implementation of setup_pagetables() to make use of Xen
cache coloring configuration. Page tables construction is essentially the
same except for the fact that PTEs point to a new temporary mapped,
physically co
On 23.01.2023 16:47, Carlo Nonato wrote:
> Shared caches in multi-core CPU architectures represent a problem for
> predictability of memory access latency. This jeopardizes applicability
> of many Arm platform in real-time critical and mixed-criticality
> scenarios. We introduce support for cache p
On 23/01/2023 14:30, Xenia Ragiadakou wrote:
On 1/23/23 15:10, Michal Orzel wrote:
At the moment, the static-mem check relies on the way Xen exposes the
memory banks in device tree. As this might change, the check should be
modified to be generic and not to rely on device tree. In this case,
On Mon, Jan 23, 2023 at 9:55 AM Jan Beulich wrote:
>
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary fork handling (with the
> backing function yet to be filled i
On 23.01.2023 16:20, George Dunlap wrote:
> Re the original question: I've stared at the code for a bit now, and I
> can't see anything obviously wrong or dangerous about it.
>
> But it does make me ask, why do we need the "unpinning_l3" pseudo-argument
> at all? Is there any reason not to uncond
Hi Jan,
On Mon, Jan 23, 2023 at 4:52 PM Jan Beulich wrote:
>
> On 23.01.2023 16:47, Carlo Nonato wrote:
> > Shared caches in multi-core CPU architectures represent a problem for
> > predictability of memory access latency. This jeopardizes applicability
> > of many Arm platform in real-time criti
On 12/12/2022 09:55, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Julien Grall
Per D5-4929 in ARM DDI 0487H.a:
"A DSB NSH is sufficient
On 23.01.2023 17:09, Tamas K Lengyel wrote:
> On Mon, Jan 23, 2023 at 9:55 AM Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1653,6 +1653,65 @@ static void copy_vcpu_nonreg_state(struc
>> hvm_set_nonreg_state(cd_vcpu, &nrs);
>> }
>>
>>
On 23.01.2023 13:49, Jan Beulich wrote:
> On 23.01.2023 13:30, Andrew Cooper wrote:
>> On 23/01/2023 10:47 am, Jan Beulich wrote:
>>> On 23.01.2023 11:43, Andrew Cooper wrote:
On 23/01/2023 8:12 am, Jan Beulich wrote:
> While the table is used only when HVM=y, the table entry of course nee
Hi Alistair and community,
I am working on RISC-V support upstream for Xen based on your and Bobby
patches.
Adding the RISC-V support I realized that Xen is ran in S-mode. Output
of OpenSBI:
...
Domain0 Next Mode : S-mode
...
So the first my question is shouldn't it be in H-mo
On 23.01.2023 17:56, Jan Beulich wrote:
> On 23.01.2023 13:49, Jan Beulich wrote:
>> On 23.01.2023 13:30, Andrew Cooper wrote:
>>> This is a layering violation which has successfully tricked you into
>>> making a buggy patch.
>>>
>>> I'm unwilling to bet this will be the final time either... "this
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
We need a new helper for Xen to enable MPU in boot-time.
The new helpe
flight 176060 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
flight 176066 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176066/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Mon, Jan 23, 2023 at 11:24 AM Jan Beulich wrote:
>
> On 23.01.2023 17:09, Tamas K Lengyel wrote:
> > On Mon, Jan 23, 2023 at 9:55 AM Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/mem_sharing.c
> >> +++ b/xen/arch/x86/mm/mem_sharing.c
> >> @@ -1653,6 +1653,65 @@ static void copy_vcpu_nonreg_sta
flight 176062 xen-unstable real [real]
flight 176073 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176062/
http://logs.test-lab.xenproject.org/osstest/logs/176073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 23/01/2023 3:17 pm, Oleksii wrote:
> On Mon, 2023-01-23 at 11:50 +, Andrew Cooper wrote:
>> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>>> + /* Save context to stack */
>>> + REG_S sp, (RISCV_CPU_USER_REGS_OFFSET(sp) -
>>> RISCV_CPU_USER_REGS_SIZE) (sp)
>>> + addi
On Mon, 23 Jan 2023, Michal Orzel wrote:
> At the moment, the static-mem check relies on the way Xen exposes the
> memory banks in device tree. As this might change, the check should be
> modified to be generic and not to rely on device tree. In this case,
> let's use /proc/iomem which exposes the
On Sat, 21 Jan 2023, Chuck Zmudzinski wrote:
> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> as noted in docs/igd-assign.txt in the Qemu source code.
>
> Currently, when the xl toolstack is used to configure a Xen HVM guest with
> Intel IGD passthrough to the guest with t
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
testid guest-localmigrate
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits
On Mon, Jan 23, 2023 at 06:56:19PM +0200, Oleksii wrote:
> Hi Alistair and community,
>
> I am working on RISC-V support upstream for Xen based on your and Bobby
> patches.
>
> Adding the RISC-V support I realized that Xen is ran in S-mode. Output
> of OpenSBI:
> ...
> Domain0 Next Mode
On Mon, 23 Jan 2023, Ayan Kumar Halder wrote:
> 1. One should use 'PRIpaddr' to display 'paddr_t' variables. However,
> while creating nodes in fdt, the address (if present in the node name)
> should be represented using 'PRIx64'. This is to be in conformance
> with the following rule present in ht
On Mon, 23 Jan 2023, Ayan Kumar Halder wrote:
> uart->io_size represents the size in bytes. Thus, when serial_port.bit_width
> is assigned to it, it should be converted to size in bytes.
>
> Fixes: 17b516196c55 ("ns16550: add ACPI support for ARM only")
> Signed-off-by: Ayan Kumar Halder
Reviewe
On Fri, 16 Dec 2022, Julien Grall wrote:
> From: Julien Grall
>
> Order the includes with the xen headers first, then asm headers and
> last public headers. Within each category, they are sorted alphabetically.
>
> Note that the includes in protected by CONFIG_X86 hasn't been sorted
> to avoid a
On Fri, 16 Dec 2022, Julien Grall wrote:
> From: Wei Liu
>
> After the direct map removal, pages from the boot allocator are not
> mapped at all 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 me
On Fri, 16 Dec 2022, Julien Grall wrote:
> 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 dependences are a mess. We would need to re-include
> asm/page.h (was r
On Fri, 16 Dec 2022, Julien Grall wrote:
> 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 boot command line option, not a Kconfig to allow
> the user to experiment the feature without
On Fri, 16 Dec 2022, Julien Grall wrote:
> 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
> alia
1 - 100 of 125 matches
Mail list logo
