[xen-unstable-smoke test] 186425: regressions - FAIL

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

[ovmf test] 186422: all pass - PUSHED

flight 186422 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186422/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 57a890fd03356350a1b7a2a0064c8118f44e9958 baseline version: ovmf 95e220e95d6237e21f7c0

[linux-linus test] 186413: regressions - FAIL

flight 186413 linux-linus real [real] flight 186424 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186413/ http://logs.test-lab.xenproject.org/osstest/logs/186424/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

[xen-unstable-smoke test] 186420: regressions - FAIL

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

Re: [XEN PATCH 4/5] automation/eclair_analysis: address remaining violations of MISRA C Rule 20.12

On Sat, 1 Jun 2024, Nicola Vetrini wrote: > The DEFINE macro in asm-offsets.c (for all architectures) still generates > violations despite the file(s) being excluded from compliance, due to the > fact that in its expansion it sometimes refers entities in non-excluded files. > These corner cases are

Re: [XEN PATCH v3] automation/eclair: extend existing deviations of MISRA C Rule 16.3

On Fri, 14 Jun 2024, Federico Serafini wrote: > Update ECLAIR configuration to deviate more cases where an > unintentional fallthrough cannot happen. > > Add Rule 16.3 to the monitored set and tag it as clean for arm. > > Signed-off-by: Federico Serafini Acked-by: Stefano Stabellini

Re: [XEN PATCH v3] automation/eclair: add deviation for MISRA C Rule 17.7

On Fri, 14 Jun 2024, Federico Serafini wrote: > Update ECLAIR configuration to deviate some cases where not using > the return value of a function is not dangerous. > > Signed-off-by: Federico Serafini Acked-by: Stefano Stabellini > --- > Changes in v3: > - removed unwanted underscores; > - g

Re: [PATCH] automation/eclair_analysis: deviate common/unlzo.c for MISRA Rule 7.3

