flight 136270 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
flight 136156 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136156/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 135931
flight 136258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
flight 136175 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136175/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 133596
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid guests-nbd-mirror/debian
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
> On 14. May 2019, at 18:09, Sironi, Filippo wrote:
>
>> On 14. May 2019, at 17:26, Christian Borntraeger
>> wrote:
>>
>>> On 14.05.19 17:16, Filippo Sironi wrote:
>>> Start populating /sys/hypervisor with KVM entries when we're running on
>>> KVM. This is to replicate functionality that's
flight 136241 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
Hi,
On 5/14/19 5:19 PM, Paul Durrant wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 13 May 2019 09:11
To: Paul Durrant
Cc: Brian Woods ; Suravee Suthikulpanit
; Julien
Grall ; Andrew Cooper ; Roger
Pau Monne
; Wei Liu ; Kevin Tian
; Stefano
Stabellini ;
flight 136173 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136173/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd e45876ac9f0ee913fcc73cfa00e409a5a461dbfb
baseline version:
freebsd
flight 136132 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 134015
Tests which did not
flight 136138 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
flight 136152 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 127792
build-amd64
flight 136116 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136116/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair18 guests-nbd-mirror/debian fail REGR. vs. 133580
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volodymyr Babchuk
Suggested-by: Andrii Anisov
---
xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} | 0
1 file changed, 0
Ease up XEN configuration for non-standard builds, like
armv8 tiny config.
Signed-off-by: Volodymyr Babchuk
---
Makefile | 4
xen/Makefile | 3 +++
2 files changed, 7 insertions(+)
diff --git a/Makefile b/Makefile
index 829ac63741..ef1ea44ef1 100644
--- a/Makefile
+++ b/Makefile
@@
flight 136227 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
On Tue, Apr 16, 2019 at 08:21:39AM +0100, Wei Liu wrote:
> We will soon provide this new capability to humans and automated
> systems.
>
> The default behaviour is retained: tip and base are passed by Gitlab
> CI.
>
> Signed-off-by: Wei Liu
Swore I replied to this already. I apologize.
>>> On 14.05.19 at 18:13, wrote:
> All its callers live inside #ifdef CONFIG_HVM sections.
>
> Signed-off-by: Razvan Cojocaru
Thanks!
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -514,6 +514,7 @@ static inline unsigned long mfn_to_gfn(struct domain *d,
> mfn_t
On 14.05.19 18:09, Sironi, Filippo wrote:
>> Isnt kvm_para_available a function that is defined in the context of the HOST
>> and not of the guest?
>
> No, kvm_para_available is defined in the guest context.
> On x86, it checks for the presence of the KVM CPUID leafs.
>
Right you are, I
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 May 2019 09:11
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien
> Grall ; Andrew Cooper ;
> Roger Pau Monne
> ; Wei Liu ; Kevin Tian
> ; Stefano
> Stabellini ; xen-devel
>
> Subject:
On 5/14/19 6:42 PM, Jan Beulich wrote:
On 23.04.19 at 16:30, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
mm_write_unlock(>lock);
}
+int altp2m_get_effective_entry(struct p2m_domain
All its callers live inside #ifdef CONFIG_HVM sections.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/p2m.c | 72 +++
xen/include/asm-x86/p2m.h | 2 ++
2 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 May 2019 08:36
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew
> Cooper ; Roger Pau Monne ;
> Wei Liu
> ; Kevin Tian ; xen-devel
>
> Subject: Re: [PATCH 2/5] iommu / x86: move call
> On 14. May 2019, at 17:26, Christian Borntraeger
> wrote:
>
>
>
> On 14.05.19 17:16, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>>
>> Start with
Hello all,
in the function advance_pc in xen/arch/arm/traps.c in line 1655,1656 you
can find the following code:
1655 BUG_ON( (!psr_mode_is_32bit(cpsr)||!(cpsr_THUMB))
1656 && (cpsr_IT_MASK) );
This code seems to check that we are not running in thumb mode and that
the
>>> On 23.04.19 at 16:30, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
> mm_write_unlock(>lock);
> }
>
> +int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t
>
On Tue, May 14, 2019 at 04:44:19PM +0200, Olaf Hering wrote:
> Am Tue, 14 May 2019 15:38:55 +0100
> schrieb Wei Liu :
>
> > > While it is easy for the resume path, doing the same in the suspend path
> > > needs more changes. libxl__domain_suspend_device_model would need to
> > > receive
> > >
Start populating /sys/hypervisor with KVM entries when we're running on
KVM. This is to replicate functionality that's available when we're
running on Xen.
Start with /sys/hypervisor/uuid, which users prefer over
/sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual
machine,
Long-time Xen HVM and Xen PV users are missing /sys/hypervisor entries when
moving to KVM. One report is about getting the VM UUID. The VM UUID can
already be retrieved using /sys/devices/virtual/dmi/id/product_uuid. This has
two downsides: (1) it requires root privileges and (2) it is only
On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
as VM UUID.
Signed-off-by: Filippo Sironi
---
arch/x86/kernel/kvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 5c93a65ee1e5..441cab08a09d 100644
---
On 14.05.19 17:16, Filippo Sironi wrote:
> Start populating /sys/hypervisor with KVM entries when we're running on
> KVM. This is to replicate functionality that's available when we're
> running on Xen.
>
> Start with /sys/hypervisor/uuid, which users prefer over
>
Am Tue, 14 May 2019 15:38:55 +0100
schrieb Wei Liu :
> > While it is easy for the resume path, doing the same in the suspend path
> > needs more changes. libxl__domain_suspend_device_model would need to receive
> > the callback and set it if a device model is active.
>
> What do you mean here?
On Tue, May 14, 2019 at 10:14:52AM +0200, Olaf Hering wrote:
> Am Tue, 14 May 2019 10:05:58 +0200
> schrieb Olaf Hering :
>
> > @@ -459,7 +461,9 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid,
> > int suspend_cancel)
> > goto out;
> > }
> >
> > -if (type ==
>>> On 14.05.19 at 16:22, wrote:
> Provide information on what is expected from the build system
> regarding python.
>
> Signed-off-by: Wei Liu
FWIW
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Tue, May 14, 2019 at 12:39:07PM +0200, Roger Pau Monné wrote:
> On Tue, May 14, 2019 at 12:31:18PM +0200, Olaf Hering wrote:
> > Am Tue, 14 May 2019 12:18:56 +0200
> > schrieb Roger Pau Monné :
> >
> > > Why is it not fine to set the device model version in
> > >
The same sentence is repeated in the next paragraph.
Signed-off-by: Wei Liu
---
INSTALL | 1 -
1 file changed, 1 deletion(-)
diff --git a/INSTALL b/INSTALL
index 9aa9ebdddc..1665ddd6a4 100644
--- a/INSTALL
+++ b/INSTALL
@@ -225,7 +225,6 @@ XEN_BUILD_TIME=hh:mm:ss
SMBIOS_REL_DATE=mm/dd/
Wei Liu (3):
gitignore: ignore .vscode directory
README: document requirement about python
INSTALL: remove duplicate sentence
.gitignore | 1 +
INSTALL| 1 -
README | 7 +++
3 files changed, 8 insertions(+), 1 deletion(-)
--
2.20.1
Provide information on what is expected from the build system
regarding python.
Signed-off-by: Wei Liu
---
README | 7 +++
1 file changed, 7 insertions(+)
diff --git a/README b/README
index 23e4f7c3dc..26d44cf7c1 100644
--- a/README
+++ b/README
@@ -181,6 +181,13 @@ Various tools, such as
The directory is created by Visual Studio Code editor to store its
local state.
Signed-off-by: Wei Liu
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 26bc583f74..3822bb75ba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@ cscope.out
On 5/14/19 5:16 PM, Jan Beulich wrote:
On 14.05.19 at 15:47, wrote:
Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
Looking at the source code, the emulator does appear to support
vpmaddwd, however only for EVEX:
>>> On 14.05.19 at 15:47, wrote:
> Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
> 05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
>
> Looking at the source code, the emulator does appear to support
> vpmaddwd, however only for EVEX:
>
>
On Tue, 14 May 2019, Steven Haigh wrote:
> The final fix would be figuring out why pygrub currently boots the *second*
> entry in the resulting grub.cfg - unlike how F29 worked. This may be either a
> fix on the grub2-mkconfig or pygrub side - I'm not quite sure yet. This would
> likely restore
On Tue, May 14, 2019 at 03:59:22PM +0200, Roger Pau Monne wrote:
> So a user can decide whether to compile a PV shim as part of the tools
> build. Note that the default behavior is preserved, which is to build
> a PV shim when the target or host (if target is unset) architecture is
> 64bit x86.
>
So a user can decide whether to compile a PV shim as part of the tools
build. Note that the default behavior is preserved, which is to build
a PV shim when the target or host (if target is unset) architecture is
64bit x86.
Requested-by: Olaf Hering
Signed-off-by: Roger Pau Monné
---
NOTE: run
On Tue, May 14, 2019 at 11:50 PM, Lars Kurth
wrote:
Apologies,
I mixed up some references
Lars
...
[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1703700
Bug B1 here was lodged by myself. There is also a post to xen-devel
titled
Apologies,
I mixed up some references
Lars
> On 13 May 2019, at 16:29, Lars Kurth wrote:
>
> Hi all,
>
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders,
On 14/05/2019 14:05, Andrii Anisov wrote:
On 14.05.19 15:02, Jan Beulich wrote:
Well, I think Julian's implication was that we can't support in particular
the boot loader -> kernel handover case without extra measures (if
at all), and hence he added things together and said what results
On Tue, May 14, 2019 at 11:40 PM, George Dunlap
wrote:
On Mon, May 13, 2019 at 11:25 AM Steven Haigh
wrote:
There seems to be some changes in Fedora 30 that cause the second
boot
entry in grub.cfg to be booted instead of the first.
This means that Fedora 30 systems either always boot
>>> On 14.05.19 at 15:05, wrote:
> On 14.05.19 15:02, Jan Beulich wrote:
>> Well, I think Julian's implication was that we can't support in particular
>> the boot loader -> kernel handover case without extra measures (if
>> at all), and hence he added things together and said what results
>> from
On 5/13/19 5:15 PM, Razvan Cojocaru wrote:
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the
On Mon, May 13, 2019 at 11:25 AM Steven Haigh wrote:
>
> There seems to be some changes in Fedora 30 that cause the second boot
> entry in grub.cfg to be booted instead of the first.
>
> This means that Fedora 30 systems either always boot into an older
> kernel, or in the case of systems with
On 14.05.19 15:02, Jan Beulich wrote:
Well, I think Julian's implication was that we can't support in particular
the boot loader -> kernel handover case without extra measures (if
at all), and hence he added things together and said what results
from this. Of course ideally we'd reject mixed
>>> On 14.05.19 at 14:24, wrote:
> Arm currently provides two macro BIT and BIT_ULL that are only usable
> in C and return respectively unsigned long and unsigned long long.
>
> Extending the macros to deal with assembly would be a nice benefits as
> it could replace the common pattern to define
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.
Furthermore, we never walked the page-tables fully. This means that any
With the newly introduced flags, it is now possible to know how the page
will be updated through the flags.
All the use of xenmap_operation are now replaced with the flags. At the
same time, validity check are now removed as they are gathered in
xen_pt_check_entry().
Signed-off-by: Julien Grall
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated will reside in xenheap, in practive the
page-tables covering Xen memory (e.g xen_mapping) is part of Xen
create_xen_entries() is doing more than creating entries. It can also
modify and remove entries.
Rename the function to make clear what the function is actually doing.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Add Andrii's reviewed-by
---
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
moment, the update to Xen PT is scattered all around mm.c. This makes
difficult to rework Xen memory layout or even ensuring we are following the
Arm Arm properly (and we are not so far!).
This part contains code to
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destroy_xen_mappings().
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page table handling.
However they are not sufficient as they could still allow to
modify/remove entry with
In preparation of rework of the Xen PT, the logic to update an entry
in moved out in a separate function.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Add Andrii's reviewed-by
---
xen/arch/arm/mm.c | 140
There are few places requiring to generate offsets from an address.
Rather than open-coding everywhere, we can introduce a macro to do the
job for us.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Add Andrii's reviewed-by
---
xen/arch/arm/p2m.c
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more convenient to have all the information for the update
in a single place.
Two new flags are added to remove the
The enum xenmap_operation is not used anymore. So remove it.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Add Andrii's reviewed-by
---
xen/arch/arm/mm.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git
Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first iteration.
While this is not a major problem today, this will be in the future if
the code expect an invalid MFN at every iteration.
Such behavior is prevented by avoiding to
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are not meant to fail for fixmap, hence the BUG_ON()
checking the return.
Signed-off-by: Julien Grall
We have multiple static page-tables defined in arch/arm/mm.c. The
current way to define them is difficult to read and does not help when
making modification.
Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
DEFINE_PAGE_TABLE (alias of DEFINE_PAGE_TABLES(..., 1)) are
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits as
it could replace the common pattern to define fields (AC(1, sfx) << X)
easier to read.
Hi all,
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.
The first part of the rework is "xen/arm: TLB flush helpers rework" [1].
For convenience, I provided a branch with all the patches applied based
on
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR_EL1.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor
The SCTLR_* are currently used for SCTLR/HSCTLR (arm32) and
SCTLR_EL1/SCTLR_EL2 (arm64).
The naming scheme is actually quite confusing because they may only be
defined for an archicture (or even an exception level). So it is not easy
for the developer to know which one to use.
The naming scheme
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.
Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
also not correct and looks like to be a verbatim copy from Arm32.
HSCTLR_BASE is
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling secondary_start.
Signed-off-by: Julien Grall
- Re-order the patch with "xen/arm: Remove
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_fixmap.
Signed-off-by: Julien Grall
So far, we don't have specific core initialization at boot. So remove
the comment.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Fix typo in the commit message
- Add Andrii's reviewed-by
---
xen/arch/arm/arm64/head.S | 2 --
1 file changed, 2
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.
Furthermore, CPU0 page-tables are part of Xen binary and will already be
zeroed before been used.
At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.
Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
I
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.
The implementation create_xen_entries() contains quite a few TOCTOU
races such as when allocating the 3rd-level page-tables.
Thankfully, they are
The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.
Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.
Signed-off-by:
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor
The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2
- Add Andrii's reviewed-by
---
xen/arch/arm/arm32/head.S | 2 --
1 file changed, 2
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.
So always zero r3 within the few
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Grall
---
- Re-order the patch with "xen/arm: Rework secondary_start
prototype"
---
xen/arch/arm/arm32/head.S | 1 -
xen/arch/arm/arm64/head.S | 1 -
xen/arch/arm/setup.c | 3 +--
3 files changed, 1
Use the pattern BIT(..., UL) to make the code more readable. Note that
unsigned long is used instead of unsigned because SCTLR is technically
32-bit on Arm32 and 64-bit on Arm64.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the patch to use BIT(..., UL) instead of
Hi all,
I forgot to remove the patches for part1 before sending the part2. I will resend
the series properly.
Sorry for the noise.
Cheers,
On 14/05/2019 13:21, Julien Grall wrote:
Hi all,
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.
The implementation create_xen_entries() contains quite a few TOCTOU
races such as when allocating the 3rd-level page-tables.
Thankfully, they are
The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2
- Add Andrii's reviewed-by
---
xen/arch/arm/arm32/head.S | 2 --
1 file changed, 2
We have multiple static page-tables defined in arch/arm/mm.c. The
current way to define them is difficult to read and does not help when
making modification.
Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
DEFINE_PAGE_TABLE (alias of DEFINE_PAGE_TABLES(..., 1)) are
At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.
Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
I
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_fixmap.
Signed-off-by: Julien Grall
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes
Hi all,
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.
The first part of the rework is "xen/arm: TLB flush helpers rework" [1].
For convenience, I provided a branch with all the patches applied based
on
The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.
Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.
Signed-off-by:
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.
So always zero r3 within the few
The AIVIVT is a type of instruction cache available on Armv7. This is
the only cache not implementing the IVIPT extension and therefore
requiring specific care.
To simplify maintenance requirements, Xen will not boot on platform
using AIVIVT cache.
This should not be an issue because Xen Arm32
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.
Furthermore, CPU0 page-tables are part of Xen binary and will already be
zeroed before been used.
1 - 100 of 175 matches
Mail list logo
