[libvirt test] 174168: tolerable all pass - PUSHED

[osstest service owner]

flight 174168 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174168/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 174112
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 174112
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 174112
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  f1d63048b76bae8d9dd5c2f693a6df64c8117538
baseline version:
 libvirt  a58da464154cb02b5630fb42e0b0924d22aeb750

Last test of basis   174112  2022-10-20 02:09:40 Z2 days
Testing same since   174168  2022-10-21 03:40:58 Z1 days1 attempts


People who touched revisions under test:
  Gogo Gogsi 
  Ján Tomko 
  Michal Privoznik 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-arm64-arm64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of 

Re: [PATCH v4] templates: introduce GRUB_TOP_LEVEL_* vars

[Denton Liu]

Hi Olaf,

On Thu, Oct 20, 2022 at 05:13:06PM +0200, Olaf Hering wrote:
> After reading the patch again, the newly added documentation states:
> "This option should be a path to a kernel image."
> 
> I think it needs to be more specific: is it expecting an absolute path, or 
> just the basename of the desired image?

Thanks for the feedback, it should be an absolute path. I can submit a
new version of the patch later. However, before I do so, are you still
a NAK on the general idea?

-Denton

[linux-linus test] 174174: regressions - FAIL

[osstest service owner]

flight 174174 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174174/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-seattle   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 173462
 test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-vhd   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 173462
 test-armhf-armhf-libvirt-qcow2  8 xen-boot   fail REGR. vs. 173462
 test-armhf-armhf-xl-multivcpu  8 xen-bootfail REGR. vs. 173462
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-libvirt  8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl-arndale   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl-credit2   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-libvirt-raw  8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-credit2   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl-vhd   8 xen-boot fail REGR. vs. 173462

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  8 xen-boot fail REGR. vs. 173462

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173462
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173462
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173462
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173462
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173462
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass

version targeted for testing:
 linuxe35184f321518acadb681928a016da21a9a20c13
baseline version:
 linux9d84bb40bcb30a7fa16f33baa967aeb9953dda78

Last test of basis   173462  2022-10-07 18:41:45 Z   14 days
Failing since173470  2022-10-08 06:21:34 Z   13 days   22 attempts
Testing same since   174174  2022-10-21 05:53:21 Z0 days1 attempts


1328 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-coresched-amd64-xlpass
 test-arm64-arm64-xl  fail
 test-armhf-armhf-xl  fail
 

RE: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM

[Henry Wang]

Hi Bertrand,

> -Original Message-
> From: Bertrand Marquis 
> Subject: Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM
> 
> Hi,
> 
> > On 21 Oct 2022, at 15:40, Henry Wang  wrote:
> >
> > (+ Arm maintainers)
> >
> > Hi Oleksandr,
> >
> >> -Original Message-
> >> From: Oleksandr 
> >> Subject: Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM
> >> Hello all.
> >> On 19.07.22 13:40, Jan Beulich wrote:
> >>> On 19.07.2022 12:32, Volodymyr Babchuk wrote:
>  Jan Beulich  writes:
> 
> > On 18.07.2022 23:15, Volodymyr Babchuk wrote:
> >> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
> >> iounmap(), but not added corresponding include.
> >>
> >> Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
> > I don't think there's any active issue with the "missing" include:
> > That's only a problem once Arm has vPCI code enabled? In which
> > case I don't think a Fixes: tag is warranted.
>  Fair enough. May I ask committer to drop this tag?
> >>> I had taken respective note already, in case I end up committing this.
> >>> But this is the last patch of the series, so I can only guess whether
> >>> it might be okay to go in ahead of the other three patches.
> >>>
> >>> Jan
> >>
> >>
> >> I am wondering, where this patch could be 4.17 material?
> >>
> >> The patch series seem to get stuck, but the current patch just adds a
> >> missing include to fix a build on Arm, so it is completely independent.
> >> I agree, there is no issue with the current code base as vPCI is
> >> disabled on Arm, so nothing to fix right now. But as PCI
> >> passthrough/vPCI on Arm is in the development stage, the developers
> >> enable that support in their builds. I think the risk is rather low than
> >> high.
> >
> > It seems reasonable to me, but I am curious about what Arm maintainers
> > and PCI maintainers think. From the history discussion in this thread I
> > think it is pretty safe to include this in 4.17. Thanks for the ping.
> 
> I think this can safely go in for 4.17.
> 
> Cheers
> Bertrand

Thanks for the feedback :) Feel free to add my:

Release-acked-by: Henry Wang 

Kind regards,
Henry


> 
> >
> > Kind regards,
> > Henry
> >
> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Oleksandr Tyshchenko
> 

[xen-4.15-testing test] 174183: regressions - trouble: fail/pass/starved

[osstest service owner]

flight 174183 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174183/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-libvirt-qcow2 12 debian-di-install fail in 173987 REGR. vs. 
172547
 test-armhf-armhf-libvirt-raw 12 debian-di-install fail in 173987 REGR. vs. 
172547
 test-armhf-armhf-xl-arndale  14 guest-startfail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl  14 guest-startfail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl-credit2  14 guest-startfail in 173987 REGR. vs. 172547
 test-armhf-armhf-libvirt 14 guest-startfail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl-credit1  14 guest-startfail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl-vhd   12 debian-di-install fail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl-multivcpu 14 guest-start   fail in 173987 REGR. vs. 172547
 test-armhf-armhf-xl-cubietruck 14 guest-start  fail in 173987 REGR. vs. 172547

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-i386  7 xen-installfail in 173987 pass in 174183
 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail in 174063 pass in 174183
 test-amd64-i386-xl-xsm7 xen-install  fail in 174063 pass in 174183
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail in 174063 pass in 174183
 test-arm64-arm64-xl-xsm  14 guest-startfail pass in 173987
 test-arm64-arm64-libvirt-xsm 14 guest-startfail pass in 173987
 test-arm64-arm64-libvirt-raw 12 debian-di-install  fail pass in 173987
 test-arm64-arm64-xl-credit2  14 guest-startfail pass in 174063
 test-arm64-arm64-xl-credit1  14 guest-startfail pass in 174063

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 14 guest-startfail in 173987 REGR. vs. 172547

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-vhd  12 debian-di-install   fail blocked in 172547
 test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 173987 never 
pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 173987 never 
pass
 test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 174063 never 
pass
 test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 174063 never 
pass
 test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 174063 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172547
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172547
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172547
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 build-armhf-libvirt   1 build-check(1)

Re: [RFC PATCH v1 04/12] Arm: GICv3: Emulate GICR_TYPER on AArch32

[Xenia Ragiadakou]

On 10/21/22 18:31, Ayan Kumar Halder wrote:
Hi Ayan


Refer Arm IHI 0069H ID020922,
The upper 32 bits of GICR_TYPER represent the affinity
whereas the lower 32 bits represent the other bits (eg processor
number, etc).
MPIDR_AFFINITY_LEVEL() returns a 32 bit number on aarch32. Thus, this
is appended to return GICR_TYPER register.

Signed-off-by: Ayan Kumar Halder 
---
  xen/arch/arm/vgic-v3.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c31140eb20..d86b41a39f 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -190,14 +190,18 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
  
  case VREG64(GICR_TYPER):

  {
-uint64_t typer, aff;
+uint64_t typer;
+uint32_t aff;
  
  if ( !vgic_reg64_check_access(dabt) ) goto bad_width;

-aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
+aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 24 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 16 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 8 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0));
  typer = aff;
+
+typer = typer << 32;
+
  /* We use the VCPU ID as the redistributor ID in bits[23:8] */
  typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
  


I don't see an issue I just want to propose alternatives that I think 
would reduce the changes, hopefully without breaking it.
So, other ways would be either to assign v->arch.vmpidr to a new 
variable uint64_t vmpidr and operate on this (without changing the 
shifts), or to leave the type of aff uint64_t, adjust the shifts and do 
typer = aff << 32.


--
Xenia

Re: [for-4.17] automation: Do not use null scheduler for boot cpupools test

[Julien Grall]

Hi Stefano,

On 21/10/2022 20:36, Stefano Stabellini wrote:

For the NULL scheduler, it is clearly important to many users so it
would be valuable to move it to "supported, non security supported" and
enabling it by default in the build. I don't recall if we still have any
known outstanding issues with it. I think we need a separate email
thread for that discussion and I would understand if the decision is not
to change NULL support status for the 4.17 release (maybe for the 4.18
release?).


At the moment, I am tracking two major issues for NULL scheduler:
 - ed25be5e-d695-4763-b97a-78d6040e2...@amazon.com
 - alpine.DEB.2.22.394.2201051615060.2060010@ubuntu-linux-20-04-desktop 
(reported by you)


Have they been fixed? If not, then I don't think can be moved to 
"supported, not security supported" because it would fall over basic setup.


Cheers,

--
Julien Grall

Re: Intended behavior/usage of SSBD setting

[Andrew Cooper]

On 20/10/2022 12:01, Roger Pau Monné wrote:
> Hello,
>
> As part of some follow up improvements to my VIRT_SPEC_CTRL series we
> have been discussing what the usage of SSBD should be for the
> hypervisor itself.  There's currently a `spec-ctrl=ssbd` option [0],
> that has an out of date description, as now SSBD is always offered to
> guests on AMD hardware, either using SPEC_CTRL or VIRT_SPEC_CTRL.
>
> It has been pointed out by Andrew that toggling SSBD on AMD using
> VIRT_SPEC_CTRL or the non-architectural way (MSR_AMD64_LS_CFG) can
> have a high impact on performance, and hence switching it on every
> guest <-> hypervisor context switch is likely a very high
> performance penalty.
>
> It's been suggested that it could be more appropriate to run Xen with
> the guest SSBD selection on those systems, however that clashes with
> the current intent of the `spec-ctrl=ssbd` option.
>
> I hope I have captured the expressed opinions correctly in the text
> above.
>
> I see two ways to solve this:
>
>  * Keep the current logic for switching SSBD on guest <-> hypervisor
>context switch, but only use it if `spec-ctrl=ssbd` is set on the
>command line.
>
>  * Remove the logic for switching SSBD on guest <-> hypervisor context
>switch, ignore setting of `spec-ctrl=ssbd` on those systems and run
>hypervisor code with the guest selection of SSBD.
>
> Which has raised me the question of whether there's an use case
> for always running hypervisor code with SSBD enabled, or that's no
> longer relevant if we always offer guests a way for them to toggle the
> setting when required.
>
> I would like to settle on a way forward, so we can get this fixed
> before 4.17.
>
> Thanks, Roger.
>
> [0] 
> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#spec-ctrl-x86

There are many issues at play here.  Not least that virt spec ctrl is
technically a leftover task that ought to force a re-issue of XSA-263.

Accessing MSRs (even reading) is very expensive, typically >1k cycles. 
The core CFG registers are more expensive than most, because they're
intended to be configured once after reset and then left alone.

Throughout the speculation work, we've seen crippling performance hits
from accessing MSRs in fastpaths.  The fact we're forced to use MSRs in
fastpaths even on new CPUs with built in (rather than retrofitted)
speculation support is is an area of concern still being worked on with
the CPU vendors.

Case in point.  We found for XSA-398 that toggling AMD's
MSR_SPEC_CTRL.IBRS on the PV entrypath was so bad that setting it
unilaterally behind the back of PV guests was the faster option. 
(Another todo is to stop doing this on Intel eIBRS systems, and this
will recover us a decent chunk of performance.)


SSBD mitigations are (rightly or wrongly) off by default for performance
reasons.  AMD are less affected than Intel, for microarchitectural
reasons which are discussed in relevant whitepapers, and which are
expected to remain true for future CPUs.

When Xen doesn't care about the protecting itself against SSBD by
default, I guarantee you that it will be faster to omit the MSR accesses
and run in the guest kernel's choice, than to clear the SSBD
protection.  We simply don't spend long enough in the hypervisor for the
hit against memory accesses to dwarf the hit for MSR accesses taken on
entry/exit.

The reason we put in spec-ctrl=ssbd was as a stopgap, because at the
time we didn't know how bad SSB really was, and it was decided that the
admin should have a big hammer to use if they really needed.

When Xen does care about protecting itself, the above reasoning bites
back hard.  Because we spend (or should be spending!) >99% of time in
the guest, the hit to memory accesses is far more likely to be able
dwarf the hit from the MSR accesses, but now, the dominating factor for
performance is the vmexit rate.

The problem is that if you've got a completely compute bound workload,
there are very few exits, while if you've got an IO bound workload,
there are plenty of exits.  I honestly don't know if it will be more
efficient to leave SSBD active unilaterally (whether or not we hide
this, e.g. synthesizing SSB_NO), or to let the guest run with it kernels
choice.  I suspect the answer is different with different workloads.


But, one other factor helps us.  Given that the default is fast (rather
than secure), anyone opting in to spec-ctrl=ssbd is saying "I care more
about security than performance", at which point we can simplify what we
do because we don't need to cater to everyone.


As a slight tangent, there is a cost to having too many options, which
must not be ignored.  Xen's speculation safety is far too complicated
already and needs to get more simple; this has a material impact on how
easy it is to follow, and how easy it to make changes.

It is the way it is because we've had 6 years of drip feeding one
problem after another, and haven't had the time to take a step and
design something more sensible 

Re: [GIT PULL] xen: branch for v6.1-rc2

[pr-tracker-bot]

The pull request you sent on Fri, 21 Oct 2022 11:31:19 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-6.1-rc2-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1d61754caa8c69f566504e63c8b3f3a2df0954c8

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH] automation: test.yaml: Introduce templates to reduce the overhead

[Stefano Stabellini]

On Wed, 19 Oct 2022, Michal Orzel wrote:
> At the moment, we define lots of test jobs in test.yaml, that make use
> of the same configuration sections like variables, tags, artifacts.
> Introduce templates (hidden jobs whose names start with a dot) to
> reduce the overhead and simplify the file (more than 100 lines saved).
> This way, the actual jobs can only specify sections that are unique
> to them.
> 
> Most of the test jobs specify the same set of prerequisite jobs under needs
> property with just one additional being unique to the job itself. Introduce
> YAML anchors for that purpose, because when using extends, the needs property
> is not being merged (the parent property overwrites the child one).

I like the patch. Replying here on top because the diff below is not
very helpful.

When you say that "extends" overwrites the properties, do you mean that
"needs" in qemu-smoke-dom0-arm64-gcc overwrites "needs" in .qemu-arm64,
when qemu-smoke-dom0-arm64-gcc includes .qemu-arm64?


If there is no way to solve the overwrite problem then it is OK to use
YAML achors but is it possible to define the anchors outside of
.qemu-arm64/.qemu-arm32 ? It would make things a lot clearer in the
code. Maybe under a top level "definitions" key? The point is that
.qemu-arm64 and .qemu-arm32 should use the anchor rather than define the
anchor.

I wouldn't call it qemu-arm64-needs because it has things
like alpine-3.12-arm64-rootfs-export and kernel-5.19-arm64-export that
are not required by qemu-system-aarch64-6.0.0-arm64-export. If anything
qemu-system-aarch64-6.0.0-arm64-export needs CONTAINER:
debian:unstable-arm64v8.

So I would call the anchor something like "arm64-test-needs". Same
comment for the arm32 anchor.


> Signed-off-by: Michal Orzel 
> ---
> This patch is based on the CI next branch where we already have several
> patches (already acked) to be merged into staging after the release:
> https://gitlab.com/xen-project/people/sstabellini/xen/-/tree/next
> 
> Tested pipeline:
> https://gitlab.com/xen-project/people/morzel/xen-orzelmichal/-/pipelines/671114820
> ---
>  automation/gitlab-ci/test.yaml | 266 ++---
>  1 file changed, 80 insertions(+), 186 deletions(-)
> 
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index 92e0a1f7c510..fc0884b12082 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -7,32 +7,12 @@
>  - /^coverity-tested\/.*/
>  - /^stable-.*/
>  
> -# Test jobs
> -build-each-commit-gcc:
> -  extends: .test-jobs-common
> -  variables:
> -CONTAINER: debian:stretch
> -XEN_TARGET_ARCH: x86_64
> -CC: gcc
> -  script:
> -- BASE=${BASE_SHA:-${CI_COMMIT_BEFORE_SHA}} 
> TIP=${TIP_SHA:-${CI_COMMIT_SHA}} ./automation/gitlab-ci/build-each-commit.sh 
> 2>&1 | tee ../build-each-commit-gcc.log
> -- mv ../build-each-commit-gcc.log .
> -  artifacts:
> -paths:
> -  - '*.log'
> -when: always
> -  needs: []
> -  tags:
> -- x86_64
> -
> -qemu-smoke-dom0-arm64-gcc:
> +.qemu-arm64:
>extends: .test-jobs-common
>variables:
>  CONTAINER: debian:unstable-arm64v8
> -  script:
> -- ./automation/scripts/qemu-smoke-dom0-arm64.sh 2>&1 | tee 
> qemu-smoke-arm64.log
> -  needs:
> -- alpine-3.12-gcc-arm64
> +LOGFILE: qemu-smoke-arm64.log
> +  needs: 
>  - alpine-3.12-arm64-rootfs-export
>  - kernel-5.19-arm64-export
>  - qemu-system-aarch64-6.0.0-arm64-export

LOGFILE should be listed among the artifacts (and maybe we can remove
*.log if it has become redundant?)


> @@ -44,17 +24,13 @@ qemu-smoke-dom0-arm64-gcc:
>tags:
>  - arm64
>  
> -qemu-smoke-dom0-arm64-gcc-debug:
> +.qemu-arm32:
>extends: .test-jobs-common
>variables:
>  CONTAINER: debian:unstable-arm64v8
> -  script:
> -- ./automation/scripts/qemu-smoke-dom0-arm64.sh 2>&1 | tee 
> qemu-smoke-arm64.log
> -  needs:
> -- alpine-3.12-gcc-debug-arm64
> -- alpine-3.12-arm64-rootfs-export
> -- kernel-5.19-arm64-export
> -- qemu-system-aarch64-6.0.0-arm64-export
> +LOGFILE: qemu-smoke-arm32.log
> +  needs: 
> +- qemu-system-aarch64-6.0.0-arm32-export
>artifacts:
>  paths:
>- smoke.serial
> @@ -63,16 +39,11 @@ qemu-smoke-dom0-arm64-gcc-debug:
>tags:
>  - arm64
>  
> -qemu-alpine-x86_64-gcc:
> +.qemu-x86-64:
>extends: .test-jobs-common
>variables:
>  CONTAINER: debian:stretch
> -  script:
> -- ./automation/scripts/qemu-alpine-x86_64.sh 2>&1 | tee 
> qemu-smoke-x86_64.log
> -  needs:
> -- alpine-3.12-gcc
> -- alpine-3.12-rootfs-export
> -- kernel-5.10.74-export
> +LOGFILE: qemu-smoke-x86-64.log
>artifacts:
>  paths:
>- smoke.serial
> @@ -81,214 +52,137 @@ qemu-alpine-x86_64-gcc:
>tags:
>  - x86_64
>  
> -qemu-smoke-dom0less-arm64-gcc:
> +# Test jobs
> +build-each-commit-gcc:
>extends: .test-jobs-common
>variables:
> -CONTAINER: debian:unstable-arm64v8
> +CONTAINER: 

Re: [RFC PATCH v1 02/12] Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32

[Xenia Ragiadakou]

On 10/21/22 18:31, Ayan Kumar Halder wrote:
Hi Ayan


Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#L14 , these macros are specific for arm64.

When one computes MPIDR_LEVEL_SHIFT(3), it crosses the width of a 32
bit register.

Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
asm/cputype.h#L54  , these macros are specific for arm32.

Signed-off-by: Ayan Kumar Halder 
---
  xen/arch/arm/include/asm/arm32/processor.h | 10 ++
  xen/arch/arm/include/asm/arm64/processor.h | 13 +
  xen/arch/arm/include/asm/processor.h   | 14 --
  3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/processor.h 
b/xen/arch/arm/include/asm/arm32/processor.h
index 4e679f3273..3e03ce78dc 100644
--- a/xen/arch/arm/include/asm/arm32/processor.h
+++ b/xen/arch/arm/include/asm/arm32/processor.h
@@ -56,6 +56,16 @@ struct cpu_user_regs
  uint32_t pad1; /* Doubleword-align the user half of the frame */
  };
  
+/*

+ * Macros to extract affinity level. Picked from kernel
+ */
+
+#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
+#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+((mpidr >> (MPIDR_LEVEL_BITS * level)) & MPIDR_LEVEL_MASK)
+
  #endif
  
  #endif /* __ASM_ARM_ARM32_PROCESSOR_H */

diff --git a/xen/arch/arm/include/asm/arm64/processor.h 
b/xen/arch/arm/include/asm/arm64/processor.h
index c749f80ad9..c026334eec 100644
--- a/xen/arch/arm/include/asm/arm64/processor.h
+++ b/xen/arch/arm/include/asm/arm64/processor.h
@@ -84,6 +84,19 @@ struct cpu_user_regs
  uint64_t sp_el1, elr_el1;
  };
  
