[qemu-mainline test] 163066: regressions - FAIL

flight 163066 qemu-mainline real [real] flight 163108 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/163066/ http://logs.test-lab.xenproject.org/osstest/logs/163108/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

[ovmf test] 163096: regressions - FAIL

flight 163096 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163096/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359

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

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

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

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

[ovmf test] 163055: regressions - FAIL

flight 163055 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163055/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359

Re: [PATCH] xen/arm: smmuv1: Set privileged attr to 'default'

On Fri, 25 Jun 2021, Rahul Singh wrote: > Backport commit e19898077cfb642fe151ba22981e795c74d9e114 > "iommu/arm-smmu: Set privileged attribute to 'default' instead of > 'unprivileged'" > > Original commit message: > Currently the driver sets all the device transactions privileges > to

[linux-linus test] 163027: regressions - FAIL

flight 163027 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/163027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332

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

On 25/06/2021 14:24, Jan Beulich wrote: > 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 > > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -131,6 +131,11 @@ ARM only has one guest type at the momen > > ## Toolstack >

Re: [PATCH 11/12] x86/mm: pull a sanity check earlier in xenmem_add_to_physmap_one()

On 25/06/2021 14:22, Jan Beulich wrote: > We should try to limit the failure reasons after we've started making > changes. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [PATCH 08/12] x86/paging: deal with log-dirty stats overflow

On 25/06/2021 14:21, Jan Beulich wrote: > While the precise values are unlikely of interest once they exceed 4 > billion (allowing us to leave alone the domctl struct), we still > shouldn't wrap or truncate the actual values. It is in particular > problematic if the truncated values were zero

Re: [PATCH 07/12] libxenguest: fix off-by-1 in colo-secondary-bitmap merging

On 25/06/2021 14:20, Jan Beulich wrote: > Valid GFNs (having a representation in the dirty bitmap) need to be > strictly below p2m_size. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [PATCH 06/12] libxenguest: guard against overflow from too large p2m when checkpointing

On 25/06/2021 14:20, Jan Beulich wrote: > struct xc_sr_record's length field has just 32 bits. The stream max record length is /* Somewhat arbitrary - 128MB */ #define REC_LENGTH_MAX    (128U << 20) and is checked in the low level helpers, making the upper bound on the number of

Re: [PATCH 05/12] libxenguest: complete loops in xc_map_domain_meminfo()

On 25/06/2021 14:19, Jan Beulich wrote: > minfo->p2m_size may have more than 31 significant bits. Change the > induction variable to unsigned long, and (largely for signed-ness > consistency) a helper variable to unsigned int. > > Signed-off-by: Jan Beulich > > --- a/tools/libs/guest/xg_domain.c

Re: [PATCH 04/12] libxenguest: avoid allocating unused deferred-pages bitmap

On 25/06/2021 14:19, Jan Beulich wrote: > 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 > --- > The clearing of the bitmap at the end of

Re: [GIT PULL] xen: branch for v5.13-rc8

The pull request you sent on Fri, 25 Jun 2021 16:48:32 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.13b-rc8-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b960e0147451915b5d4cd208b7abd3b07ceaf1a2 Thank you! -- Deet-doot-dot,

Re: [PATCH] xen/arm: add forward_smc command line option for debugging

On Fri, 25 Jun 2021, Julien Grall wrote: > Hi, > > On 25/06/2021 02:51, Stefano Stabellini wrote: > > It has become clear that an option to disable trapping SMC calls to Xen > > is very useful for debugging user issues. > > > > Instead of having to provide a > > patch to users every time, it

Re: [PATCH 03/12] libxenguest: short-circuit "all-dirty" handling

On 25/06/2021 14:18, Jan Beulich wrote: > 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

[PATCH] xen/arm: smmuv1: Set privileged attr to 'default'

Backport commit e19898077cfb642fe151ba22981e795c74d9e114 "iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'" Original commit message: Currently the driver sets all the device transactions privileges to UNPRIVILEGED, but there are cases where the iommu masters

[PATCH] xen/arm: smmuv1: Fixed stream matching register allocation

SMR allocation should be based on the number of supported stream matching register for each SMMU device. Issue introduced by commit 5e08586afbb90b2e2d56c175c07db77a4afa873c when backported the patches from Linux to XEN to fix the stream match conflict issue when two devices have the same

Re: [PATCH 02/12] libxenguest: deal with log-dirty op stats overflow

On 25/06/2021 14:18, Jan Beulich wrote: > 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

Re: [PATCH 01/12] libxc: split xc_logdirty_control() from xc_shadow_control()

On 25/06/2021 14:17, Jan Beulich wrote: > For log-dirty operations a 64-bit field is being truncated to become an > "int" return value. Seeing the large number of arguments the present > function takes, reduce its set of parameters to that needed for all > operations not involving the log-dirty

[qemu-mainline test] 163024: regressions - FAIL

flight 163024 qemu-mainline real [real] flight 163056 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/163024/ http://logs.test-lab.xenproject.org/osstest/logs/163056/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

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

