On 27.04.2022 21:08, Demi Marie Obenour wrote:
> On Wed, Apr 27, 2022 at 10:56:34AM +0200, Jan Beulich wrote:
>> On 19.04.2022 17:49, Demi Marie Obenour wrote:
>>> This hypercall can be used to get the ESRT from the hypervisor. It
>>> returning successfully also indicates that Xen has reserved the
On 27.04.2022 18:12, Roger Pau Monné wrote:
> On Wed, Apr 27, 2022 at 05:25:35PM +0200, Jan Beulich wrote:
>> On 27.04.2022 17:06, Roger Pau Monné wrote:
>>> On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
On 27.04.2022 14:45, Roger Pau Monné wrote:
> On Tue, Apr 26, 2022 at 1
flight 169782 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169782/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169563
test-amd64-i386-xl-qemut-win7-amd64 19
flight 169803 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169803/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi
> -Original Message-
> From: Stefano Stabellini
> Sent: Thursday, April 28, 2022 6:32 AM
> To: Penny Zheng
> Cc: Julien Grall ; xen-devel@lists.xenproject.org; Wei Chen
> ; Henry Wang ; Stefano
> Stabellini ; Bertrand Marquis
> ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_heap_pages in runtime
for static domain fre
flight 169800 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169800/
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 169802 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Thu, 28 Apr 2022, Julien Grall wrote:
> Hi Stefano,
>
> On Thu, 28 Apr 2022, 00:02 Stefano Stabellini, wrote
> It seems to me that it is acceptable to allocate memory with interrupt
> disabled during __init. I cannot see any drawbacks with it. I think we
> should change the A
On 4/27/22 15:49, Guilherme G. Piccoli wrote:
> + crash_kexec_post_notifiers
> + This was DEPRECATED - users should always prefer the
This is DEPRECATED - users should always prefer the
> + parameter "panic_notifiers_level" -
flight 169799 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169779 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169779/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169762
test-armhf-armhf-libvirt 16 sav
On Wed, Apr 27, 2022 at 07:49:14PM -0300, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to
> register callbacks to run earlier in the panic path than they
> currently do. This aims at informational mechanisms, like dumping
> kernel offsets and showing devic
Hi Stefano,
On Thu, 28 Apr 2022, 00:02 Stefano Stabellini,
wrote
> It seems to me that it is acceptable to allocate memory with interrupt
> disabled during __init. I cannot see any drawbacks with it. I think we
> should change the ASSERT to only trigger after __init: system_state ==
> SYS_STATE_
Currently both pseries and ps3 are platforms that define special
panic notifiers that run as callbacks inside powerpc generic panic
notifier. In both cases kmsg_dump() is called, and the reason seems
to be that both of these callbacks aims to effectively stop the
machine, so nothing would execute a
Currently the panic notifier panic_exit() calls kmsg_dump() and
some console flushing routines - this makes sense since such
panic notifier exits UserMode Linux and never returns.
Happens that after a panic refactor, kmsg_dump() is now always
called *before* the pre_reboot list of panic notifiers,
There is no users anymore of this variable that requires
it to be "exported" in the headers; also, it was deprecated
by the kernel parameter "panic_notifiers_level".
Signed-off-by: Guilherme G. Piccoli
---
include/linux/panic.h | 2 --
include/linux/panic_notifier.h | 1 -
2 files chang
Commit 06e629c25daa ("powerpc/fadump: Fix inaccurate CPU state info in
vmcore generated with panic") introduced a hardcoded setting of kernel
parameter "crash_kexec_post_notifiers", effectively forcing all the
panic notifiers to execute earlier in the panic path, before kdump.
The reason for that
The panic() function is somewhat convoluted - a lot of changes were
made over the years, adding comments that might be misleading/outdated
now, it has a code structure that is a bit complex to follow, with
lots of conditionals, for example. The panic notifier list is something
else - a single list,
This patch renames the panic_notifier_list to panic_pre_reboot_list;
the idea is that a subsequent patch will refactor the panic path
in order to better split the notifiers, running some of them very
early, some of them not so early [but still before kmsg_dump()] and
finally, the rest should execut
The goal of this new panic notifier is to allow its users to
register callbacks to run earlier in the panic path than they
currently do. This aims at informational mechanisms, like dumping
kernel offsets and showing device error data (in case it's simple
registers reading, for example) as well as m
The goal of this new panic notifier is to allow its users to register
callbacks to run very early in the panic path. This aims hypervisor/FW
notification mechanisms as well as simple LED functions, and any other
simple and safe mechanism that should run early in the panic path; more
dangerous callb
This patch improves the panic/die notifiers in this driver by
making use of a passed "id" instead of comparing pointer
address; also, it removes an useless prototype declaration
and unnecessary header inclusion.
This is part of a panic notifiers refactor - this notifier in
the future will be moved
Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing a hypervisor <-> guest connection,
disabling a paravirtualized timer) as well as to data collection (sending
pani
Currently the panic notifiers from user mode linux don't follow
the convention for most of the other notifiers present in the
kernel (indentation, priority setting, numeric return).
More important, the priorities could be improved, since it's a
special case (userspace), hence we could run the notif
Since commit a11589563e96 ("x86/Hyper-V: Report crash register
data or kmsg before running crash kernel") Hyper-V forcibly sets
the kernel parameter "crash_kexec_post_notifiers"; with that, it
did enforce the execution of *all* panic notifiers before kdump.
The main reason behind that is that Hyper
The alpha panic notifier has some code issues, not following
the conventions of other notifiers. Also, it might halt the
machine but still it is set to run as early as possible, which
doesn't seem to be a good idea.
This patch cleans the code, and set the notifier to run as the
latest, following t
The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic context,
with interrupts and preemption disabled in the running CPU and all other
CPUs disabled. That said, mutexes in such context are not a good idea.
This patch rep
Currently the parameter "panic_print" relies in a function called
directly on panic path; one of the flags the users can set for
panic_print triggers a console replay mechanism, to show the
entire kernel log buffer (from the beginning) in a panic event.
Two problems with that: the dual nature of t
Currently we don't have a way to check if there are dumpers set,
except counting the list members maybe. This patch introduces a very
simple helper to provide this information, by just keeping track of
registered/unregistered kmsg dumpers. It's going to be used on the
panic path in the subsequent p
The pvpanic driver relies on panic notifiers to execute a callback
on panic event. Such function is executed in atomic context - the
panic function disables local IRQs, preemption and all other CPUs
that aren't running the panic code.
With that said, it's dangerous to use regular spinlocks in such
Currently the gsmi driver registers a panic notifier as well as
reboot and die notifiers. The callbacks registered are called in
atomic and very limited context - for instance, panic disables
preemption, local IRQs and all other CPUs that aren't running the
current panic function.
With that said,
Currently we have 3 notifier lists in the panic path, which will
be wired in a way to allow the notifier callbacks to run in
different moments at panic time, in a subsequent patch.
But there is also an odd set of architecture calls hardcoded in
the end of panic path, after the restart machinery. T
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Although many notifiers are mentioned in the comments, the panic
notifiers infrastructure is not. Also, the file contains some
trailing whitespaces. This commit fix both issues.
Cc: Arjan van de Ven
Cc: Cong Wang
Cc: Sebastian Andrzej Siewior
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-
Currently we have a debug infrastructure in the notifiers file, but
it's very simple/limited. This patch extends it by:
(a) Showing all registered/unregistered notifiers' callback names;
(b) Adding a dynamic debug tuning to allow showing called notifiers'
function names. Notice that this should b
Currently the tracing dump_on_oops feature is implemented
through separate notifiers, one for die/oops and the other
for panic. With the addition of panic notifier "id", this
patch makes use of such "id" to unify both functions.
It also comments the function and changes the priority of the
notifie
Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
is responsible for that. This makes sense, since we're turning off
such CPUs, putting them in an endless busy-wait loop.
Problem is that there is an alternative pa
The notifiers infrastructure provides a way to pass an "id" to the
callbacks to determine what kind of event happened, i.e., what is
the reason behind they getting called.
The panic notifier currently pass 0, but this is soon to be
used in a multi-targeted notifier, so let's pass a meaningful
"id"
Currently many console drivers for s390 rely on panic/reboot notifiers
to invoke callbacks on these events. The panic() function disables local
IRQs, secondary CPUs and preemption, so callbacks invoked on panic are
effectively running in atomic context.
Happens that most of these console callbacks
The panic notifiers' callbacks execute in an atomic context, with
interrupts/preemption disabled, and all CPUs not running the panic
function are off, so it's very dangerous to wait on a regular
spinlock, there's a risk of deadlock.
This patch refactors the panic notifier of parisc/power driver
to
Many other place in the kernel prefer the latter, so let's keep
it consistent in MIPS code as well. Also, removes a useless header.
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/mips/sgi-ip22/ip22-reset.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
The panic notifiers infrastructure is a bit limited in the scope of
the callbacks - basically every kind of functionality is dropped
in a list that runs in the same point during the kernel panic path.
This is not really on par with the complexities and particularities
of architecture / hypervisors'
The panic notifier of this driver is very simple code-wise, just a memory
write to a special position with some numeric code. But this is not clear
from the semantic point-of-view, and there is no public documentation
about that either.
After discussing this in the mailing-lists [0] and having Flo
In the panic path we have a list of functions to be called, the panic
notifiers - such callbacks perform various actions in the machine's
last breath, and sometimes users want them to run before kdump. We
have the parameter "crash_kexec_post_notifiers" for that. When such
parameter is used, the fun
Hey folks, this is an attempt to improve/refactor the dated panic notifiers
infrastructure. This is strongly based in a suggestion made by Pter Mladek [0]
some time ago, and it's finally ready. Below I'll detail the patch ordering,
testing made, etc.
First, a bit about the reason behind this.
The
On Wed, 27 Apr 2022, Julien Grall wrote:
> On 27/04/2022 17:38, osstest service owner wrote:
> > flight 169781 xen-unstable-smoke real [real]
> > flight 169785 xen-unstable-smoke real-retest [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/169781/
> > http://logs.test-lab.xenproject.org/
flight 169797 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169797/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169775 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169775/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-pair 11 xen-install/dst_host fail in 169756 pass in 169775
test-amd64-amd64-xl-qemut-debian
On Wed, 27 Apr 2022, Penny Zheng wrote:
> > Hi Penny,
> >
> > On 27/04/2022 11:19, Penny Zheng wrote:
> > >>> +/*
> > >>> + * Put free pages on the resv page list after having taken them
> > >>> + * off the "normal" page list, when pages from static memory */
> > >>> +#ifdef CONFIG_STATIC_MEMORY
On Wed, 27 Apr 2022, Julien Grall wrote:
> On 27/04/2022 10:49, Michal Orzel wrote:
> > Function exynos4210_uart_init_preirq defines and sets a variable
> > divisor but does not make use of it. Remove the definition and comment
> > out the assignment as this function already has some TODOs.
> >
>
On Wed, 27 Apr 2022, Roger Pau Monne wrote:
> Introduce a task that uses a FreeBSD 14 (HEAD) snapshot.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Stefano Stabellini
Roger, should you add an entry to MAINTAINERS to set yourself as
maintainer of .cirrus.yml ?
> ---
> .cirrus.yml | 6 ++
flight 169796 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169788 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169788/
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 169793 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, 2022-04-27 at 12:06 +0200, Juergen Gross wrote:
> On 27.04.22 11:49, Michal Orzel wrote:
> > Function schedule_cpu_add defines and sets a variable old_unit but
> > does not make use of it. Remove this variable.
> >
> > Signed-off-by: Michal Orzel
>
> Reviewed-by: Juergen Gross
>
Acked-b
On Mon, 25 Apr 2022, Stefano Stabellini wrote:
> Hi all,
>
> I would like to schedule a meeting to discuss Xen and MISRA C with the
> Xen community. I have a proposal on how to make progress in terms of
> MISRA C adoption in Xen and I would like to get your feedback on it.
>
> The meeting is open
Hi,
On 3/18/22 16:09, Juergen Gross wrote:
> The dcdbas driver is used to call SMI handlers for both, dcdbas and
> dell-smbios-smm. Both drivers allocate a buffer for communicating
> with the SMI handler. The physical buffer address is then passed to
> the called SMI handler via %ebx.
>
> Unfortu
On Wed, Apr 27, 2022 at 10:56:34AM +0200, Jan Beulich wrote:
> On 19.04.2022 17:49, Demi Marie Obenour wrote:
> > This hypercall can be used to get the ESRT from the hypervisor. It
> > returning successfully also indicates that Xen has reserved the ESRT and
> > it can safely be parsed by dom0.
>
flight 169791 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 27/04/2022 19:03, Andrew Cooper wrote:
On 19/04/2022 16:03, David Vrabel wrote:
From: David Vrabel
If the direct map is incorrectly modified with interrupts disabled,
the required TLB flushes are degraded to flushing the local CPU only.
This could lead to very hard to diagnose problems
flight 169767 linux-linus real [real]
flight 169789 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169767/
http://logs.test-lab.xenproject.org/osstest/logs/169789/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
Hi Rahul,
On 27/04/2022 17:12, Rahul Singh wrote:
Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.
Looking at the IORT spec (ARM DEN 0049E), 255 (0xff)
On 19/04/2022 16:03, David Vrabel wrote:
> From: David Vrabel
>
> If the direct map is incorrectly modified with interrupts disabled,
> the required TLB flushes are degraded to flushing the local CPU only.
>
> This could lead to very hard to diagnose problems as different CPUs will
> end up with d
Hi Rahul,
On 27/04/2022 17:14, Rahul Singh wrote:
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
Looking at the spec (ARM IHI 0069H), I can't find a command error named
MAPC_LPI_OFF. Is it something specific to your HW?
not enabled before mapping the collection tabl
flight 169786 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi,
On 27/04/2022 17:15, Rahul Singh wrote:
When a device is deassigned from the domain it is required to remove the
iommu group.
This read wrong to me. We should not need to re-create the IOMMU group
(and call arm_smmu_add_device()) every time a device is re-assigned.
If we don't remove
Hi,
On 27/04/2022 10:49, Michal Orzel wrote:
Function exynos4210_uart_init_preirq defines and sets a variable
divisor but does not make use of it. Remove the definition and comment
out the assignment as this function already has some TODOs.
Signed-off-by: Michal Orzel
---
Commenting out a code
Hi,
On 27/04/2022 10:49, Michal Orzel wrote:
Function omap5_init_time defines and sets a variable den but does not
s/a/the/ I think
make use of it. Remove this variable.
Signed-off-by: Michal Orzel
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 27/04/2022 10:49, Michal Orzel wrote:
Currently function xgene_check_pirq_eoi assignes a return value of
Typo: s/assignes/assigns/ also I think s/a return/the return/
dt_device_get_address to a variable res but does not make use of it.
Fix it by making use of res in a condition checkin
Hi Michal,
On 27/04/2022 10:49, Michal Orzel wrote:
Function arm_smmu_init_context_bank defines and sets a variable
gr0_base but does not make use of it. Remove this variable.
Signed-off-by: Michal Orzel
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Michal,
On 27/04/2022 10:49, Michal Orzel wrote:
Function device_tree_node_compatible defines and sets a variable
mlen but does not make use of it. Remove this variable.
Signed-off-by: Michal Orzel
Reviewed-by: Julien Grall
---
xen/arch/arm/bootfdt.c | 3 ---
1 file changed, 3 delet
Hi,
On 27/04/2022 17:38, osstest service owner wrote:
flight 169781 xen-unstable-smoke real [real]
flight 169785 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169781/
http://logs.test-lab.xenproject.org/osstest/logs/169785/
Regressions :-(
Tests which d
On Wed, Apr 27, 2022 at 12:57:17PM +0200, Jan Beulich wrote:
> The reference "to shadow the resident processes" is applicable to
> domains (potentially) running in shadow mode only. Adjust the
> calculations accordingly. This, however, requires further parameters.
> Since the original function is d
The BAR emulated register definition does not set emu_mask because it
varies depending on bar_flag. If emu_mask is not set, then the BAR is
initialized based on the host value which causes the BAR to be initially
mapped at whatever value the host device was using. Although it does
eventually get m
flight 169781 xen-unstable-smoke real [real]
flight 169785 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/169781/
http://logs.test-lab.xenproject.org/osstest/logs/169785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
When a device is deassigned from the domain it is required to remove the
iommu group.
If we don't remove the group, the next time when we assign
a device, SME and S2CR will not be setup correctly for the device
because of that SMMU fault will be observed.
Signed-off-by: Rahul Singh
---
xen/driv
MAPC_LPI_OFF ITS command error can be reported to software if LPIs are
not enabled before mapping the collection table using MAPC command.
Enable the LPIs using GICR_CTLR.EnableLPIs before mapping the collection
table.
Signed-off-by: Rahul Singh
---
xen/arch/arm/gic-v3.c | 4 ++--
1 file change
On Wed, Apr 27, 2022 at 05:25:35PM +0200, Jan Beulich wrote:
> On 27.04.2022 17:06, Roger Pau Monné wrote:
> > On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
> >> On 27.04.2022 14:45, Roger Pau Monné wrote:
> >>> On Tue, Apr 26, 2022 at 12:05:28PM +0200, Jan Beulich wrote:
> ---
Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.
Signed-off-by: Rahul Singh
---
xen/arch/arm/acpi/domain_build.c | 40
1
Hi Alex,
On 26/04/2022 17:05, Alex Bennée wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fb71fa4c1c..e5a88095f8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2030,7 +2030,7 @@ void __init setup_virt_paging(void)
unsigned int root_order; /* Page order o
flight 169784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Add monitor event that hooks the vmexit handler allowing for both sync and
async monitoring of events. With async monitoring an event is placed on the
monitor ring for each exit and the rest of the vmexit handler resumes normally.
If there are additional monitor events configured those will also pl
Alow specify distinct parts of the fork VM to be reset. This is useful when a
fuzzing operation involves mapping in only a handful of pages that are known
ahead of time. Throwing these pages away just to be re-copied immediately is
expensive, thus allowing to specify partial resets can speed things
Need to separately specify if the reset is for the memory or for the VM state,
or both.
Signed-off-by: Tamas K Lengyel
---
v5: split from the hypervisor-side patch
---
tools/include/xenctrl.h | 3 ++-
tools/libs/ctrl/xc_memshr.c | 7 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
Introduce a task that uses a FreeBSD 14 (HEAD) snapshot.
Signed-off-by: Roger Pau Monné
---
.cirrus.yml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/.cirrus.yml b/.cirrus.yml
index 4ae719136e..c38333e736 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -24,3 +24,9 @@ task:
freebsd_i
Windows Server 2019 Essentials will unconditionally attempt to read
P5_MC_ADDR MSR at boot and throw a BSOD if injected a #GP.
Fix this by adding dummy handling that returns 0 for reads of
P5_MC_ADDR. This seems to be enough to make Windows happy.
Reported-by: Steffen Einsle
Signed-off-by: Roge
flight 169768 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169768/
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
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact reviewability.
Signed-off-by: Jakub Kicinski
---
CC: ull
On Wed, Apr 27, 2022 at 3:07 AM Jan Beulich wrote:
>
> On 27.04.2022 05:46, Tian, Kevin wrote:
> >> From: Lengyel, Tamas
> >> Sent: Friday, March 25, 2022 9:33 PM
> >>
> >> During VM forking and resetting a failed vmentry has been observed due
> >> to the guest non-register state going out-of-syn
Hi,
On 18/04/2022 22:02, Stefano Stabellini wrote:
On Fri, 1 Apr 2022, Julien Grall wrote:
On 24/03/2022 13:37, Ayan Kumar Halder wrote:
/*
* At this point, we know that the instruction is either valid or has
been
* decoded successfully. Thus, Xen should be allowed to ex
On 27.04.2022 17:06, Roger Pau Monné wrote:
> On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
>> On 27.04.2022 14:45, Roger Pau Monné wrote:
>>> On Tue, Apr 26, 2022 at 12:05:28PM +0200, Jan Beulich wrote:
--- unstable.orig/xen/arch/x86/cpu/mwait-idle.c
+++ unstable/xen/arch/
On Wed, Apr 27, 2022 at 03:41:24PM +0200, Jan Beulich wrote:
> On 27.04.2022 14:45, Roger Pau Monné wrote:
> > On Tue, Apr 26, 2022 at 12:05:28PM +0200, Jan Beulich wrote:
> >> From: Artem Bityutskiy
> >>
> >> On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
> >> exclusiv
flight 169783 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 27.04.22 16:25, Raphael Ning wrote:
Hi Juergen,
On 27/04/2022 14:51, Juergen Gross wrote:
When firing special watches (e.g. "@releaseDomain"), they will be
regarded to be valid children of the "/" node. So a domain having
registered a watch for "/" and having the privilege to receive
the sp
Hi Juergen,
On 27/04/2022 14:51, Juergen Gross wrote:
> When firing special watches (e.g. "@releaseDomain"), they will be
> regarded to be valid children of the "/" node. So a domain having
> registered a watch for "/" and having the privilege to receive
> the special watches will receive those s
On 27.04.2022 16:04, Andrew Cooper wrote:
> mfn_valid() is not a trivially simple, and contains an evaluate_nospec() for
> speculative defence. Avoid calling it redundantly, and just store the result
> of the first call.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 27.04.2022 15:16, Andrew Cooper wrote:
> On 25/04/2022 09:32, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -308,11 +308,9 @@ int iommu_map(struct domain *d, dfn_t df
>> d->domain_id, dfn_x(dfn_add(dfn, i)),
>>
mfn_valid() is not a trivially simple, and contains an evaluate_nospec() for
speculative defence. Avoid calling it redundantly, and just store the result
of the first call.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/mm.c | 8 +---
1
On 27.04.2022 15:08, Andrew Cooper wrote:
> On 25/04/2022 09:30, Jan Beulich wrote:
>> Recent changes (likely 5fafa6cf529a ["AMD/IOMMU: have callers specify
>> the target level for page table walks"]) have made Coverity notice a
>> shift count in iommu_pde_from_dfn() which might in theory grow too
1 - 100 of 187 matches
Mail list logo
