Re: RMRRs and Phantom Functions

On 26.04.2022 19:51, Andrew Cooper wrote: > Hello, > > Edvin has found a machine with some very weird properties.  It is an HP > ProLiant BL460c Gen8 with: > >  \-[:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2 > +-01.0-[11]-- > +-01.1-[02]-- > +-02

Re: [PATCH] xen/arm: alternative: Don't call vmap() within stop_machine_run()

On 26.04.2022 22:06, Julien Grall wrote: > From: Julien Grall > > Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap > alloc/free" extended the checks in the buddy allocator to catch > any use of the helpers from context with interrupts disabled. > > Unfortunately, the rule is not

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid

Hi Jan, On 2022/4/27 13:56, Jan Beulich wrote: On 27.04.2022 05:52, Wei Chen wrote: From: Jan Beulich Sent: 2022年4月26日 22:42 On 26.04.2022 12:59, Wei Chen wrote: On 2022/4/26 17:02, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: 2. error: wrong type argument to unary exclamation m

Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common

Hi Jan, On 2022/4/27 13:54, Jan Beulich wrote: On 27.04.2022 04:56, Wei Chen wrote: -Original Message- From: Jan Beulich Sent: 2022年4月26日 22:31 On 26.04.2022 12:37, Wei Chen wrote: On 2022/4/26 16:53, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: diff --git a/xen/arch/x86

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid

On 27.04.2022 05:52, Wei Chen wrote: >> From: Jan Beulich >> Sent: 2022年4月26日 22:42 >> >> On 26.04.2022 12:59, Wei Chen wrote: >>> On 2022/4/26 17:02, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: > 2. error: wrong type argument to unary exclamation mark. > This is becau

[ovmf test] 169769: regressions - FAIL

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

Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common

On 27.04.2022 04:56, Wei Chen wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 2022年4月26日 22:31 >> >> On 26.04.2022 12:37, Wei Chen wrote: >>> On 2022/4/26 16:53, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: > diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x8

[ovmf test] 169766: regressions - FAIL

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

RE: [PATCH v4 21/21] VT-d: fold dma_pte_clear_one() into its only caller

> From: Jan Beulich > Sent: Monday, April 25, 2022 4:45 PM > > This way intel_iommu_unmap_page() ends up quite a bit more similar to > intel_iommu_map_page(). > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian > --- > v4: New. > > --- a/xen/drivers/pa

RE: [PATCH v4 20/21] VT-d: fold iommu_flush_iotlb{,_pages}()

> From: Jan Beulich > Sent: Monday, April 25, 2022 4:45 PM > > With iommu_flush_iotlb_all() gone, iommu_flush_iotlb_pages() is merely a > wrapper around the not otherwise called iommu_flush_iotlb(). Fold both > functions. > > No functional change intended. > > Signed-off-by: Jan Beulich Revie

RE: [PATCH v4 16/21] VT-d: free all-empty page tables

> From: Jan Beulich > Sent: Monday, April 25, 2022 4:43 PM > > 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. > > Note that while its output isn't used there

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

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

RE: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid

Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年4月26日 22:42 > To: Wei Chen > Cc: nd ; Andrew Cooper ; Roger Pau > Monné ; Wei Liu ; George Dunlap > ; Julien Grall ; Stefano > Stabellini ; xen-devel@lists.xenproject.org > Subject: Re: [PATCH v2 05/10] xen/x86: Use ASSERT ins

RE: [PATCH v5] x86/vmx: add hvm functions to get/set non-register state

> From: Lengyel, Tamas > Sent: Friday, March 25, 2022 9:33 PM > > During VM forking and resetting a failed vmentry has been observed due > to the guest non-register state going out-of-sync with the guest register > state. For example, a VM fork reset right after a STI instruction can trigger > th

RE: RMRRs and Phantom Functions

> From: Andrew Cooper > Sent: Wednesday, April 27, 2022 1:52 AM > > Hello, > > Edvin has found a machine with some very weird properties.  It is an HP > ProLiant BL460c Gen8 with: > >  \-[:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2 > +-01.0-[11]-- > +-01.1-

[ovmf test] 169764: regressions - FAIL

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

RE: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common

Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年4月26日 22:31 > To: Wei Chen > Cc: nd ; Andrew Cooper ; Roger Pau > Monné ; Wei Liu ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions > from x86 to common > > On 26.04

[ovmf test] 169763: regressions - FAIL

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

[ovmf test] 169761: regressions - FAIL

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

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

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

Re: [PATCH v3] xen/build: Add cppcheck and cppcheck-html make rules

On Tue, 26 Apr 2022, Bertrand Marquis wrote: > cppcheck can be used to check Xen code quality. > > To create a report do "make cppcheck" on a built tree adding any options > you added during the process you used to build xen (like CROSS_COMPILE > or XEN_TARGET_ARCH). This will generate an xml repo

[ovmf test] 169759: regressions - FAIL

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

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On Tue, 26 Apr 2022, Andrew Cooper wrote: > > Can my (personal) GitLab be added as a Developer to the Xen Project > > group? I think this is the intended way for people to run the CI > > pipelines on their own branches. > > It is.  Username? David, let us know if you have any issues with gitlab.

Re: [PATCH] xen/arm: alternative: Don't call vmap() within stop_machine_run()

On Tue, 26 Apr 2022, Julien Grall wrote: > From: Julien Grall > > Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap > alloc/free" extended the checks in the buddy allocator to catch > any use of the helpers from context with interrupts disabled. > > Unfortunately, the rule is not

[ovmf test] 169758: regressions - FAIL

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

Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm

On Sat, 23 Apr 2022, Christoph Hellwig wrote: > swiotlb-xen uses very different ways to allocate coherent memory on x86 > vs arm. On the former it allocates memory from the page allocator, while > on the later it reuses the dma-direct allocator the handles the > complexities of non-coherent DMA on

[ovmf test] 169757: regressions - FAIL

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

[ovmf test] 169754: regressions - FAIL

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

[PATCH] MAINTAINERS: add Rahul as SMMU maintainer

Add Rahul as ARM SMMU maintainer. Create a new explicit entry for "ARM SMMU" also with Julien which is the original contributor of the code and continues to maintain it. Signed-off-by: Stefano Stabellini diff --git a/MAINTAINERS b/MAINTAINERS index 2a47fafe85..ba0d1c0c1b 100644 --- a/MAINTAINER

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 26/04/2022 15:14, Julien Grall wrote: On 26/04/2022 15:01, Jan Beulich wrote: On 25.04.2022 15:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@   static char __initdata opt_badpage[100] = "";   string_param("badpage", opt_badpage); +/*

[PATCH] xen/arm: alternative: Don't call vmap() within stop_machine_run()

From: Julien Grall Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap alloc/free" extended the checks in the buddy allocator to catch any use of the helpers from context with interrupts disabled. Unfortunately, the rule is not followed in the alternative code and this will result t

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

flight 169748 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169748/ 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 v2] xen/arm: p2m_set_entry reuse mask variables

Thansk! > It is common to add a changelog after "---". This helps the reviewer to > know what changed in your patch. I think this experience will be very helpful for the next more meaningful patch. > > "1UL << order" refers to the number of pages and not a mask. So I don't > think re-using the l

Re: [PATCH v2] xen/arm: p2m_set_entry reuse mask variables

Hi, On 26/04/2022 16:49, Paran Lee wrote: Reuse mask variables on order shift duplicated calculation. Signed-off-by: Paran Lee --- xen/arch/arm/p2m.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) It is common to add a changelog after "---". This helps the reviewer to know

Re: [PATCH] xen/arm: p2m_set_entry duplicate calculation.

Hi, On 26/04/2022 16:37, Paran Lee wrote: Thanks you, I agreed! It made me think once more about what my patch could improve. patches I sent have been reviewed in various ways. It was a good opportunity to analyze my patch from various perspectives. :) I checked objdump in -O2 optimization(defa

Re: [PATCH v5] x86/vmx: add hvm functions to get/set non-register state

On Wed, Apr 20, 2022 at 2:50 AM Jan Beulich wrote: > > On 20.04.2022 08:39, Tian, Kevin wrote: > >> From: Tamas K Lengyel > >> Sent: Tuesday, April 19, 2022 2:43 AM > >> > >> On Fri, Mar 25, 2022 at 9:34 AM Tamas K Lengyel > >> wrote: > >>> > >>> During VM forking and resetting a failed vmentry

Re: [PATCH v4 2/2] x86/monitor: Add new monitor event to catch all vmexits

On Tue, Apr 26, 2022 at 4:50 AM Roger Pau Monné wrote: > > On Mon, Apr 25, 2022 at 11:40:11AM -0400, Tamas K Lengyel wrote: > > On Mon, Apr 25, 2022 at 10:41 AM Roger Pau Monné > > wrote: > > > > > > On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote: > > > > Add monitor event that

[ovmf test] 169750: regressions - FAIL

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

RMRRs and Phantom Functions

Hello, Edvin has found a machine with some very weird properties.  It is an HP ProLiant BL460c Gen8 with:  \-[:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2 +-01.0-[11]-- +-01.1-[02]-- +-02.0-[04]--+-00.0  Emulex Corporation OneConnect 10Gb NIC (be3

[ovmf test] 169746: regressions - FAIL

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

[cxenstored] Potential bug in special watch event firing

While reading C xenstored code, I noticed that it may send special events like @releaseDomain to (privileged) clients that only watch the root node (/). That's probably not the intended behaviour. For example, when firing @releaseDomain, fire_watches() is called with exact == false: https://gi

Re: DomU Windows Server Essentials crashes with xen 4.16 but works with xen 4.14

On Tue, Apr 26, 2022 at 10:10:37AM +0200, Steffen Einsle wrote: > Hello, > > I can confirm that "msr_relaxed = 1" solves the problem with Server 2019 > Essentials crashing. Can you post which CPU model are you using? A dump of the first CPU entry in /proc/cpuinfo will do. Thanks, Roger.

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

flight 169737 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169737/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169630 test-armhf-a

[ovmf test] 169744: regressions - FAIL

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

[RFC PATCH] xen/arm: p2m don't fall over on FEAT_LPA enabled hw

When we introduced FEAT_LPA to QEMU's -cpu max we discovered older kernels had a bug where the physical address was copied directly from ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits the same error by blindly copying across the max supported range. Unsurprisingly when the

[PATCH v2] xen/arm: p2m_set_entry reuse mask variables

Reuse mask variables on order shift duplicated calculation. Signed-off-by: Paran Lee --- xen/arch/arm/p2m.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 1d1059f7d2..cdb3b56aa1 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/ar

Re: [PATCH] xen/arm: p2m_set_entry duplicate calculation.

Hello, Julien Grall. Thanks you, I agreed! It made me think once more about what my patch could improve. patches I sent have been reviewed in various ways. It was a good opportunity to analyze my patch from various perspectives. :) I checked objdump in -O2 optimization(default) of Xen Makefile to

Re: [PATCH] xen/public: add new macro to ring.h

On 26.04.22 11:43, Jan Beulich wrote: On 26.04.2022 11:08, Juergen Gross wrote: --- a/xen/include/public/io/ring.h +++ b/xen/include/public/io/ring.h @@ -184,6 +184,11 @@ typedef struct __name##_back_ring __name##_back_ring_t #define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s,

[ovmf test] 169742: regressions - FAIL

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

Re: [PATCH RFC] EFI: strip xen.efi when putting it on the EFI partition

Hi Jan, > On 26 Apr 2022, at 15:09, Jan Beulich wrote: > > On 26.04.2022 14:26, Bertrand Marquis wrote: >> Hi Jan, >> >>> On 25 Apr 2022, at 11:46, Jan Beulich wrote: >>> >>> With debug info retained, xen.efi can be quite large. Unlike for xen.gz >>> there's no intermediate step (mkelf32 ther

[ovmf test] 169740: regressions - FAIL

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

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid

On 26.04.2022 12:59, Wei Chen wrote: > On 2022/4/26 17:02, Jan Beulich wrote: >> On 18.04.2022 11:07, Wei Chen wrote: >>> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This >>> results in two lines of error-checking code in phys_to_nid >>> that is not actually working and causing two compil

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 26/04/2022 15:33, David Vrabel wrote: > > > On 26/04/2022 15:14, Julien Grall wrote: >> Hi, >> >> On 26/04/2022 15:01, Jan Beulich wrote: >>> On 25.04.2022 15:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@   static cha

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 26/04/2022 15:14, Julien Grall wrote: Hi, On 26/04/2022 15:01, Jan Beulich wrote: On 25.04.2022 15:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@   static char __initdata opt_badpage[100] = "";   string_param("badpage", opt_badpag

Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common

On 26.04.2022 12:37, Wei Chen wrote: > On 2022/4/26 16:53, Jan Beulich wrote: >> On 18.04.2022 11:07, Wei Chen wrote: >>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >>> similarity index 71% >>> rename from xen/arch/x86/efi/stub.c >>> rename to xen/arch/x86/efi/stub-x86.c >>>

Potential race between shutting down a domain and handling I/O

Hi all, While looking at the I/O handling code, I noticed that hvmemul_do_io() contains the following code: 333 rc = ioreq_send(s, &p, 0); 334 if ( rc != X86EMUL_RETRY || currd->is_shutting_down ) 335 vio->req.state = STATE_IOREQ_NONE; Looking at his

Re: [PATCH 09/11] nvme: remove a spurious clear of discard_alignment

Reviewed-by: Sagi Grimberg

Re: [PATCH v3 5/8] libxenguest: deal with log-dirty op stats overflow

On 26.04.2022 12:54, Andrew Cooper wrote: > On 26/04/2022 11:24, Jan Beulich wrote: >> In send_memory_live() the precise value the dirty_count struct field >> gets initialized to doesn't matter much > > Yes it does. > > And as you keep on refusing to actually fix the bugs pointed out during > rev

Re: [PATCH v2] libxl: Retry QMP PCI device_add

On Fri, Apr 22, 2022 at 10:07:03AM -0400, Jason Andryuk wrote: > PCI device assignment to an HVM with stubdom is potentially racy. First > the PCI device is assigned to the stubdom via the PV PCI protocol. Then > QEMU is sent a QMP command to attach the PCI device to QEMU running > within the stu

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

Hi, On 26/04/2022 15:01, Jan Beulich wrote: On 25.04.2022 15:28, David Vrabel wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -162,6 +162,13 @@ static char __initdata opt_badpage[100] = ""; string_param("badpage", opt_badpage); +/* + * Heap allocations may need TLB

Re: [PATCH RFC] EFI: strip xen.efi when putting it on the EFI partition

On 26.04.2022 14:26, Bertrand Marquis wrote: > Hi Jan, > >> On 25 Apr 2022, at 11:46, Jan Beulich wrote: >> >> With debug info retained, xen.efi can be quite large. Unlike for xen.gz >> there's no intermediate step (mkelf32 there) involved which would strip >> debug info kind of as a side effect.

Re: [PATCH v4] page_alloc: assert IRQs are enabled in heap alloc/free

On 25.04.2022 15:28, David Vrabel wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -162,6 +162,13 @@ > static char __initdata opt_badpage[100] = ""; > string_param("badpage", opt_badpage); > > +/* > + * Heap allocations may need TLB flushes which require IRQs to be >

[ovmf test] 169738: regressions - FAIL

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

[ovmf test] 169735: regressions - FAIL

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

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

flight 169729 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169729/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169630 test-armhf-a

Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm

Hi Christoph, > On 23 Apr 2022, at 6:14 pm, Christoph Hellwig wrote: > > swiotlb-xen uses very different ways to allocate coherent memory on x86 > vs arm. On the former it allocates memory from the page allocator, while > on the later it reuses the dma-direct allocator the handles the > complex

[PATCH v3] xen/build: Add cppcheck and cppcheck-html make rules

cppcheck can be used to check Xen code quality. To create a report do "make cppcheck" on a built tree adding any options you added during the process you used to build xen (like CROSS_COMPILE or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml. To create a html report do "make

[ovmf test] 169734: regressions - FAIL

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

Re: [PATCH RFC] EFI: strip xen.efi when putting it on the EFI partition

Hi Jan, > On 25 Apr 2022, at 11:46, Jan Beulich wrote: > > With debug info retained, xen.efi can be quite large. Unlike for xen.gz > there's no intermediate step (mkelf32 there) involved which would strip > debug info kind of as a side effect. While the installing of xen.efi on > the EFI partiti

Re: [PATCH] EFI: don't mistakenly delete a file we never installed

Hi Jan, > On 25 Apr 2022, at 11:47, Jan Beulich wrote: > > Just like for "install", make dealing with xen.efi on the EFI partition > dependent upon mount point and vendor directory being known. > > Signed-off-by: Jan Beulich Reviewed-by: Bertrand Marquis Cheers Bertrand > > --- a/xen/Makef

[libvirt test] 169727: regressions - FAIL

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

[ovmf test] 169733: regressions - FAIL

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

Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen

On Tue, Apr 26, 2022 at 11:36:40AM +0200, Juergen Gross wrote: > As the suggestion was to add another flag this wouldn't be a problem IMO. We had a problem already with adding one flag would break the same flag on the other guest type. That's why we added cc_vendor too. So it can be tricky. > pla

Re: [PATCH v2 10/10] xen/x86: add detection of memory interleaves for different nodes

Hi Jan, On 2022/4/26 17:20, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: --- a/xen/arch/x86/srat.c +++ b/xen/arch/x86/srat.c @@ -271,6 +271,35 @@ acpi_numa_processor_affinity_init(const struct acpi_srat_cpu_affinity *pa) pxm, pa->apic_id, node); } +/* +

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid

Hi Jan, On 2022/4/26 17:02, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This results in two lines of error-checking code in phys_to_nid that is not actually working and causing two compilation errors: 1. error: "MAX_NUMNODES" und

[ovmf test] 169732: regressions - FAIL

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

Re: [PATCH v3 5/8] libxenguest: deal with log-dirty op stats overflow

On 26/04/2022 11:24, Jan Beulich wrote: > In send_memory_live() the precise value the dirty_count struct field > gets initialized to doesn't matter much Yes it does. And as you keep on refusing to actually fix the bugs pointed out during review, this entire series is NACKED, seeing as you've also

Re: [PATCH] xsm/flask: code style formatting

On 4/26/22 04:38, Jan Beulich wrote: On 23.04.2022 01:07, Andrew Cooper wrote: On 22/04/2022 20:43, Daniel P. Smith wrote: diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 0bf63ffa84..e2ebbc7716 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -120,8 +121,8 @

Re: [PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

On Tue, Apr 26, 2022, 4:33 AM Julien Grall wrote: > Hi, > > On 26/04/2022 09:17, Roger Pau Monné wrote: > > On Mon, Apr 25, 2022 at 11:24:37AM -0400, Tamas K Lengyel wrote: > >> On Mon, Apr 25, 2022 at 10:12 AM Roger Pau Monné > wrote: > diff --git a/xen/common/vm_event.c b/xen/common/vm_ev

Re: [PATCH v4 1/2] xsm: create idle domain privileged and demote after setup

On 4/26/22 02:35, Jan Beulich wrote: On 25.04.2022 19:22, Daniel P. Smith wrote: --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -621,6 +621,9 @@ static void noreturn init_done(void) void *va; unsigned long start, end; +if ( xsm_set_system_active() != 0 ) +pa

Re: [PATCH v1.1] evtchn: add early-out to evtchn_move_pirqs()

Hi Jan, On 26/04/2022 11:33, Jan Beulich wrote: See the code comment. The higher the rate of vCPU-s migrating across pCPU-s, the less useful this attempted optimization actually is. With credit2 the migration rate looks to be unduly high even on mostly idle systems, and hence on large systems lo

Re: [PATCH v2 09/10] xen/x86: use paddr_t for addresses in NUMA node structure

Hi Jan, On 2022/4/26 17:11, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: v1 ->v2: 1. Drop useless cast. 2. Use initializers of the variables. Would have been nice if this was extended to ... diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c index 680b7d9002..2b3a51afd0 10064

Re: [PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common

Hi Jan, On 2022/4/26 16:53, Jan Beulich wrote: On 18.04.2022 11:07, Wei Chen wrote: diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c similarity index 71% rename from xen/arch/x86/efi/stub.c rename to xen/arch/x86/efi/stub-x86.c index 9984932626..2cd5c8d4dc 100644 --- a/xen/arc

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

flight 169725 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/169725/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169717 Tests which did not succee

[PATCH v1.1] evtchn: add early-out to evtchn_move_pirqs()

See the code comment. The higher the rate of vCPU-s migrating across pCPU-s, the less useful this attempted optimization actually is. With credit2 the migration rate looks to be unduly high even on mostly idle systems, and hence on large systems lock contention here isn't very difficult to observe

[PATCH v3 6/8] x86/paging: supply more useful log-dirty page count

In paging_log_dirty_op(), always update the count of pages field: - if more pages were specified than the guest has ever accessed (HVM) or marked part of the p2m (PV), there's no point for the caller to inspect bits beyond the one for that last page, - if the guest's p2m size has grown in the m

[PATCH v3 8/8] SUPPORT.md: write down restriction of 32-bit tool stacks

Let's try to avoid giving the impression that 32-bit tool stacks are as capable as 64-bit ones. Signed-off-by: Jan Beulich --- v2: Wording adjustments as per review discussion. --- a/SUPPORT.md +++ b/SUPPORT.md @@ -137,6 +137,12 @@ ARM only has one guest type at the momen ## Toolstack +Whil

[PATCH v3 7/8] x86/mm: update log-dirty bitmap when manipulating P2M

Just like for PV guests MMU_MACHPHYS_UPDATE implies marking of the respective page as dirty, additions to a HVM guest's P2M should do so. For HVM the opposite is also true: Pages being removed from the P2M are no longer dirty at their prior GFN; there's no point in telling the tool stack to try an

[PATCH v3 5/8] libxenguest: deal with log-dirty op stats overflow

In send_memory_live() the precise value the dirty_count struct field gets initialized to doesn't matter much (apart from the triggering of the log message in send_dirty_pages(), see below), but it is important that it not be zero on the first iteration (or else send_dirty_pages() won't get called a

[PATCH v3 4/8] libxenguest: restrict PV guest size

The P2M, the use of PFNs, and hence the maximum valid PFN are purely software constructs in PV. In principle a guest is free to use arbitrary PFNs. However, at least page table normalization requires that PFN space be, like MFN space, limited to the architectural 40 bits (52 address bits). And of c

[PATCH v3 3/8] libxenguest: guard against overflow from too large p2m when checkpointing

struct xc_sr_record's length field has just 32 bits. Fill it early and check that the calculated value hasn't overflowed. Additionally check for counter overflow early - there's no point even trying to allocate any memory in such an event. While there also limit an induction variable's type to uns

[PATCH v3 2/8] libxenguest: avoid allocating unused deferred-pages bitmap

Like for the dirty bitmap, it is unnecessary to allocate the deferred- pages bitmap when all that's ever going to happen is a single all-dirty run. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -130,7 +130,7 @@ s

[PATCH v3 1/8] libxenguest: short-circuit "all-dirty" handling

For one it is unnecessary to fill a perhaps large chunk of memory with all ones. Add a new parameter to send_dirty_pages() for callers to indicate so. Then it is further unnecessary to allocate the dirty bitmap altogether when all that's ever going to happen is a single all-dirty run. Signed-off-

Re: [PATCH] xen/build: Fix build failure from LDFLAGS mismatch

Hi Andrew, > On 26 Apr 2022, at 00:06, Andrew Cooper wrote: > > In a GNU compatbile makefile, $(LDFLAGS) are passed to $(CC), not $(LD). You mean because CC is used for linking or even when compiling object files ? If not, what is the expected way to pass linker flags ? > > In a default Cent

[PATCH v3 0/8] x86: more or less log-dirty related improvements

... or so I hope. This series continues the attempt to deal with the ovmf change putting the shared info page at a very high address (which is now planned to get reverted there, but the general problem doesn't go away by them doing so). There are further issues with truncated value, which are being

[ovmf test] 169731: regressions - FAIL

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

[PATCH 4/4] mwait-idle: add core C6 optimization for SPR

From: Artem Bityutskiy Add a Sapphire Rapids Xeon C6 optimization, similar to what we have for Sky Lake Xeon: if package C6 is disabled, adjust C6 exit latency and target residency to match core C6 values, instead of using the default package C6 values. Signed-off-by: Artem Bityutskiy Signed-of

[PATCH 3/4] mwait-idle: add 'preferred_cstates' module argument

From: Artem Bityutskiy On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually exclusive - only one of them can be enabled. By default, 'intel_idle' driver enables C1 and disables C1E. However, some users prefer to use C1E instead of C1, because it saves more energy. This patc

[PATCH 2/4] mwait-idle: add SPR support

From: Artem Bityutskiy Add Sapphire Rapids Xeon support. Up until very recently, the C1 and C1E C-states were independent, but this has changed in some new chips, including Sapphire Rapids Xeon (SPR). In these chips the C1 and C1E states cannot be enabled at the same time. The "C1E promotion" bi

[PATCH 1/4] x86/mwait-idle: switch to asm/intel-family.h naming

This brings us (back) closer to the original Linux source. While touching mwait_idle_state_table_update() also drop a stray leading blank. Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -61,6 +61,7 @@ #include #include #include +#incl

  1   2   >