+/*

+ * Macros to extract affinity level. picked from kernel
+ */
+
+#define MPIDR_LEVEL_BITS_SHIFT  3
+#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_LEVEL_SHIFT(level) \
+ (((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+ ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
+
  #undef __DECL_REG
  
  #endif /* __ASSEMBLY__ */

diff --git a/xen/arch/arm/include/asm/processor.h 
b/xen/arch/arm/include/asm/processor.h
index 1dd81d7d52..7d90c3b5f2 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -118,20 +118,6 @@
  #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
  #define MPIDR_LEVEL_BITS(8)
  
-

-/*
- * Macros to extract affinity level. picked from kernel
- */
-
-#define MPIDR_LEVEL_BITS_SHIFT  3
-#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
-
-#define MPIDR_LEVEL_SHIFT(level) \
- (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
-
-#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
- (((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
-
  #define AFFINITY_MASK(level)~((_AC(0x1,UL) << MPIDR_LEVEL_SHIFT(level)) - 
1)
  
  /* TTBCR Translation Table Base Control Register */


Since only the definition of the MPIDR_AFFINITY_LEVEL() differs, maybe 
you could add only this one to the arch specific headers e.g

for arm64:
#define MPIDR_LEVEL_SHIFT(level) \
(((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
for arm32:
#define MPIDR_LEVEL_SHIFT(level) \
((level) << MPIDR_LEVEL_BITS_SHIFT)

But in any case don't forget to add parentheses around the macro 
parameters when an operator acts on them to avoid trouble with operator 
precedence (MISRA-C Rule 20.7 :))


--
Xenia

Re: Issue: Networking performance in Xen VM on Arm64

[Stefano Stabellini]

On Fri, 21 Oct 2022, Leo Yan wrote:
> Hi Stefano and all,
> 
> On Mon, Oct 17, 2022 at 04:50:05PM -0700, Stefano Stabellini wrote:
> 
> [...]
> 
> > > We can see DomU sends notification with timestamp (raw counter) is
> > > 4989078592 and Dom0 receives the interrupt with timestamp 4989092169.
> > > Since Dom0 and DomU use the same time counter and the counter
> > > frequency is 25MHz, so we can get the delta value (in macroseconds):
> > > 
> > > (4989092169 - 4989078592) / 2500 * 1000 * 1000
> > >   = 543us
> > > 
> > > Which means it takes 543us to let Dom0 to receive the notification.
> > > You could see DomU runs in CPU3 and Dom0 runs on CPU13, there should
> > > not have contention for CPU resources.  Seems to me, it's likely Xen
> > > hypervisor takes long time to deliver the interrupt, note, it's not
> > > take so long time for every skb transferring, sometimes the time for
> > > response a notification is short (about ~10us).
> > 
> > Good find. I think this is worth investigating further. Do you have
> > vwfi=native in your Xen command line as well?
> > 
> > After that, I would add printk also in Xen with the timestamp. The event
> > channel notification code path is the following:
> > 
> > # domU side
> > xen/arch/arm/vgic-v2.c:vgic_v2_to_sgi
> > xen/arch/arm/vgic.c:vgic_to_sgi
> > xen/arch/arm/vgic.c:vgic_inject_irq
> > xen/arch/arm/vgic.c:vcpu_kick
> > xen/arch/arm/gic-v2.c:gicv2_send_SGI
> > 
> > # dom0 side
> > xen/arch/arm/gic.c:do_sgi
> > xen/arch/arm/traps.c:leave_hypervisor_to_guest
> > 
> > It would be good to understand why sometimes it takes ~10us and some
> > other times it takes ~540us
> 
> Some updates for why it takes several hundreds us for Xen backend driver
> to respond interrupt.  The short answer is the vcpu running Xen backend
> driver needs to switch context, even I have set options "sched=null
> vwfi=native" in Xen command line.
> 
> So please see below detailed logs for how the things happen.
> 
> Let's take the timestamp 3842008681 as the start point, it's the time
> for Xen backend driver sending out notification (xennet_notify_tx_irq);
> at the timestamp 3842008885 the Xen hypervisor injects the interrupt
> (it's about ~8us duration from the start point).
> 
> And then at the timestamp 3842008935 it invokes vcpu_kick() to kick the
> virtual CPU for running Xen forend driver, you could see
> VCPU_PROCESSOR is 11 and VCPU_ID is 9 for dom0, the duration is
> 10.16us from the start point.
> 
> The key point is at this point the vcpu's is_running is 0, this is
> different from the case without long latency which vcpu's is_running
> is 1.  IIUC, Xen hypervisor needs to take time to restore the vcpu's
> context, thus we can see the virtual CPU 9 in Dom0 starts to run at
> the timestamp 3842016505.

is_running should be always 1 with the NULL scheduler and vwfi=native.
That is because VMs are never descheduled. Please double-check.

If you are really running with the NULL scheduler, then I would
investigate why the vCPU has is_running == 0 because it should not
happen.


Now regarding the results, I can see the timestamp 3842008681 for
xennet_notify_tx_irq, 3842008885 for vgic_inject_irq, and 3842008935 for
vcpu_kick. Where is the corresponding TSC for the domain receiving the
notification?

Also for the other case, starting at 3842016505, can you please
highlight the timestamp for vgic_inject_irq, vcpu_kick, and also the one
for the domain receiving the notification?

The most interesting timestamps would be the timestamp for vcpu_kick in
"notification sending domain" [a], the timestamp for receiving the
interrupt in the Xen on pCPU for the "notification receiving domain"
[b], and the timestamp for the "notification receiving domain" getting
the notification [c].

If really context switch is the issue, then the interesting latency
would be between [a] and [b].



> 3842008548  pub-310   [001]67.352980: bprint:   
> xennet_start_xmit: xennet_start_xmit: TSC: 3842008548
> 3842008652  pub-310   [001]67.352984: bprint:   
> xennet_tx_setup_grant: id=52 ref=820 offset=2 len=1514 TSC: 3842008652
> 3842008681  pub-310   [001]67.352985: bprint:   
> xennet_start_xmit: xennet_notify_tx_irq: TSC: 3842008681
> 3842008689 (XEN) leave_hypervisor_to_guest: CPU_ID: 0 TSC: 3842008689
> 3842008766 (XEN) EVTCHNOP_send: CPU_ID: 2 TSC: 3842008766
> 3842008885 (XEN) vgic_inject_irq: CPU_ID: 2 TSC: 3842008885
> 3842008929 (XEN) leave_hypervisor_to_guest: CPU_ID: 14 TSC: 3842008929
> 3842008935 (XEN) vcpu_kick: VCPU_PROCESSOR: 11 VCPU_ID: 9 is_running 0 TSC: 
> 3842008935
> 3842009049 (XEN) leave_hypervisor_to_guest: CPU_ID: 2 TSC: 3842009049
> 3842009322  pub-310   [001]67.353011: bprint:   
> xennet_start_xmit: xennet_start_xmit: TSC: 3842009322
> 3842009374  pub-310   [001]67.353013: bprint:   
> xennet_tx_setup_grant: id=12 ref=780 offset=2050 

[xen-4.13-testing test] 174152: regressions - FAIL

[osstest service owner]

flight 174152 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174152/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm  14 guest-start  fail REGR. vs. 172549
 test-arm64-arm64-xl-credit1  14 guest-start  fail REGR. vs. 172549
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 172549
 test-armhf-armhf-xl-arndale  14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-xl-credit1  14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-xl-credit2  14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 172549
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-libvirt-qcow2 12 debian-di-install  fail REGR. vs. 172549
 test-armhf-armhf-xl  14 guest-start  fail REGR. vs. 172549
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 172549
 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 172549

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-dom0pvh-xl-intel  8 xen-bootfail in 173935 pass in 174152
 test-arm64-arm64-libvirt-xsm 14 guest-startfail pass in 173735
 test-arm64-arm64-libvirt-raw 12 debian-di-install  fail pass in 173735
 test-arm64-arm64-xl  14 guest-startfail pass in 173935
 test-arm64-arm64-xl-credit2  14 guest-startfail pass in 173935
 test-arm64-arm64-xl-vhd  12 debian-di-install  fail pass in 173935
 test-amd64-i386-libvirt-xsm   7 xen-installfail pass in 174126

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 14 guest-start  fail REGR. vs. 172549

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 173735 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 173735 never 
pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 173735 never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 173735 never 
pass
 test-arm64-arm64-xl 15 migrate-support-check fail in 173935 never pass
 test-arm64-arm64-xl 16 saverestore-support-check fail in 173935 never pass
 test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 173935 never pass
 test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 173935 never 
pass
 test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 173935 never pass
 test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 173935 never pass
 test-amd64-i386-libvirt-xsm 15 migrate-support-check fail in 174126 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172549
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172549
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172549
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172549
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172549
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172549
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172549
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172549
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172549
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved in 174126 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1) starved in 174126 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  starved in 174126 n/a
 test-armhf-armhf-xl   1 build-check(1)   starved in 174126 n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved in 174126 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   starved in 174126 n/a
 

Re: [PATCH V3] xen/virtio: Handle PCI devices which Host controller is described in DT

[Stefano Stabellini]

On Fri, 21 Oct 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko 
> 
> Use the same "xen-grant-dma" device concept for the PCI devices
> behind device-tree based PCI Host controller, but with one modification.
> Unlike for platform devices, we cannot use generic IOMMU bindings
> (iommus property), as we need to support more flexible configuration.
> The problem is that PCI devices under the single PCI Host controller
> may have the backends running in different Xen domains and thus have
> different endpoints ID (backend domains ID).
> 
> Add ability to deal with generic PCI-IOMMU bindings (iommu-map/
> iommu-map-mask properties) which allows us to describe relationship
> between PCI devices and backend domains ID properly.
> 
> To avoid having to look up for the PCI Host bridge twice and reduce
> the amount of checks pass an extra struct device_node *np to both
> xen_dt_grant_init_backend_domid() and xen_is_dt_grant_dma_device().
> While at it also pass domid_t *backend_domid instead of
> struct xen_grant_dma_data *data to the former.
> 
> So with current patch the code expects iommus property for the platform
> devices and iommu-map/iommu-map-mask properties for PCI devices.
> 
> The example of generated by the toolstack iommu-map property
> for two PCI devices :00:01.0 and :00:02.0 whose
> backends are running in different Xen domains with IDs 1 and 2
> respectively:
> iommu-map = <0x08 0xfde9 0x01 0x08 0x10 0xfde9 0x02 0x08>;
> 
> Signed-off-by: Oleksandr Tyshchenko 
> ---
> Slightly RFC. This is needed to support Xen grant mappings for virtio-pci 
> devices
> on Arm at some point in the future. The Xen toolstack side is not completely 
> ready yet.
> Here, for PCI devices we use more flexible way to pass backend domid to the 
> guest
> than for platform devices.
> 
> Changes V1 -> V2:
>- update commit description
>- rebase
>- rework to use generic PCI-IOMMU bindings instead of generic IOMMU 
> bindings
> 
> Changes V2 -> V3:
>- update commit description, add an example
>- drop xen_dt_map_id() and squash xen_dt_get_pci_host_node() with
>  xen_dt_get_node()
>- pass struct device_node *np to xen_is_dt_grant_dma_device() and
>  xen_dt_grant_init_backend_domid()
>- pass domid_t *backend_domid instead of struct xen_grant_dma_data *data
>  to xen_dt_grant_init_backend_domid()
> 
> Previous discussion is at:
> https://lore.kernel.org/xen-devel/20221006174804.2003029-1-olekst...@gmail.com/
> https://lore.kernel.org/xen-devel/20221015153409.918775-1-olekst...@gmail.com/
> 
> Based on:
> https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-6.1
> ---
>  drivers/xen/grant-dma-ops.c | 80 ++---
>  1 file changed, 66 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> index daa525df7bdc..76b29d20aeee 100644
> --- a/drivers/xen/grant-dma-ops.c
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -292,12 +293,37 @@ static const struct dma_map_ops xen_grant_dma_ops = {
>   .dma_supported = xen_grant_dma_supported,
>  };
>  
> -static bool xen_is_dt_grant_dma_device(struct device *dev)
> +static struct device_node *xen_dt_get_node(struct device *dev)
>  {
> - struct device_node *iommu_np;
> + if (dev_is_pci(dev)) {
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct pci_bus *bus = pdev->bus;
> +
> + /* Walk up to the root bus to look for PCI Host controller */
> + while (!pci_is_root_bus(bus))
> + bus = bus->parent;
> +
> + return of_node_get(bus->bridge->parent->of_node);
> + }
> +
> + return of_node_get(dev->of_node);
> +}
> +
> +static bool xen_is_dt_grant_dma_device(struct device *dev,
> + struct device_node *np)
> +{
> + struct device_node *iommu_np = NULL;
>   bool has_iommu;
>  
> - iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
> + if (dev_is_pci(dev)) {
> + struct pci_dev *pdev = to_pci_dev(dev);
> + u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
> +
> + if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", 
> _np, NULL))
> + return false;
> + } else
> + iommu_np = of_parse_phandle(np, "iommus", 0);
> +
>   has_iommu = iommu_np &&
>   of_device_is_compatible(iommu_np, "xen,grant-dma");
>   of_node_put(iommu_np);

I think we can remove xen_is_dt_grant_dma_device and just call
xen_dt_grant_init_backend_domid passing a NULL backend_domid?

It is a bit annoying that we are basically doing the same device tree
parsing twice in a row given that the callers do:

if (xen_is_grant_dma_device(dev))
xen_grant_setup_dma_ops(dev);

Maybe we could move the backend_domid 

Re: [for-4.17] automation: Do not use null scheduler for boot cpupools test

[Stefano Stabellini]

On Fri, 21 Oct 2022, Andrew Cooper wrote:
> On 21/10/2022 17:53, Michal Orzel wrote:
> > Null scheduler is not enabled on non-debug Xen builds so the current
> > test can lead to a failure on such jobs. We still want to test that we
> > can assign the cpupool to a domU with a different scheduler than default
> > one (credit2). Switch to credit as it is enabled by default.
> >
> > Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time 
> > cpupools on arm64")
> > Signed-off-by: Michal Orzel 
> 
> /sigh - I'm sure I nacked that stupidity to begin with.  apparently not...
> 
> It is totally bogus for CONFIG_DEBUG to influence logical chunks of
> functionality like this.  The CI script is good in its current form.
> 
> RTDS and ARINC should be default n.
> 
> NULL is more tricky.  PV_SHIM is explicitly security supported, and has
> been for years, so the "UNSUPPORTED" is bogus, whatever the default is.
> 
> As NULL is explicitly tested in CI, it's clearly supported, and probably
> ought to be on default.
> 
> 
> Please instead fix Kconfig to not be broken.  That will be a far better
> fix overall for people.
> 
> As a more general note, tests which are using non-default pieces of
> logic ought to activate them explicitly.


I agree with you, but first let me clarify the word "supported".


In Xen Project "supported" implies extra efforts to follow the security
process and of course the security team should be on board with it. If
we say "supported, non security supported" we don't need to follow the
security process but still we sign up for backporting fixes to the
stable tree. It is less extra effort but still some extra effort is
involved.

So, this specific issue aside, I think that as we expand the testing
capabilities of gitlab-ci, we'll have tests for things that are not
necessarily neither "supported" nor "supported, non security supported".


For the NULL scheduler, it is clearly important to many users so it
would be valuable to move it to "supported, non security supported" and
enabling it by default in the build. I don't recall if we still have any
known outstanding issues with it. I think we need a separate email
thread for that discussion and I would understand if the decision is not
to change NULL support status for the 4.17 release (maybe for the 4.18
release?).


In any case, we don't need CONFIG_DEBUG to enable CONFIG_UNSUPPORTED. It
is just that UNSUPPORTED and NULL don't get enabled by default in the
non-DEBUG build. So to fix gitlab-ci, we can simply enable
CONFIG_UNSUPPORTED explicitly for the builds where we need it
(alpine-3.12-gcc-arm64-boot-cpupools).

Re: [for-4.17] automation: Build Xen according to the type of the job

[Stefano Stabellini]

On Fri, 21 Oct 2022, Michal Orzel wrote:
> All the build jobs exist in two flavors: debug and non-debug, where the
> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
> is only being recognized by the toolstack, because Xen requires
> enabling/disabling debug build via e.g. menuconfig/config file.
> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
> set to a default value ('y' for unstable and 'n' for stable branches),
> regardless of the type of the build job.
> 
> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
> 
> Signed-off-by: Michal Orzel 

Reviewed-by: Stefano Stabellini 


> ---
> Xen used debug variable to control the build type before switching to Kconfig.
> Support for GitLab CI was added later, which means that this issue was always
> present. This is a low risk for 4.17 with a benefit of being able to test Xen
> in both debug and non-debug versions.
> ---
>  automation/scripts/build | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/automation/scripts/build b/automation/scripts/build
> index 8c0882f3aa33..a5934190634b 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -21,12 +21,13 @@ if [[ "${RANDCONFIG}" == "y" ]]; then
>  make -j$(nproc) -C xen KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config 
> randconfig
>  hypervisor_only="y"
>  else
> +echo "CONFIG_DEBUG=${debug}" > xen/.config
> +
>  if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then
> -echo "${EXTRA_XEN_CONFIG}" > xen/.config
> -make -j$(nproc) -C xen olddefconfig
> -else
> -make -j$(nproc) -C xen defconfig
> +echo "${EXTRA_XEN_CONFIG}" >> xen/.config
>  fi
> +
> +make -j$(nproc) -C xen olddefconfig
>  fi
>  
>  # Save the config file before building because build failure causes the 
> script
> -- 
> 2.25.1
> 

Re: [PATCH for-4.17?] test/vpci: enable by default

[Andrew Cooper]

On 20/10/2022 11:27, Roger Pau Monne wrote:
> CONFIG_HAS_PCI is not defined for the tools build, and as a result the
> vpci harness would never get build.  Fix this by building it
> unconditionally, there's nothing arch specific in it.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
> While not strictly a bugfix, I think it's worth adding this change to the
> release in order to always build the vpci test hardness and prevent it
> from bitrotting.
> ---
>  tools/tests/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/tests/Makefile b/tools/tests/Makefile
> index 33e32730c4..d99146d56a 100644
> --- a/tools/tests/Makefile
> +++ b/tools/tests/Makefile
> @@ -10,7 +10,7 @@ SUBDIRS-$(CONFIG_X86) += x86_emulator
>  endif
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += depriv
> -SUBDIRS-$(CONFIG_HAS_PCI) += vpci
> +SUBDIRS-y += vpci

I'm afraid this is only half the fix.  The other half is:

diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
index 5075bc2be28c..336904958f6a 100644
--- a/tools/tests/vpci/Makefile
+++ b/tools/tests/vpci/Makefile
@@ -22,6 +22,8 @@ distclean: clean
 
 .PHONY: install
 install:
+   $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+   $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)
 
 vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c
    # Remove includes and add the test harness header

so it can actually get deployed somewhere useful.

~Andrew

Re: [PATCH 04/12] tools/xl: add support for cache coloring configuration

[Julien Grall]

Hi Carlo,

This patch seems to be missing the tools maintainers/reviewers. I have 
added them now.


I am not sure what you are to generate the CCs. If you are not aware, we 
have a script that will add the correct maintainers/reviewers for each 
patch. The script is called "scripts/add_maintainers.pl" and can be used 
after generating the patches.


Cheers,

On 26/08/2022 13:51, Carlo Nonato wrote:

Add a new "colors" parameter that defines the color assignment for a
domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the documentation.
The parameter is defined as a list of strings that represent the
color ranges.
Also documentation is added.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
  docs/man/xl.cfg.5.pod.in | 10 ++
  tools/libs/light/libxl_create.c  | 12 
  tools/libs/light/libxl_types.idl |  1 +
  tools/xl/xl_parse.c  | 52 ++--
  4 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index b2901e04cf..5f53cec8bf 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2880,6 +2880,16 @@ Currently, only the "sbsa_uart" model is supported for 
ARM.
  
  =back
  
+=over 4

+
+=item B
+
+Specify the LLC color configuration for the guest. B can be 
either
+a single color value or a hypen-separated closed interval of colors
+(such as "0-4").
+
+=back
+
  =head3 x86
  
  =over 4

diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index b9dd2deedf..94c511912c 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -615,6 +615,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
  struct xs_permissions rwperm[1];
  struct xs_permissions noperm[1];
  xs_transaction_t t = 0;
+DECLARE_HYPERCALL_BUFFER(unsigned int, colors);
  
  /* convenience aliases */

  libxl_domain_create_info *info = _config->c_info;
@@ -676,6 +677,16 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
  goto out;
  }
  
+if (d_config->b_info.num_colors) {

+size_t bytes = sizeof(unsigned int) * d_config->b_info.num_colors;
+colors = xc_hypercall_buffer_alloc(ctx->xch, colors, bytes);
+memcpy(colors, d_config->b_info.colors, bytes);
+set_xen_guest_handle(create.arch.colors, colors);
+create.arch.num_colors = d_config->b_info.num_colors;
+create.arch.from_guest = 1;
+LOG(DEBUG, "Setup %u domain colors", d_config->b_info.num_colors);
+}
+
  for (;;) {
  uint32_t local_domid;
  bool recent;
@@ -922,6 +933,7 @@ retry_transaction:
  rc = 0;
   out:
  if (t) xs_transaction_end(ctx->xsh, t, 1);
+if (colors) xc_hypercall_buffer_free(ctx->xch, colors);
  return rc;
  }
  
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl

index d634f304cd..642173af1a 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -557,6 +557,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
  ("ioports",  Array(libxl_ioport_range, "num_ioports")),
  ("irqs", Array(uint32, "num_irqs")),
  ("iomem",Array(libxl_iomem_range, "num_iomem")),
+("colors",   Array(uint32, "num_colors")),
  ("claim_mode",   libxl_defbool),
  ("event_channels",   uint32),
  ("kernel",   string),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 1b5381cef0..7f8fbbfb4c 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1220,8 +1220,9 @@ void parse_config_data(const char *config_source,
  XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
 *usbctrls, *usbdevs, *p9devs, *vdispls, *pvcallsifs_devs;
  XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs,
-   *mca_caps;
-int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps;
+   *mca_caps, *colors;
+int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps,
+num_colors;
  int pci_power_mgmt = 0;
  int pci_msitranslate = 0;
  int pci_permissive = 0;
@@ -1370,6 +1371,53 @@ void parse_config_data(const char *config_source,
  if (!xlu_cfg_get_long (config, "maxmem", , 0))
  b_info->max_memkb = l * 1024;
  
+if (!xlu_cfg_get_list(config, "colors", , _colors, 0)) {

+int k, p, cur_index;
+
+b_info->num_colors = 0;
+/* Get number of colors based on ranges */
+for (i = 0; i < num_colors; i++) {
+uint32_t start = 0, end = 0;
+
+buf = xlu_cfg_get_listitem(colors, i);
+if (!buf) {
+fprintf(stderr,
+"xl: 

Re: [PATCH 02/12] xen/arm: add cache coloring initialization for domains

[Julien Grall]

Hi,

On 26/08/2022 13:51, Carlo Nonato wrote:

  #endif /* !__ASM_ARM_COLORING_H__ */
diff --git a/xen/arch/arm/include/asm/domain.h 
b/xen/arch/arm/include/asm/domain.h
index 26a8348eed..291f7c375d 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -58,6 +58,10 @@ struct arch_domain
  #ifdef CONFIG_ARM_64
  enum domain_type type;
  #endif
+#ifdef CONFIG_CACHE_COLORING
+unsigned int *colors;
+unsigned int num_colors;
+#endif
  
  /* Virtual MMU */

  struct p2m_domain p2m;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c8b6058d3a..adf843a7a1 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -314,6 +314,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
  #define XEN_DOMCTL_CONFIG_TEE_NONE  0
  #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1
  
+__DEFINE_XEN_GUEST_HANDLE(color_t, unsigned int);

+
  struct xen_arch_domainconfig {
  /* IN/OUT */
  uint8_t gic_version;
@@ -335,6 +337,12 @@ struct xen_arch_domainconfig {
   *
   */
  uint32_t clock_frequency;
+/* IN */
+uint8_t from_guest;
+/* IN */
+uint16_t num_colors;
+/* IN */
+XEN_GUEST_HANDLE(color_t) colors;
  };
  #endif /* __XEN__ || __XEN_TOOLS__ */



I forgot to mention. I think the golang and OCaml bindings will also 
need to be re-generated. Andrew, Anthony, can you confirm?


Cheers,

--
Julien Grall

Re: [PATCH 02/12] xen/arm: add cache coloring initialization for domains

[Julien Grall]

Hi Carlo,

On 26/08/2022 13:51, Carlo Nonato wrote:

This commit adds array pointers to domains as well as to the hypercall
and configuration structure employed in domain creation. The latter is used
both by the toolstack and by Xen itself to pass configuration data to the
domain creation function, so the XEN_GUEST_HANDLE macro must be adopted to be
able to access guest memory in the first case. This implies special care for
the copy of the configuration data into the domain data, meaning that a
discrimination variable for the two possible code paths (coming from Xen or
from the toolstack) is needed.


So this means that a toolstack could set from_guest. I know the 
toolstack is trusted... However, we should try to limit when the trust 
when this is possible.


In this case, I would consider to modify the prototype of 
domain_create() to pass internal information.




The initialization and free functions for colored domains are also added.
The former is responsible for allocating and populating the color array
of the domain and it also checks for configuration issues. One of those
issues is enabling both coloring and directmap for the domain because they
contradicts one another. Since that, Dom0 must not be created with the
directmap flag.
The latter instead frees allocated memory.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
  docs/misc/arm/cache-coloring.rst|  7 ++--
  xen/arch/arm/coloring.c | 56 +
  xen/arch/arm/domain.c   | 11 ++
  xen/arch/arm/domain_build.c | 13 +--
  xen/arch/arm/include/asm/coloring.h |  7 
  xen/arch/arm/include/asm/domain.h   |  4 +++
  xen/include/public/arch-arm.h   |  8 +
  7 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst
index c7adcb0f1f..345d97cb56 100644
--- a/docs/misc/arm/cache-coloring.rst
+++ b/docs/misc/arm/cache-coloring.rst
@@ -13,7 +13,7 @@ In order to enable and use it, few steps are needed.
(refer to menuconfig help for value meaning and when it should be changed).
  
  CONFIG_MAX_CACHE_COLORS=

-- Assign colors to Dom0 using the `Color selection format`_ (see
+- Assign colors to domains using the `Color selection format`_ (see
`Coloring parameters`_ for more documentation pointers).
  
  Background

@@ -109,4 +109,7 @@ Coloring parameters
  
  LLC way size (as previously discussed) and Dom0 colors can be set using the

  appropriate command line parameters. See the relevant documentation in
-"docs/misc/xen-command-line.pandoc".
\ No newline at end of file
+"docs/misc/xen-command-line.pandoc".
+
+Note that if no color configuration is provided for domains, they fallback to
+the default one, which corresponds simply to all available colors.
\ No newline at end of file
diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c
index c010ebc01b..2b37cda067 100644
--- a/xen/arch/arm/coloring.c
+++ b/xen/arch/arm/coloring.c
@@ -22,6 +22,7 @@
   * along with this program.  If not, see .
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -211,6 +212,61 @@ bool __init coloring_init(void)
  return true;
  }
  
+int domain_coloring_init(struct domain *d,

+ const struct xen_arch_domainconfig *config)
+{
+if ( is_domain_direct_mapped(d) )
+{
+printk(XENLOG_ERR
+   "Can't enable coloring and directmap at the same time for 
%pd\n",
+   d);
+return -EINVAL;
+}
+
+if ( is_hardware_domain(d) )
+{
+d->arch.colors = dom0_colors;
+d->arch.num_colors = dom0_num_colors;
+}


I think it would be better if we allocate an array also for the HW 
domain. This is not going to require too much extra memory and will help 
the code to be simpler.


I would also pass the color to domain_create(). So there is no logic 
specific to the HW domain here.



+else if ( config->num_colors == 0 )
+{
+printk(XENLOG_WARNING
+   "Color config not found for %pd. Using default\n", d);
+d->arch.colors = xzalloc_array(unsigned int, max_colors);
+d->arch.num_colors = set_default_domain_colors(d->arch.colors);
Ah, so your check in set_default_domain_colors() is here to cater this 
case? I would prefer if we check the allocation before using it. This 
will make it more obvious compare to expecting 
set_default_domain_colors() checking for NULL.



+}
+else
+{
+d->arch.colors = xzalloc_array(unsigned int, config->num_colors);
+d->arch.num_colors = config->num_colors;
+if ( config->from_guest )
+copy_from_guest(d->arch.colors, config->colors, 
config->num_colors);
+else
+memcpy(d->arch.colors, config->colors.p,
+   sizeof(unsigned int) * config->num_colors);


See my remark above.


+}
+
+if ( !d->arch.colors )
+{
+   

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

[osstest service owner]

flight 174140 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174140/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 172623
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 172623
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 172623
 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 172623
 test-armhf-armhf-xl-arndale  14 guest-start  fail REGR. vs. 172623
 test-armhf-armhf-xl-credit1  14 guest-start  fail REGR. vs. 172623
 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 172623
 test-armhf-armhf-xl-credit2  14 guest-start  fail REGR. vs. 172623
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 172623
 test-armhf-armhf-xl  14 guest-start  fail REGR. vs. 172623
 test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 172623
 test-armhf-armhf-libvirt-qcow2 12 debian-di-install  fail REGR. vs. 172623

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 173511 pass in 174140
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail in 174070 pass 
in 174140
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail in 174070 pass in 
174140
 test-arm64-arm64-xl  14 guest-startfail pass in 173493
 test-arm64-arm64-xl-credit2  14 guest-startfail pass in 173493
 test-arm64-arm64-xl-xsm  14 guest-startfail pass in 173493
 test-arm64-arm64-xl-credit1  14 guest-startfail pass in 173511
 test-arm64-arm64-libvirt-xsm 14 guest-startfail pass in 173511
 test-arm64-arm64-xl-vhd  12 debian-di-install  fail pass in 174070

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 14 guest-start  fail REGR. vs. 172623

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl 15 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-xl 16 saverestore-support-check fail in 173493 never pass
 test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 173493 never 
pass
 test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 173493 never 
pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 173493 never 
pass
 test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 173493 never pass
 test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 173493 never pass
 test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 173493 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172623
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172623
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172623
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172623
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172623
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172623
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172623
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172623
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172623
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1bce7fb1f702da4f7a749c6f1457ecb20bf74fca
baseline version:
 xen  cea5ed49bb5716698a11312a3f38bc8865cd1e67

Last test of basis   172623  2022-08-18 12:08:13 Z   64 days
Testing 

Re: [PATCH 02/12] xen/arm: add cache coloring initialization for domains

[Julien Grall]

On 26/09/2022 07:39, Wei Chen wrote:



On 2022/8/26 20:51, Carlo Nonato wrote:

This commit adds array pointers to domains as well as to the hypercall
and configuration structure employed in domain creation. The latter is 
used

both by the toolstack and by Xen itself to pass configuration data to the
domain creation function, so the XEN_GUEST_HANDLE macro must be 
adopted to be
able to access guest memory in the first case. This implies special 
care for

the copy of the configuration data into the domain data, meaning that a
discrimination variable for the two possible code paths (coming from 
Xen or

from the toolstack) is needed.

The initialization and free functions for colored domains are also added.
The former is responsible for allocating and populating the color array
of the domain and it also checks for configuration issues. One of those
issues is enabling both coloring and directmap for the domain because 
they

contradicts one another. Since that, Dom0 must not be created with the
directmap flag.
The latter instead frees allocated memory.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
  docs/misc/arm/cache-coloring.rst    |  7 ++--
  xen/arch/arm/coloring.c | 56 +
  xen/arch/arm/domain.c   | 11 ++
  xen/arch/arm/domain_build.c | 13 +--
  xen/arch/arm/include/asm/coloring.h |  7 
  xen/arch/arm/include/asm/domain.h   |  4 +++
  xen/include/public/arch-arm.h   |  8 +
  7 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/docs/misc/arm/cache-coloring.rst 
b/docs/misc/arm/cache-coloring.rst

index c7adcb0f1f..345d97cb56 100644
--- a/docs/misc/arm/cache-coloring.rst
+++ b/docs/misc/arm/cache-coloring.rst
@@ -13,7 +13,7 @@ In order to enable and use it, few steps are needed.
    (refer to menuconfig help for value meaning and when it should be 
changed).

  CONFIG_MAX_CACHE_COLORS=
-- Assign colors to Dom0 using the `Color selection format`_ (see
+- Assign colors to domains using the `Color selection format`_ (see
    `Coloring parameters`_ for more documentation pointers).
  Background
@@ -109,4 +109,7 @@ Coloring parameters
  LLC way size (as previously discussed) and Dom0 colors can be set 
using the

  appropriate command line parameters. See the relevant documentation in
-"docs/misc/xen-command-line.pandoc".
\ No newline at end of file
+"docs/misc/xen-command-line.pandoc".
+
+Note that if no color configuration is provided for domains, they 
fallback to

+the default one, which corresponds simply to all available colors.
\ No newline at end of file
diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c
index c010ebc01b..2b37cda067 100644
--- a/xen/arch/arm/coloring.c
+++ b/xen/arch/arm/coloring.c
@@ -22,6 +22,7 @@
   * along with this program.  If not, see 
.

   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -211,6 +212,61 @@ bool __init coloring_init(void)
  return true;
  }
+int domain_coloring_init(struct domain *d,
+ const struct xen_arch_domainconfig *config)
+{
+    if ( is_domain_direct_mapped(d) )
+    {
+    printk(XENLOG_ERR
+   "Can't enable coloring and directmap at the same time 
for %pd\n",

+   d);
+    return -EINVAL;
+    }
+
+    if ( is_hardware_domain(d) )
+    {
+    d->arch.colors = dom0_colors;
+    d->arch.num_colors = dom0_num_colors;
+    }
+    else if ( config->num_colors == 0 )
+    {
+    printk(XENLOG_WARNING
+   "Color config not found for %pd. Using default\n", d);
+    d->arch.colors = xzalloc_array(unsigned int, max_colors);
+    d->arch.num_colors = set_default_domain_colors(d->arch.colors);
+    }
+    else
+    {
+    d->arch.colors = xzalloc_array(unsigned int, 
config->num_colors);

+    d->arch.num_colors = config->num_colors;
+    if ( config->from_guest )
+    copy_from_guest(d->arch.colors, config->colors, 
config->num_colors);

+    else
+    memcpy(d->arch.colors, config->colors.p,
+   sizeof(unsigned int) * config->num_colors);
+    }
+
+    if ( !d->arch.colors )
+    {
+    printk(XENLOG_ERR "Colors allocation failed for %pd\n", d);
+    return -ENOMEM;
+    }
+
+    if ( !check_colors(d->arch.colors, d->arch.num_colors) )
+    {


If we add xfree(d->arch.colors) here for non-hw domains, is it possible 
to make this function have a complete fallback process? And I know 
currently, this is handled in domain_coloring_free.


arch_domain_destroy() (and therefore domain_coloring_free()) will always 
be called by arch_domain_create(). So here you will want to use XFREE() 
to avoid a double free.


However, I would just rely on the free() in domain_coloring_free().

Cheers,

--
Julien Grall

[PATCH V3] xen/virtio: Handle PCI devices which Host controller is described in DT

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Use the same "xen-grant-dma" device concept for the PCI devices
behind device-tree based PCI Host controller, but with one modification.
Unlike for platform devices, we cannot use generic IOMMU bindings
(iommus property), as we need to support more flexible configuration.
The problem is that PCI devices under the single PCI Host controller
may have the backends running in different Xen domains and thus have
different endpoints ID (backend domains ID).

Add ability to deal with generic PCI-IOMMU bindings (iommu-map/
iommu-map-mask properties) which allows us to describe relationship
between PCI devices and backend domains ID properly.

To avoid having to look up for the PCI Host bridge twice and reduce
the amount of checks pass an extra struct device_node *np to both
xen_dt_grant_init_backend_domid() and xen_is_dt_grant_dma_device().
While at it also pass domid_t *backend_domid instead of
struct xen_grant_dma_data *data to the former.

So with current patch the code expects iommus property for the platform
devices and iommu-map/iommu-map-mask properties for PCI devices.

The example of generated by the toolstack iommu-map property
for two PCI devices :00:01.0 and :00:02.0 whose
backends are running in different Xen domains with IDs 1 and 2
respectively:
iommu-map = <0x08 0xfde9 0x01 0x08 0x10 0xfde9 0x02 0x08>;

Signed-off-by: Oleksandr Tyshchenko 
---
Slightly RFC. This is needed to support Xen grant mappings for virtio-pci 
devices
on Arm at some point in the future. The Xen toolstack side is not completely 
ready yet.
Here, for PCI devices we use more flexible way to pass backend domid to the 
guest
than for platform devices.

Changes V1 -> V2:
   - update commit description
   - rebase
   - rework to use generic PCI-IOMMU bindings instead of generic IOMMU bindings

Changes V2 -> V3:
   - update commit description, add an example
   - drop xen_dt_map_id() and squash xen_dt_get_pci_host_node() with
 xen_dt_get_node()
   - pass struct device_node *np to xen_is_dt_grant_dma_device() and
 xen_dt_grant_init_backend_domid()
   - pass domid_t *backend_domid instead of struct xen_grant_dma_data *data
 to xen_dt_grant_init_backend_domid()

Previous discussion is at:
https://lore.kernel.org/xen-devel/20221006174804.2003029-1-olekst...@gmail.com/
https://lore.kernel.org/xen-devel/20221015153409.918775-1-olekst...@gmail.com/

Based on:
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-6.1
---
 drivers/xen/grant-dma-ops.c | 80 ++---
 1 file changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index daa525df7bdc..76b29d20aeee 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -292,12 +293,37 @@ static const struct dma_map_ops xen_grant_dma_ops = {
.dma_supported = xen_grant_dma_supported,
 };
 
-static bool xen_is_dt_grant_dma_device(struct device *dev)
+static struct device_node *xen_dt_get_node(struct device *dev)
 {
-   struct device_node *iommu_np;
+   if (dev_is_pci(dev)) {
+   struct pci_dev *pdev = to_pci_dev(dev);
+   struct pci_bus *bus = pdev->bus;
+
+   /* Walk up to the root bus to look for PCI Host controller */
+   while (!pci_is_root_bus(bus))
+   bus = bus->parent;
+
+   return of_node_get(bus->bridge->parent->of_node);
+   }
+
+   return of_node_get(dev->of_node);
+}
+
+static bool xen_is_dt_grant_dma_device(struct device *dev,
+   struct device_node *np)
+{
+   struct device_node *iommu_np = NULL;
bool has_iommu;
 
-   iommu_np = of_parse_phandle(dev->of_node, "iommus", 0);
+   if (dev_is_pci(dev)) {
+   struct pci_dev *pdev = to_pci_dev(dev);
+   u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
+
+   if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", 
_np, NULL))
+   return false;
+   } else
+   iommu_np = of_parse_phandle(np, "iommus", 0);
+
has_iommu = iommu_np &&
of_device_is_compatible(iommu_np, "xen,grant-dma");
of_node_put(iommu_np);
@@ -307,9 +333,17 @@ static bool xen_is_dt_grant_dma_device(struct device *dev)
 
 bool xen_is_grant_dma_device(struct device *dev)
 {
+   struct device_node *np;
+
/* XXX Handle only DT devices for now */
-   if (dev->of_node)
-   return xen_is_dt_grant_dma_device(dev);
+   np = xen_dt_get_node(dev);
+   if (np) {
+   bool ret;
+
+   ret = xen_is_dt_grant_dma_device(dev, np);
+   of_node_put(np);
+   return ret;
+   }
 
return false;
 }
@@ -323,14 +357,26 @@ bool xen_virtio_mem_acc(struct virtio_device *dev)
 }
 

Re: [for-4.17] automation: Do not use null scheduler for boot cpupools test

[Andrew Cooper]

On 21/10/2022 17:53, Michal Orzel wrote:
> Null scheduler is not enabled on non-debug Xen builds so the current
> test can lead to a failure on such jobs. We still want to test that we
> can assign the cpupool to a domU with a different scheduler than default
> one (credit2). Switch to credit as it is enabled by default.
>
> Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time 
> cpupools on arm64")
> Signed-off-by: Michal Orzel 

/sigh - I'm sure I nacked that stupidity to begin with.  apparently not...

It is totally bogus for CONFIG_DEBUG to influence logical chunks of
functionality like this.  The CI script is good in its current form.

RTDS and ARINC should be default n.

NULL is more tricky.  PV_SHIM is explicitly security supported, and has
been for years, so the "UNSUPPORTED" is bogus, whatever the default is.

As NULL is explicitly tested in CI, it's clearly supported, and probably
ought to be on default.


Please instead fix Kconfig to not be broken.  That will be a far better
fix overall for people.

As a more general note, tests which are using non-default pieces of
logic ought to activate them explicitly.

~Andrew

Re: [PATCH 01/12] xen/arm: add cache coloring initialization

[Julien Grall]

Hi Carlo,

On 26/08/2022 13:51, Carlo Nonato wrote:

This commit adds the cache coloring support initialization, Kconfig options,
command line parameters and the initial documentation.
The initialization consists of an auto probing of the cache layout
necessary to retrieve the LLC way size which is used to compute the
number of available colors. The Dom0 colors are then initialized with default
colors (all available ones) if not provided from the command line, and
they are checked for bad configuration.

It also adds a debug-key to dump general cache coloring info.
This includes LLC way size, total available colors and the mask used to
extract colors from physical addresses.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
---
  docs/misc/arm/cache-coloring.rst | 112 ++
  docs/misc/xen-command-line.pandoc|  22 +++
  xen/arch/arm/Kconfig |  16 ++
  xen/arch/arm/Makefile|   1 +
  xen/arch/arm/coloring.c  | 222 +++
  xen/arch/arm/include/asm/coloring.h  |  31 
  xen/arch/arm/include/asm/processor.h |  16 ++
  xen/arch/arm/setup.c |   8 +
  8 files changed, 428 insertions(+)
  create mode 100644 docs/misc/arm/cache-coloring.rst
  create mode 100644 xen/arch/arm/coloring.c
  create mode 100644 xen/arch/arm/include/asm/coloring.h

diff --git a/docs/misc/arm/cache-coloring.rst b/docs/misc/arm/cache-coloring.rst
new file mode 100644
index 00..c7adcb0f1f
--- /dev/null
+++ b/docs/misc/arm/cache-coloring.rst
@@ -0,0 +1,112 @@
+Xen cache coloring user guide
+=
+
+The cache coloring support in Xen allows to reserve Last Level Cache (LLC)
+partition for Dom0, DomUs and Xen itself. Currently only ARM64 is supported.
+
+In order to enable and use it, few steps are needed.
+
+- Enable cache coloring in Xen configuration file.
+
+CONFIG_CACHE_COLORING=y
+- If needed, change the maximum number of colors in Xen configuration file
+  (refer to menuconfig help for value meaning and when it should be changed).
+
+CONFIG_MAX_CACHE_COLORS=
+- Assign colors to Dom0 using the `Color selection format`_ (see
+  `Coloring parameters`_ for more documentation pointers).
+
+Background
+**
+
+Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
+to each core (hence using multiple cache units), while the last level is shared
+among all of them. Such configuration implies that memory operations on one
+core (e.g. running a DomU) are able to generate interference on another core
+(e.g .hosting another DomU). Cache coloring allows eliminating this
+mutual interference, and thus guaranteeing higher and more predictable
+performances for memory accesses.
+The key concept underlying cache coloring is a fragmentation of the memory
+space into a set of sub-spaces called colors that are mapped to disjoint cache
+partitions. Technically, the whole memory space is first divided into a number
+of subsequent regions. Then each region is in turn divided into a number of
+subsequent sub-colors. The generic i-th color is then obtained by all the
+i-th sub-colors in each region.
+
+.. raw:: html
+
+
+Region jRegion j+1
+.   
+. . .
+.   .
+_ _ ___ _ _ _ _
+| | | | | | |
+| c_0 | c_1 | | c_n | c_0 | c_1 |
+   _ _ _|_|_|_ _ _|_|_|_|_ _ _
+:   :
+:   :... ... .
+:color 0
+:... ... .
+:
+  . . ..:
+
+
+There are two pragmatic lesson to be learnt.
+
+1. If one wants to avoid cache interference between two domains, different
+   colors needs to be used for their memory.
+
+2. Color assignment must privilege contiguity in the partitioning. E.g.,
+   assigning colors (0,1) to domain I  and (2,3) to domain  J is better than
+   assigning colors (0,2) to I and (1,3) to J.
+
+How to compute the number of colors
+***
+
+To compute the number of available colors for a specific platform, the size of
+a LLC way and the page size used by Xen must be known. The first parameter can
+be found in the processor manual or can be also computed dividing the total
+cache size by the number of its ways. The second parameter is the minimum 
amount
+of memory that can be mapped by the hypervisor, thus dividing the way size by
+the page size, the number of total cache partitions is found. So for example,
+an Arm Cortex-A53 with a 16-ways associative 1 MiB LLC, can isolate up to 16

[for-4.17] automation: Do not use null scheduler for boot cpupools test

[Michal Orzel]

Null scheduler is not enabled on non-debug Xen builds so the current
test can lead to a failure on such jobs. We still want to test that we
can assign the cpupool to a domU with a different scheduler than default
one (credit2). Switch to credit as it is enabled by default.

Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time cpupools 
on arm64")
Signed-off-by: Michal Orzel 
---
This patch acts as a prerequisite before merging the following patch:
https://lore.kernel.org/xen-devel/20221021132238.16056-1-michal.or...@amd.com/
(to which Henry already gave RAB), that helped to find the issue described
in the comment.
---
 automation/scripts/qemu-smoke-arm64.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/automation/scripts/qemu-smoke-arm64.sh 
b/automation/scripts/qemu-smoke-arm64.sh
index 5b566072f72a..a5d8d135b659 100755
--- a/automation/scripts/qemu-smoke-arm64.sh
+++ b/automation/scripts/qemu-smoke-arm64.sh
@@ -29,10 +29,10 @@ fi
 fi
 
 if [[ "${test_variant}" == "boot-cpupools" ]]; then
-# Check if domU0 (id=1) is assigned to Pool-1 with null scheduler
+# Check if domU0 (id=1) is assigned to Pool-1 with credit scheduler
 passed="${test_variant} test passed"
 dom0_check="
-if xl list -c 1 | grep -q Pool-1 && xl cpupool-list Pool-1 | grep -q Pool-1; 
then
+if xl list -c 1 | grep -q Pool-1 && xl cpupool-list Pool-1 | grep -q credit; 
then
 echo ${passed}
 fi
 "
@@ -140,7 +140,7 @@ fi
 
 if [[ "${test_variant}" == "boot-cpupools" ]]; then
 echo '
-CPUPOOL[0]="cpu@1 null"
+CPUPOOL[0]="cpu@1 credit"
 DOMU_CPUPOOL[0]=0
 NUM_CPUPOOLS=1' >> binaries/config
 fi
-- 
2.25.1

Re: [PATCH 08/12] Revert "xen/arm: setup: Add Xen as boot module before printing all boot modules"

[Julien Grall]

On 12/09/2022 14:54, Carlo Nonato wrote:

Hi Julien,


Hi Carlo,


On Sat, Sep 10, 2022 at 4:01 PM Julien Grall  wrote: > Do you 
have any suggestions? Is it ok to add the print to this very patch
explaining why I added that (since it would edit the clean revert)?


I would consider to the call to early_print_info() after the Xen module 
is created.


Cheers,

--
Julien Grall

[xen-unstable test] 174165: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

flight 174165 xen-unstable real [real]
flight 174205 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174165/
http://logs.test-lab.xenproject.org/osstest/logs/174205/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-examine-bios  6 xen-install fail pass in 174205-retest
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail pass in 
174205-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174133
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 174133
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 174133
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 174133
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 174133
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 174133
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 174133
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 174133
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174133
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-examine  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-seattle   3 hosts-allocate   starved  n/a

version targeted for testing:
 xen  0c06760be3dc3f286015e18c4b1d1694e55da026
baseline version:
 xen  9029bc265cdf2bd63376dde9fdd91db4ce9c0586

Last test of basis   174133  2022-10-20 11:59:00 Z1 days
Testing same since   174165  2022-10-21 02:14:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Artem Bityutskiy 
  Borislav Petkov 
  Christian Lindig 
  Daniel P. Smith 
  George Dunlap 
  Henry Wang 
  Jan Beulich 
  Jason Andryuk 
  Julien Grall 
  

Re: [for-4.17] automation: Build Xen according to the type of the job

[Michal Orzel]

On 21/10/2022 16:32, Michal Orzel wrote:
> 
> 
> Hi Andrew,
> 
> On 21/10/2022 15:31, Andrew Cooper wrote:
>>
>>
>> On 21/10/2022 14:22, Michal Orzel wrote:
>>> All the build jobs exist in two flavors: debug and non-debug, where the
>>> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
>>> is only being recognized by the toolstack, because Xen requires
>>> enabling/disabling debug build via e.g. menuconfig/config file.
>>> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
>>> set to a default value ('y' for unstable and 'n' for stable branches),
>>> regardless of the type of the build job.
>>>
>>> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
>>>
>>> Signed-off-by: Michal Orzel 
>>> ---
>>> Xen used debug variable to control the build type before switching to 
>>> Kconfig.
>>> Support for GitLab CI was added later, which means that this issue was 
>>> always
>>> present. This is a low risk for 4.17 with a benefit of being able to test 
>>> Xen
>>> in both debug and non-debug versions.
>>
>> Both series were floating around for ages before being accepted.  It's
>> quite possible that one bitrotted around the other.
>>
>> This should be backported, and therefore should be considered for 4.17
>> at this point.
>>
>> Is there a Gitlab CI run which includes this patch?
> 
> I submitted the one here not long ago:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fxen-project%2Fpeople%2Fmorzel%2Fxen-orzelmichal%2F-%2Fpipelines%2F673396949data=05%7C01%7Cmichal.orzel%40amd.com%7Cd091891dbc3a4144356d08dab37120ae%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638019595719666762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=r6qIERShnnovl57xvY%2Fo8eKozAy9NBlqyj0le56ZClY%3Dreserved=0
> 
> and there is already one failure in Arm boot-cpupools test because the script 
> sets null
> scheduler for the domain which is not present in non-debug build...

The CI finished running the pipeline and it looks like the null sched issue is 
the only one (at least this means that this patch is worth having).
I will push a fix for the boot-cpupools test (I will also mark it as for-4.17).

> 
>>
>> ~Andrew
> 
> ~Michal
> 

~Michal

[xen-4.16-testing bisection] complete test-armhf-armhf-xl-multivcpu

[osstest service owner]

branch xen-4.16-testing
xenbranch xen-4.16-testing
job test-armhf-armhf-xl-multivcpu
testid guest-start

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: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  44e9dcc48b81bca202a5b31926125a6a59a4c72e
  Bug not present: 3a16da801e14b8ff996b6f7408391ce488abd925
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/174207/


  commit 44e9dcc48b81bca202a5b31926125a6a59a4c72e
  Author: Henry Wang 
  Date:   Tue Oct 11 14:55:53 2022 +0200
  
  xen/arm: Allocate and free P2M pages from the P2M pool
  
  This commit sets/tearsdown of p2m pages pool for non-privileged Arm
  guests by calling `p2m_set_allocation` and `p2m_teardown_allocation`.
  
  - For dom0, P2M pages should come from heap directly instead of p2m
  pool, so that the kernel may take advantage of the extended regions.
  
  - For xl guests, the setting of the p2m pool is called in
  `XEN_DOMCTL_shadow_op` and the p2m pool is destroyed in
  `domain_relinquish_resources`. Note that domctl->u.shadow_op.mb is
  updated with the new size when setting the p2m pool.
  
  - For dom0less domUs, the setting of the p2m pool is called before
  allocating memory during domain creation. Users can specify the p2m
  pool size by `xen,domain-p2m-mem-mb` dts property.
  
  To actually allocate/free pages from the p2m pool, this commit adds
  two helper functions namely `p2m_alloc_page` and `p2m_free_page` to
  `struct p2m_domain`. By replacing the `alloc_domheap_page` and
  `free_domheap_page` with these two helper functions, p2m pages can
  be added/removed from the list of p2m pool rather than from the heap.
  
  Since page from `p2m_alloc_page` is cleaned, take the opportunity
  to remove the redundant `clean_page` in `p2m_create_table`.
  
  This is part of CVE-2022-33747 / XSA-409.
  
  Signed-off-by: Henry Wang 
  Reviewed-by: Stefano Stabellini 
  master commit: cbea5a1149ca7fd4b7cdbfa3ec2e4f109b601ff7
  master date: 2022-10-11 14:28:44 +0200


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.16-testing/test-armhf-armhf-xl-multivcpu.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.16-testing/test-armhf-armhf-xl-multivcpu.guest-start
 --summary-out=tmp/174207.bisection-summary --basis-template=172623 
--blessings=real,real-bisect,real-retry xen-4.16-testing 
test-armhf-armhf-xl-multivcpu guest-start
Searching for failure / basis pass:
 174070 fail [host=arndale-metrocentre] / 172623 [host=arndale-lakeside] 172548 
[host=arndale-westfield] 172130 ok.
Failure / basis pass flights: 174070 / 172130
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: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9d6915ca91519271a79bc6190a31f0af89e339b2 
107951211a8d17658e1aaa0c23a8cf29f8806ad8 
46de2eec93bffa0706e6229c0da2919763c8eb04 
1bce7fb1f702da4f7a749c6f1457ecb20bf74fca
Basis pass f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
0dc9b78a46813d61533b2bb0f7ef897a06a273be 
107951211a8d17658e1aaa0c23a8cf29f8806ad8 
46de2eec93bffa0706e6229c0da2919763c8eb04 
48b67651746f3124b0d5d30147180f1238d2e9c6
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#f0f0e602f7c9781699ecda9be763eac0b03d54f0-f0f0e602f7c9781699ecda9be763eac0b03d54f0
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#0dc9b78a46813d61533b2bb0f7ef897a06a273be-9d6915ca91519271a79bc6190a31f0af89e339b2
 git://xenbits.xen.org/qemu-xen.git#107951211a8d17658e1aaa0c23a8cf29f8806ad\
 8-107951211a8d17658e1aaa0c23a8cf29f8806ad8 
git://xenbits.xen.org/osstest/seabios.git#46de2eec93bffa0706e6229c0da2919763c8eb04-46de2eec93bffa0706e6229c0da2919763c8eb04
 
git://xenbits.xen.org/xen.git#48b67651746f3124b0d5d30147180f1238d2e9c6-1bce7fb1f702da4f7a749c6f1457ecb20bf74fca
Loaded 10001 nodes in revision graph
Searching for test results:
 173759 fail f0f0e602f7c9781699ecda9be763eac0b03d54f0 

[qemu-mainline test] 174155: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

flight 174155 qemu-mainline real [real]
flight 174206 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174155/
http://logs.test-lab.xenproject.org/osstest/logs/174206/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-vhd 21 guest-start/debian.repeat fail pass in 174206-retest
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 
174206-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174060
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 174060
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 174060
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 174060
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 174060
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-seattle   3 hosts-allocate   starved  n/a

version targeted for testing:
 qemuu0529245488865038344d64fff7ee05864d3d17f6
baseline version:
 qemuu214a8da23651f2472b296b3293e619fd58d9e212

Last test of basis   174060  2022-10-18 20:37:04 Z2 days
Testing same since   174155  2022-10-20 22:37:37 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Anders Roxell 
  Baruch Siach 
  Peter Maydell 
  Richard Henderson 
  Stefan Hajnoczi 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  starved 
 build-i386   

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

[osstest service owner]

flight 174201 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174201/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass

version targeted for testing:
 xen  73c62927f64ecb48f27d06176befdf76b879f340
baseline version:
 xen  f838b956779ff8a0b94636462f3c6d95c3adeb73

Last test of basis   174192  2022-10-21 10:00:58 Z0 days
Testing same since   174201  2022-10-21 13:00:27 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Roger Pau Monné 
  Stewart Hildebrand 
  Xenia Ragiadakou 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f838b95677..73c62927f6  73c62927f64ecb48f27d06176befdf76b879f340 -> smoke

[RFC PATCH v1 10/12] Arm: GICv3: Use ULL instead of UL for 64bits

[Ayan Kumar Halder]

"unsigned long long" is defined as 64 bits on AArch64 and AArch32
Thus, one should this instead of "unsigned long" which is 32 bits
on AArch32.

Also use 'PRIu64' instead of 'lx' to print uint64_t.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/gic-v3-its.c  | 20 ++--
 xen/arch/arm/gic-v3-lpi.c  |  8 
 xen/arch/arm/gic-v3.c  |  4 ++--
 xen/arch/arm/include/asm/gic_v3_defs.h |  2 +-
 xen/arch/arm/include/asm/gic_v3_its.h  |  2 +-
 xen/arch/arm/vgic-v3-its.c | 17 +
 6 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index e217c21bf8..dd056a3140 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -163,7 +163,7 @@ static int gicv3_its_wait_commands(struct host_its *hw_its)
 static uint64_t encode_rdbase(struct host_its *hw_its, unsigned int cpu,
   uint64_t reg)
 {
-reg &= ~GENMASK(51, 16);
+reg &= ~GENMASK_ULL(51, 16);
 
 reg |= gicv3_get_redist_address(cpu, hw_its->flags & HOST_ITS_USES_PTA);
 
@@ -219,7 +219,7 @@ static int its_send_cmd_mapd(struct host_its *its, uint32_t 
deviceid,
 {
 ASSERT(size_bits <= its->evid_bits);
 ASSERT(size_bits > 0);
-ASSERT(!(itt_addr & ~GENMASK(51, 8)));
+ASSERT(!(itt_addr & ~GENMASK_ULL(51, 8)));
 
 /* The number of events is encoded as "number of bits minus one". */
 size_bits--;
@@ -273,9 +273,9 @@ int gicv3_its_setup_collection(unsigned int cpu)
 
 #define BASER_ATTR_MASK   \
 ((0x3UL << GITS_BASER_SHAREABILITY_SHIFT)   | \
- (0x7UL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
- (0x7UL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
-#define BASER_RO_MASK   (GENMASK(58, 56) | GENMASK(52, 48))
+ (0x7ULL << GITS_BASER_OUTER_CACHEABILITY_SHIFT) | \
+ (0x7ULL << GITS_BASER_INNER_CACHEABILITY_SHIFT))
+#define BASER_RO_MASK   (GENMASK_ULL(58, 56) | GENMASK_ULL(52, 48))
 
 /* Check that the physical address can be encoded in the PROPBASER register. */
 static bool check_baser_phys_addr(void *vaddr, unsigned int page_bits)
@@ -287,13 +287,13 @@ static bool check_baser_phys_addr(void *vaddr, unsigned 
int page_bits)
 
 static uint64_t encode_baser_phys_addr(paddr_t addr, unsigned int page_bits)
 {
-uint64_t ret = addr & GENMASK(47, page_bits);
+uint64_t ret = addr & GENMASK_ULL(47, page_bits);
 
 if ( page_bits < 16 )
 return ret;
 
 /* For 64K pages address bits 51-48 are encoded in bits 15-12. */
-return ret | ((addr & GENMASK(51, 48)) >> (48 - 12));
+return ret | ((addr & GENMASK_ULL(51, 48)) >> (48 - 12));
 }
 
 static void *its_map_cbaser(struct host_its *its)
@@ -310,7 +310,7 @@ static void *its_map_cbaser(struct host_its *its)
 if ( !buffer )
 return NULL;
 
-if ( virt_to_maddr(buffer) & ~GENMASK(51, 12) )
+if ( virt_to_maddr(buffer) & ~GENMASK_ULL(51, 12) )
 {
 xfree(buffer);
 return NULL;
@@ -446,7 +446,7 @@ static int gicv3_disable_its(struct host_its *hw_its)
 udelay(1);
 } while ( NOW() <= deadline );
 
-printk(XENLOG_ERR "ITS@%lx not quiescent.\n", hw_its->addr);
+printk(XENLOG_ERR "ITS@%" PRIu64 " not quiescent.\n", hw_its->addr);
 
 return -ETIMEDOUT;
 }
@@ -999,7 +999,7 @@ static void add_to_host_its_list(paddr_t addr, paddr_t size,
 its_data->size = size;
 its_data->dt_node = node;
 
-printk("GICv3: Found ITS @0x%lx\n", addr);
+printk("GICv3: Found ITS 0x%" PRIu64 "\n", addr);
 
 list_add_tail(_data->entry, _its_list);
 }
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 61d90eb386..9ca74bc321 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -134,7 +134,7 @@ void gicv3_set_redist_address(paddr_t address, unsigned int 
redist_id)
 uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
 {
 if ( use_pta )
-return per_cpu(lpi_redist, cpu).redist_addr & GENMASK(51, 16);
+return per_cpu(lpi_redist, cpu).redist_addr & GENMASK_ULL(51, 16);
 else
 return per_cpu(lpi_redist, cpu).redist_id << 16;
 }
@@ -253,7 +253,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
 return -ENOMEM;
 
 /* Make sure the physical address can be encoded in the register. */
-if ( virt_to_maddr(pendtable) & ~GENMASK(51, 16) )
+if ( virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16) )
 {
 xfree(pendtable);
 return -ERANGE;
@@ -281,7 +281,7 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
 return -ENOMEM;
 }
 
-ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
+ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK_ULL(51, 16)));
 
 val  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
 val |= 

[RFC PATCH v1 12/12] Arm: GICv3: Enable GICv3 for AArch32

[Ayan Kumar Halder]

Refer ARM DDI 0487G.b ID072021,
D13.2.86 -
ID_PFR1_EL1, AArch32 Processor Feature Register 1

GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32

One can now enable GICv3 on AArch32 systems.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/Kconfig  | 2 +-
 xen/arch/arm/include/asm/cpufeature.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 1fe5faf847..5eaf21b8e0 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -41,7 +41,7 @@ config ARM_EFI
 
 config GICV3
bool "GICv3 driver"
-   depends on ARM_64 && !NEW_VGIC
+   depends on (ARM_64 || ARM_32) && !NEW_VGIC
default y
---help---
 
diff --git a/xen/arch/arm/include/asm/cpufeature.h 
b/xen/arch/arm/include/asm/cpufeature.h
index c86a2e7f29..c8ca09d1c3 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -31,6 +31,7 @@
 #define cpu_has_jazelle   (boot_cpu_feature32(jazelle) > 0)
 #define cpu_has_thumbee   (boot_cpu_feature32(thumbee) == 1)
 #define cpu_has_aarch32   (cpu_has_arm || cpu_has_thumb)
+#define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1)
 
 #ifdef CONFIG_ARM_32
 #define cpu_has_gentimer  (boot_cpu_feature32(gentimer) == 1)
-- 
2.17.1

[RFC PATCH v1 08/12] Arm: GICv3: Define ICH_AP0R and ICH_AP1R for AArch32

[Ayan Kumar Halder]

Refer "Arm IHI 0069H ID020922",
12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/arm32/sysregs.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h 
b/xen/arch/arm/include/asm/arm32/sysregs.h
index f3b4dfbca8..693da22324 100644
--- a/xen/arch/arm/include/asm/arm32/sysregs.h
+++ b/xen/arch/arm/include/asm/arm32/sysregs.h
@@ -117,6 +117,18 @@
 #define ICH_LRC14_EL2  __LRC8_EL2(6)
 #define ICH_LRC15_EL2  __LRC8_EL2(7)
 
+#define __AP0Rx_EL2(x)___CP32(p15,4,c12,c8,x)
+#define ICH_AP0R0_EL2 __AP0Rx_EL2(0)
+#define ICH_AP0R1_EL2 __AP0Rx_EL2(1)
+#define ICH_AP0R2_EL2 __AP0Rx_EL2(2)
+#define ICH_AP0R3_EL2 __AP0Rx_EL2(3)
+
+#define __AP1Rx_EL2(x)___CP32(p15,4,c12,c9,x)
+#define ICH_AP1R0_EL2 __AP1Rx_EL2(0)
+#define ICH_AP1R1_EL2 __AP1Rx_EL2(1)
+#define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
+#define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM32_SYSREGS_H */
-- 
2.17.1

[RFC PATCH v1 11/12] Arm: GICv3: Define macros to read/write 64 bit

[Ayan Kumar Halder]

Defined readq_relaxed()/writeq_relaxed() to read and write 64 bit regs.
This in turn calls readl_relaxed()/writel_relaxed() twice for the lower
and upper 32 bits.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/arm32/io.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/include/asm/arm32/io.h 
b/xen/arch/arm/include/asm/arm32/io.h
index 73a879e9fb..6a5f563fbc 100644
--- a/xen/arch/arm/include/asm/arm32/io.h
+++ b/xen/arch/arm/include/asm/arm32/io.h
@@ -80,10 +80,14 @@ static inline u32 __raw_readl(const volatile void __iomem 
*addr)
 __raw_readw(c)); __r; })
 #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
 __raw_readl(c)); __r; })
+#define readq_relaxed(c) ({ u64 __r = (le64_to_cpu(readl_relaxed(c+4)) << 32) 
| \
+readl_relaxed(c); __r; })
 
 #define writeb_relaxed(v,c) __raw_writeb(v,c)
 #define writew_relaxed(v,c) __raw_writew((__force u16) cpu_to_le16(v),c)
 #define writel_relaxed(v,c) __raw_writel((__force u32) cpu_to_le32(v),c)
+#define writeq_relaxed(v,c) writel_relaxed(((uint64_t)v&0x), c); \
+writel_relaxeduint64_t)v)>>32), (c+4));
 
 #define readb(c)({ u8  __v = readb_relaxed(c); __iormb(); __v; 
})
 #define readw(c)({ u16 __v = readw_relaxed(c); __iormb(); __v; 
})
-- 
2.17.1