flight 163048 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/163048/ 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: [PATCH 01/12] libxc: split xc_logdirty_control() from xc_shadow_control()

For the OCaml part: Acked-by: Christian Lindig mailto:christian.lin...@citrix.com>> On 25 Jun 2021, at 14:17, Jan Beulich mailto:jbeul...@suse.com>> wrote: For log-dirty operations a 64-bit field is being truncated to become an "int" return value. Seeing the large number of arguments the

[GIT PULL] xen: branch for v5.13-rc8

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.13b-rc8-tag xen: branch for v5.13-rc8 It contains a fix for a regression introduced in 5.12: when migrating an irq related to a Xen user event to another cpu, a race might result

Re: [xen-unstable test] 163021: regressions - FAIL

On 25/06/2021 10:43, osstest service owner wrote: > flight 163021 xen-unstable real [real] > flight 163030 xen-unstable real-retest [real] > http://logs.test-lab.xenproject.org/osstest/logs/163021/ > http://logs.test-lab.xenproject.org/osstest/logs/163030/ > > Regressions :-( > > Tests which did

Re: [PATCH v2 2/2] AMD/IOMMU: re-work locking around sending of commands

On 25/06/2021 13:15, Jan Beulich wrote: It appears unhelpful to me for flush_command_buffer() to block all progress elsewhere for the given IOMMU by holding its lock while waiting for command completion. There's no real need for callers of that function or of send_iommu_command() to hold the

[ovmf test] 163028: regressions - FAIL

flight 163028 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163028/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359

Re: [PATCH] Replace FSF street address with canonical URL (again)

Hi Andrew, On 25/06/2021 15:41, Andrew Cooper wrote: As recommended in http://www.gnu.org/licenses/gpl-howto.en.html. Exactly as per changeset 443701ef0c7ff3 - Some errors have crept back in in the past 6 years. Signed-off-by: Andrew Cooper Acked-by: Julien Grall Cheers, --- CC: George

[PATCH] Replace FSF street address with canonical URL (again)

As recommended in http://www.gnu.org/licenses/gpl-howto.en.html. Exactly as per changeset 443701ef0c7ff3 - Some errors have crept back in in the past 6 years. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Julien

[PATCH 12/12] 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 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -131,6 +131,11 @@ ARM only has one guest type at the momen ## Toolstack +While 32-bit builds of the tool stack are generally

[PATCH 11/12] x86/mm: pull a sanity check earlier in xenmem_add_to_physmap_one()

We should try to limit the failure reasons after we've started making changes. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -2763,6 +2763,15 @@ int xenmem_add_to_physmap_one( goto put_both; } +/* XENMAPSPACE_gmfn: Check if the MFN is

[PATCH 10/12] 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 als 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

[PATCH 09/12] 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

[PATCH 08/12] x86/paging: deal with log-dirty stats overflow

While the precise values are unlikely of interest once they exceed 4 billion (allowing us to leave alone the domctl struct), we still shouldn't wrap or truncate the actual values. It is in particular problematic if the truncated values were zero (causing libxenguest to skip an iteration

[PATCH 07/12] libxenguest: fix off-by-1 in colo-secondary-bitmap merging

