Dump the complete Xenstore status to a file (daemon case) or memory
(stubdom case).
As we don't know the exact length of the needed area in advance we are
using an anonymous rather large mapping in stubdom case, which will
use only virtual address space until accessed. And as we are writing
the ar
Add the needed functions for reading node state for live update.
This requires some refactoring of current node handling in Xenstore in
order to avoid repeating the same code patterns multiple times.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Julien Grall
---
V4:
- drop l
Add activation of the new binary for live update. The daemon case is
handled completely, while for stubdom we only add stubs.
Signed-off-by: Juergen Gross
---
V7:
- added unbinding dom0 and virq event channels
V8:
- no longer close dom0 evtchn (Julien Grall)
V10:
- remember original argc and ar
Hi,
On 15/12/2020 02:16, Elliott Mitchell wrote:
Finally getting to the truly productive stages of my project with Xen on
ARM.
How many of the OSes which function as x86 DomUs for Xen, function as
ARM DomUs? Getting Linux operational was straightforward, but what of
others?
If you are intere
On Mon, 14 Dec 2020, Elliott Mitchell wrote:
> Finally getting to the truly productive stages of my project with Xen on
> ARM.
>
> How many of the OSes which function as x86 DomUs for Xen, function as
> ARM DomUs? Getting Linux operational was straightforward, but what of
> others?
I know of Fre
From: Julien Grall
A domain could just be dying when live updating Xenstore, so the case
of not being able to map the ring page or to connect to the event
channel must be handled gracefully.
Signed-off-by: Julien Grall
Reviewed-by: Paul Durrant
---
V4:
- new patch (Julien, I hope adding the So
flight 157561 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
Add the needed functions for reading connection state for live update.
As the connection is identified by a unique connection id in the state
records we need to add this to struct connection. Add a new function
to return the connection based on a connection id.
Signed-off-by: Juergen Gross
Revie
Add reading the watch state records for live update.
This requires factoring out some of the add watch functionality into a
dedicated function.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V4:
- add comment (Julien Grall)
V6:
- correct check_watch_path() (setting errno)
Signed-o
Hi,
On 15/12/2020 02:35, Roman Shaposhnik wrote:
On Mon, Dec 14, 2020 at 6:16 PM Elliott Mitchell wrote:
Finally getting to the truly productive stages of my project with Xen on
ARM.
How many of the OSes which function as x86 DomUs for Xen, function as
ARM DomUs? Getting Linux operational w
On Tue, Dec 15, 2020 at 11:28 AM Jan Beulich wrote:
>
> Signed-off-by: Jan Beulich
Reviewed-by: Tamas K Lengyel
On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > While processing the parents of a BDS, one of the parents may process
> > the child that's doing the tail recursion, which leads to a BDS being
> > processed twice. This is especia
On Tue, Dec 15, 2020 at 04:01:19PM +0100, Kevin Wolf wrote:
> Am 15.12.2020 um 14:15 hat Sergio Lopez geschrieben:
> > On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> > > Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > > > While processing the parents of a BDS, one of the par
On Tue, Dec 15, 2020 at 04:34:05PM +0100, Kevin Wolf wrote:
> Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > There's a cross-dependency between closing the block exports and
> > draining the block layer. The latter needs that we close all export's
> > client connections to ensure they won
On 15/12/2020 16:35, Juergen Gross wrote:
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
> Reviewed-by: Julien Grall
> ---
> V7:
> - new patch
>
> V8:
> - some minor comments by Julien Grall addressed
>
> Signed-off-by: Juergen Gross
Various of your patches still have double SoB. (Just
Hi Ash,
Apologies for the late reply.
On 05/11/2020 18:55, Ash Wilding wrote:
The current Arm boot_cpu_feature64() and boot_cpu_feature32() macros
are hardcoded to only detect features in ID_AA64PFR{0,1}_EL1 and
ID_PFR{0,1} respectively.
This patch replaces these macros with a new macro, boot_
Hi Ash,
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
Most of the "work" here is simply deleting the atomic64_t helper
definitions as we don't have an atomic64_t type in Xen.
There is some request to support atomic64_t in Xen. I would suggest to
keep as this would be simpler to
Hi Ash,
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
- s/arch_xchg/xchg/
- s/arch_cmpxchg/cmpxchg/
- Replace calls to BUILD_BUG() with calls to __bad_cmpxchg() as we
don't currently have a BUILD_BUG() macro in Xen and this will
equivalently cause a link-time error.
flight 157555 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157555/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi list,
This is a reply to the thread of the same title (linked here:
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg84916.html
) which I could not reply to because I receive this list by digest.
I'm unclear if this is exactly the reason, but I experienced the
same symptom
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
Hey,
Hi Ash,
I've found some time to improve this series a bit:
Changes since RFC v1
- Broken up patches into smaller chunks to aid in readability.
- As per Julien's feedback I've also introduced int
On 12/15/20 6:10 AM, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible by signals.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - don't special case SIGKILL as libxenstore is handling -EINTR fine
Reviewed-by: Boris Ostrov
flight 157570 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
Hi Daniel,
On Fri, 13 Nov 2020 at 19:07, Daniel Kiper wrote:
>
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
>
On 15/12/2020 11:10, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible by signals.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - don't special case SIGKILL as libxenstore is handling -EINTR fine
> ---
> drivers/xen/xenbus/x
Hopefully I can provide a little more context. Here is a link to the patch:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-extended/xen/files/libxl-fix-reboot.patch
The patch is a bit mis-named. It does not implement
XEN_DOMCTL_SENDTRIGGER_RESET. It's just a workaround to handle th
flight 157575 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
On Tue, Dec 15, 2020 at 03:54:08PM +0100, Peter Zijlstra wrote:
> The problem is that a single instance of unwind information (ORC) must
> capture and correctly unwind all alternatives. Since the trivially
> correct mandate is out, implement the straight forward brute-force
> approach:
>
> 1) gen
Hi all,
I am building Xen tools for ARM32 using qemu-user. I am getting the
following error building tools/flask. Everything else works fine. It is
worth noting that make -j1 works fine, it is only make -j4 that fails.
I played with .NOTPARALLEL but couldn't get it to work. Anyone has any
ideas?
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://
flight 157582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
On Tue, Dec 15, 2020 at 08:36:34AM -0800, Stefano Stabellini wrote:
> On Mon, 14 Dec 2020, Elliott Mitchell wrote:
> > The available examples seem geared towards Linux DomUs. I'm looking at a
> > FreeBSD installation image and it appears to expect an EFI firmware.
> > Beyond having a bunch of file
flight 157562 xen-4.12-testing real [real]
flight 157578 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157562/
http://logs.test-lab.xenproject.org/osstest/logs/157578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 157563 xen-4.13-testing real [real]
flight 157592 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157563/
http://logs.test-lab.xenproject.org/osstest/logs/157592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 157590 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
flight 157564 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157564/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 157133
test-amd64-amd64-qemuu-nested-am
On 15.12.20 19:09, Andrew Cooper wrote:
On 15/12/2020 16:35, Juergen Gross wrote:
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Reviewed-by: Julien Grall
---
V7:
- new patch
V8:
- some minor comments by Julien Grall addressed
Signed-off-by: Juergen Gross
Various of your patches still
On 17.09.20 14:55, Qinglang Miao wrote:
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signa
On 14.10.20 19:53, Jason Andryuk wrote:
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden vari
On 20.11.20 19:32, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Sil
On 20.11.20 19:40, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Sil
On 27.11.20 17:07, t...@redhat.com wrote:
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital si
101 - 142 of 142 matches
Mail list logo