[RFC PATCH v1 09/12] Arm: GICv3: Define GIC registers for AArch32

[Ayan Kumar Halder]

Refer "Arm IHI 0069H ID020922"
12.5.23 ICC_SGI1R, Interrupt Controller Software Generated Interrupt
Group 1 Register
12.5.12 ICC_HSRE, Interrupt Controller Hyp System Register Enable register
12.7.10 ICH_VTR, Interrupt Controller VGIC Type Register
12.7.5 ICH_HCR, Interrupt Controller Hyp Control Register
12.5.20 ICC_PMR, Interrupt Controller Interrupt Priority Mask Register
12.5.24 ICC_SRE, Interrupt Controller System Register Enable register
12.5.7 ICC_DIR, Interrupt Controller Deactivate Interrupt Register
12.5.9 ICC_EOIR1, Interrupt Controller End Of Interrupt Register 1
12.5.14 ICC_IAR1, Interrupt Controller Interrupt Acknowledge Register 1
12.5.5 ICC_BPR1, Interrupt Controller Binary Point Register 1
12.5.6 ICC_CTLR, Interrupt Controller Control Register
12.5.16 ICC_IGRPEN1, Interrupt Controller Interrupt Group 1 Enable register
12.7.9 ICH_VMCR, Interrupt Controller Virtual Machine Control Register

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/arm32/sysregs.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h 
b/xen/arch/arm/include/asm/arm32/sysregs.h
index 693da22324..d2c5a115f9 100644
--- a/xen/arch/arm/include/asm/arm32/sysregs.h
+++ b/xen/arch/arm/include/asm/arm32/sysregs.h
@@ -129,6 +129,22 @@
 #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
 #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
 
