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 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 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
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
@@
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.
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
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
On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
> On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
> > On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
> > > What is the recommended way to disable CONFIG_PV_SHIM, which is set in
> > > tools/firmware/Makefile?
>>> On 02.05.19 at 16:51, wrote:
On 05.04.19 at 09:01, wrote:
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/passthrough/amd/iommu_intr.c
>> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
>> @@ -503,7 +503,7 @@ static struct amd_iommu *_find_iommu_for
>> {
>> struct amd_iommu
On 13. May 2019, at 12:48, Wei Liu
mailto:wei.l...@citrix.com>> wrote:
On Tue, May 07, 2019 at 01:53:20PM +, Eslam Elnikety wrote:
Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
This consumes host resources unnecessarily for guests that have no use for
vkbd.
Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
This consumes host resources unnecessarily for guests that have no use for
vkbd. Make this behaviour tunable to allow an administrator to choose. The
commit retains the current behaviour -- HVM guests still get vkdb
An upcoming change will set the value of device_model_version properly
also for the non-HVM case.
Move existing code to new function libxl__domain_set_device_model.
Move also initialization for device_model_stubdomain to that function.
Make sure libxl__domain_build_info_setdefault is called with
If a domU has a qemu-xen instance attached, it is required to call qemus
"xen-save-devices-state" method. Without it, the receiving side of a PV or
PVH migration may be unable to lock the image:
xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get
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 == LIBXL_DOMAIN_TYPE_HVM) {
> +if (type == LIBXL_DOMAIN_TYPE_HVM ||
> +
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
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 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
> 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
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
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
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 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
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 136121 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 135251
build-arm64-xsm
>>> On 14.05.19 at 11:23, wrote:
> On Tue, May 14, 2019 at 10:55:18AM +0200, Roger Pau Monné wrote:
>> On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
>> > On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
>> > > On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
Hello Julien,
On 14.05.19 12:58, Julien Grall wrote:
I guess we should agree what to implement first.
I think there are an agreement that the two methods should not be used together.
For a domain or for a particular VCPU?
How should we response on the request to register paddr when we
Wei Liu (2):
tools: remove blktap2 related code and documentation
Drop blktap2
.gitignore | 15 -
.hgignore | 12 -
INSTALL|4 -
MAINTAINERS|4 -
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
> libxl__domain_build_info_setdefault?
Because it receives just build_info, which lacks all the data to decide
if a device type needs a device model or not.
Olaf
>>> On 13.05.19 at 15:44, wrote:
> On 3/5/19 1:26 PM, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -192,21 +192,27 @@ void __hwdom_init iommu_hwdom_init(struc
>>
>> page_list_for_each ( page, >page_list )
>> {
>> -
>>> On 14.05.19 at 13:11, wrote:
> On Tue, May 14, 2019 at 03:26:53AM -0600, Jan Beulich wrote:
>> >>> On 14.05.19 at 10:55, wrote:
>> > On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
>> >> On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
>> >> > On Mon, May 13, 2019 at
flight 136098 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136098/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
On Tue, May 14, 2019 at 09:27:41AM +0200, Olaf Hering wrote:
> An upcoming change will set the value of device_model_version properly
> also for the non-HVM case.
>
> Move existing code to new function libxl__domain_set_device_model.
> Move also initialization for device_model_stubdomain to that
On Fri, Apr 05, 2019 at 01:01:04AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Not sure if it's of much help, but:
Reviewed-by: Roger Pau Monné
The change it's trivial and obviously correct to me.
Roger.
___
Xen-devel mailing list
Blktap2 is effectively dead for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. libxl no longer supports TAP disk backend, with appropriate assertions
added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend
3. Remove blktap2
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
git rm blktap2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, May 14, 2019 at 03:26:53AM -0600, Jan Beulich wrote:
> >>> On 14.05.19 at 10:55, wrote:
> > On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
> >> On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
> >> > On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering 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 architecture is x86.
Requested-by: Olaf Hering
Signed-off-by: Roger Pau Monné
---
NOTE: run autogen.sh after applying.
---
Cc:
On 14/05/2019 10:48, Jan Beulich wrote:
On 14.05.19 at 11:35, wrote:
On a similar topic, how does Kexec works on Xen? Do we reset the
domain as well?
No, how could we? What gets invoked isn't Xen in the common case,
but some other (typically bare metal) OS like Linux.
It is not what I
>>> On 14.05.19 at 12:30, wrote:
> Blktap2 is effectively dead for a few years.
>
> Notable changes in this patch:
>
> 0. Unhook blktap2 from build system
> 1. libxl no longer supports TAP disk backend, with appropriate assertions
>added and some code paths now return ERROR_FAIL
And also
On Tue, May 14, 2019 at 10:55:18AM +0200, Roger Pau Monné wrote:
> On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
> > On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
> > > On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
> > > > What is the recommended way to
On Tue, May 14, 2019 at 08:43:25AM +, Eslam Elnikety wrote:
> Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
> This consumes host resources unnecessarily for guests that have no use for
> vkbd. Make this behaviour tunable to allow an administrator to choose. The
Hi Jan,
On 09/05/2019 10:27, Jan Beulich wrote:
On 08.05.19 at 17:40, wrote:
On 23/04/2019 09:10, Andrii Anisov wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -163,15 +163,23 @@ struct vcpu
void*sched_priv;/* scheduler-specific data */
>>> On 14.05.19 at 11:35, wrote:
> On a similar topic, how does Kexec works on Xen? Do we reset the
> domain as well?
No, how could we? What gets invoked isn't Xen in the common case,
but some other (typically bare metal) OS like Linux.
Jan
___
On 13/05/2019 13:30, Andrii Anisov wrote:
On 08.05.19 18:40, Julien Grall wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6dc633e..8e24e63 100644
{
- void __user *guest_handle = NULL;
+ if ( !guest_handle_is_null(runstate_guest(v)) )
+ {
+ void
On Tue, May 14, 2019 at 03:52:39AM -0600, Jan Beulich wrote:
> >>> On 14.05.19 at 11:23, wrote:
> > On Tue, May 14, 2019 at 10:55:18AM +0200, Roger Pau Monné wrote:
> >> On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
> >> > On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné
Am Mon, 13 May 2019 17:20:05 +0200
schrieb Roger Pau Monné :
> enabled by default
Does anyone actually require it at all?
Those who do pass --enable-pvshim to configure. No need for (incorrect)
host_cpu checks.
Olaf
pgpBfGEmkd8MY.pgp
Description: Digitale Signatur von OpenPGP
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
> > libxl__domain_build_info_setdefault?
>
> Because it receives just build_info, which lacks all the data to
flight 136106 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 21 leak-check/check fail REGR. vs.
135997
Tests which
On 14/05/2019 11:08, Andrii Anisov wrote:
Hello Julien,
On 14.05.19 12:58, Julien Grall wrote:
I guess we should agree what to implement first.
I think there are an agreement that the two methods should not be used together.
For a domain or for a particular VCPU?
How should we response
>>> On 14.05.19 at 10:55, wrote:
> On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
>> On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
>> > On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
>> > > What is the recommended way to disable CONFIG_PV_SHIM, which is
On 14/05/2019 10:23, Wei Liu wrote:
> On Tue, May 14, 2019 at 10:55:18AM +0200, Roger Pau Monné wrote:
>> On Mon, May 13, 2019 at 04:28:12PM +0100, Wei Liu wrote:
>>> On Mon, May 13, 2019 at 05:20:05PM +0200, Roger Pau Monné wrote:
On Mon, May 13, 2019 at 04:53:21PM +0200, Olaf Hering wrote:
On 14/05/2019 08:07, Jan Beulich wrote:
On 02.05.19 at 16:51, wrote:
> On 05.04.19 at 09:01, wrote:
>>> Signed-off-by: Jan Beulich
>>>
>>> --- a/xen/drivers/passthrough/amd/iommu_intr.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
>>> @@ -503,7 +503,7 @@ static struct amd_iommu
On Tue, May 14, 2019 at 12:34:06PM +0200, Olaf Hering wrote:
> Am Mon, 13 May 2019 17:20:05 +0200
> schrieb Roger Pau Monné :
>
> > enabled by default
>
> Does anyone actually require it at all?
Hm, that's the default behavior so far (enabled on x86), so I would
like to keep it as-is.
> Those
On Tue, May 14, 2019 at 10:05:58AM +0200, Olaf Hering wrote:
> If a domU has a qemu-xen instance attached, it is required to call qemus
> "xen-save-devices-state" method. Without it, the receiving side of a PV or
> PVH migration may be unable to lock the image:
>
> xen be: qdisk-51712: xen be:
>>> On 14.05.19 at 13:23, wrote:
> On 14/05/2019 10:48, Jan Beulich wrote:
> On 14.05.19 at 11:35, wrote:
>>> On a similar topic, how does Kexec works on Xen? Do we reset the
>>> domain as well?
>>
>> No, how could we? What gets invoked isn't Xen in the common case,
>> but some other
>>> On 14.05.19 at 13:17, 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 architecture is x86.
But the original behavior was so only when building x86_64 - see
the
On Tue, May 14, 2019 at 05:35:25AM -0600, Jan Beulich wrote:
> >>> On 14.05.19 at 12:30, wrote:
> > Blktap2 is effectively dead for a few years.
> >
> > Notable changes in this patch:
> >
> > 0. Unhook blktap2 from build system
> > 1. libxl no longer supports TAP disk backend, with appropriate
On 14.05.19 14:24, Julien Grall wrote:
I think there are an agreement that the two methods should not be used together.
For a domain or for a particular VCPU?
How should we response on the request to register paddr when we already have
registered vaddr and vice versa?
From the discussion
Luckily the function currently has no callers - it would have called
through NULL for both Arm and x86/AMD.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -409,7 +409,7 @@ int iommu_lookup_page(struct domain *d,
{
const struct
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 logic to set SCTLR_EL2.WXN is the same for the boot CPU and
non-boot CPU. So introduce a function to set the bit and clear TLBs.
This new function will help us to document and update the logic in a
single place.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB instructions used will act on both Data and Instruction TLBs.
Take the opportunity to rework the documentation which can be confusing
to read as
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
At the moment, create_xen_entries will only flush the TLBs if the full
range has successfully been updated. This may lead to leave unwanted
entries in the TLBs if we fail to update some entries.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
---
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.
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
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.
The function flush_xen_text_tlb_local() has been misused and will result
to invalidate the instruction cache more than necessary.
For instance, there is no need to invalidate the instruction cache if
we are setting SCTLR_EL2.WXN.
There is effectively only one caller (i.e free_init_memory() who
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
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
TLB helpers in the headers tlbflush.h are currently quite confusing to
use the name may lead to think they are dealing with hypervisors TLBs
while they actually deal with guest TLBs.
Rename them to make it clearer that we are dealing with guest TLBs.
Signed-off-by: Julien Grall
Reviewed-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_EL1.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor
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
All the TLBs helpers invalidate all the TLB entries are using the same
pattern:
DSB SY
TLBI ...
DSB SY
ISB
This pattern is following pattern recommended by the Arm Arm to ensure
visibility of updates to translation tables (see K11.5.2 in ARM DDI
0487D.b).
We have been a bit too
At the moment, TLB helpers are scattered in 2 headers: page.h (for
Xen TLB helpers) and tlbflush.h (for guest TLB helpers).
This patch is gathering all of them in tlbflush. This will help to
uniformize and update the logic of the helpers in follow-up patches.
Signed-off-by: Julien Grall
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 13:39, wrote:
> On Tue, May 14, 2019 at 05:35:25AM -0600, Jan Beulich wrote:
>> >>> On 14.05.19 at 12:30, wrote:
>> > Blktap2 is effectively dead for a few years.
>> >
>> > Notable changes in this patch:
>> >
>> > 0. Unhook blktap2 from build system
>> > 1. libxl no longer
flight 136089 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136089/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 128858
The function passes 0 as "alloc" argument to addr_to_dma_page_maddr(),
so -ENOMEM simply makes no sense (and its use was probably simply a
copy-and-paste effect originating at intel_iommu_map_page()).
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 May 2019 05:04
> To: xen-devel
> Cc: Paul Durrant ; Kevin Tian
> Subject: [PATCH] VT-d: change bogus return value of intel_iommu_lookup_page()
>
> The function passes 0 as "alloc" argument to
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
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
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
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
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.
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
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
1 - 100 of 175 matches
Mail list logo
