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

flight 185976 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/185976/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: Serious AMD-Vi(?) issue

On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote: > > I suspect this is a case of there is some step which is missing from > Xen's IOMMU handling. Perhaps something which Linux does during an early > DMA setup stage, but the current Xen implementation does lazily? > Alternatively

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

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

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 2024/5/10 19:27, Jürgen Groß wrote: > On 10.05.24 12:32, Chen, Jiqian wrote: >> On 2024/5/10 18:21, Jürgen Groß wrote: >>> On 10.05.24 12:13, Chen, Jiqian wrote: On 2024/5/10 17:53, Jürgen Groß wrote: > On 10.05.24 11:06, Chen, Jiqian wrote: >> Hi, >> >> On 2024/5/10 14:46,

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

flight 185973 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/185973/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[PATCH v2 0/4] Guest magic region allocation for 11 Dom0less domUs - Take two

Hi all, This series is trying to fix the reported guest magic region allocation issue for 11 Dom0less domUs, an error message can seen from the init-dom0less application on 1:1 direct-mapped Dom0less DomUs: ``` Allocating magic pages memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1 Error on

[PATCH v2 4/4] docs/features/dom0less: Update the late XenStore init protocol

With the new allocation strategy of Dom0less DomUs magic page region, update the documentation of the late XenStore init protocol accordingly. Signed-off-by: Henry Wang --- v2: - New patch. --- docs/features/dom0less.pandoc | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff

[PATCH v2 2/4] xen/arm: Add new HVM_PARAM_HV_RSRV_{BASE_PFN,SIZE} keys in HVMOP

For use cases such as Dom0less PV drivers, a mechanism to communicate Dom0less DomU's static data with the runtime control plane (Dom0) is needed. Since on Arm HVMOP is already the existing approach to address such use cases (for example the allocation of HVM_PARAM_CALLBACK_IRQ), add new HVMOP

[PATCH v2 3/4] tools/init-dom0less: Avoid hardcoding GUEST_MAGIC_BASE

Currently the GUEST_MAGIC_BASE in the init-dom0less application is hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less DomUs. Since the guest magic region is now allocated from the hypervisor, instead of hardcoding the guest magic pages region, use xc_hvm_param_get() to get the

[PATCH v2 1/4] xen/arm: Alloc hypervisor reserved pages as magic pages for Dom0less DomUs

There are use cases (for example using the PV driver) in Dom0less setup that require Dom0less DomUs start immediately with Dom0, but initialize XenStore later after Dom0's successful boot and call to the init-dom0less application. An error message can seen from the init-dom0less application on

[PATCH] fix Rule 10.2 violation

Change opt_conswitch to char to fix a violation of Rule 10.2. Signed-off-by: Stefano Stabellini diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2c363d9c1d..3a3a97bcbe 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -49,7 +49,7 @@

[PATCH] docs/misra: replace R13.1 with R13.2

After looking closely at the R13.1 violations and potential fixes or deviations, upon further reflection and discussions, we realized that it is R13.2, limited to initializers list, that we want to comply with. Link: https://marc.info/?l=xen-devel=170751643325805 Signed-off-by: Stefano Stabellini

Re: [PATCH v3] docs/misra: add R21.6 R21.9 R21.10 R21.14 R21.15 R21.16

On 10/05/2024 10:48 pm, Andrew Cooper wrote: > On 26/04/2024 10:36 pm, Stefano Stabellini wrote: >> Signed-off-by: Stefano Stabellini >> --- >> >> Changes in v3: >> - add explanation in footnote >> - remove comment from 21.14, 21.15, 21.16 >> >> docs/misra/rules.rst | 42

[PATCH 3/4] tools/xen-cpuid: Use automatically generated feature names

From: Roger Pau Monné Have gen-cpuid.py write out INIT_FEATURE_VAL_TO_NAME, derived from the same data source as INIT_FEATURE_NAME_TO_VAL, although both aliases of common_1d are needed. In xen-cpuid.c, have the compiler pad both leaf_info[] and feature_names[] if necessary. This avoids needing

[PATCH 1/4] x86/gen-cpuid: Minor cleanup

Rename INIT_FEATURE_NAMES to INIT_FEATURE_NAME_TO_VAL as we're about to gain a inverse mapping of the same thing. Use dict.items() unconditionally. iteritems() is a marginal perf optimsiation for Python2 only, and simply not worth the effort on a script this small. Signed-off-by: Andrew Cooper

[PATCH 4/4] tools/xen-cpuid: Drop old names

From: Roger Pau Monné Not used any more. Split out of previous patch to aid legibility. Signed-off-by: Roger Pau Monné Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné v3: * New (split out) --- tools/misc/xen-cpuid.c | 287 +++-- 1

[PATCH v3 0/4] x86/xen-cpuid: Use automagically generated names

I may have got a bit carried away tweaking Roger's v2. The major bugfix is getting both alias of common_1d, which matters when using xen-cpuid on AMD hardware. Andrew Cooper (1): x86/gen-cpuid: Minor cleanup Roger Pau Monné (3): tools/xen-cpuid: Rename decodes[] to leaf_info[]

[PATCH 2/4] tools/xen-cpuid: Rename decodes[] to leaf_info[]

From: Roger Pau Monné Split out of subsequent patch to aid legibility. Signed-off-by: Roger Pau Monné Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné v3: * New (split out) --- tools/misc/xen-cpuid.c | 15 +++ 1 file changed, 7 insertions(+), 8

Re: [PATCH] libxl: Fix handling XenStore errors in device creation

On Fri, May 10, 2024 at 07:00:49PM +0100, Andrew Cooper wrote: > On 10/05/2024 9:05 am, Jürgen Groß wrote: > > On 27.04.24 04:17, Demi Marie Obenour wrote: > >> If xenstored runs out of memory it is possible for it to fail operations > >> that should succeed.  libxl wasn't robust against this, and

Re: [PATCH v3] docs/misra: add R21.6 R21.9 R21.10 R21.14 R21.15 R21.16

On 26/04/2024 10:36 pm, Stefano Stabellini wrote: > Signed-off-by: Stefano Stabellini > --- > > Changes in v3: > - add explanation in footnote > - remove comment from 21.14, 21.15, 21.16 > > docs/misra/rules.rst | 42 ++ > 1 file changed, 42 insertions(+)

Re: [PATCH 3/7] xen/p2m: put reference for superpage

Hi Roger, On 09/05/2024 13:58, Roger Pau Monné wrote: On Thu, May 09, 2024 at 01:12:00PM +0100, Julien Grall wrote: Hi, On 09/05/2024 12:28, Roger Pau Monné wrote: On Thu, May 09, 2024 at 10:50:56AM +0100, Julien Grall wrote: On 09/05/2024 09:13, Roger Pau Monné wrote: On Wed, May 08,

Re: [PATCH] x86/io: Don't cast away constness in read{b..q}()

On Fri, 10 May 2024, Andrew Cooper wrote: > Addresses various MISRA R11.8 violations. > > Signed-off-by: Andrew Cooper Reviewed-by: Stefano Stabellini > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Marek Marczykowski-Górecki > CC: Stefano Stabellini > CC: Nicola Vetrini > CC:

Re: [PATCH v7] xen: allow up to 16383 cpus

On 10/05/2024 22:11, Andrew Cooper wrote: On 10/05/2024 10:08 pm, Julien Grall wrote: Hi Juergen, On 10/05/2024 15:16, Juergen Gross wrote: With lock handling now allowing up to 16384 cpus (spinlocks can handle 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for the

Re: [PATCH v7] xen: allow up to 16383 cpus

On 10/05/2024 10:08 pm, Julien Grall wrote: > Hi Juergen, > > On 10/05/2024 15:16, Juergen Gross wrote: >> With lock handling now allowing up to 16384 cpus (spinlocks can handle >> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for >> the number of cpus to be configured to

Re: [PATCH v7] xen: allow up to 16383 cpus

Hi Juergen, On 10/05/2024 15:16, Juergen Gross wrote: With lock handling now allowing up to 16384 cpus (spinlocks can handle 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for the number of cpus to be configured to 16383. The new limit is imposed by

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

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

Re: [XEN PATCH v3] arm/mem_access: add conditional build of mem_access.c

Hi, On 10/05/2024 13:32, Alessandro Zucchelli wrote: In order to comply to MISRA C:2012 Rule 8.4 for ARM the following changes are done: revert preprocessor conditional changes to xen/mem_access.h which had it build unconditionally, add conditional build for xen/mem_access.c I am afraid, I

[PATCH] x86/io: Don't cast away constness in read{b..q}()

Addresses various MISRA R11.8 violations. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Marek Marczykowski-Górecki CC: Stefano Stabellini CC: Nicola Vetrini CC: consult...@bugseng.com --- xen/arch/x86/include/asm/io.h | 8 1 file changed, 4

Re: [PATCH] xen/build: Use -Wflex-array-member-not-at-end when available

On Fri, 10 May 2024, Andrew Cooper wrote: > This option is new in GCC-14, and maps to MISRA Rule 1.1. The codebase is > clean to it, and Eclair is blocking. > > Signed-off-by: Andrew Cooper Acked-by: Stefano Stabellini > --- > CC: Stefano Stabellini > CC: Nicola Vetrini > CC: Simone

[PATCH] xen/build: Use -Wflex-array-member-not-at-end when available

This option is new in GCC-14, and maps to MISRA Rule 1.1. The codebase is clean to it, and Eclair is blocking. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Nicola Vetrini CC: Simone Ballarin CC: consult...@bugseng.com I really ought to have posted this before we regressed

Re: [XEN PATCH] automation/eclair_analysis: tag MISRA C Rule 1.1 as clean

On 10/05/2024 7:03 pm, Nicola Vetrini wrote: > Tag the rule as clean, as there are no more violations in the codebase since > 93c27d54dd23 ("xen/arm: Fix MISRA regression on R1.1, > flexible array member not at the end"). > > Signed-off-by: Nicola Vetrini Acked-by: Andrew Cooper

Re: [PATCH for-4.19 v2] tools/xen-cpuid: switch to use cpu-policy defined names

On 02/05/2024 12:49 pm, Roger Pau Monne wrote: > diff --git a/tools/include/xen-tools/common-macros.h > b/tools/include/xen-tools/common-macros.h > index 07aed92684b5..3e6a66080a4f 100644 > --- a/tools/include/xen-tools/common-macros.h > +++ b/tools/include/xen-tools/common-macros.h > @@ -83,6

[XEN PATCH] automation/eclair_analysis: tag MISRA C Rule 1.1 as clean

Tag the rule as clean, as there are no more violations in the codebase since 93c27d54dd23 ("xen/arm: Fix MISRA regression on R1.1, flexible array member not at the end"). Signed-off-by: Nicola Vetrini --- automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] libxl: Fix handling XenStore errors in device creation

On 10/05/2024 9:05 am, Jürgen Groß wrote: > On 27.04.24 04:17, Demi Marie Obenour wrote: >> If xenstored runs out of memory it is possible for it to fail operations >> that should succeed.  libxl wasn't robust against this, and could fail >> to ensure that the TTY path of a non-initial console was

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

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

Re: [PATCH v2 3/3] x86: detect PIT aliasing on ports other than 0x4[0-3]

On 2023-12-18 09:48, Jan Beulich wrote: ... in order to also deny Dom0 access through the alias ports. Without this it is only giving the impression of denying access to PIT. Unlike for CMOS/RTC, do detection pretty early, to avoid disturbing normal operation later on (even if typically we won't

Re: [PATCH v3 6/9] xen/arm64: bpi: Add missing code symbol annotations

On Tue, May 7, 2024 at 7:37 PM Julien Grall wrote: > > > > On 07/05/2024 17:55, Edgar E. Iglesias wrote: > > On Tue, May 7, 2024 at 11:57 AM Julien Grall wrote: > > Hi Julien, > > Hi Edgar, > > > > > The reason I choose FUNC for the start of the symbol is because these > > symbols contain > >

[libvirt test] 185968: tolerable all pass - PUSHED

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

Re: [PATCH for-4.19] libxl: fix population of the online vCPU bitmap for PVH

On 10/05/2024 1:49 pm, Roger Pau Monne wrote: > libxl passes some information to libacpi to create the ACPI table for a PVH > guest, and among that information it's a bitmap of which vCPUs are online > which can be less than the maximum number of vCPUs assigned to the domain. > > While the

Re: [PATCH v8 2/6] x86/hvm: Allow access to registers on the same page as MSI-X table

On Fri, May 10, 2024 at 05:53:22AM +0200, Marek Marczykowski-Górecki wrote: > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers > on the same page as MSI-X table. Device model (especially one in > stubdomain) cannot really handle those, as direct writes to that page is >

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

flight 185961 xen-unstable real [real] flight 185969 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/185961/ http://logs.test-lab.xenproject.org/osstest/logs/185969/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

[PATCH v7] xen: allow up to 16383 cpus

With lock handling now allowing up to 16384 cpus (spinlocks can handle 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for the number of cpus to be configured to 16383. The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and QINVAL_MAX_ENTRY_NR required to be larger than

Re: [RFC PATCH v2 0/5] Add bridge VLAN support

On Thu, May 9, 2024 at 12:10 PM Leigh Brown wrote: > > Hi Andrew, > > On 2024-05-09 16:53, Andrew Cooper wrote: > > On 08/05/2024 10:38 pm, Leigh Brown wrote: > > This is past the last-post date, so Oleksii will need to decide whether > > he's happy to make an exception for it. > > From my own

Re: [PATCH for-4.19] libxl: fix population of the online vCPU bitmap for PVH

Hi Roger, Thanks for responding and fixing this so quickly. On 2024-05-10 13:49, Roger Pau Monne wrote: libxl passes some information to libacpi to create the ACPI table for a PVH guest, and among that information it's a bitmap of which vCPUs are online which can be less than the maximum

[PATCH for-4.19] libxl: fix population of the online vCPU bitmap for PVH

libxl passes some information to libacpi to create the ACPI table for a PVH guest, and among that information it's a bitmap of which vCPUs are online which can be less than the maximum number of vCPUs assigned to the domain. While the population of the bitmap is done correctly for HVM based on

[XEN PATCH v3] arm/mem_access: add conditional build of mem_access.c

In order to comply to MISRA C:2012 Rule 8.4 for ARM the following changes are done: revert preprocessor conditional changes to xen/mem_access.h which had it build unconditionally, add conditional build for xen/mem_access.c as well and provide stubs in asm/mem_access.h for the users of this header.

Re: [PATCH for-4.19 v2 3/3] xen/x86: remove foreign mappings from the p2m on teardown

On Wed, May 08, 2024 at 01:23:23PM +0200, Roger Pau Monne wrote: > Iterate over the p2m up to the maximum recorded gfn and remove any foreign > mappings, in order to drop the underlying page references and thus don't keep > extra page references if a domain is destroyed while still having foreign

Re: Domain Birth Time

On Fri, May 10, 2024 at 4:10 AM James Dingwall wrote: > Hi, > > We've added a feature to Xen 4.15 such that `xl uptime -b` reports the > birth > time of the domain (i.e. a value preserved across migrations). If this > would > be of wider interest I can try porting this to a more recent release

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 10.05.24 12:32, Chen, Jiqian wrote: On 2024/5/10 18:21, Jürgen Groß wrote: On 10.05.24 12:13, Chen, Jiqian wrote: On 2024/5/10 17:53, Jürgen Groß wrote: On 10.05.24 11:06, Chen, Jiqian wrote: Hi, On 2024/5/10 14:46, Jürgen Groß wrote: On 19.04.24 05:36, Jiqian Chen wrote: + +   

Re: [PATCH v2 6/7] hw/xen: register legacy backends via xen_backend_init

On 10/5/24 12:49, Philippe Mathieu-Daudé wrote: From: Paolo Bonzini It is okay to register legacy backends in the middle of xen_bus_init(). All that the registration does is record the existence of the backend in xenstore. This makes it possible to remove them from the build without

[PATCH v2 7/7] hw/xen: Register framebuffer backend via xen_backend_init()

Align the framebuffer backend with the other legacy ones, register it via xen_backend_init() when '-vga xenfb' is used. It is safe because MODULE_INIT_XEN_BACKEND is called in xen_bus_realize(), long after CLI processing initialized the vga_interface_type variable. Signed-off-by: Philippe

[PATCH v2 6/7] hw/xen: register legacy backends via xen_backend_init

From: Paolo Bonzini It is okay to register legacy backends in the middle of xen_bus_init(). All that the registration does is record the existence of the backend in xenstore. This makes it possible to remove them from the build without introducing undefined symbols in xen_be_init(). It also

[PATCH v2 5/7] hw/xen: initialize legacy backends from xen_bus_init()

From: Paolo Bonzini Prepare for moving the calls to xen_be_register() under the control of xen_bus_init(), using the normal xen_backend_init() method that is used by the "modern" backends. This requires the xenstore global variable to be initialized, which is done by xen_be_init(). To ensure

[PATCH v2 1/7] hw/xen: Remove declarations left over in 'xen-legacy-backend.h'

'xen_blkdev_ops' was removed in commit 19f87870ba ("xen: remove the legacy 'xen_disk' backend"), 'xen_netdev_ops' in commit 25967ff69f ("hw/xen: update Xen PV NIC to XenDevice model") and 'xen_console_ops' in commit 9b77374690 ("hw/xen: update Xen console to XenDevice model"). Remove them.

[PATCH v2 4/7] hw/xen: Make XenDevOps structures const

Keep XenDevOps structures in .rodata. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen-legacy-backend.h | 8 hw/9pfs/xen-9p-backend.c| 2 +- hw/display/xenfb.c | 4 ++-- hw/usb/xen-usb.c| 4 ++-- 4 files changed, 9

[PATCH v2 3/7] hw/xen: Constify xenstore_be::XenDevOps

XenDevOps @ops is not updated, mark it const. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen-legacy-backend.h | 2 +- hw/xen/xen-legacy-backend.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/hw/xen/xen-legacy-backend.h

[PATCH v2 2/7] hw/xen: Constify XenLegacyDevice::XenDevOps

XenDevOps @ops is not updated, mark it const. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/xen/xen_pvdev.h | 2 +- hw/xen/xen-legacy-backend.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h index

[PATCH v2 0/7] hw/xen: Simplify legacy backends handling

Respin of Paolo's Xen patches from https://lore.kernel.org/qemu-devel/20240509170044.190795-1-pbonz...@redhat.com/ rebased on one of my cleanup branches making backend structures const. Treat xenfb as other backends. Paolo Bonzini (2): hw/xen: initialize legacy backends from xen_bus_init()

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 2024/5/10 18:21, Jürgen Groß wrote: > On 10.05.24 12:13, Chen, Jiqian wrote: >> On 2024/5/10 17:53, Jürgen Groß wrote: >>> On 10.05.24 11:06, Chen, Jiqian wrote: Hi, On 2024/5/10 14:46, Jürgen Groß wrote: > On 19.04.24 05:36, Jiqian Chen wrote: >> + >> +    info->type

Fwd: [ANNOUNCE] Xen Project Summit 2024 Design Sessions

*Our design sessions are now open for Xen Summit! * If you've attended Xen Summit before, you might be familiar with the process. For anyone who hasn't done so before, please follow the instructions below, using the link to create an account . Once you've

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 10.05.24 12:13, Chen, Jiqian wrote: On 2024/5/10 17:53, Jürgen Groß wrote: On 10.05.24 11:06, Chen, Jiqian wrote: Hi, On 2024/5/10 14:46, Jürgen Groß wrote: On 19.04.24 05:36, Jiqian Chen wrote: + +    info->type = IRQT_PIRQ; I am considering whether I need to use a new type(like

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 2024/5/10 17:53, Jürgen Groß wrote: > On 10.05.24 11:06, Chen, Jiqian wrote: >> Hi, >> >> On 2024/5/10 14:46, Jürgen Groß wrote: >>> On 19.04.24 05:36, Jiqian Chen wrote: + +    info->type = IRQT_PIRQ; >> I am considering whether I need to use a new type(like IRQT_GSI) here to >>

Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy configuration and violation

On Tue May 7, 2024 at 4:16 PM UTC, Sean Christopherson wrote: > > If yes, that would indeed require a *lot* of work for something we're not > > sure will be accepted later on. > > Yes and no. The AWS folks are pursuing VSM support in KVM+QEMU, and SVSM > support > is trending toward the paired

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 10.05.24 11:06, Chen, Jiqian wrote: Hi, On 2024/5/10 14:46, Jürgen Groß wrote: On 19.04.24 05:36, Jiqian Chen wrote: + +    info->type = IRQT_PIRQ; I am considering whether I need to use a new type(like IRQT_GSI) here to distinguish with IRQT_PIRQ, because function restore_pirqs will

Re: [PATCH 6/7] xen/arm: Implement the logic for static shared memory from Xen heap

> On 10 May 2024, at 10:32, Michal Orzel wrote: > > Hi Luca, > > On 10/05/2024 11:25, Luca Fancellu wrote: >> >> >>> On 10 May 2024, at 10:17, Michal Orzel wrote: >>> >>> Hi Luca, >>> >>> On 23/04/2024 10:25, Luca Fancellu wrote: This commit implements the logic to have

Re: [PATCH 7/7] xen/docs: Describe static shared memory when host address is not provided

Hi Luca, On 23/04/2024 10:25, Luca Fancellu wrote: > > > From: Penny Zheng > > This commit describe the new scenario where host address is not provided > in "xen,shared-mem" property and a new example is added to the page to > explain in details. > > Take the occasion to fix some typos in

Re: [PATCH 6/7] xen/arm: Implement the logic for static shared memory from Xen heap

Hi Luca, On 10/05/2024 11:25, Luca Fancellu wrote: > > >> On 10 May 2024, at 10:17, Michal Orzel wrote: >> >> Hi Luca, >> >> On 23/04/2024 10:25, Luca Fancellu wrote: >>> >>> >>> This commit implements the logic to have the static shared memory banks >>> from the Xen heap instead of having the

Re: [PATCH 6/7] xen/arm: Implement the logic for static shared memory from Xen heap

> On 10 May 2024, at 10:17, Michal Orzel wrote: > > Hi Luca, > > On 23/04/2024 10:25, Luca Fancellu wrote: >> >> >> This commit implements the logic to have the static shared memory banks >> from the Xen heap instead of having the host physical address passed from >> the user. >> >> When

Re: [PATCH 6/7] xen/arm: Implement the logic for static shared memory from Xen heap

Hi Luca, On 23/04/2024 10:25, Luca Fancellu wrote: > > > This commit implements the logic to have the static shared memory banks > from the Xen heap instead of having the host physical address passed from > the user. > > When the host physical address is not supplied, the physical memory is >

Domain Birth Time

Hi, We've added a feature to Xen 4.15 such that `xl uptime -b` reports the birth time of the domain (i.e. a value preserved across migrations). If this would be of wider interest I can try porting this to a more recent release and submitting it for review. Regards, James

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

Hi, On 2024/5/10 14:46, Jürgen Groß wrote: > On 19.04.24 05:36, 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

Re: [PATCH 02/15] xen/arm/gic: Enable interrupt assignment to running VM

Hi, On 09/05/2024 16:31, Henry Wang wrote: On 5/9/2024 4:46 AM, Julien Grall wrote: Hi Henry, [...] we have 3 possible states which can be read from LR for this case : active, pending, pending and active. - I don't think we can do anything about the active state, so we should return -EBUSY

Re: [RFC KERNEL PATCH v6 2/3] xen/pvh: Setup gsi for passthrough device

Hi, On 2024/5/10 15:48, Juergen Gross wrote: > On 19.04.24 05:36, Jiqian Chen wrote: >> In PVH dom0, the gsis don't get registered, but the gsi of >> a passthrough device must be configured for it to be able to be >> mapped into a domU. >> >> When assign a device to passthrough, proactively setup

Re: [PATCH 1/5] xen: sync elfnote.h from xen tree

On 10.04.24 21:48, Jason Andryuk wrote: Sync Xen's elfnote.h header from xen.git to pull in the XEN_ELFNOTE_PHYS32_RELOC define. xen commit dfc9fab00378 ("x86/PVH: Support relocatable dom0 kernels") This is a copy except for the removal of the emacs editor config at the end of the file.

Feature freeze date for Xen 4.19 is 17.05.2024

Hi all, I would like to remind that the feature freeze date for Xen 4.19 is May 17, 2024. If you want your features to be included for the release, please make sure they are committed by May 17, 2024. Have a nice day! Best regards, Oleksii

Re: [PATCH] libxl: Fix handling XenStore errors in device creation

On 27.04.24 04:17, Demi Marie Obenour wrote: If xenstored runs out of memory it is possible for it to fail operations that should succeed. libxl wasn't robust against this, and could fail to ensure that the TTY path of a non-initial console was created and read-only for guests. This doesn't

Re: [RFC KERNEL PATCH v6 2/3] xen/pvh: Setup gsi for passthrough device

On 19.04.24 05:36, Jiqian Chen wrote: In PVH dom0, the gsis don't get registered, but the gsi of a passthrough device must be configured for it to be able to be mapped into a domU. When assign a device to passthrough, proactively setup the gsi of the device during that process.

Re: [PATCH 1/3] xen/arm/dom0less-build: Alloc magic pages for Dom0less DomUs from hypervisor

Hi Michal, Thanks very much for taking a look! On 5/10/2024 3:37 PM, Michal Orzel wrote: Hi Henry, On 26/04/2024 05:14, Henry Wang wrote: There are use cases (for example using the PV driver) in Dom0less setup that require Dom0less DomUs start immediately with Dom0, but initialize XenStore

Re: [PATCH 1/3] xen/arm/dom0less-build: Alloc magic pages for Dom0less DomUs from hypervisor

Hi Henry, On 26/04/2024 05:14, Henry Wang wrote: > There are use cases (for example using the PV driver) in Dom0less > setup that require Dom0less DomUs start immediately with Dom0, but > initialize XenStore later after Dom0's successful boot and call to > the init-dom0less application. > > An

Re: [PATCH v1 1/1] xen/xenbus: Use *-y instead of *-objs in Makefile

On 08.05.24 17:26, Andy Shevchenko wrote: *-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Signed-off-by: Andy Shevchenko

Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

On 19.04.24 05:36, 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

Re: [PATCH] xen/x86: add extra pages to unpopulated-alloc if available

On 29.04.24 17:50, Roger Pau Monne wrote: Commit 262fc47ac174 ('xen/balloon: don't use PV mode extra memory for zone device allocations') removed the addition of the extra memory ranges to the unpopulated range allocator, using those only for the balloon driver. This forces the unpopulated

[ovmf test] 185967: all pass - PUSHED

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