Re: [PATCH v2] misra: add R21.1 R21.2

[Jan Beulich]

On 14.11.2023 23:59, Stefano Stabellini wrote:
> Add 21.1 and 21.2, with a longer comment to explain how strategy with
> leading underscores and why we think we are safe today.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Jan Beulich 
with one nit:

> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -519,6 +519,28 @@ maintainers if you want to suggest a change.
> they are related
>   -
>  
> +   * - `Rule 21.1 
> `_
> + - Required
> + - #define and #undef shall not be used on a reserved identifier or
> +   reserved macro name
> + - Identifiers starting with an underscore followed by another underscore
> +   or an upper-case letter are reserved. Today Xen uses many, such as
> +   header guards and bitwise manipulation functions. Upon analysis it 
> turns
> +   out Xen identifiers do not clash with the identifiers used by modern
> +   GCC, but that is not a guarantee that there won't be a naming clash in
> +   the future or with another compiler.  For these reasons we discourage
> +   the introduction of new reserved identifiers in Xen, and we see it as
> +   positive the reduction of reserved identifiers. At the same time,
> +   certain identifiers starting with an underscore are also commonly used
> +   in Linux (e.g. __set_bit) and we don't think it would be an 
> improvement
> +   to rename them.

I think this last sentence would also better say "two underscores".

Jan

Re: [PATCH 4/5] tools/xenstored: remove "-N" command line option

[Edwin Torok]

> On 14 Nov 2023, at 22:11, Andrew Cooper  wrote:
> 
> On 13/11/2023 12:43 pm, Juergen Gross wrote:
>> The "-N" (do not daemonize) command line option is of questionable use:
>> its sole purpose seems to be to aid debugging of xenstored by making it
>> easier to start xenstored under gdb, or to see any debug messages
>> easily.
>> 
>> Debug messages can as well be sent to syslog(), while gdb can be
>> attached to the daemon easily. The only not covered case is an error
>> while initializing xenstored, but this could be handled e.g. by saving
>> a core dump, which can be analyzed later.
>> 
>> The call of talloc_enable_leak_report_full() done only with "-N"
>> specified is no longer needed, as the same can be achieved via
>> "xenstore-control memreport".
>> 
>> Signed-off-by: Juergen Gross 
> 
> CC Edvin.
> 
> There's a patch out to specifically use this option (under systemd) to
> fix a bug we found.
> 
> I can't recall the details, but I seem to recall it wasn't specific to
> oxenstored.
> 


The patch is here 
https://lore.kernel.org/xen-devel/ecfa15a7-9dc8-4476-8d0b-44a6d1219...@cloud.com/

It is about not losing stderr when run under systemd (well you can use syslog 
but what if your connection to syslog fails or you fail before getting to the 
point of parsing which syslog to use). 
Alternatively we could have a "don't redirect stderr to /dev/null" flag,
but such redirections are usually expected when daemonizing.

It'd be good if the --no-fork flag could be retained for C xenstored, currently 
there is a CI failure on a non-systemd system that I'm trying to fix (a bit 
blindly because I don't have such a system myself), but from my testing the 
flag does work on a systemd system with C xenstored.

The patch is motivated by having some undebuggable issues in oxenstored where 
it just exits without writing any messages and without dumping core, so by 
retaining the stderr path we should have an output of last resort in case 
something goes so wrong that the syslog error handler cannot function.

Best regards,
--Edwin

Re: [PATCH v3] xen/asm-generic: ifdef inclusion of

[Oleksii]

On Tue, 2023-11-14 at 18:19 +0100, Jan Beulich wrote:
> On 14.11.2023 16:13, Oleksii Kurochko wrote:
> > ifdefing inclusion of  in 
> > allows to avoid generation of empty  header
> > for the case when !CONFIG_MEM_ACCESS.
> > 
> > For Arm it was explicitly added inclusion of  for
> > p2m.c
> > and traps.c because they require some functions from
> >  which
> > aren't available in case of !CONFIG_MEM_ACCESS.
> > 
> > Suggested-by: Jan Beulich 
> > Signed-off-by: Oleksii Kurochko 
> > 
> > ---
> > This patch was part of patch series:
> > https://lore.kernel.org/xen-devel/cover.1699633310.git.oleksii.kuroc...@gmail.com/
> > 
> > The patch series hasn't been reviewed all yet so send this path
> > separately.
> > ---
> >  xen/arch/arm/p2m.c   | 6 ++
> >  xen/arch/arm/traps.c | 6 ++
> >  xen/include/xen/mem_access.h | 2 ++
> >  3 files changed, 14 insertions(+)
> 
> Also drop PPC's then dead header, please.
Sure. Missed that. I'll do that.
> 
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -11,6 +11,12 @@
> >  #include 
> >  #include 
> >  #include 
> > +/*
> > + * Inclusion of  in  is #ifdef-
> > ed with
> > + * CONFIG_MEM_ACCESS so in case of !CONFIG_MEM_ACCESS will cause a
> > compilation
> > + * issue "implicit declaration of functions 'p2m_mem_access*'.
> > + */
> > +#include 
> 
> Personally I'm against such comments (they simply don't scale), but
> this
> is Arm code, so Arm folks will need to judge.
The comment can be removed. Probably it is enough to have an
explanation in the commit message.


Thanks.

~ Oleksii

[xen-4.18-testing test] 183754: tolerable FAIL - PUSHED

[osstest service owner]

flight 183754 xen-4.18-testing real [real]
flight 183761 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183754/
http://logs.test-lab.xenproject.org/osstest/logs/183761/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 windows-install fail pass in 
183761-retest

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop   fail in 183761 like 183744
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183744
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183744
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183744
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183744
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183744
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183744
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183744
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183744
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183744
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183744
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183744
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   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-amd64-i386-libvirt-raw  14 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-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-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-libvirt-xsm 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-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 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-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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
 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  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 xen  2185851bbf72123ea76c9ce26e0c3a4d1a0ab8b0
baseline version:
 xen  509f737d3e80c75f948eb896a08c324287b00adc

Last test of basis   183744  2023-11-13 15:

Re: [PATCH 4/5] tools/xenstored: remove "-N" command line option

[Juergen Gross]

On 15.11.23 09:31, Edwin Torok wrote:




On 14 Nov 2023, at 22:11, Andrew Cooper  wrote:

On 13/11/2023 12:43 pm, Juergen Gross wrote:

The "-N" (do not daemonize) command line option is of questionable use:
its sole purpose seems to be to aid debugging of xenstored by making it
easier to start xenstored under gdb, or to see any debug messages
easily.

Debug messages can as well be sent to syslog(), while gdb can be
attached to the daemon easily. The only not covered case is an error
while initializing xenstored, but this could be handled e.g. by saving
a core dump, which can be analyzed later.

The call of talloc_enable_leak_report_full() done only with "-N"
specified is no longer needed, as the same can be achieved via
"xenstore-control memreport".

Signed-off-by: Juergen Gross 


CC Edvin.

There's a patch out to specifically use this option (under systemd) to
fix a bug we found.

I can't recall the details, but I seem to recall it wasn't specific to
oxenstored.




The patch is here 
https://lore.kernel.org/xen-devel/ecfa15a7-9dc8-4476-8d0b-44a6d1219...@cloud.com/

It is about not losing stderr when run under systemd (well you can use syslog 
but what if your connection to syslog fails or you fail before getting to the 
point of parsing which syslog to use).
Alternatively we could have a "don't redirect stderr to /dev/null" flag,
but such redirections are usually expected when daemonizing.

It'd be good if the --no-fork flag could be retained for C xenstored, currently 
there is a CI failure on a non-systemd system that I'm trying to fix (a bit 
blindly because I don't have such a system myself), but from my testing the 
flag does work on a systemd system with C xenstored.

The patch is motivated by having some undebuggable issues in oxenstored where 
it just exits without writing any messages and without dumping core, so by 
retaining the stderr path we should have an output of last resort in case 
something goes so wrong that the syslog error handler cannot function.


Using the --no-fork as in your patch would mean that setting the oom_score in
the lauch_xenstore script wouldn't be executed any longer, right?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 07/15] xen/asm-generic: introduce stub header

[Jan Beulich]

On 10.11.2023 17:30, Oleksii Kurochko wrote:
>  is common for Arm, PPC and RISC-V thereby it
> is moved to asm-generic.

When you say "moved", ...

> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
>  - update the commit messages
> ---
>  xen/include/asm-generic/random.h | 20 
>  1 file changed, 20 insertions(+)
>  create mode 100644 xen/include/asm-generic/random.h

... you also want to actually move things.

Since the above comment matches ones on earlier patches, yet otoh in your
submissions of two individual patches you mentioned you sent them
separately because this series wasn't fully reviewed yet, would you mind
clarifying whether further going through this version of the series is
actually going to be a good use of time?

Jan

Re: [PATCH v2 13/15] xen/asm-generic: introduce stub header monitor.h

[Jan Beulich]

On 10.11.2023 17:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/monitor.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * include/asm-GENERIC/monitor.h
> + *
> + * Arch-specific monitor_op domctl handler.
> + *
> + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> + * Copyright (c) 2016, Bitdefender S.R.L.
> + *
> + */
> +
> +#ifndef __ASM_GENERIC_MONITOR_H__
> +#define __ASM_GENERIC_MONITOR_H__
> +
> +#include 

What is this needed for? I expect ...

> +struct xen_domctl_monitor_op;
> +
> +static inline
> +void arch_monitor_allow_userspace(struct domain *d, bool allow_userspace)

... struct domain, but since you never de-reference any such pointer, forward-
declaring that (just like struct xen_domctl_monitor_op) would do here. Which
would leave you with needing at most xen/types.h, but maybe as little as
xen/stdbool.h and xen/stdint.h.

Jan

> +{
> +}
> +
> +static inline
> +int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op 
> *mop)
> +{
> +/* No arch-specific monitor ops on GENERIC. */
> +return -EOPNOTSUPP;
> +}
> +
> +int arch_monitor_domctl_event(struct domain *d,
> +  struct xen_domctl_monitor_op *mop);
> +
> +static inline
> +int arch_monitor_init_domain(struct domain *d)
> +{
> +/* No arch-specific domain initialization on GENERIC. */
> +return 0;
> +}
> +
> +static inline
> +void arch_monitor_cleanup_domain(struct domain *d)
> +{
> +/* No arch-specific domain cleanup on GENERIC. */
> +}
> +
> +static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
> +{
> +return 0;
> +}
> +
> +#endif /* __ASM_GENERIC_MONITOR_H__ */
> +
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: BSD
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Re: [PATCH v2 14/15] xen/asm-generic: introduce stub header numa.h

[Jan Beulich]

On 10.11.2023 17:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/numa.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ARCH_GENERIC_NUMA_H
> +#define __ARCH_GENERIC_NUMA_H
> +
> +#include 
> +#include 

I'm afraid I can't spot what you need these for here. You clearly need
xen/stdint.h, and you need xen/mm-frame.h for mfn_t. Yes, max_page is
declared in xen/mm.h, but its questionable whether the header needs
including here for that reason, as all uses are in macros. (We aren't
anywhere near consistent in this regard). Plus you don't also include
xen/cpumask.h to pull in cpu_online_map (which another macro
references).

> +typedef uint8_t nodeid_t;
> +
> +#ifndef CONFIG_NUMA

Isn't it an error to include this header when NUMA=y?

> +/* Fake one node for now. See also node_online_map. */
> +#define cpu_to_node(cpu) 0
> +#define node_to_cpumask(node)   (cpu_online_map)
> +
> +/*
> + * TODO: make first_valid_mfn static when NUMA is supported on Arm, this
> + * is required because the dummy helpers are using it.
> + */
> +extern mfn_t first_valid_mfn;
> +
> +/* XXX: implement NUMA support */
> +#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn))
> +#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
> +#define __node_distance(a, b) (20)
> +
> +#endif
> +
> +#define arch_want_default_dmazone() (false)
> +
> +#endif /* __ARCH_GENERIC_NUMA_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Re: xen | Failed pipeline for staging-4.17 | 28f44b60

[Jan Beulich]

On 14.11.2023 21:26, GitLab wrote:
> 
> 
> Pipeline #1072370735 has failed!
> 
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging-4.17 ( 
> https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
> 
> Commit: 28f44b60 ( 
> https://gitlab.com/xen-project/xen/-/commit/28f44b603fd86c233726bdc2a11b6325f102471a
>  )
> Commit Message: xen/grant: Fix build in PV_SHIM
> 
> There was a va...
> Commit Author: Andrew Cooper ( https://gitlab.com/andyhhp )
> 
> 
> Pipeline #1072370735 ( 
> https://gitlab.com/xen-project/xen/-/pipelines/1072370735 ) triggered by 
> Ganis ( https://gitlab.com/ganis )
> had 4 failed jobs.
> 
> Job #5534997591 ( https://gitlab.com/xen-project/xen/-/jobs/5534997591/raw )
> 
> Stage: build
> Name: ubuntu-focal-gcc-debug
> Job #5534997608 ( https://gitlab.com/xen-project/xen/-/jobs/5534997608/raw )
> 
> Stage: build
> Name: alpine-3.12-gcc-debug
> Job #5534997597 ( https://gitlab.com/xen-project/xen/-/jobs/5534997597/raw )
> 
> Stage: build

These three failed due to (once again) too little disk space.

> Name: opensuse-leap-clang-debug
> Job #5534997599 ( https://gitlab.com/xen-project/xen/-/jobs/5534997599/raw )
> 
> Stage: build
> Name: opensuse-leap-gcc-debug

Here it's unclear, as the log referenced ends too early.

Jan

Re: [PATCH v2] xen: remove

[Jan Beulich]

On 31.10.2023 15:28, Oleksii Kurochko wrote:
>  only declares udelay() function so udelay()
> declaration was moved to xen/delay.h.
> 
> For x86, __udelay() was renamed to udelay() and removed
> inclusion of  in x86 code.
> 
> For ppc, udelay() stub definition was moved to ppc/stubs.c.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Oleksii Kurochko 
> Reviewed-by: Jan Beulich 
> ---
> Changes in v2:
>  - rebase on top of the latest staging.
>  - add Suggested-by:/Reviewed-by: Jan Beulich .
>  - remove  for PPC.
>  - remove changes related to RISC-V's  as they've not
>introduced in staging branch yet.
> ---
>  xen/arch/arm/include/asm/delay.h  | 14 --
>  xen/arch/ppc/include/asm/delay.h  | 12 
>  xen/arch/ppc/stubs.c  |  7 +++
>  xen/arch/x86/cpu/microcode/core.c |  2 +-
>  xen/arch/x86/delay.c  |  2 +-
>  xen/arch/x86/include/asm/delay.h  | 13 -
>  xen/include/xen/delay.h   |  2 +-
>  7 files changed, 10 insertions(+), 42 deletions(-)
>  delete mode 100644 xen/arch/arm/include/asm/delay.h
>  delete mode 100644 xen/arch/ppc/include/asm/delay.h
>  delete mode 100644 xen/arch/x86/include/asm/delay.h

Shawn: As per the diffstat below your ack is needed here. Recently I did
(silently) time out on two sufficiently trivial (PPC-wise) patches, but
this shouldn't become a common pattern.

Oleksii: It is normally on the submitter to chase missing acks.

Jan

Re: [XEN PATCH v4 1/2] automation/eclair: make the docs for MISRA C:2012 Dir 4.1 visible to ECLAIR

[Nicola Vetrini]

On 2023-11-14 23:12, Julien Grall wrote:

Hi,

On 14/11/2023 15:36, Nicola Vetrini wrote:

To be able to check for the existence of the necessary subsections in
the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a 
source

file that is built.

This file is generated from 'C-runtime-failures.rst' in docs/misra
and the configuration is updated accordingly.

Signed-off-by: Nicola Vetrini 
---
Changes from RFC:
- Dropped unused/useless code
- Revised the sed command
- Revised the clean target

Changes in v2:
- Added explanative comment to the makefile
- printf instead of echo

Changes in v3:
- Terminate the generated file with a newline
- Build it with -std=c99, so that the documentation
   for D1.1 applies.
Changes in v5:
- Transform and build the file directly in the eclair-specific 
directory

---
  automation/eclair_analysis/build.sh   | 21 +++--
  automation/eclair_analysis/prepare.sh |  7 ---
  2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/automation/eclair_analysis/build.sh 
b/automation/eclair_analysis/build.sh

index ec087dd822fa..f24292ed0643 100755
--- a/automation/eclair_analysis/build.sh
+++ b/automation/eclair_analysis/build.sh
@@ -33,12 +33,29 @@ else
PROCESSORS=6
  fi
  +runtime_failures_docs() {
+  doc="C-runtime-failures.rst"
+  builddir="automation/eclair_analysis"
+
+  cp "docs/misra/${doc}" "${builddir}"


Is it necessary to copy the .rst? IOW, would it be sufficient to use...


+  cd "${builddir}"
+  printf "/*\n\n" >"${doc}.tmp"
+  sed -e 's|\*/|*//*|g' "${doc}" >>"${doc}.tmp"


... docs/misc/${doc} here?



I didn't want to leave a stray file under docs/misra, but it's not 
essential.



+  printf "\n\n*/\n" >>"${doc}.tmp"
+  mv "${doc}.tmp" "${doc}.c"


NIT: I am not sure why you need to first create .tmp and then create.c.



Wasn't this a pattern to defend against interruptions of the build, just 
as I did in v3?


+$(TARGETS:.o=.c): %.c: %.rst
+printf "/*\n\n" > $@.tmp
+sed -e 's|\*/|*//*|g' $< >> $@.tmp
+printf "\n\n*/\n" >> $@.tmp
+mv $@.tmp $@


+
+  # Cannot redirect to /dev/null because it would be excluded from 
the analysis

+  "${CROSS_COMPILE}gcc-12" -std=c99 -c "${doc}.c" -o "${doc}.o"


NIT: It would be helpful to specify why -std=c99 is used. Above, you 
suggest this is to enable D1.1.




Yeah, the comment in the changelog should be pasted here


NIT: Can we define CC and use here and ...


+  cd -
+}
+
  (
-  cd xen
+  runtime_failures_docs
  make "-j${PROCESSORS}" "-l${PROCESSORS}.0"\
 "CROSS_COMPILE=${CROSS_COMPILE}" \
 "CC=${CROSS_COMPILE}gcc-12"  \


...? This would make easier to re-use the code.



I don't expect this build script to be changed much to be honest, but if 
you think

this is beneficial then it's ok.


 "CXX=${CROSS_COMPILE}g++-12" \
-   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}"
+   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}" \
+   -C xen
  )
diff --git a/automation/eclair_analysis/prepare.sh 
b/automation/eclair_analysis/prepare.sh

index 0cac5eba00ae..fe9d16e48ecc 100755
--- a/automation/eclair_analysis/prepare.sh
+++ b/automation/eclair_analysis/prepare.sh
@@ -35,11 +35,12 @@ else
  fi
(
-cd xen
-cp "${CONFIG_FILE}" .config
+./configure
+cp "${CONFIG_FILE}" xen/.config
  make clean
  find . -type f -name "*.safparse" -print -delete
-make -f ${script_dir}/Makefile.prepare prepare
+cd xen
+make -f "${script_dir}/Makefile.prepare" prepare
  # Translate the /* SAF-n-safe */ comments into ECLAIR CBTs
  scripts/xen-analysis.py --run-eclair --no-build --no-clean
  )


Cheers,


--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH v4 1/2] automation/eclair: make the docs for MISRA C:2012 Dir 4.1 visible to ECLAIR

[Julien Grall]

Hi,

On 15/11/2023 11:02, Nicola Vetrini wrote:

On 2023-11-14 23:12, Julien Grall wrote:

Hi,

On 14/11/2023 15:36, Nicola Vetrini wrote:

To be able to check for the existence of the necessary subsections in
the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a 
source

file that is built.

This file is generated from 'C-runtime-failures.rst' in docs/misra
and the configuration is updated accordingly.

Signed-off-by: Nicola Vetrini 
---
Changes from RFC:
- Dropped unused/useless code
- Revised the sed command
- Revised the clean target

Changes in v2:
- Added explanative comment to the makefile
- printf instead of echo

Changes in v3:
- Terminate the generated file with a newline
- Build it with -std=c99, so that the documentation
   for D1.1 applies.
Changes in v5:
- Transform and build the file directly in the eclair-specific directory
---
  automation/eclair_analysis/build.sh   | 21 +++--
  automation/eclair_analysis/prepare.sh |  7 ---
  2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/automation/eclair_analysis/build.sh 
b/automation/eclair_analysis/build.sh

