Re: [XEN v3 3/3] xen/arm: arm32: Add emulation of Debug Data Transfer Registers
Hi Ayan,
On 05/01/2024 12:21, Ayan Kumar Halder wrote:
> DBGOSLSR is emulated in the same way as its AArch64 variant (ie OSLSR_EL1).
> This is to ensure that DBGOSLSR.OSLK is 0, thus MDSCR_EL1.TXfull is treated
> as UNK/SBZP.
No need for this dot and yet another thus (it reads difficult).
You explained the OSLK bit, but you are not emulating this reg as ro_raz.
Instead you
copied the code from AArch64 (ro_read_val) which also sets OSLM[1] bit. Do we
want the same handling
given that Linux on arm32 does not make use of it?
> Thus only MDCCSR_EL0 can be emulated (which is DBGDSCRINT on arm32).
> DBGDSCRINT can be accessed at EL0 as DBGDSCREXT is emulated as RAZ (as
> DBGOSLSR.OSLK == 0). DBGDSCRINT.TXfull is set to 1.
Even though this patch comes after the one explaining the need of emulating DCC
I would still expect some reasoning here. Someone reading the vcpreg code and
checking the commit
behind would not know the rationale behind this patch.
Allowing access DBGDSCRINT from EL0 is a fix, so I would make it clear by
starting a sentence
with "Take the opportunity to fix the minimum EL for DBGDSCRINT ...".
>
> Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint
> "If TXfull is set to 1, set DTRTX to UNKNOWN".
> So, DBGDTR[TR]XINT is emulated as RAZ/WI.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from
>
> v1 :- 1. DBGDTR_EL0 does not emulate RXfull. This is to avoid giving the OS
> any
> indication that the RX buffer is full and is waiting to be read.
>
> 2. In Arm32, DBGOSLSR is emulated. Also DBGDTRTXINT is emulated at EL0 only.
>
> 3. Fixed the commit message and inline code comments.
>
> v2 :- 1. Split the patch into two (separate patches for arm64 and arm32).
> 2. Fixed in line comments and style related issues.
> 3. Updated commit message to mention DBGDSCRINT handling.
>
> xen/arch/arm/include/asm/cpregs.h | 2 ++
> xen/arch/arm/vcpreg.c | 36 ++-
> 2 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/include/asm/cpregs.h
> b/xen/arch/arm/include/asm/cpregs.h
> index 6b083de204..aec9e8f329 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -75,6 +75,8 @@
> #define DBGDIDR p14,0,c0,c0,0 /* Debug ID Register */
> #define DBGDSCRINT p14,0,c0,c1,0 /* Debug Status and Control Internal
> */
> #define DBGDSCREXT p14,0,c0,c2,2 /* Debug Status and Control External
> */
> +#define DBGDTRRXINT p14,0,c0,c5,0 /* Debug Data Transfer Register,
> Receive */
> +#define DBGDTRTXINT p14,0,c0,c5,0 /* Debug Data Transfer Register,
> Transmit */
> #define DBGVCR p14,0,c0,c7,0 /* Vector Catch */
> #define DBGBVR0 p14,0,c0,c0,4 /* Breakpoint Value 0 */
> #define DBGBCR0 p14,0,c0,c0,5 /* Breakpoint Control 0 */
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index a2d0500704..474f872b5f 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -493,11 +493,12 @@ void do_cp14_32(struct cpu_user_regs *regs, const union
> hsr hsr)
> * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
> *
> * Unhandled:
> - *DBGOSLSR
> *DBGPRCR
> */
> case HSR_CPREG32(DBGOSLAR):
> return handle_wo_wi(regs, regidx, cp32.read, hsr, 1);
> +case HSR_CPREG32(DBGOSLSR):
> +return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, 1U << 3);
> case HSR_CPREG32(DBGOSDLR):
> return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>
> @@ -509,8 +510,6 @@ void do_cp14_32(struct cpu_user_regs *regs, const union
> hsr hsr)
> *
> * Unhandled:
> *DBGDCCINT
> - *DBGDTRRXint
> - *DBGDTRTXint
> *DBGWFAR
> *DBGDTRTXext
> *DBGDTRRXext,
> @@ -549,11 +548,24 @@ void do_cp14_32(struct cpu_user_regs *regs, const union
> hsr hsr)
> }
>
> case HSR_CPREG32(DBGDSCRINT):
> +{
> /*
> - * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
> - * is set to 0, which we emulated below.
> + * Xen doesn't expose a real (or emulated) Debug Communications
> Channel
> + * (DCC) to a domain. Yet the Arm ARM implies this is not an optional
> + * feature. So some domains may start to probe it. For instance, the
> + * HVC_DCC driver in Linux (since f35dc083 and at least up to
> v6.7),
> + * will try to write some characters and check if the transmit buffer
> + * has emptied. By setting TX status bit to indicate the transmit
> buffer
> + * is full. This we would hint the OS that the DCC is probably not
> + * working.
> + *
> + * Bit 29: TX full
> + *
> + * Accessible by EL0 if DBGDSCRext.UDCCdis is set to 0, which we
> emulate
> + * as RAZ/WI in the next case.
> */
> -return handle_ro_raz(regs, regidx, cp32.read, hsr, 1);
> +
Re: [XEN v3 2/3] xen/arm: arm64: Add emulation of Debug Data Transfer Registers
Hi Ayan,
On 05/01/2024 12:21, Ayan Kumar Halder wrote:
> From: Michal Orzel
>
> Currently if user enables HVC_DCC config option in Linux, it invokes access
> to debug data transfer registers (ie DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
> arm32). As these registers are not emulated, Xen injects an undefined
> exception to the VM and Linux (running as VM) crashes.
>
> We wish to avoid this crash by adding a partial emulation of DBGDTRTX_EL0.
> MDCCSR_EL0 is emulated as TXfull.
>
> Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0
> "If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN".
>
> Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before
> using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(),
> it returns -ENODEV. In this way, we are preventing the VM from accessing
> DBGDTRTX_EL0 register.
AFAIK, we are preventing the VM from making use of HVC DCC as a console.
DBGDTRTX_EL0 and MDCCSR_EL0 will be accessed at least once as part of
hvc_dcc_check().
>
> We also emulate DBGDTR[TR]X_EL0 as RAZ/WI.
>
> Signed-off-by: Michal Orzel
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from
>
> v1 :- 1. DBGDTR_EL0 does not emulate RXfull. This is to avoid giving the OS
> any
> indication that the RX buffer is full and is waiting to be read.
>
> 2. In Arm32, DBGOSLSR is emulated. Also DBGDTRTXINT is emulated at EL0 only.
>
> 3. Fixed the commit message and inline code comments.
>
> v2 :- 1. Split the patch into two (separate patches for arm64 and arm32).
> 2. Removed the "fail" label.
> 3. Fixed the commit message.
>
> xen/arch/arm/arm64/vsysreg.c | 25 +
> xen/arch/arm/include/asm/arm64/hsr.h | 3 +++
> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index b5d54c569b..2f70eea2e5 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -159,9 +159,6 @@ void do_sysreg(struct cpu_user_regs *regs,
> *
> * Unhandled:
> *MDCCINT_EL1
> - *DBGDTR_EL0
> - *DBGDTRRX_EL0
> - *DBGDTRTX_EL0
> *OSDTRRX_EL1
> *OSDTRTX_EL1
> *OSECCR_EL1
> @@ -172,11 +169,31 @@ void do_sysreg(struct cpu_user_regs *regs,
> case HSR_SYSREG_MDSCR_EL1:
> return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> case HSR_SYSREG_MDCCSR_EL0:
> +{
> /*
> + * Xen doesn't expose a real (or emulated) Debug Communications
> Channel
> + * (DCC) to a domain. Yet the Arm ARM implies this is not an optional
> + * feature. So some domains may start to probe it. For instance, the
> + * HVC_DCC driver in Linux (since f35dc083 and at least up to
> v6.7),
> + * will try to write some characters and check if the transmit buffer
> + * has emptied. By setting TX status bit to indicate the transmit
> buffer
> + * is full, we would hint the OS that the DCC is probably not
> working.
> + *
> + * Bit 29: TX full
> + *
> * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate
> that
> * register as RAZ/WI above. So RO at both EL0 and EL1.
> */
> -return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0);
> +return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 0,
> + 1U << 29);
I would assume that if partial emulation is not enabled, we should stick to
ro_raz
instead of emulating TX set.
> +}
> +#ifdef CONFIG_PARTIAL_EMULATION
> +case HSR_SYSREG_DBGDTR_EL0:
> +/* DBGDTR[TR]X_EL0 share the same encoding */
> +case HSR_SYSREG_DBGDTRTX_EL0:
> +if ( opt_partial_emulation )
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 0);
This is incorrect. What will happen if CONFIG_PARTIAL_EMULATION=y and
opt_partial_emulation=false ?
You would fall through to cases below and end up in RAZ/WI. Instead, you should
jump to default case,
so that we would inject undefined exception.
> +#endif
> HSR_SYSREG_DBG_CASES(DBGBVR):
> HSR_SYSREG_DBG_CASES(DBGBCR):
> HSR_SYSREG_DBG_CASES(DBGWVR):
> diff --git a/xen/arch/arm/include/asm/arm64/hsr.h
> b/xen/arch/arm/include/asm/arm64/hsr.h
> index e691d41c17..1495ccddea 100644
> --- a/xen/arch/arm/include/asm/arm64/hsr.h
> +++ b/xen/arch/arm/include/asm/arm64/hsr.h
> @@ -47,6 +47,9 @@
> #define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4)
> #define HSR_SYSREG_DBGPRCR_EL1HSR_SYSREG(2,0,c1,c4,4)
> #define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0)
> +#define HSR_SYSREG_DBGDTR_EL0 HSR_SYSREG(2,3,c0,c4,0)
> +#define HSR_SYSREG_DBGDTRTX_EL0 HSR_SYSREG(2,3,c0,c5,0)
> +#define HSR_SYSREG_DBGDTRRX_EL0 HSR_SYSREG(2,3,c0,c5,0)
>
> #define HSR_SYSREG_DBGBVRn_EL1(n) HSR_SYSREG(2,0,c0,c##n,4)
> #define HSR_SYSREG_DBGBCRn_EL1(n) HSR_SYSREG(2,0,c0,c##n,5)
~Michal
Re: [XEN v3 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option
Hi Ayan,
On 05/01/2024 12:21, Ayan Kumar Halder wrote:
>
>
> There can be situations when the registers cannot be emulated to their full
> functionality. This can be due to the complexity involved. In such cases, one
> can emulate those registers as RAZ/WI. We call them as partial emulation.
I read this as if RAZ/WI was the only solution which is not true. I would add
e.g.
>
> A suitable example of this (as seen in subsequent patches) is emulation of
> DBGDTRTX_EL0 (on Arm64) and DBGDTRTXINT(on Arm32). These non-optional
> registers can be partially emulated as RAZ/WI and they can be enclosed
> within CONFIG_PARTIAL_EMULATION.
I think we are missing the purpose of this patch i.e. why we want to enable
partial
emulation instead of default behavior which is injecting undefined exception.
>
> Further, "partial-emulation" command line option enables us to
> enable/disable partial emulation at run time. While CONFIG_PARTIAL_EMULATION
> enables support for partial emulation at compile time (ie adds code for
> partial emulation), this option may be enabled or disabled by Yocto or other
> build systems. However if the build system turns this option on, customers
Users (in general) instead of customers?
> can use cripts like Imagebuilder to generate uboot-script which will append
s/cripts/scripts
> "partial-emulation=false" to xen command line to turn off the partial
> emulation. Thus, it helps to avoid rebuilding xen.
>
> By default, "CONFIG_PARTIAL_EMULATION=y" and "partial-emulation=false".
> This is done so that Xen supports partial emulation. However, customers are
> fully aware when they enable partial emulation.
It's important to note that enabling such support might result in
unwanted/non-spec
compliant behavior.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from v1 :-
> 1. New patch introduced in v2.
>
> v2 :-
> 1. Reordered the patches so that the config and command line option is
> introduced in the first patch.
>
> docs/misc/xen-command-line.pandoc | 7 +++
> xen/arch/arm/Kconfig | 8
> xen/arch/arm/include/asm/regs.h | 6 ++
> xen/arch/arm/traps.c | 3 +++
> 4 files changed, 24 insertions(+)
>
> diff --git a/docs/misc/xen-command-line.pandoc
> b/docs/misc/xen-command-line.pandoc
> index 8e65f8bd18..dd2a76fb19 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1949,6 +1949,13 @@ This option is ignored in **pv-shim** mode.
>
> > Default: `on`
>
> +### partial-emulation (arm)
> +> `= `
> +
> +> Default: `false`
> +
> +Flag to enable or disable partial emulation of registers
Missing dot at the end of sentence.
Also, I would add a warning that enabling this option might result in unwanted
behavior
and that it is only effective if CONFIG_PARTIAL_EMULATION is enabled.
> +
> ### pci
> = List of [ serr=, perr= ]
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 50e9bfae1a..8f25d9cba0 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -225,6 +225,14 @@ config STATIC_EVTCHN
> This option enables establishing static event channel communication
> between domains on a dom0less system (domU-domU as well as
> domU-dom0).
>
> +config PARTIAL_EMULATION
> +bool "Enable partial emulation for registers"
Shouldn't we be more specific and write system/coprocessor registers?
> +default y
> +help
> + This option enabled partial emulation for registers to avoid guests
s/enabled/enables
> + crashing when accessing registers which are not optional but has not
> been
> + emulated to its complete functionality.
Ditto about the possible side effect.
Formatting is incorrect. bool, default, help should be indented by tab and help
text
by tab and 2 spaces.
> +
> endmenu
>
> menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/include/asm/regs.h b/xen/arch/arm/include/asm/regs.h
> index f998aedff5..b71fa20f91 100644
> --- a/xen/arch/arm/include/asm/regs.h
> +++ b/xen/arch/arm/include/asm/regs.h
> @@ -13,6 +13,12 @@
>
> #define psr_mode(psr,m) (((psr) & PSR_MODE_MASK) == (m))
>
> +/*
> + * opt_partial_emulation: If true, partial emulation for registers will be
> + * enabled.
> + */
Description would better suit at the definition.
> +extern bool opt_partial_emulation;
> +
Given that parameter definition is in traps.c, I would add declaration in
traps.h.
> static inline bool regs_mode_is_32bit(const struct cpu_user_regs *regs)
> {
> #ifdef CONFIG_ARM_32
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9c10e8f78c..d5fb9c1035 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -42,6 +42,9 @@
> #include
> #include
>
> +bool opt_partial_emulation = false;
> +boolean_param("partial-emulation", opt_partial_emulation);
Looking at other patches, the partial emulation code will most often be used as
follows:
#ifdef CONFIG_PARTIAL_EMULATION
[ovmf test] 184272: all pass - PUSHED
flight 184272 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184272/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ff1305c9fb171ad51bfc149c544e3ab5a0edf521 baseline version: ovmf 9cf1d03ebe076b3e3825dfebbc19fd6b52b5f336 Last test of basis 184259 2024-01-05 20:42:55 Z2 days Testing same since 184272 2024-01-08 02:11:04 Z0 days1 attempts People who touched revisions under test: Suqiang Ren jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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/osstest/ovmf.git 9cf1d03ebe..ff1305c9fb ff1305c9fb171ad51bfc149c544e3ab5a0edf521 -> xen-tested-master
Re: [RFC XEN PATCH v4 5/5] libxl: Use gsi instead of irq for mapping pirq
On 2024/1/6 09:11, Stefano Stabellini wrote: > On Fri, 5 Jan 2024, Jiqian Chen wrote: >> In PVH dom0, it uses the linux local interrupt mechanism, >> when it allocs irq for a gsi, it is dynamic, and follow >> the principle of applying first, distributing first. And >> the irq number is alloced from small to large, but the >> applying gsi number is not, may gsi 38 comes before gsi >> 28, that causes the irq number is not equal with the gsi >> number. And when passthrough a device, xl wants to use >> gsi to map pirq, see pci_add_dm_done->xc_physdev_map_pirq, >> but the gsi number is got from file >> /sys/bus/pci/devices//irq in current code, so it >> will fail when mapping. >> >> So, use real gsi number read from gsi sysfs. >> >> Co-developed-by: Huang Rui >> Signed-off-by: Jiqian Chen > > Reviewed-by: Stefano Stabellini Thank you very much! I will add this in next version. And this implementation depends on the third patch on kernel side, if the maintainer doesn't like to add a gsi sysfs, this implementation may be changed in the future, if so, I will let you know. > -- Best regards, Jiqian Chen.
[linux-linus test] 184270: tolerable FAIL - PUSHED
flight 184270 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184270/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184268 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184268 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184268 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184268 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184268 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184268 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184268 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184268 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 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-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-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-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-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 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-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linux0dd3ee31125508cd67f7e7172247f05b7fd1753a baseline version: linux52b1853b080a082ec3749c3a9577f6c71b1d4a90 Last test of basis 184268 2024-01-07 02:16:58 Z1 days Testing same since 184270 2024-01-07 20:42:19 Z0 days1 attempts People who touched revisions under test: Linus Torvalds jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
Re: [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission
On 2024/1/6 09:08, Stefano Stabellini wrote:
> On Fri, 5 Jan 2024, Jiqian Chen wrote:
>> Some type of domain don't have PIRQ, like PVH, current
>> implementation is not suitable for those domain.
>>
>> When passthrough a device to guest on PVH dom0, this
>> pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
>> at domain_pirq_to_irq.
>>
>> So, change it to use gsi to grant/revoke irq permission.
>> And change the caller of XEN_DOMCTL_irq_permission to
>> pass gsi to it instead of pirq.
>>
>> Co-developed-by: Huang Rui
>> Signed-off-by: Jiqian Chen
>
> I realize there is no explanation or comment right now, but I think this
> change would benefit from a in-code comment in xen/include/public/domctl.h
> E.g.:
>
> /* XEN_DOMCTL_irq_permission */
> struct xen_domctl_irq_permission {
> uint32_t pirq; /* pirq is the GSI on x86 */
> uint8_t allow_access;/* flag to specify enable/disable of IRQ access
> */
> uint8_t pad[3];
> };
Will add this comment in next version, thanks.
>
>
>> ---
>> tools/libs/light/libxl_pci.c | 6 --
>> tools/libs/light/libxl_x86.c | 5 -
>> xen/common/domctl.c | 12 ++--
>> 3 files changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
>> index 96cb4da0794e..e1341d1e9850 100644
>> --- a/tools/libs/light/libxl_pci.c
>> +++ b/tools/libs/light/libxl_pci.c
>> @@ -1418,6 +1418,7 @@ static void pci_add_dm_done(libxl__egc *egc,
>> unsigned long long start, end, flags, size;
>> int irq, i;
>> int r;
>> +int gsi;
>> uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED;
>> uint32_t domainid = domid;
>> bool isstubdom = libxl_is_stubdom(ctx, domid, );
>> @@ -1486,6 +1487,7 @@ static void pci_add_dm_done(libxl__egc *egc,
>> goto out_no_irq;
>> }
>> if ((fscanf(f, "%u", ) == 1) && irq) {
>> +gsi = irq;
>
> A question for Roger and Jan: are we always guaranteed that gsi == irq
> (also in the PV case)?
>
> Also I don't think we necessarily need the gsi local variable, I would
> just add an in-code comment below...
Here pass the pointer of irq to xc_physdev_map_pirq, and that function will
assign the value of pirq to irq on Xen side, so after calling
xc_physdev_map_pirq, the value of irq isn't the original value, we need a local
variable to record the original value.
>
>
>> r = xc_physdev_map_pirq(ctx->xch, domid, irq, );
>> if (r < 0) {
>> LOGED(ERROR, domainid, "xc_physdev_map_pirq irq=%d (error=%d)",
>> @@ -1494,10 +1496,10 @@ static void pci_add_dm_done(libxl__egc *egc,
>> rc = ERROR_FAIL;
>> goto out;
>> }
>
> ... like this:
>
> /* xc_domain_irq_permission takes a gsi, here we assume irq == gsi */
> r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
Will add this comment in next version, thanks.
>
>
>> -r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
>> +r = xc_domain_irq_permission(ctx->xch, domid, gsi, 1);
>> if (r < 0) {
>> LOGED(ERROR, domainid,
>> - "xc_domain_irq_permission irq=%d (error=%d)", irq, r);
>> + "xc_domain_irq_permission irq=%d (error=%d)", gsi, r);
>> fclose(f);
>> rc = ERROR_FAIL;
>> goto out;
>> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
>> index d16573e72cd4..88ad50cf6360 100644
>> --- a/tools/libs/light/libxl_x86.c
>> +++ b/tools/libs/light/libxl_x86.c
>> @@ -654,12 +654,15 @@ out:
>> int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t domid, int irq)
>
> you could just rename the int irq parameter to int gsi ?
No, the same reason as above.
>
>
>> {
>> int ret;
>> +int gsi;
>> +
>> +gsi = irq;
>>
>> ret = xc_physdev_map_pirq(CTX->xch, domid, irq, );
>> if (ret)
>> return ret;
>>
>> -ret = xc_domain_irq_permission(CTX->xch, domid, irq, 1);
>> +ret = xc_domain_irq_permission(CTX->xch, domid, gsi, 1);
>> return ret;
>> }
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index f5a71ee5f78d..eeb975bd0194 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -653,12 +653,20 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>> u_domctl)
>> unsigned int pirq = op->u.irq_permission.pirq, irq;
>> int allow = op->u.irq_permission.allow_access;
>
> here we could benefit from renaming pirq to gsi, at least it becomes
> clear:
>
> unsigned int gsi = op->u.irq_permission.pirq, irq;
Thank you, I will rename it in next version.
>
>
>> -if ( pirq >= current->domain->nr_pirqs )
>> +if ( pirq >= nr_irqs_gsi )
>> {
>> ret = -EINVAL;
>> break;
>> }
>> -irq = pirq_access_permitted(current->domain, pirq);
>> +
>> +if ( irq_access_permitted(current->domain, pirq) )
>> +irq = pirq;
>> +
!qemu_in_coroutine() assert on ARM64 XEN
Hi All, When enabling virtio disk and virtio net on Xen, I could see qemu blk assert and being killed sometimes, This is not 100% reproducible. I am using qemu master branch 7425b6277f12e82952cede1f531bfc689bf77fb1 (HEAD -> dummy, origin/staging, origin/master, origin/HEAD, master) Merge tag 'tracing-pull-request' of https://gitlab.com/stefanha/qemu into staging The qemu built option is the one in xen tool/Makefile, I just change to qemu-system-aarch64. Anyone has suggestions? The coredump stack: Symbols already loaded for /usr/lib/libc.so.6 (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x9e100568 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78 #2 0x9e0bacd0 in __GI_raise (sig=sig@entry=6) at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/raise.c:26 #3 0x9e0a6ef0 in __GI_abort () at abort.c:79 #4 0x9e0b43f8 in __assert_fail_base ( fmt=0x9e1ca8a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xe0d25740 "!qemu_in_coroutine()", file=file@entry=0xe0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xe0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:92 #5 0x9e0b4470 in __assert_fail ( assertion=assertion@entry=0xe0d25740 "!qemu_in_coroutine()", file=file@entry=0xe0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xe0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:101 #6 0xe0a66a60 in bdrv_graph_rdlock_main_loop () at ../qemu-xen-dir-remote/block/graph-lock.c:260 #7 0xe0a6d9e0 in graph_lockable_auto_lock_mainloop (x=) --Type for more, q to quit, c to continue without paging-- at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/block/graph-lock.h:259 #8 bdrv_unregister_buf (bs=bs@entry=0xf619d5a0, host=host@entry=0x742c8000, size=size@entry=2097152) at ../qemu-xen-dir-remote/block/io.c:3362 #9 0xe0a5ddd4 in blk_unregister_buf (blk=, host=0x742c8000, size=2097152) at ../qemu-xen-dir-remote/block/block-backend.c:2859 #10 0xe060aab4 in ram_block_removed (n=, host=, size=, max_size=) at ../qemu-xen-dir-remote/block/block-ram-registrar.c:33 #11 0xe0399318 in ram_block_notify_remove (host=0x742c8000, size=2097152, max_size=2097152) at ../qemu-xen-dir-remote/hw/core/numa.c:883 #12 0xe097cf84 in xen_invalidate_map_cache_entry_unlocked ( buffer=buffer@entry=0x743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:475 #13 0xe097dad0 in xen_invalidate_map_cache_entry ( buffer=buffer@entry=0x743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:487 #14 0xe0993e18 in address_space_unmap ( as=as@entry=0xe1ca3ae8 , buffer=0x743c5000, len=, is_write=is_write@entry=true, --Type for more, q to quit, c to continue without paging-- access_len=access_len@entry=32768) at ../qemu-xen-dir-remote/system/physmem.c:3199 #15 0xe095cc9c in dma_memory_unmap (access_len=32768, dir=DMA_DIRECTION_FROM_DEVICE, len=, buffer=, as=0xe1ca3ae8 ) at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/sysemu/dma.h:236 #16 virtqueue_unmap_sg (vq=vq@entry=0x965cc010, elem=elem@entry=0xf620aa30, len=len@entry=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:758 #17 0xe095efa4 in virtqueue_fill (vq=vq@entry=0x965cc010, elem=elem@entry=0xf620aa30, len=len@entry=32769, idx=idx@entry=0) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:919 #18 0xe095f0b8 in virtqueue_push (vq=0x965cc010, elem=elem@entry=0xf620aa30, len=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:994 #19 0xe091a608 in virtio_blk_req_complete ( req=req@entry=0xf620aa30, status=status@entry=0 '\000') at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:67 #20 0xe091bdc8 in virtio_blk_rw_complete (opaque=, ret=0) at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:136 #21 0xe0a5a938 in blk_aio_complete (acb=acb@entry=0x880015f0) at ../qemu-xen-dir-remote/block/block-backend.c:1559 --Type for more, q to quit, c to continue without paging-- #22 0xe0a5b58c in blk_aio_read_entry (opaque=0x880015f0) at ../qemu-xen-dir-remote/block/block-backend.c:1614 #23 0xe0b96c2c in coroutine_trampoline (i0=, i1=) at ../qemu-xen-dir-remote/util/coroutine-ucontext.c:177 #24 0x9e0bfb40 in ?? () at ../sysdeps/unix/sysv/linux/aarch64/setcontext.S:123 from /usr/lib/libc.so.6 (gdb) thread apply all bt Thread 10 (Thread 0x951348c0 (LWP 5460)): #0 0x9e15d8c4 in __GI___libc_read (nbytes=16,
[PATCH] hw/i386/pc_piix: Make piix_intx_routing_notifier_xen() more device independent
This is a follow-up on commit 89965db43cce "hw/isa/piix3: Avoid Xen-specific
variant of piix3_write_config()" which introduced
piix_intx_routing_notifier_xen(). This function is implemented in board code but
accesses the PCI configuration space of the PIIX ISA function to determine the
PCI interrupt routes. Avoid this by reusing pci_device_route_intx_to_irq() which
makes piix_intx_routing_notifier_xen() more device-agnostic.
One remaining improvement would be making piix_intx_routing_notifier_xen()
agnostic towards the number of PCI interrupt routes and move it to xen-hvm.
This might be useful for possible Q35 Xen efforts but remains a future exercise
for now.
Signed-off-by: Bernhard Beschow
---
hw/i386/pc_piix.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 042c13cdbc..abfcfe4d2b 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -92,13 +92,10 @@ static void piix_intx_routing_notifier_xen(PCIDevice *dev)
{
int i;
-/* Scan for updates to PCI link routes (0x60-0x63). */
+/* Scan for updates to PCI link routes. */
for (i = 0; i < PIIX_NUM_PIRQS; i++) {
-uint8_t v = dev->config_read(dev, PIIX_PIRQCA + i, 1);
-if (v & 0x80) {
-v = 0;
-}
-v &= 0xf;
+const PCIINTxRoute route = pci_device_route_intx_to_irq(dev, i);
+const uint8_t v = route.mode == PCI_INTX_ENABLED ? route.irq : 0;
xen_set_pci_link_route(i, v);
}
}
--
2.43.0
[linux-linus test] 184268: tolerable FAIL - PUSHED
flight 184268 linux-linus real [real] flight 184269 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184268/ http://logs.test-lab.xenproject.org/osstest/logs/184269/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-freebsd11-amd64 19 guest-localmigrate/x10 fail pass in 184269-retest test-armhf-armhf-libvirt-raw 8 xen-bootfail pass in 184269-retest test-amd64-amd64-xl-credit1 22 guest-start/debian.repeat fail pass in 184269-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 184269 like 184265 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 184269 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184265 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184265 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184265 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184265 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184265 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184265 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184265 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 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-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-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-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-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-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-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-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linux52b1853b080a082ec3749c3a9577f6c71b1d4a90 baseline version: linux95c8a35f1c017327eab3b6a2ff5c04255737c856 Last test of basis 184265 2024-01-06 13:44:26 Z1 days Testing same since 184268 2024-01-07 02:16:58 Z0 days1 attempts People who touched revisions under test: Attreyee Mukherjee Benjamin Bara Linus Torvalds Michael Walle Randy Dunlap Tor Vic Wolfram Sang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
xen | Successful pipeline for staging | 5a3ace21
Pipeline #1129775950 has passed! Project: xen ( https://gitlab.com/xen-project/xen ) Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging ) Commit: 5a3ace21 ( https://gitlab.com/xen-project/xen/-/commit/5a3ace21f3d779b291a2d305824b2820d88de7f1 ) Commit Message: xen/arm: smmu-v3: address violations of MISRA C... Commit Author: Federico Serafini Committed by: Stefano Stabellini Pipeline #1129775950 ( https://gitlab.com/xen-project/xen/-/pipelines/1129775950 ) triggered by Andrew Cooper ( https://gitlab.com/andyhhp ) successfully completed 133 jobs in 3 stages. -- You're receiving this email because of your account on gitlab.com.
[PATCH v2] xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import
From: Oleksandr Tyshchenko
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately, here (for special Xen device) we can avoid using
pages and calculate gfns directly from dma addresses provided by
the sg table.
Suggested-by: Daniel Vetter
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Christian König
Reviewed-by: Stefano Stabellini
---
Please note, I didn't manage to test the patch against the latest master branch
on real HW (patch was only build tested there). Patch was tested on Arm64
guests using Linux v5.10.41 from vendor's BSP, this is the environment where
running this use-case is possible and to which I have an access (Xen PV display
with zero-copy and backend domain as a buffer provider - be-alloc=1, so dma-buf
import part was involved). A little bit old, but the dma-buf import code
in gntdev-dmabuf.c hasn't been changed much since that time, all context
remains allmost the same according to my code inspection.
v2:
- add R-b and A-b
- fix build warning noticed by kernel test robot by initializing
"ret" in case of error
https://lore.kernel.org/oe-kbuild-all/202401062122.it6zvlg0-...@intel.com/
---
---
drivers/xen/gntdev-dmabuf.c | 44 -
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 4440e626b797..272c0ab01ef5 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -50,7 +51,7 @@ struct gntdev_dmabuf {
/* Number of pages this buffer has. */
int nr_pages;
- /* Pages of this buffer. */
+ /* Pages of this buffer (only for dma-buf export). */
struct page **pages;
};
@@ -484,7 +485,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv *priv,
int flags,
/* DMA buffer import support. */
static int
-dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+dmabuf_imp_grant_foreign_access(unsigned long *gfns, u32 *refs,
int count, int domid)
{
grant_ref_t priv_gref_head;
@@ -507,7 +508,7 @@ dmabuf_imp_grant_foreign_access(struct page **pages, u32
*refs,
}
gnttab_grant_foreign_access_ref(cur_ref, domid,
- xen_page_to_gfn(pages[i]), 0);
+ gfns[i], 0);
refs[i] = cur_ref;
}
@@ -529,7 +530,6 @@ static void dmabuf_imp_end_foreign_access(u32 *refs, int
count)
static void dmabuf_imp_free_storage(struct gntdev_dmabuf *gntdev_dmabuf)
{
- kfree(gntdev_dmabuf->pages);
kfree(gntdev_dmabuf->u.imp.refs);
kfree(gntdev_dmabuf);
}
@@ -549,12 +549,6 @@ static struct gntdev_dmabuf *dmabuf_imp_alloc_storage(int
count)
if (!gntdev_dmabuf->u.imp.refs)
goto fail;
- gntdev_dmabuf->pages = kcalloc(count,
- sizeof(gntdev_dmabuf->pages[0]),
- GFP_KERNEL);
- if (!gntdev_dmabuf->pages)
- goto fail;
-
gntdev_dmabuf->nr_pages = count;
for (i = 0; i < count; i++)
@@ -576,7 +570,8 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
struct dma_buf *dma_buf;
struct dma_buf_attachment *attach;
struct sg_table *sgt;
- struct sg_page_iter sg_iter;
+ struct sg_dma_page_iter sg_iter;
+ unsigned long *gfns;
int i;
dma_buf = dma_buf_get(fd);
@@ -624,26 +619,25 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv,
struct device *dev,
gntdev_dmabuf->u.imp.sgt = sgt;
- /* Now convert sgt to array of pages and check for page validity. */
+ gfns = kcalloc(count, sizeof(*gfns), GFP_KERNEL);
+ if (!gfns) {
+ ret = ERR_PTR(-ENOMEM);
+ goto fail_unmap;
+ }
+
+ /* Now convert sgt to array of gfns without accessing underlying pages.
*/
i = 0;
- for_each_sgtable_page(sgt, _iter, 0) {
- struct page *page = sg_page_iter_page(_iter);
- /*
-* Check if page is valid: this can happen if we are given
-* a page from VRAM or other resources which are not backed
-* by a struct page.
-*/
- if (!pfn_valid(page_to_pfn(page))) {
- ret = ERR_PTR(-EINVAL);
- goto fail_unmap;
- }
+ for_each_sgtable_dma_page(sgt, _iter, 0) {
+ dma_addr_t addr = sg_page_iter_dma_address(_iter);
+ unsigned long pfn = bfn_to_pfn(XEN_PFN_DOWN(dma_to_phys(dev,
addr)));
- gntdev_dmabuf->pages[i++] = page;
+
[xen-unstable test] 184267: tolerable FAIL
flight 184267 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184267/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail pass in 184264 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184264 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184264 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184264 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184264 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184264 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184264 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184264 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184264 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184264 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184264 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184264 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184264 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-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 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-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-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-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-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-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-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-armhf-armhf-libvirt-qcow2 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-armhf-armhf-libvirt-raw 14 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-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 5a3ace21f3d779b291a2d305824b2820d88de7f1 baseline version: xen 5a3ace21f3d779b291a2d305824b2820d88de7f1 Last test of basis 184267 2024-01-07 01:57:26 Z0 days Testing same since (not found) 0 attempts jobs:
