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 receive any comments:
https://lists.xenproject.org/archives/html/x
flight 186324 linux-linus real [real]
flight 186329 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186324/
http://logs.test-lab.xenproject.org/osstest/logs/186329/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186322 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186322/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186315
test-amd64-amd64-xl-qemut-win7-amd64
On 11.06.24 21:19, Andrew Morton wrote:
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specif
flight 186320 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186320/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186150
test-amd64-amd64-xl-qemuu-ws16-amd64 19
flight 186323 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186323/
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 Wed, Jun 12, 2024 at 05:00:30PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 12, 2024 at 10:01:18AM +0200, Roger Pau Monné wrote:
> > On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> > > blkfront always had a robust negotiation protocol for detecting a write
> > > cache. St
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 in fixup_irqs() that attempts to prevent
> >>> _
On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > I wonder if you should explicitly mention that if adding the
> > mfn_valid() check was done to ensure all mappings to MMIO are created
> > with effective UC caching attribute it won't be f
On Wed, Jun 12, 2024 at 04:53:14PM +0200, Jan Beulich wrote:
> On 12.06.2024 16:38, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:16:59PM +0200, Jan Beulich wrote:
> >> For non-present entries EMT, like most other fields, is meaningless to
> >> hardware. Make the logic in ept_set_entry() se
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 be restricted to UC
>> only; especially video frame buffer accesses
On 12.06.2024 17:02, Roger Pau Monné wrote:
> We could also add an extra check to exit the loop early if special
> pages have been found but don't match the current loop index, as it's
> all special pages or none.
I was actually considering to make such a change, but then concluded
that in the com
On Wed, Jun 12, 2024 at 04:47:12PM +0200, Jan Beulich wrote:
> On 12.06.2024 16:11, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:16:37PM +0200, Jan Beulich wrote:
> >> mfn_valid() granularity is (currently) 256Mb. Therefore the start of a
> >> 1Gb page passing the test doesn't necessarily
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 be restricted to UC
> only; especially video frame buffer accesses are unduly affected by such
> a restriction.
>
>
On Wed, Jun 12, 2024 at 10:01:18AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> > blkfront always had a robust negotiation protocol for detecting a write
> > cache. Stop simply disabling cache flushes when they fail as that is
> > a grave err
On Tue, 11 Jun 2024 at 07:24, Christoph Hellwig wrote:
>
> Move the cache control settings into the queue_limits so that they
> can be set atomically and all I/O is frozen when changing the
> flags.
>
> Add new features and flags field for the driver set flags, and internal
> (usually sysfs-contro
On 12.06.2024 16:38, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:16:59PM +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
On 12.06.2024 16:11, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:16:37PM +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.
>
> How would suc
On Wed, Jun 12, 2024 at 03:16:59PM +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
On Wed, Jun 12, 2024 at 03:16:37PM +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.
How would such a superpage end up in the EPT?
I would assume this
On 12.06.2024 13:23, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 03:50:42PM +0200, Jan Beulich wrote:
>> On 10.06.2024 16:20, Roger Pau Monne wrote:
>>> @@ -2649,6 +2649,25 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
>>> !cpumask_test_cpu(cpu, &cpu_online_map) &&
>>>
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 in fixup_irqs() that attempts to prevent
>>> _assign_irq_vector() from failing, as fixup_irqs() is required to evacua
mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
access to actual MMIO space should not generally be restricted to UC
only; especially video frame buffer accesses are unduly affected by such
a restriction.
Since, as of ("x86/EPT: avoid marking non-present entries
f
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 two effects for epte_get_entry_emt() which we'll
want to leverage
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 mfn_valid() checking is liable to result in a crash
(the invocation
..., getting in the way of, in particular, PVH Dom0 accessing its video
frame buffer (if it has a console).
While especially the 1st one may not appear to be so, both of the earlier
patches are strictly prereqs to the last one.
1: correct special page checking in epte_get_entry_emt()
2: avoid mar
flight 186316 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186316/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186286
test-amd64-amd64-libvirt 15 migrate-s
On Fri, May 24, 2024 at 03:55:21PM -0700, Stefano Stabellini wrote:
> From: Henry Wang
>
> 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 allocation from init-dom
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/COFF header can now be generated as build
artifacts.
Note that thi
On 12/06/2024 12:45 pm, Jan Beulich wrote:
> On 12.06.2024 13:05, Andrew Cooper wrote:
>> On 12/06/2024 9:44 am, Jan Beulich wrote:
>>> It's hardly ever correct to check for just DOMID_SELF, as guests have
>>> ways to figure out their domain IDs and hence could instead use those as
>>> inputs to re
On 11.06.2024 18:21, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 04:53:22PM +0200, Jan Beulich wrote:
>> On 11.06.2024 15:52, Roger Pau Monné wrote:
>>> On Tue, Jun 11, 2024 at 01:52:58PM +0200, Jan Beulich wrote:
On 11.06.2024 13:08, Roger Pau Monné wrote:
> I really wonder whether X
flight 186319 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186319/
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 12.06.2024 12:52, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 10:44:56AM +0200, Jan Beulich wrote:
>> It's hardly ever correct to check for just DOMID_SELF, as guests have
>> ways to figure out their domain IDs and hence could instead use those as
>> inputs to respective hypercalls. Note, h
On 12.06.2024 13:05, Andrew Cooper wrote:
> On 12/06/2024 9:44 am, Jan Beulich wrote:
>> It's hardly ever correct to check for just DOMID_SELF, as guests have
>> ways to figure out their domain IDs and hence could instead use those as
>> inputs to respective hypercalls. Note, however, that for ordi
On 12.06.2024 12:55, 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, map);
Looking
On Tue, Jun 11, 2024 at 03:50:42PM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, 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 previ
On 12/06/2024 9:44 am, Jan Beulich wrote:
> It's hardly ever correct to check for just DOMID_SELF, as guests have
> ways to figure out their domain IDs and hence could instead use those as
> inputs to respective hypercalls. Note, however, that for ordinary DomU-s
> the adjustment is relaxing things
Nobody volunteered *up front* to take notes for the Matrix design
session [1], but I did end up taking a few notes, so agreed to do some
follow-up.
The general issue seemed to be how difficult it was to pull out
"signal" from "noise" (where "noise" is individual; i.e., something
completely ARM-spe
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:
Some type of domain don't have PIRQ, like PVH, it do not do
PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>>
On Wed, Jun 12, 2024 at 10:44:56AM +0200, Jan Beulich wrote:
> It's hardly ever correct to check for just DOMID_SELF, as guests have
> ways to figure out their domain IDs and hence could instead use those as
> inputs to respective hypercalls. Note, however, that for ordinary DomU-s
> the adjustment
On 12.06.2024 12:25, Andrew Cooper wrote:
> On 12/06/2024 10:40 am, Damien Thenot wrote:
>> Hello,
>>
>> A XCP-ng 8.3 user that use Blue Iris Software encountered a crash with
>> Xen upgraded to version 4.17.
>> It worked correctly when XCP-ng 8.3 used Xen 4.13.
>> It is happening on Intel Xeon E-
flight 186315 xen-unstable real [real]
flight 186321 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186315/
http://logs.test-lab.xenproject.org/osstest/logs/186321/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On Wed, Jun 12, 2024 at 11:04:26AM +0200, Jan Beulich wrote:
> On 12.06.2024 10:47, Roger Pau Monné wrote:
> > On Tue, Jun 11, 2024 at 02:45:09PM +0200, Jan Beulich wrote:
> >> On 10.06.2024 16:20, Roger Pau Monne wrote:
> >>> Given the current logic it's possible for ->arch.old_cpu_mask to get out
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 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 pr
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". Therefore, some
>>> macro definitions
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:
>>> Some type of domain don't have PIRQ, like PVH, it do not do
>>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>>> to guest on PVH dom0, callstack
>>> pci_add
On 12/06/2024 10:40 am, Damien Thenot wrote:
> Hello,
>
> A XCP-ng 8.3 user that use Blue Iris Software encountered a crash with
> Xen upgraded to version 4.17.
> It worked correctly when XCP-ng 8.3 used Xen 4.13.
> It is happening on Intel Xeon E-2378 CPU @ 2.60GHz CPUs and it seems
> more recen
On 2024/6/12 17:21, Jan Beulich wrote:
> On 12.06.2024 11:07, Chen, Jiqian wrote:
>> On 2024/6/12 16:53, Jan Beulich wrote:
>>> On 12.06.2024 04:43, Chen, Jiqian wrote:
On 2024/6/10 23:58, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm
On 2024/6/11 00:04, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> On 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 hvm domU.
>> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
>>
On Tue, 2024-06-11 at 11:59 +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > The current check used in fixup_irqs() to decide whether to move
> > around
> > interrupts is based on the affinity mask, but such mask can have
> > all bits set,
> > and hence is unlikely to be
Hi Jan,
On 2024/6/11 22:39, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> Some type of domain don't have PIRQ, like PVH, it do not do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest on PVH dom0, callstack
>> pci_add_dm_done->XEN_DOMCTL_irq_permission wil
On Tue, 2024-06-11 at 09:44 +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > The logic to move interrupts across CPUs is complex, attempt to
> > provide a
> > comment that describes the expected behavior so users of the
> > interrupt system
> > have more context about the
On Wed, 2024-06-12 at 10:56 +0200, Jan Beulich wrote:
> On 12.06.2024 10:09, Roger Pau Monné wrote:
> > On Tue, Jun 11, 2024 at 09:42:39AM +0200, Jan Beulich wrote:
> > > On 10.06.2024 16:20, Roger Pau Monne wrote:
> > > > Due to the current rwlock logic, if the CPU calling
> > > > get_cpu_maps() d
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". Therefore, some
macro definitions should gain additional parentheses to ensure that
all
ret is assigned first, so it does not need to initialize the assignment.
Signed-off-by: Li zeming
---
arch/x86/pci/xen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 652cd53e77f6..67cb9dc9b2e7 100644
--- a/arch/x86/pci/xen.
Hello,
A XCP-ng 8.3 user that use Blue Iris Software encountered a crash with
Xen upgraded to version 4.17.
It worked correctly when XCP-ng 8.3 used Xen 4.13.
It is happening on Intel Xeon E-2378 CPU @ 2.60GHz CPUs and it seems
more recent Intel CPUs.
His guests are Windows with a NVIDIA GPU given
On Wed, 2024-06-12 at 10:44 +0200, Jan Beulich wrote:
> It's hardly ever correct to check for just DOMID_SELF, as guests have
> ways to figure out their domain IDs and hence could instead use those
> as
> inputs to respective hypercalls. Note, however, that for ordinary
> DomU-s
> the adjustment is
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". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 12.06.2024 11:07, Chen, Jiqian wrote:
> On 2024/6/12 16:53, Jan Beulich wrote:
>> On 12.06.2024 04:43, Chen, Jiqian wrote:
>>> On 2024/6/10 23:58, Jan Beulich wrote:
On 07.06.2024 10:11, Jiqian Chen wrote:
> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
> a passthro
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". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
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". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
flight 186318 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186318/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3b32dca06b987d7214637f3952c2ce1ce69f308
baseline version:
ovmf 0982da4f50279bfb2be47
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". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 2024/6/12 16:53, Jan Beulich wrote:
> On 12.06.2024 04:43, Chen, Jiqian wrote:
>> On 2024/6/10 23:58, Jan Beulich wrote:
>>> On 07.06.2024 10:11, Jiqian Chen wrote:
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see qemu code
xen_
On 12.06.2024 10:47, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 02:45:09PM +0200, Jan Beulich wrote:
>> On 10.06.2024 16:20, Roger Pau Monne wrote:
>>> 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 onlin
On 12.06.2024 10:09, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 09:42:39AM +0200, Jan Beulich wrote:
>> On 10.06.2024 16:20, Roger Pau Monne wrote:
>>> Due to the current rwlock logic, if the CPU calling get_cpu_maps() does so
>>> from
>>> a cpu_hotplug_{begin,done}() region the function wil
On 12.06.2024 04:43, Chen, Jiqian wrote:
> On 2024/6/10 23:58, Jan Beulich wrote:
>> On 07.06.2024 10:11, Jiqian Chen wrote:
>>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>>> a passthrough device by using gsi, see qemu code
>>> xen_pt_realize->xc_physdev_map_pirq and libxl code
On Tue, Jun 11, 2024 at 02:45:09PM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > 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 u
It's hardly ever correct to check for just DOMID_SELF, as guests have
ways to figure out their domain IDs and hence could instead use those as
inputs to respective hypercalls. Note, however, that for ordinary DomU-s
the adjustment is relaxing things rather than tightening them, since
- as a result
On Tue, Jun 11, 2024 at 03:47:03PM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > @@ -2589,6 +2589,28 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
> > affinity);
> > }
> >
> > +if ( desc->arch.move_in_progres
On Mon, Jun 10, 2024 at 05:10:45PM +, Petr Beneš wrote:
> From: Petr Beneš
>
> This commit activates the previously introduced altp2m_count parameter,
> establishing the connection between libxl and Xen.
>
> Signed-off-by: Petr Beneš
Acked-by: Anthony PERARD
Thanks,
--
Anthony Perard |
On Tue, Jun 11, 2024 at 12:20:33PM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > If external interrupts are using logical mode it's possible to have an
> > overlap
> > between the current ->arch.cpu_mask and the provided mask (or TARGET_CPUS).
> > If
> > that's the
On Mon, Jun 10, 2024 at 05:10:43PM +, Petr Beneš wrote:
> From: Petr Beneš
>
> Update manual pages to include detailed information about the altp2m_count
> configuration parameter.
>
> Signed-off-by: Petr Beneš
Acked-by: Anthony PERARD
Thanks,
--
Anthony Perard | Vates XCP-ng Developer
On Mon, Jun 10, 2024 at 05:10:42PM +, Petr Beneš wrote:
> From: Petr Beneš
>
> Introduce a new altp2m_count parameter to control the maximum number of altp2m
> views a domain can use. By default, if altp2m_count is unspecified and altp2m
> is enabled, the value is set to 10, reflecting the leg
On Tue, Jun 11, 2024 at 11:59:39AM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > The current check used in fixup_irqs() to decide whether to move around
> > interrupts is based on the affinity mask, but such mask can have all bits
> > set,
> > and hence is unlikely to
On Tue, Jun 11, 2024 at 09:42:39AM +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > Due to the current rwlock logic, if the CPU calling get_cpu_maps() does so
> > from
> > a cpu_hotplug_{begin,done}() region the function will still return success,
> > because a CPU takin
On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> blkfront always had a robust negotiation protocol for detecting a write
> cache. Stop simply disabling cache flushes when they fail as that is
> a grave error.
It's my understanding the current code attempts to cover up for the
flight 186314 linux-linus real [real]
flight 186317 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186314/
http://logs.test-lab.xenproject.org/osstest/logs/186317/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
78 matches
Mail list logo