On Tue, 18 Jun 2024, Jan Beulich wrote: > On 18.06.2024 11:54, Alessandro Zucchelli wrote: > > The file contains violations of Rule 7.3 which states as following: The > > lowercase character `l' shall not be used in a literal suffix. > > > > This file defines a non-compliant constant used in a mac

Re: [PATCH v4 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

On Wed, 18 Jun 2024, Julien Grall wrote: > Hi Stefano, > > On 19/06/2024 01:37, Stefano Stabellini wrote: > > On Mon, 27 May 2024, Oleksii K. wrote: > > > > I don't think it is a big problem if this is not merged for the code > > > > freeze as this is technically a bug fix. > > > > > > Agree, thi

[xen-unstable-smoke test] 186418: regressions - FAIL

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

[xen-unstable-smoke test] 186416: regressions - FAIL

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

[ovmf test] 186414: all pass - PUSHED

flight 186414 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186414/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 95e220e95d6237e21f7c0b83fca02d56b9327c4a baseline version: ovmf 4d4f56992460c039d0cfe

[PATCH for-4.19 v2] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX

AMD have updated the SRSO whitepaper[1] with further information. There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't cross the user/supervisor boundary. i.e. Xen don't need to use IBPB-on-entry for PV. There's also a new SRSO_MSR_FIX identifying that the BP_SPEC_REDUCE bit is a

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

flight 186409 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186409/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186401 test-amd64-amd64-xl-qemut-win7-amd64

[xen-unstable-smoke test] 186412: regressions - FAIL

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

[PATCH 1/2] automation/eclair_analysis: deviate MISRA C Rule 21.2

Rule 21.2 reports identifiers reserved for the C and POSIX standard libraries: all xen's translation units are compiled with option -nostdinc, this guarantees that these libraries are not used, therefore a justification is provided for allowing uses of such identifiers in the project. Builtins star

[PATCH 2/2] x86/APIC: address violation of MISRA C Rule 21.2

From: Nicola Vetrini The rule disallows the usage of an identifier reserved by the C standard. All identfiers starting with '__' are reserved for any use, so the label can be renamed in order to avoid the violation. No functional change. Signed-off-by: Nicola Vetrini --- xen/arch/x86/apic.c |

[PATCH 0/2] automation/eclair_analysis: deviate MISRA C Rule 21.2

This series aims to address several violations of Rule 21.2 which states the following: A reserved identifier or reserved macro name shall not be declared. The series contains two patches, one changes x86/APIC which used an identifier starting with '__', the second deviates all reserved identifiers

Re: Design session notes: GPU acceleration in Xen

On Wed, Jun 19, 2024 at 12:27 PM Christian König wrote: > > Am 18.06.24 um 16:12 schrieb Demi Marie Obenour: > > On Tue, Jun 18, 2024 at 08:33:38AM +0200, Christian König wrote: > > > Am 18.06.24 um 02:57 schrieb Demi Marie Obenour: > > >> On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykows

[PATCH] xen/guest_access: Fix accessors for 32bit builds of Xen

Gitlab CI reports an ARM32 randconfig failure as follows: In file included from common/livepatch.c:9: common/livepatch.c: In function ‘livepatch_list’: ./include/xen/guest_access.h:130:25: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 130 | __ra

Re: [RFC PATCH] iommu/xen: Add Xen PV-IOMMU driver

On Thu, Jun 13, 2024 at 01:50:22PM +, Teddy Astie wrote: > +struct iommu_domain *xen_iommu_domain_alloc(unsigned type) > +{ > + struct xen_iommu_domain *domain; > + u16 ctx_no; > + int ret; > + > + if (type & IOMMU_DOMAIN_IDENTITY) { > + /* use default domain */ > +

Re: [PATCH] AMD/IOMMU: Improve register_iommu_exclusion_range()

On 19/06/2024 8:45 am, Jan Beulich wrote: > On 18.06.2024 20:31, Andrew Cooper wrote: >> * Use 64bit accesses instead of 32bit accesses >> * Simplify the constant names >> * Pull base into a local variable to avoid it being reloaded because of the >>memory clobber in writeq(). >> >> No funct

Re: [PATCH 14/26] block: move the nonrot flag to queue_limits

Hi folks, how can I unsubscribe from this group.? Thanks in advance. S > On 17 Jun 2024, at 07:04, Christoph Hellwig wrote: > > Move the nonrot flag into the queue_limits feature field so that it can > be set atomically with the queue frozen. > > Use the chance to switch to defaulting to non-ro

Re: [PATCH for-4.19? v6 6/9] xen: Make the maximum number of altp2m views configurable for x86

On Thu, Jun 13, 2024 at 2:03 PM Jan Beulich wrote: > > @@ -510,13 +526,13 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned > > int idx, > > mfn_t mfn; > > int rc = -EINVAL; > > > > -if ( idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) || > > +if ( idx >= d->nr_altp2

Re: xen | Failed pipeline for staging | 43d5c5d5

On 19/06/2024 3:44 pm, GitLab wrote: > GitLab > ✖ Pipeline #1338876222 has failed! > >   > Project xen-project / xen > > Branch > staging > > Commit

[libvirt test] 186407: tolerable all pass - PUSHED

flight 186407 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/186407/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186390 test-amd64-amd64-libvirt-xsm 15 migrate-s

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

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

Re: [PATCH for-4.19] hotplug: Restore block-tap phy compatibility

On Wed, Jun 19, 2024 at 02:07:04PM +0200, Jan Beulich wrote: > On 16.05.2024 15:52, Jason Andryuk wrote: > > On 2024-05-16 03:41, Jan Beulich wrote: > >> On 16.05.2024 04:22, Jason Andryuk wrote: > >>> From: Jason Andryuk > >>> > >>> From: Jason Andryuk > >> > >> Two identical From: (also in anot

Re: [PATCH] loadpolicy: Verifies memory allocation during policy loading

On 6/19/24 08:04, Jan Beulich wrote: On 27.05.2024 14:54, ysk...@gmail.com wrote: --- a/tools/flask/utils/loadpolicy.c +++ b/tools/flask/utils/loadpolicy.c @@ -58,6 +58,11 @@ int main (int argCnt, const char *args[]) } polMemCp = malloc(info.st_size); +if (!polMemCp) { +

Re: move features flags into queue_limits v2

On Wed, Jun 19, 2024 at 08:21:14AM -0600, Jens Axboe wrote: > Please check for-6.11/block, as I pulled in the changes to the main > block branch and that threw some merge conflicts mostly due to Damien's > changes in for-6.11/block. While fixing those up, I also came across > oddities like: > > (l

Re: move features flags into queue_limits v2

On 6/19/24 8:18 AM, Jens Axboe wrote: > > On Mon, 17 Jun 2024 08:04:27 +0200, Christoph Hellwig wrote: >> this is the third and last major series to convert settings to >> queue_limits for this merge window. After a bunch of prep patches to >> get various drivers in shape, it moves all the queue_

Re: move features flags into queue_limits v2

On Mon, 17 Jun 2024 08:04:27 +0200, Christoph Hellwig wrote: > this is the third and last major series to convert settings to > queue_limits for this merge window. After a bunch of prep patches to > get various drivers in shape, it moves all the queue_flags that specify > driver controlled featu

Re: MISRA C Rule 5.3 violation - shadowing in mctelem.c

On 19.06.2024 15:23, Nicola Vetrini wrote: > I was looking at the shadowing due to the struct identifier and the > local variables "mctctl" in x86/cpu/mcheck/mctelem.c (see [1], the > second report). This kind of shadowing seems very intentional, and the > initial naive approach I devised was to

MISRA C Rule 5.3 violation - shadowing in mctelem.c

Hi all, I was looking at the shadowing due to the struct identifier and the local variables "mctctl" in x86/cpu/mcheck/mctelem.c (see [1], the second report). This kind of shadowing seems very intentional, and the initial naive approach I devised was to simply rename the local variables. This

Re: [PATCH] tools/libs/light: Fix nic->vlan memory allocation

On Mon, May 20, 2024 at 01:08:03PM -0400, Jason Andryuk wrote: > On 2024-05-20 12:44, Leigh Brown wrote: > > After the following commit: > > 3bc14e4fa4b9 ("tools/libs/light: Add vlan field to libxl_device_nic") > > xl list -l aborts with a double free error if a domain has at least > > one vif defi

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

On 19/06/2024 13:06, Michal Orzel wrote: Hi Julien, On 19/06/2024 13:55, Julien Grall wrote: Hi Michal, On 19/06/2024 07:46, Michal Orzel wrote: Building Xen with CONFIG_STATIC_SHM=y results in a build failure: arch/arm/static-shmem.c: In function 'process_shm': arch/arm/static-shmem.c:

Re: [PATCH for-4.19] hotplug: Restore block-tap phy compatibility

On 16.05.2024 15:52, Jason Andryuk wrote: > On 2024-05-16 03:41, Jan Beulich wrote: >> On 16.05.2024 04:22, Jason Andryuk wrote: >>> From: Jason Andryuk >>> >>> From: Jason Andryuk >> >> Two identical From: (also in another patch of yours, while in yet another one >> you have two _different_ ones

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi Julien, On 19/06/2024 13:55, Julien Grall wrote: > > > Hi Michal, > > On 19/06/2024 07:46, Michal Orzel wrote: >> Building Xen with CONFIG_STATIC_SHM=y results in a build failure: >> >> arch/arm/static-shmem.c: In function 'process_shm': >> arch/arm/static-shmem.c:327:41: error: 'gbase' may

[linux-linus test] 186406: tolerable FAIL - PUSHED

flight 186406 linux-linus real [real] flight 186410 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186406/ http://logs.test-lab.xenproject.org/osstest/logs/186410/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-

Re: [PATCH] loadpolicy: Verifies memory allocation during policy loading

On 27.05.2024 14:54, ysk...@gmail.com wrote: > --- a/tools/flask/utils/loadpolicy.c > +++ b/tools/flask/utils/loadpolicy.c > @@ -58,6 +58,11 @@ int main (int argCnt, const char *args[]) > } > > polMemCp = malloc(info.st_size); > +if (!polMemCp) { > +fprintf(stderr, "Error oc

Re: [PATCH for-4.19?] tools/libs/light: Fix nic->vlan memory allocation

On 20.05.2024 19:08, Jason Andryuk wrote: > On 2024-05-20 12:44, Leigh Brown wrote: >> After the following commit: >> 3bc14e4fa4b9 ("tools/libs/light: Add vlan field to libxl_device_nic") >> xl list -l aborts with a double free error if a domain has at least >> one vif defined: >> >>$ sudo xl l

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi Michal, On 19/06/2024 07:46, Michal Orzel wrote: Building Xen with CONFIG_STATIC_SHM=y results in a build failure: arch/arm/static-shmem.c: In function 'process_shm': arch/arm/static-shmem.c:327:41: error: 'gbase' may be used uninitialized [-Werror=maybe-uninitialized] 327 | if (

Re: [PATCH for-4.19 v4] x86/irq: forward pending interrupts to new destination in fixup_irqs()

On 19.06.2024 11:58, Roger Pau Monne wrote: > fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given > the CPU is to become offline, the normal migration logic used by Xen where the > vector in the previous target(s) is left configured until the interrupt is > received on the

Re: [PATCH for-4.19 v4.5 2/7] x86/xstate: Cross-check dynamic XSTATE sizes at boot

On 19.06.2024 12:46, Andrew Cooper wrote: > Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for > every call. This is expensive, being used for domain create/migrate, as well > as to service certain guest CPUID instructions. > > Instead, arrange to check the sizes once

Re: [PATCH v4 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

Hi Stefano, On 19/06/2024 01:37, Stefano Stabellini wrote: On Mon, 27 May 2024, Oleksii K. wrote: I don't think it is a big problem if this is not merged for the code freeze as this is technically a bug fix. Agree, this is not a problem as it is still looks to me as a bug fix. ~ Oleksii Hi

Re: [XEN PATCH v2] xen: add explicit comment to identify notifier patterns

On 19.06.2024 13:21, Julien Grall wrote: > > > On 19/06/2024 12:17, Julien Grall wrote: >> Hi Federico, >> >> On 19/06/2024 10:29, Federico Serafini wrote: >>> MISRA C Rule 16.4 states that every `switch' statement shall have a >>> `default' label" and a statement or a comment prior to the >>> te

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi Julein, On 19/06/2024 13:37, Julien Grall wrote: > > > Hi, > > On 19/06/2024 12:19, Oleksii K. wrote: >> Hi, >> On Wed, 2024-06-19 at 09:02 +, Bertrand Marquis wrote: >>> Hi, >>> >>> Adding Oleksii for Release ack. >>> >>> Cheers >>> Bertrand >>> On 19 Jun 2024, at 08:46, Michal Orz

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi, On 19/06/2024 12:19, Oleksii K. wrote: Hi, On Wed, 2024-06-19 at 09:02 +, Bertrand Marquis wrote: Hi, Adding Oleksii for Release ack. Cheers Bertrand On 19 Jun 2024, at 08:46, Michal Orzel wrote: Building Xen with CONFIG_STATIC_SHM=y results in a build failure: arch/arm/static-sh

