flight 184685 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184685/
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
Hi,
On 05/02/2024 11:11, Elias El Yandouzi wrote:
Hi Jan,
On 29/01/2024 08:28, Jan Beulich wrote:
On 16.01.2024 20:25, Elias El Yandouzi wrote:
Julien Grall (8):
xen/vmap: Check the page has been mapped in vm_init_type()
xen/vmap: Introduce vmap_size() and use it
xen/arm: fixmap:
flight 184683 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184683/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184671
test-amd64-amd64-xl-qemut-win7-amd64
Add support for the new 9pfs backend "xen_9pfsd". For this backend type
the tag defaults to "Xen" and the host side path to
"/var/log/xen/guests/".
Do most of the default settings in libxl. Unfortunately the default
path can't easily be set in libxl, as the domain name isn't available
in the
Make the backend type of 9pfs PV devices configurable. The default is
"qemu" with the related Xenstore backend-side directory being "9pfs".
Add another type "xen_9pfsd" with the related Xenstore backend-side
directory "xen_9pfs".
As additional security features it is possible to specify:
-
Add a 9pfs device to Xenstore stubdom in order to allow it to do e.g.
logging into a dom0 file.
Use the following parameters for the new device:
- tag = "Xen"
- type = "xen_9pfsd"
- path = "/var/lib/xen/xenstore"
- security-model = "none"
For now don't limit allowed file space or number of
This series is adding 9pfs support to Xenstore-stubdom, enabling it
to do logging to a dom0 directory.
This is a prerequisite for the final goal to add live update support
to Xenstore-stubdom, as it enables the stubdom to store its state in
a dom0 file.
Reposting the rest series.
Changes in V8:
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
stubdom/xenstore-minios.cfg| 2 +-
stubdom/xenstorepvh-minios.cfg | 2 +-
2 files changed, 2
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib/xen/xenstore)
- expansion of xenstore_daemon_rundir()
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has been
mounted.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
Mount the 9pfs device in stubdom enabling it to use files.
This has to happen in a worker thread in order to allow the main thread
handling the required Xenstore accesses in parallel.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
---
V3:
- add logging in
With 9pfs now available in Xenstore-stubdom, there is no reason to
have distinct do_control_memreport() variants for the daemon and the
stubdom implementations.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xenstored/control.c | 27 +++
1 file
On 15.02.2024 18:23, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote:
>> On 15.02.2024 17:08, Roger Pau Monné wrote:
>>> On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -15,7 +15,11 @@ srcdir
On Wed, Feb 14, 2024 at 06:06:38PM +, Andrew Cooper wrote:
> On 14/02/2024 6:00 pm, Anthony PERARD wrote:
> > The `which` command is not standard, may not exist on the build host,
> > or may not behave as expected by the build system. It is recommended
> > to use `command -v` to find out if a
flight 184681 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184681/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
184677
test-armhf-armhf-libvirt-raw 17
On Thu, 2024-02-15 at 17:43 +0100, Jan Beulich wrote:
> On 15.02.2024 17:38, Oleksii wrote:
> > On Tue, 2024-02-13 at 14:33 +0100, Jan Beulich wrote:
> > > On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > > > + depends on LLD_VERSION >= 15 || LD_VERSION >=
> > > > 23600
> > >
> > >
Arm, PPC and RISC-V introduce the same things in asm/device.h, so
generic device.h was introduced.
Arm's device.h was taken as a base with the following changes:
- #ifdef ACPI related things.
- Rename #ifdef guards.
- Add SPDX tag.
- #ifdef CONFIG_HAS_DEVICE_TREE related things.
- #ifdef-ing
Signed-off-by: Oleksii Kurochko
---
Changed in V8:
- nothing changed. only rebase.
---
Changes in V7:
- newly introduced patch which is based on the previous version of the patch:
[PATCH v6 9/9] xen/asm-generic: introduce generic device.h
---
xen/arch/ppc/include/asm/Makefile | 1 +
On Wed, Feb 14, 2024 at 11:15:51AM +0100, Jan Beulich wrote:
> ... if available only, of course.
>
> Signed-off-by: Jan Beulich
> ---
> I don't really like issuing an IPI (and having another cf_check
> function) here, yet then again this is issued only when the debug key
> is actually used, and
The following changes were done as a result of switching to
asm-generic/device.h:
* DEVICE_GIC was renamed to DEVICE_INTERRUPT_CONTROLLER according
to definition of enum device_class in asm-generic/device.h.
* acpi-related things in Arm code were guarded by #ifdef CONFIG_ACPI
as struct
The header is shared between several archs so it is
moved to asm-generic.
Switch partly Arm and PPC to asm-generic/monitor.h and only
arch_monitor_get_capabilities() left in arch-specific/monitor.h.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
Acked-by: Tamas K Lengyel
Acked-by:
The current patch is a follow-up to the patch titled:
xen/asm-generic: introduce generic device.h
Also, a prerequisite for this patch is, without which a compilation
error will occur:
xen/arm: switch Arm to use asm-generic/device.h
The 'struct dev_archdata' is exclusively used within
This patch introduces the anchor riscv-fixed-randconfig,
which includes all configurations that should be disabled for
randconfig builds.
Suggested-by: Stefano Stabellini
Signed-off-by: Oleksii Kurochko
---
The patch were introduced after discussion in a topic:
ifdefing inclusion of in
allows to avoid generation of empty header
for the case when !CONFIG_MEM_ACCESS.
For Arm it was explicitly added inclusion of for p2m.c
and traps.c because they require some functions from which
aren't available in case of !CONFIG_MEM_ACCESS.
Suggested-by: Jan
Some headers are common between several architectures, so the current patch
series
provide them.
Another one reason to have them as generic is a simplification of adding support
necessary to make a complete Xen build as it was/is being done in the patch
series [1]
and [2].
Also, instead of
On 2/16/24 06:44, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 03:30:00PM -0500, Stewart Hildebrand wrote:
>> From: Oleksandr Andrushchenko
>>
>> Use the per-domain PCI read/write lock to protect the presence of the
>> pci device vpci field. This lock can be used (and in a few cases is used
On Thu, Feb 15, 2024 at 03:30:00PM -0500, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko
>
> Use the per-domain PCI read/write lock to protect the presence of the
> pci device vpci field. This lock can be used (and in a few cases is used
> right away) so that vpci removal can be
flight 184682 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184682/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184662
test-armhf-armhf-libvirt-raw 15
Hi,
On 16/02/2024 13:39, Oleksii Kurochko wrote:
>
>
> This patch introduces the anchor riscv-fixed-randconfig,
> which includes all configurations that should be disabled for
> randconfig builds.
>
> Suggested-by: Stefano Stabellini
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Michal
>
> > + } free;
> > + } u;
> > +
> > + union {
> > + /* Page is in use, but not as a shadow. */
>
> I'm also pretty sure I asked before what shadow this comment alludes
> to.
I missed your request about 'shadow' before.
The comment arrived from Arm.
I tried to find out the
On many entries we push 8-bytes zero and exception constants are
small so we can just write a single byte saving 3 bytes for
instruction.
With ENDBR64 this reduces the size of many entry points from 32 to
16 bytes (due to alignment).
The push and the mov are overlapping stores either way.
On Fri, Feb 16, 2024 at 11:04:46AM +0100, Jan Beulich wrote:
> On 15.02.2024 18:23, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote:
> >> On 15.02.2024 17:08, Roger Pau Monné wrote:
> >>> On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
> ---
On Thu, Feb 15, 2024 at 05:06:44PM +0200, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Allow administrators to control whether Xen grant mappings for
> the virtio disk devices should be used. By default (when new
> parameter is not specified), the existing behavior is retained
>
On Fri, Jun 18, 2021 at 09:54:14AM +0100, Alex Bennée wrote:
>
> Marek Marczykowski-Górecki writes:
>
> > Kernel on Xen is loaded via fw_cfg. Previously it used non-DMA version,
> > which loaded the kernel (and initramfs) byte by byte. Change this
> > to DMA, to load in bigger chunks.
> > This
flight 184686 linux-linus real [real]
flight 184690 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184686/
http://logs.test-lab.xenproject.org/osstest/logs/184690/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184684 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184684/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat fail in 184681 pass
in 184684
Hi Julien,
On 15/02/2024 17:05, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 15/02/2024 14:39, Michal Orzel wrote:
>> At the moment, the hardware domain vUART is always compiled in. In the
>> spirit of fine granular configuration, make it optional so that the
>> feature can be disabled if not
37 matches
Mail list logo
