Re: request for feedback on a Xen/Linux compatibility issue

On 06.01.22 01:40, Stefano Stabellini wrote: Hi all, Today Xen dom0less guests are not "Xen aware": the hypervisor node (compatible = "xen,xen") is missing from dom0less domUs device trees and as a consequence Linux initializes as if Xen is not present. The reason is that interfaces like grant

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

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

request for feedback on a Xen/Linux compatibility issue

Hi all, Today Xen dom0less guests are not "Xen aware": the hypervisor node (compatible = "xen,xen") is missing from dom0less domUs device trees and as a consequence Linux initializes as if Xen is not present. The reason is that interfaces like grant table and xenstore (xenbus in Linux) don't work

sched=null vwfi=native and call_rcu()

Hi all, As you might remember, we have an outstanding issue with call_rcu() when sched=null vwfi=native are used. That is because in that configuration the CPU never goes idle so rcu_idle_enter() never gets called. The issue was caught on the field and I managed to repro the problem doing the

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

From: Oleksandr Tyshchenko Rework Arm implementation to store grant table frame GFN in struct page_info directly instead of keeping it in standalone status/shared arrays. This patch is based on the assumption that grant table page is the xenheap page. To cover 64-bit/40-bit IPA on Arm64/Arm32

Re: qemu-xen is unavailable

Hello, On Wed, Jan 05, 2022 at 04:27:56PM +, Anthony PERARD wrote: > The bug here is that libxl shouldn't print this message for PVH guest > because it's confusing. It also does it for PV guests, again if no qemu is installed (or needed). I squash it by adding:

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

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

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

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

Re: qemu-xen is unavailable

On Wed, 5 Jan 2022, Anthony PERARD wrote: > Looking at the original email, the domain config file has type="pvh", so > I don't think qemu is actually needed. And the domain is starting fine, > so this message isn't really needed and would be a bug I guess. Thanks for responding. Indeed, the

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

flight 167610 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/167610/ 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: [XEN v2] xen/arm64: io: Decode 32-bit ldr/str post-indexing instructions

Hi, Thank you so much for your feedback. I need a couple of clarifications before I can start with the v3 patch. On 08/12/2021 12:00, Andre Przywara wrote: On Mon, 6 Dec 2021 19:31:06 + Julien Grall wrote: Hi, On 01/12/2021 08:41, Bertrand Marquis wrote: Hi Ayan, On 30 Nov 2021,

Re: [PATCH] xen/x86: obtain upper 32 bits of video frame buffer address for Dom0

On 1/5/22 2:59 AM, Jan Beulich wrote: Anyway - I'd appreciate if the patch at hand could be taken independent of possible further adjustments here, as it addresses an issue observed in the field. Reviewed-by: Boris Ostrovsky

Re: qemu-xen is unavailable

CC xen-devel On Tue, Jan 04, 2022 at 11:52:21AM +, George Dunlap wrote: > > On Sun, 19 Dec 2021, Christian Kujau wrote: > > > # xl create -f /etc/xen/debian.cfg > > > Parsing config from /etc/xen/debian.cfg > > > libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: > >

Re: [PATCH RFC v2 3/3] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order

On Wed, Jan 5, 2022 at 3:59 AM Jan Beulich wrote: > > On 04.01.2022 18:48, Tamas K Lengyel wrote: > >> I may be entirely wrong and hence that part of the change may also be > >> wrong, but I'm having trouble seeing why the original > >> "!mfn_eq(m, INVALID_MFN)" wasn't "mfn_eq(m, INVALID_MFN)".

Re: [PATCH] x86/spec-ctrl: Fix default calculation of opt_srb_lock

On 04.01.2022 15:44, Andrew Cooper wrote: > Since this logic was introduced, opt_tsx has become more complicated and > shouldn't be compared to 0 directly. While there are no buggy logic paths, > the correct expression is !(opt_tsx & 1) but the rtm_disabled boolean is > easier and clearer to use.

Re: [PATCH 5/5] tools/xl: Fix potential deallocation bug

On Thu, Dec 10, 2020 at 03:09:06PM -0800, Elliott Mitchell wrote: > There is potential for the info and info_free variable's purposes to > diverge. If info was overwritten with a distinct value, yet info_free > still needed deallocation a bug would occur on this line. Preemptively > address this