index ec087dd822fa..f24292ed0643 100755
--- a/automation/eclair_analysis/build.sh
+++ b/automation/eclair_analysis/build.sh
@@ -33,12 +33,29 @@ else
    PROCESSORS=6
  fi
  +runtime_failures_docs() {
+  doc="C-runtime-failures.rst"
+  builddir="automation/eclair_analysis"
+
+  cp "docs/misra/${doc}" "${builddir}"


Is it necessary to copy the .rst? IOW, would it be sufficient to use...


+  cd "${builddir}"
+  printf "/*\n\n" >"${doc}.tmp"
+  sed -e 's|\*/|*//*|g' "${doc}" >>"${doc}.tmp"


... docs/misc/${doc} here?



I didn't want to leave a stray file under docs/misra, but it's not 
essential.


I am confused. I am suggesting to use:

sed -e 's|\*/|*//*|g' "../../docs/misc/${doc}" >> "${doc}.tmp"

So *.tmp is still created at the same place.




+  printf "\n\n*/\n" >>"${doc}.tmp"
+  mv "${doc}.tmp" "${doc}.c"


NIT: I am not sure why you need to first create .tmp and then create.c.



Wasn't this a pattern to defend against interruptions of the build, just 
as I did in v3?


+$(TARGETS:.o=.c): %.c: %.rst
+    printf "/*\n\n" > $@.tmp
+    sed -e 's|\*/|*//*|g' $< >> $@.tmp
+    printf "\n\n*/\n" >> $@.tmp
+    mv $@.tmp $@


Yes but it makes sense for the Makefile because the target would not be 
re-executed if *.c exists.


But I don't think this is the case for you because you are using a bash 
script. So your function should always be re-executed regardless on 
whether it was interrupted or not.





+
+  # Cannot redirect to /dev/null because it would be excluded from 
the analysis

+  "${CROSS_COMPILE}gcc-12" -std=c99 -c "${doc}.c" -o "${doc}.o"


NIT: It would be helpful to specify why -std=c99 is used. Above, you 
suggest this is to enable D1.1.




Yeah, the comment in the changelog should be pasted here


NIT: Can we define CC and use here and ...


+  cd -
+}
+
  (
-  cd xen
+  runtime_failures_docs
  make "-j${PROCESSORS}" "-l${PROCESSORS}.0"    \
 "CROSS_COMPILE=${CROSS_COMPILE}" \
 "CC=${CROSS_COMPILE}gcc-12"  \


...? This would make easier to re-use the code.



I don't expect this build script to be changed much to be honest, but if 
you think

this is beneficial then it's ok.


This is not only about code evolving. It makes easier to spot your are 
using the same compiler. I would not have made the remark if you were 
using 'gcc'.


But I noticed you were using gcc-12 and originally thought it was a 
mistake until I saw the second use.


The advantage of a variable CC (and CXX) is you can add a comment on top 
why you are specifically requestion gcc-12? IOW, why is gcc not fine?


Cheers,

--
Julien Grall

[RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Sergiy Kibrik]

From: Oleksandr Tyshchenko 

In order to enable more use-cases such as having multiple
device-models (Qemu) running in different backend domains which provide
virtio-pci devices for the same guest, we allocate and expose one
PCI host bridge for every virtio backend domain for that guest.

For that purpose, reserve separate virtio-pci resources (memory and SPI range
for Legacy PCI interrupts) up to 8 possible PCI hosts (to be aligned with
MAX_NR_IOREQ_SERVERS) and allocate a host per backend domain. The PCI host
details including its host_id to be written to dedicated Xenstore node for
the device-model to retrieve.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 xen/include/public/arch-arm.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index a25e87dbda..e6c9cd5335 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -466,6 +466,19 @@ typedef uint64_t xen_callback_t;
 #define GUEST_VPCI_MEM_ADDR xen_mk_ullong(0x2300)
 #define GUEST_VPCI_MEM_SIZE xen_mk_ullong(0x1000)
 
+/*
+ * 16 MB is reserved for virtio-pci configuration space based on calculation
+ * 8 bridges * 2 buses x 32 devices x 8 functions x 4 KB = 16 MB
+ */
+#define GUEST_VIRTIO_PCI_ECAM_BASE  xen_mk_ullong(0x3300)
+#define GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZExen_mk_ullong(0x0100)
+#define GUEST_VIRTIO_PCI_HOST_ECAM_SIZE xen_mk_ullong(0x0020)
+
+/* 64 MB is reserved for virtio-pci memory */
+#define GUEST_VIRTIO_PCI_ADDR_TYPE_MEMxen_mk_ullong(0x0200)
+#define GUEST_VIRTIO_PCI_MEM_ADDR xen_mk_ullong(0x3400)
+#define GUEST_VIRTIO_PCI_MEM_SIZE xen_mk_ullong(0x0400)
+
 /*
  * 16MB == 4096 pages reserved for guest to use as a region to map its
  * grant table in.
@@ -476,6 +489,11 @@ typedef uint64_t xen_callback_t;
 #define GUEST_MAGIC_BASE  xen_mk_ullong(0x3900)
 #define GUEST_MAGIC_SIZE  xen_mk_ullong(0x0100)
 
+/* 64 MB is reserved for virtio-pci Prefetch memory */
+#define GUEST_VIRTIO_PCI_ADDR_TYPE_PREFETCH_MEMxen_mk_ullong(0x4200)
+#define GUEST_VIRTIO_PCI_PREFETCH_MEM_ADDR xen_mk_ullong(0x3a00)
+#define GUEST_VIRTIO_PCI_PREFETCH_MEM_SIZE xen_mk_ullong(0x0400)
+
 #define GUEST_RAM_BANKS   2
 
 /*
@@ -515,6 +533,9 @@ typedef uint64_t xen_callback_t;
 #define GUEST_VIRTIO_MMIO_SPI_FIRST   33
 #define GUEST_VIRTIO_MMIO_SPI_LAST43
 
+#define GUEST_VIRTIO_PCI_SPI_FIRST   44
+#define GUEST_VIRTIO_PCI_SPI_LAST76
+
 /* PSCI functions */
 #define PSCI_cpu_suspend 0
 #define PSCI_cpu_off 1
-- 
2.25.1

[RFC PATCH 0/6] ARM virtio-pci initial support

[Sergiy Kibrik]

Hi,
In this patch series we introduce support of PCI devices emulated by Virtio 
on ARM platform. A guest system is presented with Virtio Host bridge device, 
through
which a number of emulated PCI devices (e.g. disk, network, graphic, audio etc)
can work with corresponding guests' subsystems.

For that purpose we add a new "pci" virtio transport mechanism in xl
configuration, in addition to present "mmio" mechanism.

Suitable MMIO and IRQ ranges are reverved, for guests' PCI accesses are trapped
and forwarded to IOREQ server to be handled outside of Xen. Also guest's DT
extended with PCI (#INTA..#INTD) interrupt mappings.

For now only supported combination of backends is when both PCI Host bridge
and all PCI devices behind it are emulated by the same single instance (i.e. 
Qemu).

The code was tested with QEMU backends, yet it aims to be extendable to support
stand-alone backends.

 -Sergiy

Oleksandr Tyshchenko (6):
  libxl: Pass max_vcpus to Qemu in case of PVH domain (Arm) as well
  xen/public: arch-arm: reserve resources for virtio-pci
  libxl/arm: Add basic virtio-pci support
  libxl/arm: Reuse generic PCI-IOMMU bindings for virtio-pci devices
  xen/arm: Intercept vPCI config accesses and forward them to emulator
  libxl: Add "backend_type" property for the Virtio devices

 docs/man/xl.cfg.5.pod.in  |  18 +-
 tools/libs/light/libxl_arm.c  | 351 --
 tools/libs/light/libxl_create.c   |  18 +-
 tools/libs/light/libxl_dm.c   |  98 ++-
 tools/libs/light/libxl_internal.h |   5 +
 tools/libs/light/libxl_types.idl  |  41 ++-
 tools/libs/light/libxl_virtio.c   | 119 +++--
 tools/xl/xl_parse.c   |  39 +++
 xen/arch/arm/Kconfig  |  10 +
 xen/arch/arm/domain.c |   2 +-
 xen/arch/arm/{ => include/asm}/vpci.h |  11 +
 xen/arch/arm/io.c |   8 +-
 xen/arch/arm/ioreq.c  |  19 +-
 xen/arch/arm/vpci.c   | 106 +++-
 xen/include/public/arch-arm.h |  21 ++
 15 files changed, 797 insertions(+), 69 deletions(-)
 rename xen/arch/arm/{ => include/asm}/vpci.h (75%)

-- 
2.25.1

[RFC PATCH 4/6] libxl/arm: Reuse generic PCI-IOMMU bindings for virtio-pci devices

[Sergiy Kibrik]

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).

Reuse generic PCI-IOMMU bindings (iommu-map/iommu-map-mask properties)
which allows us to describe relationship between PCI devices and
backend domains ID properly. Linux guest is already able to deal
with generic PCI-IOMMU bindings (see Linux drivers/xen/grant-dma-ops.c
for details).

According to Linux:
   - Documentation/devicetree/bindings/pci/pci-iommu.txt
   - Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 tools/libs/light/libxl_arm.c | 64 
 1 file changed, 64 insertions(+)

diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index df6cbbe756..03cf3e424b 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -1030,6 +1030,7 @@ static int make_vpci_node(libxl__gc *gc, void *fdt,
 }
 
 #define PCI_IRQ_MAP_MIN_STRIDE   8
+#define PCI_IOMMU_MAP_STRIDE 4
 
 static int create_virtio_pci_irq_map(libxl__gc *gc, void *fdt,
  libxl_virtio_pci_host *host)
@@ -1099,6 +1100,65 @@ static int create_virtio_pci_irq_map(libxl__gc *gc, void 
*fdt,
 return 0;
 }
 
+/* XXX Consider reusing libxl__realloc() to avoid an extra loop */
+static int create_virtio_pci_iommu_map(libxl__gc *gc, void *fdt,
+   libxl_virtio_pci_host *host,
+   libxl_domain_config *d_config)
+{
+uint32_t *full_iommu_map, *iommu_map;
+unsigned int i, len, ntranslated = 0;
+int res;
+
+for (i = 0; i < d_config->num_virtios; i++) {
+libxl_device_virtio *virtio = &d_config->virtios[i];
+
+if (libxl_defbool_val(virtio->grant_usage) &&
+virtio->transport == LIBXL_VIRTIO_TRANSPORT_PCI &&
+virtio->u.pci.host_id == host->id) {
+ntranslated++;
+}
+}
+
+if (!ntranslated)
+return 0;
+
+len = ntranslated * sizeof(uint32_t) * PCI_IOMMU_MAP_STRIDE;
+full_iommu_map = libxl__malloc(gc, len);
+iommu_map = full_iommu_map;
+
+/* See Linux Documentation/devicetree/bindings/pci/pci-iommu.txt */
+for (i = 0; i < d_config->num_virtios; i++) {
+libxl_device_virtio *virtio = &d_config->virtios[i];
+
+if (libxl_defbool_val(virtio->grant_usage) &&
+virtio->transport == LIBXL_VIRTIO_TRANSPORT_PCI &&
+virtio->u.pci.host_id == host->id) {
+uint16_t bdf = (virtio->u.pci.bus << 8) |
+(virtio->u.pci.dev << 3) | virtio->u.pci.func;
+unsigned int j = 0;
+
+/* rid_base (1 cell) */
+iommu_map[j++] = cpu_to_fdt32(bdf);
+
+/* iommu_phandle (1 cell) */
+iommu_map[j++] = cpu_to_fdt32(GUEST_PHANDLE_IOMMU);
+
+/* iommu_base (1 cell) */
+iommu_map[j++] = cpu_to_fdt32(virtio->backend_domid);
+
+/* length (1 cell) */
+iommu_map[j++] = cpu_to_fdt32(1 << 3);
+
+iommu_map += PCI_IOMMU_MAP_STRIDE;
+}
+}
+
+res = fdt_property(fdt, "iommu-map", full_iommu_map, len);
+if (res) return res;
+
+return 0;
+}
+
 /* TODO Consider reusing make_vpci_node() */
 static int make_virtio_pci_node(libxl__gc *gc, void *fdt,
 libxl_virtio_pci_host *host,
@@ -1147,6 +1207,10 @@ static int make_virtio_pci_node(libxl__gc *gc, void *fdt,
 res = create_virtio_pci_irq_map(gc, fdt, host);
 if (res) return res;
 
+/* xen,grant-dma bindings */
+res = create_virtio_pci_iommu_map(gc, fdt, host, d_config);
+if (res) return res;
+
 res = fdt_end_node(fdt);
 if (res) return res;
 
-- 
2.25.1

[RFC PATCH 1/6] libxl: Pass max_vcpus to Qemu in case of PVH domain (Arm) as well

[Sergiy Kibrik]

From: Oleksandr Tyshchenko 

The number of vCPUs used for the IOREQ configuration (machine->smp.cpus)
should really match the system value as for each vCPU we setup a dedicated
evtchn for the communication with Xen at the runtime. This is needed
for the IOREQ to be properly configured and work if the involved domain
has more than one vCPU assigned.

Note that Qemu should set mc->max_cpus to GUEST_MAX_VCPUS in
xen_arm_machine_class_init().

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 tools/libs/light/libxl_dm.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 14b593110f..0b2548d35b 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -1553,18 +1553,6 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 if (!libxl__acpi_defbool_val(b_info)) {
 flexarray_append(dm_args, "-no-acpi");
 }
-if (b_info->max_vcpus > 1) {
-flexarray_append(dm_args, "-smp");
-if (b_info->avail_vcpus.size) {
-int nr_set_cpus = 0;
-nr_set_cpus = libxl_bitmap_count_set(&b_info->avail_vcpus);
-
-flexarray_append(dm_args, GCSPRINTF("%d,maxcpus=%d",
-nr_set_cpus,
-b_info->max_vcpus));
-} else
-flexarray_append(dm_args, GCSPRINTF("%d", b_info->max_vcpus));
-}
 for (i = 0; i < num_nics; i++) {
 if (nics[i].nictype == LIBXL_NIC_TYPE_VIF_IOEMU) {
 char *smac = GCSPRINTF(LIBXL_MAC_FMT,
@@ -1800,6 +1788,22 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
 flexarray_append(dm_args, b_info->extra[i]);
 
+if (b_info->type == LIBXL_DOMAIN_TYPE_HVM ||
+b_info->type == LIBXL_DOMAIN_TYPE_PVH) {
+if (b_info->max_vcpus > 1) {
+flexarray_append(dm_args, "-smp");
+if (b_info->avail_vcpus.size) {
+int nr_set_cpus = 0;
+nr_set_cpus = libxl_bitmap_count_set(&b_info->avail_vcpus);
+
+flexarray_append(dm_args, GCSPRINTF("%d,maxcpus=%d",
+nr_set_cpus,
+b_info->max_vcpus));
+} else
+flexarray_append(dm_args, GCSPRINTF("%d", b_info->max_vcpus));
+}
+}
+
 flexarray_append(dm_args, "-machine");
 switch (b_info->type) {
 case LIBXL_DOMAIN_TYPE_PVH:
-- 
2.25.1

[RFC PATCH 3/6] libxl/arm: Add basic virtio-pci support

[Sergiy Kibrik]

From: Oleksandr Tyshchenko 

Introduce new transport mechanism "pci" for the Virtio device
and update parsing and configuration logic accordingly.

In order to enable more use-cases such as having multiple
device-models (Qemu) running in different backend domains which provide
virtio-pci devices for the same guest, we allocate and expose one
PCI host bridge for every virtio backend domain for that guest.

Also extend PCI Host bridge DT node exposed to the guest by adding
bindings for Legacy PCI interrupts (#INTA - #INTD).

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 docs/man/xl.cfg.5.pod.in  |   9 +-
 tools/libs/light/libxl_arm.c  | 287 --
 tools/libs/light/libxl_create.c   |  18 +-
 tools/libs/light/libxl_dm.c   |  70 
 tools/libs/light/libxl_internal.h |   5 +
 tools/libs/light/libxl_types.idl  |  34 +++-
 tools/libs/light/libxl_virtio.c   |  98 +++---
 tools/xl/xl_parse.c   |  36 
 8 files changed, 507 insertions(+), 50 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 2e234b450e..0fba750815 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1616,8 +1616,13 @@ hexadecimal format, without the "0x" prefix and all in 
lower case, like
 
 =item B
 
-Specifies the transport mechanism for the Virtio device, only "mmio" is
-supported for now.
+Specifies the transport mechanism for the Virtio device, both "mmio" and "pci"
+are supported. This option is mandatory.
+
+=item B
+
+The Virtio device with transport "pci" must be identified by its B.
+See L for more details about the format for B.
 
 =item B
 
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 1539191774..df6cbbe756 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -20,6 +20,11 @@
  */
 #define VIRTIO_MMIO_DEV_SIZE   xen_mk_ullong(0x200)
 
+#define VIRTIO_PCI_HOST_MEM_SIZExen_mk_ullong(0x80)
+#define VIRTIO_PCI_HOST_PREFETCH_MEM_SIZE   xen_mk_ullong(0x80)
+#define VIRTIO_PCI_HOST_NUM_SPIS4
+#define VIRTIO_PCI_MAX_HOSTS8
+
 static uint64_t alloc_virtio_mmio_base(libxl__gc *gc, uint64_t 
*virtio_mmio_base)
 {
 uint64_t base = *virtio_mmio_base;
@@ -80,14 +85,101 @@ static const char *gicv_to_string(libxl_gic_version 
gic_version)
 }
 }
 
+static int alloc_virtio_pci_host(libxl__gc *gc,
+ uint32_t backend_domid,
+ uint32_t *host_id,
+ unsigned int *num_hosts,
+ libxl_virtio_pci_host *hosts)
+{
+unsigned int i;
+
+BUILD_BUG_ON(VIRTIO_PCI_MAX_HOSTS !=
+ GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE / 
GUEST_VIRTIO_PCI_HOST_ECAM_SIZE);
+BUILD_BUG_ON(VIRTIO_PCI_MAX_HOSTS !=
+ GUEST_VIRTIO_PCI_MEM_SIZE / VIRTIO_PCI_HOST_MEM_SIZE);
+BUILD_BUG_ON(VIRTIO_PCI_MAX_HOSTS !=
+ GUEST_VIRTIO_PCI_PREFETCH_MEM_SIZE / 
VIRTIO_PCI_HOST_PREFETCH_MEM_SIZE);
+BUILD_BUG_ON(VIRTIO_PCI_MAX_HOSTS !=
+ (GUEST_VIRTIO_PCI_SPI_LAST - GUEST_VIRTIO_PCI_SPI_FIRST) / 
VIRTIO_PCI_HOST_NUM_SPIS);
+
+if (*num_hosts > VIRTIO_PCI_MAX_HOSTS)
+return ERROR_INVAL;
+
+for (i = 0; i < *num_hosts; i++) {
+if (hosts[i].backend_domid == backend_domid) {
+*host_id = hosts[i].id;
+
+LOG(DEBUG, "Reuse host #%u: "
+"ECAM: 0x%"PRIx64"-0x%"PRIx64" "
+"MEM: 0x%"PRIx64"-0x%"PRIx64" "
+"PREFETCH_MEM: 0x%"PRIx64"-0x%"PRIx64" "
+"IRQ: %u-%u",
+hosts[i].id,
+hosts[i].ecam_base,
+hosts[i].ecam_base + hosts[i].ecam_size - 1,
+hosts[i].mem_base,
+hosts[i].mem_base + hosts[i].mem_size - 1,
+hosts[i].prefetch_mem_base,
+hosts[i].prefetch_mem_base + 
hosts[i].prefetch_mem_size - 1,
+hosts[i].irq_first,
+hosts[i].irq_first + hosts[i].num_irqs - 1);
+
+return 0;
+}
+}
+
+if (i == VIRTIO_PCI_MAX_HOSTS) {
+LOG(ERROR, "Ran out of reserved resources for virtio-pci host\n");
+return ERROR_FAIL;
+}
+
+hosts[i].backend_domid = backend_domid;
+hosts[i].id = i;
+hosts[i].ecam_base = GUEST_VIRTIO_PCI_ECAM_BASE +
+i * GUEST_VIRTIO_PCI_HOST_ECAM_SIZE;
+hosts[i].ecam_size = GUEST_VIRTIO_PCI_HOST_ECAM_SIZE;
+hosts[i].mem_base = GUEST_VIRTIO_PCI_MEM_ADDR +
+i * VIRTIO_PCI_HOST_MEM_SIZE;
+hosts[i].mem_size = VIRTIO_PCI_HOST_MEM_SIZE;
+hosts[i].prefetch_mem_base = GUEST_VIRTIO_PCI_PREFETCH_MEM_ADDR +
+i * VIRTIO_PCI_HOST_PREFETCH_MEM_SIZE;
+hosts[i].prefetch_mem_size = VIRTIO_PCI_HOST_PREFETCH_MEM_SIZE;
+hosts[i].ir

[RFC PATCH 5/6] xen/arm: Intercept vPCI config accesses and forward them to emulator

[Sergiy Kibrik]

From: Oleksandr Tyshchenko 

This is needed for supporting virtio-pci.

In case when the PCI Host bridge is emulated outside of Xen
(IOREQ server), we need some mechanism to intercept config space
accesses on Xen on Arm, and forward them to the emulator
(for example, virtio backend) via IOREQ request.

Unlike x86, on Arm these accesses are MMIO, there is no CFC/CF8 method
to detect which PCI device is targeted.

In order to not mix PCI passthrough with virtio-pci features we add
one more region to cover the total configuration space for all possible
host bridges which can serve virtio-pci devices for that guest.
We expose one PCI host bridge per virtio backend domain.

To distinguish between virtio-pci devices belonging to PCI host
bridges emulated by device-models running in different backend domains
we also need to calculate a segment in virtio_pci_ioreq_server_get_addr().
For this to work the toolstack is responsible to allocate and assign unique
configuration space range and segment (host_id) within total reserved range
for these device-models. The device-models are responsible for applying
a segment when forming DM op for registering PCI devices with IOREQ Server.

Introduce new CONFIG_VIRTIO_PCI to guard the whole handling.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 xen/arch/arm/Kconfig  |  10 +++
 xen/arch/arm/domain.c |   2 +-
 xen/arch/arm/{ => include/asm}/vpci.h |  11 +++
 xen/arch/arm/io.c |   8 +-
 xen/arch/arm/ioreq.c  |  19 -
 xen/arch/arm/vpci.c   | 106 +-
 6 files changed, 146 insertions(+), 10 deletions(-)
 rename xen/arch/arm/{ => include/asm}/vpci.h (75%)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2939db429b..9e8d6c4ce2 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -190,6 +190,16 @@ config STATIC_SHM
help
  This option enables statically shared memory on a dom0less system.
 
+config VIRTIO_PCI
+   bool "Support of virtio-pci transport" if EXPERT
+   depends on ARM_64
+   select HAS_PCI
+   select HAS_VPCI
+   select IOREQ_SERVER
+   default n
+   help
+ This option enables support of virtio-pci transport
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 28e3aaa5e4..140f9bbd58 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -28,9 +28,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
-#include "vpci.h"
 #include "vuart.h"
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
diff --git a/xen/arch/arm/vpci.h b/xen/arch/arm/include/asm/vpci.h
similarity index 75%
rename from xen/arch/arm/vpci.h
rename to xen/arch/arm/include/asm/vpci.h
index 3c713f3fcd..54d083c67b 100644
--- a/xen/arch/arm/vpci.h
+++ b/xen/arch/arm/include/asm/vpci.h
@@ -30,6 +30,17 @@ static inline unsigned int 
domain_vpci_get_num_mmio_handlers(struct domain *d)
 }
 #endif
 
+#ifdef CONFIG_VIRTIO_PCI
+bool virtio_pci_ioreq_server_get_addr(const struct domain *d,
+  paddr_t gpa, uint64_t *addr);
+#else
+static inline bool virtio_pci_ioreq_server_get_addr(const struct domain *d,
+paddr_t gpa, uint64_t 
*addr)
+{
+return false;
+}
+#endif
+
 #endif /* __ARCH_ARM_VPCI_H__ */
 
 /*
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 96c740d563..5c3e03e30d 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -26,6 +26,7 @@ static enum io_state handle_read(const struct mmio_handler 
*handler,
 {
 const struct hsr_dabt dabt = info->dabt;
 struct cpu_user_regs *regs = guest_cpu_user_regs();
+int ret;
 /*
  * Initialize to zero to avoid leaking data if there is an
  * implementation error in the emulation (such as not correctly
@@ -33,8 +34,9 @@ static enum io_state handle_read(const struct mmio_handler 
*handler,
  */
 register_t r = 0;
 
-if ( !handler->ops->read(v, info, &r, handler->priv) )
-return IO_ABORT;
+ret = handler->ops->read(v, info, &r, handler->priv);
+if ( ret != IO_HANDLED )
+return ret != IO_RETRY ? IO_ABORT : ret;
 
 r = sign_extend(dabt, r);
 
@@ -53,7 +55,7 @@ static enum io_state handle_write(const struct mmio_handler 
*handler,
 
 ret = handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
   handler->priv);
-return ret ? IO_HANDLED : IO_ABORT;
+return ret != IO_HANDLED && ret != IO_RETRY ? IO_ABORT : ret;
 }
 
 /* This function assumes that mmio regions are not overlapped */
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 5df755b48b..fd4cc755b6 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -193,12 +194,24 @@ bool arch_ioreq_server_get_type_addr(const struct domain 
*

Re: [XEN PATCH][for-4.19 v2] xen: replace occurrences of SAF-1-safe with asmlinkage attribute

[Nicola Vetrini]

On 2023-11-13 15:44, Jan Beulich wrote:

On 07.11.2023 11:30, Nicola Vetrini wrote:

--- a/xen/arch/x86/boot/cmdline.c
+++ b/xen/arch/x86/boot/cmdline.c
@@ -31,6 +31,7 @@ asm (
 );

 #include 
+#include 
 #include "defs.h"
 #include "video.h"


Please respect the goal of alphabetically sorted groups of #include-s.



Will do


--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -33,6 +33,8 @@ asm (
 #include "../../../include/xen/kconfig.h"
 #include 

+#include 


Same here, put on top of the tidying patch I just sent.



This one, right?
https://lore.kernel.org/xen-devel/c027b9cd-37f3-8223-141f-a1dceda82...@suse.com/


--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1254,9 +1254,8 @@ static void __init efi_exit_boot(EFI_HANDLE 
ImageHandle, EFI_SYSTEM_TABLE *Syste

 efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
 }

-/* SAF-1-safe */
-void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
-  EFI_SYSTEM_TABLE *SystemTable)
+void asmlinkage EFIAPI __init noreturn efi_start(EFI_HANDLE 
ImageHandle,
+ EFI_SYSTEM_TABLE 
*SystemTable)

 {
 static EFI_GUID __initdata loaded_image_guid = 
LOADED_IMAGE_PROTOCOL;
 static EFI_GUID __initdata shim_lock_guid = 
SHIM_LOCK_PROTOCOL_GUID;


Besides this patch not working on its own (as already said by Julien,
you want to explicitly state dependencies), the change above makes me
wonder about efi_multiboot2(): Neither the earlier series nor the
change here are touching either of the two instances of the function.
Was that merely an oversight, or is there another reason?



Looks like an oversight, but I'll have to investigate; if it needs to be 
modified I'll do a separate patch.


--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

[RFC PATCH 6/6] libxl: Add "backend_type" property for the Virtio devices

[Sergiy Kibrik]

From: Oleksandr Tyshchenko 

Introduce new configuration option "backend_type" for the Virtio
devices in order to specify backend implementation to use.
There are two possible values "qemu" (default) and "standalone".

If backend is in Qemu (backend_type=qemu) and Qemu runs in toolstack
domain (backend=Domain-0) then Qemu will be launched automatically
at the guest creation time. For this to work implement "dm_needed"
callback.

Please note, there is no support for Qemu in other domains for
the time being, so the combination of "backend=DomD" and
"backend_type=qemu" just won't work.

Qemu configuration for Virtio devices should be described via
"device_model_args" property.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
 docs/man/xl.cfg.5.pod.in |  9 +
 tools/libs/light/libxl_types.idl |  7 +++
 tools/libs/light/libxl_virtio.c  | 29 -
 tools/xl/xl_parse.c  |  3 +++
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 0fba750815..592aad1d1e 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1624,6 +1624,15 @@ are supported. This option is mandatory.
 The Virtio device with transport "pci" must be identified by its B.
 See L for more details about the format for B.
 
+=item B
+
+Specifies the software implementation of the backend implementation to use.
+This option doesn't affect the guest's view of the Virtio device.
+
+Both "qemu" and "standalone" are supported. The only difference is
+that for the former the toolstack assists with configuring and launching
+the device-model. If this option is missing, then "qemu" value will be used.
+
 =item B
 
 If this option is B, the Xen grants are always enabled.
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index a86c601994..13b8ade41c 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -284,6 +284,12 @@ libxl_virtio_transport = Enumeration("virtio_transport", [
 (2, "PCI"),
 ])
 
+libxl_virtio_backend = Enumeration("virtio_backend", [
+(0, "UNKNOWN"),
+(1, "QEMU"),
+(2, "STANDALONE"),
+])
+
 libxl_passthrough = Enumeration("passthrough", [
 (0, "default"),
 (1, "disabled"),
@@ -778,6 +784,7 @@ libxl_device_vkb = Struct("device_vkb", [
 libxl_device_virtio = Struct("device_virtio", [
 ("backend_domid", libxl_domid),
 ("backend_domname", string),
+("backend_type", libxl_virtio_backend),
 ("type", string),
 ("u", KeyedUnion(None, libxl_virtio_transport, "transport",
   [("unknown", None),
diff --git a/tools/libs/light/libxl_virtio.c b/tools/libs/light/libxl_virtio.c
index 8062423c75..339a2006f0 100644
--- a/tools/libs/light/libxl_virtio.c
+++ b/tools/libs/light/libxl_virtio.c
@@ -32,9 +32,20 @@ static int libxl__device_virtio_setdefault(libxl__gc *gc, 
uint32_t domid,
 libxl_defbool_setdefault(&virtio->grant_usage,
  virtio->backend_domid != LIBXL_TOOLSTACK_DOMID);
 
+if (virtio->backend_type == LIBXL_VIRTIO_BACKEND_UNKNOWN)
+virtio->backend_type = LIBXL_VIRTIO_BACKEND_QEMU;
+
 return 0;
 }
 
+static int libxl__device_virtio_dm_needed(void *e, unsigned domid)
+{
+libxl_device_virtio *elem = e;
+
+return elem->backend_type == LIBXL_VIRTIO_BACKEND_QEMU &&
+   elem->backend_domid == domid;
+}
+
 static int libxl__device_from_virtio(libxl__gc *gc, uint32_t domid,
  libxl_device_virtio *virtio,
  libxl__device *device)
@@ -55,7 +66,8 @@ static int libxl__set_xenstore_virtio(libxl__gc *gc, uint32_t 
domid,
   flexarray_t *back, flexarray_t *front,
   flexarray_t *ro_front)
 {
-const char *transport = 
libxl_virtio_transport_to_string(virtio->transport);
+const char *transport = 
libxl_virtio_transport_to_string(virtio->transport),
+   *backend = libxl_virtio_backend_to_string(virtio->backend_type);
 
 if (virtio->transport == LIBXL_VIRTIO_TRANSPORT_MMIO) {
 flexarray_append_pair(back, "irq", GCSPRINTF("%u", 
virtio->u.mmio.irq));
@@ -74,6 +86,7 @@ static int libxl__set_xenstore_virtio(libxl__gc *gc, uint32_t 
domid,
 }
 flexarray_append_pair(back, "type", GCSPRINTF("%s", virtio->type));
 flexarray_append_pair(back, "transport", GCSPRINTF("%s", transport));
+flexarray_append_pair(back, "backend_type", GCSPRINTF("%s", backend));
 flexarray_append_pair(back, "grant_usage",
   libxl_defbool_val(virtio->grant_usage) ? "1" : "0");
 
@@ -166,6 +179,19 @@ static int libxl__virtio_from_xenstore(libxl__gc *gc, 
const char *libxl_path,
 }
 }
 
+tmp = NULL;
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/backend_type", be_path), &tmp);
+   

Important - Documentation Discussion

[Kelly Choi]

Hi all,

As you may be aware, we are in the process of reviewing our existing
documentation platform and content. In order to meet the requirements of
the community and project, I need your input and feedback.

The aim of the new documentation is to encourage community members to
collaborate in updating content (where possible) and educate users on how
the project works. The updated documentation will be hosted on our new
upcoming website.

*Suggestion for user-orientated documentation:*

   - git - for hosting (gitlab recommended)
   - RST - for the format of the documentation
   - Sphynx - to generate web pages and PDF and other formats from RST

*Suggestion for developer reference documentation:*

   - Doxygen
   - Kerneldoc
   - Open to other suggestions here

Example of how documentation will be split:

   1. Getting started/beginner user guides
   2. Learning orientated tutorials
   3. Goal-orientated how-to guides
   4. Developer related documentation

Side note: Whilst I appreciate everyone has a different vision of what
ideal documentation looks like, please be mindful that not everyone's
thought processes or depth of knowledge are the same. All ideas are
welcome, and decisions made will always reflect community needs.

Many thanks,
Kelly Choi

Open Source Community Manager
XenServer, Cloud Software Group

Re: Important - Documentation Discussion

[Alejandro Vallejo]

Hi,

On Wed, Nov 15, 2023 at 11:43:46AM +, Kelly Choi wrote:
> Hi all,
> 
> As you may be aware, we are in the process of reviewing our existing
> documentation platform and content. In order to meet the requirements of
> the community and project, I need your input and feedback.
> 
> The aim of the new documentation is to encourage community members to
> collaborate in updating content (where possible) and educate users on how
> the project works. The updated documentation will be hosted on our new
> upcoming website.
> 
> *Suggestion for user-orientated documentation:*
> 
>- git - for hosting (gitlab recommended)
>- RST - for the format of the documentation
>- Sphynx - to generate web pages and PDF and other formats from RST
In my experience Sphinx's strength is in its ability to cross-reference the
code. That isn't something terribly helpful for user documentation, and it
makes the whole thing harder to set up for no clear benefit.

For user-facing docs I'd propose `mkdocs` instead, which is a lot more
focused and simpler to set up (can be done literally in a couple of
minutes). The main difference would be that it takes Markdown rather than
RST[1]. It trivially supports plugins for interesting things, like mermaid
(for sequence/block diagrams or FSMs) 

Main website: https://www.mkdocs.org/
Plugin catalog: https://github.com/mkdocs/catalog
* mermaid plugin: https://github.com/fralau/mkdocs-mermaid2-plugin
* kroki plugin: https://kroki.io/

[1] I happen to prefer Markdown, as I find it easier to read and write, but
that's just personal preference

> 
> *Suggestion for developer reference documentation:*
> 
>- Doxygen
>- Kerneldoc
>- Open to other suggestions here
There's 2 areas here. The format for the annotations, and the visualization
frontend. They need not be the same. Using Doxygen seems the less
"not-invented-here" approach, while kerneldoc would 

As for the frontend I would suggest to _not_ use Doxygen itself as the
generated websites are hideous to look at. Sphinx (through Breathe) or any
other Doxygen-database parse wouldr do the job as well providing a much
(much) better output.

> 
> Example of how documentation will be split:
> 
>1. Getting started/beginner user guides
>2. Learning orientated tutorials
>3. Goal-orientated how-to guides
>4. Developer related documentation
(1-3) seem like pretty much the same thing. Guides of increasing complexity
meant to train a new user/admin. Dividing such a section in those 3 blocks
seems sensible.

(4) could be split in a "Developer Manual", which would contain plain
explanation for dev-heavy concepts, and a "Reference Manual" with links to
the Doxygen-esque websites and a higher focus on implementation details.

> 
> Side note: Whilst I appreciate everyone has a different vision of what
> ideal documentation looks like, please be mindful that not everyone's
> thought processes or depth of knowledge are the same. All ideas are
> welcome, and decisions made will always reflect community needs.
> 
> Many thanks,
> Kelly Choi
> 
> Open Source Community Manager
> XenServer, Cloud Software Group

Cheers,
Alejandro

[PATCH for-4.18] SUPPORT.md: Define support lifetime

[Julien Grall]

From: Julien Grall 

Signed-off-by: Julien Grall 
---
 SUPPORT.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index fff4b4c5bad6..c452635eb552 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-Xen-Version: 4.18-rc
-Initial-Release: n/a
-Supported-Until: TBD
-Security-Support-Until: Unreleased - not yet security-supported
+Xen-Version: 4.18
+Initial-Release: 2023-11-16
+Supported-Until: 2025-05-16
+Security-Support-Until: 2025-11-16
 
 Release Notes
 : https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes";>RN
-- 
2.40.1

Re: [PATCH for-4.18] SUPPORT.md: Define support lifetime

[Henry Wang]

Hi Julien,

> On Nov 15, 2023, at 20:16, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 

Thanks for the patch and all your effort during the release period!

Release-acked-by: Henry Wang 

Kind regards,
Henry

> ---
> SUPPORT.md | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index fff4b4c5bad6..c452635eb552 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
> 
> # Release Support
> 
> -Xen-Version: 4.18-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unreleased - not yet security-supported
> +Xen-Version: 4.18
> +Initial-Release: 2023-11-16
> +Supported-Until: 2025-05-16
> +Security-Support-Until: 2025-11-16
> 
> Release Notes
> :  href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes";>RN
> -- 
> 2.40.1
> 

Re: [PATCH for-4.18] SUPPORT.md: Define support lifetime

[Henry Wang]

Hi Julien,

> On Nov 15, 2023, at 20:16, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> Signed-off-by: Julien Grall 
> ---
> SUPPORT.md | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index fff4b4c5bad6..c452635eb552 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
> 
> # Release Support
> 
> -Xen-Version: 4.18-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unreleased - not yet security-supported
> +Xen-Version: 4.18
> +Initial-Release: 2023-11-16
> +Supported-Until: 2025-05-16
> +Security-Support-Until: 2025-11-16

I thought we have a 3 years’ support lifetime, so maybe it should be 
2026-11-16, but not sure
if it is still the case.

I will let Jan to double check. My release ack still holds once we have the 
conclusion.

Kind regards,
Henry

> 

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Julien Grall]

Hi,

Thanks for adding support for virtio-pci in Xen. I have some questions.

On 15/11/2023 11:26, Sergiy Kibrik wrote:

From: Oleksandr Tyshchenko 

In order to enable more use-cases such as having multiple
device-models (Qemu) running in different backend domains which provide
virtio-pci devices for the same guest, we allocate and expose one
PCI host bridge for every virtio backend domain for that guest.


OOI, why do you need to expose one PCI host bridge for every stubdomain?

In fact looking at the next patch, it seems you are handling some of the 
hostbridge request in Xen. This is adds a bit more confusion.


I was expecting the virtual PCI device would be in the vPCI and each 
Device emulator would advertise which BDF they are covering.




For that purpose, reserve separate virtio-pci resources (memory and SPI range
for Legacy PCI interrupts) up to 8 possible PCI hosts (to be aligned with


Do you mean host bridge rather than host?


MAX_NR_IOREQ_SERVERS) and allocate a host per backend domain. The PCI host
details including its host_id to be written to dedicated Xenstore node for
the device-model to retrieve.


So which with approach, who is decide which BDF will be used for a given 
virtio PCI device?




Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
  xen/include/public/arch-arm.h | 21 +
  1 file changed, 21 insertions(+)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index a25e87dbda..e6c9cd5335 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -466,6 +466,19 @@ typedef uint64_t xen_callback_t;
  #define GUEST_VPCI_MEM_ADDR xen_mk_ullong(0x2300)
  #define GUEST_VPCI_MEM_SIZE xen_mk_ullong(0x1000)
  
+/*

+ * 16 MB is reserved for virtio-pci configuration space based on calculation
+ * 8 bridges * 2 buses x 32 devices x 8 functions x 4 KB = 16 MB


Can you explain how youd ecided the "2"?


+ */
+#define GUEST_VIRTIO_PCI_ECAM_BASE  xen_mk_ullong(0x3300)
+#define GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZExen_mk_ullong(0x0100)
+#define GUEST_VIRTIO_PCI_HOST_ECAM_SIZE xen_mk_ullong(0x0020)
+
+/* 64 MB is reserved for virtio-pci memory */
+#define GUEST_VIRTIO_PCI_ADDR_TYPE_MEMxen_mk_ullong(0x0200)
+#define GUEST_VIRTIO_PCI_MEM_ADDR xen_mk_ullong(0x3400)
+#define GUEST_VIRTIO_PCI_MEM_SIZE xen_mk_ullong(0x0400)
+
  /*
   * 16MB == 4096 pages reserved for guest to use as a region to map its
   * grant table in.
@@ -476,6 +489,11 @@ typedef uint64_t xen_callback_t;
  #define GUEST_MAGIC_BASE  xen_mk_ullong(0x3900)
  #define GUEST_MAGIC_SIZE  xen_mk_ullong(0x0100)
  
+/* 64 MB is reserved for virtio-pci Prefetch memory */


This doesn't seem a lot depending on your use case. Can you details how 
you can up with "64 MB"?



+#define GUEST_VIRTIO_PCI_ADDR_TYPE_PREFETCH_MEMxen_mk_ullong(0x4200)
+#define GUEST_VIRTIO_PCI_PREFETCH_MEM_ADDR xen_mk_ullong(0x3a00)
+#define GUEST_VIRTIO_PCI_PREFETCH_MEM_SIZE xen_mk_ullong(0x0400)
+
  #define GUEST_RAM_BANKS   2
  
  /*

@@ -515,6 +533,9 @@ typedef uint64_t xen_callback_t;
  #define GUEST_VIRTIO_MMIO_SPI_FIRST   33
  #define GUEST_VIRTIO_MMIO_SPI_LAST43
  
+#define GUEST_VIRTIO_PCI_SPI_FIRST   44

+#define GUEST_VIRTIO_PCI_SPI_LAST76


Just to confirm this is 4 interrupts per PCI host bridge? If so, can 
this be clarified in a comment?


Also, above you said that the host ID will be written to Xenstore. But 
who will decide which SPI belongs to which host bridge?


Cheers,

--
Julien Grall

Re: [PATCH for-4.18] SUPPORT.md: Define support lifetime

[Julien Grall]

Hi Henry,

On 15/11/2023 12:27, Henry Wang wrote:

On Nov 15, 2023, at 20:16, Julien Grall  wrote:

From: Julien Grall 

Signed-off-by: Julien Grall 
---
SUPPORT.md | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index fff4b4c5bad6..c452635eb552 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,10 +9,10 @@ for the definitions of the support status levels etc.

# Release Support

-Xen-Version: 4.18-rc
-Initial-Release: n/a
-Supported-Until: TBD
-Security-Support-Until: Unreleased - not yet security-supported
+Xen-Version: 4.18
+Initial-Release: 2023-11-16
+Supported-Until: 2025-05-16
+Security-Support-Until: 2025-11-16


I thought we have a 3 years’ support lifetime, so maybe it should be 
2026-11-16, but not sure
if it is still the case.


Hmmm... You are right for the security support. I didn't do the math 
properly.


So it should be 2026-11-16. I can adjust on commit. I think the other 
date should be correct. For reference this is what we have for 4.17:


+Initial-Release: 2022-12-12
+Supported-Until: 2024-06-12
+Security-Support-Until: 2025-12-12

--
Julien Grall

Re: [PATCH for-4.18] SUPPORT.md: Define support lifetime

[Henry Wang]

Hi Julien,

> On Nov 15, 2023, at 20:35, Julien Grall  wrote:
> 
> Hi Henry,
> 
> On 15/11/2023 12:27, Henry Wang wrote:
>>> On Nov 15, 2023, at 20:16, Julien Grall  wrote:
>>> 
>>> From: Julien Grall 
>>> 
>>> Signed-off-by: Julien Grall 
>>> ---
>>> SUPPORT.md | 8 
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>> index fff4b4c5bad6..c452635eb552 100644
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>>> 
>>> # Release Support
>>> 
>>> -Xen-Version: 4.18-rc
>>> -Initial-Release: n/a
>>> -Supported-Until: TBD
>>> -Security-Support-Until: Unreleased - not yet security-supported
>>> +Xen-Version: 4.18
>>> +Initial-Release: 2023-11-16
>>> +Supported-Until: 2025-05-16
>>> +Security-Support-Until: 2025-11-16
>> I thought we have a 3 years’ support lifetime, so maybe it should be 
>> 2026-11-16, but not sure
>> if it is still the case.
> 
> Hmmm... You are right for the security support. I didn't do the math properly.
> 
> So it should be 2026-11-16. I can adjust on commit.

Thanks, adjusting on commit sounds good.

> I think the other date should be correct.

Yes it is correct.

> For reference this is what we have for 4.17:
> 
> +Initial-Release: 2022-12-12
> +Supported-Until: 2024-06-12
> +Security-Support-Until: 2025-12-12

Kind regards,
Henry

> 
> -- 
> Julien Grall

Re: [PATCH v2 07/15] xen/asm-generic: introduce stub header

[Oleksii]

On Wed, 2023-11-15 at 10:56 +0100, Jan Beulich wrote:
> On 10.11.2023 17:30, Oleksii Kurochko wrote:
> >  is common for Arm, PPC and RISC-V thereby it
> > is moved to asm-generic.
> 
> When you say "moved", ...
> 
> > Signed-off-by: Oleksii Kurochko 
> > ---
> > Changes in V2:
> >  - update the commit messages
> > ---
> >  xen/include/asm-generic/random.h | 20 
> >  1 file changed, 20 insertions(+)
> >  create mode 100644 xen/include/asm-generic/random.h
> 
> ... you also want to actually move things.
Sure, I'll delete Arm and PPC's random.h in the next patch series
version.

> 
> Since the above comment matches ones on earlier patches, yet otoh in
> your
> submissions of two individual patches you mentioned you sent them
> separately because this series wasn't fully reviewed yet, would you
> mind
> clarifying whether further going through this version of the series
> is
> actually going to be a good use of time?
I think it still makes sense to review this series.

I probably have to stop sending patches from this series separately. I
thought merging almost-ready patches would be a little faster if they
moved outside the patch series.

If it is possible to merge approved patches separately without getting
approved for the whole patch series, then what I did before doesn't
make sense, and I am sorry for this inconvenience.

I can return the patches I sent separately to this patch series.

~ Oleksii

Re: [RFC PATCH 5/6] xen/arm: Intercept vPCI config accesses and forward them to emulator

[Julien Grall]

Hi,

On 15/11/2023 11:26, Sergiy Kibrik wrote:

From: Oleksandr Tyshchenko 

This is needed for supporting virtio-pci.

In case when the PCI Host bridge is emulated outside of Xen
(IOREQ server), we need some mechanism to intercept config space
accesses on Xen on Arm, and forward them to the emulator
(for example, virtio backend) via IOREQ request.

Unlike x86, on Arm these accesses are MMIO, there is no CFC/CF8 method
to detect which PCI device is targeted.

In order to not mix PCI passthrough with virtio-pci features we add
one more region to cover the total configuration space for all possible
host bridges which can serve virtio-pci devices for that guest.
We expose one PCI host bridge per virtio backend domain.
I am a little confused. If you expose one PCI host bridge per virtio 
backend, then why can't the backend simply register the MMIO region and 
do the translation itself when it receives the read/write?


To me, it only makes sense for Xen to emulate the host bridge access if 
you plan to have one host bridge shared between multiple IOREQ domains 
or mix with PCI pasthrough.


From my perspective, I don't expect we would have that many virtio PCI 
devices. So imposing a host bridge per device emulator will mean extra 
resource in the guest as well (they need to keep track of all the 
hostbridge).


So in the longer run, I think we want to allow mixing PCI passthrough 
and virtio-PCI (or really any emulated PCI because nothing here is 
virtio specific).


For now, your approach would be OK to enable virtio PCI on Xen. But I 
don't think there are any changes necessary in Xen other than reserving 
some MMIO regions/IRQ.


Cheers,

--
Julien Grall

Re: [PATCH v2 13/15] xen/asm-generic: introduce stub header monitor.h

[Oleksii]

On Wed, 2023-11-15 at 11:00 +0100, Jan Beulich wrote:
> On 10.11.2023 17:30, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/monitor.h
> > @@ -0,0 +1,62 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * include/asm-GENERIC/monitor.h
> > + *
> > + * Arch-specific monitor_op domctl handler.
> > + *
> > + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> > + * Copyright (c) 2016, Bitdefender S.R.L.
> > + *
> > + */
> > +
> > +#ifndef __ASM_GENERIC_MONITOR_H__
> > +#define __ASM_GENERIC_MONITOR_H__
> > +
> > +#include 
> 
> What is this needed for? I expect ...
> 
> > +struct xen_domctl_monitor_op;
> > +
> > +static inline
> > +void arch_monitor_allow_userspace(struct domain *d, bool
> > allow_userspace)
> 
> ... struct domain, but since you never de-reference any such pointer,
> forward-
> declaring that (just like struct xen_domctl_monitor_op) would do
> here. Which
> would leave you with needing at most xen/types.h, but maybe as little
> as
> xen/stdbool.h and xen/stdint.h.
Yes, the reason for " #include  " was ' struct domain '.
Let's switch to forward-declaring.

Shouldn't it be included  too for inline?

~ Oleksii

> > +{
> > +}
> > +
> > +static inline
> > +int arch_monitor_domctl_op(struct domain *d, struct
> > xen_domctl_monitor_op *mop)
> > +{
> > +    /* No arch-specific monitor ops on GENERIC. */
> > +    return -EOPNOTSUPP;
> > +}
> > +
> > +int arch_monitor_domctl_event(struct domain *d,
> > +  struct xen_domctl_monitor_op *mop);
> > +
> > +static inline
> > +int arch_monitor_init_domain(struct domain *d)
> > +{
> > +    /* No arch-specific domain initialization on GENERIC. */
> > +    return 0;
> > +}
> > +
> > +static inline
> > +void arch_monitor_cleanup_domain(struct domain *d)
> > +{
> > +    /* No arch-specific domain cleanup on GENERIC. */
> > +}
> > +
> > +static inline uint32_t arch_monitor_get_capabilities(struct domain
> > *d)
> > +{
> > +    return 0;
> > +}
> > +
> > +#endif /* __ASM_GENERIC_MONITOR_H__ */
> > +
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: BSD
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 

Re: [PATCH 0/2] livepatch-tools: fixes for building on non-glibc

[Ross Lagerwall]

On Mon, Nov 13, 2023 at 4:10 PM Roger Pau Monne  wrote:
>
> Hello,
>
> A couple of fixes to allow building the tools on non-glibc systems (BSD
> and musl tested).
>
> No functional changes intended for either of the two fixes.
>

Reviewed-by: Ross Lagerwall 

Applied, thanks.

Ross

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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

version targeted for testing:
 xen  7ad0c774e474f6d95dfda868d876af507d399657
baseline version:
 xen  a48bb129f1b9ff55c22cf6d2b589247c8ba3b10e

Last test of basis   183750  2023-11-14 13:03:54 Z1 days
Testing same since   183762  2023-11-15 11:03:53 Z0 days1 attempts


People who touched revisions under test:
  Alejandro Vallejo 
  Andrew Cooper 
  Federico Serafini 
  Jan Beulich 

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
   a48bb129f1..7ad0c774e4  7ad0c774e474f6d95dfda868d876af507d399657 -> smoke

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   8 xen-bootfail pass in 183763-retest
 test-amd64-i386-qemuu-rhel6hvm-intel 14 guest-start/redhat.repeat fail pass in 
183763-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 15 migrate-support-check fail in 183763 never pass
 test-armhf-armhf-xl 16 saverestore-support-check fail in 183763 never pass
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183748
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183748
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183748
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183748
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183748
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183748
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183748
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 183748
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183748
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183748
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183748
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183748
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   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-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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  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-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 15 migrate-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-libvirt 15 migrate-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-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-amd64-amd64-libvirt-vhd 14 migrate-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
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-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-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-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

version targeted for testing:
 xen  a48bb129f1b9ff55c22cf6d2b589247c8ba3b10e
baseline version:
 xen  fb

Re: [PATCH v2 14/15] xen/asm-generic: introduce stub header numa.h

[Oleksii]

On Wed, 2023-11-15 at 11:07 +0100, Jan Beulich wrote:
> On 10.11.2023 17:30, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/numa.h
> > @@ -0,0 +1,40 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ARCH_GENERIC_NUMA_H
> > +#define __ARCH_GENERIC_NUMA_H
> > +
> > +#include 
> > +#include 
> 
> I'm afraid I can't spot what you need these for here. You clearly
> need
> xen/stdint.h, and you need xen/mm-frame.h for mfn_t. Yes, max_page is
> declared in xen/mm.h, but its questionable whether the header needs
> including here for that reason, as all uses are in macros. (We aren't
> anywhere near consistent in this regard). Plus you don't also include
> xen/cpumask.h to pull in cpu_online_map (which another macro
> references).
I agree with almost you wrote but should  be included
then? It looks like it is the same situation as with max_page and
.

> 
> > +typedef uint8_t nodeid_t;
> > +
> > +#ifndef CONFIG_NUMA
> 
> Isn't it an error to include this header when NUMA=y?
It's still need to define arch_want_default_dmazone() macros which is
used by common code.
All other code is under #ifndef CONFIG_NUMA so it won't conflict with
defintions in .

> 
> > +/* Fake one node for now. See also node_online_map. */
> > +#define cpu_to_node(cpu) 0
> > +#define node_to_cpumask(node)   (cpu_online_map)
> > +
> > +/*
> > + * TODO: make first_valid_mfn static when NUMA is supported on
> > Arm, this
> > + * is required because the dummy helpers are using it.
> > + */
> > +extern mfn_t first_valid_mfn;
> > +
> > +/* XXX: implement NUMA support */
> > +#define node_spanned_pages(nid) (max_page -
> > mfn_x(first_valid_mfn))
> > +#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
> > +#define __node_distance(a, b) (20)
> > +
> > +#endif
> > +
> > +#define arch_want_default_dmazone() (false)
> > +
> > +#endif /* __ARCH_GENERIC_NUMA_H */
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 

~ Oleksii

Re: [PATCH v2 13/15] xen/asm-generic: introduce stub header monitor.h

[Oleksii]

On Wed, 2023-11-15 at 14:54 +0200, Oleksii wrote:
> On Wed, 2023-11-15 at 11:00 +0100, Jan Beulich wrote:
> > On 10.11.2023 17:30, Oleksii Kurochko wrote:
> > > --- /dev/null
> > > +++ b/xen/include/asm-generic/monitor.h
> > > @@ -0,0 +1,62 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * include/asm-GENERIC/monitor.h
> > > + *
> > > + * Arch-specific monitor_op domctl handler.
> > > + *
> > > + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> > > + * Copyright (c) 2016, Bitdefender S.R.L.
> > > + *
> > > + */
> > > +
> > > +#ifndef __ASM_GENERIC_MONITOR_H__
> > > +#define __ASM_GENERIC_MONITOR_H__
> > > +
> > > +#include 
> > 
> > What is this needed for? I expect ...
> > 
> > > +struct xen_domctl_monitor_op;
> > > +
> > > +static inline
> > > +void arch_monitor_allow_userspace(struct domain *d, bool
> > > allow_userspace)
> > 
> > ... struct domain, but since you never de-reference any such
> > pointer,
> > forward-
> > declaring that (just like struct xen_domctl_monitor_op) would do
> > here. Which
> > would leave you with needing at most xen/types.h, but maybe as
> > little
> > as
> > xen/stdbool.h and xen/stdint.h.
> Yes, the reason for " #include  " was ' struct domain '.
> Let's switch to forward-declaring.
> 
> Shouldn't it be included  too for inline?
It should be added "#include " because EOPNOTSUPP is used
in arch_monitor_domctl_op.
> 
> ~ Oleksii
> 
> > > +{
> > > +}
> > > +
> > > +static inline
> > > +int arch_monitor_domctl_op(struct domain *d, struct
> > > xen_domctl_monitor_op *mop)
> > > +{
> > > +    /* No arch-specific monitor ops on GENERIC. */
> > > +    return -EOPNOTSUPP;
> > > +}
> > > +
> > > +int arch_monitor_domctl_event(struct domain *d,
> > > +  struct xen_domctl_monitor_op
> > > *mop);
> > > +
> > > +static inline
> > > +int arch_monitor_init_domain(struct domain *d)
> > > +{
> > > +    /* No arch-specific domain initialization on GENERIC. */
> > > +    return 0;
> > > +}
> > > +
> > > +static inline
> > > +void arch_monitor_cleanup_domain(struct domain *d)
> > > +{
> > > +    /* No arch-specific domain cleanup on GENERIC. */
> > > +}
> > > +
> > > +static inline uint32_t arch_monitor_get_capabilities(struct
> > > domain
> > > *d)
> > > +{
> > > +    return 0;
> > > +}
> > > +
> > > +#endif /* __ASM_GENERIC_MONITOR_H__ */
> > > +
> > > +
> > > +/*
> > > + * Local variables:
> > > + * mode: C
> > > + * c-file-style: BSD
> > > + * c-basic-offset: 4
> > > + * indent-tabs-mode: nil
> > > + * End:
> > > + */
> > 
> 

xen | Successful pipeline for staging-4.18 | 1924da16

[GitLab]

Pipeline #1073406875 has passed!

Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.18 ( 
https://gitlab.com/xen-project/xen/-/commits/staging-4.18 )

Commit: 1924da16 ( 
https://gitlab.com/xen-project/xen/-/commit/1924da16239703edc7be6de0f5a549a30aa84b82
 )
Commit Message: Config.mk: Fix tag for mini-os

Signed-off-by: ...
Commit Author: Julien Grall



Pipeline #1073406875 ( 
https://gitlab.com/xen-project/xen/-/pipelines/1073406875 ) triggered by Ganis 
( https://gitlab.com/ganis )
successfully completed 129 jobs in 3 stages.

-- 
You're receiving this email because of your account on gitlab.com.

Re: xen | Failed pipeline for staging-4.17 | 28f44b60

[Anthony PERARD]

On Wed, Nov 15, 2023 at 11:11:30AM +0100, Jan Beulich wrote:
> On 14.11.2023 21:26, GitLab wrote:
> > Pipeline #1072370735 ( 
> > https://gitlab.com/xen-project/xen/-/pipelines/1072370735 ) triggered by 
> > Ganis ( https://gitlab.com/ganis )
> > had 4 failed jobs.
> > 
> > Job #5534997591 ( https://gitlab.com/xen-project/xen/-/jobs/5534997591/raw )
> > 
> > Stage: build
> > Name: ubuntu-focal-gcc-debug
> > Job #5534997608 ( https://gitlab.com/xen-project/xen/-/jobs/5534997608/raw )
> > 
> > Stage: build
> > Name: alpine-3.12-gcc-debug
> > Job #5534997597 ( https://gitlab.com/xen-project/xen/-/jobs/5534997597/raw )
> > 
> > Stage: build
> 
> These three failed due to (once again) too little disk space.

Runner is "gitlab-docker-seagull".
Looks like the cleanup task that I've setup sometime ago and run
weekly only isn't enough anymore. Sorry.
I'll look at running it hourly instead.

> > Name: opensuse-leap-clang-debug
> > Job #5534997599 ( https://gitlab.com/xen-project/xen/-/jobs/5534997599/raw )
> > 
> > Stage: build
> > Name: opensuse-leap-gcc-debug
> 
> Here it's unclear, as the log referenced ends too early.

I had to log into the runner to find out, because no artifact as been
uploaded to gitlab (which would have a more complete log).
Turns out that this runner also got into a "no space left" situation.
This time, runner is "gitlab-docker-swift".

Cheers,

-- 
Anthony PERARD

Re: [PATCH v2] xen: remove

[Oleksii]

On Wed, 2023-11-15 at 11:24 +0100, Jan Beulich wrote:
> On 31.10.2023 15:28, Oleksii Kurochko wrote:
> >  only declares udelay() function so udelay()
> > declaration was moved to xen/delay.h.
> > 
> > For x86, __udelay() was renamed to udelay() and removed
> > inclusion of  in x86 code.
> > 
> > For ppc, udelay() stub definition was moved to ppc/stubs.c.
> > 
> > Suggested-by: Jan Beulich 
> > Signed-off-by: Oleksii Kurochko 
> > Reviewed-by: Jan Beulich 
> > ---
> > Changes in v2:
> >  - rebase on top of the latest staging.
> >  - add Suggested-by:/Reviewed-by: Jan Beulich .
> >  - remove  for PPC.
> >  - remove changes related to RISC-V's  as they've not
> >    introduced in staging branch yet.
> > ---
> >  xen/arch/arm/include/asm/delay.h  | 14 --
> >  xen/arch/ppc/include/asm/delay.h  | 12 
> >  xen/arch/ppc/stubs.c  |  7 +++
> >  xen/arch/x86/cpu/microcode/core.c |  2 +-
> >  xen/arch/x86/delay.c  |  2 +-
> >  xen/arch/x86/include/asm/delay.h  | 13 -
> >  xen/include/xen/delay.h   |  2 +-
> >  7 files changed, 10 insertions(+), 42 deletions(-)
> >  delete mode 100644 xen/arch/arm/include/asm/delay.h
> >  delete mode 100644 xen/arch/ppc/include/asm/delay.h
> >  delete mode 100644 xen/arch/x86/include/asm/delay.h
> 
> Shawn: As per the diffstat below your ack is needed here. Recently I
> did
> (silently) time out on two sufficiently trivial (PPC-wise) patches,
> but
> this shouldn't become a common pattern.
> 
> Oleksii: It is normally on the submitter to chase missing acks.
Probably it wasn't right but I sent a private e-mail to Shawn last week
with the request. I'll do it publicly next time.

~ Oleksii

Re: [PATCH v2 08/15] xen/asm-generic: introduce generic header percpu.h

[Oleksii]

I have to drop arch specific headers and switch to asm-generic version.
I'll do the same for patches 09-12 in the next patch version.

~ Oleksii
On Fri, 2023-11-10 at 18:30 +0200, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V2:
> - use smp_processor_id() instead of get_processor_id().
> - update commit message .
> ---
>  xen/include/asm-generic/percpu.h | 35
> 
>  1 file changed, 35 insertions(+)
>  create mode 100644 xen/include/asm-generic/percpu.h
> 
> diff --git a/xen/include/asm-generic/percpu.h b/xen/include/asm-
> generic/percpu.h
> new file mode 100644
> index 00..85a3f3ef17
> --- /dev/null
> +++ b/xen/include/asm-generic/percpu.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_PERCPU_H__
> +#define __ASM_GENERIC_PERCPU_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +
> +extern char __per_cpu_start[], __per_cpu_data_end[];
> +extern unsigned long __per_cpu_offset[NR_CPUS];
> +void percpu_init_areas(void);
> +
> +#define per_cpu(var, cpu)  \
> +    (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> +
> +#define this_cpu(var) \
> +    (*RELOC_HIDE(&per_cpu__##var,
> __per_cpu_offset[smp_processor_id()]))
> +
> +#define per_cpu_ptr(var, cpu)  \
> +    (*RELOC_HIDE(var, __per_cpu_offset[cpu]))
> +#define this_cpu_ptr(var) \
> +    (*RELOC_HIDE(var, smp_processor_id()))
> +
> +#endif
> +
> +#endif /* __ASM_GENERIC_PERCPU_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

[Discussion]: Making "LIBXL_HOTPLUG_TIMEOUT" configurable through 'xl.conf'

[Divin Raj]

Hi Xen community,

On one of our internal projects we came across an issue in the 
toolstack: when multiple network interfaces are initialized 
concurrently with other system workloads, the execution time of the 
hotplug script often exceeds 40 seconds, leading to an error.
To mitigate this issue, we are considering making 
“LIBXL_HOTPLUG_TIMEOUT” configurable through ‘xl.conf’, instead of 
increasing the hard-coded “hotplug timeout”, do you think it could 
make sense?We would greatly appreciate any feedback, suggestions, or 
improvements you could provide.

Thank you for your time and consideration.

Regards
Divin

Re: [RFC PATCH 6/6] libxl: Add "backend_type" property for the Virtio devices

[Juergen Gross]

On 15.11.23 12:44, Sergiy Kibrik wrote:

From: Oleksandr Tyshchenko 

Introduce new configuration option "backend_type" for the Virtio
devices in order to specify backend implementation to use.
There are two possible values "qemu" (default) and "standalone".

If backend is in Qemu (backend_type=qemu) and Qemu runs in toolstack
domain (backend=Domain-0) then Qemu will be launched automatically
at the guest creation time. For this to work implement "dm_needed"
callback.

Please note, there is no support for Qemu in other domains for
the time being, so the combination of "backend=DomD" and
"backend_type=qemu" just won't work.

Qemu configuration for Virtio devices should be described via
"device_model_args" property.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 


Reviewed-by: Juergen Gross 


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[linux-linus test] 183759: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64   broken
 test-amd64-amd64-xl-qemut-debianhvm-amd64 5 host-install(5) broken REGR. vs. 
183746

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183746
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183746
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183746
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183746
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183746
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183746
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183746
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183746
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail 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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-libvirt-qcow2 14 migrate-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-amd64-amd64-libvirt-raw 14 migrate-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-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
 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-libvirt-qcow2 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

version targeted for testing:
 linux86d11b0e20c09e0a91cd2aa57b115000274e2ac5
baseline version:
 linux9bacdd8996c77c42ca004440be610692275ff9d0

Last test of basis   183746  2023-11-13 17:42:24 Z1 days
Testing same since   183759  2023-11-15 04:41:05 Z0 days1 attempts


People who touched revisions under test:
  Bob Peterson 
  Linus Torvalds 
  Nick Terrell 

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

Re: Values generated by the ViryaOS uboot-script-gen do not work correctly on the Chromebook Snow

[Chuck Zmudzinski]

On 11/14/2023 6:43 PM, Mario Marietto wrote:
> I hope that the informations below are correct :

I don't know that they are correct. I have not spent the necessary time to
determine what the correct values for MEMORY_START and MEMORY_END are for
the Chromebook we are using. I just presumed, probably incorrectly, that
the entire 2 GB memory is safe, but obviously that is not the case with
this Chromebook. Most likely, it requires a good understanding of the
particular way booting is done on a Chromebook, which seems to be different
from other devices.

I plan to eventually look into finding values for MEMORY_START and MEMORY_END
sothe uboot-script-gen script computes usable values for loading Xen and dom0
on this Chromebook in the script, but I might not get to that task immediately.
I plan to look at it within the next week or so.

> 
> - the imagebuilder config file :
> 
> MEMORY_START="0x0"
> MEMORY_END="0x8000"
> LOAD_CMD="ext2load mmc 1:3"
> BOOT_CMD="bootm"
> DEVICE_TREE="exynos5250-snow.dtb"
> XEN="xen-4.17-armhf"
> XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M dom0_max_vcpus=2 
> bootscrub=0 vwfi=native sched=null"
> DOM0_KERNEL="zImage-6.6.0-xen-iommu-dma-on-xen"
> DOM0_CMD="console=tty earlycon=xen earlyprintk=xen root=/dev/mmcblk1p4 rw 
> rootwait clk_ignore_unused"
> UBOOT_SOURCE="xen.source"
> UBOOT_SCRIPT="xen.scr"
> 
> xen.source : (that does not work)
> 
> mmc dev 1
> ext2load mmc 1:3 0xE0 zImage-6.6.0-xen-iommu-dma-on-xen
> ext2load mmc 1:3 0x180 xen-4.17-armhf.ub
> ext2load mmc 1:3 0x1A0 exynos5250-snow.dtb
> fdt addr 0x1A0
> fdt resize 1024
> fdt set /chosen \#address-cells <0x2>
> fdt set /chosen \#size-cells <0x2>
> fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 
> dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> fdt mknod /chosen dom0
> fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module" 
> "multiboot,module"
> fdt set /chosen/dom0 reg <0x0 0xE0 0x0 0x87C200 >
> fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen 
> root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
> setenv fdt_high 0x
> bootm 0x180 - 0x1A0
> 
> xen.source : (created by chuck and that works)
> 
> mmc dev 1
> ext2load mmc 1:3 0x4200 zImage-6.6.0-xen-iommu-dma-on-xen
> ext2load mmc 1:3 0x5100 xen-4.17-armhf-armmp-0x51004000.ub
> ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb
> fdt addr 0x5ffec000
> fdt resize 1024
> fdt set /chosen \#address-cells <0x2>
> fdt set /chosen \#size-cells <0x2>
> fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 
> dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> fdt mknod /chosen dom0
> fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module" 
> "multiboot,module"
> fdt set /chosen/dom0 reg <0x0 0x4200 0x0 0x87C200 >
> fdt set /chosen xen,dom0-bootargs "console=tty1 root=/dev/mmcblk1p4 rw 
> rootwait clk_ignore_unused --no-log"
> bootm 0x5100 - 0x5ffec000
> 
> all the values that you see in this conf. files have been calculated by chuck 
> by hand,because the values generated by the imagebuilder are wrong. The only 
> value that's well calculated by the imagebuilder is 0x87C200
> 
> - the size of all the binaries specified in the imagebuilder config file :
> 
> exynos5250-snow.dtb = 46.6 KiB (47,769 byte)
> zImage-6.6.0-xen-iommu-dma-on-xen = 8.5 MiB (8,897,024 byte)
> 
> 
> 
> On Wed, Nov 15, 2023 at 12:17 AM Stefano Stabellini  > wrote:
> 
> Hi Mario,
> 
> I think we misunderstood each other :-)
> 
> MEMORY_START-MEMORY_END is not supposed to be computed: it is supposed
> to come from the memory node in device tree tree (/memory) of the
> platform. The idea is that you should not have to do any computations,
> but only reuse the same address range specified there.
> 
> Similarly in regards to "please post the size of all the binaries",
> this is just for debugging, so that I can see if there are any bugs with
> uboot-script-gen. I cannot debug the script unless I figure out what the
> problem is and the only way I can do that is with the binary sizes and
> redoing all the steps by hand.
> 
> The expected outcome is that once we resolve the problem you should be
> able to use uboot-script-gen without any additional computation needed.
> 
> Of course using static values is also OK.
> 
> 
> On Wed, 15 Nov 2023, Mario Marietto wrote:
> > ---> uboot-script-gen assumes that the memory range specified by 
> MEMORY_START-MEMORY_END is valid and correct.
> >
> > Actually Chuck chose 0 as MEMORY_START and 0x80 as MEMORY_END and 
> these are stable values,they don't change. If you ask me to calculate
> > those values,it means that we need to compute these values. I imagine 
> that to calculate these values is not easy.
> >
> > ---> To debug this kind of issues please post the

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Oleksandr Tyshchenko]

On 15.11.23 14:33, Julien Grall wrote:
> Hi,


Hello Julien

Let me please try to explain some bits.


> 
> Thanks for adding support for virtio-pci in Xen. I have some questions.
> 
> On 15/11/2023 11:26, Sergiy Kibrik wrote:
>> From: Oleksandr Tyshchenko 
>>
>> In order to enable more use-cases such as having multiple
>> device-models (Qemu) running in different backend domains which provide
>> virtio-pci devices for the same guest, we allocate and expose one
>> PCI host bridge for every virtio backend domain for that guest.
> 
> OOI, why do you need to expose one PCI host bridge for every stubdomain?
> 
> In fact looking at the next patch, it seems you are handling some of the 
> hostbridge request in Xen. This is adds a bit more confusion.
> 
> I was expecting the virtual PCI device would be in the vPCI and each 
> Device emulator would advertise which BDF they are covering.


This patch series only covers use-cases where the device emulator 
handles the *entire* PCI Host bridge and PCI (virtio-pci) devices behind 
it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI 
pass-through resources, handling, accounting, nothing. From the 
hypervisor we only need a help to intercept the config space accesses 
happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ... 
GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and 
forward them to the linked device emulator (if any), that's all.

It is not possible (with current series) to run device emulators what
emulate only separate PCI (virtio-pci) devices. For it to be possible, I 
think, much more changes are required than current patch series does. 
There at least should be special PCI Host bridge emulation in Xen (or 
reuse vPCI) for the integration. Also Xen should be in charge of forming 
resulting PCI interrupt based on each PCI device level signaling (if we 
use legacy interrupts), some kind of x86's XEN_DMOP_set_pci_intx_level, 
etc. Please note, I am not saying this is not possible in general, 
likely it is possible, but initial patch series doesn't cover these 
use-cases)

We expose one PCI host bridge per virtio backend domain. This is a 
separate PCI host bridge to combine all virtio-pci devices running in 
the same backend domain (in the same device emulator currently).
The examples:
- if only one domain runs Qemu which servers virtio-blk, virtio-net, 
virtio-console devices for DomU - only single PCI Host bridge will be 
exposed for DomU
- if we add another domain to run Qemu to serve additionally virtio-gpu, 
virtio-input and virtio-snd for the *same* DomU - we expose second PCI 
Host bridge for DomU

I am afraid, we cannot end up exposing only single PCI Host bridge with 
current model (if we use device emulators running in different domains 
that handles the *entire* PCI Host bridges), this won't work.

Please note, I might miss some bits since this enabling work.


> 
>>
>> For that purpose, reserve separate virtio-pci resources (memory and 
>> SPI range
>> for Legacy PCI interrupts) up to 8 possible PCI hosts (to be aligned with
> 
> Do you mean host bridge rather than host?

yes


> 
>> MAX_NR_IOREQ_SERVERS) and allocate a host per backend domain. The PCI 
>> host
>> details including its host_id to be written to dedicated Xenstore node 
>> for
>> the device-model to retrieve.
> 
> So which with approach, who is decide which BDF will be used for a given 
> virtio PCI device?


toolstack (via configuration file)

> 
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> Signed-off-by: Sergiy Kibrik 
>> ---
>>   xen/include/public/arch-arm.h | 21 +
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/xen/include/public/arch-arm.h 
>> b/xen/include/public/arch-arm.h
>> index a25e87dbda..e6c9cd5335 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -466,6 +466,19 @@ typedef uint64_t xen_callback_t;
>>   #define GUEST_VPCI_MEM_ADDR xen_mk_ullong(0x2300)
>>   #define GUEST_VPCI_MEM_SIZE xen_mk_ullong(0x1000)
>> +/*
>> + * 16 MB is reserved for virtio-pci configuration space based on 
>> calculation
>> + * 8 bridges * 2 buses x 32 devices x 8 functions x 4 KB = 16 MB
> 
> Can you explain how youd ecided the "2"?

good question, we have a limited free space available in memory layout 
(we had difficulties to find a suitable holes) also we don't expect a 
lot of virtio-pci devices, so "256" used vPCI would be too much. It was 
decided to reduce significantly, but select maximum to fit into free 
space, with having "2" buses we still fit into the chosen holes.


> 
>> + */
>> +#define GUEST_VIRTIO_PCI_ECAM_BASE  xen_mk_ullong(0x3300)
>> +#define GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE    xen_mk_ullong(0x0100)
>> +#define GUEST_VIRTIO_PCI_HOST_ECAM_SIZE xen_mk_ullong(0x0020)
>> +
>> +/* 64 MB is reserved for virtio-pci memory */
>> +#define GUEST_VIRTIO_PCI_ADDR_TYPE_MEM    xen_mk_ullong(0x0200)
>> +#define GUEST_VIRTIO_PCI_ME

xen | Failed pipeline for staging | 7ad0c774

[GitLab]

Pipeline #1073278423 has failed!

Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )

Commit: 7ad0c774 ( 
https://gitlab.com/xen-project/xen/-/commit/7ad0c774e474f6d95dfda868d876af507d399657
 )
Commit Message: x86/boot: tidy #include-s

As of d58a509e01c4 (...
Commit Author: Jan Beulich ( https://gitlab.com/jbeulich )


Pipeline #1073278423 ( 
https://gitlab.com/xen-project/xen/-/pipelines/1073278423 ) triggered by Ganis 
( https://gitlab.com/ganis )
had 8 failed jobs.

Job #5541061819 ( https://gitlab.com/xen-project/xen/-/jobs/5541061819/raw )

Stage: analyze
Name: eclair-ARM64
Job #5541061940 ( https://gitlab.com/xen-project/xen/-/jobs/5541061940/raw )

Stage: build
Name: alpine-3.18-clang-debug
Job #5541062280 ( https://gitlab.com/xen-project/xen/-/jobs/5541062280/raw )

Stage: build
Name: opensuse-leap-gcc
Job #5541062296 ( https://gitlab.com/xen-project/xen/-/jobs/5541062296/raw )

Stage: build
Name: opensuse-tumbleweed-clang
Job #5541062200 ( https://gitlab.com/xen-project/xen/-/jobs/5541062200/raw )

Stage: build
Name: fedora-gcc-debug
Job #5541062233 ( https://gitlab.com/xen-project/xen/-/jobs/5541062233/raw )

Stage: build
Name: ubuntu-bionic-gcc
Job #5541062243 ( https://gitlab.com/xen-project/xen/-/jobs/5541062243/raw )

Stage: build
Name: ubuntu-focal-gcc
Job #5541062248 ( https://gitlab.com/xen-project/xen/-/jobs/5541062248/raw )

Stage: build
Name: ubuntu-focal-gcc-debug

-- 
You're receiving this email because of your account on gitlab.com.

Re: [Discussion]: Making "LIBXL_HOTPLUG_TIMEOUT" configurable through 'xl.conf'

[Olaf Hering]

Wed, 15 Nov 2023 15:29:09 + Divin Raj :

> LIBXL_HOTPLUG_TIMEOUT

This is already solved by "libxl.LIBXL_HOTPLUG_TIMEOUT.patch" from 
https://build.opensuse.org/package/show/openSUSE:Factory/xen
Up to now it was not considered important enough for xen.git#staging.


Olaf


pgpNn3pRObDgi.pgp
Description: Digitale Signatur von OpenPGP

[PATCH 2/3] vl: disable default serial when xen-console is enabled

[David Woodhouse]

From: David Woodhouse 

If a Xen console is configured on the command line, do not add a default
serial port.

Signed-off-by: David Woodhouse 
---
 system/vl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/system/vl.c b/system/vl.c
index 5af7ced2a1..8109231834 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -198,6 +198,7 @@ static const struct {
 const char *driver;
 int *flag;
 } default_list[] = {
+{ .driver = "xen-console",  .flag = &default_serial},
 { .driver = "isa-serial",   .flag = &default_serial},
 { .driver = "isa-parallel", .flag = &default_parallel  },
 { .driver = "isa-fdc",  .flag = &default_floppy},
-- 
2.41.0

[PATCH 1/3] net: do not delete nics in net_cleanup()

[David Woodhouse]

From: David Woodhouse 

In net_cleanup() we only need to delete the netdevs, as those may have
state which outlives Qemu when it exits, and thus may actually need to
be cleaned up on exit.

The nics, on the other hand, are owned by the device which created them.
Most devices don't bother to clean up on exit because they don't have
any state which will outlive Qemu... but XenBus devices do need to clean
up their nodes in XenStore, and do have an exit handler to delete them.

When the XenBus exit handler destroys the xen-net-device, it attempts
to delete its nic after net_cleanup() had already done so. And crashes.

Fix this by only deleting netdevs as we walk the list. As the comment
notes, we can't use QTAILQ_FOREACH_SAFE() as each deletion may remove
*multiple* entries, including the "safely" saved 'next' pointer. But
we can store the *previous* entry, since nics are safe.

Signed-off-by: David Woodhouse 
Reviewed-by: Paul Durrant 
---
 net/net.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/net/net.c b/net/net.c
index c0c0cbe99e..bbe33da176 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1499,18 +1499,34 @@ static void net_vm_change_state_handler(void *opaque, 
bool running,
 
 void net_cleanup(void)
 {
-NetClientState *nc;
+NetClientState *nc, **p = &QTAILQ_FIRST(&net_clients);
 
 /*cleanup colo compare module for COLO*/
 colo_compare_cleanup();
 
-/* We may del multiple entries during qemu_del_net_client(),
- * so QTAILQ_FOREACH_SAFE() is also not safe here.
+/*
+ * Walk the net_clients list and remove the netdevs but *not* any
+ * NET_CLIENT_DRIVER_NIC entries. The latter are owned by the device
+ * model which created them, and in some cases (e.g. xen-net-device)
+ * the device itself may do cleanup at exit and will be upset if we
+ * just delete its NIC from underneath it.
+ *
+ * Since qemu_del_net_client() may delete multiple entries, using
+ * QTAILQ_FOREACH_SAFE() is not safe here. The only safe pointer
+ * to keep as a bookmark is a NET_CLIENT_DRIVER_NIC entry, so keep
+ * 'p' pointing to either the head of the list, or the 'next' field
+ * of the latest NET_CLIENT_DRIVER_NIC, and operate on *p as we walk
+ * the list.
+ *
+ * The 'nc' variable isn't part of the list traversal; it's purely
+ * for convenience as too much '(*p)->' has a tendency to make the
+ * readers' eyes bleed.
  */
-while (!QTAILQ_EMPTY(&net_clients)) {
-nc = QTAILQ_FIRST(&net_clients);
+while (*p) {
+nc = *p;
 if (nc->info->type == NET_CLIENT_DRIVER_NIC) {
-qemu_del_nic(qemu_get_nic(nc));
+/* Skip NET_CLIENT_DRIVER_NIC entries */
+p = &QTAILQ_NEXT(nc, next);
 } else {
 qemu_del_net_client(nc);
 }
-- 
2.41.0

[PATCH 3/3] hw/xen: clean up xen_block_find_free_vdev() to avoid Coverity false positive

[David Woodhouse]

From: David Woodhouse 

Coverity couldn't see that nr_existing was always going to be zero when
qemu_xen_xs_directory() returned NULL in the ENOENT case (CID 1523906).

Perhaps more to the point, neither could Peter at first glance. Improve
the code to hopefully make it clearer to Coverity and human reviewers
alike.

Signed-off-by: David Woodhouse 
---
 hw/block/xen-block.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 6d64ede94f..aed1d5c330 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -91,9 +91,27 @@ static bool xen_block_find_free_vdev(XenBlockDevice 
*blockdev, Error **errp)
 
 existing_frontends = qemu_xen_xs_directory(xenbus->xsh, XBT_NULL, fe_path,
&nr_existing);
-if (!existing_frontends && errno != ENOENT) {
-error_setg_errno(errp, errno, "cannot read %s", fe_path);
-return false;
+if (!existing_frontends) {
+if (errno == ENOENT) {
+/*
+ * If the frontend directory doesn't exist because there are
+ * no existing vbd devices, that's fine. Just ensure that we
+ * don't dereference the NULL existing_frontends pointer, by
+ * checking that nr_existing is zero so the loop below is not
+ * entered.
+ *
+ * In fact this is redundant since nr_existing is initialized
+ * to zero, but setting it again here makes it abundantly clear
+ * to Coverity, and to the human reader who doesn't know the
+ * semantics of qemu_xen_xs_directory() off the top of their
+ * head.
+ */
+nr_existing = 0;
+} else {
+/* All other errors accessing the frontend directory are fatal. */
+error_setg_errno(errp, errno, "cannot read %s", fe_path);
+return false;
+}
 }
 
 memset(used_devs, 0, sizeof(used_devs));
-- 
2.41.0

[PATCH 0/3] Misc fixes for 8.2

[David Woodhouse]

Fix a use-after-free (or double-free) due to net_cleanup() freeing NICs
that don't belong to it, fix a newly-introduced launch failure with a
documented command line, and clean up code to avoid a Coverity warning.

David Woodhouse (3):
  net: do not delete nics in net_cleanup()
  vl: disable default serial when xen-console is enabled
  hw/xen: clean up xen_block_find_free_vdev() to avoid Coverity false 
positive

 hw/block/xen-block.c | 24 +---
 net/net.c| 28 ++--
 system/vl.c  |  1 +
 3 files changed, 44 insertions(+), 9 deletions(-)

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Julien Grall]

Hi Oleksandr,

On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:



On 15.11.23 14:33, Julien Grall wrote:

Hi,



Hello Julien

Let me please try to explain some bits.




Thanks for adding support for virtio-pci in Xen. I have some questions.

On 15/11/2023 11:26, Sergiy Kibrik wrote:

From: Oleksandr Tyshchenko 

In order to enable more use-cases such as having multiple
device-models (Qemu) running in different backend domains which provide
virtio-pci devices for the same guest, we allocate and expose one
PCI host bridge for every virtio backend domain for that guest.


OOI, why do you need to expose one PCI host bridge for every stubdomain?

In fact looking at the next patch, it seems you are handling some of the
hostbridge request in Xen. This is adds a bit more confusion.

I was expecting the virtual PCI device would be in the vPCI and each
Device emulator would advertise which BDF they are covering.



This patch series only covers use-cases where the device emulator
handles the *entire* PCI Host bridge and PCI (virtio-pci) devices behind
it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI
pass-through resources, handling, accounting, nothing. 


I understood you want to one Device Emulator to handle the entire PCI 
host bridge. But...


From the

hypervisor we only need a help to intercept the config space accesses
happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ...
GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and
forward them to the linked device emulator (if any), that's all.


... I really don't see why you need to add code in Xen to trap the 
region. If QEMU is dealing with the hostbridge, then it should be able 
to register the MMIO region and then do the translation.




It is not possible (with current series) to run device emulators what
emulate only separate PCI (virtio-pci) devices. For it to be possible, I
think, much more changes are required than current patch series does.
There at least should be special PCI Host bridge emulation in Xen (or
reuse vPCI) for the integration. Also Xen should be in charge of forming
resulting PCI interrupt based on each PCI device level signaling (if we
use legacy interrupts), some kind of x86's XEN_DMOP_set_pci_intx_level,
etc. Please note, I am not saying this is not possible in general,
likely it is possible, but initial patch series doesn't cover these
use-cases)

We expose one PCI host bridge per virtio backend domain. This is a
separate PCI host bridge to combine all virtio-pci devices running in
the same backend domain (in the same device emulator currently).
The examples:
- if only one domain runs Qemu which servers virtio-blk, virtio-net,
virtio-console devices for DomU - only single PCI Host bridge will be
exposed for DomU
- if we add another domain to run Qemu to serve additionally virtio-gpu,
virtio-input and virtio-snd for the *same* DomU - we expose second PCI
Host bridge for DomU

I am afraid, we cannot end up exposing only single PCI Host bridge with
current model (if we use device emulators running in different domains
that handles the *entire* PCI Host bridges), this won't work.


That makes sense and it is fine. But see above, I think only the #2 is 
necessary for the hypervisor. Patch #5 should not be necessary at all.


[...]


Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Sergiy Kibrik 
---
   xen/include/public/arch-arm.h | 21 +
   1 file changed, 21 insertions(+)

diff --git a/xen/include/public/arch-arm.h
b/xen/include/public/arch-arm.h
index a25e87dbda..e6c9cd5335 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -466,6 +466,19 @@ typedef uint64_t xen_callback_t;
   #define GUEST_VPCI_MEM_ADDR xen_mk_ullong(0x2300)
   #define GUEST_VPCI_MEM_SIZE xen_mk_ullong(0x1000)
+/*
+ * 16 MB is reserved for virtio-pci configuration space based on
calculation
+ * 8 bridges * 2 buses x 32 devices x 8 functions x 4 KB = 16 MB


Can you explain how youd ecided the "2"?


good question, we have a limited free space available in memory layout
(we had difficulties to find a suitable holes) also we don't expect a
lot of virtio-pci devices, so "256" used vPCI would be too much. It was
decided to reduce significantly, but select maximum to fit into free
space, with having "2" buses we still fit into the chosen holes.


If you don't expect a lot of virtio devices, then why do you need two 
buses? Wouldn't one be sufficient?








+ */
+#define GUEST_VIRTIO_PCI_ECAM_BASE  xen_mk_ullong(0x3300)
+#define GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE    xen_mk_ullong(0x0100)
+#define GUEST_VIRTIO_PCI_HOST_ECAM_SIZE xen_mk_ullong(0x0020)
+
+/* 64 MB is reserved for virtio-pci memory */
+#define GUEST_VIRTIO_PCI_ADDR_TYPE_MEM    xen_mk_ullong(0x0200)
+#define GUEST_VIRTIO_PCI_MEM_ADDR xen_mk_ullong(0x3400)
+#define GUEST_VIRTIO_PCI_MEM_SIZE xen_mk_ullong(0x0400)
+
   /*
    * 16MB == 4096 pages 

Re: [PATCH] arm/mm: add option to prefer IOMMU ops for DMA on Xen

[Chuck Zmudzinski]

On 11/14/2023 5:20 PM, Stefano Stabellini wrote:
> On Tue, 14 Nov 2023, Robin Murphy wrote:
>> On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
>> > Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
>> > attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
>> > (and probably on other devices that use the Exynos mixer):
>> > 
>> > [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
>> > exynos-drm exynos-drm: bound 1440.fimd (ops 0xc0d96354)
>> > exynos-mixer 1445.mixer: [drm:exynos_drm_register_dma] *ERROR* Device
>> >   1445.mixer lacks support for IOMMU
>> > exynos-drm exynos-drm: failed to bind 1445.mixer (ops 0xc0d97554): -22
>> > exynos-drm exynos-drm: adev bind failed: -22
>> > exynos-dp: probe of 145b.dp-controller failed with error -22
>> > 
>> > Linux normally uses xen_swiotlb_dma_ops for DMA for all devices when
>> > xen_swiotlb is detected even when Xen exposes an IOMMU to Linux. Enabling
>> > the new config option allows devices such as the Exynos mixer to use the
>> > IOMMU instead of xen_swiotlb_dma_ops for DMA and this fixes the error.
>> > 
>> > The new config option is not set by default because it is likely some
>> > devices that use IOMMU for DMA on Xen will cause DMA errors and memory
>> > corruption when Xen PV block and network drivers are in use on the system.
>> > 
>> > Link:
>> > https://lore.kernel.org/xen-devel/acfab1c5-eed1-4930-8c70-8681e256c...@netscape.net/
>> > 
>> > Signed-off-by: Chuck Zmudzinski 
>> > ---
>> > The reported error with the Exynos mixer is not fixed by default by adding
>> > a second patch to select the new option in the Kconfig definition for the
>> > Exynos mixer if EXYNOS_IOMMU and SWIOTLB_XEN are enabled because it is
>> > not certain setting the config option is suitable for all cases. So it is
>> > necessary to explicitly select the new config option during the config
>> > stage of the Linux kernel build to fix the reported error or similar
>> > errors that have the same cause of lack of support for IOMMU on Xen. This
>> > is necessary to avoid any regressions that might be caused by enabling the
>> > new option by default for the Exynos mixer.
>> >   arch/arm/mm/dma-mapping.c |  6 ++
>> >   drivers/xen/Kconfig   | 16 
>> >   2 files changed, 22 insertions(+)
>> > 
>> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> > index 5409225b4abc..ca04fdf01be3 100644
>> > --- a/arch/arm/mm/dma-mapping.c
>> > +++ b/arch/arm/mm/dma-mapping.c
>> > @@ -1779,6 +1779,12 @@ void arch_setup_dma_ops(struct device *dev, u64
>> > dma_base, u64 size,
>> >if (iommu)
>> >arm_setup_iommu_dma_ops(dev, dma_base, size, iommu, coherent);
>> >   +#ifdef CONFIG_ARM_DMA_USE_IOMMU_XEN
>> 
>> FWIW I don't think this really needs a config option - if Xen *has* made an
>> IOMMU available, then there isn't really much reason not to use it, and if 
>> for
>> some reason someone really didn't want to then they could simply disable the
>> IOMMU driver anyway.
> 
> The fact that the Exynos IOMMU is exposed to Linux is a mistake. Xen
> doesn't recognize the Exynos IOMMU (it is not one of the IOMMUs Xen has
> a driver for) so it assigns the IOMMU to Dom0. It doesn't happen on
> purpose, it happens by accident. Certain things are going to break,
> specifically I am fairly certain PV drivers are going to break.
> 
> If Xen recognized the Exynos IOMMU as an IOMMU it would probably hide it
> from Dom0. (Today Xen doesn't have a list of IOMMUs Xen recognizes but
> doesn't have a driver for.)
> 
> I think it is OK for Chuck and others to play around with this
> configuration but I wouldn't add a new kconfig option to Linux to
> support it.
> 
> If we do want a kconfig option, I would add a kconfig option or Linux
> command line option to enable/disable swiotlb-xen. Basically a way to
> force-enable or force-disable xen_swiotlb_detect(). That could be
> generally useful for debugging and would also solve the problem here as
> it could be used to force-disable swiotlb-xen. I would imagine that the
> end result is the same: the default ops (iommu_ops) are used.

I will try this. It isn't exactly what I have tested until now because
in all my tests so far all the DMA capable devices on the Chromebook use
swioltlb-xen except for the two devices that need to use the Exynos IOMMU
to fix the error with the Exynos mixer.

> 
> 
> 
>> > +  if (dev->dma_ops == &iommu_ops) {
>> > +  dev->archdata.dma_ops_setup = true;
>> 
>> The existing assignment is effectively unconditional by this point anyway, so
>> could probably just be moved earlier to save duplicating it (or perhaps just
>> make the xen_setup_dma_ops() call conditional instead to save the early 
>> return
>> as well).
>> 
>> However, are the IOMMU DMA ops really compatible with Xen? The comments about
>> hypercalls and foreign memory in xen_arch_need_swiotlb() leave me concerned
>>

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Oleksandr Tyshchenko]

On 15.11.23 19:31, Julien Grall wrote:
> Hi Oleksandr,


Hello Julien

> 
> On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:
>>
>>
>> On 15.11.23 14:33, Julien Grall wrote:
>>> Hi,
>>
>>
>> Hello Julien
>>
>> Let me please try to explain some bits.
>>
>>
>>>
>>> Thanks for adding support for virtio-pci in Xen. I have some questions.
>>>
>>> On 15/11/2023 11:26, Sergiy Kibrik wrote:
 From: Oleksandr Tyshchenko 

 In order to enable more use-cases such as having multiple
 device-models (Qemu) running in different backend domains which provide
 virtio-pci devices for the same guest, we allocate and expose one
 PCI host bridge for every virtio backend domain for that guest.
>>>
>>> OOI, why do you need to expose one PCI host bridge for every stubdomain?
>>>
>>> In fact looking at the next patch, it seems you are handling some of the
>>> hostbridge request in Xen. This is adds a bit more confusion.
>>>
>>> I was expecting the virtual PCI device would be in the vPCI and each
>>> Device emulator would advertise which BDF they are covering.
>>
>>
>> This patch series only covers use-cases where the device emulator
>> handles the *entire* PCI Host bridge and PCI (virtio-pci) devices behind
>> it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI
>> pass-through resources, handling, accounting, nothing. 
> 
> I understood you want to one Device Emulator to handle the entire PCI 
> host bridge. But...
> 
>  From the
>> hypervisor we only need a help to intercept the config space accesses
>> happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ...
>> GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and
>> forward them to the linked device emulator (if any), that's all.
> 
> ... I really don't see why you need to add code in Xen to trap the 
> region. If QEMU is dealing with the hostbridge, then it should be able 
> to register the MMIO region and then do the translation.


Hmm, sounds surprising I would say. Are you saying that unmodified Qemu 
will work if we drop #5? I think this wants to be re-checked (@Sergiy 
can you please investigate?). If indeed so, than #5 will be dropped of 
course from the that series (I would say, postponed until more use-cases).



> 
>>
>> It is not possible (with current series) to run device emulators what
>> emulate only separate PCI (virtio-pci) devices. For it to be possible, I
>> think, much more changes are required than current patch series does.
>> There at least should be special PCI Host bridge emulation in Xen (or
>> reuse vPCI) for the integration. Also Xen should be in charge of forming
>> resulting PCI interrupt based on each PCI device level signaling (if we
>> use legacy interrupts), some kind of x86's XEN_DMOP_set_pci_intx_level,
>> etc. Please note, I am not saying this is not possible in general,
>> likely it is possible, but initial patch series doesn't cover these
>> use-cases)
>>
>> We expose one PCI host bridge per virtio backend domain. This is a
>> separate PCI host bridge to combine all virtio-pci devices running in
>> the same backend domain (in the same device emulator currently).
>> The examples:
>> - if only one domain runs Qemu which servers virtio-blk, virtio-net,
>> virtio-console devices for DomU - only single PCI Host bridge will be
>> exposed for DomU
>> - if we add another domain to run Qemu to serve additionally virtio-gpu,
>> virtio-input and virtio-snd for the *same* DomU - we expose second PCI
>> Host bridge for DomU
>>
>> I am afraid, we cannot end up exposing only single PCI Host bridge with
>> current model (if we use device emulators running in different domains
>> that handles the *entire* PCI Host bridges), this won't work.
> 
> That makes sense and it is fine. But see above, I think only the #2 is 
> necessary for the hypervisor. Patch #5 should not be necessary at all.


Good, it should be re-checked without #5 sure.


> 
> [...]
> 
 Signed-off-by: Oleksandr Tyshchenko 
 Signed-off-by: Sergiy Kibrik 
 ---
    xen/include/public/arch-arm.h | 21 +
    1 file changed, 21 insertions(+)

 diff --git a/xen/include/public/arch-arm.h
 b/xen/include/public/arch-arm.h
 index a25e87dbda..e6c9cd5335 100644
 --- a/xen/include/public/arch-arm.h
 +++ b/xen/include/public/arch-arm.h
 @@ -466,6 +466,19 @@ typedef uint64_t xen_callback_t;
    #define GUEST_VPCI_MEM_ADDR 
 xen_mk_ullong(0x2300)
    #define GUEST_VPCI_MEM_SIZE 
 xen_mk_ullong(0x1000)
 +/*
 + * 16 MB is reserved for virtio-pci configuration space based on
 calculation
 + * 8 bridges * 2 buses x 32 devices x 8 functions x 4 KB = 16 MB
>>>
>>> Can you explain how youd ecided the "2"?
>>
>> good question, we have a limited free space available in memory layout
>> (we had difficulties to find a suitable holes) also we don't expect a
>> lot of virtio-pci devices, so "256" used vPCI would be too much. It was
>> decided t

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Julien Grall]

Hi Oleksandr,

On 15/11/2023 18:14, Oleksandr Tyshchenko wrote:

On 15.11.23 19:31, Julien Grall wrote:

On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:

On 15.11.23 14:33, Julien Grall wrote:

Thanks for adding support for virtio-pci in Xen. I have some questions.

On 15/11/2023 11:26, Sergiy Kibrik wrote:

From: Oleksandr Tyshchenko 

In order to enable more use-cases such as having multiple
device-models (Qemu) running in different backend domains which provide
virtio-pci devices for the same guest, we allocate and expose one
PCI host bridge for every virtio backend domain for that guest.


OOI, why do you need to expose one PCI host bridge for every stubdomain?

In fact looking at the next patch, it seems you are handling some of the
hostbridge request in Xen. This is adds a bit more confusion.

I was expecting the virtual PCI device would be in the vPCI and each
Device emulator would advertise which BDF they are covering.



This patch series only covers use-cases where the device emulator
handles the *entire* PCI Host bridge and PCI (virtio-pci) devices behind
it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI
pass-through resources, handling, accounting, nothing.


I understood you want to one Device Emulator to handle the entire PCI
host bridge. But...

  From the

hypervisor we only need a help to intercept the config space accesses
happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ...
GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and
forward them to the linked device emulator (if any), that's all.


... I really don't see why you need to add code in Xen to trap the
region. If QEMU is dealing with the hostbridge, then it should be able
to register the MMIO region and then do the translation.



Hmm, sounds surprising I would say. Are you saying that unmodified Qemu
will work if we drop #5?


I don't know if an unmodified QEMU will work. My point is I don't view 
the patch in Xen necessary. You should be able to tell QEMU "here is the 
ECAM region, please emulate an hostbridge". QEMU will then register the 
region to Xen and all the accesses will be forwarded.


In the future we may need a patch similar to #5 if we want to have 
multiple DM using the same hostbridge. But this is a different 
discussion and the patch would need some rework.


The ioreq.c code was always meant to be generic and is always for every 
emulated MMIO. So you want to limit any change in it. Checking the MMIO 
region belongs to the hostbridge and doing the translation is IMHO not a 
good idea to do in ioreq.c. Instead you want to do the conversion from 
MMIO to (sbdf, offset) in virtio_pci_mmio{read, write}(). So the job of 
ioreq.c is to simply find the correct Device Model and forward it.


I also don't see why the feature is gated by has_vcpi(). They are two 
distinct features (at least in your current model).


Cheers,

--
Julien Grall

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Oleksandr Tyshchenko]

On 15.11.23 20:33, Julien Grall wrote:
> Hi Oleksandr,

Hello Julien


> 
> On 15/11/2023 18:14, Oleksandr Tyshchenko wrote:
>> On 15.11.23 19:31, Julien Grall wrote:
>>> On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:
 On 15.11.23 14:33, Julien Grall wrote:
> Thanks for adding support for virtio-pci in Xen. I have some 
> questions.
>
> On 15/11/2023 11:26, Sergiy Kibrik wrote:
>> From: Oleksandr Tyshchenko 
>>
>> In order to enable more use-cases such as having multiple
>> device-models (Qemu) running in different backend domains which 
>> provide
>> virtio-pci devices for the same guest, we allocate and expose one
>> PCI host bridge for every virtio backend domain for that guest.
>
> OOI, why do you need to expose one PCI host bridge for every 
> stubdomain?
>
> In fact looking at the next patch, it seems you are handling some 
> of the
> hostbridge request in Xen. This is adds a bit more confusion.
>
> I was expecting the virtual PCI device would be in the vPCI and each
> Device emulator would advertise which BDF they are covering.


 This patch series only covers use-cases where the device emulator
 handles the *entire* PCI Host bridge and PCI (virtio-pci) devices 
 behind
 it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI
 pass-through resources, handling, accounting, nothing.
>>>
>>> I understood you want to one Device Emulator to handle the entire PCI
>>> host bridge. But...
>>>
>>>   From the
 hypervisor we only need a help to intercept the config space accesses
 happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ...
 GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and
 forward them to the linked device emulator (if any), that's all.
>>>
>>> ... I really don't see why you need to add code in Xen to trap the
>>> region. If QEMU is dealing with the hostbridge, then it should be able
>>> to register the MMIO region and then do the translation.
>>
>>
>> Hmm, sounds surprising I would say. Are you saying that unmodified Qemu
>> will work if we drop #5?
> 
> I don't know if an unmodified QEMU will work. My point is I don't view 
> the patch in Xen necessary. You should be able to tell QEMU "here is the 
> ECAM region, please emulate an hostbridge". QEMU will then register the 
> region to Xen and all the accesses will be forwarded. >
> In the future we may need a patch similar to #5 if we want to have 
> multiple DM using the same hostbridge. But this is a different 
> discussion and the patch would need some rework.


ok

> 
> The ioreq.c code was always meant to be generic and is always for every 
> emulated MMIO. So you want to limit any change in it. Checking the MMIO 
> region belongs to the hostbridge and doing the translation is IMHO not a 
> good idea to do in ioreq.c. Instead you want to do the conversion from 
> MMIO to (sbdf, offset) in virtio_pci_mmio{read, write}(). So the job of 
> ioreq.c is to simply find the correct Device Model and forward it.



Are you about virtio_pci_ioreq_server_get_addr() called from 
arch_ioreq_server_get_type_addr()? If so and if I am not mistaken the 
x86 also check what PCI device is targeted there.

But, I am not against the suggestion, I agree with it.


> 
> I also don't see why the feature is gated by has_vcpi(). They are two 
> distinct features (at least in your current model).

yes, you are correct. In #5 virtio-pci mmio handlers are still 
registered in domain_vpci_init() (which is gated by has_vcpi()), etc


> 
> Cheers,
> 

Re: [PATCH] arm/mm: add option to prefer IOMMU ops for DMA on Xen

[Mario Marietto]

---> So I plan to do some tests and see what DMA ops the other devices use
if swiotlb-xen is disabled and also what DMA ops the other devices use when
Linux runs on the Chromebook on bare metal without Xen. If these tests show
the problem can be fixed by disabling swiotlb-xen with a Kconfig  or
command line option, I will propose v2 to implement that as a solution.

and this could bring you to the next level of our project. Try to install
xen on different devices. At least it is my next project. I've already
bought two arm64 phones where xen can be installed because there is a hack
to overcome the bootloader / hypervisor protection mechanism. For sure I
hope that you also want to buy them to work on this together. And don't
worry about how much money they will cost you. I've bought them used and
refurbished. Or you could buy only one,that I suggest could be the SM-A600G
(Samsung Galaxy A6) with Exynos7870. Please start looking for it at a good
price.

On Wed, Nov 15, 2023 at 6:57 PM Chuck Zmudzinski 
wrote:

> On 11/14/2023 5:20 PM, Stefano Stabellini wrote:
> > On Tue, 14 Nov 2023, Robin Murphy wrote:
> >> On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
> >> > Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
> >> > attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
> >> > (and probably on other devices that use the Exynos mixer):
> >> >
> >> > [drm] Exynos DRM: using 1440.fimd device for DMA mapping
> operations
> >> > exynos-drm exynos-drm: bound 1440.fimd (ops 0xc0d96354)
> >> > exynos-mixer 1445.mixer: [drm:exynos_drm_register_dma] *ERROR*
> Device
> >> >   1445.mixer lacks support for IOMMU
> >> > exynos-drm exynos-drm: failed to bind 1445.mixer (ops
> 0xc0d97554): -22
> >> > exynos-drm exynos-drm: adev bind failed: -22
> >> > exynos-dp: probe of 145b.dp-controller failed with error -22
> >> >
> >> > Linux normally uses xen_swiotlb_dma_ops for DMA for all devices when
> >> > xen_swiotlb is detected even when Xen exposes an IOMMU to Linux.
> Enabling
> >> > the new config option allows devices such as the Exynos mixer to use
> the
> >> > IOMMU instead of xen_swiotlb_dma_ops for DMA and this fixes the error.
> >> >
> >> > The new config option is not set by default because it is likely some
> >> > devices that use IOMMU for DMA on Xen will cause DMA errors and memory
> >> > corruption when Xen PV block and network drivers are in use on the
> system.
> >> >
> >> > Link:
> >> >
> https://lore.kernel.org/xen-devel/acfab1c5-eed1-4930-8c70-8681e256c...@netscape.net/
> >> >
> >> > Signed-off-by: Chuck Zmudzinski 
> >> > ---
> >> > The reported error with the Exynos mixer is not fixed by default by
> adding
> >> > a second patch to select the new option in the Kconfig definition for
> the
> >> > Exynos mixer if EXYNOS_IOMMU and SWIOTLB_XEN are enabled because it is
> >> > not certain setting the config option is suitable for all cases. So
> it is
> >> > necessary to explicitly select the new config option during the config
> >> > stage of the Linux kernel build to fix the reported error or similar
> >> > errors that have the same cause of lack of support for IOMMU on Xen.
> This
> >> > is necessary to avoid any regressions that might be caused by
> enabling the
> >> > new option by default for the Exynos mixer.
> >> >   arch/arm/mm/dma-mapping.c |  6 ++
> >> >   drivers/xen/Kconfig   | 16 
> >> >   2 files changed, 22 insertions(+)
> >> >
> >> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> >> > index 5409225b4abc..ca04fdf01be3 100644
> >> > --- a/arch/arm/mm/dma-mapping.c
> >> > +++ b/arch/arm/mm/dma-mapping.c
> >> > @@ -1779,6 +1779,12 @@ void arch_setup_dma_ops(struct device *dev, u64
> >> > dma_base, u64 size,
> >> >if (iommu)
> >> >arm_setup_iommu_dma_ops(dev, dma_base, size, iommu,
> coherent);
> >> >   +#ifdef CONFIG_ARM_DMA_USE_IOMMU_XEN
> >>
> >> FWIW I don't think this really needs a config option - if Xen *has*
> made an
> >> IOMMU available, then there isn't really much reason not to use it, and
> if for
> >> some reason someone really didn't want to then they could simply
> disable the
> >> IOMMU driver anyway.
> >
> > The fact that the Exynos IOMMU is exposed to Linux is a mistake. Xen
> > doesn't recognize the Exynos IOMMU (it is not one of the IOMMUs Xen has
> > a driver for) so it assigns the IOMMU to Dom0. It doesn't happen on
> > purpose, it happens by accident. Certain things are going to break,
> > specifically I am fairly certain PV drivers are going to break.
> >
> > If Xen recognized the Exynos IOMMU as an IOMMU it would probably hide it
> > from Dom0. (Today Xen doesn't have a list of IOMMUs Xen recognizes but
> > doesn't have a driver for.)
> >
> > I think it is OK for Chuck and others to play around with this
> > configuration but I wouldn't add a new kconfig option to Linux to
> > support it.
> >
> > If we do want a kconfig option

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Julien Grall]

Hi Oleksandr,

On 15/11/2023 19:38, Oleksandr Tyshchenko wrote:

The ioreq.c code was always meant to be generic and is always for every
emulated MMIO. So you want to limit any change in it. Checking the MMIO
region belongs to the hostbridge and doing the translation is IMHO not a
good idea to do in ioreq.c. Instead you want to do the conversion from
MMIO to (sbdf, offset) in virtio_pci_mmio{read, write}(). So the job of
ioreq.c is to simply find the correct Device Model and forward it.




Are you about virtio_pci_ioreq_server_get_addr() called from
arch_ioreq_server_get_type_addr()? If so and if I am not mistaken the
x86 also check what PCI device is targeted there.

Well yes. We can do better to avoid extra complexity for each MMIO.

Note that the x86 version is somewhat more light-weight.

Cheers,

--
Julien Grall

[xen-4.17-testing test] 183760: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183753
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 183753
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183753
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183753
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183753
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183753
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183753
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183753
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183753
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183753
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183753
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183753
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-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-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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-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-armhf-armhf-libvirt-raw 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-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 xen  28f44b603fd86c233726bdc2a11b6325f102471a
baseline version:
 xen  0527bab0901b800e3f1be2e7836c5346b6e08809

Last test of basis   183753  2023-11-14 13:07:02 Z1 days
Testing same since   183760  2023-11-15 04:51:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm   

Re: [PATCH 3/3] hw/xen: clean up xen_block_find_free_vdev() to avoid Coverity false positive

[Paul Durrant]

On 15/11/2023 12:24, David Woodhouse wrote:

From: David Woodhouse 

Coverity couldn't see that nr_existing was always going to be zero when
qemu_xen_xs_directory() returned NULL in the ENOENT case (CID 1523906).

Perhaps more to the point, neither could Peter at first glance. Improve
the code to hopefully make it clearer to Coverity and human reviewers
alike.

Signed-off-by: David Woodhouse 
---
  hw/block/xen-block.c | 24 +---
  1 file changed, 21 insertions(+), 3 deletions(-)



Reviewed-by: Paul Durrant 

Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Stefano Stabellini]

+ Stewart, Vikram

On Wed, 15 Nov 2023, Oleksandr Tyshchenko wrote:
> On 15.11.23 14:33, Julien Grall wrote:
> > Thanks for adding support for virtio-pci in Xen. I have some questions.
> > 
> > On 15/11/2023 11:26, Sergiy Kibrik wrote:
> >> From: Oleksandr Tyshchenko 
> >>
> >> In order to enable more use-cases such as having multiple
> >> device-models (Qemu) running in different backend domains which provide
> >> virtio-pci devices for the same guest, we allocate and expose one
> >> PCI host bridge for every virtio backend domain for that guest.
> > 
> > OOI, why do you need to expose one PCI host bridge for every stubdomain?
> > 
> > In fact looking at the next patch, it seems you are handling some of the 
> > hostbridge request in Xen. This is adds a bit more confusion.
> > 
> > I was expecting the virtual PCI device would be in the vPCI and each 
> > Device emulator would advertise which BDF they are covering.
> 
> 
> This patch series only covers use-cases where the device emulator 
> handles the *entire* PCI Host bridge and PCI (virtio-pci) devices behind 
> it (i.e. Qemu). Also this patch series doesn't touch vPCI/PCI 
> pass-through resources, handling, accounting, nothing. From the 
> hypervisor we only need a help to intercept the config space accesses 
> happen in a range [GUEST_VIRTIO_PCI_ECAM_BASE ... 
> GUEST_VIRTIO_PCI_ECAM_BASE + GUEST_VIRTIO_PCI_TOTAL_ECAM_SIZE] and 
> forward them to the linked device emulator (if any), that's all.
> 
> It is not possible (with current series) to run device emulators what
> emulate only separate PCI (virtio-pci) devices. For it to be possible, I 
> think, much more changes are required than current patch series does. 
> There at least should be special PCI Host bridge emulation in Xen (or 
> reuse vPCI) for the integration. Also Xen should be in charge of forming 
> resulting PCI interrupt based on each PCI device level signaling (if we 
> use legacy interrupts), some kind of x86's XEN_DMOP_set_pci_intx_level, 
> etc. Please note, I am not saying this is not possible in general, 
> likely it is possible, but initial patch series doesn't cover these 
> use-cases)
>
> We expose one PCI host bridge per virtio backend domain. This is a 
> separate PCI host bridge to combine all virtio-pci devices running in 
> the same backend domain (in the same device emulator currently).
> The examples:
> - if only one domain runs Qemu which servers virtio-blk, virtio-net, 
> virtio-console devices for DomU - only single PCI Host bridge will be 
> exposed for DomU
> - if we add another domain to run Qemu to serve additionally virtio-gpu, 
> virtio-input and virtio-snd for the *same* DomU - we expose second PCI 
> Host bridge for DomU
> 
> I am afraid, we cannot end up exposing only single PCI Host bridge with 
> current model (if we use device emulators running in different domains 
> that handles the *entire* PCI Host bridges), this won't work.
 

We were discussing the topic of vPCI and Virtio PCI just this morning
with Stewart and Vikram. We also intend to make them work well together
in the next couple of months (great timing!!)

However, our thinking is to go with the other approach Julien
suggested: a single PCI Root Complex emulated in Xen by vPCI. QEMU would
register individual PCI devices against it.

Vikram, Stewart, please comment. Our understanding is that it should be
possible to make QEMU virtio-pci work with vPCI with relatively minor
efforts and AMD volunteers to do the work in the next couple of months
on the vPCI side.


Although it should be possible to make both approaches work at the same
time, given that it would seem that EPAM and AMD have very similar
requirements, I suggest we work together and collaborate on a single
approach going forward that works best for everyone.


Let me start by saying that if we can get away with it, I think that a
single PCI Root Complex in Xen would be best because it requires less
complexity. Why emulate 2/3 PCI Root Complexes if we can emulate only
one?

Stewart, you are deep into vPCI, what's your thinking?

Re: [RFC PATCH 5/6] xen/arm: Intercept vPCI config accesses and forward them to emulator

[Stefano Stabellini]

On Wed, 15 Nov 2023, Julien Grall wrote:
> Hi,
> 
> On 15/11/2023 11:26, Sergiy Kibrik wrote:
> > From: Oleksandr Tyshchenko 
> > 
> > This is needed for supporting virtio-pci.
> > 
> > In case when the PCI Host bridge is emulated outside of Xen
> > (IOREQ server), we need some mechanism to intercept config space
> > accesses on Xen on Arm, and forward them to the emulator
> > (for example, virtio backend) via IOREQ request.
> > 
> > Unlike x86, on Arm these accesses are MMIO, there is no CFC/CF8 method
> > to detect which PCI device is targeted.
> > 
> > In order to not mix PCI passthrough with virtio-pci features we add
> > one more region to cover the total configuration space for all possible
> > host bridges which can serve virtio-pci devices for that guest.
> > We expose one PCI host bridge per virtio backend domain.
> I am a little confused. If you expose one PCI host bridge per virtio backend,
> then why can't the backend simply register the MMIO region and do the
> translation itself when it receives the read/write?
> 
> To me, it only makes sense for Xen to emulate the host bridge access if you
> plan to have one host bridge shared between multiple IOREQ domains or mix with
> PCI pasthrough.

+1

This is exactly what Stewart, Vikram and I were thinking


> From my perspective, I don't expect we would have that many virtio PCI
> devices. So imposing a host bridge per device emulator will mean extra
> resource in the guest as well (they need to keep track of all the hostbridge).

+1


> So in the longer run, I think we want to allow mixing PCI passthrough and
> virtio-PCI (or really any emulated PCI because nothing here is virtio
> specific).

+1


> For now, your approach would be OK to enable virtio PCI on Xen. But I don't
> think there are any changes necessary in Xen other than reserving some MMIO
> regions/IRQ.

I don't mean to slow down EPAM, but I think we can jump in and do the
necessary changes to vPCI for everyone's benefits and with a timeframe
that works for AMD, EPAM and the Xen community.

Re: Values generated by the ViryaOS uboot-script-gen do not work correctly on the Chromebook Snow

[Stefano Stabellini]

On Wed, 15 Nov 2023, Chuck Zmudzinski wrote:
> On 11/14/2023 6:43 PM, Mario Marietto wrote:
> > I hope that the informations below are correct :
> 
> I don't know that they are correct. I have not spent the necessary time to
> determine what the correct values for MEMORY_START and MEMORY_END are for
> the Chromebook we are using. I just presumed, probably incorrectly, that
> the entire 2 GB memory is safe, but obviously that is not the case with
> this Chromebook. Most likely, it requires a good understanding of the
> particular way booting is done on a Chromebook, which seems to be different
> from other devices.
> 
> I plan to eventually look into finding values for MEMORY_START and MEMORY_END
> sothe uboot-script-gen script computes usable values for loading Xen and dom0
> on this Chromebook in the script, but I might not get to that task 
> immediately.
> I plan to look at it within the next week or so.

A couple of suggestions. I noticed that the addresses you chose have a
higher alignment compared to the one chosen by Imagebuilder.
Imagebuilder uses 2MB:

offset=$((2*1024*1024))

I would think that a 2MB alignment should be sufficient, but you can
increase the alignment chosen by Imagebuilder simply by changing
"offset" at the top of uboot-script-gen. You seem to be used a 240MB
offset:

offset=$((240*1024*1024))

The other suggestion is about MEMORY_START and MEMORY_END. Looking at
the addresses you picked by hand, the following you should give you very
similar results:

MEMORY_START=0x3300
MEMORY_END=0x8000


> > - the imagebuilder config file :
> > 
> > MEMORY_START="0x0"
> > MEMORY_END="0x8000"
> > LOAD_CMD="ext2load mmc 1:3"
> > BOOT_CMD="bootm"
> > DEVICE_TREE="exynos5250-snow.dtb"
> > XEN="xen-4.17-armhf"
> > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M dom0_max_vcpus=2 
> > bootscrub=0 vwfi=native sched=null"
> > DOM0_KERNEL="zImage-6.6.0-xen-iommu-dma-on-xen"
> > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen root=/dev/mmcblk1p4 rw 
> > rootwait clk_ignore_unused"
> > UBOOT_SOURCE="xen.source"
> > UBOOT_SCRIPT="xen.scr"
> > 
> > xen.source : (that does not work)
> > 
> > mmc dev 1
> > ext2load mmc 1:3 0xE0 zImage-6.6.0-xen-iommu-dma-on-xen
> > ext2load mmc 1:3 0x180 xen-4.17-armhf.ub
> > ext2load mmc 1:3 0x1A0 exynos5250-snow.dtb
> > fdt addr 0x1A0
> > fdt resize 1024
> > fdt set /chosen \#address-cells <0x2>
> > fdt set /chosen \#size-cells <0x2>
> > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 
> > dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> > fdt mknod /chosen dom0
> > fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module" 
> > "multiboot,module"
> > fdt set /chosen/dom0 reg <0x0 0xE0 0x0 0x87C200 >
> > fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen 
> > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
> > setenv fdt_high 0x
> > bootm 0x180 - 0x1A0
> > 
> > xen.source : (created by chuck and that works)
> > 
> > mmc dev 1
> > ext2load mmc 1:3 0x4200 zImage-6.6.0-xen-iommu-dma-on-xen
> > ext2load mmc 1:3 0x5100 xen-4.17-armhf-armmp-0x51004000.ub
> > ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb
> > fdt addr 0x5ffec000
> > fdt resize 1024
> > fdt set /chosen \#address-cells <0x2>
> > fdt set /chosen \#size-cells <0x2>
> > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 
> > dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> > fdt mknod /chosen dom0
> > fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module" 
> > "multiboot,module"
> > fdt set /chosen/dom0 reg <0x0 0x4200 0x0 0x87C200 >
> > fdt set /chosen xen,dom0-bootargs "console=tty1 root=/dev/mmcblk1p4 rw 
> > rootwait clk_ignore_unused --no-log"
> > bootm 0x5100 - 0x5ffec000
> > 
> > all the values that you see in this conf. files have been calculated by 
> > chuck by hand,because the values generated by the imagebuilder are wrong. 
> > The only value that's well calculated by the imagebuilder is 0x87C200
> > 
> > - the size of all the binaries specified in the imagebuilder config file :
> > 
> > exynos5250-snow.dtb = 46.6 KiB (47,769 byte)
> > zImage-6.6.0-xen-iommu-dma-on-xen = 8.5 MiB (8,897,024 byte)
> > 
> > 
> > 
> > On Wed, Nov 15, 2023 at 12:17 AM Stefano Stabellini  > > wrote:
> > 
> > Hi Mario,
> > 
> > I think we misunderstood each other :-)
> > 
> > MEMORY_START-MEMORY_END is not supposed to be computed: it is supposed
> > to come from the memory node in device tree tree (/memory) of the
> > platform. The idea is that you should not have to do any computations,
> > but only reuse the same address range specified there.
> > 
> > Similarly in regards to "please post the size of all the binaries",
> > this is just for debugging, so that I can see if there are any bugs with
> > uboot-script-gen. I cannot debug the script unless I

Re: [PATCH v2] misra: add R21.1 R21.2

[Stefano Stabellini]

On Wed, 15 Nov 2023, Jan Beulich wrote:
> On 14.11.2023 23:59, Stefano Stabellini wrote:
> > Add 21.1 and 21.2, with a longer comment to explain how strategy with
> > leading underscores and why we think we are safe today.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Acked-by: Jan Beulich 
> with one nit:
> 
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -519,6 +519,28 @@ maintainers if you want to suggest a change.
> > they are related
> >   -
> >  
> > +   * - `Rule 21.1 
> > `_
> > + - Required
> > + - #define and #undef shall not be used on a reserved identifier or
> > +   reserved macro name
> > + - Identifiers starting with an underscore followed by another 
> > underscore
> > +   or an upper-case letter are reserved. Today Xen uses many, such as
> > +   header guards and bitwise manipulation functions. Upon analysis it 
> > turns
> > +   out Xen identifiers do not clash with the identifiers used by modern
> > +   GCC, but that is not a guarantee that there won't be a naming clash 
> > in
> > +   the future or with another compiler.  For these reasons we 
> > discourage
> > +   the introduction of new reserved identifiers in Xen, and we see it 
> > as
> > +   positive the reduction of reserved identifiers. At the same time,
> > +   certain identifiers starting with an underscore are also commonly 
> > used
> > +   in Linux (e.g. __set_bit) and we don't think it would be an 
> > improvement
> > +   to rename them.
> 
> I think this last sentence would also better say "two underscores".

Done on commit

Re: Values generated by the ViryaOS uboot-script-gen do not work correctly on the Chromebook Snow

[Mario Marietto]

It didn't work. This is the scr file generated.

ext2load mmc 1:3 0x5100 zImage-6.6.0-xen-iommu-dma-on-xen
ext2load mmc 1:3 0x6000 xen-4.17-armhf.ub
ext2load mmc 1:3 0x6100 exynos5250-snow.dtb
fdt addr 0x6100
fdt resize 1024
fdt set /chosen \#address-cells <0x2>
fdt set /chosen \#size-cells <0x2>
fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0
dom0_mem=768 dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
fdt mknod /chosen dom0
fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module"
"multiboot,module"
fdt set /chosen/dom0 reg <0x0 0x5100 0x0 0x87C200 >
fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen
root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
setenv fdt_high 0x
bootm 0x6000 - 0x6100

So,I ran :

bash /boot/./uboot-script-gen -c /boot/xen-config -d .

it says :

Image Name:
Created:  Wed Nov 15 23:55:40 2023
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:884744 Bytes = 864.01 KiB = 0.84 MiB
Load Address: 6000
Entry Point:  6000
Generated uboot script xen-stef.scr, to be loaded at address 0x4200:
ext2load mmc 1:3 0x4200 xen-stef.scr; source 0x4200

ok,I've booted xen with the suggested address :

ext2load mmc 1:3 0x4200 xen-stef.scr; source 0x4200

but it rebooted to the verification screen.

NB : I have applied both your suggestions (offset + your new start and end
memory address. Maybe they auto exclude each other ?)

On Thu, Nov 16, 2023 at 12:49 AM Stefano Stabellini 
wrote:

> On Wed, 15 Nov 2023, Chuck Zmudzinski wrote:
> > On 11/14/2023 6:43 PM, Mario Marietto wrote:
> > > I hope that the informations below are correct :
> >
> > I don't know that they are correct. I have not spent the necessary time
> to
> > determine what the correct values for MEMORY_START and MEMORY_END are for
> > the Chromebook we are using. I just presumed, probably incorrectly, that
> > the entire 2 GB memory is safe, but obviously that is not the case with
> > this Chromebook. Most likely, it requires a good understanding of the
> > particular way booting is done on a Chromebook, which seems to be
> different
> > from other devices.
> >
> > I plan to eventually look into finding values for MEMORY_START and
> MEMORY_END
> > sothe uboot-script-gen script computes usable values for loading Xen and
> dom0
> > on this Chromebook in the script, but I might not get to that task
> immediately.
> > I plan to look at it within the next week or so.
>
> A couple of suggestions. I noticed that the addresses you chose have a
> higher alignment compared to the one chosen by Imagebuilder.
> Imagebuilder uses 2MB:
>
> offset=$((2*1024*1024))
>
> I would think that a 2MB alignment should be sufficient, but you can
> increase the alignment chosen by Imagebuilder simply by changing
> "offset" at the top of uboot-script-gen. You seem to be used a 240MB
> offset:
>
> offset=$((240*1024*1024))
>
> The other suggestion is about MEMORY_START and MEMORY_END. Looking at
> the addresses you picked by hand, the following you should give you very
> similar results:
>
> MEMORY_START=0x3300
> MEMORY_END=0x8000
>
>
> > > - the imagebuilder config file :
> > >
> > > MEMORY_START="0x0"
> > > MEMORY_END="0x8000"
> > > LOAD_CMD="ext2load mmc 1:3"
> > > BOOT_CMD="bootm"
> > > DEVICE_TREE="exynos5250-snow.dtb"
> > > XEN="xen-4.17-armhf"
> > > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M dom0_max_vcpus=2
> bootscrub=0 vwfi=native sched=null"
> > > DOM0_KERNEL="zImage-6.6.0-xen-iommu-dma-on-xen"
> > > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen root=/dev/mmcblk1p4
> rw rootwait clk_ignore_unused"
> > > UBOOT_SOURCE="xen.source"
> > > UBOOT_SCRIPT="xen.scr"
> > >
> > > xen.source : (that does not work)
> > >
> > > mmc dev 1
> > > ext2load mmc 1:3 0xE0 zImage-6.6.0-xen-iommu-dma-on-xen
> > > ext2load mmc 1:3 0x180 xen-4.17-armhf.ub
> > > ext2load mmc 1:3 0x1A0 exynos5250-snow.dtb
> > > fdt addr 0x1A0
> > > fdt resize 1024
> > > fdt set /chosen \#address-cells <0x2>
> > > fdt set /chosen \#size-cells <0x2>
> > > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0
> dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> > > fdt mknod /chosen dom0
> > > fdt set /chosen/dom0 compatible  "xen,linux-zimage"
> "xen,multiboot-module" "multiboot,module"
> > > fdt set /chosen/dom0 reg <0x0 0xE0 0x0 0x87C200 >
> > > fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen
> earlyprintk=xen root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
> > > setenv fdt_high 0x
> > > bootm 0x180 - 0x1A0
> > >
> > > xen.source : (created by chuck and that works)
> > >
> > > mmc dev 1
> > > ext2load mmc 1:3 0x4200 zImage-6.6.0-xen-iommu-dma-on-xen
> > > ext2load mmc 1:3 0x5100 xen-4.17-armhf-armmp-0x51004000.ub
> > > ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb
> > > fdt addr 0x5ffec000
> > > fdt resize 1024
> > > fdt s

Re: [RFC 1/4] x86/ioemul: address MISRA C:2012 Rule 9.3

[Stefano Stabellini]

On Mon, 13 Nov 2023, Jan Beulich wrote:
> On 11.11.2023 02:23, Stefano Stabellini wrote:
> > On Mon, 6 Nov 2023, Nicola Vetrini wrote:
> > There's also this functionally equivalent alternative, with or without
> > the zeros, which
> > doesn't incur in the risk of mistakenly attempting to initialize the
> > same element twice,
> > while also giving an explicit cue to the reader that all elements are
> > truly zero-initialized.
> >
> >   .matches = {
> >   DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
> >   DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL5"),
> > +{0}, {0}
> >   },
> 
>  Adding a dependency on the array actually having 4 elements (while iirc
>  we have seen already that we could in principle go down to 3). A change
>  of this number would then require touching all these sites, which is
>  what we'd like to avoid.
> >>>
> >>> How often the array needs to change though? Looking at the git history
> >>> it doesn't seem the number of elements ever changed. So I think it is a
> >>> good tradeoff, and I would go with this type of fix (maybe also at the
> >>> other locations mechanically too although I haven't looked at them in
> >>> details).
> >>
> >> Hi, any updates on this? Considering the opinions expressed above, what 
> >> would
> >> be the path preferred by the community?
> > 
> > Hi Jan, to bring this discussion to a conclusion, I think we have these
> > options:
> > 
> > 1) fix these violations by adding {}, {}
> > 2) fix these violations by adding [0]=xxx,[1]=xxx
> > 3) deviate these violations by adding /* SAF-safe-xxx */
> > 4) remove the MISRA rule 9.3 from docs/misra/rules.rst
> > 
> > Let's make a decision. My preference is 1) as we only have ~50
> > violations.
> 
> Of these, to be honest, my preference would be 4. Just that that's
> undesirable for other reasons. But have we thought of alternatives, say
> a variadic macro that would supply the "missing" initializers? Imo such
> decisions shouldn't be rushed; there are enough other issues to take
> care of in the meantime. A sound solution is, I think, generally
> preferable to a quick one. (Whether my new suggestion is "sound" I of
> course can't tell, until it was tried out and the overall result /
> effects can be inspected.)

I don't like the idea of the variadic macro as we should attempt to make
things more obviously correct, rather than more obscure.

Thinking out of the box, what if we added a single {} E.g.:

.ident = "HP ProLiant DL3xx",
.matches = {
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL3"),
{}
},

It would accomplish the goal of highlighting that there are more members
of the array that gets initialized to zero. At the same time it wouldn't
require the introductino of [0] and [1] that as we have seen are error
prone and it wouldn't depend on the exact number of elements like adding
one {} per missing initialization. To be clear, I am suggesting adding a
single {} only.

Nicola, what do you think? Would it be OK for MISRA / ECLAIR?

Re: Values generated by the ViryaOS uboot-script-gen do not work correctly on the Chromebook Snow

[Stefano Stabellini]

I miscalculated MEMORY_START. If you try with:

offset=$((240*1024*1024)) # this change in scripts/uboot-script-gen
MEMORY_START="0x2400"
MEMORY_END="0x8000"

then it should use:
tftpb 0x4200 Linux
tftpb 0x5000 Xen
tftpb 0x6000 DTB

which is very similar to what Chuck used. It might work.

However, I noticed now that Chuck's last addess is lower than
0x6000. I wonder if that is the issue? If we cannot exceed
0x6000, then maybe I would try with:

offset=$((120*1024*1024)) # this change in scripts/uboot-script-gen
MEMORY_START="0x3300"
MEMORY_END="0x8000"



On Thu, 16 Nov 2023, Mario Marietto wrote:
> It didn't work. This is the scr file generated.
> 
> ext2load mmc 1:3 0x5100 zImage-6.6.0-xen-iommu-dma-on-xen
> ext2load mmc 1:3 0x6000 xen-4.17-armhf.ub
> ext2load mmc 1:3 0x6100 exynos5250-snow.dtb
> fdt addr 0x6100
> fdt resize 1024
> fdt set /chosen \#address-cells <0x2>
> fdt set /chosen \#size-cells <0x2>
> fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 dom0_mem=768 
> dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
> fdt mknod /chosen dom0
> fdt set /chosen/dom0 compatible  "xen,linux-zimage" "xen,multiboot-module" 
> "multiboot,module"
> fdt set /chosen/dom0 reg <0x0 0x5100 0x0 0x87C200 >
> fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen 
> root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
> setenv fdt_high 0x
> bootm 0x6000 - 0x6100
> 
> So,I ran :
> 
> bash /boot/./uboot-script-gen -c /boot/xen-config -d .
> 
> it says :
> 
> Image Name:    
> Created:  Wed Nov 15 23:55:40 2023
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:    884744 Bytes = 864.01 KiB = 0.84 MiB
> Load Address: 6000
> Entry Point:  6000
> Generated uboot script xen-stef.scr, to be loaded at address 0x4200:
> ext2load mmc 1:3 0x4200 xen-stef.scr; source 0x4200
> 
> ok,I've booted xen with the suggested address :
> 
> ext2load mmc 1:3 0x4200 xen-stef.scr; source 0x4200
> 
> but it rebooted to the verification screen.
> 
> NB : I have applied both your suggestions (offset + your new start and end 
> memory address. Maybe they auto exclude each other ?)
> 
> On Thu, Nov 16, 2023 at 12:49 AM Stefano Stabellini  
> wrote:
>   On Wed, 15 Nov 2023, Chuck Zmudzinski wrote:
>   > On 11/14/2023 6:43 PM, Mario Marietto wrote:
>   > > I hope that the informations below are correct :
>   >
>   > I don't know that they are correct. I have not spent the necessary 
> time to
>   > determine what the correct values for MEMORY_START and MEMORY_END are 
> for
>   > the Chromebook we are using. I just presumed, probably incorrectly, 
> that
>   > the entire 2 GB memory is safe, but obviously that is not the case 
> with
>   > this Chromebook. Most likely, it requires a good understanding of the
>   > particular way booting is done on a Chromebook, which seems to be 
> different
>   > from other devices.
>   >
>   > I plan to eventually look into finding values for MEMORY_START and 
> MEMORY_END
>   > sothe uboot-script-gen script computes usable values for loading Xen 
> and dom0
>   > on this Chromebook in the script, but I might not get to that task 
> immediately.
>   > I plan to look at it within the next week or so.
> 
>   A couple of suggestions. I noticed that the addresses you chose have a
>   higher alignment compared to the one chosen by Imagebuilder.
>   Imagebuilder uses 2MB:
> 
>   offset=$((2*1024*1024))
> 
>   I would think that a 2MB alignment should be sufficient, but you can
>   increase the alignment chosen by Imagebuilder simply by changing
>   "offset" at the top of uboot-script-gen. You seem to be used a 240MB
>   offset:
> 
>   offset=$((240*1024*1024))
> 
>   The other suggestion is about MEMORY_START and MEMORY_END. Looking at
>   the addresses you picked by hand, the following you should give you very
>   similar results:
> 
>   MEMORY_START=0x3300
>   MEMORY_END=0x8000
> 
> 
>   > > - the imagebuilder config file :
>   > >
>   > > MEMORY_START="0x0"
>   > > MEMORY_END="0x8000"
>   > > LOAD_CMD="ext2load mmc 1:3"
>   > > BOOT_CMD="bootm"
>   > > DEVICE_TREE="exynos5250-snow.dtb"
>   > > XEN="xen-4.17-armhf"
>   > > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M 
> dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null"
>   > > DOM0_KERNEL="zImage-6.6.0-xen-iommu-dma-on-xen"
>   > > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen 
> root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused"
>   > > UBOOT_SOURCE="xen.source"
>   > > UBOOT_SCRIPT="xen.scr"
>   > >
>   > > xen.source : (that does not work)
>   > >
>   > > mmc dev 1
>   > > ext2load mmc 1:3 0xE0 zImage-6.6.0-xen-iommu-dma-on-xen
>   > > ext2load mmc 1:3 0x180 xen-4.17-armhf.

xen | Successful pipeline for staging | fb62aa71

[GitLab]

Pipeline #1074149645 has passed!

Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )

Commit: fb62aa71 ( 
https://gitlab.com/xen-project/xen/-/commit/fb62aa714d72349722d63b32a5a6d20a677f39e0
 )
Commit Message: misra: add R21.1 R21.2

Add 21.1 and 21.2, with...
Commit Author: Stefano Stabellini ( https://gitlab.com/sstabellini )
Committed by: Stefano Stabellini



Pipeline #1074149645 ( 
https://gitlab.com/xen-project/xen/-/pipelines/1074149645 ) triggered by Ganis 
( https://gitlab.com/ganis )
successfully completed 129 jobs in 3 stages.

-- 
You're receiving this email because of your account on gitlab.com.

[xen-4.18-testing test] 183764: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop   fail blocked in 183754
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183754
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183754
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183754
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183754
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183754
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183754
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183754
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183754
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183754
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183754
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183754
 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-amd64-i386-xl-pvshim14 guest-start  fail   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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-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-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-libvirt-xsm 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-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 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-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-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-armhf-armhf-libvirt-raw 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  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 xen  1924da16239703edc7be6de0f5a549a30aa84b82
baseline version:
 xen  2185851bbf72123ea76c9ce26e0c3a4d1a0ab8b0

Last test of basis   183754  2023-11-14 13:07:20 Z1 days
Testing same since   183764  2023-11-15 12:36:55 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

jobs:
 build-amd64-xsm

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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

version targeted for testing:
 xen  fb62aa714d72349722d63b32a5a6d20a677f39e0
baseline version:
 xen  7ad0c774e474f6d95dfda868d876af507d399657

Last test of basis   183762  2023-11-15 11:03:53 Z0 days
Testing same since   183767  2023-11-16 01:03:51 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Stefano Stabellini 
  Stefano Stabellini 

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
   7ad0c774e4..fb62aa714d  fb62aa714d72349722d63b32a5a6d20a677f39e0 -> smoke

Re: [PATCH v2 07/15] xen/asm-generic: introduce stub header

[Jan Beulich]

On 15.11.2023 13:39, Oleksii wrote:
> On Wed, 2023-11-15 at 10:56 +0100, Jan Beulich wrote:
>> On 10.11.2023 17:30, Oleksii Kurochko wrote:
>>>  is common for Arm, PPC and RISC-V thereby it
>>> is moved to asm-generic.
>>
>> When you say "moved", ...
>>
>>> Signed-off-by: Oleksii Kurochko 
>>> ---
>>> Changes in V2:
>>>  - update the commit messages
>>> ---
>>>  xen/include/asm-generic/random.h | 20 
>>>  1 file changed, 20 insertions(+)
>>>  create mode 100644 xen/include/asm-generic/random.h
>>
>> ... you also want to actually move things.
> Sure, I'll delete Arm and PPC's random.h in the next patch series
> version.
> 
>>
>> Since the above comment matches ones on earlier patches, yet otoh in
>> your
>> submissions of two individual patches you mentioned you sent them
>> separately because this series wasn't fully reviewed yet, would you
>> mind
>> clarifying whether further going through this version of the series
>> is
>> actually going to be a good use of time?
> I think it still makes sense to review this series.
> 
> I probably have to stop sending patches from this series separately. I
> thought merging almost-ready patches would be a little faster if they
> moved outside the patch series.
> 
> If it is possible to merge approved patches separately without getting
> approved for the whole patch series,

We do this quite frequently, as long as it's clear that later patches
in a series (which are approved and hence can go in) don't depend on
earlier ones. Ones at the beginning of a series can go individually
anyway; the only time that I can think of right away where this would
not be desirable is if they introduced then-dead code.

Jan

> then what I did before doesn't
> make sense, and I am sorry for this inconvenience.
> 
> I can return the patches I sent separately to this patch series.
> 
> ~ Oleksii
> 

Re: [PATCH v2 13/15] xen/asm-generic: introduce stub header monitor.h

[Jan Beulich]

On 15.11.2023 13:54, Oleksii wrote:
> On Wed, 2023-11-15 at 11:00 +0100, Jan Beulich wrote:
>> On 10.11.2023 17:30, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/monitor.h
>>> @@ -0,0 +1,62 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * include/asm-GENERIC/monitor.h
>>> + *
>>> + * Arch-specific monitor_op domctl handler.
>>> + *
>>> + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
>>> + * Copyright (c) 2016, Bitdefender S.R.L.
>>> + *
>>> + */
>>> +
>>> +#ifndef __ASM_GENERIC_MONITOR_H__
>>> +#define __ASM_GENERIC_MONITOR_H__
>>> +
>>> +#include 
>>
>> What is this needed for? I expect ...
>>
>>> +struct xen_domctl_monitor_op;
>>> +
>>> +static inline
>>> +void arch_monitor_allow_userspace(struct domain *d, bool
>>> allow_userspace)
>>
>> ... struct domain, but since you never de-reference any such pointer,
>> forward-
>> declaring that (just like struct xen_domctl_monitor_op) would do
>> here. Which
>> would leave you with needing at most xen/types.h, but maybe as little
>> as
>> xen/stdbool.h and xen/stdint.h.
> Yes, the reason for " #include  " was ' struct domain '.
> Let's switch to forward-declaring.
> 
> Shouldn't it be included  too for inline?

I'm actually not sure why we (still?) override "inline" there. It's a
normal keyword in C99. IOW I don't think xen/compiler.h would be
needed here (just for that).

Jan

Re: [PATCH v2 14/15] xen/asm-generic: introduce stub header numa.h

[Jan Beulich]

On 15.11.2023 15:11, Oleksii wrote:
> On Wed, 2023-11-15 at 11:07 +0100, Jan Beulich wrote:
>> On 10.11.2023 17:30, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/numa.h
>>> @@ -0,0 +1,40 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef __ARCH_GENERIC_NUMA_H
>>> +#define __ARCH_GENERIC_NUMA_H
>>> +
>>> +#include 
>>> +#include 
>>
>> I'm afraid I can't spot what you need these for here. You clearly
>> need
>> xen/stdint.h, and you need xen/mm-frame.h for mfn_t. Yes, max_page is
>> declared in xen/mm.h, but its questionable whether the header needs
>> including here for that reason, as all uses are in macros. (We aren't
>> anywhere near consistent in this regard). Plus you don't also include
>> xen/cpumask.h to pull in cpu_online_map (which another macro
>> references).
> I agree with almost you wrote but should  be included
> then? It looks like it is the same situation as with max_page and
> .

Well, yes and no: Indeed the minimal requirement is to be consistent
(either include both or include neither). Personally I'd prefer if
headers would be included only if they are needed to successfully
compiler the header on its own. That limits needless dependencies on
the (otherwise) included headers. But I can easily see that others
might take the other sensible perspective.

>>> +typedef uint8_t nodeid_t;
>>> +
>>> +#ifndef CONFIG_NUMA
>>
>> Isn't it an error to include this header when NUMA=y?
> It's still need to define arch_want_default_dmazone() macros which is
> used by common code.

Oh, yes. I somehow managed to overlook that. Some of the #include-s then
want to move inside the #ifndef, though. (Ultimately I question the
placement of this #define in this header, but we can deal with that
separately.)

Jan

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 183768-retest
 test-armhf-armhf-libvirt-raw 13 guest-start fail pass in 183768-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 183768 like 
183755
 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 183768 never pass
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183755
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183755
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183755
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183755
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183755
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183755
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 183755
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183755
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183755
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183755
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183755
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   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-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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  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-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 15 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-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-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-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-amd64-amd64-libvirt-vhd 14 migrate-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
 test-armhf-armhf-libvirt-qcow2 14 migrate-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-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-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

version targeted for testing:
 xen  7ad0c774e474f6d95dfda868d876af507d399657
baseline version:
 xen   

Re: [PATCH v2 08/15] xen/asm-generic: introduce generic header percpu.h

[Jan Beulich]

On 10.11.2023 17:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/percpu.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_PERCPU_H__
> +#define __ASM_GENERIC_PERCPU_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +
> +extern char __per_cpu_start[], __per_cpu_data_end[];

Can we go one tiny step beyond what Arm presently has and make the
latter of the two const?

Jan

Re: [Discussion]: Making "LIBXL_HOTPLUG_TIMEOUT" configurable through 'xl.conf'

[Jan Beulich]

On 15.11.2023 18:23, Olaf Hering wrote:
> Wed, 15 Nov 2023 15:29:09 + Divin Raj :
> 
>> LIBXL_HOTPLUG_TIMEOUT
> 
> This is already solved by "libxl.LIBXL_HOTPLUG_TIMEOUT.patch" from 
> https://build.opensuse.org/package/show/openSUSE:Factory/xen
> Up to now it was not considered important enough for xen.git#staging.

Did you ever submit it? A quick request to Google suggests you may not have
done so.

Jan

4.18 vs mini-os

[Jan Beulich]

All,

may I ask on what basis the xen-RELEASE-4.18.0 tag placement was chosen?
It matches the 4.17 ones, despite there having been new commits from
Jürgen dating back to January / February. (My own build fix would have
been nice to have, too, but I can see how that came late.)

Jan

Re: [Discussion]: Making "LIBXL_HOTPLUG_TIMEOUT" configurable through 'xl.conf'

[Olaf Hering]

Thu, 16 Nov 2023 08:45:43 +0100 Jan Beulich :

> Did you ever submit it?

Likely not.

I think the approach to use a xenstore entry was used to avoid
ABI incompatibilities due to changed .idl files.

In case anyone really wants up upstream such change, a global
per-device timeout should not go into xl.conf, to make sure
domUs managed by libvirt can also be tuned.


Olaf


pgpLTkWz7xNWD.pgp
Description: Digitale Signatur von OpenPGP