Hi,
I've got a report[1] that after some update Linux HVM fails to start with the
error as in the subject. It looks to be caused by some change between
Xen 4.17.3 and 4.17.4. Here the failure is on Linux 6.6.25 (both dom0
and domU), but the 6.1.62 that worked with older Xen before, now fails
too.
flight 185982 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185982/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-vhd 10 host-ping-check-xen fail in 185977 pass in
185982
test-armhf-armhf-xl-qcow2
Various functions have a parameter or local variable called cpuid, but this
triggers a MISRA R5.3 violation because we also have a function called cpuid()
which wraps the real CPUID instruction.
In all these cases, it's a Xen cpu index, which is far more commonly named
just cpu in our code.
flight 185980 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185980/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185975
flight 185977 linux-linus real [real]
flight 185981 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185977/
http://logs.test-lab.xenproject.org/osstest/logs/185981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
I was playing with GCC-14, and gave the new static analyser (-fanalyze) a
try. One of the more serious things it came back with was this:
In file included from ./arch/x86/include/asm/mm.h:10,
from ./include/xen/mm.h:233,
from
flight 185978 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185978/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185968
test-amd64-amd64-libvirt-xsm 15
Hi Henry,
On 11/05/2024 01:56, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error
flight 185975 xen-unstable real [real]
flight 185979 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185975/
http://logs.test-lab.xenproject.org/osstest/logs/185979/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Henry,
On 11/05/2024 01:56, Henry Wang wrote:
Currently the GUEST_MAGIC_BASE in the init-dom0less application is
hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less
DomUs.
Since the guest magic region is now allocated from the hypervisor,
instead of hardcoding the guest
Hi Henry,
On 11/05/2024 10:02, Henry Wang wrote:
+
+ rc = guest_physmap_add_pages(d, gfn, mfn, NR_MAGIC_PAGES);
+ if ( rc )
+ {
+ free_domheap_pages(magic_pg,
get_order_from_pages(NR_MAGIC_PAGES));
+ return rc;
+ }
+
+ return 0;
+}
+
static int __init
Hi Henry,
On 11/05/2024 01:56, Henry Wang wrote:
For use cases such as Dom0less PV drivers, a mechanism to communicate
Dom0less DomU's static data with the runtime control plane (Dom0) is
needed. Since on Arm HVMOP is already the existing approach to address
such use cases (for example the
Hi Julien,
On 5/11/2024 4:46 PM, Julien Grall wrote:
Hi Henry,
On 11/05/2024 01:56, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and
Hi Henry,
On 11/05/2024 01:56, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error
Hi Julien,
On 5/11/2024 4:22 PM, Julien Grall wrote:
Hi Henry,
On 11/05/2024 08:29, Henry Wang wrote:
+ /*
+ * Handle the LR where the physical interrupt is
de-assigned from the
+ * guest before it was EOIed
+ */
+ struct vcpu *v_target =
Hi Henry,
On 11/05/2024 08:29, Henry Wang wrote:
+ /*
+ * Handle the LR where the physical interrupt is de-assigned
from the
+ * guest before it was EOIed
+ */
+ struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
This will return a vCPU
Hi Julien,
On 5/10/2024 4:54 PM, Julien Grall wrote:
Hi,
On 09/05/2024 16:31, Henry Wang wrote:
On 5/9/2024 4:46 AM, Julien Grall wrote:
Hi Henry,
[...]
```
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a775f886ed..d3f9cd2299 100644
--- a/xen/arch/arm/gic.c
+++
17 matches
Mail list logo