Re: [PATCH] tools/xen-detect: avoid possible pitfall with cpuid()

On Fri, Dec 03, 2021 at 01:09:04PM +0100, Jan Beulich wrote: > The 64-bit form forces %ecx to 0 while the 32-bit one so far didn't - it > only ended up that way when "pv_context" is zero. While presently no > leaf queried by callers has separate subleaves, let's avoid chancing it. > > While there

scheduler credit capture

Hi Everyone, Today I'm looking for capturing vCPU credit for both credit1 and credit2. How can I do that? -- *Regards* *Noohi* *noohi.org *

Re: Possible bug? DOM-U network stopped working after fatal error reported in DOM0

On Wed, Jan 05, 2022 at 12:05:39AM +0800, G.R. wrote: > > > > > But seems like this patch is not stable enough yet and has its own > > > > > issue -- memory is not properly released? > > > > > > > > I know. I've been working on improving it this morning and I'm > > > > attaching an updated version

[PATCH v2 3/3] x86/perfc: fold HVM's VM-exit counter arrays

Only one of them can be in use at a time, so make the whole set union- like. While doing the rename in SVM code, combine the two perf_incra(), generalizing the range upwards of VMEXIT_NPF. Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c

[PATCH v2 2/3] SVM: sync VM-exit perf counters with known VM-exit reasons

This has gone out of sync over time, resulting in NPF and XSETBV exits incrementing the same counter. Introduce a simplistic mechanism to hopefully keep things in better sync going forward. Signed-off-by: Jan Beulich --- v2: Use sentinel comments only. ---

[PATCH v2 1/3] VMX: sync VM-exit perf counters with known VM-exit reasons

This has gone out of sync over time. Introduce a simplistic mechanism to hopefully keep things in sync going forward. Also limit the array index to just the "basic exit reason" part, which is what the pseudo-enumeration covers. Signed-off-by: Jan Beulich --- v2: Use sentinel comment only. ---

[PATCH v2 0/3] x86/perfc: assorted adjustments

Addressing some observations made while reviewing other patches. 1: VMX: sync VM-exit perf counters with known VM-exit reasons 2: SVM: sync VM-exit perf counters with known VM-exit reasons 3: x86/perfc: fold HVM's VM-exit counter arrays Jan

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

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

Re: [PATCH 1/5] tools/libxl: Mark pointer args of many functions constant

> On 5 Jan 2022, at 10:09, Anthony PERARD wrote: > > On Fri, Dec 18, 2020 at 01:37:44PM -0800, Elliott Mitchell wrote: >> Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be >> examining the pointed to thing, not modifying it. This potentially >> results in

[xen-unstable test] 167605: tolerable FAIL

flight 167605 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/167605/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167603 test-armhf-armhf-libvirt 16

[libvirt test] 167607: regressions - FAIL

flight 167607 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/167607/ 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 1/5] tools/libxl: Mark pointer args of many functions constant

On Fri, Dec 18, 2020 at 01:37:44PM -0800, Elliott Mitchell wrote: > Anything *_is_empty(), *_is_default(), or *_gen_json() is going to be > examining the pointed to thing, not modifying it. This potentially > results in higher-performance output. This also allows spreading > constants further,

[xen-unstable-coverity test] 167608: all pass - PUSHED

flight 167608 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/167608/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen af0c5430a82c77432729d61c9b409dd32c477b20 baseline version: xen

Re: [PATCH] tools/libxc: Drop copy-in in xc_physinfo()

On Thu, Dec 23, 2021 at 04:22:44PM +, Andrew Cooper wrote: > The first thing XEN_SYSCTL_physinfo does is zero op->u.physinfo. > > Do not copy-in. It's pointless, and most callers don't initialise their > xc_physinfo_t buffer to begin with. Remove the pointless zeroing from the > remaining

Re: [PATCH RFC v2 3/3] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order

On 04.01.2022 18:48, Tamas K Lengyel wrote: >> I may be entirely wrong and hence that part of the change may also be >> wrong, but I'm having trouble seeing why the original >> "!mfn_eq(m, INVALID_MFN)" wasn't "mfn_eq(m, INVALID_MFN)". Isn't the >> goal there to pre-fill entries that were