flight 171647 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171647/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 07c8e5e59b117f2414d7c928d3f86c85574f1fc3
baseline version:
ovmf
flight 171639 qemu-mainline real [real]
flight 171646 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171639/
http://logs.test-lab.xenproject.org/osstest/logs/171646/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 171637 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171637/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 171628 pass in
171637
Introduction of 'feature_persistent' made two bugs. First one is wrong
overwrite of 'vbd->feature_gnt_persistent' in 'blkback' due to wrong
parameter value caching position, and the second one is unintended
behavioral change that could break previous dynamic frontend/backend
persistent feature
In some use cases[1], the backend is created while the frontend doesn't
support the persistent grants feature, but later the frontend can be
changed to support the feature and reconnect. In the past, 'blkback'
enabled the persistent grants feature since it unconditionally checked
if frontend
Persistent grants feature can be used only when both backend and the
frontend supports the feature. The feature was always supported by
'blkback', but commit aac8a70db24b ("xen-blkback: add a parameter for
disabling of persistent grants") has introduced a parameter for
disabling it runtime.
To
From: Maximilian Heyne
In some use cases[1], the backend is created while the frontend doesn't
support the persistent grants feature, but later the frontend can be
changed to support the feature and reconnect. In the past, 'blkback'
enabled the persistent grants feature since it unconditionally
Hi all,
On Fri, 15 Jul 2022 18:12:26 + SeongJae Park wrote:
> Hi all,
>
> On Fri, 15 Jul 2022 17:55:19 + SeongJae Park wrote:
>
> > The first patch of this patchset fixes 'feature_persistent' parameter
> > handling in 'blkback' to respect the frontend's persistent grants
> > support
flight 171645 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171645/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0d23c447d6f574cbe511414b70df14119099c70f
baseline version:
ovmf
On 7/15/2022 6:05 AM, Jan Beulich wrote:
> On 15.07.2022 04:07, Chuck Zmudzinski wrote:
> > On 7/14/2022 1:30 AM, Thorsten Leemhuis wrote:
> >> On 13.07.22 03:36, Chuck Zmudzinski wrote:
> >>> The commit 99c13b8c8896d7bcb92753bf
> >>> ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
Hi Daniel,
On 06/07/2022 22:04, Daniel P. Smith wrote:
The x86 and Arm architectures represent in memory the general boot information
and boot modules differently despite having commonality. The x86
representations are bound to the multiboot v1 structures while the Arm
representations are a
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-disk backend (emulator) which is intended to run out of
Qemu and could be run in any domain.
Although the Virtio block device is quite different from traditional
Xen PV block device
From: Julien Grall
This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory region) and create specific device node in
the Guest device-tree with allocated params. In order to deal
with multiple Virtio devices, reserve corresponding ranges.
For now, we reserve 1MB for memory
From: Oleksandr Tyshchenko
Reuse generic IOMMU device tree bindings to communicate Xen specific
information for the virtio devices for which the restricted memory
access using Xen grant mappings need to be enabled.
Insert "iommus" property pointed to the IOMMU node with "xen,grant-dma"
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add missing virtio-mmio bits to Xen
toolstack on Arm.
The Virtio support for toolstack [1] was postponed as the main target was to
upstream IOREQ/DM
support on Arm in the first place. Now, we already have IOREQ
Hi Daniel,
On 06/07/2022 22:04, Daniel P. Smith wrote:
For x86 the number of allowable multiboot modules varies between the different
entry points, non-efi boot, pvh boot, and efi boot. In the case of both Arm and
x86 this value is fixed to values based on generalized assumptions. With
Hi Penny,
On 07/07/2022 10:22, Penny Zheng wrote:
Later, we want to use acquire_domstatic_pages() for populating memory
for static domain on runtime, however, there are a lot of pointless work
(checking mfn_valid(), scrubbing the free part, cleaning the cache...)
considering we know the page is
On 15/07/2022 19:51, Julien Grall wrote:
Hi Penny,
On 07/07/2022 10:22, Penny Zheng wrote:
In order to have an easy and quick way to find out whether this domain
memory
is statically configured, this commit introduces a new flag
CDF_staticmem and a
new helper is_domain_using_staticmem()
Hi Penny,
On 07/07/2022 10:22, Penny Zheng wrote:
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
---
v8
Hi Penny,
On 07/07/2022 10:22, Penny Zheng wrote:
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
Hi Penny,
On 04/07/2022 08:20, Penny Zheng wrote:
+
+return acquire_static_memory_bank(d, NULL, addr_cells, size_cells,
+ pbase, psize);
+
+}
+
+/*
+ * Func allocate_shared_memory is supposed to be only called
I am a bit concerned with the word
Hi all,
On Fri, 15 Jul 2022 17:55:19 + SeongJae Park wrote:
> The first patch of this patchset fixes 'feature_persistent' parameter
> handling in 'blkback' to respect the frontend's persistent grants
> support always. The fix makes a behavioral change, so the second patch
> makes the
On 15.07.22 20:49, Julien Grall wrote:
Hi Oleksandr,
Hello Julien
On 24/06/2022 12:47, Oleksandr wrote:
On 23.06.22 20:50, Julien Grall wrote:
On 11/05/2022 19:47, Oleksandr Tyshchenko wrote:
diff --git a/xen/arch/arm/include/asm/mm.h
b/xen/arch/arm/include/asm/mm.h
+/*
+ * All
Hi Penny,
On 29/06/2022 09:39, Penny Zheng wrote:
+for ( i = 0; i < mem->nr_banks; i++ )
+{
+/*
+ * A static shared memory region could be shared between multiple
+ * domains.
+ */
+if ( paddr == mem->bank[i].start && size == mem->bank[i].size )
+
From: Maximilian Heyne
Given dom0 supports persistent grants but the guest does not.
Then, when attaching a block device during runtime of the guest, dom0
will enable persistent grants for this newly attached block device:
$ xenstore-ls -f | grep 20674 | grep persistent
The first patch of this patchset fixes 'feature_persistent' parameter
handling in 'blkback' to respect the frontend's persistent grants
support always. The fix makes a behavioral change, so the second patch
makes the counterpart of 'blkfront' to consistently follow the behavior
change.
Changes
Previous commit made xen-blkback's 'feature_persistent' parameter to
make effect for not only newly created backends but also for every
reconnected backends. This commit makes xen-blkfront's counterpart
parameter to works in same manner and update the document to avoid any
confusion due to
Hi Oleksandr,
On 24/06/2022 12:47, Oleksandr wrote:
On 23.06.22 20:50, Julien Grall wrote:
On 11/05/2022 19:47, Oleksandr Tyshchenko wrote:
diff --git a/xen/arch/arm/include/asm/mm.h
b/xen/arch/arm/include/asm/mm.h
+/*
+ * All accesses to the GFN portion of type_info field should always be
The pull request you sent on Fri, 15 Jul 2022 08:00:19 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.19a-rc7-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/339f74e38f53c83b5715abd28f7002b66731d917
Thank you!
--
Deet-doot-dot,
On 15.07.22 20:15, Julien Grall wrote:
On 24/06/2022 16:31, Oleksandr wrote:
On 23.06.22 21:08, Julien Grall wrote:
Hi Oleksandr,
Hello Julien
Hi Oleksandr,
Hello Julien
On 11/05/2022 19:47, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Borrow the x86's check
Hi Jan,
On 09/06/2022 14:22, Jan Beulich wrote:
/*
* This function should only be called with valid pages from the same NUMA
- * node.
+ * node and the same zone.
*
* Callers should use is_contig_page() first to check if all the pages
* in a range are contiguous.
@@ -1817,8
On 24/06/2022 16:31, Oleksandr wrote:
On 23.06.22 21:08, Julien Grall wrote:
Hi Oleksandr,
Hello Julien
Hi Oleksandr,
On 11/05/2022 19:47, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Borrow the x86's check from p2m_remove_page() which was added
by the following
flight 171635 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 171587
Tests which did
From: Julien Grall
Hi all,
As part of the Live-Update work, we noticed that a big part Xen boot
is spent to add pages in the heap. For instance, on when running Xen
in a nested envionment on a c5.metal with 90GB, it takes ~1.4s.
This small series is reworking init_heap_pages() to give the
From: Julien Grall
At the moment, init_heap_pages() will call free_heap_pages() page
by page. To reduce the time to initialize the heap, we will want
to provide multiple pages at the same time.
init_heap_pages() is now split in two parts:
- init_heap_pages(): will break down the range in
From: Julien Grall
init_heap_pages() is using an open-code version of IS_ALIGNED(). Replace
it to improve the readability of the code.
No functional change intended.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/common/page_alloc.c | 2 +-
1 file changed, 1
From: Hongyan Xia
The idea is to split the range into multiple aligned power-of-2 regions
which only needs to call free_heap_pages() once each. We check the least
significant set bit of the start address and use its bit index as the
order of this increment. This makes sure that each increment is
On Fri, Jul 15, 2022 at 4:25 PM Juergen Gross wrote:
>
> There are several MTRR functions which also do PAT handling. In order
> to support PAT handling without MTRR in the future, add some wrappers
> for those functions.
>
> Cc: # 5.17
> Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT
On 15.07.22 18:24, Anthony PERARD wrote:
Hello Anthony
> On Wed, Jul 13, 2022 at 08:03:17AM +, Oleksandr Tyshchenko wrote:
>> On 13.07.22 03:01, George Dunlap wrote:
>>
>> Hello George, Anthony
>>
>>>
On 30 Jun 2022, at 22:18, Oleksandr wrote:
Dear all.
Hi All,
I was wondering if someone could help me understand some of the rules of the
memory sharing implementation in Xen?
Specifically I'm looking to understand what restrictions Xen places on
granting access from one Dom to another from Xen's perspective, and what types
of grant requests
Hello,
Oleksandr, thank you for Cc-ing Andrii. Andrii, thank you for the comment!
On Fri, 15 Jul 2022 15:00:10 +0300 Andrii Chepurnyi
wrote:
> [-- Attachment #1: Type: text/plain, Size: 5237 bytes --]
>
> Hello All,
>
> I faced the mentioned issue recently and just to bring more context
flight 171640 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171640/
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
On Wed, Jul 13, 2022 at 08:03:17AM +, Oleksandr Tyshchenko wrote:
>
> On 13.07.22 03:01, George Dunlap wrote:
>
> Hello George, Anthony
>
> >
> >
> >> On 30 Jun 2022, at 22:18, Oleksandr wrote:
> >>
> >>
> >> Dear all.
> >>
> >>
> >> On 25.06.22 17:32, Oleksandr wrote:
> >>>
> >>> On
Hi Julien,
On Fri, Jul 08, 2022 at 02:40:56PM +0100, Julien Grall wrote:
> Hi Jens,
>
> I haven't checked whether the FFA driver is complaint with the spec. I
> mainly checked whether the code makes sense from Xen PoV.
>
> This is a fairly long patch to review. So I will split my review in
Prepare making PAT and MTRR support independent from each other by
moving some code needed by both out of the MTRR specific sources.
Cc: # 5.17
Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/mtrr.h| 4
There are several MTRR functions which also do PAT handling. In order
to support PAT handling without MTRR in the future, add some wrappers
for those functions.
Cc: # 5.17
Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
Signed-off-by: Juergen Gross
---
Today PAT can't be used without MTRR being available, unless MTRR is at
least configured via CONFIG_MTRR and the system is running as Xen PV
guest. In this case PAT is automatically available via the hypervisor,
but the PAT MSR can't be modified by the kernel and MTRR is disabled.
As an
Today PAT is usable only with MTRR being active, with some nasty tweaks
to make PAT usable when running as Xen PV guest, which doesn't support
MTRR.
The reason for this coupling is, that both, PAT MSR changes and MTRR
changes, require a similar sequence and so full PAT support was added
using the
flight 171636 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171636/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 171627
Tests which did not
While Xen's current VMA means it works, the mawk fix (i.e. using $((0xN)) in
the shell) isn't portable in 32bit shells. See the code comment for the fix.
The fix found a second latent bug. Recombining $vma_hi/lo should have used
printf "%s%08x" and only worked previously because $vma_lo had
From: Anthony PERARD
check-endbr.sh works with gawk, but fails with mawk. The produced $ALL
file is smaller as it is missing 0x$vma_lo on every line. With mawk,
int(0x2A) just produces 0, instead of the expected value.
The use of hexadecimal-constant in awk is an optional part of the posix
I committed the two trivial patches, which leaves the main MAWK fix from
Anthony, and the fix for the portability issue spotted by Jan.
Andrew Cooper (1):
xen: Fix latent check-endbr.sh bug with 32bit build environments
Anthony PERARD (1):
xen: Fix check-endbr.sh with mawk
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
diff --git a/arch/x86/xen/suspend_hvm.c
flight 171634 linux-5.4 real [real]
flight 171641 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171634/
http://logs.test-lab.xenproject.org/osstest/logs/171641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
Hello All,
I faced the mentioned issue recently and just to bring more context here is
our setup:
We use pvblock backend for Android guest. It starts using u-boot with
pvblock support(which frontend doesn't support the persistent grants
feature), later it loads and starts the Linux kernel(which
flight 171638 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 15/07/2022 11:51, Jan Beulich wrote:
> On 15.07.2022 12:43, Andrew Cooper wrote:
>> On 15/07/2022 11:14, Jan Beulich wrote:
>>> On 14.07.2022 16:39, Anthony PERARD wrote:
--- a/xen/tools/check-endbr.sh
+++ b/xen/tools/check-endbr.sh
@@ -78,7 +78,7 @@ then
else
+ Oleksandr Tyshchenko
-- Artem
From: Alex Bennée
Sent: Wednesday, July 13, 2022 6:39:23 PM
To: Trilok Soni
Cc: Stratos Mailing List ; Viresh Kumar
; Mathieu Poirier ; Mike
Holmes ; Azzedine Touzni ;
Stefano Stabellini ; Christopher Clark
; Arnd Bergmann ;
On 15.07.2022 12:43, Andrew Cooper wrote:
> On 15/07/2022 11:14, Jan Beulich wrote:
>> On 14.07.2022 16:39, Anthony PERARD wrote:
>>> --- a/xen/tools/check-endbr.sh
>>> +++ b/xen/tools/check-endbr.sh
>>> @@ -78,7 +78,7 @@ then
>>> else
>>> grep -aob -e "$(printf '\363\17\36\372')" -e
When vgic performs irouter registers emulation, to get the target vCPU
via virq conveniently, Xen doesn't store the irouter value directly,
instead it will use the value (affinities) in irouter to calculate the
target vCPU, and then save the target vCPU in irq rank->vCPU[offset].
But there seems
On 15/07/2022 11:14, Jan Beulich wrote:
> On 14.07.2022 16:39, Anthony PERARD wrote:
>> --- a/xen/tools/check-endbr.sh
>> +++ b/xen/tools/check-endbr.sh
>> @@ -78,7 +78,7 @@ then
>> else
>> grep -aob -e "$(printf '\363\17\36\372')" -e "$(printf
>> '\363\17\36\373')" \
>> -e
On 14/07/2022 19:59, Andrew Cooper wrote:
> On 14/07/2022 16:12, Andrew Cooper wrote:
>> On 14/07/2022 15:39, Anthony PERARD wrote:
>>> check-endbr.sh works well with gawk, but fails with mawk. The produced
>>> $ALL file is smaller, it is missing 0x$vma_lo on every line. On mawk,
>>> int(0x2A)
On 15.07.22 01:44, SeongJae Park wrote:
Hello all.
Adding Andrii Chepurnyi to CC who have played with the use-case which
required reconnect recently and faced some issues with
feature_persistent handling.
Persistent grants feature can be used only when both backend and the
frontend
On 14.07.2022 16:39, Anthony PERARD wrote:
> --- a/xen/tools/check-endbr.sh
> +++ b/xen/tools/check-endbr.sh
> @@ -78,7 +78,7 @@ then
> else
> grep -aob -e "$(printf '\363\17\36\372')" -e "$(printf
> '\363\17\36\373')" \
> -e "$(printf '\146\17\37\1')" $TEXT_BIN
> -fi | awk -F':'
On 14.07.2022 20:53, Andrew Cooper wrote:
> In particular, we support FreeBSD and NetBSD build environments, and some
> Linux build environments use MAWK over GAWK anyway.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 15.07.2022 04:07, Chuck Zmudzinski wrote:
> On 7/14/2022 1:30 AM, Thorsten Leemhuis wrote:
>> On 13.07.22 03:36, Chuck Zmudzinski wrote:
>>> The commit 99c13b8c8896d7bcb92753bf
>>> ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
>>> incorrectly failed to account for the case in
On 15/07/2022 09:18, Jane Malalane wrote:
> On 14/07/2022 00:27, Boris Ostrovsky wrote:
>>> xen_hvm_smp_init();
>>> WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
>>> diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
>>> index
Hi Matthieu,
> On 15 Jul 2022, at 09:53, Mathieu Tarral
> wrote:
>
(We're trying some new project management tools.) Can you try opening a
bug here: https://gitlab.com/xen-project/xen/-/issues about the
check-endbr.sh issue?
>
> I'm getting a Gitlab 404 page when trying to
On 15.07.22 11:20, Dan Carpenter wrote:
Hello Dan
> The "m.num * sizeof(*m.arr)" multiplication can have an integer overflow
> on 32 bit systems. Probably no one really uses this software on 32 bit
> systems, but it's still worth fixing the bug if only to make the static
> checker happy.
>
>
> > > (We're trying some new project management tools.) Can you try opening a
> > > bug here: https://gitlab.com/xen-project/xen/-/issues about the
> > > check-endbr.sh issue?
I'm getting a Gitlab 404 page when trying to access this link.
Are there access restrictions in place ?
And same for:
The "m.num * sizeof(*m.arr)" multiplication can have an integer overflow
on 32 bit systems. Probably no one really uses this software on 32 bit
systems, but it's still worth fixing the bug if only to make the static
checker happy.
Fixes: ceb90fa0a800 ("xen/privcmd: add PRIVCMD_MMAPBATCH_V2
On 14/07/2022 00:27, Boris Ostrovsky wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open
> attachments unless you have verified the sender and know the content is
> safe.
>
> On 7/11/22 11:22 AM, Jane Malalane wrote:
>> --- a/arch/x86/xen/enlighten_hvm.c
>> +++
flight 171631 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171631/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171623
test-armhf-armhf-libvirt 16
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年7月14日 18:58
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 2/9] xen/x86: Use enumerations to indicate NUMA
> status
>
> On 14.07.2022 12:49,
Hi,
> -Original Message-
> From: Henry Wang
> Subject: Xen 4.17: Proposed release schedule
>
> Hi,
>
> As discussed in the community call on July 7, the release schedule for Xen
> 4.17 is proposed below. Please send comments ASAP and in any case by the
> end of Friday the 15th of July.
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.19a-rc7-tag
xen: branch for v5.19-rc7
It contains a single patch for fixing an issue in the Xen gntdev driver
causing inappropriate WARN() messages.
Thanks.
Juergen
76 matches
Mail list logo
