Re: [PATCH v2] Grab the EFI System Resource Table and check it

Hi, > > diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h > index 458cfbbed4..398a2411a1 100644 > --- a/xen/arch/arm/efi/efi-boot.h > +++ b/xen/arch/arm/efi/efi-boot.h > @@ -187,7 +187,8 @@ static bool __init meminfo_add_bank(struct meminfo *mem, > > static EFI_STATUS __init

Re: [PATCH v1 3/5] xen/arm: unpopulate memory when domain on static allocation

On 31.03.2022 08:13, Penny Zheng wrote: > Hi Jan > >> -Original Message- >> From: Jan Beulich >> Sent: Wednesday, March 30, 2022 5:53 PM >> To: Penny Zheng >> Cc: Wei Chen ; Henry Wang ; >> Andrew Cooper ; George Dunlap >> ; Julien Grall ; Stefano Stabellini >> ; Wei Liu ; xen- >> de...@

[PATCH] tools/libs/light: update xenstore entry when setting max domain memory

libxl_domain_setmaxmem() should update the domain's memory/static-max Xenstore node, as otherwise "xl mem-set" won't be able to set the memory size to the new maximum. Signed-off-by: Juergen Gross --- tools/libs/light/libxl_mem.c | 9 + 1 file changed, 9 insertions(+) diff --git a/tools

[PATCH v3 0/2] xen: Linker scripts synchronization

This patch series aims to do the first step towards linker scripts synchronization. Linker scripts for arm and x86 share a lot of common sections and in order to make the process of changing/improving/syncing them, these sections shall be defined in just one place. The first patch creates an empty

[PATCH v3 1/2] xen: Introduce a header to store common linker scripts content

Both x86 and arm linker scripts share quite a lot of common content. It is difficult to keep syncing them up, thus introduce a new header in include/xen called xen.lds.h to store the internals mutual to all the linker scripts. Include this header in linker scripts for x86 and arm. This patch serve

[PATCH v3 2/2] xen: Populate xen.lds.h and make use of its macros

Populate header file xen.lds.h with the first portion of macros storing constructs common to x86 and arm linker scripts. Replace the original constructs with these helpers. No functional improvements to x86 linker script. Making use of common macros improves arm linker script with: - explicit lis

Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch

On Thu, Mar 31, 2022 at 08:42:47AM +0200, Jan Beulich wrote: > On 30.03.2022 19:04, Roger Pau Monné wrote: > > On Wed, Mar 30, 2022 at 01:05:31PM +0200,>> --- a/xen/arch/x86/livepatch.c > >> +++ b/xen/arch/x86/livepatch.c > >> @@ -157,9 +157,15 @@ void noinline arch_livepatch_apply(struc > >>

Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch

On 31.03.2022 10:01, Roger Pau Monné wrote: > On Thu, Mar 31, 2022 at 08:42:47AM +0200, Jan Beulich wrote: >> On 30.03.2022 19:04, Roger Pau Monné wrote: >>> On Wed, Mar 30, 2022 at 01:05:31PM +0200,>> --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -157,9 +157,15 @@ void

Re: [PATCH v3] livepatch: account for patch offset when applying NOP patch

On Thu, Mar 31, 2022 at 08:49:46AM +0200, Jan Beulich wrote: > While not triggered by the trivial xen_nop in-tree patch on > staging/master, that patch exposes a problem on the stable trees, where > all functions have ENDBR inserted. When NOP-ing out a range, we need to > account for this. Handle t

Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch

On Thu, Mar 31, 2022 at 10:13:06AM +0200, Jan Beulich wrote: > On 31.03.2022 10:01, Roger Pau Monné wrote: > > On Thu, Mar 31, 2022 at 08:42:47AM +0200, Jan Beulich wrote: > >> On 30.03.2022 19:04, Roger Pau Monné wrote: > >>> On Wed, Mar 30, 2022 at 01:05:31PM +0200,>> --- a/xen/arch/x86/livepatch

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

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

Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch

On 31.03.2022 10:27, Roger Pau Monné wrote: > On Thu, Mar 31, 2022 at 10:13:06AM +0200, Jan Beulich wrote: >> On 31.03.2022 10:01, Roger Pau Monné wrote: >>> On Thu, Mar 31, 2022 at 08:42:47AM +0200, Jan Beulich wrote: On 30.03.2022 19:04, Roger Pau Monné wrote: > On Wed, Mar 30, 2022 at 0

Re: [PATCH v3] livepatch: account for patch offset when applying NOP patch

On 31.03.2022 10:21, Roger Pau Monné wrote: > On Thu, Mar 31, 2022 at 08:49:46AM +0200, Jan Beulich wrote: >> While not triggered by the trivial xen_nop in-tree patch on >> staging/master, that patch exposes a problem on the stable trees, where >> all functions have ENDBR inserted. When NOP-ing out

Re: OS Headers hypercall.h/hypervisor.h

Hi Elliot, On 31/03/2022 02:15, Elliott Mitchell wrote: On Tue, Mar 29, 2022 at 08:27:24AM +0200, Jan Beulich wrote: On 29.03.2022 00:25, Stefano Stabellini wrote: On Sat, 26 Mar 2022, Elliott Mitchell wrote: The hypercalls implementation for Linux and FreeBSD have two key headers, hypercall.

Re: [PATCH] Livepatch: fix typos

On 11.03.2022 20:11, Bjoern Doebel wrote: > Fix a couple of typos in livepatch code. > > Signed-off-by: Bjoern Doebel > CC: Konrad Rzeszutek Wilk > CC: Ross Lagerwall Acked-by: Jan Beulich and committed in spite of a lack of a maintainer ack. Jan

[PATCH v4 0/4] x86: further time/APIC improvements (and more)

... plus some tidying (or so I hope). While perhaps seemingly unrelated, the 3rd patch is actually a result of my (successlessly) hunting for PASTE() or alike, as now being introduced by patch 2. 1: APIC: calibrate against platform timer when possible 2: APIC: make connections between seemingly a

[PATCH v3 0/3] amd/msr: implement MSR_VIRT_SPEC_CTRL for HVM guests

Hello, The following series implements support for MSR_VIRT_SPEC_CTRL (VIRT_SSBD) on different AMD CPU families. Note that the support is added backwards, starting with the newer CPUs that support MSR_SPEC_CTRL and moving to the older ones either using MSR_VIRT_SPEC_CTRL or the SSBD bit in LS_CFG

[PATCH v3 1/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL

Use the logic to set shadow SPEC_CTRL values in order to implement support for VIRT_SPEC_CTRL (signaled by VIRT_SSBD CPUID flag) for HVM guests. This includes using the spec_ctrl vCPU MSR variable to store the guest set value of VIRT_SPEC_CTRL.SSBD, which will be OR'ed with any SPEC_CTRL values bei

[PATCH v3 2/3] amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests

Allow HVM guests untrapped access to MSR_VIRT_SPEC_CTRL if the hardware has support for it. This requires adding logic in the vm{entry,exit} paths for SVM in order to context switch between the hypervisor value and the guest one. The added handlers for context switch will also be used for the legac

[PATCH v3 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

Expose VIRT_SSBD to guests if the hardware supports setting SSBD in the LS_CFG MSR (a.k.a. non-architectural way). Different AMD CPU families use different bits in LS_CFG, so exposing VIRT_SPEC_CTRL.SSBD allows for an unified way of exposing SSBD support to guests on AMD hardware that's compatible

[PATCH v4 1/4] x86/APIC: calibrate against platform timer when possible

Use the original calibration against PIT only when the platform timer is PIT. This implicitly excludes the "xen_guest" case from using the PIT logic (init_pit() fails there, and as of 5e73b2594c54 ["x86/time: minor adjustments to init_pit()"] using_pit also isn't being set too early anymore), so th

[PATCH v4 3/4] include: move STR() and IS_ALIGNED()

lib.h is imo a better fit for them than config.h. Signed-off-by: Jan Beulich --- v4: New. --- Originally I thought I'd also move KB() etc, but they're used in places where yet further adjustments (adding of #include) would be necessary. --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @

[PATCH v4 4/4] x86/time: use fake read_tsc()

Go a step further than bed9ae54df44 ("x86/time: switch platform timer hooks to altcall") did and eliminate the "real" read_tsc() altogether: It's not used except in pointer comparisons, and hence it looks overall more safe to simply poison plt_tsc's read_counter hook. Signed-off-by: Jan Beulich -

[PATCH v4 2/4] x86/APIC: make connections between seemingly arbitrary numbers

Making adjustments to arbitrarily chosen values shouldn't require auditing the code for possible derived numbers - such a change should be doable in a single place, having an effect on all code depending on that choice. For one make the TDCR write actually use APIC_DIVISOR. With the necessary mask

[PATCH v4 0/8] x86/boot: (mostly) video mode handling adjustments

v4 largely has some re-basing changes compared to v3, plus one new patch. I have to admit that I find it particularly sad that the enhancement done by patch 1 has not made 4.16. This series had been submitted well in time. 1: make "vga=current" work with graphics modes 2: obtain video info from bo

[PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

GrUB2 can be told to leave the screen in the graphics mode it has been using (or any other one), via "set gfxpayload=keep" (or suitable variants thereof). In this case we can avoid doing another mode switch ourselves. This in particular avoids possibly setting the screen to a less desirable mode: O

[PATCH v4 2/8] x86/boot: obtain video info from boot loader

With MB2 the boot loader may provide this information, allowing us to obtain it without needing to enter real mode (assuming we don't need to set a new mode from "vga=", but can instead inherit the one the bootloader may have established). Signed-off-by: Jan Beulich --- v4: Re-base. v3: Re-base.

[PATCH v4 3/8] x86/EFI: retrieve EDID

When booting directly from EFI, obtaining this information from EFI is the only possible way. And even when booting with a boot loader interposed, it's more clean not to use legacy BIOS calls for this purpose. (The downside being that there are no "capabilities" that we can retrieve the EFI way.)

[PATCH v4 4/8] x86/boot: simplify mode_table

There's no point in writing 80x25 text mode information via multiple insns all storing immediate values. The data can simply be included first thing in the vga_modes table, allowing the already present REP MOVSB to take care of everything in one go. While touching this also correct a related but s

[PATCH v4 5/8] x86/boot: fold branches in video handling code

Using Jcc to branch around a JMP is necessary only in pre-386 code, where Jcc is limited to disp8. Use the opposite Jcc directly in two places. Since it's adjacent, also convert an ORB to TESTB. Signed-off-by: Jan Beulich --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -332,8

[PATCH v4 6/8] x86/boot: fold/replace moves in video handling code

Replace (mainly) MOV forms with shorter insns (or sequences thereof). Signed-off-by: Jan Beulich --- Of course there's more room for improvement. For example there look to be a number of LEAs which really could be MOVs. --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -121,8 +1

[PATCH v4 7/8] x86/boot: LEA -> MOV in video handling code

Replace most LEA instances with (one byte shorter) MOV. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -60,7 +60,7 @@ video: xorw%ax, %ax callmode_set# Set the mode jc vid1 -

[PATCH v4 8/8] x86/boot: fold two MOVs into an ADD

There's no point going through %ax; the addition can be done directly in %di. Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/boot/mem.S +++ b/xen/arch/x86/boot/mem.S @@ -24,9 +24,7 @@ get_memory_map: cmpw$E820_BIOS_MAX, bootsym(bios_e820nr) # up to this many entries

RE: [PATCH v1 3/5] xen/arm: unpopulate memory when domain on static allocation

Hi Jan > -Original Message- > From: Jan Beulich > Sent: Thursday, March 31, 2022 3:06 PM > To: Penny Zheng > Cc: Wei Chen ; Henry Wang ; > Andrew Cooper ; George Dunlap > ; Julien Grall ; Stefano Stabellini > ; Wei Liu ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v1 3/5] xe

Re: [PATCH v4 3/4] include: move STR() and IS_ALIGNED()

Hi Jan, On 31/03/2022 10:31, Jan Beulich wrote: lib.h is imo a better fit for them than config.h. Signed-off-by: Jan Beulich Reviewed-by: Julien Grall Cheers, --- v4: New. --- Originally I thought I'd also move KB() etc, but they're used in places where yet further adjustments (adding of

Re: [PATCH v8 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86

On 23/03/2022 11:30, Roger Pau Monné wrote: > On Wed, Mar 16, 2022 at 09:13:14AM +, Jane Malalane wrote: >> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >> index e1e1fa14e6..77ce0b2121 100644 >> --- a/xen/arch/x86/hvm/vmx/vmcs.c >> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>

[ANNOUNCE] Call for agenda items for 5 April Community Call @ 1500 UTC

Hi all, The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/LX1iwUFsMmBkyttPZuN5SvRE/ and you can edit to add items. Alternatively, you can reply to this mail directly. Agenda items appreciated a few days before the call: please put your name besides items if you edit the document

Re: [PATCH v2] Grab the EFI System Resource Table and check it

On Thu, Mar 31, 2022 at 07:04:34AM +, Luca Fancellu wrote: > Hi, > > > > > diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h > > index 458cfbbed4..398a2411a1 100644 > > --- a/xen/arch/arm/efi/efi-boot.h > > +++ b/xen/arch/arm/efi/efi-boot.h > > @@ -187,7 +187,8 @@ static

Re: Increasing domain memory beyond initial maxmem

On Thu, Mar 31, 2022 at 08:41:19AM +0200, Juergen Gross wrote: > On 31.03.22 05:51, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I'm trying to make use of CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y to increase > > domain memory beyond initial maxmem, but I hit few issues. > > > > A little context:

Re: [PATCH v2] Grab the EFI System Resource Table and check it

> On 31 Mar 2022, at 12:57, Demi Marie Obenour > wrote: > > On Thu, Mar 31, 2022 at 07:04:34AM +, Luca Fancellu wrote: >> Hi, >> >>> >>> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h >>> index 458cfbbed4..398a2411a1 100644 >>> --- a/xen/arch/arm/efi/efi-boot.h >>

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

flight 169064 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169064/ 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: Increasing domain memory beyond initial maxmem

On 31.03.22 14:01, Marek Marczykowski-Górecki wrote: On Thu, Mar 31, 2022 at 08:41:19AM +0200, Juergen Gross wrote: On 31.03.22 05:51, Marek Marczykowski-Górecki wrote: Hi, I'm trying to make use of CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y to increase domain memory beyond initial maxmem, but I hit

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On Thu, Mar 31, 2022 at 12:34 AM Chuck Zmudzinski wrote: > > On 3/30/22 2:45 PM, Jason Andryuk wrote: > > On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote: > >> On 14.03.2022 04:41, Chuck Zmudzinski wrote: > >>> When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD > >>> opregio

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski wrote: > > On 3/30/22 1:27 PM, Andrew Cooper wrote: > > On 30/03/2022 18:15, Anthony PERARD wrote: > >> > >> Some more though on that, looking at QEMU, it seems that there's already > >> a call to xc_domain_iomem_permission(), in igd_write_opregion

Re: Increasing domain memory beyond initial maxmem

On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote: > Maybe some kernel config differences, or other udev rules (memory onlining > is done via udev in my guest)? > > I'm seeing: > > # zgrep MEMORY_HOTPLUG /proc/config.gz > CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y > CONFIG_MEMORY_HOTPLUG=y >

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On Wed, Mar 30, 2022 at 07:05:48PM -0400, Daniel P. Smith wrote: > There are now instances where internal hypervisor logic needs to make resource > allocation calls that are protected by XSM checks. The internal hypervisor > logic > is represented a number of system domains which by designed are r

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

flight 169017 qemu-mainline real [real] flight 169067 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169017/ http://logs.test-lab.xenproject.org/osstest/logs/169067/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-am

Re: [PATCH 2/2] arch: ensure idle domain is not left privileged

On Wed, Mar 30, 2022 at 07:05:49PM -0400, Daniel P. Smith wrote: > It is now possible to promote the idle domain to privileged during setup. It > is not desirable for the idle domain to still be privileged when moving into a > running state. If the idle domain was elevated and not properly demoted

Re: [PATCH 2/2] arch: ensure idle domain is not left privileged

Hi, On 31/03/2022 13:46, Roger Pau Monné wrote: On Wed, Mar 30, 2022 at 07:05:49PM -0400, Daniel P. Smith wrote: It is now possible to promote the idle domain to privileged during setup. It is not desirable for the idle domain to still be privileged when moving into a running state. If the idl

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith wrote: > > There are now instances where internal hypervisor logic needs to make resource > allocation calls that are protected by XSM checks. The internal hypervisor > logic > is represented a number of system domains which by designed are represen

[ovmf test] 169046: regressions - FAIL

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

Re: [PATCH] libxl: Always set ao for qmp_proxy_spawn_outcome

On Wed, Mar 30, 2022 at 02:16:58PM -0400, Jason Andryuk wrote: > diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c > index 9a8ddbe188..59a8dcf3a9 100644 > --- a/tools/libs/light/libxl_dm.c > +++ b/tools/libs/light/libxl_dm.c > @@ -2468,6 +2468,9 @@ static void spawn_stub_launch

Re: [PATCH] libxl: constify libxl__stubdomain_is_linux

On Wed, Mar 30, 2022 at 02:17:22PM -0400, Jason Andryuk wrote: > libxl__stubdomain_is_linux can take a const pointer, so make the change. > > This isn't an issue in-tree, but was found with an OpenXT patch where it > was called with only const libxl_domain_build_info available. > > Signed-off-by:

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/31/2022 8:23 AM, Jason Andryuk wrote: On Thu, Mar 31, 2022 at 12:34 AM Chuck Zmudzinski wrote: On 3/30/22 2:45 PM, Jason Andryuk wrote: On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote: On 14.03.2022 04:41, Chuck Zmudzinski wrote: When gfx_passthru is enabled for the Intel IGD, hvmloa

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/31/2022 8:29 AM, Jason Andryuk wrote: On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski wrote: On 3/30/22 1:27 PM, Andrew Cooper wrote: This has been discussed before, but noone's done anything about it. It's a massive layering violation for QEMU to issue xc_domain_iomem_permission()/etc

Re: [PATCH] libxl: Don't segfault on soft-reset failure

On Wed, Mar 30, 2022 at 02:17:27PM -0400, Jason Andryuk wrote: > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c > index 15ed021f41..631caa416d 100644 > --- a/tools/libs/light/libxl_create.c > +++ b/tools/libs/light/libxl_create.c > @@ -1970,7 +1970,8 @@ static void d

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski wrote: > > On 3/31/2022 8:29 AM, Jason Andryuk wrote: > > On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski > > wrote: > >> On 3/30/22 1:27 PM, Andrew Cooper wrote: > >>> > >>> This has been discussed before, but noone's done anything about it. >

Re: [PATCH] libxl: Always set ao for qmp_proxy_spawn_outcome

On Thu, Mar 31, 2022 at 9:24 AM Anthony PERARD wrote: > > On Wed, Mar 30, 2022 at 02:16:58PM -0400, Jason Andryuk wrote: > > diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c > > index 9a8ddbe188..59a8dcf3a9 100644 > > --- a/tools/libs/light/libxl_dm.c > > +++ b/tools/libs/lig

Re: [PATCH] xl: Fix global pci options

On Wed, Mar 30, 2022 at 02:17:41PM -0400, Jason Andryuk wrote: > commit babde47a3fed "introduce a 'passthrough' configuration option to > xl.cfg..." moved the pci list parsing ahead of the global pci option > parsing. This broke the global pci configuration options since they > need to be set firs

Ping: [XEN PATCH v10 1/7] build: grab common EFI source files in arch specific dir

Hi Julien, Stefano, Bertrand, Could I get a ack on this patch and the next one "[XEN PATCH v10 2/7] build: replace $(BASEDIR) by $(objtree)" for the Arm part? Cheers, On Tue, Mar 22, 2022 at 11:22:32AM +, Anthony PERARD wrote: > Rather than preparing the efi source file, we will make the sym

Re: OS Headers hypercall.h/hypervisor.h

On Thu, Mar 31, 2022 at 09:44:06AM +0100, Julien Grall wrote: > > On 31/03/2022 02:15, Elliott Mitchell wrote: > > On Tue, Mar 29, 2022 at 08:27:24AM +0200, Jan Beulich wrote: > >> On 29.03.2022 00:25, Stefano Stabellini wrote: > >>> On Sat, 26 Mar 2022, Elliott Mitchell wrote: > The hypercal

[xen-4.14-testing test] 169028: regressions - FAIL

flight 169028 xen-4.14-testing real [real] flight 169071 xen-4.14-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169028/ http://logs.test-lab.xenproject.org/osstest/logs/169071/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

Re: [PATCH] libxl: Don't segfault on soft-reset failure

On Thu, Mar 31, 2022 at 10:10 AM Anthony PERARD wrote: > > On Wed, Mar 30, 2022 at 02:17:27PM -0400, Jason Andryuk wrote: > > diff --git a/tools/libs/light/libxl_create.c > > b/tools/libs/light/libxl_create.c > > index 15ed021f41..631caa416d 100644 > > --- a/tools/libs/light/libxl_create.c > > ++

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/30/22 1:15 PM, Anthony PERARD wrote: Hi Chuck, On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote: When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD opregion to the guest but libxl does not grant the guest permission to I'm not reading the same thing whe

Re: [XEN PATCH v10 1/7] build: grab common EFI source files in arch specific dir

Hi Anthony, On 22/03/2022 11:22, Anthony PERARD wrote: Rather than preparing the efi source file, we will make the symbolic link as needed from the build location. The `ln` command is run every time to allow to update the link in case the source tree change location. This patch also introduce

Re: [XEN PATCH v10 2/7] build: replace $(BASEDIR) by $(objtree)

Hi Anthony, On 22/03/2022 11:22, Anthony PERARD wrote: We need to differentiate between source files and generated/built files. We will be replacing $(BASEDIR) by $(objtree) for files that are generated. Signed-off-by: Anthony PERARD Acked-by: Jan Beulich Acked-by: Julien Grall Cheers, -

[xen-4.15-testing test] 169040: regressions - FAIL

flight 169040 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169040/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-livepatch13 livepatch-runfail REGR. vs. 168502 test-amd64-amd

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/31/22 10:19 AM, Jason Andryuk wrote: On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski wrote: That still doesn't answer my question - will the Qemu upstream accept the patches that move the hypercalls to the toolstack? If not, we have to live with what we have now, which is that the hyper

Re: OS Headers hypercall.h/hypervisor.h

On 31/03/2022 09:44, Julien Grall wrote: On 31/03/2022 02:15, Elliott Mitchell wrote: On Tue, Mar 29, 2022 at 08:27:24AM +0200, Jan Beulich wrote: On 29.03.2022 00:25, Stefano Stabellini wrote: On Sat, 26 Mar 2022, Elliott Mitchell wrote: The hypercalls implementation for Linux and FreeBSD

Re: [PATCH 2/2] arch: ensure idle domain is not left privileged

On Thu, 31 Mar 2022, Julien Grall wrote: > On 31/03/2022 13:46, Roger Pau Monné wrote: > > On Wed, Mar 30, 2022 at 07:05:49PM -0400, Daniel P. Smith wrote: > > > It is now possible to promote the idle domain to privileged during setup. > > > It > > > is not desirable for the idle domain to still be

[libvirt test] 169058: regressions - FAIL

flight 169058 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169058/ 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

[xen-4.16-testing test] 169048: regressions - FAIL

flight 169048 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169048/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch 13 livepatch-runfail REGR. vs. 168513 test-amd64-i38

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/30/22 1:15 PM, Anthony PERARD wrote: Hi Chuck, On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote: When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD opregion to the guest but libxl does not grant the guest permission to I'm not reading the same thing whe

[xen-unstable-smoke test] 169078: regressions - FAIL

flight 169078 xen-unstable-smoke real [real] flight 169085 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169078/ http://logs.test-lab.xenproject.org/osstest/logs/169085/ Regressions :-( Tests which did not succeed and are blocking, including tests which co

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 3/31/22 2:32 PM, Chuck Zmudzinski wrote: On 3/30/22 1:15 PM, Anthony PERARD wrote: Hi Chuck, On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote: When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD opregion to the guest but libxl does not grant the guest perm

Re: [PATCH v3 1/5] xen: introduce xen,enhanced dom0less property

On Fri, 25 Mar 2022, Julien Grall wrote: > On 23/03/2022 00:08, Stefano Stabellini wrote: > > On Sat, 29 Jan 2022, Julien Grall wrote: > > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > > > > index 6931c022a2..9144d6c0b6 100644 > > > > --- a/xen/arch/arm/domain_build.c

Re: [PATCH v3 3/5] xen/arm: configure dom0less domain for enabling xenstore after boot

On Fri, 25 Mar 2022, Julien Grall wrote: > On 23/03/2022 01:18, Stefano Stabellini wrote: > > On Sat, 29 Jan 2022, Julien Grall wrote: > > > On 28/01/2022 21:33, Stefano Stabellini wrote: > > > > +rc = evtchn_alloc_unbound(&alloc, true); > > > > +if ( rc ) > > > > +{ > > > > +pr

Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers

On Mon, 28 Mar 2022, Julien Grall wrote: > On 23/03/2022 02:50, Stefano Stabellini wrote: > > On Sat, 29 Jan 2022, Julien Grall wrote: > > > On 28/01/2022 21:33, Stefano Stabellini wrote: > > > > +libxl_uuid uuid; > > > > +uint64_t v; > > > > +int rc; > > > > + > > > > +printf("Init

[PATCH v4 1/9] xen/dt: dt_property_read_string should return -ENODATA on !length

From: Stefano Stabellini When the length is zero (pp->length == 0), dt_property_read_string should return -ENODATA, but actually currently returns -EILSEQ because there is no specific check for lenght == 0. Add a check now. Signed-off-by: Stefano Stabellini --- xen/common/device_tree.c | 2 +-

[PATCH v4 2/9] xen/arm: implement domU extended regions

From: Stefano Stabellini Implement extended regions for dom0less domUs. The implementation is based on the libxl implementation. Signed-off-by: Stefano Stabellini --- xen/arch/arm/domain_build.c | 42 ++--- 1 file changed, 39 insertions(+), 3 deletions(-) diff

[PATCH v4 5/9] xen: introduce xen,enhanced dom0less property

From: Stefano Stabellini Introduce a new "xen,enhanced" dom0less property to enable/disable PV driver interfaces for dom0less guests. Currently only "enabled" and "disabled" are supported property values (and empty). Leave the option open to implement further possible values in the future (e.g. "

[PATCH v4 7/9] xenstored: send an evtchn notification on introduce_domain

From: Luca Miccio When xs_introduce_domain is called, send out a notification on the xenstore event channel so that any (dom0less) domain waiting for the xenstore interface to be ready can continue with the initialization. The extra notification is harmless for domains that don't require it. Si

[PATCH v4 8/9] tools: add example application to initialize dom0less PV drivers

From: Luca Miccio Add an example application that can be run in dom0 to complete the dom0less domains initialization so that they can get access to xenstore and use PV drivers. Signed-off-by: Luca Miccio Signed-off-by: Stefano Stabellini CC: Wei Liu CC: Anthony PERARD CC: Juergen Gross ---

[PATCH v4 0/9] dom0less PV drivers

Hi all, Currently dom0less guests cannot use PV drivers because they don't have access to xenstore. Also, the hypervisor node in device tree is missing so they don't detect that they are running on Xen (thus, they don't try to enable PV interfaces.) This patch series enables dom0less guests (on A

[PATCH v4 3/9] xen/arm: temporarily elevate idle_domain privileged during create_domUs

From: Stefano Stabellini create_domUs might call functions that perform XSM checks on the current domain, which is idle_domain at this time. Temporarily elevate idle_domain privileges in create_domUs. Signed-off-by: Stefano Stabellini --- xen/arch/arm/domain_build.c | 5 + 1 file changed,

[PATCH v4 4/9] xen: export evtchn_alloc_unbound

From: Stefano Stabellini It will be used during dom0less domains construction. Signed-off-by: Stefano Stabellini --- xen/common/event_channel.c | 2 +- xen/include/xen/event.h| 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/common/event_channel.c b/xen/common/even

[PATCH v4 6/9] xen/arm: configure dom0less domain for enabling xenstore after boot

From: Luca Miccio If "xen,enhanced" is enabled, then add to dom0less domains: - the hypervisor node in device tree - the xenstore event channel The xenstore event channel is also used for the first notification to let the guest know that xenstore has become available. Signed-off-by: Luca Micci

[PATCH v4 9/9] docs: document dom0less + PV drivers

From: Stefano Stabellini Document how to use the feature and how the implementation works. Signed-off-by: Stefano Stabellini --- docs/features/dom0less.pandoc | 43 --- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/docs/features/dom0less.pandoc

[PATCH] of: of_property_read_string return -ENODATA when !length

From: Stefano Stabellini When the length of the string is zero of_property_read_string should return -ENODATA according to the description of the function. However, of_property_read_string doesn't check pp->length. If pp->length is zero, return -ENODATA. Without this patch the following command

[linux-linus test] 169055: tolerable FAIL - PUSHED

flight 169055 linux-linus real [real] flight 169095 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169055/ http://logs.test-lab.xenproject.org/osstest/logs/169095/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-

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

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

[ovmf test] 169069: regressions - FAIL

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

[xen-4.16-testing bisection] complete test-amd64-amd64-livepatch

branch xen-4.16-testing xenbranch xen-4.16-testing job test-amd64-amd64-livepatch testid livepatch-run Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.x