Re: [PATCH for-4.19 v4 0/7] x86/xstate: Fixes to size calculations

On Mon, 2024-06-17 at 18:39 +0100, Andrew Cooper wrote: > Only minor changes in v4 vs v3.  See patches for details. > > The end result has been tested across the entire XenServer hardware > lab.  This > found several false assupmtion about how the dynamic sizes behave. Release-Acked-by: Oleksii Ku

Re: [XEN PATCH v2] xen: add explicit comment to identify notifier patterns

On 19/06/2024 12:17, Julien Grall wrote: Hi Federico, On 19/06/2024 10:29, Federico Serafini wrote: MISRA C Rule 16.4 states that every `switch' statement shall have a `default' label" and a statement or a comment prior to the terminating break statement. This patch addresses some violation

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi, On Wed, 2024-06-19 at 09:02 +, Bertrand Marquis wrote: > Hi, > > Adding Oleksii for Release ack. > > Cheers > Bertrand > > > On 19 Jun 2024, at 08:46, Michal Orzel > > wrote: > > > > Building Xen with CONFIG_STATIC_SHM=y results in a build failure: > > > > arch/arm/static-shmem.c: In

Re: [XEN PATCH v2] xen: add explicit comment to identify notifier patterns

Hi Federico, On 19/06/2024 10:29, Federico Serafini wrote: MISRA C Rule 16.4 states that every `switch' statement shall have a `default' label" and a statement or a comment prior to the terminating break statement. This patch addresses some violations of the rule related to the "notifier patter

