On 24.02.2022 23:27, Dongli Zhang wrote:
> Hello,
>
> This is to report that the soft_reset (kexec/kdump) has not been working for
> me
> since long time ago.
>
> I have tested again with the most recent mainline xen and the most recent
> mainline kernel.
>
> While it works with my old xen vers
HI Ayan,
> -Original Message-
> From: Ayan Kumar Halder
> Sent: 2022年2月24日 19:52
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> jul...@xen.org; Stefano Stabellini
> Cc: Bertrand Marquis ; Penny Zheng
> ; Henry Wang ; nd
> Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftA
>
flight 168220 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168220/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 168214
test-amd64-amd64-xl-qemut-win7-amd64
flight 168217 qemu-mainline real [real]
flight 168223 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168217/
http://logs.test-lab.xenproject.org/osstest/logs/168223/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 168222 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168222/
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
Hi Wei,
This is extremely exciting, thanks for the very nice summary!
On Thu, 24 Feb 2022, Wei Chen wrote:
> # Proposal for Porting Xen to Armv8-R64
>
> This proposal will introduce the PoC work of porting Xen to Armv8-R64,
> which includes:
> - The changes of current Xen capability, like Xen b
On Wed, Feb 23, 2022 at 09:59:48AM +0100, Jan Beulich wrote:
Hi, I hope the end of the week is going well for everyone.
> On 22.02.2022 19:52, Dr. Greg wrote:
> > On Fri, Feb 18, 2022 at 08:04:14AM +0100, Jan Beulich wrote:
> >> On 17.02.2022 21:15, Dr. Greg wrote:
> >>> On Mon, Feb 14, 2022 at 0
On 24/02/2022 11:22, Andrew Cooper wrote:
> On 24/02/2022 10:21, Andrew Cooper wrote:
>> On 24/02/2022 10:14, Jan Beulich wrote:
>>> With version 2.7 I'm observing support for binary searches, but
>>> unreliable results: Only a subset of the supposed matches is actually
>>> reported; for our patter
Hi Jan,
On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
On 15.02.22 22:13, Julien Grall wrote:
As a side note, should we also update SUPPORT.md?
Good question.
I'm not sure here either - talking about individual hypercall sub-ops
seems overly small granula
On 22/02/2022 15:55, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 21 Feb 2022, at 10:22, Julien Grall wrote:
From: Julien Grall
The array level_orders and level_masks can be replaced with the
recently introduced macros LEVEL_ORDER and LEVEL_MASK.
Signed-off-by: Julien Grall
R
Hello,
This is to report that the soft_reset (kexec/kdump) has not been working for me
since long time ago.
I have tested again with the most recent mainline xen and the most recent
mainline kernel.
While it works with my old xen version, it does not work with mainline xen.
This is the log of
On 22/02/2022 15:38, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 21 Feb 2022, at 10:22, Julien Grall wrote:
From: Julien Grall
Currently, Xen PT helpers are only working with 4KB page granularity
and open-code the generic helpers. To allow more flexibility, we can
re-use the gen
On 22/02/2022 13:30, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 21.02.2022 11:22, Julien Grall wrote:
From: Julien Grall
Commit 05031fa87357 "xen/arm: guest_walk: Only generate necessary
offsets/masks" introduced LPAE_ENTRIES_MASK_GS. In a follow-up patch,
we will use it for to define
This is the v3 of the patch to fix xen kexec kernel panic issue when the
kexec is triggered on VCPU >= 32.
PANIC: early exception 0x0e IP 10:a96679b6 error 0 cr2 0x20
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
5.17.0-rc4xen-00054-gf71077a4d84b-dirty #1
[0.00] Hardware
The sched_clock() can be used very early since commit 857baa87b642
("sched/clock: Enable sched clock early"). In addition, with commit
38669ba205d1 ("x86/xen/time: Output xen sched_clock time from 0"), kdump
kernel in Xen HVM guest may panic at very early stage when accessing
&__this_cpu_read(xen_v
flight 168218 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168218/
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
Two fixes from investing a QubesOS bug report.
Andrew Cooper (2):
x86/CET: Fix S3 resume with shadow stacks active
x86/vmx: Don't spuriously crash the domain when INIT is received
xen/arch/x86/boot/x86_64.S | 18 +-
xen/arch/x86/hvm/vmx/vmx.c | 4
2 files changed, 17 in
The original shadow stack support has an error on S3 resume with very bizzare
fallout. The BSP comes back up, but APs fail with:
(XEN) Enabling non-boot CPUs ...
(XEN) Stuck ??
(XEN) Error bringing CPU1 up: -5
and then later (on at least two Intel TigerLake platforms), the next HVM vCPU
to
In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT has
nothing to do with the guest in question, simply signals that an INIT was
received.
Ignoring the INIT is probably the wrong thing to do, but is helpful for
debugging. Crashing the domain which happens to be in context i
flight 168214 xen-unstable real [real]
flight 168219 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168214/
http://logs.test-lab.xenproject.org/osstest/logs/168219/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Thu, Feb 24, 2022 at 8:10 AM Jan Beulich wrote:
>
> On 03.02.2022 14:57, Jan Beulich wrote:
> > For higher order mappings the comparison against p2m->min_remapped_gfn
> > needs to take the upper bound of the covered GFN range into account, not
> > just the base GFN. Otherwise, i.e. when droppin
On 24/02/2022 11:25, Jan Beulich wrote:
> On 13.01.2022 14:17, Jan Beulich wrote:
>> Except in the "clocksource=tsc" case we can replace the indirect calls
>> involved in accessing the platform timers by direct ones, as they get
>> established once and never changed. To also cover the "tsc" case, i
Hi Andrew,
On 23/02/2022 19:38, Andrew Cooper wrote:
On 23/02/2022 19:08, Julien Grall wrote:
From: Julien Grall
The local variable pg_offlined in free_heap_pages() can only take two
values. So switch it to a bool.
Signed-off-by: Julien Grall
I'd argue this might want to go as far as decl
Hello:
This series was applied to netdev/net.git (master)
by Jakub Kicinski :
On Tue, 22 Feb 2022 01:18:16 +0100 you wrote:
> This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
>
> The 'hotplug-status' node should not be removed as long as the vif
> device remains configured. Otherwis
On 2/24/22 11:39 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 11:18:33AM -0500, Boris Ostrovsky wrote:
On 2/24/22 10:58 AM, Christoph Hellwig wrote:
Thanks.
This looks really strange as early_amd_iommu_init should not interact much
with the changes. I'll see if I can find a AMD syst
On 24.02.2022 17:59, Jane Malalane wrote:
> On 24/02/2022 14:16, Jan Beulich wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>> unless you have verified the sender and know the content is safe.
>>
>> On 18.02.2022 18:29, Jane Malalane wrote:
>>> --- a/xen/arch/x
On 24/02/2022 14:16, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 18.02.2022 18:29, Jane Malalane wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/v
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/UQhtWwPPUUD6p2gWGXEPrIc1/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
On 24.02.2022 17:37, Roger Pau Monne wrote:
> Introduce a new field to mark devices as broken: having it set
> prevents the device from being assigned to guests. Use the field in
> order to mark ATS devices that have failed a flush as broken, thus
> preventing them to be assigned to any guest.
>
>
On Thu, Feb 24, 2022 at 11:18:33AM -0500, Boris Ostrovsky wrote:
>
> On 2/24/22 10:58 AM, Christoph Hellwig wrote:
>> Thanks.
>>
>> This looks really strange as early_amd_iommu_init should not interact much
>> with the changes. I'll see if I can find a AMD system to test on.
>
>
> Just to be clear
Introduce a new field to mark devices as broken: having it set
prevents the device from being assigned to guests. Use the field in
order to mark ATS devices that have failed a flush as broken, thus
preventing them to be assigned to any guest.
This allows the device IOMMU context entry to be cleane
On 24.02.22 17:23, Jan Beulich wrote:
On 24.02.2022 16:41, Juergen Gross wrote:
On 24.02.22 16:37, Jan Beulich wrote:
On 24.02.2022 16:24, Juergen Gross wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -662,6 +662,13 @@ struct xen_mem_acquire_resource {
* t
On 24.02.2022 16:41, Juergen Gross wrote:
> On 24.02.22 16:37, Jan Beulich wrote:
>> On 24.02.2022 16:24, Juergen Gross wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -662,6 +662,13 @@ struct xen_mem_acquire_resource {
>>>* two calls.
>>>*/
On 2/24/22 10:58 AM, Christoph Hellwig wrote:
Thanks.
This looks really strange as early_amd_iommu_init should not interact much
with the changes. I'll see if I can find a AMD system to test on.
Just to be clear: this crashes only as dom0. Boots fine as baremetal.
-boris
On Wed, Feb
On 24.02.2022 11:54, Juergen Gross wrote:
> Instead of only passing the lock_debug address to check_lock() et al
> use the address of the spinlock.
I'm uncertain about this full exposure. The next patch looks to again
only use the new "data" subfield in these debugging helpers.
Jan
On 24.02.2022 11:54, Juergen Gross wrote:
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -42,7 +42,7 @@ static inline void mm_lock_init(mm_lock_t *l)
>
> static inline bool mm_locked_by_me(const mm_lock_t *l)
> {
> -return (l->lock.recurse_cpu == current->process
Thanks.
This looks really strange as early_amd_iommu_init should not interact much
with the changes. I'll see if I can find a AMD system to test on.
On Wed, Feb 23, 2022 at 07:57:49PM -0500, Boris Ostrovsky wrote:
> [ 37.377313] BUG: unable to handle page fault for address: c90042880018
>
On 24.02.22 16:37, Jan Beulich wrote:
On 24.02.2022 16:24, Juergen Gross wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -662,6 +662,13 @@ struct xen_mem_acquire_resource {
* two calls.
*/
uint32_t nr_frames;
+/*
+ * Padding field, must b
On 24.02.2022 16:24, Juergen Gross wrote:
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -662,6 +662,13 @@ struct xen_mem_acquire_resource {
> * two calls.
> */
> uint32_t nr_frames;
> +/*
> + * Padding field, must be zero on input.
> + * I
On 24.02.2022 15:53, Roger Pau Monné wrote:
> On Thu, Feb 24, 2022 at 01:58:31PM +0100, Jan Beulich wrote:
>> On 24.02.2022 13:43, Roger Pau Monne wrote:
>>> TBD: it's unclear whether we still need the pcidevs_lock in
>>> iommu_dev_iotlb_flush_timeout. The caller of
>>> iommu_dev_iotlb_flush_timeou
Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible
way. Unfortunately the changed parts were already in use in the Linux
kernel, so an update of the header in the kernel would result in a build
breakage.
As the change of above commit was in a section originally meant to be
Hi Michal,
On 22/02/2022 10:56, Michal Orzel wrote:
The request to rename psr_mode_is_32bit to regs_mode_is_32bit was make during
a discussion [1]. Because psr_mode_is_user shares the same prototype, we should
rename it as well to keep the naming consistent.
[1] https://marc.info/?l=xen-devel&m
flight 168216 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168216/
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
Hi,
On 17/02/2022 19:38, Julien Grall wrote:
On 17/02/2022 11:47, Juergen Gross wrote:
The Xenstore migration document is missing the specification that a
node record must be preceded by the record of its parent node in case
of live update.
The patch also cover normal migration. So I think you
On 15.02.2022 16:25, Rahul Singh wrote:
> {read,write}{l,q} function argument is different for ARM and x86.
> ARM {read,wrie}(l,q} function argument is pointer whereas X86
> {read,wrie}(l,q} function argument is address itself.
I'm afraid I don't follow: x86 has
#define readl(x) (*(volatile uint3
On Fri, Feb 18, 2022 at 09:06:35AM +0100, Jan Beulich wrote:
> On 17.02.2022 15:09, Roger Pau Monne wrote:
> > Prevent libxl from creating guests that attempts to use PoD together
> > with an IOMMU, even if no devices are actually assigned.
> >
> > While the hypervisor could support using PoD toge
On 15.02.2022 16:25, Rahul Singh wrote:
> vpci/msix.c file will be used for arm architecture when vpci msix
> support will be added to ARM, but there is x86 specific code in this
> file.
>
> Move x86 specific code to the x86/hvm/vmsi.c file to make sure common
> code will be used for other archite
Hi Andrew,
On 23/02/2022 19:30, Andrew Cooper wrote:
On 23/02/2022 18:38, Julien Grall wrote:
From: Julien Grall
free_heap_pages() has an ASSERT() checking that node is >= 0. However
node is defined as an unsigned int. So it cannot be negative.
Therefore remove the check as it will always be
Hi Jan,
On 24/02/2022 08:27, Jan Beulich wrote:
On 23.02.2022 19:38, Julien Grall wrote:
From: Julien Grall
free_heap_pages() has an ASSERT() checking that node is >= 0. However
node is defined as an unsigned int. So it cannot be negative.
Therefore remove the check as it will always be true
On Thu, Feb 24, 2022 at 01:58:31PM +0100, Jan Beulich wrote:
> On 24.02.2022 13:43, Roger Pau Monne wrote:
> > Introduce a new field to mark devices as broken: having it set
> > prevents the device from being assigned to domains. Use the field in
> > order to mark ATS devices that have failed a flu
On 24.02.2022 15:09, Roger Pau Monné wrote:
> On Thu, Jan 13, 2022 at 02:17:18PM +0100, Jan Beulich wrote:
>> Except in the "clocksource=tsc" case we can replace the indirect calls
>> involved in accessing the platform timers by direct ones, as they get
>> established once and never changed. To als
On 18.02.2022 18:29, Jane Malalane wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -,15 +,15 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
>
> void vmx_vlapic_msr_changed(struct vcpu *v)
> {
> -int virtualize_x2apic_mode;
> +bool vir
On Thu, Jan 13, 2022 at 02:17:18PM +0100, Jan Beulich wrote:
> Except in the "clocksource=tsc" case we can replace the indirect calls
> involved in accessing the platform timers by direct ones, as they get
> established once and never changed. To also cover the "tsc" case, invoke
> what read_tsc()
On 18.02.2022 18:29, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
> and x2apic, on x86 hardware.
> No such features are currently implemented on AMD hardware.
>
> For that purpose, also add an arch-speci
As noted in the context of 3330013e6739 ("VT-d / x86: re-arrange cache
syncing"): While cache_writeback() has the SFENCE on the correct side of
CLFLUSHOPT, flush_area_local() doesn't. While I can't prove it due to
lacking a copy of the old SDM version, I can only assume this placement
was a result
Besides keeping things centralized and reducing (by folding) a few
conditionals, this also allows this helper to be put in .init.text.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -744,6 +744,23 @@ void __init detect_zen2_null_seg_behavio
1: AMD: collect checking for bugs in a single function
2: correct fencing around CLFLUSH
Jan
Hi,
Yes I will be acting as the contact point for tboot.
Best regards,
Mateusz
-Original Message-
From: Jan Beulich
Sent: Thursday, February 24, 2022 2:08 PM
To: Cooper, Andrew ; George Dunlap
; Julien Grall ; Wei Liu
; Stefano Stabellini ; Mowka, Mateusz
Cc: xen-devel@lists.xenpro
On 24.02.2022 14:12, Mowka, Mateusz wrote:
> Yes I will be acting as the contact point for tboot.
>
> Best regards,
> Mateusz
I'll take the liberty to translate this to an Acked-by: then.
Jan
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, February 24, 2022 2:08 PM
> To: Co
On 03.02.2022 14:57, Jan Beulich wrote:
> For higher order mappings the comparison against p2m->min_remapped_gfn
> needs to take the upper bound of the covered GFN range into account, not
> just the base GFN. Otherwise, i.e. when dropping a mapping overlapping
> the remapped range but the base GFN
On 17.02.2022 18:02, Jan Beulich wrote:
> Since Lukasz has left Intel, they have suggested a replacement contact.
>
> Signed-off-by: Jan Beulich
May I ask for an ack here please?
Mateusz, it would be good to have your ack too, considering it wasn't you
who proposed the addition.
Jan
> ---
> v
On 27.01.2022 16:04, Jan Beulich wrote:
> On 04.01.2022 11:57, Jan Beulich wrote:
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count should indicate too large a
>> value in preference to a too small one, to avoid functions bailing earl
On 27.01.2022 16:04, Jan Beulich wrote:
> On 04.01.2022 10:48, Jan Beulich wrote:
>> Avoid recurring MFN -> page or page -> MFN translations. Drop the pretty
>> pointless local variable "p". Make sure the MFN logged in a debugging
>> error message is actually the offending one. Return negative errn
On 24.02.2022 13:43, Roger Pau Monne wrote:
> Introduce a new field to mark devices as broken: having it set
> prevents the device from being assigned to domains. Use the field in
> order to mark ATS devices that have failed a flush as broken, thus
> preventing them to be assigned to any guest.
>
Introduce a new field to mark devices as broken: having it set
prevents the device from being assigned to domains. Use the field in
order to mark ATS devices that have failed a flush as broken, thus
preventing them to be assigned to any guest.
This allows the device IOMMU context entry to be clean
On 23.02.2022 13:33, Andrew Cooper wrote:
> On 23/02/2022 10:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -346,9 +346,14 @@ void __init early_cpu_init(void)
>> c->x86_model, c->x86_model, c->x86_mask, eax);
>>
>> if (c->cpuid_
Hi Wei,
This is a nice writeup. I have a few initial queries.
On 24/02/2022 06:01, Wei Chen wrote:
# Proposal for Porting Xen to Armv8-R64
This proposal will introduce the PoC work of porting Xen to Armv8-R64,
which includes:
- The changes of current Xen capability, like Xen build system, memo
On 13.01.2022 14:17, Jan Beulich wrote:
> Except in the "clocksource=tsc" case we can replace the indirect calls
> involved in accessing the platform timers by direct ones, as they get
> established once and never changed. To also cover the "tsc" case, invoke
> what read_tsc() resolves to directly.
On 24/02/2022 10:21, Andrew Cooper wrote:
> On 24/02/2022 10:14, Jan Beulich wrote:
>> With version 2.7 I'm observing support for binary searches, but
>> unreliable results: Only a subset of the supposed matches is actually
>> reported; for our pattern I've never observed any match. This same
>> ve
Instead of only passing the lock_debug address to check_lock() et al
use the address of the spinlock.
Signed-off-by: Juergen Gross
---
xen/common/spinlock.c | 34 +-
xen/include/xen/rwlock.h | 10 +-
xen/include/xen/spinlock.h | 10 --
3 fil
The spinlock data structure contains two cpu fields for storing the
cpu number of the lock holder (one for debug purposes and one for
recursive spinlocks). Merging them removes a build time limitation for
supporting higher cpu numbers than today.
This series is NOT using more bits for storing the
Instead of having two fields in struct spinlock holding a cpu number,
just merge them. For this purpose get rid of union lock_debug and use a
32 bit sized union for cpu, recurse_cnt and the two debug booleans.
Signed-off-by: Juergen Gross
---
xen/arch/x86/mm/mm-locks.h | 6 ++---
xen/common/spi
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> Let the caller chose a zone to allocate from.
This is being used later via xen_swiotlb_gfp() on arm platform.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/pci/sta2x11-fixup.c | 2 +-
> include/linux/swiotlb.h | 2 +-
> kernel/dma/
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> swiotlb_late_init_with_default_size is an overly verbose name that
> doesn't even catch what the function is doing, given that the size is
> not just a default but the actual requested size.
>
> Rename it to swiotlb_init_late.
>
> Signed-off-by: C
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> Remove the bogus Xen override that was usually larger than the actual
> size and just calculate the value on demand. Note that
> swiotlb_max_segment still doesn't make sense as an interface and should
> eventually be removed.
>
> Signed-off-by: Ch
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> If force bouncing is enabled we can't release the bufffers.
typo
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/swiotlb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --gi
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> Use the more specific is_swiotlb_active check instead of checking the
> global swiotlb_force variable.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/direct.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kern
On 24/02/2022 10:14, Jan Beulich wrote:
> With version 2.7 I'm observing support for binary searches, but
> unreliable results: Only a subset of the supposed matches is actually
> reported; for our pattern I've never observed any match. This same
> version works fine when handing it a Perl regexp u
flight 168212 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168212/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> The IOMMU table tries to separate the different IOMMUs into different
> backends, but actually requires various cross calls.
>
> Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
> in pci-dma.c and then just call into the IOMMU d
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> Allow to pass a remap argument to the swiotlb initialization functions
> to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
> from xen_swiotlb_fixup, so we don't even need that quirk.
>
> Signed-off-by: Christoph Hellwig
> ---
> ar
With version 2.7 I'm observing support for binary searches, but
unreliable results: Only a subset of the supposed matches is actually
reported; for our pattern I've never observed any match. This same
version works fine when handing it a Perl regexp using hex or octal
escapes. Probe for support of
On 24/02/2022 07:56, Durrant, Paul wrote:
On 22/02/2022 00:18, Marek Marczykowski-Górecki wrote:
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied o
On Wed, Feb 23, 2022 at 05:31:53PM +0100, Jan Beulich wrote:
> On 23.02.2022 17:11, Roger Pau Monné wrote:
> > On Wed, Feb 23, 2022 at 09:38:56AM -0600, Alex Olson wrote:
> >> 1) For conditions in which MSR registers are writeable from PV guests
> >> (such as
> >> dom0), they should probably be r
flight 168211 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168211/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 168198
test-armhf-armhf-xl-rtds 18 gues
On 23.02.2022 19:38, Julien Grall wrote:
> From: Julien Grall
>
> free_heap_pages() has an ASSERT() checking that node is >= 0. However
> node is defined as an unsigned int. So it cannot be negative.
>
> Therefore remove the check as it will always be true.
>
> Signed-off-by: Julien Grall
>
>
86 matches
Mail list logo
