flight 186328 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186328/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186322
test-amd64-amd64-xl-qemut-win7-amd64
On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:17:38PM +0200, Jan Beulich wrote:
> >> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
> >> access to actual MMIO space should not generally
Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
this bit is set by the BIOS then CPUID evaluation does not work when
data from any leaf greater than two is needed; early_cpu_init() in
particular wants to collect leaf 7 data.
Cure this by unlocking CPUID right before evaluating
On 13/06/24 10:16, Jan Beulich wrote:
On 13.06.2024 08:38, 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
---
On 12.06.2024 17:36, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:42:58PM +0200, Jan Beulich wrote:
>> On 12.06.2024 12:39, Roger Pau Monné wrote:
>>> On Tue, Jun 11, 2024 at 03:18:32PM +0200, Jan Beulich wrote:
On 10.06.2024 16:20, Roger Pau Monne wrote:
> Currently there's logic i
On 13.06.2024 08:38, 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
> ---
> The v1 of this patch did not rece
Update ECLAIR configuration to deviate some cases where not using
the return value of a function is not dangerous.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra/deviations.rst| 11 +++
2 files changed,
On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote:
> > + if (sdkp->device->type == TYPE_ZBC)
>
> Nit: use sd_is_zoned() here ?
Actually - is there much in even keeping sd_is_zoned now that the
host aware support is removed? Just open coding the type check isn't
any more code, and
On 2024-06-12 12:36, Jan Beulich wrote:
On 12.06.2024 11:52, Nicola Vetrini wrote:
On 2024-06-12 11:19, Jan Beulich wrote:
On 11.06.2024 17:53, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". There
On 13.06.2024 11:07, Federico Serafini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -364,6 +364,17 @@ Deviations related to MISRA C:2012 Rules:
> by `stdarg.h`.
> - Tagged as `deliberate` for ECLAIR.
>
> + * - R17.7
> + - Not using the return
On 13/06/24 12:08, Jan Beulich wrote:
On 13.06.2024 11:07, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -364,6 +364,17 @@ Deviations related to MISRA C:2012 Rules:
by `stdarg.h`.
- Tagged as `deliberate` for ECLAIR.
+ * - R17.7
On 13/06/24 12:03, Jan Beulich wrote:
On 13.06.2024 11:02, Federico Serafini wrote:
On 13/06/24 10:16, Jan Beulich wrote:
On 13.06.2024 08:38, Federico Serafini wrote:
+ * - R16.3
+ - Switch clauses ending with a do-while-false which, in turn, ends with an
Maybe more precisely "the bod
On 24.05.2024 14:31, Vaishali Thakkar wrote:
> --- a/xen/arch/x86/hvm/asid.c
> +++ b/xen/arch/x86/hvm/asid.c
> @@ -27,8 +27,8 @@ boolean_param("asid", opt_asid_enabled);
> * the TLB.
> *
> * Sketch of the Implementation:
> - *
> - * ASIDs are a CPU-local resource. As preemption of ASIDs is n
On 6/13/2024 3:49 PM, Jan Beulich wrote:
On 23.04.2024 14:59, Teddy Astie wrote:
--- /dev/null
+++ b/docs/designs/iommu-contexts.md
@@ -0,0 +1,373 @@
+# IOMMU context management in Xen
+
+Status: Experimental
+Revision: 0
+
+# Background
+
+The design for *IOMMU paravirtualization for Dom0* [1
On Thu, Jun 13, 2024 at 10:38:35AM +0200, Jan Beulich wrote:
> On 12.06.2024 17:36, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:42:58PM +0200, Jan Beulich wrote:
> >> On 12.06.2024 12:39, Roger Pau Monné wrote:
> >>> On Tue, Jun 11, 2024 at 03:18:32PM +0200, Jan Beulich wrote:
> On 1
Hi,
On 11/06/2024 13:42, Michal Orzel wrote:
We would like this serie to be in Xen 4.19, there was a misunderstanding on our
side because we thought
that since the serie was sent before the last posting date, it could have been
a candidate for merging in the
new release, instead after speaking
On 13.06.2024 13:31, Roger Pau Monné wrote:
> On Thu, Jun 13, 2024 at 10:38:35AM +0200, Jan Beulich wrote:
>> On 12.06.2024 17:36, Roger Pau Monné wrote:
>>> On Wed, Jun 12, 2024 at 03:42:58PM +0200, Jan Beulich wrote:
On 12.06.2024 12:39, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 0
On 13/06/24 12:08, Jan Beulich wrote:
On 13.06.2024 11:07, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -364,6 +364,17 @@ Deviations related to MISRA C:2012 Rules:
by `stdarg.h`.
- Tagged as `deliberate` for ECLAIR.
+ * - R17.7
On 10.06.2024 19:10, Petr Beneš wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -724,16 +724,42 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> return -EINVAL;
> }
>
> -if ( altp2m_mode && nested_virt )
> +if ( altp2m_mo
On 13.06.2024 13:50, Federico Serafini wrote:
> On 13/06/24 12:08, Jan Beulich wrote:
>> On 13.06.2024 11:07, Federico Serafini wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -364,6 +364,17 @@ Deviations related to MISRA C:2012 Rules:
>>> by `stdarg.h
On Sun, 02 Jun 2024 01:26:04 +0200,
li...@treblig.org wrote:
>
> From: "Dr. David Alan Gilbert"
>
> 'alsa_sndif_hw_param' has been unused since the original
> commit 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound
> driver").
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilber
Current IOMMU subsystem has some limitations that make PV-IOMMU practically
impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU
domain", which
also causes complications with quarantine implementation.
Moreover, current IOMMU subsystem is not entirely well-define
Based on docs/designs/iommu-contexts.md, implement the redesigned IOMMU
subsystem.
Signed-off-by Teddy Astie
---
Missing in this RFC
Quarantine implementation is incomplete
Automatic determination of max ctx_no (maximum IOMMU context count) using
on PCI device count.
Automatic determination of
This work has been presented at Xen Summit 2024 during the
IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.
Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).
VFIO support is mandatory for
Introduce a new pv interface to manage the underlying IOMMU and manage contexts
and devices. This interface allows creation of new contexts from Dom0 and
addition of IOMMU mappings using guest PoV.
This interface doesn't allow creation of mappings to other domains.
Signed-off-by Teddy Astie
---
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.
Signed-off-by Teddy Astie
---
docs/designs/pv-iommu.md | 105 +++
1 file changed, 105 in
Port the driver with guidances specified in iommu-contexts.md.
Add a arena-based allocator for allocating a fixed chunk of memory and
split it into 4k pages for use by the IOMMU contexts. This chunk size
is configurable with X86_ARENA_ORDER and dom0-iommu=arena-order=N.
Signed-off-by Teddy Astie
flight 186330 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186330/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186316
test-amd64-amd64-libvirt 15 migrate-s
On 13.06.2024 11:02, Federico Serafini wrote:
> On 13/06/24 10:16, Jan Beulich wrote:
>> On 13.06.2024 08:38, Federico Serafini wrote:
>>> + * - R16.3
>>> + - Switch clauses ending with a do-while-false which, in turn, ends
>>> with an
>>
>> Maybe more precisely "the body of which"?
>
> Wil
On 23.04.2024 14:59, Teddy Astie wrote:
> --- /dev/null
> +++ b/docs/designs/iommu-contexts.md
> @@ -0,0 +1,373 @@
> +# IOMMU context management in Xen
> +
> +Status: Experimental
> +Revision: 0
> +
> +# Background
> +
> +The design for *IOMMU paravirtualization for Dom0* [1] explains that some
>
Hi,
On 11/06/2024 11:36, Oleksii K. wrote:
Hi Bertrand and Julien,
On Tue, 2024-06-11 at 07:09 +, Bertrand Marquis wrote:
Hi Julien and Oleksii,
@Oleksii: Could we consider having this serie merged for next release
?
We can consider including it in Xen 4.19 as it has a low impact on
exis
On Wed, Jun 12, 2024 at 10:55:14AM +, Chen, Jiqian wrote:
> On 2024/6/12 18:34, Jan Beulich wrote:
> > On 12.06.2024 12:12, Chen, Jiqian wrote:
> >> On 2024/6/11 22:39, Jan Beulich wrote:
> >>> On 07.06.2024 10:11, Jiqian Chen wrote:
> +r = xc_domain_gsi_permission(ctx->xch, domid, gsi
On Thu, Jun 13, 2024 at 01:36:55PM +0200, Jan Beulich wrote:
> On 13.06.2024 13:31, Roger Pau Monné wrote:
> > On Thu, Jun 13, 2024 at 10:38:35AM +0200, Jan Beulich wrote:
> >> On 12.06.2024 17:36, Roger Pau Monné wrote:
> >>> On Wed, Jun 12, 2024 at 03:42:58PM +0200, Jan Beulich wrote:
> On 1
On 12.06.2024 14:15, milandjokic1...@gmail.com wrote:
> From: Nikola Jelic
>
> Extended RISC-V xen image with PE/COFF headers,
> in order to support xen boot from popular bootloaders like U-boot.
> Image header is optionally included (with CONFIG_RISCV_EFI) so
> both plain ELF and image with PE/C
Hi Julien,
> On 13 Jun 2024, at 14:44, Julien Grall wrote:
>
> Hi,
>
> On 11/06/2024 11:36, Oleksii K. wrote:
>> Hi Bertrand and Julien,
>> On Tue, 2024-06-11 at 07:09 +, Bertrand Marquis wrote:
>>> Hi Julien and Oleksii,
>>>
>>> @Oleksii: Could we consider having this serie merged for nex
On 13.06.2024 14:55, Roger Pau Monné wrote:
> On Thu, Jun 13, 2024 at 01:36:55PM +0200, Jan Beulich wrote:
>> On 13.06.2024 13:31, Roger Pau Monné wrote:
>>> On Thu, Jun 13, 2024 at 10:38:35AM +0200, Jan Beulich wrote:
On 12.06.2024 17:36, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 0
In the context of Xen, Linux runs as Dom0 and doesn't have access to the
machine IOMMU. Although, a IOMMU is mandatory to use some kernel features
such as VFIO or DMA protection.
In Xen, we added a paravirtualized IOMMU with iommu_op hypercall in order
to allow Dom0 to implement such feature. This
On Wed, Jun 12, 2024 at 05:56:15PM +0200, Roger Pau Monné wrote:
> Right. AFAICT advertising "feature-barrier" and/or
> "feature-flush-cache" could be done based on whether blkback
> understand those commands, not on whether the underlying storage
> supports the equivalent of them.
>
> Worst case
On 13.06.2024 15:50, Teddy Astie wrote:
> @@ -214,6 +215,38 @@ struct xen_add_to_physmap_range {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
>
> +/*
> + * With some legacy devices, certain guest-physical addresses cannot safely
> + * be used for other purposes, e.g. to map gues
On Thu, 2024-06-13 at 10:19 +0200, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
> this bit is set by the BIOS then CPUID evaluation does not work when
> data from any leaf greater than two is needed; early_cpu_init() in
> particular wants to collect leaf
On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> mfn_valid() granularity is (currently) 256Mb. Therefore the start of
> a
> 1Gb page passing the test doesn't necessarily mean all parts of such
> a
> range would also pass. Yet using the result of mfn_to_page() on an
> MFN
> which doesn't pass
On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> For non-present entries EMT, like most other fields, is meaningless
> to
> hardware. Make the logic in ept_set_entry() setting the field (and
> iPAT)
> conditional upon dealing with a present entry, leaving the value at 0
> otherwise. This has
On Thu, Jun 13, 2024 at 10:19:30AM +0200, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
> this bit is set by the BIOS then CPUID evaluation does not work when
> data from any leaf greater than two is needed; early_cpu_init() in
> particular wants to colle
On 31/05/2024 00:59, Andrew Cooper wrote:
> On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
>> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
>> index e01f494b772a..85d56f26537b 100644
>> --- a/tools/include/xenguest.h
>> +++ b/tools/include/xenguest.h
>> @@ -799,15 +799,23 @@ int
On 13.06.2024 17:16, Roger Pau Monné wrote:
> On Thu, Jun 13, 2024 at 10:19:30AM +0200, Jan Beulich wrote:
>> @@ -315,16 +329,7 @@ static void cf_check early_init_intel(st
>> bootsym(trampoline_misc_enable_off) &
>> MSR_IA32_MISC_ENABLE_XD_DISABLE)
>> printk(KERN_INFO "re-ena
On Thu, Jun 13, 2024 at 05:53:02PM +0200, Jan Beulich wrote:
> On 13.06.2024 17:16, Roger Pau Monné wrote:
> > On Thu, Jun 13, 2024 at 10:19:30AM +0200, Jan Beulich wrote:
> >> @@ -315,16 +329,7 @@ static void cf_check early_init_intel(st
> >>bootsym(trampoline_misc_enable_off) &
> >> MSR_
Hi Jan,
On 16/05/2024 08:17, Jan Beulich wrote:
On 15.05.2024 20:25, Elias El Yandouzi wrote:
However, I noticed quite a weird bug while doing some testing. I may
need your expertise to find the root cause.
Looks like you've overflowed the dom0 kernel stack, most likely because
of recurring n
Given the current logic it's possible for ->arch.old_cpu_mask to get out of
sync: if a CPU set in old_cpu_mask is offlined and then onlined
again without old_cpu_mask having been updated the data in the mask will no
longer be accurate, as when brought back online the CPU will no longer have
old_vec
Hello,
The following series aim to fix interrupt handling when doing CPU
plug/unplug operations. Without this series running:
cpus=`xl info max_cpu_id`
while [ 1 ]; do
for i in `seq 1 $cpus`; do
xen-hptool cpu-offline $i;
xen-hptool cpu-online $i;
done
done
Quite quickly
This addresses violations of MISRA C:2012 Rule 7.3 which states as
following: The lowercase character `l' shall not be used in a literal
suffix.
Changed moreover suffixes 'u' in 'U' for better readability next to
the 'L's.
No functional change.
Signed-off-by: Alessandro Zucchelli
---
xen/inclu
flight 186335 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186335/
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
flight 186337 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186337/
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
On 13/06/2024 9:19 am, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
> this bit is set by the BIOS then CPUID evaluation does not work when
> data from any leaf greater than two is needed; early_cpu_init() in
> particular wants to collect leaf 7 data.
>
>
flight 186338 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186338/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 712797cf19acd292bf203522a79e40e7e13d268b
baseline version:
ovmf d3b32dca06b987d721463
Currently there's logic in fixup_irqs() that attempts to prevent
_assign_irq_vector() from failing, as fixup_irqs() is required to evacuate all
interrupts from the CPUs not present in the input mask. The current logic in
fixup_irqs() is incomplete, as it doesn't deal with interrupts that have
move
flight 186332 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186332/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186328
test-amd64-amd64-xl-qemut-win7-amd64
flight 186331 linux-linus real [real]
flight 186339 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186331/
http://logs.test-lab.xenproject.org/osstest/logs/186339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 13.06.2024 18:04, Roger Pau Monné wrote:
> On Thu, Jun 13, 2024 at 05:53:02PM +0200, Jan Beulich wrote:
>> On 13.06.2024 17:16, Roger Pau Monné wrote:
>>> On Thu, Jun 13, 2024 at 10:19:30AM +0200, Jan Beulich wrote:
@@ -315,16 +329,7 @@ static void cf_check early_init_intel(st
b
GPU acceleration requires that pageable host memory be able to be mapped
into a guest. This requires changes to all of the Xen hypervisor, Linux
kernel, and userspace device model.
### Goals
- Allow any userspace pages to be mapped into a guest.
- Support deprivileged operation: this API must
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
Christoph,
> Instead of a separate handler function that leaves no work in the
> interrupt hanler itself, split out a per-request end I/O helper and
^^ handler
> clean up the coding style and variable naming while we're at it.
Reviewed-by: Martin K. Petersen
--
Martin K. Pet
Christoph,
> Discard and Write Zeroes are different operation and implemented
> by different fallocate opcodes for ubd. If one fails the other one
> can work and vice versa.
>
> Split the code to disable the operations in ubd_handler to only
> disable the operation that actually failed.
Review
Christoph,
> Commit 16d80c54ad42 ("rbd: set io_min, io_opt and discard_granularity
> to alloc_size") lowered the io_opt size for rbd from objset_bytes
> which is 4MB for typical setup to alloc_size which is typically 64KB.
>
> The commit mostly talks about discard behavior and does mention io_mi
Christoph,
> The soft max_sectors limit is normally capped by the hardware limits and
> an arbitrary upper limit enforced by the kernel, but can be modified by
> the user. A few drivers want to increase this limit (nbd, rbd) or
> adjust it up or down based on hardware capabilities (sd).
Review
Christoph,
> Don't reset the discard settings to no-op over and over when a user
> writes to the provisioning attribute as that is already the default
> mode for ZBC devices. In hindsight we should have made writing to
> the attribute fail for ZBC devices, but the code has probably been
> aroun
Christoph,
> Add helper to disable discard when it is not supported and use it
> instead of sd_config_discard in the I/O completion handler. This avoids
> touching more fields than required in the I/O completion handler and
> prepares for converting sd to use the atomic queue limits API.
Revie
Christoph,
> Add helper to disable WRITE SAME when it is not supported and use it
> instead of sd_config_write_same in the I/O completion handler. This
> avoids touching more fields than required in the I/O completion
> handler and prepares for converting sd to use the atomic queue limits
> API.
Christoph,
> Fall through to the main call to blk_queue_max_discard_sectors given
> that max_blocks has been initialized to zero above instead of
> duplicating the call.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Split the logic to pick the right discard mode into a little helper
> to prepare for further changes.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> Consolidate setting zone-related queue limits in sd_zbc_read_zones
> instead of splitting them between sd_zbc_revalidate_zones and
> sd_zbc_read_zones, and move the early_zone_information initialization
> in sd_zbc_read_zones above setting up the queue limits.
Reviewed-by: Martin K
Christoph,
> Assign all queue limits through a local queue_limits variable and
> queue_limits_commit_update so that we can't race updating them from
> multiple places, and freeze the queue when updating them so that
> in-progress I/O submissions don't see half-updated limits.
Reviewed-by: Marti
Christoph,
> Assign all queue limits through a local queue_limits variable and
> queue_limits_commit_update so that we can't race updating them from
> multiple places, and free the queue when updating them so that
> in-progress I/O submissions don't see half-updated limits.
Reviewed-by: Martin
Christoph,
> Remove all APIs that are unused now that sd and sr have been converted
> to the atomic queue limits API.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Christoph,
> A few drivers optimistically try to support discard, write zeroes and
> secure erase and disable the features from the I/O completion handler
> if the hardware can't support them. This disable can't be done using
> the atomic queue limits API because the I/O completion handlers can'
On 2024/6/13 20:51, Anthony PERARD wrote:
> On Wed, Jun 12, 2024 at 10:55:14AM +, Chen, Jiqian wrote:
>> On 2024/6/12 18:34, Jan Beulich wrote:
>>> On 12.06.2024 12:12, Chen, Jiqian wrote:
On 2024/6/11 22:39, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> +r =
Hi Daniel,
On 2024/6/11 22:39, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> +case XEN_DOMCTL_gsi_permission:
>> +{
>> +unsigned int gsi = domctl->u.gsi_permission.gsi;
>> +int irq = gsi_2_irq(gsi);
>> +bool allow = domctl->u.gsi_permission.allow
flight 186341 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186341/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186332
test-amd64-amd64-xl-qemut-win7-amd64
flight 186342 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186342/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186314
Tests which did not
On 13.06.2024 18:31, Elias El Yandouzi wrote:
> On 16/05/2024 08:17, Jan Beulich wrote:
>> On 15.05.2024 20:25, Elias El Yandouzi wrote:
>>> However, I noticed quite a weird bug while doing some testing. I may
>>> need your expertise to find the root cause.
>>
>> Looks like you've overflowed the do
On 13.06.2024 18:17, Andrew Cooper wrote:
> On 13/06/2024 9:19 am, Jan Beulich wrote:
>> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
>> this bit is set by the BIOS then CPUID evaluation does not work when
>> data from any leaf greater than two is needed; early_cpu_init() in
Update ECLAIR configuration to deviate some cases where not using
the return value of a function is not dangerous.
Signed-off-by: Federico Serafini
---
Changes in v2:
- do not deviate strlcpy and strlcat.
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra/deviations.rst
On 13.06.2024 20:43, Demi Marie Obenour wrote:
> GPU acceleration requires that pageable host memory be able to be mapped
> into a guest.
I'm sure it was explained in the session, which sadly I couldn't attend.
I've been asking Ray and Xenia the same before, but I'm afraid it still
hasn't become c
On 14.06.2024 05:11, Chen, Jiqian wrote:
> On 2024/6/13 20:51, Anthony PERARD wrote:
>> On Wed, Jun 12, 2024 at 10:55:14AM +, Chen, Jiqian wrote:
>>> On 2024/6/12 18:34, Jan Beulich wrote:
On 12.06.2024 12:12, Chen, Jiqian wrote:
> On 2024/6/11 22:39, Jan Beulich wrote:
>> On 07.06
On 14.06.2024 08:31, Federico Serafini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -413,6 +413,10 @@ explicit comment indicating the fallthrough intention is
> present."
> -config=MC3R1.R17.1,macros+={hide , "^va_(a
On 2024/6/14 14:41, Jan Beulich wrote:
> On 14.06.2024 05:11, Chen, Jiqian wrote:
>> On 2024/6/13 20:51, Anthony PERARD wrote:
>>> On Wed, Jun 12, 2024 at 10:55:14AM +, Chen, Jiqian wrote:
On 2024/6/12 18:34, Jan Beulich wrote:
> On 12.06.2024 12:12, Chen, Jiqian wrote:
>> On 2024/
85 matches
Mail list logo
