The reserved heap, or statically configured heap, refers to parts
of RAM reserved in the beginning for heap. Like the static memory
allocation, such reserved heap regions are reserved by configuration
in the device tree using physical address ranges.
This feature is useful to run Xen on Arm MPU sy
This commit firstly adds a global variable `reserved_heap`.
This newly introduced global variable is set at the device tree
parsing time if the reserved heap ranges are defined in the device
tree chosen node.
For Arm32, In `setup_mm`, if the reserved heap is enabled, we use
the reserved heap regio
This commit introduces the reserved heap memory, which is parts of RAM
reserved in the beginning of the boot time for heap.
A new boolean field `xen_heap` in `struct membank` is added to store the
configuration telling if the memory bank is reserved as heap through
`xen,static-mem` property in dev
Hi Jan,
> On 23 Aug 2022, at 17:15, Jan Beulich wrote:
>
> On 23.08.2022 16:41, Bertrand Marquis wrote:
>>
>>
>>> On 23 Aug 2022, at 15:31, Jan Beulich wrote:
>>>
>>> On 23.08.2022 15:34, Bertrand Marquis wrote:
> On 23 Aug 2022, at 13:33, Jan Beulich wrote:
> On 23.08.2022 12:24, B
On 23.08.2022 17:56, Bertrand Marquis wrote:
>> On 23 Aug 2022, at 16:45, Jan Beulich wrote:
>> On 23.08.2022 17:09, Bertrand Marquis wrote:
>>> How about moving those to a xen-acpi.h header and include that one in xen.h
>>> ?
>>
>> In principle okay, if there wasn't the need for HVM_MAX_VCPUS. W
On Thu, Aug 18, 2022 at 3:45 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 18 Aug 2022, at 11:55, Jens Wiklander wrote:
> >
> > SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
> > registers and result registers for the SMC and HVC instructions.
> >
> > Arm Firmware Framework
Hi,
On Thu, Aug 18, 2022 at 7:31 PM Julien Grall wrote:
>
> Hi Bertrand,
>
> On 18/08/2022 16:55, Bertrand Marquis wrote:
> >> On 18 Aug 2022, at 15:31, Julien Grall wrote:
> +/*
> + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
> + *struc
Hi Jens,
On 18/08/2022 12:55, Jens Wiklander wrote:
> Moves the two helper functions regpair_to_uint64() and
> uint64_to_regpair() from xen/arch/arm/tee/optee.c to the common arm
> specific regs.h.
>
Would be good to add a justification that these helpers will be needed by
subsequent patches.
Al
Hi Bertrand,
On 23/08/2022 11:34, Bertrand Marquis wrote:
On 12 Aug 2022, at 10:17, Julien Grall wrote:
Hi Rahul,
On 11/08/2022 16:42, Rahul Singh wrote:
When devices are deassigned/assigned, SMMU global fault is observed
because SMEs are freed in detach function and not allocated again w
Hi,
On 16/08/2022 07:40, Jan Beulich wrote:
On 16.08.2022 04:36, Penny Zheng wrote:
+void free_domstatic_page(struct page_info *page)
+{
+struct domain *d = page_get_owner(page);
+bool drop_dom_ref;
+
+if ( unlikely(!d) )
+{
+ASSERT_UNREACHABLE();
+printk("The ab
Hi Penny,
On 16/08/2022 03:36, Penny Zheng wrote:
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not
On 24-03-22, 06:12, Juergen Gross wrote:
> For a rather long time we were using "normal" user pages for this purpose,
> which were just locked into memory for doing the hypercall.
>
> Unfortunately there have been very rare problems with that approach, as
> the Linux kernel can set a user page rel
On 24.08.22 11:03, Julien Grall wrote:
Hi,
On 16/08/2022 07:40, Jan Beulich wrote:
On 16.08.2022 04:36, Penny Zheng wrote:
+void free_domstatic_page(struct page_info *page)
+{
+ struct domain *d = page_get_owner(page);
+ bool drop_dom_ref;
+
+ if ( unlikely(!d) )
+ {
+ ASSER
Hi Jens,
On 18/08/2022 12:55, Jens Wiklander wrote:
> Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
>
> This commit brings in only the parts needed to negotiate FF-A version
> number with guest and SPMC.
>
> A guest configuration variable "ffa_ena
Hi Juergen,
On 24/08/2022 10:27, Juergen Gross wrote:
On 24.08.22 11:03, Julien Grall wrote:
Hi,
On 16/08/2022 07:40, Jan Beulich wrote:
On 16.08.2022 04:36, Penny Zheng wrote:
+void free_domstatic_page(struct page_info *page)
+{
+ struct domain *d = page_get_owner(page);
+ bool drop_d
On 24.08.22 11:31, Julien Grall wrote:
Hi Juergen,
On 24/08/2022 10:27, Juergen Gross wrote:
On 24.08.22 11:03, Julien Grall wrote:
Hi,
On 16/08/2022 07:40, Jan Beulich wrote:
On 16.08.2022 04:36, Penny Zheng wrote:
+void free_domstatic_page(struct page_info *page)
+{
+ struct domain *d
Hi Penny,
On 16/08/2022 03:36, Penny Zheng wrote:
Penny Zheng (9):
xen/arm: rename PGC_reserved to PGC_static
This was committed by Jan a week ago. And ...
xen: do not merge reserved pages in free_heap_pages()
xen: add field "flags" to cover all internal CDF_XXX
... I have commit
On 24.08.22 11:19, Viresh Kumar wrote:
On 24-03-22, 06:12, Juergen Gross wrote:
For a rather long time we were using "normal" user pages for this purpose,
which were just locked into memory for doing the hypercall.
Unfortunately there have been very rare problems with that approach, as
the Linu
flight 172746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
builds a warning seems to be appropriate when hitting one.
In order not to flood the console in reproducible cases, introduce
WARN_ONCE() to be used in this case.
Signed-off-by: Juergen Gross
---
Notice for the release manage
Hi Juergen,
Thanks for sending the patch quickly :).
On 24/08/2022 11:22, Juergen Gross wrote:
Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
builds a warning seems to be appropriate when hitting one.
In order not to flood the console in reproducible cases, introduce
WA
On 24.08.2022 12:22, Juergen Gross wrote:
> Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
> builds a warning seems to be appropriate when hitting one.
I disagree, for two reasons: This violates the implication of NDEBUG
meaning ASSERT() and friends expand to no actual code
Hi,
> On 24 Aug 2022, at 11:35, Jan Beulich wrote:
>
> On 24.08.2022 12:22, Juergen Gross wrote:
>> Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
>> builds a warning seems to be appropriate when hitting one.
>
> I disagree, for two reasons: This violates the implication
On 24.08.2022 11:03, Julien Grall wrote:
> Hi,
>
> On 16/08/2022 07:40, Jan Beulich wrote:
>> On 16.08.2022 04:36, Penny Zheng wrote:
>>> +void free_domstatic_page(struct page_info *page)
>>> +{
>>> +struct domain *d = page_get_owner(page);
>>> +bool drop_dom_ref;
>>> +
>>> +if ( unlik
On 24.08.22 12:35, Jan Beulich wrote:
On 24.08.2022 12:22, Juergen Gross wrote:
Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
builds a warning seems to be appropriate when hitting one.
I disagree, for two reasons: This violates the implication of NDEBUG
meaning ASSERT(
All encountered while debugging a regression in Xen 4.17.
They're all very trivial, and addressing low hanging fruit.
Andrew Cooper (4):
x86/hvmloader: SMP improvements
x86/hvmloader: Don't build as PIC/PIE
x86/hvmloader: Don't override stddef.h
x86/hvmloader: Move various helpers to bein
* Use MOV CR instead of LMSW. LMSW has no decode assist at all on AMD CPUs,
forcing us to fully emulate the instruction.
* Use __attribute__((used)) to fix the comment about ap_start().
* Have ap_start() perform a self-INIT for APs, rather than having boot_cpu()
do it. This is marginally
The IO port, MSR, IO-APIC and LAPIC accessors compile typically to single or
pairs of instructions, which is less overhead than even the stack manipulation
to call the helpers.
Move the implementations from util.c to being static inlines in util.h
In addition, turn ioapic_base_address into a cons
HVMLoader is not relocatable in memory, and 32bit PIC code has a large
overhead. Build it as non-relocatable.
Bloat-o-meter reports a net:
add/remove: 0/0 grow/shrink: 3/107 up/down: 14/-3370 (-3356)
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Since c/s 73b13705af7c ("firmware: provide a stand alone set of headers"),
we've had an implementation of offsetof() which isn't undefined behaviour.
Actually use it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/firmware/hvm
flight 172744 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172744/
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 24.08.2022 12:45, Juergen Gross wrote:
> On 24.08.22 12:35, Jan Beulich wrote:
>> On 24.08.2022 12:22, Juergen Gross wrote:
>>> Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
>>> builds a warning seems to be appropriate when hitting one.
>>
>> I disagree, for two reasons:
On 24/08/2022 11:35, Jan Beulich wrote:
> On 24.08.2022 12:22, Juergen Gross wrote:
>> Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
>> builds a warning seems to be appropriate when hitting one.
> I disagree, for two reasons: This violates the implication of NDEBUG
> meanin
Hi Greg,
stable kernels 5.18 and 5.15 seem to be missing upstream patch
c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
Could you plea
On 24.08.22 13:12, Jan Beulich wrote:
On 24.08.2022 12:45, Juergen Gross wrote:
On 24.08.22 12:35, Jan Beulich wrote:
On 24.08.2022 12:22, Juergen Gross wrote:
Hitting an ASSERT_UNREACHABLE() is always wrong, so even in production
builds a warning seems to be appropriate when hitting one.
I
Andrew Cooper writes:
> On 24/08/2022 10:19, Viresh Kumar wrote:
>> On 24-03-22, 06:12, Juergen Gross wrote:
>>> For a rather long time we were using "normal" user pages for this purpose,
>>> which were just locked into memory for doing the hypercall.
>>>
>>> Unfortunately there have been very
Juergen Gross writes:
> [[PGP Signed Part:Undecided]]
> On 24.08.22 11:19, Viresh Kumar wrote:
>> On 24-03-22, 06:12, Juergen Gross wrote:
>>> For a rather long time we were using "normal" user pages for this purpose,
>>> which were just locked into memory for doing the hypercall.
>>>
>>> Unfor
On 23/08/2022 13:01, Jan Beulich wrote:
> On 23.08.2022 12:48, Andrew Cooper wrote:
>> On 23/08/2022 10:27, Jan Beulich wrote:
>>> On 23.08.2022 10:59, Andrew Cooper wrote:
On 23/08/2022 07:42, Jan Beulich wrote:
> +++ b/xen/arch/x86/cpuid.c
> @@ -1142,7 +1142,7 @@ void guest_cpuid(con
On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> Hi Greg,
>
> stable kernels 5.18 and 5.15 seem to be missing upstream patch
> c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
> error_en
On 23/08/2022 13:01, Jan Beulich wrote:
> On 23.08.2022 12:48, Andrew Cooper wrote:
>> On 23/08/2022 10:27, Jan Beulich wrote:
>>> On 23.08.2022 10:59, Andrew Cooper wrote:
On 23/08/2022 07:42, Jan Beulich wrote:
But this is going to further complicate my several-year-old series
tryi
Hi Julien,
> On 23 Aug 2022, at 11:05 am, Julien Grall wrote:
>
> Hi,
>
> On 19/08/2022 11:02, Rahul Singh wrote:
>> Introduce a new "xen,enhanced" dom0less property value "evtchn" to
>> enable/disable event-channel interfaces for dom0less guests.
>
> The documentation in docs/misc/arm/device-
On 24/08/2022 07:00, Jan Beulich wrote:
> On 23.08.2022 12:48, Andrew Cooper wrote:
>> On 23/08/2022 10:27, Jan Beulich wrote:
>>> On 23.08.2022 10:59, Andrew Cooper wrote:
But this is going to further complicate my several-year-old series
trying to get Xen's XSTATE handling into a positi
On 24.08.2022 14:19, Andrew Cooper wrote:
> On 24/08/2022 07:00, Jan Beulich wrote:
>> On 23.08.2022 12:48, Andrew Cooper wrote:
>>> On 23/08/2022 10:27, Jan Beulich wrote:
On 23.08.2022 10:59, Andrew Cooper wrote:
> But this is going to further complicate my several-year-old series
>
flight 172749 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172749/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
> On 24 Aug 2022, at 08:37, Jan Beulich wrote:
>
> On 23.08.2022 17:56, Bertrand Marquis wrote:
>>> On 23 Aug 2022, at 16:45, Jan Beulich wrote:
>>> On 23.08.2022 17:09, Bertrand Marquis wrote:
How about moving those to a xen-acpi.h header and include that one in
xen.h ?
>>>
>>> I
Hi Jan,
> On 24 Aug 2022, at 13:33, Jan Beulich wrote:
>
> While Arm64 does so uniformly, for Arm32 only strchr() currently handles
> this properly. Add the necessary conversion also to strrchr(), memchr(),
> and memset().
>
> As to the placement in memset(): Putting the new insn at the beginni
flight 172750 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
While Arm64 does so uniformly, for Arm32 only strchr() currently handles
this properly. Add the necessary conversion also to strrchr(), memchr(),
and memset().
As to the placement in memset(): Putting the new insn at the beginning
of the function is apparently deemed more "obvious". It could be pl
On 24/08/2022 13:15, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
Please let me know your view on this.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bfe7bc6b36..a1e23eee59 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3562,12 +35
On 24.08.2022 14:43, Bertrand Marquis wrote:
>
>
>> On 24 Aug 2022, at 08:37, Jan Beulich wrote:
>>
>> On 23.08.2022 17:56, Bertrand Marquis wrote:
On 23 Aug 2022, at 16:45, Jan Beulich wrote:
On 23.08.2022 17:09, Bertrand Marquis wrote:
> How about moving those to a xen-acpi.h he
Hi Jan,
> On 24 Aug 2022, at 14:05, Jan Beulich wrote:
>
> On 24.08.2022 14:43, Bertrand Marquis wrote:
>>
>>
>>> On 24 Aug 2022, at 08:37, Jan Beulich wrote:
>>>
>>> On 23.08.2022 17:56, Bertrand Marquis wrote:
> On 23 Aug 2022, at 16:45, Jan Beulich wrote:
> On 23.08.2022 17:09, B
On 24.08.22 13:22, Alex Bennée wrote:
Andrew Cooper writes:
On 24/08/2022 10:19, Viresh Kumar wrote:
On 24-03-22, 06:12, Juergen Gross wrote:
For a rather long time we were using "normal" user pages for this purpose,
which were just locked into memory for doing the hypercall.
Unfortunately
On 24.08.22 13:47, Alex Bennée wrote:
Juergen Gross writes:
[[PGP Signed Part:Undecided]]
On 24.08.22 11:19, Viresh Kumar wrote:
On 24-03-22, 06:12, Juergen Gross wrote:
For a rather long time we were using "normal" user pages for this purpose,
which were just locked into memory for doing t
Hello all,
The purpose of this RFC is to get feedback about a new acquire resource that
exposes vcpu statistics for a given domain. The current mechanism to get those
statistics is by querying the hypervisor. This mechanism relies on a hypercall
and holds the domctl spinlock during its execution.
This commit proposes a new mechanism to query the RUNSTATE_running counter for
a given vcpu from a dom0 userspace application. This commit proposes to expose
that counter by using the acquire_resource interface. The current mechanism
relies on the XEN_DOMCTL_getvcpuinfo and holds a single global do
Add a demostration tool that uses the stats_table resource to
query vcpus' RUNSTATE_running counter for a DomU.
Signed-off-by: Matias Ezequiel Vara Larsen
---
Changes in v1:
- change the name of the tool to xen-vcpus-stats
- set command line parameters in the same order that are passed
- remove h
Hi Henry,
On 24/08/2022 09:31, Henry Wang wrote:
> diff --git a/docs/misc/arm/device-tree/booting.txt
> b/docs/misc/arm/device-tree/booting.txt
> index 98253414b8..e064f64d9a 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -378,3 +378,49 @@
On 24.08.22 14:10, Greg Kroah-Hartman wrote:
On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
Hi Greg,
stable kernels 5.18 and 5.15 seem to be missing upstream patch
c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
This is a prerequisite patch for 64cbd0acb
flight 172741 xen-unstable real [real]
flight 172751 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172741/
http://logs.test-lab.xenproject.org/osstest/logs/172751/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Backport Linux commit dc898eb84b25c39ea46f28c48a169bdbd0e2c7e0
iommu/arm-smmu-v3: Fix l1 stream table size in the error message
Original commit message:
iommu/arm-smmu-v3: Fix l1 stream table size in the error message
The actual size of level-1 stream table is l1size. This looks like
a
This patch series merge the applicable Linux fixes to Xen.
Rahul Singh (10):
xen/arm: smmuv3: Fix l1 stream table size in the error message
xen/arm: smmuv3: Fix endianness annotations
xen/arm: smmuv3: Ensure queue is read after updating prod pointer
xen/arm: smmuv3: Move definitions to a h
Backport Linux commit 376cdf66f62444a1b4ebb393bab9fc44966f9b49
"iommu/arm-smmu-v3: Fix endianness annotations"
Original commit message:
When building with C=1, sparse reports some issues regarding
endianness annotations:
arm-smmu-v3.c:221:26: warning: cast to restricted __le64
arm
Backport Linux commit affa909571b0036b5d46aeff940ad4358f4abe1d
"iommu/arm-smmu-v3: Remove unnecessary oom message"
Original commit message:
iommu/arm-smmu-v3: Remove unnecessary oom message
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Backport Linux commit 86d2d9214880c1879cb0ff466cce2fcd9c853e44
"iommu/arm-smmu-v3: Remove the page 1 fixup"
Original commit message:
iommu/arm-smmu-v3: Remove the page 1 fixup
Since we now keep track of page 1 via a separate pointer that
already encapsulates aliasing to page 0 as nece
Backport Linux commit e0bb4b73540495111ff2723e41cf5add2f031021
Original commit message:
iommu/arm-smmu-v3: Remove the unused fields for PREFETCH_CONFIG
command
Per SMMUv3 spec, there is no Size and Addr field in the
PREFETCH_CONFIG command and they're not used by the driver.
R
Backport Linux commit d56d5162e31760ab5b6ffe592aea8494d5567220
"iommu/arm-smmu-v3: Change *array into *const array"
Original commit message:
iommu/arm-smmu-v3: Change *array into *const array
Fix checkpatch warning in arm-smmu-v3.c:
static const char * array should probably be static
Backport Linux commit 98b64741d61124a12fb05a7595acb1fd6c1dc55d
"iommu/arm-smmu-v3: Avoid open coded arithmetic in memory allocation"
Original commit message:
iommu/arm-smmu-v3: Avoid open coded arithmetic in memory allocation
kmalloc_array()/kcalloc() should be used to avoid potential over
Backport Linux commit 5a1ab5c0299a7b3b9e7ec52c327f44d98b8e001d
"iommu/arm-smmu-v3: Fix fall-through warning for Clang"
Original commit message:
iommu/arm-smmu-v3: Fix fall-through warning for Clang
Fix the following fallthrough warning (arm64-randconfig with Clang):
drivers/iommu/arm/
Backport Linux commit a76a3f2c936b1f046bfc0c5982c958b16bfe
"Ensure queue is read after updating prod pointer"
Original commit message:
iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer
Reading the 'prod' MMIO register in order to determine whether or
not there is
Allow sharing structure definitions with the upcoming virtual
smmuv3 support for Arm SMMUv3, by moving them to a separate header.
Code was imported from Linux source code so keep the Linux syntax.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/arm/smmu-v3.c | 376 +--
On 20.08.2022 19:30, Rustam Subkhankulov wrote:
> Version: 6.0-rc1
>
> Description:
>
> In function 'privcmd_ioctl_dm_op' (drivers/xen/privcmd.c: 615)return
> value of 'kcalloc' with GFP_KERNEL flag is assigned to "pages"
> variable. GFP_KERNEL flag does not guarantee, that the return value
> wi
On 24.08.22 15:59, Jan Beulich wrote:
On 20.08.2022 19:30, Rustam Subkhankulov wrote:
Version: 6.0-rc1
Description:
In function 'privcmd_ioctl_dm_op' (drivers/xen/privcmd.c: 615)return
value of 'kcalloc' with GFP_KERNEL flag is assigned to "pages"
variable. GFP_KERNEL flag does not guarantee,
Hi,
I am porting xen hypervisor on rpi4 with yocto kirkstone sources. Followed
the basic steps to build xen-image-minimal & xen-guest-image-minimal. I
could flash sd card with xen minimal image & could see dom0 up. I copied
"Image", "xen-guest-image-minimal" .ext3 file & guest.cfg to "/home/root".
On 24.08.2022 12:59, Andrew Cooper wrote:
> --- a/tools/firmware/hvmloader/smp.c
> +++ b/tools/firmware/hvmloader/smp.c
> @@ -35,9 +35,9 @@ asm (
> "mov %cs,%ax \n"
> "mov %ax,%ds \n"
> "lgdt gdt_desr-ap_boot_start\n"
> -"xor %ax
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Fix that by calling unlock_pages only if lock_pages() was at least
partially successful.
Cc:
Fixes: ab520be8cd5d ("xen/privcmd: Add IOCTL_PRIVCMD_DM_OP")
Reported-b
Hi Vipul,
> On 24 Aug 2022, at 15:16, Vipul Suneja wrote:
>
> Hi,
>
> I am porting xen hypervisor on rpi4 with yocto kirkstone sources. Followed
> the basic steps to build xen-image-minimal & xen-guest-image-minimal. I could
> flash sd card with xen minimal image & could see dom0 up. I copied
Hi Julien,
> On 24 Aug 2022, at 1:59 pm, Julien Grall wrote:
>
>
>
> On 24/08/2022 13:15, Rahul Singh wrote:
>> Hi Julien,
>
> Hi Rahul,
>
>> Please let me know your view on this.
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index bfe7bc6b36..a1e23eee59 100644
Hi Julien,
> On 23 Aug 2022, at 10:32 am, Julien Grall wrote:
>
> Hi Rahul,
>
> On 19/08/2022 11:02, Rahul Singh wrote:
>> Introduce a new sub-node under /chosen node to establish static event
>> channel communication between domains on dom0less systems.
>> An event channel will be created befo
This patch series is a first attempt to check if we could use Yocto in
gitlab ci to build and run xen on qemu for arm, arm64 and x86.
The first patch is making sure build-yocto.sh is not catched by
gitignore.
The second patch is creating a container with all elements required to
build Yocto, a ch
...because there are some script in automation corresponding to the
build-* filter (build-test.sh and build-each-commit.sh)
Signed-off-by: Bertrand Marquis
---
Changes in v1:
- instead of removing build-*, replace it by build-*/ (suggested by Jan)
- rename patch accordingly
---
.gitignore | 2 +-
Create yocto containers for kirkstone with a builder step to fill the
yocto cache by running the build script once.
Those containers depend on the kirkstone.dockerfile container to be
created and use it as base image.
To run a build test on one image the following command must be called
inside the
Add a container suitable to run yocto kirkstone build based on ubuntu
22.04. It contains all packages required by Yocto and a checkout of the
layers required to build Xen with Yocto.
Add a build script to build and run xen on qemu using Yocto.
The script supports arm32, arm64 and x86_64 and checks
Add make clean support to remove the containers from the local docker
registry:
- make clean: remove all images
- clean-yocto/kirkstone-qemuarm: remove yocto kirkstone for qemuarm
image
Signed-off-by: Bertrand Marquis
---
Changes in v1:
- patch added
---
automation/build/Makefile | 17 ++
Hi Rahul,
On 24/08/2022 14:53, Rahul Singh wrote:
Backport Linux commit dc898eb84b25c39ea46f28c48a169bdbd0e2c7e0
iommu/arm-smmu-v3: Fix l1 stream table size in the error message
We have a tag for this (see Origin). If you use it, then...
Original commit message:
You don't need to add "ori
Hi,
On 24/08/2022 14:53, Rahul Singh wrote:
Allow sharing structure definitions with the upcoming virtual
smmuv3 support for Arm SMMUv3, by moving them to a separate header.
I haven't seen this feature posted yet. So I can't tell how this will
allow sharing. I guess you will introduce a new f
flight 172753 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172743 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
When Xen is compiled for x86 on an arm machine, libacpi build is failing
due to a wrong include path:
- arch-x86/xen.h includes xen.h
- xen.h includes arch-arm.h (as __i386__ and __x86_64__ are not defined
but arm ones are).
To solve this issue move XEN_ACPI_ definitions in a new header
guest-acpi
On 24/08/2022 15:42, Rahul Singh wrote:
On 24 Aug 2022, at 1:59 pm, Julien Grall wrote:
On 24/08/2022 13:15, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
Please let me know your view on this.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bfe7bc6b36..a1e23eee59 1
Hi Julien
> On 24 Aug 2022, at 4:36 pm, Julien Grall wrote:
>
> On 24/08/2022 15:42, Rahul Singh wrote:
>>> On 24 Aug 2022, at 1:59 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 24/08/2022 13:15, Rahul Singh wrote:
Hi Julien,
>>>
>>> Hi Rahul,
>>>
Please let me know your view on thi
flight 172752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172752/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
Juergen Gross writes:
> [[PGP Signed Part:Undecided]]
> On 24.08.22 13:22, Alex Bennée wrote:
>> Andrew Cooper writes:
>>
>>> On 24/08/2022 10:19, Viresh Kumar wrote:
On 24-03-22, 06:12, Juergen Gross wrote:
> For a rather long time we were using "normal" user pages for this purpose,
flight 172745 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
Hi Bertrand,
Thanks for your response!
I builded the guest image on yocto kirkstone source which has FSTYPE ext3.
Guest image generated is xen-guest-image-minimal-raspberrypi4-64.ext3.
Below is the content of guest.cfg file
* kernel = "/home/root/Image" *
* cmdline = "console=hvc0 earlyprint
Hello,
On Wed, 24 Aug 2022 08:02:40 +0200 Juergen Gross wrote:
>
> [-- Attachment #1.1.1: Type: text/plain, Size: 4312 bytes --]
>
> On 24.08.22 02:20, Marek Marczykowski-Górecki wrote:
> > FWIW, I hit this issue twice already in this week CI run, while it never
> > happened before. The differ
On 24.08.22 17:26, Juergen Gross wrote:
Hello Juergen
> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
> potentially with pages being NULL, leading to a NULL dereference.
>
> Fix that by calling unlock_pages only if lock_pages() was at least
> partially successful.
>
> Cc:
>
Hi Jan,
I'm sorry I didn't get where in /sys/firmware you'd like to take a look at.
Sometimes when I power the laptop off I can see it's crashing somewhere in
ACPI/weird address issue
Is there anyone else struggling with AMD Ryzen 6000 on Xen?
flight 172747 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172756 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
+ Roger
On Wed, 24 Aug 2022 17:44:42 + SeongJae Park wrote:
> Hello,
>
> On Wed, 24 Aug 2022 08:02:40 +0200 Juergen Gross wrote:
>
> >
> > [-- Attachment #1.1.1: Type: text/plain, Size: 4312 bytes --]
> >
> > On 24.08.22 02:20, Marek Marczykowski-Górecki wrote:
> > > FWIW, I hit this is
1 - 100 of 114 matches
Mail list logo