[PATCH for-4.19 v4.5 2/7] x86/xstate: Cross-check dynamic XSTATE sizes at boot

Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for every call. This is expensive, being used for domain create/migrate, as well as to service certain guest CPUID instructions. Instead, arrange to check the sizes once at boot. See the code comments for details. Right

[PATCH v2] x86/xen/time: Reduce Xen timer tick

Current timer tick is causing some deadline to fail. The current high value constant was probably due to an old bug in the Xen timer implementation causing errors if the deadline was in the future. This was fixed in Xen commit: 19c6cbd90965 xen/vcpu: ignore VCPU_SSHOTTMR_future Usage of VCPU_SSHO

Re: [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 2024/6/19 17:49, Jan Beulich wrote: > On 19.06.2024 10:51, Chen, Jiqian wrote: >> On 2024/6/19 16:06, Jan Beulich wrote: >>> On 19.06.2024 09:53, Chen, Jiqian wrote: On 2024/6/18 16:55, Jan Beulich wrote: > On 18.06.2024 08:57, Chen, Jiqian wrote: >> On 2024/6/17 22:52, Jan Beulich

[PATCH for-4.19 v4] x86/irq: forward pending interrupts to new destination in fixup_irqs()

fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given the CPU is to become offline, the normal migration logic used by Xen where the vector in the previous target(s) is left configured until the interrupt is received on the new destination is not suitable. Instead attempt to

Re: [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 19.06.2024 10:51, Chen, Jiqian wrote: > On 2024/6/19 16:06, Jan Beulich wrote: >> On 19.06.2024 09:53, Chen, Jiqian wrote: >>> On 2024/6/18 16:55, Jan Beulich wrote: On 18.06.2024 08:57, Chen, Jiqian wrote: > On 2024/6/17 22:52, Jan Beulich wrote: >> On 17.06.2024 11:00, Jiqian Chen

[XEN PATCH v2] xen: add explicit comment to identify notifier patterns

MISRA C Rule 16.4 states that every `switch' statement shall have a `default' label" and a statement or a comment prior to the terminating break statement. This patch addresses some violations of the rule related to the "notifier pattern": a frequently-used pattern whereby only a few values are ha

Re: [PATCH v3 3/3] x86/irq: forward pending interrupts to new destination in fixup_irqs()

On 19.06.2024 10:32, Roger Pau Monné wrote: > On Wed, Jun 19, 2024 at 09:24:41AM +0200, Jan Beulich wrote: >> On 19.06.2024 09:05, Roger Pau Monné wrote: >>> On Tue, Jun 18, 2024 at 06:30:22PM +0200, Jan Beulich wrote: On 18.06.2024 16:50, Roger Pau Monné wrote: > On Tue, Jun 18, 2024 at 0

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi, Adding Oleksii for Release ack. Cheers Bertrand > On 19 Jun 2024, at 08:46, Michal Orzel wrote: > > Building Xen with CONFIG_STATIC_SHM=y results in a build failure: > > arch/arm/static-shmem.c: In function 'process_shm': > arch/arm/static-shmem.c:327:41: error: 'gbase' may be used uninit

Re: [PATCH for-4.19] xen/arm: static-shmem: fix "gbase/pbase used uninitialized" build failure

Hi Michal, > On 19 Jun 2024, at 08:46, Michal Orzel wrote: > > Building Xen with CONFIG_STATIC_SHM=y results in a build failure: > > arch/arm/static-shmem.c: In function 'process_shm': > arch/arm/static-shmem.c:327:41: error: 'gbase' may be used uninitialized > [-Werror=maybe-uninitialized] >

Re: [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 2024/6/19 16:06, Jan Beulich wrote: > On 19.06.2024 09:53, Chen, Jiqian wrote: >> On 2024/6/18 16:55, Jan Beulich wrote: >>> On 18.06.2024 08:57, Chen, Jiqian wrote: On 2024/6/17 22:52, Jan Beulich wrote: > On 17.06.2024 11:00, Jiqian Chen wrote: >> The gsi of a passthrough device m

Re: [PATCH v3 3/3] x86/irq: forward pending interrupts to new destination in fixup_irqs()

On Wed, Jun 19, 2024 at 09:24:41AM +0200, Jan Beulich wrote: > On 19.06.2024 09:05, Roger Pau Monné wrote: > > On Tue, Jun 18, 2024 at 06:30:22PM +0200, Jan Beulich wrote: > >> On 18.06.2024 16:50, Roger Pau Monné wrote: > >>> On Tue, Jun 18, 2024 at 04:34:50PM +0200, Jan Beulich wrote: > On 1

Re: [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 19.06.2024 09:53, Chen, Jiqian wrote: > On 2024/6/18 16:55, Jan Beulich wrote: >> On 18.06.2024 08:57, Chen, Jiqian wrote: >>> On 2024/6/17 22:52, Jan Beulich wrote: On 17.06.2024 11:00, Jiqian Chen wrote: > The gsi of a passthrough device must be configured for it to be > able to b

Re: [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 2024/6/18 16:55, Jan Beulich wrote: > On 18.06.2024 08:57, Chen, Jiqian wrote: >> On 2024/6/17 22:52, Jan Beulich wrote: >>> On 17.06.2024 11:00, Jiqian Chen wrote: The gsi of a passthrough device must be configured for it to be able to be mapped into a hvm domU. But When dom0 is

Re: [PATCH] AMD/IOMMU: Improve register_iommu_exclusion_range()

On 19.06.2024 09:45, Jan Beulich wrote: > On 18.06.2024 20:31, Andrew Cooper wrote: >> I've finally found the bit in the AMD IOMMU spec which says 64bit accesses >> are >> permitted: >> >> 3.4 IOMMU MMIO Registers: >> >> Software access to IOMMU registers may not be larger than 64 bits. Access

Re: [PATCH] AMD/IOMMU: Improve register_iommu_exclusion_range()

On 18.06.2024 20:31, Andrew Cooper wrote: > * Use 64bit accesses instead of 32bit accesses > * Simplify the constant names > * Pull base into a local variable to avoid it being reloaded because of the >memory clobber in writeq(). > > No functional change. > > Signed-off-by: Andrew Cooper

[ovmf test] 186408: all pass - PUSHED

flight 186408 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186408/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4d4f56992460c039d0cfe48c394c2e07aecf1d22 baseline version: ovmf 26a30abdd0f7fe5a9d242

Re: Design session notes: GPU acceleration in Xen

Am 18.06.24 um 16:12 schrieb Demi Marie Obenour: On Tue, Jun 18, 2024 at 08:33:38AM +0200, Christian König wrote: > Am 18.06.24 um 02:57 schrieb Demi Marie Obenour: >> On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki >> wrote: >>> On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roge

Re: [PATCH v3 3/3] x86/irq: forward pending interrupts to new destination in fixup_irqs()

On 19.06.2024 09:05, Roger Pau Monné wrote: > On Tue, Jun 18, 2024 at 06:30:22PM +0200, Jan Beulich wrote: >> On 18.06.2024 16:50, Roger Pau Monné wrote: >>> On Tue, Jun 18, 2024 at 04:34:50PM +0200, Jan Beulich wrote: On 18.06.2024 13:30, Roger Pau Monné wrote: > On Mon, Jun 17, 2024 at 0

Re: [PATCH for-4.19] xen/irq: Address MISRA Rule 8.3 violation

On Tue, 2024-06-18 at 14:00 +0100, Andrew Cooper wrote: > When centralising irq_ack_none(), different architectures had > different names > for the parameter of irq_ack_none().  As it's type is struct irq_desc > *, it > should be named desc.  Make this consistent. > > No functional change. > > Fi

Re: [PATCH for-4.19] avoid UB in guest handle arithmetic

On Tue, 2024-06-18 at 14:24 +0100, Andrew Cooper wrote: > On 19/03/2024 1:26 pm, Jan Beulich wrote: > > At least XENMEM_memory_exchange can have huge values passed in the > > nr_extents and nr_exchanged fields. Adding such values to pointers > > can > > overflow, resulting in UB. Cast respective po

Re: [PATCH v3 3/3] x86/irq: forward pending interrupts to new destination in fixup_irqs()

On Tue, Jun 18, 2024 at 06:30:22PM +0200, Jan Beulich wrote: > On 18.06.2024 16:50, Roger Pau Monné wrote: > > On Tue, Jun 18, 2024 at 04:34:50PM +0200, Jan Beulich wrote: > >> On 18.06.2024 13:30, Roger Pau Monné wrote: > >>> On Mon, Jun 17, 2024 at 03:41:12PM +0200, Jan Beulich wrote: > On 1

Re: [XEN PATCH v10 1/5] xen/vpci: Clear all vpci status of device

On 19.06.2024 05:39, Chen, Jiqian wrote: > On 2024/6/18 16:33, Jan Beulich wrote: >> On 18.06.2024 08:25, Chen, Jiqian wrote: >>> On 2024/6/17 22:17, Jan Beulich wrote: On 17.06.2024 11:00, Jiqian Chen wrote: > --- a/xen/drivers/pci/physdev.c > +++ b/xen/drivers/pci/physdev.c > @@