On 03.02.23 02:28, Gustavo A. R. Silva wrote:
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct xen_page_directory.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
On 03.01.23 14:02, Per Bilse wrote:
/proc/xen is a legacy pseudo filesystem which predates Xen support
getting merged into Linux. It has largely been replaced with more
normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
user devices). We want to compile xenfs support out of the
On 16.12.22 17:21, Krister Johansen wrote:
Kvm elects to use tsc instead of kvm-clock when it can detect that the
TSC is invariant.
(As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if
invariant TSC is exposed")).
Notable cloud vendors[1] and performance engineers[2] recommend tha
On 18.01.23 13:22, David Woodhouse wrote:
From: David Woodhouse
When we don't use the per-CPU vector callback, we ask Xen to deliver event
channel interrupts as INTx on the PCI platform device. As such, it can be
shared with INTx on other PCI devices.
Set IRQF_SHARED, and make it return IRQ_HA
On 19.01.23 22:11, Volodymyr Babchuk wrote:
There is a sequence of events that can lead to a permanently masked
event channel, because xen_irq_lateeoi() is newer called. This happens
when a backend receives spurious write event from a frontend. In this
case pvcalls_conn_back_write() returns early
On 08.02.23 16:36, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Update stub IOMMU driver (which main purpose is to reuse generic
IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm)
according to the recent changes done in the following
commit 57365a04c921 ("iommu: Move bu
On 03.02.23 02:28, Gustavo A. R. Silva wrote:
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct xen_page_directory.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
On 10.02.2023 16:54, Luca Fancellu wrote:
>> On 2 Feb 2023, at 12:05, Jan Beulich wrote:
>> On 02.02.2023 12:08, Luca Fancellu wrote:
>>> (is hw_cap only for x86?)
>>
>> I suppose it is, but I also expect it would better go away than be moved.
>> It doesn't hold a complete set of information, and
Especially PV device drivers often need to read multiple Xenstore
nodes from a common directory. Add support for reading a string or an
unsigned value by specifying the directory and the node.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
V2:
- check sscanf() return value (Samuel
This series is adding minimal support to use 9pfs in Mini-OS. It is
adding a PV 9pfs frontend and the ability to open, close, read and
write files.
The series has been tested with qemu as 9pfs backend in a PVH Mini-OS
guest (I've used a slightly modified Xenstore-stubdom for that purpose
in order
Add the support to mount a device at runtime. The number of dynamic
mounts is limited by a #define.
For devices supporting multiple files struct file is modified to hold
a pointer to file specific data in contrast to device specific data.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
Add the concept of mount points to Mini-OS. A mount point is a path
associated with a device pointer and an open() callback. A mount point
can be either a file (e.g. "/dev/mem") or a directory ("/var/log").
This allows to replace the special casing in the generic open()
handling with a generic mou
Add a frontend for the 9pfs PV device. For now add only the code needed
to connect to the backend and the related disconnect functionality. The
9pfs protocol support will be added later.
Due to its nature (ability to access files) the whole code is guarded
by "#ifdef HAVE_LIBC".
Signed-off-by: Ju
Add the transport layer of 9pfs. This is basically the infrastructure
to send requests to the backend and to receive the related answers via
the rings.
As a first example add the version and attach requests of the 9pfs
protocol when mounting a new 9pfs device. For the version use the
"9P2000.u" va
Add the open() and close() support to the 9pfs frontend. This requires
to split the path name and to walk to the desired directory level.
Signed-off-by: Juergen Gross
---
V2:
- check path to be canonical
- avoid short read when walking the path
- fix get_fid() (Samuel Thibault)
- return EAGAIN if
Add support to read from and write to a file handled by 9pfsfront.
Signed-off-by: Juergen Gross
---
V2:
- add check for max message size
- return EAGAIN in case no free request got (Samuel Thibault)
- loop until all data read/written (Samuel Thibault)
V3:
- use an exact limit for read/write (Samu
On 07.02.23 03:10, Demi Marie Obenour wrote:
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol
On 10.02.2023 00:00, Julien Grall wrote:
> This is a first attempt to replace all the full license text with
> SPX tag in xen/arch/x86/. For now, this is only covering files with GPL 2.0
> and 3 different patterns.
For clarification - the three patterns mentioned here are the three slightly
differ
flight 177125 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177125/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow221 guest-start/debian.repeatfail like 177001
test-amd64-amd64-xl-qemut-win7-amd64
On 07.02.2023 10:43, Xenia Ragiadakou wrote:
> APIC virtualization support is currently implemented only for Intel VT-x.
> To aid future work on separating AMD-V from Intel VT-x code, instead of
> calling directly vmx_vlapic_msr_changed() from common hvm code, add a stub
> to the hvm_function_table
On 30.01.2023 12:55, Sergey Dyasli wrote:
> The original issue has been reported on AMD Bulldozer-based CPUs where
> ucode loading loses the LWP feature bit in order to gain the IBPB bit.
> LWP disabling is per-SMT/CMT core modification and needs to happen on
> each sibling thread despite the share
On 07.12.2022 12:41, Jan Beulich wrote:
> On 03.10.2022 18:21, Marek Marczykowski-Górecki wrote:
>> Documentation for credit2_runqueue=all says it should create one queue
>> for all pCPUs on the host. But since introduction
>> sched_credit2_max_cpus_runqueue, it actually created separate runqueue
>
On 2/13/23 12:09, Jan Beulich wrote:
On 07.02.2023 10:43, Xenia Ragiadakou wrote:
APIC virtualization support is currently implemented only for Intel VT-x.
To aid future work on separating AMD-V from Intel VT-x code, instead of
calling directly vmx_vlapic_msr_changed() from common hvm code, ad
On 30.01.2023 09:03, Jan Beulich wrote:
> On 30.01.2023 05:35, Christopher Clark wrote:
>> On Mon, Nov 21, 2022 at 4:41 AM Jan Beulich wrote:
>>
>>> On 11.10.2022 11:28, Jan Beulich wrote:
find_ring_mfn() already holds a page reference when trying to obtain a
writable type reference. We
On 13/02/2023 10:54 am, Xenia Ragiadakou wrote:
>
> On 2/13/23 12:09, Jan Beulich wrote:
>> I keep forgetting why putting it on just the declaration isn't
>> sufficient; I
>> guess a short comment to that effect next to cf_check's definition in
>> compiler.h would help).
>
> Yes, that would help. I
Hi,
I'm getting some ELF note issues on multiboot binary
specifically:
xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note
description size 0xc0010001, stripped
readelf additionally says:
Dis
APIC virtualization support is currently implemented only for Intel VT-x.
To aid future work on separating AMD-V from Intel VT-x code, instead of
calling directly vmx_vlapic_msr_changed() from common hvm code, add a stub
to the hvm_function_table, named update_vlapic_mode, and create a wrapper
func
On 03.02.2023 18:05, Oleksii Kurochko wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -92,6 +92,12 @@ config STATIC_MEMORY
>
> If unsure, say N.
>
> +config GENERIC_DO_BUG_FRAME
> + bool
> + help
> + Generic do_bug_frame() function is needed to handle the
flight 177160 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177160/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
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" and
"[XEN v3 0/9] Add support for 32 bit physical address".
Patch 1/2 : This has been reviewed and ack-ed. It needs to be committed before
any of the "[XE
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
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
ARM_32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t' t
On 11/02/2023 09:10, Julien Grall wrote:
Hi,
Hi Julien/Stefano,
On 11/02/2023 00:20, Stefano Stabellini wrote:
On Wed, 8 Feb 2023, Ayan Kumar Halder wrote:
dt_device_get_address() can accept u64 only for address and size.
However, the address/size denotes physical addresses. Thus, they sho
On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I'm getting some ELF note issues on multiboot binary
> specifically:
> xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
> linked, BuildID[sha1]=f7d2c37a4ad599b268f2f2d94bff3776d12649b3, bad note
> descr
On 13.02.2023 12:05, Andrew Cooper wrote:
> On 13/02/2023 10:54 am, Xenia Ragiadakou wrote:
>>
>> On 2/13/23 12:09, Jan Beulich wrote:
>>> I keep forgetting why putting it on just the declaration isn't
>>> sufficient; I
>>> guess a short comment to that effect next to cf_check's definition in
>>> c
On 03.02.2023 18:05, Oleksii Kurochko wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -18,6 +18,7 @@ config ARM
> select HAS_PDX
> select HAS_PMAP
> select IOMMU_FORCE_PT_SHARE
> + select GENERIC_DO_BUG_FRAME
Please maintain (largely?) alphabetic orderin
On 03.02.2023 18:05, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Is there anything keeping x86 from also using the generic do_bug_frame()?
If not, switching over would then likely mean no need for the new Kconfig
control.
Jan
On 03.02.2023 18:05, Oleksii Kurochko wrote:
> Since the generic version of bug.h stuff was introduced it
> is necessary to rename all uses of to
>
> Signed-off-by: Oleksii Kurochko
Doesn't this change need to come ahead of at least what currently is patch 3?
Or else why do you say "necessary"
On 13.02.2023 12:50, Xenia Ragiadakou wrote:
> APIC virtualization support is currently implemented only for Intel VT-x.
> To aid future work on separating AMD-V from Intel VT-x code, instead of
> calling directly vmx_vlapic_msr_changed() from common hvm code, add a stub
> to the hvm_function_table
On 13/02/2023 12:24, Jan Beulich wrote:
On 03.02.2023 18:05, Oleksii Kurochko wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -92,6 +92,12 @@ config STATIC_MEMORY
If unsure, say N.
+config GENERIC_DO_BUG_FRAME
+ bool
+ help
+ Generic do_bug_frame()
flight 177133 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
test-amd64-amd64-libvirt-pair 7 host-inst
On 13.02.2023 14:19, Julien Grall wrote:
> On 13/02/2023 12:24, Jan Beulich wrote:
>> On 03.02.2023 18:05, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/common/bug.c
>>> @@ -0,0 +1,88 @@
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>
>> Please order headers alphabetically
On 13/02/2023 1:19 pm, Julien Grall wrote:
>
>
> On 13/02/2023 12:24, Jan Beulich wrote:
>> On 03.02.2023 18:05, Oleksii Kurochko wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -92,6 +92,12 @@ config STATIC_MEMORY
>>> If unsure, say N.
>>> +config GENERIC_DO_BUG
Hi Andrew,
On 13/02/2023 13:33, Andrew Cooper wrote:
On 13/02/2023 1:19 pm, Julien Grall wrote:
On 13/02/2023 12:24, Jan Beulich wrote:
On 03.02.2023 18:05, Oleksii Kurochko wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -92,6 +92,12 @@ config STATIC_MEMORY
If unsure
On 13/02/2023 13:30, Jan Beulich wrote:
On 13.02.2023 14:19, Julien Grall wrote:
On 13/02/2023 12:24, Jan Beulich wrote:
On 03.02.2023 18:05, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/common/bug.c
@@ -0,0 +1,88 @@
+#include
+#include
+#include
+#include
Please order headers alph
On Mon, Feb 13, 2023 at 01:53:21PM +0100, Jan Beulich wrote:
> On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I'm getting some ELF note issues on multiboot binary
> > specifically:
> > xen/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> > statically linked
At the moment, we only perform a single arm32 test in our CI, checking
whether dom0 boots successfully or not. This is mostly because we do not
have any arm32 runners and we only execute a hypervisor only build.
In order not to leave the arm32 testing in such a poor state, add a
script qemu-smoke-
Xen supports booting gzip compressed kernels, therefore add a new test
job qemu-smoke-dom0less-arm32-gcc-gzip in debug and non-debug variant
that will execute qemu-smoke-dom0less-arm32.sh script to test booting
a domU with a gzip compressed kernel image (in our case zImage).
By passing "gzip" as a
Add a new test job qemu-smoke-dom0less-arm32-gcc-staticmem in debug
and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
script to test static memory allocation feature. The test case itself
is directly taken from dom0less arm64 testing.
Populate build jobs to compile Xen with conf
This patch series aims at improving the arm32 CI testing by introducing
the true dom0less-based tests that do not require dom0 with a toolstack.
It creates a foundation for further test expansion.
Michal Orzel (3):
automation: Add arm32 dom0less testing
automation: Add a static memory allocati
On 13.02.2023 15:12, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 13, 2023 at 01:53:21PM +0100, Jan Beulich wrote:
>> On 13.02.2023 12:14, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I'm getting some ELF note issues on multiboot binary
>>> specifically:
>>> xen/xen: ELF 32-bit LSB executab
Add a debian container with cppcheck installation routine inside,
capable of performing cppcheck analysis on Xen-only build including
cross-builds for arm32 and arm64.
Populate build jobs making use of that container to run cppcheck
analysis to produce a text report (xen-cppcheck.txt) containing t
struct dom0_vga_console_info has been extended in the past, and it may
be extended again. The use in PV Dom0's start info already covers for
that by supplying the size of the provided data. For the recently
introduced platform-op size needs providing similarly. Go the easiest
available route and si
This series aims to provide a means to render the cpu virtualization
technology support in Xen configurable.
Currently, irrespectively of the target platform, both AMD-V and Intel VT-x
drivers are built.
The series adds two new Kconfig controls, AMD_SVM and INTEL_VMX, that can be
used to switch to
Introduce two new Kconfig options, AMD_SVM and INTEL_VMX, to allow code
specific to each virtualization technology to be separated and, when not
required, stripped.
AMD_SVM will be used to enable virtual machine extensions on platforms that
implement the AMD Virtualization Technology (AMD-V).
INTEL
Since start_svm() is AMD-V specific while start_vmx() is Intel VT-x specific,
need to be guarded with AMD_SVM and INTEL_VMX, respectively.
Instead of adding #ifdef guards around the function calls, implement them as
static inline null-returning functions when the respective technology is not
enable
The functions ept_p2m_init(), ept_p2m_uninit() and p2m_init_altp2m_ept() are
VT-x specific.
Implement them as unreachable static inline functions when !INTEL_VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/mm/p2m.h | 16
1 file changed, 16 i
The function core2_vpmu_init() is VT-x specific while the functions
amd_vpmu_init() and hygon_vpmu_init() are AMD-V specific, thus need to be
guarded with INTEL_VMX and AMD_SVM, respectively.
Instead of adding #ifdef guards around the function calls in common vpu code,
implement them as static inli
The symbol svm_stgi_label is AMD-V specific so guard its usage in common code
with AMD_SVM.
Since AMD_SVM depends on HVM, it can be used alone.
Also, use #ifdef instead of #if.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/oprofile/op_model_athlon.c | 2 +-
1
To be able to use cpu_has_svm/vmx_* macros in common code without enclosing
them inside #ifdef guards when the respective virtualization technology is
not enabled, define them as false when not applicable.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/include/a
The functions vmx_vmcs_enter() and vmx_vmcs_exit() are VT-x specific.
Guard their calls with INTEL_VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch
The functions svm_load_segs() and svm_load_segs_prefetch() are AMD-V specific
so guard their calls in common code with AMD_SVM.
Since AMD_SVM depends on HVM, it can be used alone.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/domain.c | 4 ++--
1 file changed,
VIO_realmode_completion is specific to vmx realmode, so guard the completion
handling code with INTEL_VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/x86/hvm/ioreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hv
Provide the user with configuration control over the cpu virtualization support
in Xen by making AMD_SVM and INTEL_VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to Y.
To prevent users from unknowingly disabling virtualization support
On 13.02.2023 14:56, Julien Grall wrote:
> On 13/02/2023 13:30, Jan Beulich wrote:
>> On 13.02.2023 14:19, Julien Grall wrote:
>>> On 13/02/2023 12:24, Jan Beulich wrote:
On 03.02.2023 18:05, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/xen/bug.h
> @@ -0,0 +1,127 @@
Hi,
On 13/02/2023 15:02, Jan Beulich wrote:
On 13.02.2023 14:56, Julien Grall wrote:
On 13/02/2023 13:30, Jan Beulich wrote:
On 13.02.2023 14:19, Julien Grall wrote:
On 13/02/2023 12:24, Jan Beulich wrote:
On 03.02.2023 18:05, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/include/xen/bug.
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -117,6 +117,12 @@ config HVM
>
> If unsure, say Y.
>
> +config AMD_SVM
> + def_bool y if HVM
> +
> +config INTEL_VMX
> + def_bool y if HVM
I'm not convinced we want vendo
On 13.02.2023 16:07, Julien Grall wrote:
> On 13/02/2023 15:02, Jan Beulich wrote:
>> On 13.02.2023 14:56, Julien Grall wrote:
>>> On 13/02/2023 13:30, Jan Beulich wrote:
On 13.02.2023 14:19, Julien Grall wrote:
> On 13/02/2023 12:24, Jan Beulich wrote:
>> On 03.02.2023 18:05, Oleksii
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -117,6 +117,12 @@ config HVM
If unsure, say Y.
+config AMD_SVM
+ def_bool y if HVM
+
+config INTEL_VMX
+ def_bool y if HVM
I'm no
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
> On 2/13/23 17:11, Jan Beulich wrote:
>> On 13.02.2023 15:57, Xenia Ragiadakou wrote:
>>> --- a/xen/arch/x86/cpu/Makefile
>>> +++ b/xen/arch/x86/cpu/Makefile
>>> @@ -10,4 +10,6 @@ obj-y += intel.o
>>> obj-y += intel_cacheinfo.o
>>> obj-y += mwait-id
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -261,8 +261,16 @@ extern struct hvm_function_table hvm_funcs;
> extern bool_t hvm_enabled;
> extern s8 hvm_port80_allowed;
>
> +#ifdef CONFIG_AMD_SVM
> extern
The FILE symbols in out-of-tree builds may be either a relative path to
the object dir or an absolute path depending on how the build is
invoked. Fix the paths for C files so that they are consistent with
in-tree builds - the path is relative to the "xen" directory (e.g.
common/irq.c).
This fixes
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/mm/p2m.h
> +++ b/xen/arch/x86/mm/p2m.h
> @@ -35,9 +35,25 @@ void p2m_nestedp2m_init(struct p2m_domain *p2m);
> int p2m_init_nestedp2m(struct domain *d);
> void p2m_teardown_nestedp2m(struct domain *d);
>
> +#ifdef CONFIG_INTEL_VM
On 2/13/23 18:47, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -261,8 +261,16 @@ extern struct hvm_function_table hvm_funcs;
extern bool_t hvm_enabled;
extern s8 hvm_port80_allowed;
+
> From: Jan Beulich
> Sent: Thursday, February 9, 2023 8:46 AM
> To: Ross Lagerwall
> Cc: Konrad Rzeszutek Wilk ; Andrew Cooper
> ; Sergey Dyasli ;
> xen-de...@lists.xen.org
> Subject: Re: [PATCH] create-diff-object: Handle missing secsym for debug
> sections
>
> On 08.02.2023 19:04, Ross
flight 177187 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177187/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, 2023-02-13 at 07:12 +0100, Juergen Gross wrote:
>
> Thanks for the report.
>
> I'll have a look. Probably I'll need to re-add the check for WB in
> patch 7.
Sure, let me know if you need any more details about by setup.
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -10,4 +10,6 @@ obj-y += intel.o
obj-y += intel_cacheinf
On Mon, Feb 13, 2023 at 10:26:11AM +0100, Juergen Gross wrote:
> On 07.02.23 03:10, Demi Marie Obenour wrote:
> > When a grant entry is still in use by the remote domain, Linux must put
> > it on a deferred list. Normally, this list is very short, because
> > the PV network and block protocols exp
Juergen Gross, le lun. 13 févr. 2023 09:44:11 +0100, a ecrit:
> Add the open() and close() support to the 9pfs frontend. This requires
> to split the path name and to walk to the desired directory level.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> V2:
> - check path t
Juergen Gross, le lun. 13 févr. 2023 09:44:12 +0100, a ecrit:
> Add support to read from and write to a file handled by 9pfsfront.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> V2:
> - add check for max message size
> - return EAGAIN in case no free request got (Samuel
Thanks!!
Juergen Gross, le lun. 13 févr. 2023 09:44:05 +0100, a ecrit:
> This series is adding minimal support to use 9pfs in Mini-OS. It is
> adding a PV 9pfs frontend and the ability to open, close, read and
> write files.
>
> The series has been tested with qemu as 9pfs backend in a PVH Mini-O
flight 177177 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177177/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177104
test-amd64-amd64-xl-qemuu-win7-amd64
On Mon, 13 Feb 2023, Michal Orzel wrote:
> Add a debian container with cppcheck installation routine inside,
> capable of performing cppcheck analysis on Xen-only build including
> cross-builds for arm32 and arm64.
>
> Populate build jobs making use of that container to run cppcheck
> analysis to
On Mon, 13 Feb 2023, Michal Orzel wrote:
> Add a new test job qemu-smoke-dom0less-arm32-gcc-staticmem in debug
> and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
> script to test static memory allocation feature. The test case itself
> is directly taken from dom0less arm64 testi
On Mon, 13 Feb 2023, Michal Orzel wrote:
> Xen supports booting gzip compressed kernels, therefore add a new test
> job qemu-smoke-dom0less-arm32-gcc-gzip in debug and non-debug variant
> that will execute qemu-smoke-dom0less-arm32.sh script to test booting
> a domU with a gzip compressed kernel im
On Mon, 13 Feb 2023, Michal Orzel wrote:
> At the moment, we only perform a single arm32 test in our CI, checking
> whether dom0 boots successfully or not. This is mostly because we do not
> have any arm32 runners and we only execute a hypervisor only build.
>
> In order not to leave the arm32 tes
flight 177171 xen-unstable real [real]
flight 177219 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/177171/
http://logs.test-lab.xenproject.org/osstest/logs/177219/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi all,
The following commits are also in the tip tree as different commits
(but the same patches):
415dab3c1796 ("drivers/xen/hypervisor: Expose Xen SIF flags to userspace")
336f560a8917 ("x86/xen: don't let xen_pv_play_dead() return")
f697cb00afa9 ("x86/xen: mark xen_pv_play_dead() as __n
flight 177223 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177223/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b3f321f2d7871868951cf73edb8fa4d5a88854a5
baseline version:
ovmf 93a21b465bda44cecdd63
An assert failure has been observed at p2m-basic.c:173 when performing vm
forking and then destroying the forked VM. The assert checks whether the
domain's shared pages counter is 0. According to the patch that originally
added the assert (7bedbbb5c31) the p2m_teardown should only happen after
mem_
When VM forking is initiated a VM is not supposed to try to perform mem_sharing
yet as the fork process hasn't completed all required steps. However, the vCPU
bring-up paths trigger guest memory accesses that can lead to such premature
sharing ops. However, the gating check to see whether a VM is a
flight 177222 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177222/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177177
test-amd64-amd64-xl-qemuu-win7-amd64
On 13.02.2023 15:51, Jan Beulich wrote:
> struct dom0_vga_console_info has been extended in the past, and it may
> be extended again. The use in PV Dom0's start info already covers for
> that by supplying the size of the provided data. For the recently
> introduced platform-op size needs providing
On 13.02.2023 21:53, Boris Ostrovsky wrote:
>
> On 2/13/23 11:41 AM, Jan Beulich wrote:
>> On 13.02.2023 17:30, Xenia Ragiadakou wrote:
>>> On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Make
On 13.02.23 22:01, Demi Marie Obenour wrote:
On Mon, Feb 13, 2023 at 10:26:11AM +0100, Juergen Gross wrote:
On 07.02.23 03:10, Demi Marie Obenour wrote:
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the
Hi Stefano,
On 14/02/2023 00:56, Stefano Stabellini wrote:
>
>
> On Mon, 13 Feb 2023, Michal Orzel wrote:
>> Add a debian container with cppcheck installation routine inside,
>> capable of performing cppcheck analysis on Xen-only build including
>> cross-builds for arm32 and arm64.
>>
>> Populat
Hi Stefano,
On 14/02/2023 01:37, Stefano Stabellini wrote:
>
>
> On Mon, 13 Feb 2023, Michal Orzel wrote:
>> At the moment, we only perform a single arm32 test in our CI, checking
>> whether dom0 boots successfully or not. This is mostly because we do not
>> have any arm32 runners and we only ex
98 matches
Mail list logo
