On 06.11.22 22:18, Julien Grall wrote:
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
When a domain has been recognized to have stopped, remove all its
registered watches. This avoids sending watch events to the dead domain
when all the nodes related to it are being removed by the Xen to
Hi Bertrand and Stefano,
On 31/10/2022 16:00, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 31 Oct 2022, at 14:39, Michal Orzel wrote:
>>
>> Hi Bertrand,
>>
>> On 31/10/2022 15:00, Bertrand Marquis wrote:
>>>
>>>
>>> This patch series is a first attempt to check if we could use Yocto in
>>>
flight 174653 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174653/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 35043a5ec05db6aa86b1b380416923fd1c3506e6
baseline version:
ovmf b556f2445c251adf405ac
On 06.11.22 22:08, Julien Grall wrote:
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
Today talloc_free() is not guaranteed to preserve errno, especially in
case a custom destructor is being used.
Change that by renaming talloc_free() to _talloc_free() in talloc.c and
adding a wrapper t
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, November 7, 2022 4:47 AM
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: nd ; Penny Zheng ; Stefano
> Stabellini ; Bertrand Marquis
> ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v6 09/11] xen/arm64: create boot-tim
flight 174650 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsmbroken
test-armhf-armhf-xl-credit2 18 gu
flight 174649 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462
test-arm64-arm64-xl
Hi Julien,
> -Original Message-
> Subject: Re: [PATCH v6 02/11] xen/arm: add iounmap after initrd has been
> loaded in domain_build
>
> (+ Henry)
> I think this wants to be in 4.17. This will avoid Xen to have two
> mappings with different caching attribute (initrd is part of the RAM and
Hi Juergen,
I haven't yet look at the code itself. I wanted to comment on the
external interfaces.
On 01/11/2022 15:28, Juergen Gross wrote:
Make the xenstored internal trace configurable by adding classes
which can be switched on and off independently from each other.
Define the following
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
Instead of using malloc() and friends, let the hashtable implementation
use the talloc framework.
Can you outline why switching to talloc() is better?
Cheers,
--
Julien Grall
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
The accounting for the number of nodes of a domain in an active
transaction is not working correctly, as it allows to create arbitrary
number of nodes. The transaction will finally fail due to exceeding
the number of nodes quota, but before c
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
Instead of special casing the permission handling and watch event
firing for the special watch paths "@introduceDomain" and
"@releaseDomain", use static dummy nodes added to the data base when
starting Xenstore.
A few questions I think need
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
When a domain has been recognized to have stopped, remove all its
registered watches. This avoids sending watch events to the dead domain
when all the nodes related to it are being removed by the Xen tools.
From my understanding, shutdown d
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
Let corrupt() preserve errno in order to be able to simplify error
handling in future.
This is rather easy as the errno value when entering corrupt() is
saved already.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
--
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
tdb_logger() is called by TDB for logging errors. As errno is checked
often after doing the logging, tdb_logger() should preserve errno.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
---
tools/xenstore/xenstored_cor
Hi Juergen,
On 01/11/2022 15:28, Juergen Gross wrote:
Today talloc_free() is not guaranteed to preserve errno, especially in
case a custom destructor is being used.
Change that by renaming talloc_free() to _talloc_free() in talloc.c and
adding a wrapper to talloc.c.
This allows to remove some
Hi,
On 04/11/2022 10:07, Wei Chen wrote:
From: Penny Zheng
setup_fixmap and remove_identity_mapping are two functions that
are used in Xen boot-time code flow. We implement these two
functions for MPU system, in this case, the code flow in head.S
doesn't need to use #ifdef to gate MPU/MMU code
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
From: Penny Zheng
We need some helpers for Xen to enable/disable MPU in boot-time
and runtime. For MPU enable helper, we know that it's an
essential requirement of MPU system. But for MPU disable,
we need to use it for some special situations. For e
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
From: Penny Zheng
Like boot-time page table in MMU system, we need a boot-time
MPU protection region configuration in MPU system so Xen can
fetch code and data from normal memory.
This operation need to access Armv8-R MPU system registers, but
thes
flight 174648 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174648/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b556f2445c251adf405ac966b48c237d20c0d46c
baseline version:
ovmf cc650a0378f86a4980e7a
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
There are lots of MMU specific code in head.S. This code will not
be used in MPU systems. If we use #ifdef to gate them, the code
will become messy and hard to maintain. So we move MMU related
code to head_mmu.S, and keep common code still in head.S.
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
FIXMAP is a special virtual address section for Xen to map some
physical ram or device memory temporarily in initialization for
MMU systems. FIXMAP_ADDR will return a virtual address by index
for special purpose phys-to-virt mapping usage. For example
On 04/11/2022 10:07, Wei Chen wrote:
On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address does not need to be
configu
On 06/11/2022 19:12, Julien Grall wrote:
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
Current EFI boot services support of Arm64 could not
work well for Armv8-R64 system that only has MPU in
EL2. That is because EFI boot services may need some
relocation support or partial PIE/PIC support.
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
Current EFI boot services support of Arm64 could not
work well for Armv8-R64 system that only has MPU in
EL2. That is because EFI boot services may need some
relocation support or partial PIE/PIC support.
I am a bit confused with argument. We have n
flight 174646 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail REGR. vs. 174540
test-armhf-armhf-xl-m
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
The Armv-R architecture profile was designed to support use cases
that have a high sensitivity to deterministic execution. (e.g.
Fuel Injection, Brake control, Drive trains, Motor control etc)
Arm announced Armv8-R in 2013, it is the latest generatio
(+ Henry)
Hi,
On 04/11/2022 10:07, Wei Chen wrote:
domain_build use ioremap_wc to map a new non-cacheable virtual
s/use/uses/
address for initrd. After Xen copy initrd from this address to
guest, this new allocated virtual address has not been unmapped.
So in this patch, we add an iounmap
The pull request you sent on Sun, 6 Nov 2022 06:59:58 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.1-rc4-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6e8c78d32b5c60737bcd71346130f0bf91d6e066
Thank you!
--
Deet-doot-dot, I
Hi,
On 04/11/2022 10:07, Wei Chen wrote:
These two variables are stale variables, they only have declarations
AFAICT, this has always been the case. I am guessing this was because
the header was mostly likely copied from x86...
in config.h, they don't have any definition and no any code is
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
Refer ARM DDI 0487G.b ID072021,
D13.2.86 -
ID_PFR1_EL1, AArch32 Processor Feature Register 1
GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32
One can now enable GICv3 on AArch32 systems. However, ITS is not supported.
s/enable/use/
The
Hi Ayan,
On 04/11/2022 10:04, Ayan Kumar Halder wrote:
These registers are not used by Xen.
Should I define these registers for the sake of completeness (to be in
parity with AArch64) ?
Yes. I would at least expect the MISR might end up to be used if we were
supporting some interrupts contro
flight 174645 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462
test-arm64-arm64-xl
On 03/11/2022 15:08, Michal Orzel wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
The title is a bit ambiguous given that the previous patches were also defining
GIC registers.
Maybe adding "remaining" would result in a better commit title.
Refer "Arm IHI 0069H ID020922"
On 03/11/2022 12:35, Michal Orzel wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
Refer "Arm IHI 0069H ID020922",
12.7.1 - Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
12.7.2 - Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
Commit msg lik
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/arm32/sysregs.h
b/xen/arch/arm/include/asm/arm32/sysregs.h
index 6841d5de43..8a9a014bef 100644
--- a/xen/arch/arm/include/asm/arm32/sysregs.h
+++ b/xen/arch/arm/include/asm/arm32/sysregs.h
@@ -62,6 +62,
Hi,
On 03/11/2022 12:13, Michal Orzel wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR[31:0].
On 02/11/2022 10:41, Michal Orzel wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
Aarch32 systems. Thus, the prototype needs to change to reflect this.
NIT: prototype means function declaration.
vgic_v3
Hi Ayan,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
Signed-off-by: Ayan Kumar Hald
Hi Ayan,
In the title you are using AArch32 but below you are using...
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
v->arch.vmpidr is assigned to uint64_t variable. This is to enable left shifts
for Aarch32 so that one can extract affinity bits.
... Aarch32. The naming also seem to be incons
Hi Xenia,
On 02/11/2022 10:36, Xenia Ragiadakou wrote:
Hi Julien,
On 11/2/22 12:10, Julien Grall wrote:
Hi Xenia,
On 02/11/2022 09:57, Xenia Ragiadakou wrote:
On 11/2/22 10:46, Julien Grall wrote:
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kuma
Hi Ayan,
To me the title and the explaination below suggests...
On 04/11/2022 16:23, Ayan Kumar Halder wrote:
From: Ayan Kumar Halder
Refer ARM DDI 0487I.a ID081822, B2.2.1
"Requirements for single-copy atomicity
- A read that is generated by a load instruction that loads a single
general-pu
flight 174647 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174647/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc650a0378f86a4980e7a0d37fef90d46d33afe1
baseline version:
ovmf eff44c008d99eca6e3700
flight 174641 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174641/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174636
test-amd64-i386-xl-qemuu-win7-amd64
flight 174643 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174643/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174632
test-armhf-armhf-libvirt-raw 15 saveresto
On 06.11.22 10:57, osstest service owner wrote:
flight 174642 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build
flight 174639 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462
test-arm64-arm64-xl
flight 174642 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 174540
test-armhf-armhf-xl-c
48 matches
Mail list logo