+#define ICC_SGI1R_EL1 p15,0,c12
+
+#define ICC_SRE_EL2   p15,4,c12,c9,5
+#define ICH_VTR_EL2   p15,4,c12,c11,1
+#define ICH_HCR_EL2   p15,4,c12,c11,0
+
+#define ICC_PMR_EL1   p15,0,c4,c6,0
+#define ICC_SRE_EL1   p15,0,c12,c12,5
+#define ICC_DIR_EL1   p15,0,c12,c11,1
+#define ICC_EOIR1_EL1 p15,0,c12,c12,1
+#define ICC_IAR1_EL1  p15,0,c12,c12,0
+#define ICC_BPR1_EL1  p15,0,c12,c12,3
+#define ICC_CTLR_EL1  p15,0,c12,c12,4
+#define ICC_IGRPEN1_EL1   p15,0,c12,c12,7
+#define ICH_VMCR_EL2  p15,4,c12,c11,7
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM32_SYSREGS_H */
-- 
2.17.1

[RFC PATCH v1 07/12] Arm: GICv3: Emulate ICH_LR_EL2 on AArch32

[Ayan Kumar Halder]

Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers

AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR[31:0].
AArch64 System register ICH_LR_EL2 bits [63:32] are architecturally
mapped to AArch32 System register ICH_LRC[31:0].

