[PATCH] tools/xenstore: drop support for running under SunOS

Since several years now xenstored is no longer capable to run under SunOS, as the needed libxengnttab interfaces are not available there. Several attempts to let the SunOS maintainers address this situation didn't change anything in this regard. For those reasons drop SunOS support in xenstored b

Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers

On 17.12.2021 06:34, Juergen Gross wrote: > On 16.12.21 22:15, Stefano Stabellini wrote: >> On Thu, 16 Dec 2021, Stefano Stabellini wrote: >>> On Thu, 16 Dec 2021, Juergen Gross wrote: On 16.12.21 03:10, Stefano Stabellini wrote: > The case of XENMEM_maximum_ram_page is interesting but it

Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers

On 16.12.2021 22:15, Stefano Stabellini wrote: > On Thu, 16 Dec 2021, Stefano Stabellini wrote: >> On Thu, 16 Dec 2021, Juergen Gross wrote: >>> On 16.12.21 03:10, Stefano Stabellini wrote: On Wed, 15 Dec 2021, Juergen Gross wrote: > On 14.12.21 18:36, Julien Grall wrote: >> Hi, >>

[PATCH v3] xen/arm64: Zero the top 32 bits of gp registers on entry...

to hypervisor when switching from AArch32 state. According to section D1.20.2 of Arm Arm(DDI 0487A.j): "If the general-purpose register was accessible from AArch32 state the upper 32 bits either become zero, or hold the value that the same architectural register held before any AArch32 execution.

Re: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs

On 17.12.2021 08:12, Jan Beulich wrote: > On 16.12.2021 18:36, Oleksii Moisieiev wrote: >> On Tue, Dec 14, 2021 at 10:41:30AM +0100, Jan Beulich wrote: >>> On 14.12.2021 10:34, Oleksii Moisieiev wrote: --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -1177,6 +11

Re: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs

