Re: [PATCH 1/2] x86/mm: tidy XENMEM_{get,set}_pod_target handling

On 13.09.2021 10:55, Jan Beulich wrote: > Do away with the "pod_target_out_unlock" label. In particular by folding > if()-s, the logic can be expressed with less code (and no goto-s) this > way. > > Limit scope of "p2m", constifying it at the same time. > > Signed-off-by: Jan Beulich And this

[PATCH 0/2] grant table and add-to-physmap adjustments on top of XSAs 379 and 384

I'm prepared for the "how" aspect of the 1st patch here to end up controversial. Since the observed quirk will imo want dealing with, I'd appreciate any objection to the proposed change to be accompanied by an alternative suggestion. An intention of mine was to not further increase the number of

Re: [PATCH v6 05/10] xsm: apply coding style

On 10.09.2021 22:13, Daniel P. Smith wrote: > Instead of intermixing coding style changes with code changes as they > are come upon in this patch set, moving all coding style changes > into a single commit. The focus of coding style changes here are, > > - move trailing comments to line above >

[PATCH 0/2] x86/mm: XENMEM_{get,set}_pod_target handling adjustments

In the context of PCI pass-through I came to look at this code again, while considering whether it might be usable for an issue there (which I'll send separate mail about). 1: XENMEM_{get,set}_pod_target are restricted to HVM domains 2: tidy XENMEM_{get,set}_pod_target handling Jan

Re: [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m

On 11.09.21 00:41, Julien Grall wrote: > > > On Fri, 10 Sep 2021, 21:30 Stefano Stabellini, > wrote: > > On Fri, 10 Sep 2021, Julien Grall wrote: > > On 10/09/2021 15:01, Oleksandr Andrushchenko wrote: > > > On 10.09.21 16:18, Julien Grall wrote: >

[PATCH 1/2] gnttab: remove guest_physmap_remove_page() call from gnttab_map_frame()

Without holding appropriate locks, attempting to remove a prior mapping of the underlying page is pointless, as the same (or another) mapping could be re-established by a parallel request on another vCPU. Move the code to Arm's gnttab_set_frame_gfn(). Of course this new placement doesn't improve

[PATCH 2/2] memory: XENMEM_add_to_physmap (almost) wrapping checks

Determining that behavior is correct (i.e. results in failure) for a passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit more obvious by checking input in generic code - both for singular requests to not match the value and for range ones to not pass / wrap through it. For

[linux-linus test] 164961: regressions - FAIL

flight 164961 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/164961/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332

Re: [PATCH 12/12] swiotlb-xen: this is PV-only on x86

On 11.09.2021 01:48, Stefano Stabellini wrote: > On Wed, 8 Sep 2021, Christoph Hellwig wrote: >> On Tue, Sep 07, 2021 at 02:13:21PM +0200, Jan Beulich wrote: >>> The code is unreachable for HVM or PVH, and it also makes little sense >>> in auto-translated environments. On Arm, with >>>

Re: [RFC PATCH] xen/gnttab: Store frame GFN in struct page_info on Arm

On 10.09.2021 09:52, Jan Beulich wrote: > On 10.09.2021 01:04, Oleksandr Tyshchenko wrote: >> @@ -731,11 +733,19 @@ static void p2m_put_l3_page(const lpae_t pte) >> */ >> if ( p2m_is_foreign(pte.p2m.type) ) >> { >> -mfn_t mfn = lpae_get_mfn(pte); >> - >>

Re: [PATCH 1/3] tools/libacpi: Use 64-byte alignment for FACS [and 1 more messages]

On 10.09.2021 16:50, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH 1/3] tools/libacpi: Use 64-byte alignment > for FACS"): >> The current code is clearly wrong, but happens to work correctly in >> hvmloader because FACS is the first table written and it starts on a >> page boundary.  The

[PATCH] x86/ACPI: ignore processors which cannot be brought online

ACPI 6.3 introduced a flag allowing to tell MADT entries describing hotpluggable processors from ones which are simply placeholders (often used by firmware writers to simplify handling there). Inspired by a Linux patch by Mario Limonciello . Requested-by: Andrew Cooper Signed-off-by: Jan

[libvirt test] 164964: regressions - FAIL

flight 164964 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/164964/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt

Re: Xen Booting Problem on ARM Machine

On Fri, Sep 10, 2021 at 7:30 PM Julien Grall wrote: > > > On 08/09/2021 11:43, Sai Kiran wrote: > > Hello, > > Hi, > > Thank you for the report. Moving the discussion back to xen-devel > because this looks like a potential issue in the UEFI stub in Xen. > > > I have Xen-4.15.0 on an ARM Machine,

Re: [PATCH 12/12] swiotlb-xen: this is PV-only on x86

On 11.09.2021 01:48, Stefano Stabellini wrote: > On Wed, 8 Sep 2021, Christoph Hellwig wrote: >> On Tue, Sep 07, 2021 at 02:13:21PM +0200, Jan Beulich wrote: >>> The code is unreachable for HVM or PVH, and it also makes little sense >>> in auto-translated environments. On Arm, with >>>

PCI pass-through vs PoD

Hello, libxl__domain_config_setdefault() checks whether PoD is going to be enabled and fails domain creation if at the same time devices would get assigned. Nevertheless setting up of IOMMU page tables is allowed. However, when later assigning a device to a domain which has IOMMU page tables,

[PATCH v2] x86: correct asm() constraints when dealing with immediate selector values

asm() constraints need to fit both the intended insn(s) which the respective operands are going to be used with as well as the actual kind of value specified. "m" (alone) together with a constant, however, leads to gcc saying error: memory input is not directly addressable while clang complains

[PATCH 1/2] x86/mm: XENMEM_{get,set}_pod_target are restricted to HVM domains

While for now PV domains have a host P2M associated with them and hence using XENMEM_get_pod_target on such may not be a real problem, calling p2m_pod_set_mem_target() for a PV domain is surely wrong, even if benign at present. Signed-off-by: Jan Beulich --- While the output of the two

[PATCH 1/2] x86/mm: tidy XENMEM_{get,set}_pod_target handling

Do away with the "pod_target_out_unlock" label. In particular by folding if()-s, the logic can be expressed with less code (and no goto-s) this way. Limit scope of "p2m", constifying it at the same time. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4777,7

Re: [PATCH 04/12] swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests

On 11.09.2021 01:14, Stefano Stabellini wrote: > On Tue, 7 Sep 2021, Jan Beulich wrote: >> While the hypervisor hasn't been enforcing this, we would still better >> avoid issuing requests with GFNs not aligned to the requested order. >> >> Signed-off-by: Jan Beulich >> --- >> I wonder how useful

Re: Introduction of stable interface between Xenstore and hypervisor

On 10.09.2021 15:46, Juergen Gross wrote: > On 10.09.21 15:22, Jan Beulich wrote: >> On 09.09.2021 08:27, Juergen Gross wrote: >>> Today Xenstore is using one unstable interface to retrieve the state >>> of a domain (existing, dying). >>> >>> In order to decouple Xenstore further from the

Re: Introduction of stable interface between Xenstore and hypervisor

On 13.09.21 09:39, Jan Beulich wrote: On 10.09.2021 15:46, Juergen Gross wrote: On 10.09.21 15:22, Jan Beulich wrote: On 09.09.2021 08:27, Juergen Gross wrote: Today Xenstore is using one unstable interface to retrieve the state of a domain (existing, dying). In order to decouple Xenstore

Re: [PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

Hi, Stefano! On 10.09.21 22:06, Stefano Stabellini wrote: > On Fri, 3 Sep 2021, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Arm's PCI passthrough implementation doesn't support legacy interrupts, >> but MSI/MSI-X. This can be the case for other platforms too. >> For

Xen 4.14.3 released

All, we're pleased to announce the release of Xen 4.14.3. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.14 (tag RELEASE-4.14.3) or from the XenProject download page

Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading related?)

Hi, Since 5.13, the Xen (PV) dom0 crashes on boot, before even printing the kernel version. Test environment: - Xen 4.14.2 - AMD Ryzen 5 4500U (reported also on AMD Ryzen 7 4750U) - Linux 5.13.13, confirmed also on 5.14 The crash happens only if the initramfs has earlycpio with microcode. I

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: > While LLVM's lld is supposed to be a drop-in replacement for GNU ld [1], > it appears to not understand quoted section names as operands to e.g. > ADDR(). Therefore the original workaround broke the build in > environments where ld is

Re: [PATCH v3 1/2] tools/xenstore: set oom score for xenstore daemon on Linux

Juergen Gross writes ("Re: [PATCH v3 1/2] tools/xenstore: set oom score for xenstore daemon on Linux"): > Correct. Otherwise the user would need to know about the oom_score_adj > ABI. I think they might know about it. In particular, sysadmins might well be used to configuring this directly (for

Re: [PATCH v3 2/2] tools/xenstore: set open file descriptor limit for xenstored

Juergen Gross writes ("Re: [PATCH v3 2/2] tools/xenstore: set open file descriptor limit for xenstored"): > On 31.08.21 16:22, Ian Jackson wrote: > > ISTM that the following scheme is in the intersection of everyone's > > requirements: > > > > * The limit will be adjusted/imposed in the

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On 13.09.2021 15:37, Roger Pau Monné wrote: > On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: >> I haven't been able to find an environment where I could actually try >> with lld (ld.lld); all testing was with GNU ld (ld.bfd). > > Thanks for fixing this. I've been able to test with

[xen-unstable test] 164963: regressions - FAIL

flight 164963 xen-unstable real [real] flight 164968 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/164963/ http://logs.test-lab.xenproject.org/osstest/logs/164968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH] tools/go: honor append build flags

Roger Pau Monné writes ("Re: [PATCH] tools/go: honor append build flags"): > Unless someone else has opinions I think this is ready to be > committed. Can a committer please queue it up? Thanks for the ping. Committed, with my ack. Thanks, Ian.

Re: [PATCH] tools/go: honor append build flags

On Wed, Jul 07, 2021 at 09:42:20AM -0400, Nick Rosbrook wrote: > On Wed, Jul 07, 2021 at 09:15:31AM +0200, Roger Pau Monne wrote: > > Make the go build use APPEND_{C/LD}FLAGS when necessary, just like > > other parts of the build. > > > > Reported-by: Ting-Wei Lan > > Signed-off-by: Roger Pau

Is it time to start implementing Xen bindings for rust-vmm?

Hi, As we consider the next cycle for Project Stratos I would like to make some more progress on hypervisor agnosticism for our virtio backends. While we have implemented a number of virtio vhost-user backends using C we've rapidly switched to using rust-vmm based ones for virtio-i2c, virtio-rng

Re: [PATCH v1 07/14] xen/arm: Add support for Xilinx ZynqMP PCI host controller

On 10.09.21 15:01, Rahul Singh wrote: > Hi Stefano, > >> On 10 Sep 2021, at 12:34 am, Stefano Stabellini >> wrote: >> >> On Thu, 19 Aug 2021, Rahul Singh wrote: >>> From: Oleksandr Andrushchenko >>> >>> Add support for Xilinx ZynqMP PCI host controller to map the PCI config >>> space to the

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On Mon, Sep 13, 2021 at 04:05:15PM +0200, Jan Beulich wrote: > On 13.09.2021 15:37, Roger Pau Monné wrote: > > On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: > >> I haven't been able to find an environment where I could actually try > >> with lld (ld.lld); all testing was with GNU ld

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: > .PHONY: clean > clean:: > - rm -f *.lds *.new boot/*.o boot/*~ boot/core boot/mkelf32 > + rm -f ???.lds *.new .check.* boot/*.o boot/*~ boot/core boot/mkelf32 Forgot to mention in my previous reply, but what's the point of

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On 13.09.2021 16:33, Roger Pau Monné wrote: > On Mon, Sep 13, 2021 at 04:05:15PM +0200, Jan Beulich wrote: >> On 13.09.2021 15:37, Roger Pau Monné wrote: --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -92,10 +92,16 @@ efi-$(CONFIG_PV_SHIM_EXCLUSIVE) := ifneq

Re: Is it time to start implementing Xen bindings for rust-vmm?

On 13/09/2021 13:44, Alex Bennée wrote: > Hi, > > As we consider the next cycle for Project Stratos I would like to make > some more progress on hypervisor agnosticism for our virtio backends. > While we have implemented a number of virtio vhost-user backends using C > we've rapidly switched to

[linux-linus test] 164965: regressions - FAIL

flight 164965 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/164965/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332

Re: [PATCH] x86/boot: properly "ignore" early evaluated "no-real-mode"

On 13/09/2021 17:02, Jan Beulich wrote: > The option parser takes off "no-" prefixes before matching, so they also > shouldn't be specified to match against. > > Fixes: e44d98608476 ("x86/setup: Ignore early boot parameters like > no-real-mode") > Signed-off-by: Jan Beulich Oops. Acked-by:

Re: [PATCH v1 05/14] xen/arm: PCI host bridge discovery within XEN on ARM

Hi, Rahul! On 19.08.21 15:02, Rahul Singh wrote: > XEN during boot will read the PCI device tree node “reg” property > and will map the PCI config space to the XEN memory. [snip] > +static struct pci_config_window *gen_pci_init(struct dt_device_node *dev, > +

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On 13.09.2021 16:33, Roger Pau Monné wrote: > On Mon, Sep 13, 2021 at 04:05:15PM +0200, Jan Beulich wrote: >> On 13.09.2021 15:37, Roger Pau Monné wrote: >>> On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: I haven't been able to find an environment where I could actually try

[PATCH] x86/boot: properly "ignore" early evaluated "no-real-mode"

The option parser takes off "no-" prefixes before matching, so they also shouldn't be specified to match against. Fixes: e44d98608476 ("x86/setup: Ignore early boot parameters like no-real-mode") Signed-off-by: Jan Beulich --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -692,7 +692,7

Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

On 13.09.2021 16:20, Roger Pau Monné wrote: > On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote: >> .PHONY: clean >> clean:: >> -rm -f *.lds *.new boot/*.o boot/*~ boot/core boot/mkelf32 >> +rm -f ???.lds *.new .check.* boot/*.o boot/*~ boot/core boot/mkelf32 > > Forgot to

[OSSTEST PATCH 2/5] mg-schema-update: improve an error message

Signed-off-by: Ian Jackson --- mg-schema-update | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mg-schema-update b/mg-schema-update index f22ed63a..fb754bed 100755 --- a/mg-schema-update +++ b/mg-schema-update @@ -268,5 +268,5 @@ die "need operation\n" unless @ARGV; my

[OSSTEST PATCH 4/5] mg-schema-test-database: Add a missing backslash

Signed-off-by: Ian Jackson --- mg-schema-test-database | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mg-schema-test-database b/mg-schema-test-database index 052a3577..b185e8b9 100755 --- a/mg-schema-test-database +++ b/mg-schema-test-database @@ -285,7 +285,7 @@ create)

[OSSTEST PATCH 3/5] mg-schema-test-database: Fix an error message

Signed-off-by: Ian Jackson --- mg-schema-test-database | 1 + 1 file changed, 1 insertion(+) diff --git a/mg-schema-test-database b/mg-schema-test-database index eae5d97e..052a3577 100755 --- a/mg-schema-test-database +++ b/mg-schema-test-database @@ -283,6 +283,7 @@ create) done

[OSSTEST PATCH 5/5] db: Replace ExecutiveDbOwningRoleRegexp with ExecutiveDbOwningRoleMap

And use SET ROLE. Signed-off-by: Ian Jackson --- Osstest/Executive.pm| 2 +- README | 17 --- mg-schema-test-database | 2 +- mg-schema-update| 68 - 4 files changed, 68 insertions(+), 21 deletions(-) diff --git

[OSSTEST PATCH 1/5] copyright notices: Add many missing notices

Signed-off-by: Ian Jackson --- mg-adjust-flight-makexrefs | 16 mg-blockage | 16 mg-branch-setup | 16 mg-crontab-install | 16 mg-debug-fail

Re: [PATCH v1 05/14] xen/arm: PCI host bridge discovery within XEN on ARM

On 13.09.21 23:23, Stefano Stabellini wrote: > On Mon, 13 Sep 2021, Oleksandr Andrushchenko wrote: >> Hi, Rahul! >> >> On 19.08.21 15:02, Rahul Singh wrote: >>> XEN during boot will read the PCI device tree node “reg” property >>> and will map the PCI config space to the XEN memory. >> [snip] >>>

Re: Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading related?)

Hi Marek, On Mon, Sep 13, 2021 at 02:50:00PM +0200, Marek Marczykowski-Górecki wrote: > Hi, > > Since 5.13, the Xen (PV) dom0 crashes on boot, before even printing the > kernel version. > Test environment: > - Xen 4.14.2 > - AMD Ryzen 5 4500U (reported also on AMD Ryzen 7 4750U) > - Linux

Re: [PATCH v1 07/14] xen/arm: Add support for Xilinx ZynqMP PCI host controller

On 14.09.21 00:02, Stefano Stabellini wrote: > On Mon, 13 Sep 2021, Oleksandr Andrushchenko wrote: >> On 10.09.21 15:01, Rahul Singh wrote: >>> Hi Stefano, >>> On 10 Sep 2021, at 12:34 am, Stefano Stabellini wrote: On Thu, 19 Aug 2021, Rahul Singh wrote: > From:

[linux-linus test] 164970: regressions - FAIL

flight 164970 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/164970/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl 14 guest-start fail REGR. vs. 152332

Re: [RFC PATCH] xen/gnttab: Store frame GFN in struct page_info on Arm

On 13.09.21 09:17, Jan Beulich wrote: Hi Jan On 10.09.2021 09:52, Jan Beulich wrote: On 10.09.2021 01:04, Oleksandr Tyshchenko wrote: @@ -731,11 +733,19 @@ static void p2m_put_l3_page(const lpae_t pte) */ if ( p2m_is_foreign(pte.p2m.type) ) { -mfn_t mfn =

Re: [PATCH 04/12] swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests

On Mon, 13 Sep 2021, Jan Beulich wrote: > On 11.09.2021 01:14, Stefano Stabellini wrote: > > On Tue, 7 Sep 2021, Jan Beulich wrote: > >> While the hypervisor hasn't been enforcing this, we would still better > >> avoid issuing requests with GFNs not aligned to the requested order. > >> > >>

Re: [PATCH 12/12] swiotlb-xen: this is PV-only on x86

On Mon, 13 Sep 2021, Jan Beulich wrote: > On 11.09.2021 01:48, Stefano Stabellini wrote: > > On Wed, 8 Sep 2021, Christoph Hellwig wrote: > >> On Tue, Sep 07, 2021 at 02:13:21PM +0200, Jan Beulich wrote: > >>> The code is unreachable for HVM or PVH, and it also makes little sense > >>> in

Re: [PATCH v1 05/14] xen/arm: PCI host bridge discovery within XEN on ARM

On Mon, 13 Sep 2021, Oleksandr Andrushchenko wrote: > Hi, Rahul! > > On 19.08.21 15:02, Rahul Singh wrote: > > XEN during boot will read the PCI device tree node “reg” property > > and will map the PCI config space to the XEN memory. > [snip] > > +static struct pci_config_window

Re: [PATCH 12/12] swiotlb-xen: this is PV-only on x86

On Mon, 13 Sep 2021, Jan Beulich wrote: > On 11.09.2021 01:48, Stefano Stabellini wrote: > > On Wed, 8 Sep 2021, Christoph Hellwig wrote: > >> On Tue, Sep 07, 2021 at 02:13:21PM +0200, Jan Beulich wrote: > >>> The code is unreachable for HVM or PVH, and it also makes little sense > >>> in

Re: [PATCH v1 07/14] xen/arm: Add support for Xilinx ZynqMP PCI host controller

On Mon, 13 Sep 2021, Oleksandr Andrushchenko wrote: > On 10.09.21 15:01, Rahul Singh wrote: > > Hi Stefano, > > > >> On 10 Sep 2021, at 12:34 am, Stefano Stabellini > >> wrote: > >> > >> On Thu, 19 Aug 2021, Rahul Singh wrote: > >>> From: Oleksandr Andrushchenko > >>> > >>> Add support for

[PATCH 1/1] tools/xl: Fix regular expression for autobaloon mode detection based on xen command line.

The case of specifying a negative size was handled incorrectly. >From misc/xen-command-line documentation: dom0_mem (x86) = List of ( min: | max: | ) If a size is positive, it represents an absolute value. If a size is negative, it is subtracted from the total available memory. ---

[xen-unstable-smoke test] 164966: tolerable all pass - PUSHED

flight 164966 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/164966/ 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

Re: [RFC PATCH] xen/gnttab: Store frame GFN in struct page_info on Arm

On 10.09.21 10:52, Jan Beulich wrote: Hi Jan On 10.09.2021 01:04, Oleksandr Tyshchenko wrote: @@ -731,11 +733,19 @@ static void p2m_put_l3_page(const lpae_t pte) */ if ( p2m_is_foreign(pte.p2m.type) ) { -mfn_t mfn = lpae_get_mfn(pte); -

Re: [PATCH V2 2/3] xen/arm: Add handling of extended regions for Dom0

On Fri, 10 Sep 2021, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The extended region (safe range) is a region of guest physical > address space which is unused and could be safely used to create > grant/foreign mappings instead of wasting real RAM pages from > the domain memory

[xen-unstable test] 164969: regressions - FAIL

flight 164969 xen-unstable real [real] flight 164975 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/164969/ http://logs.test-lab.xenproject.org/osstest/logs/164975/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

[ovmf test] 164971: all pass - PUSHED

flight 164971 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/164971/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3b69fcf5f849021aa3bc810f8100ea71c03019e5 baseline version: ovmf

Re: Xen Booting Problem on ARM Machine

On Mon, 13 Sep 2021, Sai Kiran Kumar Reddy Y wrote: > On Fri, Sep 10, 2021 at 7:30 PM Julien Grall wrote: > > > On 08/09/2021 11:43, Sai Kiran wrote: > > Hello, > > Hi, > > Thank you for the report. Moving the discussion back to xen-devel > because this looks

Dom0less + Argo enablement

Hi all, This email is for anybody interested in using Argo with Dom0less setups for domain-to-domain communications. Argo is a secure VM-to-VM communication mechanism based on hypercalls [1]. It is a good fit for Dom0less setups because Argo is lightweight and doesn't make use of PV frontends,

[qemu-mainline test] 164967: regressions - FAIL

flight 164967 qemu-mainline real [real] flight 164972 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/164967/ http://logs.test-lab.xenproject.org/osstest/logs/164972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

Re: Enabling hypervisor agnosticism for VirtIO backends

On Mon, 6 Sep 2021, AKASHI Takahiro wrote: > > the second is how many context switches are involved in a transaction. > > Of course with all things there is a trade off. Things involving the > > very tightest latency would probably opt for a bare metal backend which > > I think would imply