Defined ICH_LR<0...15>_EL2 and ICH_LRC<0...15>_EL2 for Aarch32.
For AArch32, the link register is stored as :-
(((uint64_t) ICH_LRC<0...15>_EL2) << 32) | ICH_LR<0...15>_EL2

Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
AArch64.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/gic-v3.c| 132 +++
 xen/arch/arm/include/asm/arm32/sysregs.h |  52 +
 xen/arch/arm/include/asm/arm64/sysregs.h |   7 +-
 xen/arch/arm/include/asm/gic_v3_defs.h   |   6 +-
 4 files changed, 126 insertions(+), 71 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 018fa0dfa0..8b4b168e78 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -73,37 +73,37 @@ static inline void gicv3_save_lrs(struct vcpu *v)
 switch ( gicv3_info.nr_lrs )
 {
 case 16:
-v->arch.gic.v3.lr[15] = READ_SYSREG(ICH_LR15_EL2);
+v->arch.gic.v3.lr[15] = READ_SYSREG_LR(15);
 case 15:
-v->arch.gic.v3.lr[14] = READ_SYSREG(ICH_LR14_EL2);
+v->arch.gic.v3.lr[14] = READ_SYSREG_LR(14);
 case 14:
-v->arch.gic.v3.lr[13] = READ_SYSREG(ICH_LR13_EL2);
+v->arch.gic.v3.lr[13] = READ_SYSREG_LR(13);
 case 13:
-v->arch.gic.v3.lr[12] = READ_SYSREG(ICH_LR12_EL2);
+v->arch.gic.v3.lr[12] = READ_SYSREG_LR(12);
 case 12:
-v->arch.gic.v3.lr[11] = READ_SYSREG(ICH_LR11_EL2);
+v->arch.gic.v3.lr[11] = READ_SYSREG_LR(11);
 case 11:
-v->arch.gic.v3.lr[10] = READ_SYSREG(ICH_LR10_EL2);
+v->arch.gic.v3.lr[10] = READ_SYSREG_LR(10);
 case 10:
-v->arch.gic.v3.lr[9] = READ_SYSREG(ICH_LR9_EL2);
+v->arch.gic.v3.lr[9] = READ_SYSREG_LR(9);
 case 9:
-v->arch.gic.v3.lr[8] = READ_SYSREG(ICH_LR8_EL2);
+v->arch.gic.v3.lr[8] = READ_SYSREG_LR(8);
 case 8:
-v->arch.gic.v3.lr[7] = READ_SYSREG(ICH_LR7_EL2);
+v->arch.gic.v3.lr[7] = READ_SYSREG_LR(7);
 case 7:
-v->arch.gic.v3.lr[6] = READ_SYSREG(ICH_LR6_EL2);
+v->arch.gic.v3.lr[6] = READ_SYSREG_LR(6);
 case 6:
-v->arch.gic.v3.lr[5] = READ_SYSREG(ICH_LR5_EL2);
+v->arch.gic.v3.lr[5] = READ_SYSREG_LR(5);
 case 5:
-v->arch.gic.v3.lr[4] = READ_SYSREG(ICH_LR4_EL2);
+v->arch.gic.v3.lr[4] = READ_SYSREG_LR(4);
 case 4:
-v->arch.gic.v3.lr[3] = READ_SYSREG(ICH_LR3_EL2);
+v->arch.gic.v3.lr[3] = READ_SYSREG_LR(3);
 case 3:
-v->arch.gic.v3.lr[2] = READ_SYSREG(ICH_LR2_EL2);
+v->arch.gic.v3.lr[2] = READ_SYSREG_LR(2);
 case 2:
-v->arch.gic.v3.lr[1] = READ_SYSREG(ICH_LR1_EL2);
+v->arch.gic.v3.lr[1] = READ_SYSREG_LR(1);
 case 1:
- v->arch.gic.v3.lr[0] = READ_SYSREG(ICH_LR0_EL2);
+ v->arch.gic.v3.lr[0] = READ_SYSREG_LR(0);
  break;
 default:
  BUG();
@@ -120,37 +120,37 @@ static inline void gicv3_restore_lrs(const struct vcpu *v)
 switch ( gicv3_info.nr_lrs )
 {
 case 16:
-WRITE_SYSREG(v->arch.gic.v3.lr[15], ICH_LR15_EL2);
+WRITE_SYSREG_LR(15, v->arch.gic.v3.lr[15]);
 case 15:
-WRITE_SYSREG(v->arch.gic.v3.lr[14], ICH_LR14_EL2);
+WRITE_SYSREG_LR(14, v->arch.gic.v3.lr[14]);
 case 14:
-WRITE_SYSREG(v->arch.gic.v3.lr[13], ICH_LR13_EL2);
+WRITE_SYSREG_LR(13, v->arch.gic.v3.lr[13]);
 case 13:
-WRITE_SYSREG(v->arch.gic.v3.lr[12], ICH_LR12_EL2);
+WRITE_SYSREG_LR(12, v->arch.gic.v3.lr[12]);
 case 12:
-WRITE_SYSREG(v->arch.gic.v3.lr[11], ICH_LR11_EL2);
+WRITE_SYSREG_LR(11, v->arch.gic.v3.lr[11]);
 case 11:
-WRITE_SYSREG(v->arch.gic.v3.lr[10], ICH_LR10_EL2);
+WRITE_SYSREG_LR(10, v->arch.gic.v3.lr[10]);
 case 10:
-WRITE_SYSREG(v->arch.gic.v3.lr[9], ICH_LR9_EL2);
+WRITE_SYSREG_LR(9, v->arch.gic.v3.lr[9]);
 case 9:
-WRITE_SYSREG(v->arch.gic.v3.lr[8], ICH_LR8_EL2);
+WRITE_SYSREG_LR(8, v->arch.gic.v3.lr[8]);
 case 8:
-WRITE_SYSREG(v->arch.gic.v3.lr[7], ICH_LR7_EL2);
+WRITE_SYSREG_LR(7, v->arch.gic.v3.lr[7]);
 case 7:
-WRITE_SYSREG(v->arch.gic.v3.lr[6], ICH_LR6_EL2);
+WRITE_SYSREG_LR(6, v->arch.gic.v3.lr[6]);
 case 6:
-WRITE_SYSREG(v->arch.gic.v3.lr[5], ICH_LR5_EL2);
+WRITE_SYSREG_LR(5, v->arch.gic.v3.lr[5]);
 case 5:
-WRITE_SYSREG(v->arch.gic.v3.lr[4], ICH_LR4_EL2);
+WRITE_SYSREG_LR(4, v->arch.gic.v3.lr[4]);
 case 4:
-WRITE_SYSREG(v->arch.gic.v3.lr[3], ICH_LR3_EL2);
+WRITE_SYSREG_LR(3, v->arch.gic.v3.lr[3]);
 case 3:
-WRITE_SYSREG(v->arch.gic.v3.lr[2], ICH_LR2_EL2);
+ 

[RFC PATCH v1 05/12] Arm: GICv3: Emulate GICR_PENDBASER and GICR_PROPBASER on AArch32

[Ayan Kumar Halder]

'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/gic_v3_defs.h | 16 
 xen/arch/arm/vgic-v3.c |  6 --
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h 
b/xen/arch/arm/include/asm/gic_v3_defs.h
index 728e28d5e5..48a1bc401e 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -134,15 +134,15 @@
 
 #define GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT 56
 #define GICR_PROPBASER_OUTER_CACHEABILITY_MASK   \
-(7UL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
+(7ULL << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT)
 #define GICR_PROPBASER_SHAREABILITY_SHIFT   10
 #define GICR_PROPBASER_SHAREABILITY_MASK \
-(3UL << GICR_PROPBASER_SHAREABILITY_SHIFT)
+(3ULL << GICR_PROPBASER_SHAREABILITY_SHIFT)
 #define GICR_PROPBASER_INNER_CACHEABILITY_SHIFT 7
 #define GICR_PROPBASER_INNER_CACHEABILITY_MASK   \
-(7UL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
+(7ULL << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT)
 #define GICR_PROPBASER_RES0_MASK \
-(GENMASK(63, 59) | GENMASK(55, 52) | GENMASK(6, 5))
+(GENMASK_ULL(63, 59) | GENMASK_ULL(55, 52) | GENMASK_ULL(6, 5))
 
 #define GICR_PENDBASER_SHAREABILITY_SHIFT   10
 #define GICR_PENDBASER_INNER_CACHEABILITY_SHIFT 7
@@ -152,11 +152,11 @@
 #define GICR_PENDBASER_INNER_CACHEABILITY_MASK   \
(7UL << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT)
 #define GICR_PENDBASER_OUTER_CACHEABILITY_MASK   \
-(7UL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
-#define GICR_PENDBASER_PTZ  BIT(62, UL)
+(7ULL << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT)
+#define GICR_PENDBASER_PTZ  BIT(62, ULL)
 #define GICR_PENDBASER_RES0_MASK \
-(BIT(63, UL) | GENMASK(61, 59) | GENMASK(55, 52) |  \
- GENMASK(15, 12) | GENMASK(6, 0))
+(BIT(63, ULL) | GENMASK_ULL(61, 59) | GENMASK_ULL(55, 52) |  \
+ GENMASK_ULL(15, 12) | GENMASK_ULL(6, 0))
 
 #define DEFAULT_PMR_VALUE0xff
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d86b41a39f..9f31360f56 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -254,14 +254,16 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 case VREG64(GICR_PENDBASER):
 {
 unsigned long flags;
+uint64_t value;
 
 if ( !v->domain->arch.vgic.has_its )
 goto read_as_zero_64;
 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
-*r = vreg_reg64_extract(v->arch.vgic.rdist_pendbase, info);
-*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+value = v->arch.vgic.rdist_pendbase;
+value &= ~GICR_PENDBASER_PTZ;/* WO, reads as 0 */
+*r = vreg_reg64_extract(value, info);
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
 return 1;
 }
-- 
2.17.1

[RFC PATCH v1 04/12] Arm: GICv3: Emulate GICR_TYPER on AArch32

[Ayan Kumar Halder]

Refer Arm IHI 0069H ID020922,
The upper 32 bits of GICR_TYPER represent the affinity
whereas the lower 32 bits represent the other bits (eg processor
number, etc).
MPIDR_AFFINITY_LEVEL() returns a 32 bit number on aarch32. Thus, this
is appended to return GICR_TYPER register.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/vgic-v3.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c31140eb20..d86b41a39f 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -190,14 +190,18 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 
 case VREG64(GICR_TYPER):
 {
-uint64_t typer, aff;
+uint64_t typer;
+uint32_t aff;
 
 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
-   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
+aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 24 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 16 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 8 |
+   MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0));
 typer = aff;
+
+typer = typer << 32;
+
 /* We use the VCPU ID as the redistributor ID in bits[23:8] */
 typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
 
-- 
2.17.1

[RFC PATCH v1 06/12] Arm: GICv3: Emulate of ICC_SGI1R on AArch32

[Ayan Kumar Halder]

Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
Aarch32 systems. Thus, the prototype needs to change to reflect this.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/vgic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 9f31360f56..48e8ef95d2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1482,7 +1482,7 @@ write_reserved:
 return 1;
 }
 
-static bool vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
+static bool vgic_v3_to_sgi(struct vcpu *v, uint64_t sgir)
 {
 int virq;
 int irqmode;
-- 
2.17.1

[RFC PATCH v1 03/12] Arm: GICv3: Enable vreg_reg64_* macros for AArch32

[Ayan Kumar Halder]

In some situations (eg GICR_TYPER), the hypervior may need to emulate
64bit registers in aarch32 mode. In such situations, the hypervisor may
need to read/modify the lower or upper 32 bits of the 64 bit register.

In aarch32, 64 bit is represented by unsigned long long. Thus, we need
to change the prototype accordingly.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/vreg.h | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
index f26a70d024..ac6e702c5c 100644
--- a/xen/arch/arm/include/asm/vreg.h
+++ b/xen/arch/arm/include/asm/vreg.h
@@ -95,7 +95,7 @@ static inline bool vreg_emulate_sysreg(struct cpu_user_regs 
*regs, union hsr hsr
  * Note that the alignment fault will always be taken in the guest
  * (see B3.12.7 DDI0406.b).
  */
-static inline register_t vreg_reg_extract(unsigned long reg,
+static inline register_t vreg_reg_extract(unsigned long long reg,
   unsigned int offset,
   enum dabt_size size)
 {
@@ -105,7 +105,7 @@ static inline register_t vreg_reg_extract(unsigned long reg,
 return reg;
 }
 
-static inline void vreg_reg_update(unsigned long *reg, register_t val,
+static inline void vreg_reg_update(unsigned long long *reg, register_t val,
unsigned int offset,
enum dabt_size size)
 {
@@ -116,7 +116,7 @@ static inline void vreg_reg_update(unsigned long *reg, 
register_t val,
 *reg |= ((unsigned long)val & mask) << shift;
 }
 
-static inline void vreg_reg_setbits(unsigned long *reg, register_t bits,
+static inline void vreg_reg_setbits(unsigned long long *reg, register_t bits,
 unsigned int offset,
 enum dabt_size size)
 {
@@ -126,7 +126,7 @@ static inline void vreg_reg_setbits(unsigned long *reg, 
register_t bits,
 *reg |= ((unsigned long)bits & mask) << shift;
 }
 
-static inline void vreg_reg_clearbits(unsigned long *reg, register_t bits,
+static inline void vreg_reg_clearbits(unsigned long long *reg, register_t bits,
   unsigned int offset,
   enum dabt_size size)
 {
@@ -149,7 +149,7 @@ static inline void vreg_reg##sz##_update(uint##sz##_t *reg, 
\
  register_t val,\
  const mmio_info_t *info)   \
 {   \
-unsigned long tmp = *reg;   \
+unsigned long long tmp = *reg;  \
 \
 vreg_reg_update(, val, info->gpa & (offmask),   \
 info->dabt.size);   \
@@ -161,7 +161,7 @@ static inline void vreg_reg##sz##_setbits(uint##sz##_t 
*reg,\
   register_t bits,  \
   const mmio_info_t *info)  \
 {   \
-unsigned long tmp = *reg;   \
+unsigned long long tmp = *reg;  \
 \
 vreg_reg_setbits(, bits, info->gpa & (offmask), \
  info->dabt.size);  \
@@ -173,7 +173,7 @@ static inline void vreg_reg##sz##_clearbits(uint##sz##_t 
*reg,  \
 register_t bits,\
 const mmio_info_t *info)\
 {   \
-unsigned long tmp = *reg;   \
+unsigned long long tmp = *reg;  \
 \
 vreg_reg_clearbits(, bits, info->gpa & (offmask),   \
info->dabt.size);\
@@ -181,15 +181,8 @@ static inline void vreg_reg##sz##_clearbits(uint##sz##_t 
*reg,  \
 *reg = tmp; \
 }
 
-/*
- * 64 bits registers are only supported on platform with 64-bit long.
- * This is also allow us to optimize the 32 bit case by using
- * unsigned long rather than uint64_t
- */
-#if BITS_PER_LONG == 64
-VREG_REG_HELPERS(64, 0x7);
-#endif
 VREG_REG_HELPERS(32, 0x3);
+VREG_REG_HELPERS(64, 0x7);
 
 #undef VREG_REG_HELPERS
 
-- 
2.17.1

[RFC PATCH v1 00/12] Arm: Enable GICv3 for AArch32

[Ayan Kumar Halder]

Hi All,

Please find the following patches to enable GICv3 for AArch32.
This is a pre-requisite to support Xen on Cortex-R52 (AArch32-v8R system)

Let me know your thoughts.

Ayan Kumar Halder (12):
  Arm: GICv3: Sysreg emulation is applicable for Aarch64 only
  Arm: GICv3: Move the macros to compute the affnity level to
arm64/arm32
  Arm: GICv3: Enable vreg_reg64_* macros for AArch32
  Arm: GICv3: Emulate GICR_TYPER on AArch32
  Arm: GICv3: Emulate GICR_PENDBASER and GICR_PROPBASER on AArch32
  Arm: GICv3: Emulate of ICC_SGI1R on AArch32
  Arm: GICv3: Emulate ICH_LR_EL2 on AArch32
  Arm: GICv3: Define ICH_AP0R and ICH_AP1R for AArch32
  Arm: GICv3: Define GIC registers for AArch32
  Arm: GICv3: Use ULL instead of UL for 64bits
  Arm: GICv3: Define macros to read/write 64 bit
  Arm: GICv3: Enable GICv3 for AArch32

 xen/arch/arm/Kconfig   |   2 +-
 xen/arch/arm/gic-v3-its.c  |  20 ++--
 xen/arch/arm/gic-v3-lpi.c  |   8 +-
 xen/arch/arm/gic-v3.c  | 132 ++---
 xen/arch/arm/include/asm/arm32/io.h|   4 +
 xen/arch/arm/include/asm/arm32/processor.h |  10 ++
 xen/arch/arm/include/asm/arm32/sysregs.h   |  80 +
 xen/arch/arm/include/asm/arm64/processor.h |  13 ++
 xen/arch/arm/include/asm/arm64/sysregs.h   |   7 +-
 xen/arch/arm/include/asm/cpufeature.h  |   1 +
 xen/arch/arm/include/asm/gic_v3_defs.h |  24 ++--
 xen/arch/arm/include/asm/gic_v3_its.h  |   2 +-
 xen/arch/arm/include/asm/processor.h   |  14 ---
 xen/arch/arm/include/asm/vreg.h|  23 ++--
 xen/arch/arm/vgic-v3-its.c |  17 +--
 xen/arch/arm/vgic-v3.c |  26 ++--
 16 files changed, 242 insertions(+), 141 deletions(-)

-- 
2.17.1

[RFC PATCH v1 01/12] Arm: GICv3: Sysreg emulation is applicable for Aarch64 only

[Ayan Kumar Halder]

Refer ARM DDI 0487G.b ID072021, EC==0b011000 is supported for Aarch64 state
only. This is when MSR, MRS, System instruction execution in AArch64 state
is trapped, that is not reported using EC 0b00, 0b01 or 0b000111.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/vgic-v3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 0c23f6df9d..c31140eb20 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1520,6 +1520,7 @@ static bool vgic_v3_emulate_sgi1r(struct cpu_user_regs 
*regs, uint64_t *r,
 }
 }
 
+#ifdef CONFIG_ARM_64
 static bool vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
 {
 struct hsr_sysreg sysreg = hsr.sysreg;
@@ -1540,6 +1541,7 @@ static bool vgic_v3_emulate_sysreg(struct cpu_user_regs 
*regs, union hsr hsr)
 return false;
 }
 }
+#endif
 
 static bool vgic_v3_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
 {
@@ -1563,8 +1565,10 @@ static bool vgic_v3_emulate_reg(struct cpu_user_regs 
*regs, union hsr hsr)
 {
 switch (hsr.ec)
 {
+#ifdef CONFIG_ARM_64
 case HSR_EC_SYSREG:
 return vgic_v3_emulate_sysreg(regs, hsr);
+#endif
 case HSR_EC_CP15_64:
 return vgic_v3_emulate_cp64(regs, hsr);
 default:
-- 
2.17.1

[RFC PATCH v1 02/12] Arm: GICv3: Move the macros to compute the affnity level to arm64/arm32

[Ayan Kumar Halder]

Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#L14 , these macros are specific for arm64.

When one computes MPIDR_LEVEL_SHIFT(3), it crosses the width of a 32
bit register.

Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm/include/ \
asm/cputype.h#L54  , these macros are specific for arm32.

Signed-off-by: Ayan Kumar Halder 
---
 xen/arch/arm/include/asm/arm32/processor.h | 10 ++
 xen/arch/arm/include/asm/arm64/processor.h | 13 +
 xen/arch/arm/include/asm/processor.h   | 14 --
 3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm32/processor.h 
b/xen/arch/arm/include/asm/arm32/processor.h
index 4e679f3273..3e03ce78dc 100644
--- a/xen/arch/arm/include/asm/arm32/processor.h
+++ b/xen/arch/arm/include/asm/arm32/processor.h
@@ -56,6 +56,16 @@ struct cpu_user_regs
 uint32_t pad1; /* Doubleword-align the user half of the frame */
 };
 
+/*
+ * Macros to extract affinity level. Picked from kernel
+ */
+
+#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
+#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+((mpidr >> (MPIDR_LEVEL_BITS * level)) & MPIDR_LEVEL_MASK)
+
 #endif
 
 #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/arch/arm/include/asm/arm64/processor.h 
b/xen/arch/arm/include/asm/arm64/processor.h
index c749f80ad9..c026334eec 100644
--- a/xen/arch/arm/include/asm/arm64/processor.h
+++ b/xen/arch/arm/include/asm/arm64/processor.h
@@ -84,6 +84,19 @@ struct cpu_user_regs
 uint64_t sp_el1, elr_el1;
 };
 
+/*
+ * Macros to extract affinity level. picked from kernel
+ */
+
+#define MPIDR_LEVEL_BITS_SHIFT  3
+#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_LEVEL_SHIFT(level) \
+ (((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+ ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
+
 #undef __DECL_REG
 
 #endif /* __ASSEMBLY__ */
diff --git a/xen/arch/arm/include/asm/processor.h 
b/xen/arch/arm/include/asm/processor.h
index 1dd81d7d52..7d90c3b5f2 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -118,20 +118,6 @@
 #define MPIDR_INVALID   (~MPIDR_HWID_MASK)
 #define MPIDR_LEVEL_BITS(8)
 
-
-/*
- * Macros to extract affinity level. picked from kernel
- */
-
-#define MPIDR_LEVEL_BITS_SHIFT  3
-#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
-
-#define MPIDR_LEVEL_SHIFT(level) \
- (((1 << (level)) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
-
-#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
- (((mpidr) >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
-
 #define AFFINITY_MASK(level)~((_AC(0x1,UL) << MPIDR_LEVEL_SHIFT(level)) - 
1)
 
 /* TTBCR Translation Table Base Control Register */
-- 
2.17.1

Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM

[Bertrand Marquis]

Hi,

> On 21 Oct 2022, at 15:40, Henry Wang  wrote:
> 
> (+ Arm maintainers)
> 
> Hi Oleksandr,
> 
>> -Original Message-
>> From: Oleksandr 
>> Subject: Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM
>> Hello all.
>> On 19.07.22 13:40, Jan Beulich wrote:
>>> On 19.07.2022 12:32, Volodymyr Babchuk wrote:
 Jan Beulich  writes:
 
> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>> iounmap(), but not added corresponding include.
>> 
>> Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
> I don't think there's any active issue with the "missing" include:
> That's only a problem once Arm has vPCI code enabled? In which
> case I don't think a Fixes: tag is warranted.
 Fair enough. May I ask committer to drop this tag?
>>> I had taken respective note already, in case I end up committing this.
>>> But this is the last patch of the series, so I can only guess whether
>>> it might be okay to go in ahead of the other three patches.
>>> 
>>> Jan
>> 
>> 
>> I am wondering, where this patch could be 4.17 material?
>> 
>> The patch series seem to get stuck, but the current patch just adds a
>> missing include to fix a build on Arm, so it is completely independent.
>> I agree, there is no issue with the current code base as vPCI is
>> disabled on Arm, so nothing to fix right now. But as PCI
>> passthrough/vPCI on Arm is in the development stage, the developers
>> enable that support in their builds. I think the risk is rather low than
>> high.
> 
> It seems reasonable to me, but I am curious about what Arm maintainers
> and PCI maintainers think. From the history discussion in this thread I
> think it is pretty safe to include this in 4.17. Thanks for the ping.

I think this can safely go in for 4.17.

Cheers
Bertrand

> 
> Kind regards,
> Henry
> 
> 
>> 
>> 
>> 
>> --
>> Regards,
>> 
>> Oleksandr Tyshchenko

[PATCH-for-4.17] xen/sched: migrate timers to correct cpus after suspend

[Juergen Gross]

Today all timers are migrated to cpu 0 when the system is being
suspended. They are not migrated back after resuming the system again.

This results (at least) to problems with the credit scheduler, as the
timer isn't handled on the cpu it was expected to occur.

Add migrating the scheduling related timers of a specific cpu from cpu
0 back to its original cpu when that cpu has gone up when resuming the
system.

Signed-off-by: Juergen Gross 
---
This is an alternative approach to this one:
https://lists.xen.org/archives/html/xen-devel/2022-09/msg00510.html
---
 xen/common/sched/core.c| 23 +++
 xen/common/sched/cpupool.c |  2 ++
 xen/common/sched/credit.c  | 13 +
 xen/common/sched/private.h | 10 +++
 xen/common/sched/rt.c  | 58 ++
 5 files changed, 88 insertions(+), 18 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 23fa6845a8..142d03ade5 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1284,6 +1284,29 @@ static int cpu_disable_scheduler_check(unsigned int cpu)
 return 0;
 }
 
+/*
+ * Called after a cpu has come up again in a suspend/resume cycle.
+ * Migrate all timers for this cpu (they have been migrated to cpu 0 when the
+ * cpu was going down).
+ * Note that only timers related to a physical cpu are migrated, not the ones
+ * related to a vcpu or domain.
+ */
+void sched_migrate_timers(unsigned int cpu)
+{
+struct sched_resource *sr;
+
+rcu_read_lock(_res_rculock);
+
+sr = get_sched_res(cpu);
+if ( sr->master_cpu == cpu )
+{
+migrate_timer(>s_timer, cpu);
+sched_move_timers(sr->scheduler, sr);
+}
+
+rcu_read_unlock(_res_rculock);
+}
+
 /*
  * In general, this must be called with the scheduler lock held, because the
  * adjust_affinity hook may want to modify the vCPU state. However, when the
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index b2c6f520c3..bdf6030ab0 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -1035,6 +1035,8 @@ static int cf_check cpu_callback(
 case CPU_ONLINE:
 if ( system_state <= SYS_STATE_active )
 rc = cpupool_cpu_add(cpu);
+else
+sched_migrate_timers(cpu);
 break;
 case CPU_DOWN_PREPARE:
 /* Suspend/Resume don't change assignments of cpus to cpupools. */
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 47945c2834..f2cd3d9da3 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -614,6 +614,18 @@ init_pdata(struct csched_private *prv, struct csched_pcpu 
*spc, int cpu)
 spc->nr_runnable = 0;
 }
 
+static void cf_check
+csched_move_timers(const struct scheduler *ops, struct sched_resource *sr)
+{
+struct csched_private *prv = CSCHED_PRIV(ops);
+struct csched_pcpu *spc = sr->sched_priv;
+
+if ( sr->master_cpu == prv->master )
+migrate_timer(>master_ticker, prv->master);
+
+migrate_timer(>ticker, sr->master_cpu);
+}
+
 /* Change the scheduler of cpu to us (Credit). */
 static spinlock_t *cf_check
 csched_switch_sched(struct scheduler *new_ops, unsigned int cpu,
@@ -2264,6 +2276,7 @@ static const struct scheduler sched_credit_def = {
 .switch_sched   = csched_switch_sched,
 .alloc_domdata  = csched_alloc_domdata,
 .free_domdata   = csched_free_domdata,
+.move_timers= csched_move_timers,
 };
 
 REGISTER_SCHEDULER(sched_credit_def);
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 0126a4bb9e..0527a8c70d 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -331,6 +331,8 @@ struct scheduler {
 struct xen_sysctl_scheduler_op *);
 void (*dump_settings)  (const struct scheduler *);
 void (*dump_cpu_state) (const struct scheduler *, int);
+void (*move_timers)(const struct scheduler *,
+struct sched_resource *);
 };
 
 static inline int sched_init(struct scheduler *s)
@@ -485,6 +487,13 @@ static inline int sched_adjust_cpupool(const struct 
scheduler *s,
 return s->adjust_global ? s->adjust_global(s, op) : 0;
 }
 
+static inline void sched_move_timers(const struct scheduler *s,
+ struct sched_resource *sr)
+{
+if ( s->move_timers )
+s->move_timers(s, sr);
+}
+
 static inline void sched_unit_pause_nosync(const struct sched_unit *unit)
 {
 struct vcpu *v;
@@ -622,6 +631,7 @@ struct cpu_rm_data *alloc_cpu_rm_data(unsigned int cpu, 
bool aff_alloc);
 void free_cpu_rm_data(struct cpu_rm_data *mem, unsigned int cpu);
 int schedule_cpu_rm(unsigned int cpu, struct cpu_rm_data *mem);
 int sched_move_domain(struct domain *d, struct cpupool *c);
+void sched_migrate_timers(unsigned int cpu);
 struct cpupool *cpupool_get_by_id(unsigned int poolid);
 void cpupool_put(struct cpupool *pool);
 int 

RE: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM

[Henry Wang]

(+ Arm maintainers)

Hi Oleksandr,

> -Original Message-
> From: Oleksandr 
> Subject: Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM
> Hello all.
> On 19.07.22 13:40, Jan Beulich wrote:
> > On 19.07.2022 12:32, Volodymyr Babchuk wrote:
> >> Jan Beulich  writes:
> >>
> >>> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>  Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>  iounmap(), but not added corresponding include.
> 
>  Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
> >>> I don't think there's any active issue with the "missing" include:
> >>> That's only a problem once Arm has vPCI code enabled? In which
> >>> case I don't think a Fixes: tag is warranted.
> >> Fair enough. May I ask committer to drop this tag?
> > I had taken respective note already, in case I end up committing this.
> > But this is the last patch of the series, so I can only guess whether
> > it might be okay to go in ahead of the other three patches.
> >
> > Jan
> 
> 
> I am wondering, where this patch could be 4.17 material?
> 
> The patch series seem to get stuck, but the current patch just adds a
> missing include to fix a build on Arm, so it is completely independent.
> I agree, there is no issue with the current code base as vPCI is
> disabled on Arm, so nothing to fix right now. But as PCI
> passthrough/vPCI on Arm is in the development stage, the developers
> enable that support in their builds. I think the risk is rather low than
> high.

It seems reasonable to me, but I am curious about what Arm maintainers
and PCI maintainers think. From the history discussion in this thread I
think it is pretty safe to include this in 4.17. Thanks for the ping.

Kind regards,
Henry


> 
> 
> 
> --
> Regards,
> 
> Oleksandr Tyshchenko

Re: [PATCH v2 4/4] vpci: include xen/vmap.h to fix build on ARM

[Oleksandr]

Hello all.


On 19.07.22 13:40, Jan Beulich wrote:

On 19.07.2022 12:32, Volodymyr Babchuk wrote:

Jan Beulich  writes:


On 18.07.2022 23:15, Volodymyr Babchuk wrote:

Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
iounmap(), but not added corresponding include.

Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")

I don't think there's any active issue with the "missing" include:
That's only a problem once Arm has vPCI code enabled? In which
case I don't think a Fixes: tag is warranted.

Fair enough. May I ask committer to drop this tag?

I had taken respective note already, in case I end up committing this.
But this is the last patch of the series, so I can only guess whether
it might be okay to go in ahead of the other three patches.

Jan



I am wondering, where this patch could be 4.17 material?

The patch series seem to get stuck, but the current patch just adds a 
missing include to fix a build on Arm, so it is completely independent. 
I agree, there is no issue with the current code base as vPCI is 
disabled on Arm, so nothing to fix right now. But as PCI 
passthrough/vPCI on Arm is in the development stage, the developers 
enable that support in their builds. I think the risk is rather low than 
high.




--
Regards,

Oleksandr Tyshchenko

Re: [for-4.17] automation: Build Xen according to the type of the job

[Michal Orzel]

Hi Andrew,

On 21/10/2022 15:31, Andrew Cooper wrote:
> 
> 
> On 21/10/2022 14:22, Michal Orzel wrote:
>> All the build jobs exist in two flavors: debug and non-debug, where the
>> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
>> is only being recognized by the toolstack, because Xen requires
>> enabling/disabling debug build via e.g. menuconfig/config file.
>> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
>> set to a default value ('y' for unstable and 'n' for stable branches),
>> regardless of the type of the build job.
>>
>> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
>>
>> Signed-off-by: Michal Orzel 
>> ---
>> Xen used debug variable to control the build type before switching to 
>> Kconfig.
>> Support for GitLab CI was added later, which means that this issue was always
>> present. This is a low risk for 4.17 with a benefit of being able to test Xen
>> in both debug and non-debug versions.
> 
> Both series were floating around for ages before being accepted.  It's
> quite possible that one bitrotted around the other.
> 
> This should be backported, and therefore should be considered for 4.17
> at this point.
> 
> Is there a Gitlab CI run which includes this patch?

I submitted the one here not long ago:
https://gitlab.com/xen-project/people/morzel/xen-orzelmichal/-/pipelines/673396949

and there is already one failure in Arm boot-cpupools test because the script 
sets null
scheduler for the domain which is not present in non-debug build...

> 
> ~Andrew

~Michal

RE: [for-4.17] automation: Build Xen according to the type of the job

[Henry Wang]

Hi Michal,

> -Original Message-
> From: Michal Orzel 
> Subject: [for-4.17] automation: Build Xen according to the type of the job
> 
> All the build jobs exist in two flavors: debug and non-debug, where the
> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
> is only being recognized by the toolstack, because Xen requires
> enabling/disabling debug build via e.g. menuconfig/config file.
> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
> set to a default value ('y' for unstable and 'n' for stable branches),
> regardless of the type of the build job.
> 
> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
> 
> Signed-off-by: Michal Orzel 

Release-acked-by: Henry Wang 

Kind regards,
Henry

Re: [for-4.17] automation: Build Xen according to the type of the job

[Andrew Cooper]

On 21/10/2022 14:22, Michal Orzel wrote:
> All the build jobs exist in two flavors: debug and non-debug, where the
> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
> is only being recognized by the toolstack, because Xen requires
> enabling/disabling debug build via e.g. menuconfig/config file.
> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
> set to a default value ('y' for unstable and 'n' for stable branches),
> regardless of the type of the build job.
>
> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
>
> Signed-off-by: Michal Orzel 
> ---
> Xen used debug variable to control the build type before switching to Kconfig.
> Support for GitLab CI was added later, which means that this issue was always
> present. This is a low risk for 4.17 with a benefit of being able to test Xen
> in both debug and non-debug versions.

Both series were floating around for ages before being accepted.  It's
quite possible that one bitrotted around the other.

This should be backported, and therefore should be considered for 4.17
at this point.

Is there a Gitlab CI run which includes this patch?

~Andrew

[for-4.17] automation: Build Xen according to the type of the job

[Michal Orzel]

All the build jobs exist in two flavors: debug and non-debug, where the
former sets 'debug' variable to 'y' and the latter to 'n'. This variable
is only being recognized by the toolstack, because Xen requires
enabling/disabling debug build via e.g. menuconfig/config file.
As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
set to a default value ('y' for unstable and 'n' for stable branches),
regardless of the type of the build job.

Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.

Signed-off-by: Michal Orzel 
---
Xen used debug variable to control the build type before switching to Kconfig.
Support for GitLab CI was added later, which means that this issue was always
present. This is a low risk for 4.17 with a benefit of being able to test Xen
in both debug and non-debug versions.
---
 automation/scripts/build | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/automation/scripts/build b/automation/scripts/build
index 8c0882f3aa33..a5934190634b 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -21,12 +21,13 @@ if [[ "${RANDCONFIG}" == "y" ]]; then
 make -j$(nproc) -C xen KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config 
randconfig
 hypervisor_only="y"
 else
+echo "CONFIG_DEBUG=${debug}" > xen/.config
+
 if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then
-echo "${EXTRA_XEN_CONFIG}" > xen/.config
-make -j$(nproc) -C xen olddefconfig
-else
-make -j$(nproc) -C xen defconfig
+echo "${EXTRA_XEN_CONFIG}" >> xen/.config
 fi
+
+make -j$(nproc) -C xen olddefconfig
 fi
 
 # Save the config file before building because build failure causes the script
-- 
2.25.1

Re: [PATCH v14 15/17] net: stream: move to QIO to enable additional parameters

[Philippe Mathieu-Daudé]

On 21/10/22 13:31, Markus Armbruster wrote:

Laurent Vivier  writes:


On 10/21/22 12:35, Markus Armbruster wrote:

Philippe Mathieu-Daudé  writes:


On 21/10/22 11:09, Laurent Vivier wrote:

Use QIOChannel, QIOChannelSocket and QIONetListener.
This allows net/stream to use all the available parameters provided by
SocketAddress.
Signed-off-by: Laurent Vivier 
Acked-by: Michael S. Tsirkin 
---
net/stream.c| 492 +---
qemu-options.hx |   4 +-
2 files changed, 178 insertions(+), 318 deletions(-)



+addr = qio_channel_socket_get_local_address(listen_sioc, NULL);
+g_assert(addr != NULL);


Missing propagating Error* (observed in v12).


*If* this is really a programming error: what about _abort?


assert() informs the compiler that following code will not use addr with a NULL 
value, I
don't think _abort does that. This could avoid an error report in code 
static analyzer.


I'd expect Coverity to see right through it.

Static analyzers with a less global view won't, of course.

For what it's worth, there are about a thousand uses of _abort
outside tests/.  I'm not aware of them confusing static analyzers we
care about.

I like _abort, because it makes the program crash when we try to
put the error into _abort, with an informative message.  This is
often right where things go wrong[*].  I personally don't care much
about the better message, but others do.  The better stack backtrace has
been quite useful to me.


I concur:

  qemu-system-x86_64: socket family 0 unsupported

VS:

   ERROR:../../net/stream.c:321:net_stream_client_connected: assertion
failed: (addr != NULL)

https://lore.kernel.org/qemu-devel/6fa6b9e5-fede-0f68-752f-0c0d8fa34...@linaro.org/



Let's use _abort, and throw in the assert when a static analyzer
we care about needs it.


[*] error_propagate() messes this up.  That's why the comments in
error.h ask you to do without when practical.

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

[osstest service owner]

flight 174134 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174134/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  broken  in 173725
 test-arm64-arm64-xl-vhd  12 debian-di-installfail REGR. vs. 172550
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 172550
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 172550
 test-armhf-armhf-libvirt-qcow2 12 debian-di-install  fail REGR. vs. 172550
 test-armhf-armhf-xl-credit2  14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-xl  14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-xl-arndale  14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-xl-credit1  14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 172550
 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 172550
 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 172550
 test-arm64-arm64-xl-xsm  14 guest-startfail in 174078 REGR. vs. 172550

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2  5 host-install(5) broken in 173725 pass in 174134
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 
173725 pass in 174134
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail in 173906 pass 
in 174134
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail in 173906 pass in 
174134
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 20 
guest-start/debianhvm.repeat fail in 173906 pass in 174134
 test-arm64-arm64-xl-credit2  14 guest-startfail pass in 173725
 test-arm64-arm64-libvirt-xsm 14 guest-startfail pass in 173725
 test-arm64-arm64-xl  14 guest-startfail pass in 173906
 test-arm64-arm64-xl-credit1  14 guest-startfail pass in 173906
 test-arm64-arm64-libvirt-raw 12 debian-di-install  fail pass in 173906
 test-amd64-i386-xl-shadow 7 xen-installfail pass in 174078
 test-arm64-arm64-xl-xsm   8 xen-boot   fail pass in 174078
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 
174078

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 14 guest-start  fail REGR. vs. 172550

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 173725 never pass
 test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 173725 never 
pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 173725 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 173725 never 
pass
 test-arm64-arm64-xl 15 migrate-support-check fail in 173906 never pass
 test-arm64-arm64-xl 16 saverestore-support-check fail in 173906 never pass
 test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 173906 never pass
 test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 173906 never 
pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 173906 never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 173906 never 
pass
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172550
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172550
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172550
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172550
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172550
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172550
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172550
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like 
172550
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172550
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172550
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 

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

[osstest service owner]

flight 174192 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174192/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f838b956779ff8a0b94636462f3c6d95c3adeb73
baseline version:
 xen  0c06760be3dc3f286015e18c4b1d1694e55da026

Last test of basis   174146  2022-10-20 18:02:03 Z0 days
Testing same since   174192  2022-10-21 10:00:58 Z0 days1 attempts


People who touched revisions under test:
  Christian Lindig 
  Edwin Török 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0c06760be3..f838b95677  f838b956779ff8a0b94636462f3c6d95c3adeb73 -> smoke

[qemu-upstream-4.16-testing test] 174136: tolerable FAIL - PUSHED

[osstest service owner]

flight 174136 qemu-upstream-4.16-testing real [real]
flight 174191 qemu-upstream-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174136/
http://logs.test-lab.xenproject.org/osstest/logs/174191/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-install   fail pass in 174191-retest
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 174191-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 168659
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 168659
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168659
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 168659
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 168659
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 168659
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 168659
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168659
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu62dd49f2172fb7dfe8d4223bfa45aede05155328
baseline 

Re: [PATCH v14 06/17] qapi: net: add stream and dgram netdevs

[Alex Bennée]

Laurent Vivier  writes:

> Copied from socket netdev file and modified to use SocketAddress
> to be able to introduce new features like unix socket.
>

> index eb38e5dc40bc..396c1d11e1e2 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2772,6 +2772,18 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
>  "-netdev socket,id=str[,fd=h][,udp=host:port][,localaddr=host:port]\n"
>  "configure a network backend to connect to another 
> network\n"
>  "using an UDP tunnel\n"
> +"-netdev 
> stream,id=str[,server=on|off],addr.type=inet,addr.host=host,addr.port=port\n"
> +"-netdev 
> stream,id=str[,server=on|off],addr.type=fd,addr.str=file-descriptor\n"
> +"configure a network backend to connect to another 
> network\n"
> +"using a socket connection in stream mode.\n"
> +"-netdev 
> dgram,id=str,remote.type=inet,remote.host=maddr,remote.port=port[,local.type=inet,local.host=addr]\n"
> +"-netdev 
> dgram,id=str,remote.type=inet,remote.host=maddr,remote.port=port[,local.type=fd,local.str=file-descriptor]\n"
> +"configure a network backend to connect to a multicast 
> maddr and port\n"
> +"use ``local.host=addr`` to specify the host address to 
> send packets from\n"
> +"-netdev 
> dgram,id=str,local.type=inet,local.host=addr,local.port=port[,remote.type=inet,remote.host=addr,remote.port=port]\n"
> +"-netdev dgram,id=str,local.type=fd,local.str=file-descriptor\n"
> +"configure a network backend to connect to another 
> network\n"
> +"using an UDP tunnel\n"
>  #ifdef CONFIG_VDE
>  "-netdev 
> vde,id=str[,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n"
>  "configure a network backend to connect to port 'n' of a 
> vde switch\n"

While the option documentation is good it might be worth taking some
additional time to document the wider networking stack. It is a topic
that often sees confusion amongst users and is a complex area of
functionality.

At a minimum a bit of preamble around DEFHEADING(Network option:) to
explain how devices and backends interact might help users understand
the context for the individual options themselves before launching
directly into explaining each one.

We also have some stuff on the wiki:

  https://wiki.qemu.org/Documentation/Networking
  https://wiki.qemu.org/Documentation/Networking/NAT

that might be worth sanitising and transcribing into a section of the
system emulation manual. We can then point to :ref:`networking` in the
options documentation so the user doesn't have to piece together
disparate bits of online information themselves.

-- 
Alex Bennée

Re: [PATCH v14 15/17] net: stream: move to QIO to enable additional parameters

[Markus Armbruster]

Laurent Vivier  writes:

> On 10/21/22 12:35, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé  writes:
>> 
>>> On 21/10/22 11:09, Laurent Vivier wrote:
 Use QIOChannel, QIOChannelSocket and QIONetListener.
 This allows net/stream to use all the available parameters provided by
 SocketAddress.
 Signed-off-by: Laurent Vivier 
 Acked-by: Michael S. Tsirkin 
 ---
net/stream.c| 492 +---
qemu-options.hx |   4 +-
2 files changed, 178 insertions(+), 318 deletions(-)
>>>
 -static void net_stream_accept(void *opaque)
 +static void net_stream_server_listening(QIOTask *task, gpointer opaque)
{
NetStreamState *s = opaque;
 -struct sockaddr_storage saddr;
 -socklen_t len;
 -int fd;
 -
 -for (;;) {
 -len = sizeof(saddr);
 -fd = qemu_accept(s->listen_fd, (struct sockaddr *), );
 -if (fd < 0 && errno != EINTR) {
 -return;
 -} else if (fd >= 0) {
 -qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
 -break;
 -}
 -}
 +QIOChannelSocket *listen_sioc = QIO_CHANNEL_SOCKET(s->listen_ioc);
 +SocketAddress *addr;
 +int ret;
 -s->fd = fd;
 -s->nc.link_down = false;
 -net_stream_connect(s);
 -switch (saddr.ss_family) {
 -case AF_INET: {
 -struct sockaddr_in *saddr_in = (struct sockaddr_in *)
 -
 -qemu_set_info_str(>nc, "connection from %s:%d",
 -  inet_ntoa(saddr_in->sin_addr),
 -  ntohs(saddr_in->sin_port));
 -break;
 +if (listen_sioc->fd < 0) {
 +qemu_set_info_str(>nc, "connection error");
 +return;
}
 -case AF_UNIX: {
 -struct sockaddr_un saddr_un;
 -len = sizeof(saddr_un);
 -getsockname(s->listen_fd, (struct sockaddr *)_un, );
 -qemu_set_info_str(>nc, "connect from %s", saddr_un.sun_path);
 -break;
 -}
 -default:
 -g_assert_not_reached();
 +addr = qio_channel_socket_get_local_address(listen_sioc, NULL);
 +g_assert(addr != NULL);
>>>
>>> Missing propagating Error* (observed in v12).
>> 
>> *If* this is really a programming error: what about _abort?
>
> assert() informs the compiler that following code will not use addr with a 
> NULL value, I 
> don't think _abort does that. This could avoid an error report in code 
> static analyzer.

I'd expect Coverity to see right through it.

Static analyzers with a less global view won't, of course.

For what it's worth, there are about a thousand uses of _abort
outside tests/.  I'm not aware of them confusing static analyzers we
care about.

I like _abort, because it makes the program crash when we try to
put the error into _abort, with an informative message.  This is
often right where things go wrong[*].  I personally don't care much
about the better message, but others do.  The better stack backtrace has
been quite useful to me.

Let's use _abort, and throw in the assert when a static analyzer
we care about needs it.


[*] error_propagate() messes this up.  That's why the comments in
error.h ask you to do without when practical.

Re: [PATCH v14 12/17] net: dgram: add unix socket

[Philippe Mathieu-Daudé]

On 21/10/22 11:09, Laurent Vivier wrote:

Signed-off-by: Laurent Vivier 
Reviewed-by: Stefano Brivio 
Reviewed-by: David Gibson 
Acked-by: Michael S. Tsirkin 
Acked-by: Markus Armbruster  (QAPI schema)
---
  net/dgram.c | 55 -
  qapi/net.json   |  2 +-
  qemu-options.hx |  1 +
  3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/net/dgram.c b/net/dgram.c
index e581cc62f39f..9f7bf3837653 100644
--- a/net/dgram.c
+++ b/net/dgram.c
@@ -426,6 +426,7 @@ int net_init_dgram(const Netdev *netdev, const char *name,
  SocketAddress *remote, *local;
  struct sockaddr *dest_addr;
  struct sockaddr_in laddr_in, raddr_in;
+struct sockaddr_un laddr_un, raddr_un;
  socklen_t dest_len;
  
  assert(netdev->type == NET_CLIENT_DRIVER_DGRAM);

@@ -465,7 +466,8 @@ int net_init_dgram(const Netdev *netdev, const char *name,
  }
  } else {
  if (local->type != SOCKET_ADDRESS_TYPE_FD) {
-error_setg(errp, "type=inet requires remote parameter");
+error_setg(errp,
+   "type=inet or type=unix requires remote parameter");


Thanks for updating.


@@ -546,6 +595,10 @@ int net_init_dgram(const Netdev *netdev, const char *name,
inet_ntoa(raddr_in.sin_addr),
ntohs(raddr_in.sin_port));
  break;
+case SOCKET_ADDRESS_TYPE_UNIX:
+qemu_set_info_str(>nc, "udp=%s:%s",
+  laddr_un.sun_path, raddr_un.sun_path);
+break;


"udp"?

Re: [PATCH v2] xen/sched: fix restore_vcpu_affinity() by removing it

[Andrew Cooper]

On 21/10/2022 11:50, Juergen Gross wrote:
> When the system is coming up after having been suspended,
> restore_vcpu_affinity() is called for each domain in order to adjust
> the vcpu's affinity settings in case a cpu didn't come to live again.
>
> The way restore_vcpu_affinity() is doing that is wrong, because the
> specific scheduler isn't being informed about a possible migration of
> the vcpu to another cpu. Additionally the migration is often even
> happening if all cpus are running again, as it is done without check
> whether it is really needed.
>
> As cpupool management is already calling cpu_disable_scheduler() for
> cpus not having come up again, and cpu_disable_scheduler() is taking
> care of eventually needed vcpu migration in the proper way, there is
> simply no need for restore_vcpu_affinity().
>
> So just remove restore_vcpu_affinity() completely, together with the
> no longer used sched_reset_affinity_broken().
>
> Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct 
> sched_unit")
> Reported-by: Marek Marczykowski-Górecki 
> Acked-by: Dario Faggioli 
> Release-acked-by: Henry Wang 
> Signed-off-by: Juergen Gross 

For whomever commits this, Marek's T-by on v1 specifically included the
delta including in v2, and is therefore still applicable.

~Andrew

> ---
> V2:
> - also remove sched_reset_affinity_broken() (Jan Beulich)
> ---
>  xen/arch/x86/acpi/power.c |  3 --
>  xen/common/sched/core.c   | 78 ---
>  xen/include/xen/sched.h   |  1 -
>  3 files changed, 82 deletions(-)
>
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 1bb4d78392..b76f673acb 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -159,10 +159,7 @@ static void thaw_domains(void)
>  
>  rcu_read_lock(_read_lock);
>  for_each_domain ( d )
> -{
> -restore_vcpu_affinity(d);
>  domain_unpause(d);
> -}
>  rcu_read_unlock(_read_lock);
>  }
>  
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 83455fbde1..23fa6845a8 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1188,84 +1188,6 @@ static bool sched_check_affinity_broken(const struct 
> sched_unit *unit)
>  return false;
>  }
>  
> -static void sched_reset_affinity_broken(const struct sched_unit *unit)
> -{
> -struct vcpu *v;
> -
> -for_each_sched_unit_vcpu ( unit, v )
> -v->affinity_broken = false;
> -}
> -
> -void restore_vcpu_affinity(struct domain *d)
> -{
> -unsigned int cpu = smp_processor_id();
> -struct sched_unit *unit;
> -
> -ASSERT(system_state == SYS_STATE_resume);
> -
> -rcu_read_lock(_res_rculock);
> -
> -for_each_sched_unit ( d, unit )
> -{
> -spinlock_t *lock;
> -unsigned int old_cpu = sched_unit_master(unit);
> -struct sched_resource *res;
> -
> -ASSERT(!unit_runnable(unit));
> -
> -/*
> - * Re-assign the initial processor as after resume we have no
> - * guarantee the old processor has come back to life again.
> - *
> - * Therefore, here, before actually unpausing the domains, we should
> - * set v->processor of each of their vCPUs to something that will
> - * make sense for the scheduler of the cpupool in which they are in.
> - */
> -lock = unit_schedule_lock_irq(unit);
> -
> -cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -if ( sched_check_affinity_broken(unit) )
> -{
> -sched_set_affinity(unit, unit->cpu_hard_affinity_saved, 
> NULL);
> -sched_reset_affinity_broken(unit);
> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -/* Affinity settings of one vcpu are for the complete unit. 
> */
> -printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
> -   unit->vcpu_list);
> -sched_set_affinity(unit, _all, NULL);
> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -}
> -
> -res = get_sched_res(cpumask_any(cpumask_scratch_cpu(cpu)));
> -sched_set_res(unit, res);
> -
> -spin_unlock_irq(lock);
> -
> -/* v->processor might have changed, so reacquire the lock. */
> -lock = unit_schedule_lock_irq(unit);
> -res = sched_pick_resource(unit_scheduler(unit), unit);
> -sched_set_res(unit, res);
> -spin_unlock_irq(lock);
> -
> -if ( old_cpu != sched_unit_master(unit) )
> -

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Markus Armbruster]

Stefano Brivio  writes:

> [Cc: Laine, full quote]
>
> On Fri, 21 Oct 2022 11:12:20 +0200
> Markus Armbruster  wrote:
>
>> Cc: Stefano Brivio
>> 
>> Laurent Vivier  writes:
>> 
>> > On 10/21/22 07:48, Markus Armbruster wrote:  
>> >> Laurent Vivier  writes:
>> >>   
>> >>> The netdev reports NETDEV_STREAM_CONNECTED event when the backend
>> >>> is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.  
>> >>
>> >> Use cases?  
>> >
>> > This is asked by Stefano Brivio to allow libvirt to detect if connection 
>> > to passt is lost and to restart passt.  
>> 
>> Let's add something like this to the commit message:
>> 
>> This lets libvirt notice when the connection is lost somehow, and
>> restart the peer (such as passt).
>> 
>> Who's working on the libvirt part?
>
> Laine Stump and myself. Nothing to show yet, though.

Good enough for me :)

[...]

[PATCH v2] xen/sched: fix restore_vcpu_affinity() by removing it

[Juergen Gross]

When the system is coming up after having been suspended,
restore_vcpu_affinity() is called for each domain in order to adjust
the vcpu's affinity settings in case a cpu didn't come to live again.

The way restore_vcpu_affinity() is doing that is wrong, because the
specific scheduler isn't being informed about a possible migration of
the vcpu to another cpu. Additionally the migration is often even
happening if all cpus are running again, as it is done without check
whether it is really needed.

As cpupool management is already calling cpu_disable_scheduler() for
cpus not having come up again, and cpu_disable_scheduler() is taking
care of eventually needed vcpu migration in the proper way, there is
simply no need for restore_vcpu_affinity().

So just remove restore_vcpu_affinity() completely, together with the
no longer used sched_reset_affinity_broken().

Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct sched_unit")
Reported-by: Marek Marczykowski-Górecki 
Acked-by: Dario Faggioli 
Release-acked-by: Henry Wang 
Signed-off-by: Juergen Gross 
---
V2:
- also remove sched_reset_affinity_broken() (Jan Beulich)
---
 xen/arch/x86/acpi/power.c |  3 --
 xen/common/sched/core.c   | 78 ---
 xen/include/xen/sched.h   |  1 -
 3 files changed, 82 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 1bb4d78392..b76f673acb 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -159,10 +159,7 @@ static void thaw_domains(void)
 
 rcu_read_lock(_read_lock);
 for_each_domain ( d )
-{
-restore_vcpu_affinity(d);
 domain_unpause(d);
-}
 rcu_read_unlock(_read_lock);
 }
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 83455fbde1..23fa6845a8 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1188,84 +1188,6 @@ static bool sched_check_affinity_broken(const struct 
sched_unit *unit)
 return false;
 }
 
-static void sched_reset_affinity_broken(const struct sched_unit *unit)
-{
-struct vcpu *v;
-
-for_each_sched_unit_vcpu ( unit, v )
-v->affinity_broken = false;
-}
-
-void restore_vcpu_affinity(struct domain *d)
-{
-unsigned int cpu = smp_processor_id();
-struct sched_unit *unit;
-
-ASSERT(system_state == SYS_STATE_resume);
-
-rcu_read_lock(_res_rculock);
-
-for_each_sched_unit ( d, unit )
-{
-spinlock_t *lock;
-unsigned int old_cpu = sched_unit_master(unit);
-struct sched_resource *res;
-
-ASSERT(!unit_runnable(unit));
-
-/*
- * Re-assign the initial processor as after resume we have no
- * guarantee the old processor has come back to life again.
- *
- * Therefore, here, before actually unpausing the domains, we should
- * set v->processor of each of their vCPUs to something that will
- * make sense for the scheduler of the cpupool in which they are in.
- */
-lock = unit_schedule_lock_irq(unit);
-
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
-{
-if ( sched_check_affinity_broken(unit) )
-{
-sched_set_affinity(unit, unit->cpu_hard_affinity_saved, NULL);
-sched_reset_affinity_broken(unit);
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-}
-
-if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
-{
-/* Affinity settings of one vcpu are for the complete unit. */
-printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
-   unit->vcpu_list);
-sched_set_affinity(unit, _all, NULL);
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-}
-}
-
-res = get_sched_res(cpumask_any(cpumask_scratch_cpu(cpu)));
-sched_set_res(unit, res);
-
-spin_unlock_irq(lock);
-
-/* v->processor might have changed, so reacquire the lock. */
-lock = unit_schedule_lock_irq(unit);
-res = sched_pick_resource(unit_scheduler(unit), unit);
-sched_set_res(unit, res);
-spin_unlock_irq(lock);
-
-if ( old_cpu != sched_unit_master(unit) )
-sched_move_irqs(unit);
-}
-
-rcu_read_unlock(_res_rculock);
-
-domain_update_node_affinity(d);
-}
-
 /*
  * This function is used by cpu_hotplug code via cpu notifier chain
  * and from cpupools to switch schedulers on a cpu.
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 557b3229f6..072e4846aa 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1019,7 +1019,6 @@ void 

Re: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Marek Marczykowski-Górecki]

On Fri, Oct 21, 2022 at 08:58:06AM +0200, Juergen Gross wrote:
> When the system is coming up after having been suspended,
> restore_vcpu_affinity() is called for each domain in order to adjust
> the vcpu's affinity settings in case a cpu didn't come to live again.
> 
> The way restore_vcpu_affinity() is doing that is wrong, because the
> specific scheduler isn't being informed about a possible migration of
> the vcpu to another cpu. Additionally the migration is often even
> happening if all cpus are running again, as it is done without check
> whether it is really needed.
> 
> As cpupool management is already calling cpu_disable_scheduler() for
> cpus not having come up again, and cpu_disable_scheduler() is taking
> care of eventually needed vcpu migration in the proper way, there is
> simply no need for restore_vcpu_affinity().
> 
> So just remove restore_vcpu_affinity() completely.
> 
> Fixes: 8a5d50dd0b04 ("xen: sched: simplify ACPI S3 resume path.")
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Juergen Gross 

I can only test it on a different configuration right now, but I can
confirm with this patch applied the system survives S3 (and it did
crashed without it at least once on this config).

With the now-unused function (also noticed by Jan) dealt with, you can add my:

Tested-by: Marek Marczykowski-Górecki 


> ---
>  xen/arch/x86/acpi/power.c |  3 --
>  xen/common/sched/core.c   | 70 ---
>  xen/include/xen/sched.h   |  1 -
>  3 files changed, 74 deletions(-)
> 
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 1bb4d78392..b76f673acb 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -159,10 +159,7 @@ static void thaw_domains(void)
>  
>  rcu_read_lock(_read_lock);
>  for_each_domain ( d )
> -{
> -restore_vcpu_affinity(d);
>  domain_unpause(d);
> -}
>  rcu_read_unlock(_read_lock);
>  }
>  
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 83455fbde1..358fa077e3 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1196,76 +1196,6 @@ static void sched_reset_affinity_broken(const struct 
> sched_unit *unit)
>  v->affinity_broken = false;
>  }
>  
> -void restore_vcpu_affinity(struct domain *d)
> -{
> -unsigned int cpu = smp_processor_id();
> -struct sched_unit *unit;
> -
> -ASSERT(system_state == SYS_STATE_resume);
> -
> -rcu_read_lock(_res_rculock);
> -
> -for_each_sched_unit ( d, unit )
> -{
> -spinlock_t *lock;
> -unsigned int old_cpu = sched_unit_master(unit);
> -struct sched_resource *res;
> -
> -ASSERT(!unit_runnable(unit));
> -
> -/*
> - * Re-assign the initial processor as after resume we have no
> - * guarantee the old processor has come back to life again.
> - *
> - * Therefore, here, before actually unpausing the domains, we should
> - * set v->processor of each of their vCPUs to something that will
> - * make sense for the scheduler of the cpupool in which they are in.
> - */
> -lock = unit_schedule_lock_irq(unit);
> -
> -cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -if ( sched_check_affinity_broken(unit) )
> -{
> -sched_set_affinity(unit, unit->cpu_hard_affinity_saved, 
> NULL);
> -sched_reset_affinity_broken(unit);
> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -/* Affinity settings of one vcpu are for the complete unit. 
> */
> -printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
> -   unit->vcpu_list);
> -sched_set_affinity(unit, _all, NULL);
> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -}
> -
> -res = get_sched_res(cpumask_any(cpumask_scratch_cpu(cpu)));
> -sched_set_res(unit, res);
> -
> -spin_unlock_irq(lock);
> -
> -/* v->processor might have changed, so reacquire the lock. */
> -lock = unit_schedule_lock_irq(unit);
> -res = sched_pick_resource(unit_scheduler(unit), unit);
> -sched_set_res(unit, res);
> -spin_unlock_irq(lock);
> -
> -if ( old_cpu != sched_unit_master(unit) )
> -sched_move_irqs(unit);
> -}
> -
> -rcu_read_unlock(_res_rculock);
> -
> -domain_update_node_affinity(d);
> -}
> -
>  /*
>   * This function is used by cpu_hotplug code via cpu notifier 

Re: Issue: Networking performance in Xen VM on Arm64

[Leo Yan]

Hi Stefano and all,

On Mon, Oct 17, 2022 at 04:50:05PM -0700, Stefano Stabellini wrote:

[...]

> > We can see DomU sends notification with timestamp (raw counter) is
> > 4989078592 and Dom0 receives the interrupt with timestamp 4989092169.
> > Since Dom0 and DomU use the same time counter and the counter
> > frequency is 25MHz, so we can get the delta value (in macroseconds):
> > 
> > (4989092169 - 4989078592) / 2500 * 1000 * 1000
> >   = 543us
> > 
> > Which means it takes 543us to let Dom0 to receive the notification.
> > You could see DomU runs in CPU3 and Dom0 runs on CPU13, there should
> > not have contention for CPU resources.  Seems to me, it's likely Xen
> > hypervisor takes long time to deliver the interrupt, note, it's not
> > take so long time for every skb transferring, sometimes the time for
> > response a notification is short (about ~10us).
> 
> Good find. I think this is worth investigating further. Do you have
> vwfi=native in your Xen command line as well?
> 
> After that, I would add printk also in Xen with the timestamp. The event
> channel notification code path is the following:
> 
> # domU side
> xen/arch/arm/vgic-v2.c:vgic_v2_to_sgi
> xen/arch/arm/vgic.c:vgic_to_sgi
> xen/arch/arm/vgic.c:vgic_inject_irq
> xen/arch/arm/vgic.c:vcpu_kick
> xen/arch/arm/gic-v2.c:gicv2_send_SGI
> 
> # dom0 side
> xen/arch/arm/gic.c:do_sgi
> xen/arch/arm/traps.c:leave_hypervisor_to_guest
> 
> It would be good to understand why sometimes it takes ~10us and some
> other times it takes ~540us

Some updates for why it takes several hundreds us for Xen backend driver
to respond interrupt.  The short answer is the vcpu running Xen backend
driver needs to switch context, even I have set options "sched=null
vwfi=native" in Xen command line.

So please see below detailed logs for how the things happen.

Let's take the timestamp 3842008681 as the start point, it's the time
for Xen backend driver sending out notification (xennet_notify_tx_irq);
at the timestamp 3842008885 the Xen hypervisor injects the interrupt
(it's about ~8us duration from the start point).

And then at the timestamp 3842008935 it invokes vcpu_kick() to kick the
virtual CPU for running Xen forend driver, you could see
VCPU_PROCESSOR is 11 and VCPU_ID is 9 for dom0, the duration is
10.16us from the start point.

The key point is at this point the vcpu's is_running is 0, this is
different from the case without long latency which vcpu's is_running
is 1.  IIUC, Xen hypervisor needs to take time to restore the vcpu's
context, thus we can see the virtual CPU 9 in Dom0 starts to run at
the timestamp 3842016505.

3842008548  pub-310   [001]67.352980: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842008548
3842008652  pub-310   [001]67.352984: bprint:   
xennet_tx_setup_grant: id=52 ref=820 offset=2 len=1514 TSC: 3842008652
3842008681  pub-310   [001]67.352985: bprint:   
xennet_start_xmit: xennet_notify_tx_irq: TSC: 3842008681
3842008689 (XEN) leave_hypervisor_to_guest: CPU_ID: 0 TSC: 3842008689
3842008766 (XEN) EVTCHNOP_send: CPU_ID: 2 TSC: 3842008766
3842008885 (XEN) vgic_inject_irq: CPU_ID: 2 TSC: 3842008885
3842008929 (XEN) leave_hypervisor_to_guest: CPU_ID: 14 TSC: 3842008929
3842008935 (XEN) vcpu_kick: VCPU_PROCESSOR: 11 VCPU_ID: 9 is_running 0 TSC: 
3842008935
3842009049 (XEN) leave_hypervisor_to_guest: CPU_ID: 2 TSC: 3842009049
3842009322  pub-310   [001]67.353011: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842009322
3842009374  pub-310   [001]67.353013: bprint:   
xennet_tx_setup_grant: id=12 ref=780 offset=2050 len=1514 TSC: 3842009374
3842009584  pub-310   [001]67.353021: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842009584
3842009625 (XEN) leave_hypervisor_to_guest: CPU_ID: 15 TSC: 3842009625
3842009633  pub-310   [001]67.353023: bprint:   
xennet_tx_setup_grant: id=83 ref=851 offset=2 len=1514 TSC: 3842009633
3842009853  pub-310   [001]67.353032: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842009853
3842009899  pub-310   [001]67.353034: bprint:   
xennet_tx_setup_grant: id=5 ref=773 offset=2050 len=1514 TSC: 3842009899
3842010080  pub-310   [001]67.353041: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842010080
3842010121  pub-310   [001]67.353043: bprint:   
xennet_tx_setup_grant: id=85 ref=853 offset=2 len=1514 TSC: 3842010121
3842010316  pub-310   [001]67.353050: bprint:   
xennet_start_xmit: xennet_start_xmit: TSC: 3842010316
3842010359  pub-310   [001]67.353052: bprint:   
xennet_tx_setup_grant: id=9 ref=777 offset=2050 len=1514 TSC: 3842010359
3842010553  pub-310   [001]67.353060: bprint:

Re: [PATCH v14 15/17] net: stream: move to QIO to enable additional parameters

[Laurent Vivier]

On 10/21/22 12:35, Markus Armbruster wrote:

Philippe Mathieu-Daudé  writes:


On 21/10/22 11:09, Laurent Vivier wrote:

Use QIOChannel, QIOChannelSocket and QIONetListener.
This allows net/stream to use all the available parameters provided by
SocketAddress.
Signed-off-by: Laurent Vivier 
Acked-by: Michael S. Tsirkin 
---
   net/stream.c| 492 +---
   qemu-options.hx |   4 +-
   2 files changed, 178 insertions(+), 318 deletions(-)



-static void net_stream_accept(void *opaque)
+static void net_stream_server_listening(QIOTask *task, gpointer opaque)
   {
   NetStreamState *s = opaque;
-struct sockaddr_storage saddr;
-socklen_t len;
-int fd;
-
-for (;;) {
-len = sizeof(saddr);
-fd = qemu_accept(s->listen_fd, (struct sockaddr *), );
-if (fd < 0 && errno != EINTR) {
-return;
-} else if (fd >= 0) {
-qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
-break;
-}
-}
+QIOChannelSocket *listen_sioc = QIO_CHANNEL_SOCKET(s->listen_ioc);
+SocketAddress *addr;
+int ret;
   -s->fd = fd;
-s->nc.link_down = false;
-net_stream_connect(s);
-switch (saddr.ss_family) {
-case AF_INET: {
-struct sockaddr_in *saddr_in = (struct sockaddr_in *)
-
-qemu_set_info_str(>nc, "connection from %s:%d",
-  inet_ntoa(saddr_in->sin_addr),
-  ntohs(saddr_in->sin_port));
-break;
+if (listen_sioc->fd < 0) {
+qemu_set_info_str(>nc, "connection error");
+return;
   }
-case AF_UNIX: {
-struct sockaddr_un saddr_un;
   -len = sizeof(saddr_un);
-getsockname(s->listen_fd, (struct sockaddr *)_un, );
-qemu_set_info_str(>nc, "connect from %s", saddr_un.sun_path);
-break;
-}
-default:
-g_assert_not_reached();
+addr = qio_channel_socket_get_local_address(listen_sioc, NULL);
+g_assert(addr != NULL);


Missing propagating Error* (observed in v12).


*If* this is really a programming error: what about _abort?


assert() informs the compiler that following code will not use addr with a NULL value, I 
don't think _abort does that. This could avoid an error report in code static analyzer.


Thanks,
Laurent

Re: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Juergen Gross]

On 21.10.22 12:37, Jan Beulich wrote:

On 21.10.2022 08:58, Juergen Gross wrote:

--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1196,76 +1196,6 @@ static void sched_reset_affinity_broken(const struct 
sched_unit *unit)
  v->affinity_broken = false;
  }


My pre-push build test failed because the function above ...


-void restore_vcpu_affinity(struct domain *d)
-{
-unsigned int cpu = smp_processor_id();
-struct sched_unit *unit;
-
-ASSERT(system_state == SYS_STATE_resume);
-
-rcu_read_lock(_res_rculock);
-
-for_each_sched_unit ( d, unit )
-{
-spinlock_t *lock;
-unsigned int old_cpu = sched_unit_master(unit);
-struct sched_resource *res;
-
-ASSERT(!unit_runnable(unit));
-
-/*
- * Re-assign the initial processor as after resume we have no
- * guarantee the old processor has come back to life again.
- *
- * Therefore, here, before actually unpausing the domains, we should
- * set v->processor of each of their vCPUs to something that will
- * make sense for the scheduler of the cpupool in which they are in.
- */
-lock = unit_schedule_lock_irq(unit);
-
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
-{
-if ( sched_check_affinity_broken(unit) )
-{
-sched_set_affinity(unit, unit->cpu_hard_affinity_saved, NULL);
-sched_reset_affinity_broken(unit);


... has its only use removed here. It didn't seem appropriate for me to
go and silently remove that function as well.


Weird I didn't spot that.

I'll update the patch.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH] xen/sched: try harder to find a runnable unit in rt_schedule()

[Juergen Gross]

Instead of directly falling back to the idle unit in case the top
unit from the run queue happened to be not runnable, consult the run
queue again.

Suggested-by: Dario Faggioli 
Signed-off-by: Juergen Gross 
---
 xen/common/sched/rt.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 960a8033e2..1f8d074884 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1080,15 +1080,20 @@ rt_schedule(const struct scheduler *ops, struct 
sched_unit *currunit,
 }
 else
 {
-snext = runq_pick(ops, cpumask_of(sched_cpu), cur_cpu);
-
-if ( snext == NULL )
-snext = rt_unit(sched_idle_unit(sched_cpu));
-else if ( !unit_runnable_state(snext->unit) )
+while ( true )
 {
+snext = runq_pick(ops, cpumask_of(sched_cpu), cur_cpu);
+
+if ( snext == NULL )
+{
+snext = rt_unit(sched_idle_unit(sched_cpu));
+break;
+}
+if ( unit_runnable_state(snext->unit) )
+break;
+
 q_remove(snext);
 replq_remove(ops, snext);
-snext = rt_unit(sched_idle_unit(sched_cpu));
 }
 
 /* if scurr has higher priority and budget, still pick scurr */
-- 
2.35.3

Re: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Jan Beulich]

On 21.10.2022 08:58, Juergen Gross wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1196,76 +1196,6 @@ static void sched_reset_affinity_broken(const struct 
> sched_unit *unit)
>  v->affinity_broken = false;
>  }

My pre-push build test failed because the function above ...

> -void restore_vcpu_affinity(struct domain *d)
> -{
> -unsigned int cpu = smp_processor_id();
> -struct sched_unit *unit;
> -
> -ASSERT(system_state == SYS_STATE_resume);
> -
> -rcu_read_lock(_res_rculock);
> -
> -for_each_sched_unit ( d, unit )
> -{
> -spinlock_t *lock;
> -unsigned int old_cpu = sched_unit_master(unit);
> -struct sched_resource *res;
> -
> -ASSERT(!unit_runnable(unit));
> -
> -/*
> - * Re-assign the initial processor as after resume we have no
> - * guarantee the old processor has come back to life again.
> - *
> - * Therefore, here, before actually unpausing the domains, we should
> - * set v->processor of each of their vCPUs to something that will
> - * make sense for the scheduler of the cpupool in which they are in.
> - */
> -lock = unit_schedule_lock_irq(unit);
> -
> -cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -if ( sched_check_affinity_broken(unit) )
> -{
> -sched_set_affinity(unit, unit->cpu_hard_affinity_saved, 
> NULL);
> -sched_reset_affinity_broken(unit);

... has its only use removed here. It didn't seem appropriate for me to
go and silently remove that function as well.

Jan

> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -
> -if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> -{
> -/* Affinity settings of one vcpu are for the complete unit. 
> */
> -printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
> -   unit->vcpu_list);
> -sched_set_affinity(unit, _all, NULL);
> -cpumask_and(cpumask_scratch_cpu(cpu), 
> unit->cpu_hard_affinity,
> -cpupool_domain_master_cpumask(d));
> -}
> -}
> -
> -res = get_sched_res(cpumask_any(cpumask_scratch_cpu(cpu)));
> -sched_set_res(unit, res);
> -
> -spin_unlock_irq(lock);
> -
> -/* v->processor might have changed, so reacquire the lock. */
> -lock = unit_schedule_lock_irq(unit);
> -res = sched_pick_resource(unit_scheduler(unit), unit);
> -sched_set_res(unit, res);
> -spin_unlock_irq(lock);
> -
> -if ( old_cpu != sched_unit_master(unit) )
> -sched_move_irqs(unit);
> -}
> -
> -rcu_read_unlock(_res_rculock);
> -
> -domain_update_node_affinity(d);
> -}
> -
>  /*
>   * This function is used by cpu_hotplug code via cpu notifier chain
>   * and from cpupools to switch schedulers on a cpu.
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 557b3229f6..072e4846aa 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1019,7 +1019,6 @@ void vcpu_set_periodic_timer(struct vcpu *v, s_time_t 
> value);
>  void sched_setup_dom0_vcpus(struct domain *d);
>  int vcpu_temporary_affinity(struct vcpu *v, unsigned int cpu, uint8_t 
> reason);
>  int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity);
> -void restore_vcpu_affinity(struct domain *d);
>  int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
>   struct xen_domctl_vcpuaffinity *vcpuaff);
>  

Re: [PATCH v14 15/17] net: stream: move to QIO to enable additional parameters

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> On 21/10/22 11:09, Laurent Vivier wrote:
>> Use QIOChannel, QIOChannelSocket and QIONetListener.
>> This allows net/stream to use all the available parameters provided by
>> SocketAddress.
>> Signed-off-by: Laurent Vivier 
>> Acked-by: Michael S. Tsirkin 
>> ---
>>   net/stream.c| 492 +---
>>   qemu-options.hx |   4 +-
>>   2 files changed, 178 insertions(+), 318 deletions(-)
>
>> -static void net_stream_accept(void *opaque)
>> +static void net_stream_server_listening(QIOTask *task, gpointer opaque)
>>   {
>>   NetStreamState *s = opaque;
>> -struct sockaddr_storage saddr;
>> -socklen_t len;
>> -int fd;
>> -
>> -for (;;) {
>> -len = sizeof(saddr);
>> -fd = qemu_accept(s->listen_fd, (struct sockaddr *), );
>> -if (fd < 0 && errno != EINTR) {
>> -return;
>> -} else if (fd >= 0) {
>> -qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
>> -break;
>> -}
>> -}
>> +QIOChannelSocket *listen_sioc = QIO_CHANNEL_SOCKET(s->listen_ioc);
>> +SocketAddress *addr;
>> +int ret;
>>   -s->fd = fd;
>> -s->nc.link_down = false;
>> -net_stream_connect(s);
>> -switch (saddr.ss_family) {
>> -case AF_INET: {
>> -struct sockaddr_in *saddr_in = (struct sockaddr_in *)
>> -
>> -qemu_set_info_str(>nc, "connection from %s:%d",
>> -  inet_ntoa(saddr_in->sin_addr),
>> -  ntohs(saddr_in->sin_port));
>> -break;
>> +if (listen_sioc->fd < 0) {
>> +qemu_set_info_str(>nc, "connection error");
>> +return;
>>   }
>> -case AF_UNIX: {
>> -struct sockaddr_un saddr_un;
>>   -len = sizeof(saddr_un);
>> -getsockname(s->listen_fd, (struct sockaddr *)_un, );
>> -qemu_set_info_str(>nc, "connect from %s", saddr_un.sun_path);
>> -break;
>> -}
>> -default:
>> -g_assert_not_reached();
>> +addr = qio_channel_socket_get_local_address(listen_sioc, NULL);
>> +g_assert(addr != NULL);
>
> Missing propagating Error* (observed in v12).

*If* this is really a programming error: what about _abort?

[...]

Re: [PATCH v14 13/17] qemu-sockets: move and rename SocketAddress_to_str()

[Marc-André Lureau]

Hi

On Fri, Oct 21, 2022 at 2:03 PM Laurent Vivier  wrote:

> Rename SocketAddress_to_str() to socket_uri() and move it to
> util/qemu-sockets.c close to socket_parse().
>
> socket_uri() generates a string from a SocketAddress while
> socket_parse() generates a SocketAddress from a string.
>

Tbh, as we are renaming functions here, I would follow good glib/C
conventions and use the type name in lower case as prefix. I would also not
use "URI", which should be reserved for RFC3986 compliant forms.

So instead, I'd suggest to rename to:

char *socket_address_to_string(SocketAddress *addr);

SocketAddress *socket_address_new_from_string(const char *str, Error **errp)

my 2c


> Signed-off-by: Laurent Vivier 
> Reviewed-by: David Gibson 
> Reviewed-by: Dr. David Alan Gilbert 
> Acked-by: Michael S. Tsirkin 
> ---
>  include/qemu/sockets.h |  2 +-
>  monitor/hmp-cmds.c | 23 +--
>  util/qemu-sockets.c| 20 
>  3 files changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/include/qemu/sockets.h b/include/qemu/sockets.h
> index db4bedb6fa20..214058d8e307 100644
> --- a/include/qemu/sockets.h
> +++ b/include/qemu/sockets.h
> @@ -58,6 +58,7 @@ NetworkAddressFamily inet_netfamily(int family);
>  int unix_listen(const char *path, Error **errp);
>  int unix_connect(const char *path, Error **errp);
>
> +char *socket_uri(SocketAddress *addr);
>  SocketAddress *socket_parse(const char *str, Error **errp);
>  int socket_connect(SocketAddress *addr, Error **errp);
>  int socket_listen(SocketAddress *addr, int num, Error **errp);
> @@ -141,5 +142,4 @@ SocketAddress
> *socket_address_flatten(SocketAddressLegacy *addr);
>   * Return 0 on success.
>   */
>  int socket_address_parse_named_fd(SocketAddress *addr, Error **errp);
> -
>  #endif /* QEMU_SOCKETS_H */
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index bab86c5537e1..01b789a79e62 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -199,27 +199,6 @@ void hmp_info_mice(Monitor *mon, const QDict *qdict)
>  qapi_free_MouseInfoList(mice_list);
>  }
>
> -static char *SocketAddress_to_str(SocketAddress *addr)
> -{
> -switch (addr->type) {
> -case SOCKET_ADDRESS_TYPE_INET:
> -return g_strdup_printf("tcp:%s:%s",
> -   addr->u.inet.host,
> -   addr->u.inet.port);
> -case SOCKET_ADDRESS_TYPE_UNIX:
> -return g_strdup_printf("unix:%s",
> -   addr->u.q_unix.path);
> -case SOCKET_ADDRESS_TYPE_FD:
> -return g_strdup_printf("fd:%s", addr->u.fd.str);
> -case SOCKET_ADDRESS_TYPE_VSOCK:
> -return g_strdup_printf("tcp:%s:%s",
> -   addr->u.vsock.cid,
> -   addr->u.vsock.port);
> -default:
> -return g_strdup("unknown address type");
> -}
> -}
> -
>  void hmp_info_migrate(Monitor *mon, const QDict *qdict)
>  {
>  MigrationInfo *info;
> @@ -382,7 +361,7 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
>  monitor_printf(mon, "socket address: [\n");
>
>  for (addr = info->socket_address; addr; addr = addr->next) {
> -char *s = SocketAddress_to_str(addr->value);
> +char *s = socket_uri(addr->value);
>  monitor_printf(mon, "\t%s\n", s);
>  g_free(s);
>  }
> diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
> index 83f4bd6fd211..9f6f655fd526 100644
> --- a/util/qemu-sockets.c
> +++ b/util/qemu-sockets.c
> @@ -1077,6 +1077,26 @@ int unix_connect(const char *path, Error **errp)
>  return sock;
>  }
>
> +char *socket_uri(SocketAddress *addr)
> +{
> +switch (addr->type) {
> +case SOCKET_ADDRESS_TYPE_INET:
> +return g_strdup_printf("tcp:%s:%s",
> +   addr->u.inet.host,
> +   addr->u.inet.port);
> +case SOCKET_ADDRESS_TYPE_UNIX:
> +return g_strdup_printf("unix:%s",
> +   addr->u.q_unix.path);
> +case SOCKET_ADDRESS_TYPE_FD:
> +return g_strdup_printf("fd:%s", addr->u.fd.str);
> +case SOCKET_ADDRESS_TYPE_VSOCK:
> +return g_strdup_printf("tcp:%s:%s",
> +   addr->u.vsock.cid,
> +   addr->u.vsock.port);
> +default:
> +return g_strdup("unknown address type");
> +}
> +}
>
>  SocketAddress *socket_parse(const char *str, Error **errp)
>  {
> --
> 2.37.3
>
>
>

-- 
Marc-André Lureau

Re: [PATCH v14 13/17] qemu-sockets: move and rename SocketAddress_to_str()

[Philippe Mathieu-Daudé]

On 21/10/22 11:09, Laurent Vivier wrote:

Rename SocketAddress_to_str() to socket_uri() and move it to
util/qemu-sockets.c close to socket_parse().

socket_uri() generates a string from a SocketAddress while
socket_parse() generates a SocketAddress from a string.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Reviewed-by: Dr. David Alan Gilbert 
Acked-by: Michael S. Tsirkin 
---
  include/qemu/sockets.h |  2 +-
  monitor/hmp-cmds.c | 23 +--
  util/qemu-sockets.c| 20 
  3 files changed, 22 insertions(+), 23 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [4.17] RE: [PATCH v2] xen/arm: p2m: fix pa_range_info for 52-bit pa range

[Julien Grall]

On 21/10/2022 02:42, Henry Wang wrote:

Hi Julien and Xenia,


Hi Henry,



-Original Message-
From: Julien Grall 
; Henry Wang 
Subject: Re: [PATCH v2] xen/arm: p2m: fix pa_range_info for 52-bit pa range

(+ Henry)

Hi Xenia,

On 19/10/2022 15:49, Xenia Ragiadakou wrote:

Currently, the fields 'root_order' and 'sl0' of the pa_range_info for
the 52-bit pa range have the values 3 and 3, respectively.
This configuration does not match any of the valid root table configurations
for 4KB granule and t0sz 12, described in ARM DDI 0487I.a D8.2.7.

More specifically, according to ARM DDI 0487I.a D8.2.7, in order to support
the 52-bit pa size with 4KB granule, the p2m root table needs to be

configured

either as a single table at level -1 or as 16 concatenated tables at level 0.
Since, currently there is not support for level -1, set the 'root_order' an


Typo: s/not/no/ (I can fix it while committing)


'sl0' fields of the 52-bit pa_range_info according to the second approach.

Note that the values of those fields are not used so far. This patch updates
their values only for the sake of correctness.

Fixes: 407b13a71e32 ("xen/arm: p2m don't fall over on FEAT_LPA enabled

hw")

Signed-off-by: Xenia Ragiadakou 


Reviewed-by: Julien Grall 

Regarding 4.17, I am a bit split whether this should be included. On one
hand, it would be good to have the value correct (not that I expect
anymore to try using 52-bit on 4.17...). On the other hand, this is not
used so there is no bug (this could also be an argument to add it
because it is nearly risk free).

If we don't include it, I will definitely add in my list of potential
backports.

Henry, any thoughts?


I am actually monitoring this patch for the same question that if
we need this patch for 4.17.

I see no reason to exclude this patch since (1) we want to make sure
our code is correct (2) I am pretty sure we are not using 52 bit PA so
as indicated by commit message this patch is just for correctness and
no potential harm to include this patch in the release (probably even
backporting this patch till the 52 bit PA was introduced?).

So if you wouldn't mind committing this patch, you can of course have
my:


Thanks for the feedback. I am happy to commit it. So...



Release-acked-by: Henry Wang 


I have now done it with your tag added.

Cheers,

--
Julien Grall

Re: [PATCH-for-4.17] xen/sched: fix race in RTDS scheduler

[Juergen Gross]

On 21.10.22 11:37, Dario Faggioli wrote:

Ok, and now, something not really related to the bug being fixed here,
but about the code that is being touched:

On Fri, 2022-10-21 at 08:10 +0200, Juergen Gross wrote:

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index d6de25531b..960a8033e2 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1087,6 +1087,7 @@ rt_schedule(const struct scheduler *ops, struct
sched_unit *currunit,
  else if ( !unit_runnable_state(snext->unit) )
  {
  q_remove(snext);
+    replq_remove(ops, snext);
  snext = rt_unit(sched_idle_unit(sched_cpu));
  }
  

So, adding a few more context here, the code looks like this:

 snext = runq_pick(ops, cpumask_of(sched_cpu), cur_cpu);

 if ( snext == NULL )
 snext = rt_unit(sched_idle_unit(sched_cpu));
 else if ( !unit_runnable_state(snext->unit) )
 {
 q_remove(snext);
 snext = rt_unit(sched_idle_unit(sched_cpu));
 }

Basically, we've tried to pick-up the highest priority task from the
runqueue. If snext is NULL, the runqueue was just empty, so we pick up
idle (and then, later, we'll check whether the currently running unit
is still runnable; and if it is, we'll continue to run it, of course).

However, it can happen that --e.g., due to core-scheduling-- we picked
up a unit that, despite being in the runqueue, is not runnable. At this
point what we do is removing it from the runqueue (to avoid picking it
up again) and we go for idle.

Now, I may be missing/misremembering something, but it looks to me that
it's possible that there are other runnable units in the runqueue. And
if that's the case, why do we just pick idle and move on, instead of
continuing trying?

Juergen... Am I missing or misremembering any fundamental reason why we
cannot continue to scan the runqueue until the first runnable unit (if
any) is found?


No. This code was introduced in the RFC V2 series of core scheduling.
And it was not the result of a previous discussion on xen-devel.


Of course, this is not really related with the bug this patch is
fixing, which is correct and should be applied, no matter what the
outcome of this subthread will be. :-)


I can write another patch trying to fix that, but that shouldn't be
4.17 material IMHO.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] xen/arm: mark handle_linux_pci_domain() __init

[Julien Grall]

On 20/10/2022 19:56, Julien Grall wrote:

On 20/10/2022 19:53, Stewart Hildebrand wrote:

On 10/20/22 14:19, Julien Grall wrote:

Hi Stewart,


Hi Julien,


I nearly missed this one because it was threaded under v1. In the
future, would you be able to send new version in a separate thread? This
makes easier to track it.


I will keep this in mind for next time.


On 14/10/2022 21:09, Stewart Hildebrand wrote:

All functions in domain_build.c should be marked __init. This was
spotted when building the hypervisor with -Og.

Fixes: 1050a7b91c xen/arm: add pci-domain for disabled devices


I missed parenthesis and quotes around the referenced commit. To keep 
it in the same format as other Fixes: tags, can you please add during 
commit (pending release ack)?


Will do.


The commit ID was also too short. Xen (and Linux) moved to 12 characters 
because 10 is not enough anymore to uniquely distinguish a commit.


You can ask git to change its default value by adding the following 
lines in either the global config or per-repo one:


[core]
abbrev = 12

It is now committed.

Cheers,

--
Julien Grall

Re: [PATCH v14 15/17] net: stream: move to QIO to enable additional parameters

[Philippe Mathieu-Daudé]

On 21/10/22 11:09, Laurent Vivier wrote:

Use QIOChannel, QIOChannelSocket and QIONetListener.
This allows net/stream to use all the available parameters provided by
SocketAddress.

Signed-off-by: Laurent Vivier 
Acked-by: Michael S. Tsirkin 
---
  net/stream.c| 492 +---
  qemu-options.hx |   4 +-
  2 files changed, 178 insertions(+), 318 deletions(-)



-static void net_stream_accept(void *opaque)
+static void net_stream_server_listening(QIOTask *task, gpointer opaque)
  {
  NetStreamState *s = opaque;
-struct sockaddr_storage saddr;
-socklen_t len;
-int fd;
-
-for (;;) {
-len = sizeof(saddr);
-fd = qemu_accept(s->listen_fd, (struct sockaddr *), );
-if (fd < 0 && errno != EINTR) {
-return;
-} else if (fd >= 0) {
-qemu_set_fd_handler(s->listen_fd, NULL, NULL, NULL);
-break;
-}
-}
+QIOChannelSocket *listen_sioc = QIO_CHANNEL_SOCKET(s->listen_ioc);
+SocketAddress *addr;
+int ret;
  
-s->fd = fd;

-s->nc.link_down = false;
-net_stream_connect(s);
-switch (saddr.ss_family) {
-case AF_INET: {
-struct sockaddr_in *saddr_in = (struct sockaddr_in *)
-
-qemu_set_info_str(>nc, "connection from %s:%d",
-  inet_ntoa(saddr_in->sin_addr),
-  ntohs(saddr_in->sin_port));
-break;
+if (listen_sioc->fd < 0) {
+qemu_set_info_str(>nc, "connection error");
+return;
  }
-case AF_UNIX: {
-struct sockaddr_un saddr_un;
  
-len = sizeof(saddr_un);

-getsockname(s->listen_fd, (struct sockaddr *)_un, );
-qemu_set_info_str(>nc, "connect from %s", saddr_un.sun_path);
-break;
-}
-default:
-g_assert_not_reached();
+addr = qio_channel_socket_get_local_address(listen_sioc, NULL);
+g_assert(addr != NULL);


Missing propagating Error* (observed in v12).


+ret = qemu_socket_try_set_nonblock(listen_sioc->fd);
+if (addr->type == SOCKET_ADDRESS_TYPE_FD && ret < 0) {
+qemu_set_info_str(>nc, "can't use file descriptor %s (errno %d)",
+  addr->u.fd.str, -ret);
+return;
  }
+g_assert(ret == 0);
+qapi_free_SocketAddress(addr);
+
+s->nc.link_down = true;
+s->listener = qio_net_listener_new();
+
+net_socket_rs_init(>rs, net_stream_rs_finalize, false);
+qio_net_listener_set_client_func(s->listener, net_stream_listen, s, NULL);
+qio_net_listener_add(s->listener, listen_sioc);
  }
  
  static int net_stream_server_init(NetClientState *peer,

@@ -283,105 +286,61 @@ static int net_stream_server_init(NetClientState *peer,
  {
  NetClientState *nc;
  NetStreamState *s;
-int fd, ret;
+QIOChannelSocket *listen_sioc = qio_channel_socket_new();
  
-switch (addr->type) {

-case SOCKET_ADDRESS_TYPE_INET: {
-struct sockaddr_in saddr_in;
-
-if (convert_host_port(_in, addr->u.inet.host, addr->u.inet.port,
-  errp) < 0) {
-return -1;
-}
-
-fd = qemu_socket(PF_INET, SOCK_STREAM, 0);
-if (fd < 0) {
-error_setg_errno(errp, errno, "can't create stream socket");
-return -1;
-}
-qemu_socket_set_nonblock(fd);
+nc = qemu_new_net_client(_stream_info, peer, model, name);
+s = DO_UPCAST(NetStreamState, nc, nc);
  
-socket_set_fast_reuse(fd);

+s->listen_ioc = QIO_CHANNEL(listen_sioc);
+qio_channel_socket_listen_async(listen_sioc, addr, 0,
+net_stream_server_listening, s,
+NULL, NULL);
  
-ret = bind(fd, (struct sockaddr *)_in, sizeof(saddr_in));

-if (ret < 0) {
-error_setg_errno(errp, errno, "can't bind ip=%s to socket",
- inet_ntoa(saddr_in.sin_addr));
-closesocket(fd);
-return -1;
-}
-break;
-}
-case SOCKET_ADDRESS_TYPE_UNIX: {
-struct sockaddr_un saddr_un;
-
-ret = unlink(addr->u.q_unix.path);
-if (ret < 0 && errno != ENOENT) {
-error_setg_errno(errp, errno, "failed to unlink socket %s",
- addr->u.q_unix.path);
-return -1;
-}
+return 0;
+}
  
-saddr_un.sun_family = PF_UNIX;

-ret = snprintf(saddr_un.sun_path, sizeof(saddr_un.sun_path), "%s",
-   addr->u.q_unix.path);
-if (ret < 0 || ret >= sizeof(saddr_un.sun_path)) {
-error_setg(errp, "UNIX socket path '%s' is too long",
-   addr->u.q_unix.path);
-error_append_hint(errp, "Path must be less than %zu bytes\n",
-  sizeof(saddr_un.sun_path));
-return -1;
-}
+static void net_stream_client_connected(QIOTask *task, gpointer opaque)
+{
+NetStreamState *s 

Re: [PATCH 17/19] xen: don't free percpu areas during suspend

[Dario Faggioli]

On Fri, 2022-10-07 at 13:17 +0200, Juergen Gross wrote:
> On 07.10.22 12:32, Mykyta Poturai wrote:
> > 
> > Signed-off-by: Juergen Gross 
> 
> I can't remember having written this patch. The one I remember was
> for
> x86.
> 
> > Reviewed-by: Dario Faggioli 
> 
> I doubt that, reasoning see above.
> 
Right. In fact, I can't find any records of having sent an email with
such a tag... Or to have ever even replied to any patch sent from this
email address, for what matters.

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Stefano Brivio]

[Cc: Laine, full quote]

On Fri, 21 Oct 2022 11:12:20 +0200
Markus Armbruster  wrote:

> Cc: Stefano Brivio
> 
> Laurent Vivier  writes:
> 
> > On 10/21/22 07:48, Markus Armbruster wrote:  
> >> Laurent Vivier  writes:
> >>   
> >>> The netdev reports NETDEV_STREAM_CONNECTED event when the backend
> >>> is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.  
> >>
> >> Use cases?  
> >
> > This is asked by Stefano Brivio to allow libvirt to detect if connection to 
> > passt is lost and to restart passt.  
> 
> Let's add something like this to the commit message:
> 
> This lets libvirt notice when the connection is lost somehow, and
> restart the peer (such as passt).
> 
> Who's working on the libvirt part?

Laine Stump and myself. Nothing to show yet, though.

> > I have also a patch to add a "reconnect=seconds" option, but I didn't want 
> > to add it to this series.  
> 
> It's okay to mention future work in commit messages, but not required.
> 
> >> Could similar event signalling be useful for other kinds of netdev
> >> backends?  
> >
> > I was wondering, but it becomes more complicated to be generic.  
> 
> Making something complicated and generic where a simpler special
> solution would do is the worst.
> 
> Not quite as bad (but still plenty bad) is making a few special
> solutions first, then replace them all with a generic solution.
> 
> I believe we should have a good, hard think on possible applications of
> a generic solution now.
> 
> There is no need to hold back this series for that.
> 
> If we conclude a generic solution is called for, we better replace this
> special solution before it becomes ABI.  Either by replacing it before
> we release it, or by keeping it unstable until we replace it.

-- 
Stefano

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Markus Armbruster]

Laurent Vivier  writes:

> On 10/21/22 11:12, Markus Armbruster wrote:
>> Cc: Stefano Brivio
>> 
>> Laurent Vivier  writes:
>> 
>>> On 10/21/22 07:48, Markus Armbruster wrote:
 Laurent Vivier  writes:

> The netdev reports NETDEV_STREAM_CONNECTED event when the backend
> is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.

 Use cases?
>>>
>>> This is asked by Stefano Brivio to allow libvirt to detect if connection to 
>>> passt is lost and to restart passt.
>> 
>> Let's add something like this to the commit message:
>> 
>>  This lets libvirt notice when the connection is lost somehow, and
>>  restart the peer (such as passt).
>> 
>> Who's working on the libvirt part?
>> 
>>> I have also a patch to add a "reconnect=seconds" option, but I didn't want 
>>> to add it to this series.
>> 
>> It's okay to mention future work in commit messages, but not required.
>> 
 Could similar event signalling be useful for other kinds of netdev
 backends?
>>>
>>> I was wondering, but it becomes more complicated to be generic.
>> 
>> Making something complicated and generic where a simpler special
>> solution would do is the worst.
>> 
>> Not quite as bad (but still plenty bad) is making a few special
>> solutions first, then replace them all with a generic solution.
>> 
>> I believe we should have a good, hard think on possible applications of
>> a generic solution now.
>> 
>> There is no need to hold back this series for that.
>> 
>> If we conclude a generic solution is called for, we better replace this
>> special solution before it becomes ABI.  Either by replacing it before
>> we release it, or by keeping it unstable until we replace it.
>> 
>
> I sent the v14 few minutes before this email.
>
> Jason, perhaps we can remove PATCH 17 from the series and only merge PATCH 1 
> to 16?
>
> I will resend PATCH 17 in a new series with the reconnect option patch once 
> this series is 
> merged.

Certainly works for me.  Thanks for your patience!

Re: [PATCH-for-4.17] xen/sched: fix race in RTDS scheduler

[Dario Faggioli]

Ok, and now, something not really related to the bug being fixed here,
but about the code that is being touched:

On Fri, 2022-10-21 at 08:10 +0200, Juergen Gross wrote:
> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
> index d6de25531b..960a8033e2 100644
> --- a/xen/common/sched/rt.c
> +++ b/xen/common/sched/rt.c
> @@ -1087,6 +1087,7 @@ rt_schedule(const struct scheduler *ops, struct
> sched_unit *currunit,
>  else if ( !unit_runnable_state(snext->unit) )
>  {
>  q_remove(snext);
> +    replq_remove(ops, snext);
>  snext = rt_unit(sched_idle_unit(sched_cpu));
>  }
>  
So, adding a few more context here, the code looks like this:

snext = runq_pick(ops, cpumask_of(sched_cpu), cur_cpu);

if ( snext == NULL )
snext = rt_unit(sched_idle_unit(sched_cpu));
else if ( !unit_runnable_state(snext->unit) )
{
q_remove(snext);
snext = rt_unit(sched_idle_unit(sched_cpu));
}

Basically, we've tried to pick-up the highest priority task from the
runqueue. If snext is NULL, the runqueue was just empty, so we pick up
idle (and then, later, we'll check whether the currently running unit
is still runnable; and if it is, we'll continue to run it, of course).

However, it can happen that --e.g., due to core-scheduling-- we picked
up a unit that, despite being in the runqueue, is not runnable. At this
point what we do is removing it from the runqueue (to avoid picking it
up again) and we go for idle.

Now, I may be missing/misremembering something, but it looks to me that
it's possible that there are other runnable units in the runqueue. And
if that's the case, why do we just pick idle and move on, instead of
continuing trying?

Juergen... Am I missing or misremembering any fundamental reason why we
cannot continue to scan the runqueue until the first runnable unit (if
any) is found?

Of course, this is not really related with the bug this patch is
fixing, which is correct and should be applied, no matter what the
outcome of this subthread will be. :-)

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Laurent Vivier]

On 10/21/22 11:12, Markus Armbruster wrote:

Cc: Stefano Brivio

Laurent Vivier  writes:


On 10/21/22 07:48, Markus Armbruster wrote:

Laurent Vivier  writes:


The netdev reports NETDEV_STREAM_CONNECTED event when the backend
is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.


Use cases?


This is asked by Stefano Brivio to allow libvirt to detect if connection to 
passt is lost and to restart passt.


Let's add something like this to the commit message:

 This lets libvirt notice when the connection is lost somehow, and
 restart the peer (such as passt).

Who's working on the libvirt part?


I have also a patch to add a "reconnect=seconds" option, but I didn't want to 
add it to this series.


It's okay to mention future work in commit messages, but not required.


Could similar event signalling be useful for other kinds of netdev
backends?


I was wondering, but it becomes more complicated to be generic.


Making something complicated and generic where a simpler special
solution would do is the worst.

Not quite as bad (but still plenty bad) is making a few special
solutions first, then replace them all with a generic solution.

I believe we should have a good, hard think on possible applications of
a generic solution now.

There is no need to hold back this series for that.

If we conclude a generic solution is called for, we better replace this
special solution before it becomes ABI.  Either by replacing it before
we release it, or by keeping it unstable until we replace it.



I sent the v14 few minutes before this email.

Jason, perhaps we can remove PATCH 17 from the series and only merge PATCH 1 to 
16?

I will resend PATCH 17 in a new series with the reconnect option patch once this series is 
merged.


Thanks,
Laurent

[GIT PULL] xen: branch for v6.1-rc2

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.1-rc2-tag

xen: branch for v6.1-rc2

It contains just 2 fixes for the new "virtio with grants" feature.


Thanks.

Juergen

 drivers/xen/grant-dma-ops.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

Oleksandr Tyshchenko (2):
  xen/virtio: Handle cases when page offset > PAGE_SIZE properly
  xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts

Re: [PATCH-for-4.17] xen/sched: fix race in RTDS scheduler

[Dario Faggioli]

On Fri, 2022-10-21 at 08:10 +0200, Juergen Gross wrote:
> When a domain gets paused the unit runnable state can change to "not
> runnable" without the scheduling lock being involved. This means that
> a specific scheduler isn't involved in this change of runnable state.
> 
> In the RTDS scheduler this can result in an inconsistency in case a
> unit is losing its "runnable" capability while the RTDS scheduler's
> scheduling function is active. RTDS will remove the unit from the run
> queue, but doesn't do so for the replenish queue, leading to hitting
> an ASSERT() in replq_insert() later when the domain is unpaused
> again.
> 
> Fix that by removing the unit from the replenish queue as well in
> this
> case.
> 
Ah, ok... So, all is fine until what could happen during rt_schedule(),
was "just" that the currently running task, not only is descheduled,
but it also became !runnable.

In fact, in this case, the unit itself is not in the runq, but it can
be in the replq. However, since it still has the RTDS_scheduled flag
set, either:
1) we reach rt_context_saved(), which remove it from replq, before any 
   replq_insert;
2) rt_unit_wake() is called, but due to RTDS_scheduled, it may only do 
   replq_reinsert(), which is fine with the unit being already there.

However, what can also happen in rt_schedule() is that we remove from
the runq an unit that was not running, and hence does not have the
RTDS_scheduled flat set. In which case, rt_context_saved() doesn't do
anything to it (of course!). And as soon as rt_unit_wake() happens, it
does replq_insert(), which is not fine with finding the replenishment
event in the queue already.

So, yes... And good catch! :-P


> Fixes: 7c7b407e7772 ("xen/sched: introduce unit_runnable_state()")
> Signed-off-by: Juergen Gross 
>
Acked-by: Dario Faggioli 

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)


signature.asc
Description: This is a digitally signed message part

Report in downstream Debian: mpt3sas broken with xen dom0 with update to 5.10.149 in 5.10.y.

[Salvatore Bonaccorso]

Hi,

We got the following report in Debian after an update from 5.10.140 to
the current 5.10.149. Full quoting below (from
https://bugs.debian.org/1022126). Does this ring some bell about known
regressions?
On Thu, Oct 20, 2022 at 05:21:03PM +0200, Adi Kriegisch wrote:
> Package: linux-image-5.10.0-19-amd64
> Version: 5.10.149-1
> Severity: important
> 
> Dear maintainers,
> 
> with the upgrade to the latest bullseye kernel (5.10.149-1), our xen setup
> is unbootable due to swiotlb buffer errors:
>   | sd 0:0:0:0: scsi_dma_map failed: request for 401408 bytes!
> and
>   | mpt3sas :01:00.0: swiotlb buffer is full (sz: 401408 bytes),
>   | total 32768 (slots), used 0 (slots)
> (the byte sizes vary between boots).
> 
> After reading bug #850425[1], we also tried to force 32bit mode in the
> mpt3sas driver by specifying a dom0 memory below 4G; this lets the machine
> boot, but almost immediately after that fails with the same error. Notable
> difference is that the used slots are 128.
> 
> Xen commandline:
>   dom0_mem=4096M,max:4096M dom0_max_vcpus=4 dom0_vcpus_pin
>   ucode=scan xpti=dom0=false,domu=true gnttab_max_frames=128
> 
> Using dom0-iommu=map-inclusive in some combinations with swiotlb on the
> kernel commandline gives us some used slots (way below 128) in the error
> message even in 64bit dma mode in the mpt3sas driver.
> 
> The kernel works when booted without xen. We'd be more than happy to get
> pointers on how to fix that issue or patches to test!
> 
> Thanks for your help!
> 
> -- Adi
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425

Regards,
Salvatore

RE: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Henry Wang]

Hi Juergen,

> -Original Message-
> From: Juergen Gross 
> Subject: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing
> it
> 
> When the system is coming up after having been suspended,
> restore_vcpu_affinity() is called for each domain in order to adjust
> the vcpu's affinity settings in case a cpu didn't come to live again.
> 
> The way restore_vcpu_affinity() is doing that is wrong, because the
> specific scheduler isn't being informed about a possible migration of
> the vcpu to another cpu. Additionally the migration is often even
> happening if all cpus are running again, as it is done without check
> whether it is really needed.
> 
> As cpupool management is already calling cpu_disable_scheduler() for
> cpus not having come up again, and cpu_disable_scheduler() is taking
> care of eventually needed vcpu migration in the proper way, there is
> simply no need for restore_vcpu_affinity().
> 
> So just remove restore_vcpu_affinity() completely.
> 
> Fixes: 8a5d50dd0b04 ("xen: sched: simplify ACPI S3 resume path.")
> Reported-by: Marek Marczykowski-Górecki
> 
> Signed-off-by: Juergen Gross 

Release-acked-by: Henry Wang 

Kind regards,
Henry

Re: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Dario Faggioli]

On Fri, 2022-10-21 at 09:06 +0200, Juergen Gross wrote:
> On 21.10.22 08:58, Juergen Gross wrote:
> > When the system is coming up after having been suspended,
> > restore_vcpu_affinity() is called for each domain in order to
> > adjust
> > the vcpu's affinity settings in case a cpu didn't come to live
> > again.
> > 
> > The way restore_vcpu_affinity() is doing that is wrong, because the
> > specific scheduler isn't being informed about a possible migration
> > of
> > the vcpu to another cpu. Additionally the migration is often even
> > happening if all cpus are running again, as it is done without
> > check
> > whether it is really needed.
> > 
> > As cpupool management is already calling cpu_disable_scheduler()
> > for
> > cpus not having come up again, and cpu_disable_scheduler() is
> > taking
> > care of eventually needed vcpu migration in the proper way, there
> > is
> > simply no need for restore_vcpu_affinity().
> > 
> > So just remove restore_vcpu_affinity() completely.
> > 
> > Fixes: 8a5d50dd0b04 ("xen: sched: simplify ACPI S3 resume path.")
> 
> This Fixes: tag is wrong. It should be:
> 
> Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct
> sched_unit")
> 
Acked-by: Dario Faggioli 

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Markus Armbruster]

Cc: Stefano Brivio

Laurent Vivier  writes:

> On 10/21/22 07:48, Markus Armbruster wrote:
>> Laurent Vivier  writes:
>> 
>>> The netdev reports NETDEV_STREAM_CONNECTED event when the backend
>>> is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.
>>
>> Use cases?
>
> This is asked by Stefano Brivio to allow libvirt to detect if connection to 
> passt is lost and to restart passt.

Let's add something like this to the commit message:

This lets libvirt notice when the connection is lost somehow, and
restart the peer (such as passt).

Who's working on the libvirt part?

> I have also a patch to add a "reconnect=seconds" option, but I didn't want to 
> add it to this series.

It's okay to mention future work in commit messages, but not required.

>> Could similar event signalling be useful for other kinds of netdev
>> backends?
>
> I was wondering, but it becomes more complicated to be generic.

Making something complicated and generic where a simpler special
solution would do is the worst.

Not quite as bad (but still plenty bad) is making a few special
solutions first, then replace them all with a generic solution.

I believe we should have a good, hard think on possible applications of
a generic solution now.

There is no need to hold back this series for that.

If we conclude a generic solution is called for, we better replace this
special solution before it becomes ABI.  Either by replacing it before
we release it, or by keeping it unstable until we replace it.

Re: [PATCH v13 00/17] qapi: net: add unix socket type support to netdev backend

[Laurent Vivier]

On 10/21/22 08:50, Jason Wang wrote:

On Fri, Oct 21, 2022 at 2:46 PM Markus Armbruster  wrote:


Jason Wang  writes:


I've queued this version and will send pull requests shortly.

Any future comment we can do patches on top.


Please give Laurent and me a few hours to try to improve PATCH 17's
commit message.  Which you could then integrate without a respin.




I'm going to send a new version, only patches 15 and 17 change.
I moved some changes from PATCH 17 to 15 as asked by Markus,
I have updated the commit message for patch 17:

net: stream: add QAPI events to report connection state

The netdev reports NETDEV_STREAM_CONNECTED event when the backend
is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.

The NETDEV_STREAM_CONNECTED event includes the destination address.

This allows a system manager like libvirt to detect when the server
fails.

For instance with passt:

{ 'execute': 'qmp_capabilities' }
{ "return": { } }
{ "timestamp": { "seconds": 1666341395, "microseconds": 505347 },
"event": "NETDEV_STREAM_CONNECTED",
"data": { "netdev-id": "netdev0",
"addr": { "path": "/tmp/passt_1.socket", "type": "unix" } } }

[killing passt here]

{ "timestamp": { "seconds": 1666341430, "microseconds": 968694 },
"event": "NETDEV_STREAM_DISCONNECTED",
"data": { "netdev-id": "netdev0" } }

Thanks,
Laurent

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

[osstest service owner]

flight 174119 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174119/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-seattle  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-libvirt-qcow2 12 debian-di-install  fail REGR. vs. 172547
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 172547
 test-armhf-armhf-xl-arndale  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-xl  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-xl-credit2  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-xl-credit1  14 guest-start  fail REGR. vs. 172547
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 172547
 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 172547
 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 172547

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-i386  7 xen-installfail in 173987 pass in 174119
 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail in 174063 pass in 174119
 test-amd64-i386-xl-xsm7 xen-install  fail in 174063 pass in 174119
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail in 174063 pass in 174119
 test-arm64-arm64-xl-xsm  14 guest-startfail pass in 173987
 test-arm64-arm64-libvirt-xsm 14 guest-startfail pass in 173987
 test-arm64-arm64-libvirt-raw 12 debian-di-install  fail pass in 173987
 test-arm64-arm64-xl-credit2  14 guest-startfail pass in 174063
 test-arm64-arm64-xl-credit1  14 guest-startfail pass in 174063

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 14 guest-start  fail REGR. vs. 172547

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-vhd  12 debian-di-install   fail blocked in 172547
 test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 173987 never 
pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 173987 never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 173987 never 
pass
 test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 174063 never 
pass
 test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 174063 never 
pass
 test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 174063 never pass
 test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 174063 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172547
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172547
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172547
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172547
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172547
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   

Re: [PATCH] x86/xen: simplify sysenter and syscall setup

[Juergen Gross]

On 21.10.22 10:06, Andrew Cooper wrote:

On 20/10/2022 12:39, Borislav Petkov wrote:

On Thu, Oct 20, 2022 at 01:36:19PM +0200, Juergen Gross wrote:

xen_enable_sysenter() and xen_enable_syscall() can be simplified a lot.

Signed-off-by: Juergen Gross 
---
  arch/x86/xen/setup.c | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index cfa99e8f054b..0f33ed6d3a7b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -910,17 +910,9 @@ static int register_callback(unsigned type, const void 
*func)
  
  void xen_enable_sysenter(void)

  {
-   int ret;
-   unsigned sysenter_feature;
-
-   sysenter_feature = X86_FEATURE_SYSENTER32;
-
-   if (!boot_cpu_has(sysenter_feature))
-   return;
-
-   ret = register_callback(CALLBACKTYPE_sysenter, 
xen_entry_SYSENTER_compat);
-   if(ret != 0)
-   setup_clear_cpu_cap(sysenter_feature);
+   if (boot_cpu_has(X86_FEATURE_SYSENTER32) &&

Can you switch that and below to cpu_feature_enabled() while at it, pls?


Why?

This function (should) be called on the BSP only (because Xen's API lets
this be specified when starting APs).


No, this is true for the syscall callback only. the sysenter and the syscall32
callbacks can only be set via Xen tools or on the local cpu by registering.



Whether it's once, or one per cpu, it doesn't matter.


It does.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state

[Laurent Vivier]

On 10/21/22 07:48, Markus Armbruster wrote:

Laurent Vivier  writes:


The netdev reports NETDEV_STREAM_CONNECTED event when the backend
is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.


Use cases?


This is asked by Stefano Brivio to allow libvirt to detect if connection to passt is lost 
and to restart passt.


I have also a patch to add a "reconnect=seconds" option, but I didn't want to add it to 
this series.




Could similar event signalling be useful for other kinds of netdev
backends?


I was wondering, but it becomes more complicated to be generic.

Thanks,
Laurent

Re: [PATCH] x86/xen: simplify sysenter and syscall setup

[Andrew Cooper]

On 20/10/2022 12:39, Borislav Petkov wrote:
> On Thu, Oct 20, 2022 at 01:36:19PM +0200, Juergen Gross wrote:
>> xen_enable_sysenter() and xen_enable_syscall() can be simplified a lot.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  arch/x86/xen/setup.c | 23 ++-
>>  1 file changed, 6 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index cfa99e8f054b..0f33ed6d3a7b 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -910,17 +910,9 @@ static int register_callback(unsigned type, const void 
>> *func)
>>  
>>  void xen_enable_sysenter(void)
>>  {
>> -int ret;
>> -unsigned sysenter_feature;
>> -
>> -sysenter_feature = X86_FEATURE_SYSENTER32;
>> -
>> -if (!boot_cpu_has(sysenter_feature))
>> -return;
>> -
>> -ret = register_callback(CALLBACKTYPE_sysenter, 
>> xen_entry_SYSENTER_compat);
>> -if(ret != 0)
>> -setup_clear_cpu_cap(sysenter_feature);
>> +if (boot_cpu_has(X86_FEATURE_SYSENTER32) &&
> Can you switch that and below to cpu_feature_enabled() while at it, pls?

Why?

This function (should) be called on the BSP only (because Xen's API lets
this be specified when starting APs).

Whether it's once, or one per cpu, it doesn't matter.

cpu_feature_enabled() puts in an out-of-line thunk (which is what
actually gets used), and a patchable code section.

Text patching will happen at least once to orphan the out-of-line thunk,
probably after the last time it gets used, then then maybe again later
to clear the feature.  Even if you had several million CPUs, there's no
way the overhead of cpu_feature_enabled() is worth it here.

~Andrew

Re: [PATCH for-4.17] tools/ocaml/xenstored: fix live update exception

[Edwin Torok]

> On 21 Oct 2022, at 08:50, Christian Lindig  
> wrote:
> 
> 
> 
>> On 20 Oct 2022, at 17:54, Edwin Török  wrote:
>> 
>> During live update we will load the /tool/xenstored path from the previous 
>> binary,
>> and then try to mkdir /tool again which will fail with EEXIST.
>> Check for existence of the path before creating it.
>> 
>> The write call to /tool/xenstored should not need any changes
>> (and we do want to overwrite any previous path, in case it changed).
>> 
>> Prior to 7110192b1df6 live update would work only if the binary path was
>> specified, and with 7110192b1df6 and this live update also works when
>> no binary path is specified in `xenstore-control live-update`.
>> 
>> Fixes: 7110192b1df6 ("tools/oxenstored: Fix Oxenstored Live Update")
>> Signed-off-by: Edwin Török 
>> ---
>> tools/ocaml/xenstored/xenstored.ml | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tools/ocaml/xenstored/xenstored.ml 
>> b/tools/ocaml/xenstored/xenstored.ml
>> index fc90fcdeb5..3299fe73f7 100644
>> --- a/tools/ocaml/xenstored/xenstored.ml
>> +++ b/tools/ocaml/xenstored/xenstored.ml
>> @@ -353,7 +353,9 @@ let _ =
>>  ) in
>> 
>>  (* required for xenstore-control to detect availability of live-update 
>> *)
>> -Store.mkdir store Perms.Connection.full_rights (Store.Path.of_string 
>> "/tool");
>> +let tool_path = Store.Path.of_string "/tool" in
>> +if not (Store.path_exists store tool_path) then
>> +Store.mkdir store 
>> Perms.Connection.full_rights tool_path;
>>  Store.write store Perms.Connection.full_rights
>>  (Store.Path.of_string "/tool/xenstored") Sys.executable_name;
> 
> I notice inconsistent indentation but let's ignore that or fix it before the 
> committing.
> 
> Acked-by: Christian Lindig 
> 


Thanks, fixed indentation here: 
https://github.com/edwintorok/xen/commit/4a89f1f44cb171e1f92dae2401a580a10fd0c5a0
And v2 patch should show up on the ML with the 2 acks included and fixed 
indentation soon too.

Best regards,
--Edwin

[PATCH for-4.17 v2] tools/ocaml/xenstored: fix live update exception

[Edwin Török]

During live update we will load the /tool/xenstored path from the previous 
binary,
and then try to mkdir /tool again which will fail with EEXIST.
Check for existence of the path before creating it.

The write call to /tool/xenstored should not need any changes
(and we do want to overwrite any previous path, in case it changed).

Prior to 7110192b1df6 live update would work only if the binary path was
specified, and with 7110192b1df6 and this live update also works when
no binary path is specified in `xenstore-control live-update`.

Fixes: 7110192b1df6 ("tools/oxenstored: Fix Oxenstored Live Update")
Signed-off-by: Edwin Török 
Acked-by: Christian Lindig 
Release-acked-by: Henry Wang 
---
 tools/ocaml/xenstored/xenstored.ml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/ocaml/xenstored/xenstored.ml 
b/tools/ocaml/xenstored/xenstored.ml
index fc90fcdeb5..acc7290627 100644
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -353,7 +353,9 @@ let _ =
) in
 
(* required for xenstore-control to detect availability of live-update 
*)
-   Store.mkdir store Perms.Connection.full_rights (Store.Path.of_string 
"/tool");
+   let tool_path = Store.Path.of_string "/tool" in
+   if not (Store.path_exists store tool_path) then
+   Store.mkdir store Perms.Connection.full_rights tool_path;
Store.write store Perms.Connection.full_rights
(Store.Path.of_string "/tool/xenstored") Sys.executable_name;
 

base-commit: 0c06760be3dc3f286015e18c4b1d1694e55da026
-- 
2.34.1

Re: [PATCH for-4.17] tools/ocaml/xenstored: fix live update exception

[Christian Lindig]

> On 20 Oct 2022, at 17:54, Edwin Török  wrote:
> 
> During live update we will load the /tool/xenstored path from the previous 
> binary,
> and then try to mkdir /tool again which will fail with EEXIST.
> Check for existence of the path before creating it.
> 
> The write call to /tool/xenstored should not need any changes
> (and we do want to overwrite any previous path, in case it changed).
> 
> Prior to 7110192b1df6 live update would work only if the binary path was
> specified, and with 7110192b1df6 and this live update also works when
> no binary path is specified in `xenstore-control live-update`.
> 
> Fixes: 7110192b1df6 ("tools/oxenstored: Fix Oxenstored Live Update")
> Signed-off-by: Edwin Török 
> ---
> tools/ocaml/xenstored/xenstored.ml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/xenstored/xenstored.ml 
> b/tools/ocaml/xenstored/xenstored.ml
> index fc90fcdeb5..3299fe73f7 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -353,7 +353,9 @@ let _ =
>   ) in
> 
>   (* required for xenstore-control to detect availability of live-update 
> *)
> - Store.mkdir store Perms.Connection.full_rights (Store.Path.of_string 
> "/tool");
> + let tool_path = Store.Path.of_string "/tool" in
> + if not (Store.path_exists store tool_path) then
> + Store.mkdir store 
> Perms.Connection.full_rights tool_path;
>   Store.write store Perms.Connection.full_rights
>   (Store.Path.of_string "/tool/xenstored") Sys.executable_name;

I notice inconsistent indentation but let's ignore that or fix it before the 
committing.

Acked-by: Christian Lindig 

Re: [PATCH for-4.17] tools/oxenstored: Fix Oxenstored Live Update

[Christian Lindig]

On 20 Oct 2022, at 17:56, Edwin Torok 
mailto:edvin.to...@citrix.com>> wrote:

Further testing has revealed another bug, patch here:
https://lore.kernel.org/xen-devel/12d90632bf881e96e0b6c256df193f00df187dc1.1666284745.git.edvin.to...@citrix.com/T/#u

For convenience the commit is also available from git:
https://github.com/edwintorok/xen/commit/12d90632bf881e96e0b6c256df193f00df187dc1

With both of these patches a smoketest 'xenstore-control live-update' with a 
stopped toolstack works now.

Acked-by: Christian Lindig 
mailto:christian.lin...@citrix.com>>

Re: [PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Juergen Gross]

On 21.10.22 08:58, Juergen Gross wrote:

When the system is coming up after having been suspended,
restore_vcpu_affinity() is called for each domain in order to adjust
the vcpu's affinity settings in case a cpu didn't come to live again.

The way restore_vcpu_affinity() is doing that is wrong, because the
specific scheduler isn't being informed about a possible migration of
the vcpu to another cpu. Additionally the migration is often even
happening if all cpus are running again, as it is done without check
whether it is really needed.

As cpupool management is already calling cpu_disable_scheduler() for
cpus not having come up again, and cpu_disable_scheduler() is taking
care of eventually needed vcpu migration in the proper way, there is
simply no need for restore_vcpu_affinity().

So just remove restore_vcpu_affinity() completely.

Fixes: 8a5d50dd0b04 ("xen: sched: simplify ACPI S3 resume path.")


This Fixes: tag is wrong. It should be:

Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct sched_unit")


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH-for-4.17] xen/sched: fix restore_vcpu_affinity() by removing it

[Juergen Gross]

When the system is coming up after having been suspended,
restore_vcpu_affinity() is called for each domain in order to adjust
the vcpu's affinity settings in case a cpu didn't come to live again.

The way restore_vcpu_affinity() is doing that is wrong, because the
specific scheduler isn't being informed about a possible migration of
the vcpu to another cpu. Additionally the migration is often even
happening if all cpus are running again, as it is done without check
whether it is really needed.

As cpupool management is already calling cpu_disable_scheduler() for
cpus not having come up again, and cpu_disable_scheduler() is taking
care of eventually needed vcpu migration in the proper way, there is
simply no need for restore_vcpu_affinity().

So just remove restore_vcpu_affinity() completely.

Fixes: 8a5d50dd0b04 ("xen: sched: simplify ACPI S3 resume path.")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 xen/arch/x86/acpi/power.c |  3 --
 xen/common/sched/core.c   | 70 ---
 xen/include/xen/sched.h   |  1 -
 3 files changed, 74 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 1bb4d78392..b76f673acb 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -159,10 +159,7 @@ static void thaw_domains(void)
 
 rcu_read_lock(_read_lock);
 for_each_domain ( d )
-{
-restore_vcpu_affinity(d);
 domain_unpause(d);
-}
 rcu_read_unlock(_read_lock);
 }
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 83455fbde1..358fa077e3 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -1196,76 +1196,6 @@ static void sched_reset_affinity_broken(const struct 
sched_unit *unit)
 v->affinity_broken = false;
 }
 
-void restore_vcpu_affinity(struct domain *d)
-{
-unsigned int cpu = smp_processor_id();
-struct sched_unit *unit;
-
-ASSERT(system_state == SYS_STATE_resume);
-
-rcu_read_lock(_res_rculock);
-
-for_each_sched_unit ( d, unit )
-{
-spinlock_t *lock;
-unsigned int old_cpu = sched_unit_master(unit);
-struct sched_resource *res;
-
-ASSERT(!unit_runnable(unit));
-
-/*
- * Re-assign the initial processor as after resume we have no
- * guarantee the old processor has come back to life again.
- *
- * Therefore, here, before actually unpausing the domains, we should
- * set v->processor of each of their vCPUs to something that will
- * make sense for the scheduler of the cpupool in which they are in.
- */
-lock = unit_schedule_lock_irq(unit);
-
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
-{
-if ( sched_check_affinity_broken(unit) )
-{
-sched_set_affinity(unit, unit->cpu_hard_affinity_saved, NULL);
-sched_reset_affinity_broken(unit);
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-}
-
-if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
-{
-/* Affinity settings of one vcpu are for the complete unit. */
-printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
-   unit->vcpu_list);
-sched_set_affinity(unit, _all, NULL);
-cpumask_and(cpumask_scratch_cpu(cpu), unit->cpu_hard_affinity,
-cpupool_domain_master_cpumask(d));
-}
-}
-
-res = get_sched_res(cpumask_any(cpumask_scratch_cpu(cpu)));
-sched_set_res(unit, res);
-
-spin_unlock_irq(lock);
-
-/* v->processor might have changed, so reacquire the lock. */
-lock = unit_schedule_lock_irq(unit);
-res = sched_pick_resource(unit_scheduler(unit), unit);
-sched_set_res(unit, res);
-spin_unlock_irq(lock);
-
-if ( old_cpu != sched_unit_master(unit) )
-sched_move_irqs(unit);
-}
-
-rcu_read_unlock(_res_rculock);
-
-domain_update_node_affinity(d);
-}
-
 /*
  * This function is used by cpu_hotplug code via cpu notifier chain
  * and from cpupools to switch schedulers on a cpu.
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 557b3229f6..072e4846aa 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1019,7 +1019,6 @@ void vcpu_set_periodic_timer(struct vcpu *v, s_time_t 
value);
 void sched_setup_dom0_vcpus(struct domain *d);
 int vcpu_temporary_affinity(struct vcpu *v, unsigned int cpu, uint8_t reason);
 int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity);
-void restore_vcpu_affinity(struct domain *d);
 int vcpu_affinity_domctl(struct domain *d, uint32_t cmd,
 

Re: [PATCH v13 00/17] qapi: net: add unix socket type support to netdev backend

[Jason Wang]

On Fri, Oct 21, 2022 at 2:46 PM Markus Armbruster  wrote:
>
> Jason Wang  writes:
>
> > I've queued this version and will send pull requests shortly.
> >
> > Any future comment we can do patches on top.
>
> Please give Laurent and me a few hours to try to improve PATCH 17's
> commit message.  Which you could then integrate without a respin.

Ok.

Thanks

>

Re: [PATCH] x86/xen: silence smatch warning in pmu_msr_chk_emulated()

[Dan Carpenter]

On Thu, Oct 20, 2022 at 10:22:17AM -0400, Boris Ostrovsky wrote:
> 
> On 10/20/22 9:34 AM, Juergen Gross wrote:
> > On 20.10.22 15:16, Jan Beulich wrote:
> > > On 20.10.2022 13:37, Juergen Gross wrote:
> > > > Commit 8714f7bcd3c2 ("xen/pv: add fault recovery control to pmu msr
> > > > accesses") introduced code resulting in a warning issued by the smatch
> > > > static checker, claiming to use an uninitialized variable.
> > > > 
> > > > This is a false positive, but work around the warning nevertheless.
> > > 
> > > The risk of introducing a problem might be quite low here, but in general
> > > it exists: With the adjustment you remove any chance of the compiler
> > > spotting a missing initialization before use. And I'm not convinced using
> > > 0 in such a case would actually be ending up sufficiently benign.
> > 
> > Hmm, an alternative would be to initialize it to -1 and add a test for the
> > index to be >= 0 before using it.
> > 
> > Or to live with the smash warning with the chance, that a compiler might be
> > warning for the same reason in the future.
> 
> 
> Is smatch complaining about both variables or just index?

Just "index".

> There are two cases in is_intel_pmu_msr() where it returns true but
> index is not set so perhaps that's what bothers smatch?

Yep.  The "index" variable *is* undefined when it's passed so Smatch
is correct in what it's saying.  But it's is not used on that path
inside the function so it's harmless.

> It shold not complain if is_intel_pmu_msr() returns false.

Correct.

I kind of like the patch.  We generally say "fix the checker and don't
silence the warning" but in this case I feel like the checker is doing
the best possible thing and I'm not going to fix it.  Trying to silence
this warning in Smatch would come with some real downsides.

regards,
dan carpenter