flight 176080 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176080/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-raw 7 xen-install fail in 176069 pass in 176080
test-arm64-arm64-xl-credit2
flight 176076 xen-unstable real [real]
flight 176088 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176076/
http://logs.test-lab.xenproject.org/osstest/logs/176088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 176072 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176072/
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
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.c: No such file or directory.
(gdb) bt
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: error: Failed to set d1's policy (err leaf
Two toolstack fixes for guest kexec. This restored kexec enough that I
got Debian bullseye to kexec once. Trying to kexec the guest a second
time had it spinning at 100% CPU after initiating the kexec. Haven't
looked into that part yet.
Regards,
Jason
Jason Andryuk (2):
libxl: Fix guest
On Mon, Jan 23, 2023 at 11:09:13PM +, Andrew Cooper wrote:
> On 19/01/2023 1:05 pm, Bobby Eshleman wrote:
> > 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.
On Mon, 23 Jan 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 23/01/2023 22:52, Stefano Stabellini wrote:
> > On Fri, 16 Dec 2022, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Implement the same command line option as x86 to enable/disable the
> > > directmap. By default this is
On Tue, Jan 24, 2023 at 9:09 AM Andrew Cooper wrote:
>
> On 19/01/2023 1:05 pm, Bobby Eshleman wrote:
> > 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.
> >>
>
flight 176069 qemu-mainline real [real]
flight 176078 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176069/
http://logs.test-lab.xenproject.org/osstest/logs/176078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> xen/arch/riscv/setup.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index d09ffe1454..174e134c93 100644
> ---
Hi Stefano,
On 23/01/2023 22:52, Stefano Stabellini wrote:
On Fri, 16 Dec 2022, Julien Grall wrote:
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
On 19/01/2023 1:05 pm, Bobby Eshleman wrote:
> 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.
On Mon, 23 Jan 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 23/01/2023 21:19, Stefano Stabellini wrote:
> > 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
On Mon, 23 Jan 2023, Julien Grall wrote:
> On 23/01/2023 22:03, Stefano Stabellini wrote:
> > On Fri, 16 Dec 2022, Julien Grall 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
On Fri, 16 Dec 2022, Julien Grall wrote:
> 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.
>
>
On Fri, 16 Dec 2022, Julien Grall wrote:
> 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
On Mon, 2023-01-23 at 18:56 +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
Hi,
On 23/01/2023 22:03, Stefano Stabellini wrote:
On Fri, 16 Dec 2022, Julien Grall 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
On Fri, 16 Dec 2022, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, on Arm64, every pCPU are 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
Hi Stefano,
On 23/01/2023 21:19, Stefano Stabellini wrote:
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
On Fri, 16 Dec 2022, Julien Grall wrote:
> From: Julien Grall
>
> The arm32 version of init_secondary_pagetables() will soon be re-used
> for arm64 as well where the root table start at level 0 rather than level 1.
>
> So rename 'first' to 'root'.
>
> Signed-off-by: Julien Grall
Reviewed-by:
On Fri, 16 Dec 2022, Julien Grall 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 a
Hi Stefano,
On 23/01/2023 21:45, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 68adcac9fa8d..2366928d71aa 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -406,6 +406,11 @@ static inline void
Hi Stefano,
On 23/01/2023 21:29, Stefano Stabellini wrote:
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
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
>
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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...
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
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
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, );
>> }
>>
>>
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
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
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
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
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 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
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
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
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
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:
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
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
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
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
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
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
---
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
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
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
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 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"
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: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
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
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
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
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
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
---
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
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
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
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
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 )
>
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:
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
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
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
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
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
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
>
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).
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
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 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 @@
> > +/*
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
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 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
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
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
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
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:
- :
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
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
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
1 - 100 of 125 matches
Mail list logo