On 16.12.2021 18:36, Oleksii Moisieiev wrote: > On Tue, Dec 14, 2021 at 10:41:30AM +0100, Jan Beulich wrote: >> On 14.12.2021 10:34, Oleksii Moisieiev wrote: >>> --- a/xen/include/public/domctl.h >>> +++ b/xen/include/public/domctl.h >>> @@ -1177,6 +1177,13 @@ struct xen_domctl_vmtrace_op { >>> #d

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

On 16.12.2021 15:55, Julien Grall wrote: > Hi, > > On 16/12/2021 14:26, Michal Orzel wrote: >> On 16.12.2021 14:50, Jan Beulich wrote: >>> On 16.12.2021 10:21, Michal Orzel wrote: to hypervisor when switching from AArch32 state. According to section D1.20.2 of Arm Arm(DDI 0487A.j

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

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

Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers

On 16.12.21 22:15, Stefano Stabellini wrote: On Thu, 16 Dec 2021, Stefano Stabellini wrote: On Thu, 16 Dec 2021, Juergen Gross wrote: On 16.12.21 03:10, Stefano Stabellini wrote: On Wed, 15 Dec 2021, Juergen Gross wrote: On 14.12.21 18:36, Julien Grall wrote: Hi, On 08/12/2021 15:55, Juerge

Re: [XEN PATCH 36/57] tools/xenstore: Cleanup makefile

On 16.12.21 19:34, Andrew Cooper wrote: On 06/12/2021 17:02, Anthony PERARD wrote: Regroup *FLAGS together, use $(LDLIBS). Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't decribe how to link to a potential libxenstored.so, instead add the value to $(LDLIBS) of xenstored.

[linux-5.4 test] 167449: tolerable FAIL - PUSHED

flight 167449 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/167449/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167422 test-amd64-amd64-xl-qemut-win7-amd64 19

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

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

Re: [RFC v1 2/5] xen/arm: add generic SCI mediator framework

On Tue, 14 Dec 2021, Oleksii Moisieiev wrote: > This patch adds the basic framework for SCI mediator. > SCI is System Control Interface, which is designed to redirect > requests for the Hardware (such as power-domain/clock/resets etc) > from the Domains to the firmware. Originally, cpg should be pa

[ovmf test] 167450: all pass - PUSHED

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

[xen-unstable test] 167448: tolerable FAIL - PUSHED

flight 167448 xen-unstable real [real] flight 167453 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/167448/ http://logs.test-lab.xenproject.org/osstest/logs/167453/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

Re: [PATCH V4 0/6] xen: Add support of extended regions (safe ranges) on Arm

On 09.12.21 22:05, Oleksandr Tyshchenko wrote: Hello Juergen, Boris May I please ask, are you happy (or otherwise) with current patch series (I assume, especially with commits #3-4)? For the convenience:   1. xen/unpopulated-alloc: Drop check for virt_addr_valid() in fill_list() - Review

Re: [PATCH V4 6/6] dt-bindings: xen: Clarify "reg" purpose

On Fri, 10 Dec 2021, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Xen on Arm has gained new support recently to calculate and report > extended regions (unused address space) safe to use for external > mappings. These regions are reported via "reg" property under > "hypervisor" no

Re: [PATCH] xen/arm: vpci: Remove PCI I/O ranges property value

On Thu, 16 Dec 2021, Rahul Singh wrote: > Hi Stefano, > > > On 16 Dec 2021, at 2:33 am, Stefano Stabellini > > wrote: > > > > On Tue, 14 Dec 2021, Rahul Singh wrote: > >> IO ports on ARM don't exist so all IO ports related hypercalls are going > >> to fail on ARM when we passthrough a PCI devic

Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers

On Thu, 16 Dec 2021, Stefano Stabellini wrote: > On Thu, 16 Dec 2021, Juergen Gross wrote: > > On 16.12.21 03:10, Stefano Stabellini wrote: > > > On Wed, 15 Dec 2021, Juergen Gross wrote: > > > > On 14.12.21 18:36, Julien Grall wrote: > > > > > Hi, > > > > > > > > > > On 08/12/2021 15:55, Juergen

Re: [PATCH 0/6] x86: Support PKS

On 16/12/2021 09:54, Andrew Cooper wrote: > I found a spare half hour, and this turned out to go very smoothly. > > It's tentatively RFC right now, because I'm still adding PKS support to the > XTF comprehensive pagewalk test, but the series is definitely fit for review > at this point. I suppose

Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers

On Thu, 16 Dec 2021, Juergen Gross wrote: > On 16.12.21 03:10, Stefano Stabellini wrote: > > On Wed, 15 Dec 2021, Juergen Gross wrote: > > > On 14.12.21 18:36, Julien Grall wrote: > > > > Hi, > > > > > > > > On 08/12/2021 15:55, Juergen Gross wrote: > > > > > Today most hypercall handlers have a r

Re: [PATCH] xen: make some per-scheduler performance counters sched global ones

On Thu, 16 Dec 2021, Jan Beulich wrote: > On 16.12.2021 06:45, Juergen Gross wrote: > > Some performance counters listed to be credit or credit2 specific are > > being used by the null scheduler, too. > > > > Make those sched global ones. > > > > Fixes: ab6ba8c6753fa76 ("perfc: conditionalize cre

[qemu-mainline test] 167443: tolerable FAIL - PUSHED

flight 167443 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/167443/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167426 test-armhf-armhf-libvirt 16 sav

Re: [XEN PATCH 50/57] tools/Rules.mk: Cleanup %.pc rules

On 06/12/2021 17:02, Anthony PERARD wrote: > PKG_CONFIG_VARS isn't used anymore. isn't set any more, so is dead logic. Will tweak on commit. ~Andrew

Re: [XEN PATCH 47/57] libs/stat: Fix and rework python-bindings build

On 06/12/2021 17:02, Anthony PERARD wrote: > Fix the dependency on the library, $(SHLIB) variable doesn't exist > anymore. > > Rework dependency on the include file, we can let `swig` generate the > dependency for us with the use of "-M*" flags. Hmm.  At no point is swig mentioned in README/etc, a

Re: [XEN PATCH 38/57] tools/xenstrace: rework Makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > .PHONY: install > -install: build > +install: all > $(INSTALL_DIR) $(DESTDIR)$(bindir) > $(INSTALL_DIR) $(DESTDIR)$(sbindir) > [ -z "$(LIBBIN)" ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) Doesn't this conditional mkdir want to be dro

Re: [XEN PATCH 37/57] tools/xentop: rework makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > diff --git a/tools/xentop/Makefile b/tools/xentop/Makefile > index 0034114684..1e52b29b37 100644 > --- a/tools/xentop/Makefile > +++ b/tools/xentop/Makefile > @@ -13,24 +13,23 @@ > XEN_ROOT=$(CURDIR)/../.. > include $(XEN_ROOT)/tools/Rules.mk > > -if

Re: [XEN PATCH 36/57] tools/xenstore: Cleanup makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > Regroup *FLAGS together, use $(LDLIBS). > > Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't > decribe how to link to a potential libxenstored.so, instead add the > value to $(LDLIBS) of xenstored. > > Add SYSTEMD_LIBS into $(LDLIBS

Re: [XEN PATCH 35/57] tools/xenpaging: Rework makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > @@ -39,6 +39,6 @@ distclean: clean > > .PHONY: TAGS > TAGS: > - etags -t $(SRCS) *.h > + etags -t *.c *.h /local/xen.git/xen$ git grep -w TAGS: -- :/ ../tools/libs/libs.mk:129:TAGS: ../tools/xenpaging/Makefile:41:TAGS: ../tools/xenstore/Make

Re: [XEN PATCH 34/57] tools/xcutils: rework Makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > Use TARGETS to collect targets to build > > Remove "build" target. > > Signed-off-by: Anthony PERARD > --- > tools/xcutils/Makefile | 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/tools/xcutils/Makefile b/tools/

Re: [XEN PATCH 26/57] tools/firmware/hvmloader: rework Makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > Setup proper dependencies with libacpi so we don't need to run "make > hvmloader" in the "all" target. ("build.o" new prerequisite isn't > exactly proper but a side effect of building the $(DSDT_FILES) is to > generate the "ssdt_*.h" needed by "build.o".

Re: [XEN PATCH 25/57] tools/examples: cleanup Makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > diff --git a/tools/examples/Makefile b/tools/examples/Makefile > index 14e24f4cb3..48b520e133 100644 > --- a/tools/examples/Makefile > +++ b/tools/examples/Makefile > @@ -26,10 +22,8 @@ uninstall: uninstall-readmes uninstall-configs > > .PHONY: instal

Re: [XEN PATCH 24/57] tools/debugger/gdbsx: Fix and cleanup makefiles

On 06/12/2021 17:02, Anthony PERARD wrote: > diff --git a/tools/debugger/gdbsx/Makefile b/tools/debugger/gdbsx/Makefile > index 8d7cd94a31..4aaf427c45 100644 > --- a/tools/debugger/gdbsx/Makefile > +++ b/tools/debugger/gdbsx/Makefile > @@ -28,7 +28,7 @@ uninstall: > gdbsx: gx/gx_all.a xg/xg_all.a

Re: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs

Hi Jan, On Tue, Dec 14, 2021 at 10:41:30AM +0100, Jan Beulich wrote: > On 14.12.2021 10:34, Oleksii Moisieiev wrote: > > --- a/xen/include/public/domctl.h > > +++ b/xen/include/public/domctl.h > > @@ -1177,6 +1177,13 @@ struct xen_domctl_vmtrace_op { > > #define XEN_DOMCTL_vmtrace_get_option

Re: [XEN PATCH 22/57] tools/console: have one Makefile per program/directory

On 06/12/2021 17:02, Anthony PERARD wrote: > Sources of both xenconsoled and xenconsole are already separated into > different directory and don't share anything in common. Having two > different Makefile means it's easier to deal with *FLAGS. > > Some common changes: > Rename $(BIN) to $(TARGETS),

Re: [PATCH] xen/build: Fix `make cscope` rune

Hi Andrew, Andrew Cooper writes: > There are two problems, both in the all_sources definition. As a cscope user I want to thank you for the fix. > > First, everything in arch/*/include gets double hits with cscope queries, > because they end up getting listed twice in cscope.files. > > Drop t

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

Nishanth, On Wed, Dec 15 2021 at 19:45, Nishanth Menon wrote: > On 17:35-20211215, Thomas Gleixner wrote: > Thanks once again for your help. Hope we can roll in the fixes for > part3. Sure, it's only the one-liner for ti sci. Got it folded already. Thanks for your help and testing! tglx

Re: [XEN PATCH 36/57] tools/xenstore: Cleanup makefile

On 06/12/2021 17:02, Anthony PERARD wrote: > Regroup *FLAGS together, use $(LDLIBS). > > Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't > decribe how to link to a potential libxenstored.so, instead add the > value to $(LDLIBS) of xenstored. > > Add SYSTEMD_LIBS into $(LDLIBS

Re: [XEN PATCH 19/57] tools/configure.ac: Create ZLIB_LIBS and ZLIB_CFLAGS

On 06/12/2021 17:02, Anthony PERARD wrote: > diff --git a/tools/libs/guest/Makefile b/tools/libs/guest/Makefile > index 8f5f3acd21..1f4b7f7c58 100644 > --- a/tools/libs/guest/Makefile > +++ b/tools/libs/guest/Makefile > @@ -103,8 +102,7 @@ NO_HEADERS_CHK := y > > include $(XEN_ROOT)/tools/libs/l

Re: [PATCH v2 1/4] x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()

On 16/12/2021 16:51, Jan Beulich wrote: > On 16.12.2021 17:41, Andrew Cooper wrote: >> On 16/12/2021 16:38, Jan Beulich wrote: >>> On 15.12.2021 23:21, Andrew Cooper wrote: To implement dom0-cpuid= support, the special cases would need extending. However there is already a problem with la

Re: [PATCH v2 1/4] x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()

On 16.12.2021 17:41, Andrew Cooper wrote: > On 16/12/2021 16:38, Jan Beulich wrote: >> On 15.12.2021 23:21, Andrew Cooper wrote: >>> To implement dom0-cpuid= support, the special cases would need extending. >>> However there is already a problem with late hwdom where the special cases >>> override

Re: [PATCH v2 4/4] x86/cpuid: Advertise SERIALIZE by default to guests

On 15.12.2021 23:21, Andrew Cooper wrote: > I've played with SERIALIZE, TSXLDTRK, MOVDIRI and MOVDIR64 on real hardware, > and they all seem fine, including emulation support. > > SERIALIZE exists specifically to have a userspace usable serialising operation > without other side effects. (The onl

Re: [PATCH v2 2/4] x86/cpuid: Factor common parsing out of parse_xen_cpuid()

On 16/12/2021 16:41, Jan Beulich wrote: > On 15.12.2021 23:21, Andrew Cooper wrote: >> dom0-cpuid= is going to want to reuse the common parsing loop, so factor it >> out into parse_cpuid(). >> >> Irritatingly, despite being static const, the features[] array gets >> duplicated >> each time parse_c

Re: [PATCH v2 3/4] x86/cpuid: Introduce dom0-cpuid command line option

On 16.12.2021 12:56, Andrew Cooper wrote: > On 15/12/2021 22:21, Andrew Cooper wrote: >> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c >> index e11f5a3c9a6b..83a80ba6de70 100644 >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -116,6 +116,23 @@ static int __init parse_xe

Re: [PATCH v2 3/4] x86/cpuid: Introduce dom0-cpuid command line option

On 15.12.2021 23:21, Andrew Cooper wrote: > Specifically, this lets the user opt in to non-default for dom0. > > Collect all dom0 settings together in dom0_{en,dis}able_feat[], and apply it > to dom0's policy when other tweaks are being made. > > As recalculate_cpuid_policy() is an expensive acti

Re: [PATCH 08/10] iommu/ipmmu-vmsa: Set IPMMU bit IMSCTLR_USE_SECGRP to 0

On 16.12.21 14:48, Yoshihiro Shimoda wrote: Hello Oleksandr-san, Hello Shimoda-san, Thank you for the patch! Thank you for the review! From: Oleksandr Tyshchenko, Sent: Sunday, November 28, 2021 2:52 AM From: Oleksandr Tyshchenko Based on the following commits from the Renesas B

Re: [PATCH v2 1/4] x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()

On 16/12/2021 16:38, Jan Beulich wrote: > On 15.12.2021 23:21, Andrew Cooper wrote: >> To implement dom0-cpuid= support, the special cases would need extending. >> However there is already a problem with late hwdom where the special cases >> override toolstack settings, which is unintended and poor

Re: [PATCH v2 2/4] x86/cpuid: Factor common parsing out of parse_xen_cpuid()

On 15.12.2021 23:21, Andrew Cooper wrote: > dom0-cpuid= is going to want to reuse the common parsing loop, so factor it > out into parse_cpuid(). > > Irritatingly, despite being static const, the features[] array gets duplicated > each time parse_cpuid() is inlined. As it is a large (and ever gro

Re: [PATCH v2 1/4] x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()

On 15.12.2021 23:21, Andrew Cooper wrote: > To implement dom0-cpuid= support, the special cases would need extending. > However there is already a problem with late hwdom where the special cases > override toolstack settings, which is unintended and poor behaviour. > > Introduce a new init_dom0_cp

[libvirt test] 167444: regressions - FAIL

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

Re: [PATCH] xen: arch_mfn_in_directmap: Reconciliate the name and the implementation

Hi Jan, On 16/12/2021 16:11, Jan Beulich wrote: On 16.12.2021 16:22, Julien Grall wrote: From: Julien Grall The name of arch_mfn_in_directmap() suggests that it will check against that the passed MFN should be in the directmap. However, the current callers are passing the next MFN and the im

Re: [PATCH] xen: arch_mfn_in_directmap: Reconciliate the name and the implementation

On 16.12.2021 16:22, Julien Grall wrote: > From: Julien Grall > > The name of arch_mfn_in_directmap() suggests that it will check against > that the passed MFN should be in the directmap. > > However, the current callers are passing the next MFN and the > implementation will return true for up t

Re: [PATCH v2 17/18] AMD/IOMMU: free all-empty page tables

On 15.12.2021 16:14, Roger Pau Monné wrote: > On Fri, Sep 24, 2021 at 11:55:57AM +0200, Jan Beulich wrote: >> When a page table ends up with no present entries left, it can be >> replaced by a non-present entry at the next higher level. The page table >> itself can then be scheduled for freeing. >>

Re: [PATCH v2 16/18] x86: introduce helper for recording degree of contiguity in page tables

On 15.12.2021 14:57, Roger Pau Monné wrote: > On Fri, Sep 24, 2021 at 11:55:30AM +0200, Jan Beulich wrote: >> --- /dev/null >> +++ b/xen/include/asm-x86/contig-marker.h >> @@ -0,0 +1,105 @@ >> +#ifndef __ASM_X86_CONTIG_MARKER_H >> +#define __ASM_X86_CONTIG_MARKER_H >> + >> +/* >> + * Short of havin

[PATCH] xen: arch_mfn_in_directmap: Reconciliate the name and the implementation

From: Julien Grall The name of arch_mfn_in_directmap() suggests that it will check against that the passed MFN should be in the directmap. However, the current callers are passing the next MFN and the implementation will return true for up to one MFN past the directmap. It would be more meaning

Re: [PATCH] xen/build: Fix `make cscope` rune

On 16/12/2021 15:15, Jan Beulich wrote: > On 16.12.2021 15:58, Andrew Cooper wrote: >> On 16/12/2021 14:00, Jan Beulich wrote: >>> On 16.12.2021 10:20, Andrew Cooper wrote: Second, and this way for a long time: $ make cscope ( find arch/x86/include -name '*.h' -print; find i

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

On 16.12.2021 15:55, Julien Grall wrote: > Hi, > > On 16/12/2021 14:26, Michal Orzel wrote: >> On 16.12.2021 14:50, Jan Beulich wrote: >>> On 16.12.2021 10:21, Michal Orzel wrote: to hypervisor when switching from AArch32 state. According to section D1.20.2 of Arm Arm(DDI 0487A.j):

Re: [PATCH] xen/build: Fix `make cscope` rune

On 16.12.2021 15:58, Andrew Cooper wrote: > On 16/12/2021 14:00, Jan Beulich wrote: >> On 16.12.2021 10:20, Andrew Cooper wrote: >>> Second, and this way for a long time: >>> >>> $ make cscope >>> ( find arch/x86/include -name '*.h' -print; find include -name '*.h' >>> -print; >>> find xsm a

Re: [PATCH] xen/build: Fix `make cscope` rune

On 16/12/2021 14:00, Jan Beulich wrote: > On 16.12.2021 10:20, Andrew Cooper wrote: >> Second, and this way for a long time: >> >> $ make cscope >> ( find arch/x86/include -name '*.h' -print; find include -name '*.h' >> -print; >> find xsm arch/x86 common drivers lib test -name '*.[chS]' -pr

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

Hi, On 16/12/2021 14:26, Michal Orzel wrote: On 16.12.2021 14:50, Jan Beulich wrote: On 16.12.2021 10:21, Michal Orzel wrote: to hypervisor when switching from AArch32 state. According to section D1.20.2 of Arm Arm(DDI 0487A.j): "If the general-purpose register was accessible from AArch32 sta

Re: [PATCH] xen/build: Fix `make cscope` rune

On Thu, Dec 16, 2021 at 09:20:14AM +, Andrew Cooper wrote: > There are two problems, both in the all_sources definition. > > First, everything in arch/*/include gets double hits with cscope queries, > because they end up getting listed twice in cscope.files. > > Drop the first `find` rune of

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

On 16.12.2021 15:26, Michal Orzel wrote: > > > On 16.12.2021 14:50, Jan Beulich wrote: >> On 16.12.2021 10:21, Michal Orzel wrote: >>> to hypervisor when switching from AArch32 state. >>> >>> According to section D1.20.2 of Arm Arm(DDI 0487A.j): >>> "If the general-purpose register was accessible

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

On 16.12.2021 14:50, Jan Beulich wrote: > On 16.12.2021 10:21, Michal Orzel wrote: >> to hypervisor when switching from AArch32 state. >> >> According to section D1.20.2 of Arm Arm(DDI 0487A.j): >> "If the general-purpose register was accessible from AArch32 state the >> upper 32 bits either bec

Re: [XEN PATCH 16/57] tools/ocaml: Remove generation of _paths.h

On 06/12/2021 17:01, Anthony PERARD wrote: > _paths.h isn't useful anymore in systemd_stubs. > > Signed-off-by: Anthony PERARD I poked Christian, who's looked at this and given it an ack.  For some reason, he doesn't appear to have this email in his inbox. ~Andrew

[ovmf test] 167445: all pass - PUSHED

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

Re: [PATCH] xen/build: Fix `make cscope` rune

On 16.12.2021 10:20, Andrew Cooper wrote: > There are two problems, both in the all_sources definition. > > First, everything in arch/*/include gets double hits with cscope queries, > because they end up getting listed twice in cscope.files. > > Drop the first `find` rune of the three, because it

Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

On Thu, Dec 16, 2021 at 11:17:12AM +, Andrew Cooper wrote: > What should happen is the domain builder place OVMF there directly.  > OVMF is linked to run there, and there ought to be no hvmloader involved > for UEFI guests, and there shouldn't be any copying into place > required.  That was a v

Re: [PATCH v2] xen/arm64: Zero the top 32 bits of gp registers on entry...

On 16.12.2021 10:21, Michal Orzel wrote: > to hypervisor when switching from AArch32 state. > > According to section D1.20.2 of Arm Arm(DDI 0487A.j): > "If the general-purpose register was accessible from AArch32 state the > upper 32 bits either become zero, or hold the value that the same > archi

Re: [PATCH] xen/vpci: msix: move x86 specific code to x86 file

On 16.12.2021 12:01, Roger Pau Monné wrote: > On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote: >> Hi Roger, >> >> Thanks for reviewing the code. >> >>> On 14 Dec 2021, at 12:37 pm, Roger Pau Monné wrote: >>> >>> On Tue, Dec 14, 2021 at 10:45:17AM +, Rahul Singh wrote: +

Re: [PATCH] x86: enable interrupts around dump_execstate()

On 16.12.2021 12:54, Andrew Cooper wrote: > On 13/12/2021 15:12, Jan Beulich wrote: >> show_hvm_stack() requires interrupts to be enabled to avoids triggering >> the consistency check in check_lock() for the p2m lock. To do so in >> spurious_interrupt() requires adding reentrancy protection / handl

RE: [PATCH 10/10] iommu/arm: Remove code duplication in all IOMMU drivers

Hello Oleksandr-san, > From: Oleksandr Tyshchenko, Sent: Sunday, November 28, 2021 2:52 AM > > From: Oleksandr Tyshchenko > > All IOMMU drivers on Arm perform almost the same generic actions in > hwdom_init callback. Move this code to common arch_iommu_hwdom_init() > in order to get rid of code

RE: [PATCH 09/10] iommu/ipmmu-vmsa: Use refcount for the micro-TLBs

Hello Oleksandr-san, Thank you for the patch! > From: Oleksandr Tyshchenko, Sent: Sunday, November 28, 2021 2:52 AM > > From: Oleksandr Tyshchenko > > Reference-count the micro-TLBs as several bus masters can be > connected to the same micro-TLB (and drop TODO comment). > This wasn't an issue

[xen-unstable test] 167440: trouble: broken/fail/pass

flight 167440 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/167440/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt broken test-armhf-armhf-lib

RE: [PATCH 08/10] iommu/ipmmu-vmsa: Set IPMMU bit IMSCTLR_USE_SECGRP to 0

Hello Oleksandr-san, Thank you for the patch! > From: Oleksandr Tyshchenko, Sent: Sunday, November 28, 2021 2:52 AM > > From: Oleksandr Tyshchenko > > Based on the following commits from the Renesas BSP: > 8fba83d97cca709a05139c38e29408e81ed4cf62 > a8d93bc07da89a7fcf4d85f34d119a030310efa5 > lo

Re: [XEN PATCH 14/57] tools/flask/utils: remove unused variables/targets from Makefile

On 06/12/2021 17:01, Anthony PERARD wrote: > @@ -35,21 +29,13 @@ flask-set-bool: set-bool.o > > .PHONY: clean > clean: > - rm -f *.o *.opic *.so > + rm -f *.o > rm -f $(CLIENTS) > $(RM) $(DEPS_RM) Can we collapse this to $(RM) *.o $(CLIENTS) $(DEPS_RM) ? Here and in plent

Re: [XEN PATCH 14/57] tools/flask/utils: remove unused variables/targets from Makefile

On 12/6/21 12:01 PM, Anthony PERARD wrote: They are no *.opic or *.so in this subdir, so no need to clean them. The TEST* variables doesn't seems to be used anywhere, and they weren't used by xen.git when introduced. Both CLIENTS_* variables aren't used. Both target "print-dir" and "print-end" o

Re: [XEN PATCH v8 34/47] build: add %.E targets

On Thu, Dec 16, 2021 at 11:18:08AM +, Andrew Cooper wrote: > On 25/11/2021 13:39, Anthony PERARD wrote: > > I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)". > > > > -%.o %.i %.s: %.c tools_fixdep FORCE > > +%.o %.i %.s %.E: %.c tools_fixdep FORCE > > $(Q)$(MAKE) $(build

Re: [PATCH v2 3/4] x86/cpuid: Introduce dom0-cpuid command line option

On 15/12/2021 22:21, Andrew Cooper wrote: > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c > index e11f5a3c9a6b..83a80ba6de70 100644 > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -116,6 +116,23 @@ static int __init parse_xen_cpuid(const char *s) > } > custom_param("cpui

Re: [PATCH] x86: enable interrupts around dump_execstate()

On 13/12/2021 15:12, Jan Beulich wrote: > show_hvm_stack() requires interrupts to be enabled to avoids triggering > the consistency check in check_lock() for the p2m lock. To do so in > spurious_interrupt() requires adding reentrancy protection / handling > there. > > Fixes: adb715db698b ("x86/HVM:

Re: [XEN PATCH 15/57] tools/libacpi: cleanup Makefile, don't check for iasl binary

On 06/12/2021 17:01, Anthony PERARD wrote: > iasl is been check for presence by ./configure, so this Makefile > doesn't have to do it. Also start to use $(IASL) that ./configure > generate. > > iasl hasn't been download by our build system for a while and the > dependency on iasl is in the main xen

Re: [PATCH v2 14/18] IOMMU: fold flush-all hook into "flush one"

Hi Jan > On 24 Sep 2021, at 10:53 am, Jan Beulich wrote: > > Having a separate flush-all hook has always been puzzling me some. We > will want to be able to force a full flush via accumulated flush flags > from the map/unmap functions. Introduce a respective new flag and fold > all flush handlin

Re: [PATCH] hvmloader: tidy pci_mem_{start,end}

On 14/12/2021 08:24, Jan Beulich wrote: > For one at least pci_mem_start has to be precisely 32 bits wide, so use > uint32_t for both. Otherwise expressions like "pci_mem_start <<= 1" > won't have the intended effect (in their context). > > Further since its introduction pci_mem_end was never writt

Re: [XEN PATCH v8 34/47] build: add %.E targets

On 25/11/2021 13:39, Anthony PERARD wrote: > I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)". > > Suggested-by: Andrew Cooper > Signed-off-by: Anthony PERARD > --- > xen/Makefile | 4 ++-- > xen/Rules.mk | 5 + > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff

Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

On 16/12/2021 11:09, Roger Pau Monné wrote: > On Thu, Dec 16, 2021 at 11:00:17AM +, Andrew Cooper wrote: >> On 16/12/2021 09:54, Roger Pau Monné wrote: >>> On Tue, Dec 14, 2021 at 09:21:22AM +0100, Jan Beulich wrote: This reverts commit c22bd567ce22f6ad9bd93318ad0d7fd1c2eadb0d. W

Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

On Thu, Dec 16, 2021 at 11:00:17AM +, Andrew Cooper wrote: > On 16/12/2021 09:54, Roger Pau Monné wrote: > > On Tue, Dec 14, 2021 at 09:21:22AM +0100, Jan Beulich wrote: > >> This reverts commit c22bd567ce22f6ad9bd93318ad0d7fd1c2eadb0d. > >> > >> While its description is correct from an abstrac

Re: [XEN PATCH v8 12/47] build: build everything from the root dir, use obj=$subdir

On Tue, Dec 07, 2021 at 12:10:34PM +0100, Jan Beulich wrote: > On 25.11.2021 14:39, Anthony PERARD wrote: > > A subdirectory is now built by setting "$(obj)" instead of changing > > directory. "$(obj)" should always be set when using "Rules.mk" and > > thus a shortcut "$(build)" is introduced and s

Re: [PATCH] xen/vpci: msix: move x86 specific code to x86 file

On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote: > Hi Roger, > > Thanks for reviewing the code. > > > On 14 Dec 2021, at 12:37 pm, Roger Pau Monné wrote: > > > > On Tue, Dec 14, 2021 at 10:45:17AM +, Rahul Singh wrote: > >> + unsigned long *data) > >> { > >> -co

Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

On 16/12/2021 09:54, Roger Pau Monné wrote: > On Tue, Dec 14, 2021 at 09:21:22AM +0100, Jan Beulich wrote: >> This reverts commit c22bd567ce22f6ad9bd93318ad0d7fd1c2eadb0d. >> >> While its description is correct from an abstract or real hardware pov, >> the range is special inside HVM guests. The ra

Re: [PATCH v2 14/18] IOMMU: fold flush-all hook into "flush one"

On 16.12.21 10:49, Jan Beulich wrote: Hi Jan On 15.12.2021 16:28, Oleksandr wrote: On 24.09.21 12:53, Jan Beulich wrote: Having a separate flush-all hook has always been puzzling me some. We will want to be able to force a full flush via accumulated flush flags from the map/unmap functions

Re: [PATCH] xen/vpci: msix: move x86 specific code to x86 file

Hi Jan, Thanks for reviewing the code. > On 14 Dec 2021, at 2:15 pm, Jan Beulich wrote: > > On 14.12.2021 11:45, Rahul Singh wrote: >> --- a/xen/drivers/vpci/msix.c >> +++ b/xen/drivers/vpci/msix.c >> @@ -17,15 +17,24 @@ >> * License along with this program; If not, see >>

Re: [PATCH] xen/vpci: msix: move x86 specific code to x86 file

Hi Roger, Thanks for reviewing the code. > On 14 Dec 2021, at 12:37 pm, Roger Pau Monné wrote: > > On Tue, Dec 14, 2021 at 10:45:17AM +, Rahul Singh wrote: >> vpci/msix.c file will be used for arm architecture when vpci msix >> support will be added to ARM, but there is x86 specific code in

Re: [PATCH] xen/arm: vpci: Remove PCI I/O ranges property value

Hi Stefano, > On 16 Dec 2021, at 2:33 am, Stefano Stabellini wrote: > > On Tue, 14 Dec 2021, Rahul Singh wrote: >> IO ports on ARM don't exist so all IO ports related hypercalls are going >> to fail on ARM when we passthrough a PCI device. >> Failure of xc_domain_ioport_permission(..) would turn

[PATCH 2/6] x86/prot-key: Split PKRU infrastructure out of asm/processor.h

asm/processor.h is in desperate need of splitting up, and protection key functionality in only used in the emulator and pagewalk. Introduce a new asm/prot-key.h and move the relevant content over. Rename the PKRU_* constants to drop the user part and to use the architectural terminology. Drop th

[PATCH 5/6] x86/pagewalk: Support PKS

PKS is incredibly similar to the existing PKU behaviour, operating on pagewalks for any supervisor mapping. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/arch/x86/include/asm/guest_pt.h | 5 + xen/arch/x86/include/asm/hvm/hvm.h | 3 +++ xen/arch

[PATCH 3/6] x86/hvm: Context switch MSR_PKRS

Under PKS, MSR_PKRS is available and based on the CPUID policy alone, and usable independently of CR4.PKS. See the large comment in prot-key.h for details of the context switching arrangement. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Kevin Tian At

[PATCH 4/6] x86/hvm: Enable guest access to MSR_PKRS

Have guest_{rd,wr}msr() access either the live register, or stashed state, depending on context. Include MSR_PKRS for migration, and let the guest have full access. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Kevin Tian --- xen/arch/x86/hvm/hvm.c

[PATCH 0/6] x86: Support PKS

I found a spare half hour, and this turned out to go very smoothly. It's tentatively RFC right now, because I'm still adding PKS support to the XTF comprehensive pagewalk test, but the series is definitely fit for review at this point. Andrew Cooper (6): x86/prot-key: Enumeration for Protection

[PATCH 1/6] x86/prot-key: Enumeration for Protection Key Supervisor

Protection Key Supervisor works in a very similar way to Protection Key User, except that instead of a PKRU register used by the {RD,WR}PKRU instructions, the supervisor protection settings live in MSR_PKRS and is accessed using normal {RD,WR}MSR instructions. PKS has the same problematic interact

[PATCH 6/6] x86/hvm: Support PKS

With all infrastructure in place, advertise the PKS CPUID bit to guests, and let them set CR4.PKS. Experiment with a tweak to the layout of hvm_cr4_guest_valid_bits() so future additions will be just a single added line. The current context switching behaviour is tied to how VT-x works, so leave

Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

On Tue, Dec 14, 2021 at 09:21:22AM +0100, Jan Beulich wrote: > This reverts commit c22bd567ce22f6ad9bd93318ad0d7fd1c2eadb0d. > > While its description is correct from an abstract or real hardware pov, > the range is special inside HVM guests. The range being UC in particular > gets in the way of O

  1   2   >