flight 180464 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180464/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 180407
build-arm64
On Fri, 28 Apr 2023, GitLab wrote:
> Pipeline #852233694 triggered by
> [568538936b4ac45a343cb3a4ab0c6cda?s=48&d=identicon]
> Ganis
> had 3 failed jobs
> Failed jobs
> ✖
> test
> qemu-smoke-dom0less-arm64-gcc
This is a real failure on staging. Unfortunately it is intermittent. It
usually happens o
flight 180461 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180461/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail in
180428 pass in 180461
test-amd64-i386-
Hi Jan,
On Mon, 2023-04-24 at 17:35 +0200, Jan Beulich wrote:
> On 24.04.2023 17:16, Oleksii wrote:
> > On Mon, 2023-04-24 at 12:18 +0200, Jan Beulich wrote:
> > > On 21.04.2023 18:01, Oleksii wrote:
> > > > On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich wrote:
> > > > > On 19.04.2023 17:42, Oleks
flight 180460 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180460/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180424
test-armhf-armhf-libvirt-qcow2 15 saveres
flight 180471 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180471/
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
Updated the license header in a separate comment of its own.
Signed-off-by: Ayan Kumar Halder
---
This was highlighted in the following review -
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg141930.html
xen/arch/riscv/include/asm/csr.h| 3 +--
xen/arch/riscv/includ
Refer ARM DDI 0406C.d ID040418, B3-1345,
"A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
- With a first-level lookup, accessing a first-level translation
table with 2-16 entries.
- With a second-level lookup, accessing a set of concatenated
flight 180452 xen-unstable real [real]
flight 180472 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180452/
http://logs.test-lab.xenproject.org/osstest/logs/180472/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_root_level can be obtained from pa_range_info[].sl0.
R
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The frame numbers are expressed using unsigned long.
Now if 64-bit >> PAGE_SHIFT, the result will have 52-bits as valid. On a
As the callback function in dt_for_each_range() uses 'uint64_t' as the datatype
for the arguments, so one needs to change the type of parameters in
is_bar_valid() as well.
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1-v5 - New patch introduced in v6.
xen/arch/arm/pci/pci-host-common.
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring an array of page table
offs
In the callback functions invoked by dt_for_each_range() ie handle_pci_range(),
map_range_to_domain(), 'u64' should be replaced with 'uint64_t' as the data type
for the parameters. Also dt_for_each_range() invokes the callback functions with
'uint64_t' arguments.
There is another callback function
As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
configs to choose if the physic
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.
This also helps us as p2maddr is 'paddr_t' (wh
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
dt_device_get_paddr() which accepts address/size as paddr_t
The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
currently accept or return 64-bit values.
In future when we support 32-bit physical address, these DT functions are
expected to accept/return 32-bit or 64-bit values (depending on the width of
physical address). Also, we
rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
Arm32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t' to
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32-bit
physical addresses and has no suppor
flight 180470 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180470/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 56e9828380b7425678a080bd3a08e7c741af67ba
baseline version:
ovmf ecbcff0f4935395f66ecc
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> index 6b11775d4c..533e3c1314 100644
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -1959,15 +1959,14 @@ int xc_domain_memory_mapping(
> uint
flight 180457 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 180278
test-amd64-amd64-li
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> xc_domain_getinfolist() internally relies on a sysctl that performs
> a linear search for the domids. Many callers of xc_domain_getinfolist()
> who require information about a precise domid are much better off calling
> xc_domain_getinfo_single() i
Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> This patch is part of an effort to remove the aio_disable_external()
> API because it does not fit in a multi-queue block layer world where
> many AioContexts may be submitting requests to the same disk.
>
> The SCSI emulation code is alrea
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> It previously mimicked the getdomaininfo sysctl semantics by returning
> the first domid higher than the requested domid that does exist. This
> unintuitive behaviour causes quite a few mistakes and makes the call
> needlessly slow in its error pat
On Thu, Apr 06, 2023 at 02:28:18PM +0530, Viresh Kumar wrote:
> The strings won't be an exact match, as we are only looking to match the
> prefix here, i.e. "virtio,device". This is already done properly in
> libxl_virtio.c file, lets do the same here too.
>
> Fixes: 43ba5202e2ee ("libxl: add supp
On Thu, Apr 06, 2023 at 02:28:17PM +0530, Viresh Kumar wrote:
> For generic virtio devices, where we don't need to add compatible or
> other special DT properties, the type field is set to "virtio,device".
>
> But this misses the case where the user sets the type with a valid
> virtio device id as
Hi Rahul,
On 28/04/2023 13:36, Rahul Singh 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.
Xen 4.17 supports the creation of static evtchns. To allow user space
On 28/04/2023 2:27 pm, Juergen Gross wrote:
> Xenstore consists of more files than just the tools/xenstore directory.
>
> Add them to the XENSTORE block.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
Xenstore consists of more files than just the tools/xenstore directory.
Add them to the XENSTORE block.
Suggested-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0e5eba2312..f2f1881b32 10064
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> It currently relies on xc_domain_getinfo() returning the next available
> domain past "first_domid", which is a feature that will disappear in a
> future patch.
>
> Furthermore and while at it, make it so the hypercall tries to fetch
> information
On Fri, Apr 28, 2023 at 01:33:45PM +0100, Andrew Cooper wrote:
> On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> > It has 2 avoidable occurences
> >
> > * Check whether a domain is valid, which can be done faster with
> > xc_domain_getinfo_single()
> > * Domain discovery, which can be done m
Sounds good to me.
Cheers,
Alejandro
On Fri, Apr 28, 2023 at 01:40:50PM +0100, Andrew Cooper wrote:
> I'm recommend having a comment here, saying something like /* Commonly
> dom0 is the only domain, but buffer a little for efficiency. */
>
> Because this is also the justification for why we don
On 28/04/2023 1:33 pm, Andrew Cooper wrote:
> On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
>> It has 2 avoidable occurences
>>
>> * Check whether a domain is valid, which can be done faster with
>> xc_domain_getinfo_single()
>> * Domain discovery, which can be done much faster with the sysc
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> diff --git a/tools/helpers/init-xenstore-domain.c
> b/tools/helpers/init-xenstore-domain.c
> index 0950ba7dc5..e210a2677e 100644
> --- a/tools/helpers/init-xenstore-domain.c
> +++ b/tools/helpers/init-xenstore-domain.c
> @@ -322,16 +323,19 @@ err:
Xen 4.17 supports the creation of static evtchns. To allow user space
application to bind static evtchns introduce new ioctl
"IOCTL_EVTCHN_BIND_STATIC". Existing IOCTL doing more than binding
that’s why we need to introduce the new IOCTL to only bind the static
event channels.
Also, static evtchns
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> It has 2 avoidable occurences
>
> * Check whether a domain is valid, which can be done faster with
> xc_domain_getinfo_single()
> * Domain discovery, which can be done much faster with the sysctl
> interface through xc_domain_getinfolist().
flight 180449 qemu-mainline real [real]
flight 180468 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180449/
http://logs.test-lab.xenproject.org/osstest/logs/180468/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On Thu, Apr 27, 2023 at 8:49 AM Jennifer Herbert
wrote:
>
>
> On 26/04/2023 21:27, Jason Andryuk wrote:
> > Hi, Jennifer,
> >
> > On Tue, Apr 25, 2023 at 1:48 PM Jennifer Herbert
> > wrote:
> >> This patch makes the TPM version, for which the ACPI libary probes,
> >> configurable.
> >> If acpi_c
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> index e939d07157..6b11775d4c 100644
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -345,6 +345,29 @@ int xc_dom_vuart_init(xc_interface *xch,
>
On 28/04/2023 11:41 am, Alejandro Vallejo wrote:
> xc_domain_getinfo() is slow and prone to races because N hypercalls are
> needed to find information about N domains. xc_domain_getinfolist() finds
> the same information in a single hypercall as long as a big enough buffer
> is provided. Plus, xc_
flight 180467 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180467/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ecbcff0f4935395f66ecc9e9ac76b804ecdec2e8
baseline version:
ovmf 95ef765839a8d0de52095
On Fri, Apr 28, 2023 at 11:41:18AM +0100, Alejandro Vallejo wrote:
> xc_domain_getinfo() is slow and prone to races because N hypercalls are
> needed to find information about N domains. xc_domain_getinfolist() finds
> the same information in a single hypercall as long as a big enough buffer
> is p
It previously mimicked the getdomaininfo sysctl semantics by returning
the first domid higher than the requested domid that does exist. This
unintuitive behaviour causes quite a few mistakes and makes the call
needlessly slow in its error path.
This patch removes the fallback search, returning -ES
Move calls that require a information about a single precisely identified
domain to the new xc_domain_getinfo_single().
Signed-off-by: Alejandro Vallejo
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Tim Deegan
Cc: George Dunlap
Cc: Juergen Gross
---
tools/console/client/main.c
It has 2 avoidable occurences
* Check whether a domain is valid, which can be done faster with
xc_domain_getinfo_single()
* Domain discovery, which can be done much faster with the sysctl
interface through xc_domain_getinfolist().
Signed-off-by: Alejandro Vallejo
---
Cc: Andrew Cooper
C
It currently relies on xc_domain_getinfo() returning the next available
domain past "first_domid", which is a feature that will disappear in a
future patch.
Furthermore and while at it, make it so the hypercall tries to fetch information
about more than one domain per hypercall so we can (hopefull
xc_domain_getinfolist() internally relies on a sysctl that performs
a linear search for the domids. Many callers of xc_domain_getinfolist()
who require information about a precise domid are much better off calling
xc_domain_getinfo_single() instead, that will use the getdomaininfo domctl
instead an
v2:
* Various stylistic changes to match Xen style
* Removed hardcoded ARRAY_SIZE() macro in favour of common-macros.h
* Changed error handling convention of xc_domain_getinfo_single()
to return {0,-1}/errno
* Removed error handling overrides on xc_getininfo_single() callers
* Improved some
xc_domain_getinfo() is slow and prone to races because N hypercalls are
needed to find information about N domains. xc_domain_getinfolist() finds
the same information in a single hypercall as long as a big enough buffer
is provided. Plus, xc_domain_getinfo() is disappearing on a future patch
so mig
It's a stricter version of xc_domain_getinfo() where the returned domid
always matches the requested domid or the error code shows an error instead.
A few patches ahead usages of xc_domain_getinfo() are removed until only
xc_domain_getinfo_single() and xc_domain_getinfolist() remain.
Signed-off-by
Introduced as part of XSA-228, the maptrack_freelist_lock is meant to
protect all accesses to entries in the vCPU freelist as well as the
head and tail pointers.
However, this principle is violated twice in get_maptrack_handle(),
where the tail pointer is directly accessed without taking the lock.
If PIE is enabled, all symbol references would be RIP-relative. However,
PVH booting runs in low address space, which could cause wrong x86_init
callbacks assignment. Since init_top_pgt has building high kernel
address mapping, let PVH booting runs in high address space to make all
things right.
P
In order to unify FIXADDR_TOP for x86 and allow fixmap area to be
moveable, vsyscall page should be mapped individually. However, for
XENPV guest, vsyscall page needs to be mapped into user pagetable too.
So introduce a new PVMMU op to help to map vsyscall page.
Suggested-by: Lai Jiangshan
Signed
startup_64() and startup_xen() both use fixed_percpu_data to set up GS
base. So for consitency, use it too in PVH entry.
Signed-off-by: Hou Wenlong
Cc: Thomas Garnier
Cc: Lai Jiangshan
Cc: Kees Cook
---
arch/x86/platform/pvh/head.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
dif
For PIE binary, all symbol references are PC-relative addressing, even
for percpu variable. So to keep compatible with PIE, add %rip suffix in
percpu assembly macros if PIE is enabled. However, relocation of percpu
variable references is broken now for PIE. It would be fixed later.
Suggested-by: L
If vsyscall page is moved out of fixmap area, then FIXADDR_TOP would be
below vsyscall page. So it should pin up to VSYSCALL_ADDR if vsyscall is
enabled.
Suggested-by: Lai Jiangshan
Signed-off-by: Hou Wenlong
Cc: Thomas Garnier
Cc: Kees Cook
---
arch/x86/xen/mmu_pv.c | 12 +---
1 file
From: Brian Gerst
From: Brian Gerst
If the compiler supports it, use a standard per-cpu variable for the
stack protector instead of the old fixed location. Keep the fixed
location code for compatibility with older compilers.
[Hou Wenlong: Disable it on Clang, adapt new code change and adapt
m
flight 180463 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180463/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 95ef765839a8d0de52095e3dec3584fc347b94b2
baseline version:
ovmf e5e1cd1a83e2e7aa2179d
On Fri, Apr 28, 2023 at 9:12 AM George Dunlap
wrote:
> The initial goal of SUPPORT.md was to help both users, and the Xen
> Project Security Team, determine what functionality was security
> supported; i.e., what kinds of security bugs would trigger an XSA.
>
> Our proposal is that as of 4.18, al
The initial goal of SUPPORT.md was to help both users, and the Xen
Project Security Team, determine what functionality was security
supported; i.e., what kinds of security bugs would trigger an XSA.
Our proposal is that as of 4.18, all functionality not explicitly
listed as security supported will
Please ignore patches 1-4 of this series...
-George
On Fri, Apr 28, 2023 at 9:08 AM George Dunlap
wrote:
> The credit scheduler tries as hard as it can to ensure that it always
> runs scheduling units with positive credit (PRI_TS_UNDER) before
> running those with negative credit (PRI_TS_OVER)
A recent xentrace highlighted an unhandled corner case in the vcpu
"start-of-day" logic, if the trace starts after the last running ->
non-running transition, but before the first non-running -> running
transition. Because start-of-day wasn't handled, vcpu_next_update()
was expecting p->current to
On large systems with many vcpus yielding due to spinlock priority
inversion, it's not uncommon for a vcpu to yield its timeslice, only
to be immediately stolen by another pcpu looking for higher-priority
work.
To prevent this:
* Keep the YIELD flag until a vcpu is removed from a runqueue
* When
The initial goal of SUPPORT.md was to help both users, and the Xen
Project Security Team, determine what functionality was security
supported; i.e., what kinds of security bugs would trigger an XSA.
Our proposal is that as of 4.18, all functionality not explicitly
listed as security supported will
The credit scheduler tries as hard as it can to ensure that it always
runs scheduling units with positive credit (PRI_TS_UNDER) before
running those with negative credit (PRI_TS_OVER). If the next
runnable scheduling unit is of priority OVER, it will always run the
load balancer, which will scour
For now, mainly just do volume analysis and get rid of the warnings.
Signed-off-by: George Dunlap
---
CC: Wei Liu
CC: Anthony PERARD
---
tools/xentrace/xenalyze.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/x
On 27.04.23 19:37, Julien Grall wrote:
Hi Juergen,
On 26/04/2023 08:19, Juergen Gross wrote:
On 05.04.23 09:03, Juergen Gross wrote:
This series reworks the Xenstore internal accounting to use a uniform
generic framework. It is adding some additional useful diagnostic
information, like account
On 27.04.23 18:32, Julien Grall wrote:
Hi,
On 26/04/2023 08:08, Juergen Gross wrote:
On 25.04.23 19:52, Julien Grall wrote:
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Instead of modifying accounting data and undo those modifications in
case of an error during further processing, a
71 matches
Mail list logo