Valid GFNs (having a representation in the dirty bitmap) need to be strictly below p2m_size. Signed-off-by: Jan Beulich --- a/tools/libs/guest/xg_sr_save.c +++ b/tools/libs/guest/xg_sr_save.c @@ -614,7 +614,7 @@ static int colo_merge_secondary_dirty_bi for ( i = 0; i < count; i++ ) {

[PATCH 06/12] 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

[PATCH 05/12] libxenguest: complete loops in xc_map_domain_meminfo()

minfo->p2m_size may have more than 31 significant bits. Change the induction variable to unsigned long, and (largely for signed-ness consistency) a helper variable to unsigned int. Signed-off-by: Jan Beulich --- a/tools/libs/guest/xg_domain.c +++ b/tools/libs/guest/xg_domain.c @@ -40,7 +40,7 @@

[PATCH 04/12] 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 --- The clearing of the bitmap at the end of suspend_and_send_dirty() also looks unnecessary - am I overlooking anything?

[PATCH 03/12] 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.

[PATCH 02/12] 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

[PATCH 01/12] libxc: split xc_logdirty_control() from xc_shadow_control()

For log-dirty operations a 64-bit field is being truncated to become an "int" return value. Seeing the large number of arguments the present function takes, reduce its set of parameters to that needed for all operations not involving the log-dirty bitmap, while introducing a new wrapper for the

[PATCH 00/12] 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

Re: [PATCH v15 00/12] Restricted DMA

On Thu, Jun 24, 2021 at 03:19:48PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system

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

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

[PATCH v2 2/2] AMD/IOMMU: re-work locking around sending of commands

It appears unhelpful to me for flush_command_buffer() to block all progress elsewhere for the given IOMMU by holding its lock while waiting for command completion. There's no real need for callers of that function or of send_iommu_command() to hold the lock. Contain all command sending related

[PATCH v2 2/2] AMD/IOMMU: redo awaiting of command completion

The present abuse of the completion interrupt does not only stand in the way of, down the road, using it for its actual purpose, but also requires holding the IOMMU lock while waiting for command completion, limiting parallelism and keeping interrupts off for non-negligible periods of time. Have

[PATCH v2 0/2] IOMMU: XSA-373 follow-on

A number of further adjustments were left out of the XSA, for not being a security concern (anymore in some of the cases, with the changes put in place there). Only AMD side pieces are left in v2. 1: AMD/IOMMU: redo awaiting of command completion 2: AMD/IOMMU: re-work locking around sending of

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 25.06.2021 13:36, Andrew Cooper wrote: > On 25/06/2021 11:59, Ian Jackson wrote: >> Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new >> functionality"): >>> On 25.06.2021 11:17, Andrew Cooper wrote: On 25/06/2021 07:31, Jan Beulich wrote: > On 24.06.2021 19:55,

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 25.06.2021 12:59, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new > functionality"): >> On 25.06.2021 11:17, Andrew Cooper wrote: >>> On 25/06/2021 07:31, Jan Beulich wrote: On 24.06.2021 19:55, Andrew Cooper wrote: > Fixes: bef64f2c00

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 25/06/2021 11:59, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new > functionality"): >> On 25.06.2021 11:17, Andrew Cooper wrote: >>> On 25/06/2021 07:31, Jan Beulich wrote: On 24.06.2021 19:55, Andrew Cooper wrote: > Fixes: bef64f2c00

Re: [PATCH] libxencall: Bump SONAME following new functionality

Jan Beulich writes ("Re: [PATCH] libxencall: Bump SONAME following new functionality"): > On 25.06.2021 11:17, Andrew Cooper wrote: > > On 25/06/2021 07:31, Jan Beulich wrote: > >> On 24.06.2021 19:55, Andrew Cooper wrote: > >>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2()

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 25.06.2021 11:17, Andrew Cooper wrote: > On 25/06/2021 07:31, Jan Beulich wrote: >> On 24.06.2021 19:55, Andrew Cooper wrote: >>> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning >>> long") >> Is this strictly necessary, i.e. is a Fixes: tag here warranted? > > Yes -

[xen-unstable test] 163021: regressions - FAIL

flight 163021 xen-unstable real [real] flight 163030 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/163021/ http://logs.test-lab.xenproject.org/osstest/logs/163030/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH] tools/xenstored: Correctly read the requests header from the stream

Hi, On 25/06/2021 08:58, Juergen Gross wrote: On 25.06.21 08:45, Julien Grall wrote: From: Julien Grall Commit c0fe360f42 ("tools/xenstored: Extend restore code to handle multiple input buffer") extend the read_buffered_state() to support multiple input buffers. Unfortunately, the commit

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 25/06/2021 07:31, Jan Beulich wrote: > On 24.06.2021 19:55, Andrew Cooper wrote: >> Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning >> long") > Is this strictly necessary, i.e. is a Fixes: tag here warranted? Yes - very much so.

[libvirt test] 163026: regressions - FAIL

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

[ovmf test] 163022: regressions - FAIL

flight 163022 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/163022/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359

Re: [PATCH] tools/xenstored: Correctly read the requests header from the stream

On 25.06.21 08:45, Julien Grall wrote: From: Julien Grall Commit c0fe360f42 ("tools/xenstored: Extend restore code to handle multiple input buffer") extend the read_buffered_state() to support multiple input buffers. Unfortunately, the commit didn't go far enough and still used sc->data (start

[PATCH] tools/xenstored: Correctly read the requests header from the stream

From: Julien Grall Commit c0fe360f42 ("tools/xenstored: Extend restore code to handle multiple input buffer") extend the read_buffered_state() to support multiple input buffers. Unfortunately, the commit didn't go far enough and still used sc->data (start of the buffers) for retrieving the

Re: [PATCH] xen/arm: add forward_smc command line option for debugging

Hi, On 25/06/2021 02:51, Stefano Stabellini wrote: It has become clear that an option to disable trapping SMC calls to Xen is very useful for debugging user issues. > Instead of having to provide a patch to users every time, it would be great if we could just tell them to add forward_smc=true

Re: [PATCH 3/6] xsm: enabling xsm to always be included

On 24.06.2021 19:18, Daniel P. Smith wrote: > > > On 6/21/21 2:53 AM, Jan Beulich wrote: >> On 18.06.2021 18:35, Daniel P. Smith wrote: >>> On 6/18/21 7:53 AM, Andrew Cooper wrote: On 18/06/2021 00:39, Daniel P. Smith wrote: > @@ -250,9 +261,8 @@ config XSM_FLASK_POLICY >

Re: [PATCH] libxencall: Bump SONAME following new functionality

On 24.06.2021 19:55, Andrew Cooper wrote: > Fixes: bef64f2c00 ("libxencall: introduce variant of xencall2() returning > long") Is this strictly necessary, i.e. is a Fixes: tag here warranted? I wonder in particular with the possibility of backporting in mind, where I think we shouldn't easily