Building the privcmd code as a loadable module on ARM, we get
a link error due to the private cache management functions:
ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
Move the code into a new that is always built in when Xen is enabled,
as suggested by Juergen Gross and B
On 19.07.2019 16:18, Jan Beulich wrote:
> On 19.07.2019 14:34, Alexandru Stefan ISAILA wrote:
>> On 18.07.2019 15:58, Jan Beulich wrote:
>>> On 03.07.2019 12:56, Alexandru Stefan ISAILA wrote:
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receivin
> -Original Message-
> From: Petre Ovidiu PIRCALABU
> Sent: 19 July 2019 18:40
> To: Jan Beulich ; Paul Durrant ;
> Andrew Cooper
>
> Cc: JulienGrall ; Alexandru Stefan ISAILA
> ; Razvan
> Cojocaru ; George Dunlap
> ; Ian Jackson
> ; Roger Pau Monne ; Stefano
> Stabellini
> ; xen-deve
On 19.07.2019 19:40, Petre Ovidiu PIRCALABU wrote:
> On Fri, 2019-07-19 at 12:59 +, Jan Beulich wrote:
>> On 19.07.2019 14:37, Paul Durrant wrote:
From: Jan Beulich
Sent: 19 July 2019 13:32
On 19.07.2019 14:11, Paul Durrant wrote:
>> -Original Message-
>> Fr
De-htmling...
-
[snip]
For RMRRs themselves, system firmware is well known for abiding by the spec
[citation needed], but an RMRR must be honoured, because the entire purpose of
them is to state "this device won't function without access to this area".
An RMRR in a hole, while a violation o
flight 139234 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 138883
test-arm64-arm64-exam
On 19.07.2019 18:48, Volodymyr Babchuk wrote:
> Jan Beulich writes:
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -64,8 +64,13 @@ Bracing
>>---
>>
>>Braces ('{' and '}') are usually placed on a line of their own, except
>> -for the do/while loop. This is unlike the Linux coding sty
> -Original Message-
[snip]
> > (XEN) Domain heap initialised
> > (XEN) ACPI: 32/64X FACS address mismatch in FADT -
> > 8ce8ef80/, using 32
> > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119
> > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
> >
On 19.07.2019 19:27, Andrew Cooper wrote:
> On 16/07/2019 17:38, Jan Beulich wrote:
>> This is in preparation of actually enabling x2APIC mode, which requires
>> this wider IRTE format to be used.
>>
>> A specific remark regarding the first hunk changing
>> amd_iommu_ioapic_update_ire(): This bypas
On 19.07.2019 19:31, Andrew Cooper wrote:
> On 16/07/2019 17:39, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> @@ -416,6 +416,25 @@ union amd_iommu_ext_features {
>>} flds;
>>};
>>
>> +/* x2APIC Cont
On Sun, Jul 21, 2019 at 07:05:16PM +0100, Julien Grall wrote:
> Hi,
>
> On 7/20/19 10:21 PM, Marek Marczykowski-Górecki wrote:
> > On Sat, Jul 20, 2019 at 05:48:56PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > Sorry for jumping late in the discussion.
> > >
> > > On 7/17/19 2:00 AM, Marek M
On 19.07.2019 19:55, Andrew Cooper wrote:
> On 16/07/2019 17:41, Jan Beulich wrote:
>> When there are sufficiently many devices listed in the ACPI tables (no
>> matter if they actually exist), output may take way longer than the
>> watchdog would like.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v3
On 19.07.2019 20:23, Woods, Brian wrote:
> On Tue, Jul 16, 2019 at 04:36:06PM +, Jan Beulich wrote:
>> Also introduce a field in struct amd_iommu caching the most recently
>> written control register. All writes should now happen exclusively from
>> that cached value, such that it is guarante
Hi Roger,
On 22/07/2019 09:45, Roger Pau Monné wrote:
On Sun, Jul 21, 2019 at 07:05:16PM +0100, Julien Grall wrote:
Hi,
On 7/20/19 10:21 PM, Marek Marczykowski-Górecki wrote:
On Sat, Jul 20, 2019 at 05:48:56PM +0100, Julien Grall wrote:
Hi,
Sorry for jumping late in the discussion.
On 7/17
On 19.07.19 12:51, Julien Grall wrote:
Currently vunmap() is called from from xen/arch/arm/cpuerrata.c with an
s/ from//
address potentially not page aligned. Instead of fixing that in ARM code,
s/ARM/Arm/
we let vunmap() making alignment by itself and stripping other existing
vunmap()
On 21.07.2019 22:06, Andy Smith wrote:
> Hi,
>
> My first time using smt=0 on hypervisor command line so not sure how
> many versions and different pieces of hardware this happens with,
> but I noticed this during the microcode update stage of boot:
>
> (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
>
On 22/07/2019 10:06, Julien Grall wrote:
Hi Roger,
On 22/07/2019 09:45, Roger Pau Monné wrote:
On Sun, Jul 21, 2019 at 07:05:16PM +0100, Julien Grall wrote:
Hi,
On 7/20/19 10:21 PM, Marek Marczykowski-Górecki wrote:
On Sat, Jul 20, 2019 at 05:48:56PM +0100, Julien Grall wrote:
Hi,
Sorry
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by PAGE_SIZE.
Despite seeing Andrew's R-b you've already got I'd like to point out
that this increases the risk of some code passing the wrong pointer
into here. {,un}map_d
On 22.07.2019 11:30, Andrii Anisov wrote:
>
>
> On 19.07.19 12:37, Jan Beulich wrote:
>> On 18.07.2019 19:11, Andrii Anisov wrote:
>>> Let vunmap align passed virtual address by PAGE_SIZE.
>>
>> Despite seeing Andrew's R-b you've already got I'd like to point out
>> that this increases the risk o
On Mon, 2019-07-22 at 07:59 +, Jan Beulich wrote:
> On 19.07.2019 19:40, Petre Ovidiu PIRCALABU wrote:
> > On Fri, 2019-07-19 at 12:59 +, Jan Beulich wrote:
> > > On 19.07.2019 14:37, Paul Durrant wrote:
> > > > > From: Jan Beulich
> > > > > Sent: 19 July 2019 13:32
> > > > >
> > > > > On
Hello Julien,
I put my two cents in:
On 18.07.19 13:09, Julien Grall wrote:
On 7/17/19 10:55 PM, Denis Obrezkov wrote:
Hi,
Hi,
Well, Xen has been supported the omap5 for quite a while. So there are
two possibilities regarding the current SMP code:
1) It is totally broken and therefore n
On Mon, Jul 22, 2019 at 08:20:36AM +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > (XEN) Domain heap initialised
> > > (XEN) ACPI: 32/64X FACS address mismatch in FADT -
> > > 8ce8ef80/, using 32
> > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec000
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 12:49
> To: Paul Durrant ; 'Roman Shaposhnik'
>
> Cc: xen-devel@lists.xenproject.org; jgr...@suse.com; Andrew Cooper
> ;
> boris.ostrov...@oracle.com; jbeul...@suse.com
> Subject: Re: [Xen-devel] [BUG] After upgrade to Xe
On 22/07/2019 11:23, Jan Beulich wrote:
On 22.07.2019 11:30, Andrii Anisov wrote:
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by PAGE_SIZE.
Despite seeing Andrew's R-b you've already got I'd like to point out
that
On 22/07/2019 10:16, Jan Beulich wrote:
> On 21.07.2019 22:06, Andy Smith wrote:
>> Hi,
>>
>> My first time using smt=0 on hypervisor command line so not sure how
>> many versions and different pieces of hardware this happens with,
>> but I noticed this during the microcode update stage of boot:
>>
On 22.07.2019 14:02, Julien Grall wrote:
> On 22/07/2019 11:23, Jan Beulich wrote:
>> On 22.07.2019 11:30, Andrii Anisov wrote:
>>>
>>>
>>> On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
> Let vunmap align passed virtual address by PAGE_SIZE.
Desp
On 22/07/2019 09:49, Jan Beulich wrote:
> On 19.07.2019 19:55, Andrew Cooper wrote:
>> On 16/07/2019 17:41, Jan Beulich wrote:
>> As an observation, I wonder whether continually sprinkling
>> process_pending_softirqs() is the best thing to do for keyhandlers.
>> We've got a number of other which in
On 22.07.2019 14:06, Andrew Cooper wrote:
> Does reverting back to credit1 make the issue go away? I've never
> encountered this on any smt=0 test, but I also don't use credit2 at all.
I'll try to remember trying this out the next time I see it. I can't
see a connection to the used scheduler thou
Hi,
On 22/07/2019 13:11, Jan Beulich wrote:
On 22.07.2019 14:02, Julien Grall wrote:
On 22/07/2019 11:23, Jan Beulich wrote:
On 22.07.2019 11:30, Andrii Anisov wrote:
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by
Ping,
Any reviews on this patch are appreciated.
Regards,
Alex
On 07.06.2019 14:50, Jan Beulich wrote:
On 07.06.19 at 12:55, wrote:
>> @@ -4735,6 +4736,28 @@ static int do_altp2m_op(
>> _gfn(a.u.change_gfn.old_gfn),
>> _gfn(a.u.change_gfn.new_gfn
On 19.07.2019 20:44, Andrew Cooper wrote:
> On 19/07/2019 17:16, Jan Beulich wrote:
>> On 19.07.2019 17:56, Andrew Cooper wrote:
>>> On 16/07/2019 17:36, Jan Beulich wrote:
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by intro
On 22/07/2019 03:57, Kevin Buckley wrote:
> This follows on from
>
> pygrub gives "raise RuntimeError("Unable to find partition containing
> kernel")"
>
> https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01589.html
>
> and for some reason I submitted my latest findings onto the grub
On 22.07.19 14:18, Jan Beulich wrote:
On 22.07.2019 14:06, Andrew Cooper wrote:
Does reverting back to credit1 make the issue go away? I've never
encountered this on any smt=0 test, but I also don't use credit2 at all.
I'll try to remember trying this out the next time I see it. I can't
see a
On 22.07.2019 14:39, Alexandru Stefan ISAILA wrote:
> Ping,
>
> Any reviews on this patch are appreciated.
FAOD I think I've provided all the feedback I have. The patch doesn't
seem to have a tool stack maintainer ack yet, and I think I had made
clear previously that I'm willing to look at change
flight 139252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139252/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Instead of dynamically decide whether the previous vcpu was using full
or default GDT just add a percpu variable for that purpose. This at
once removes the need for testing vcpu_ids to differ twice.
This change improves performance by 0.5% - 1% on my test machine when
doing parallel compilation.
On 22/07/2019 09:34, Jan Beulich wrote:
> On 19.07.2019 19:27, Andrew Cooper wrote:
>> On 16/07/2019 17:38, Jan Beulich wrote:
>>> @@ -142,7 +178,15 @@ static void free_intremap_entry(const st
>>>{
>>>union irte_ptr entry = get_intremap_entry(iommu, bdf, index);
>>>
>>> -ACCESS_
On 22/07/2019 09:43, Jan Beulich wrote:
> On 19.07.2019 19:31, Andrew Cooper wrote:
>> On 16/07/2019 17:39, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>>> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>>> @@ -416,6 +416,25 @@ union amd_iommu_ext_features {
>>>
On Mon, Jul 22, 2019 at 01:54:00PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 22 July 2019 12:49
> > To: Paul Durrant ; 'Roman Shaposhnik'
> >
> > Cc: xen-devel@lists.xenproject.org; jgr...@suse.com; Andrew Cooper
> > ;
> > boris.ostrov...@orac
On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
> > ACPI Timer does not work in a PVH guest, but local APIC works on both
>
> This is not accurate. It's not that the ACPI timer doesn't work, it's
> just that it's no
> -Original Message-
[snip]
> > > diff --git a/xen/drivers/passthrough/iommu.c
> > > b/xen/drivers/passthrough/iommu.c
> > > index 79ec6719f5..9d91f0d633 100644
> > > --- a/xen/drivers/passthrough/iommu.c
> > > +++ b/xen/drivers/passthrough/iommu.c
> > > @@ -185,7 +185,7 @@ void __hwdom_in
On 19/07/2019 14:57, Juergen Gross wrote:
> I have now a git branch with the two problems corrected and rebased to
> current staging available:
>
> github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
seems to be fixed now. But I can still re
flight 139237 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
133580
test-amd64-i386-
On Mon, Jul 22, 2019 at 04:03:44PM +0200, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > > diff --git a/xen/drivers/passthrough/iommu.c
> > > > b/xen/drivers/passthrough/iommu.c
> > > > index 79ec6719f5..9d91f0d633 100644
> > > > --- a/xen/drivers/passthrough/iommu.c
> > > > +++
On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > When running as a Xen PVH guest, there is no CMOS to read the memory
> > size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> > works without CMOS
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 15:40
> To: Paul Durrant
> Cc: 'Roman Shaposhnik' ; xen-devel@lists.xenproject.org;
> jgr...@suse.com; Andrew
> Cooper ; boris.ostrov...@oracle.com;
> jbeul...@suse.com
> Subject: Re: [Xen-devel] [BUG] After upgrade to
On 22.07.2019 15:36, Andrew Cooper wrote:
> On 22/07/2019 09:34, Jan Beulich wrote:
>> On 19.07.2019 19:27, Andrew Cooper wrote:
>>> On 16/07/2019 17:38, Jan Beulich wrote:
@@ -142,7 +178,15 @@ static void free_intremap_entry(const st
{
union irte_ptr entry = get_intremap
On Mon, Jul 22, 2019 at 05:02:35PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 22 July 2019 15:40
> > To: Paul Durrant
> > Cc: 'Roman Shaposhnik' ; xen-devel@lists.xenproject.org;
> > jgr...@suse.com; Andrew
> > Cooper ; boris.ostrov...@oracle.co
On 22.07.2019 15:45, Andrew Cooper wrote:
> On 22/07/2019 09:43, Jan Beulich wrote:
>> On 19.07.2019 19:31, Andrew Cooper wrote:
>>> On 16/07/2019 17:39, Jan Beulich wrote:
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
@@ -416,6
The current usage of need_iommu_pt_sync in p2m for non-translated
guests is wrong because it doesn't correctly handle a relaxed PV
hardware domain, that has need_sync set to false, but still need
entries to be added from calls to {set/clear}_identity_p2m_entry.
Adjust the code in guest_physmap_add
> -Original Message-
> From: Roger Pau Monne
> Sent: 22 July 2019 16:32
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; George Dunlap
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Paul Durrant
>
> Subject: [PATCH] x86/p2m: fix non-translated handling of iommu mappings
>
On 22/07/2019 16:01, Jan Beulich wrote:
> On 22.07.2019 15:36, Andrew Cooper wrote:
>> On 22/07/2019 09:34, Jan Beulich wrote:
>>> On 19.07.2019 19:27, Andrew Cooper wrote:
On 16/07/2019 17:38, Jan Beulich wrote:
> @@ -142,7 +178,15 @@ static void free_intremap_entry(const st
> {
>
Clarify why relaxed hardware domains don't need iommu page-table
syncing.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/iommu.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 79ec67
flight 139239 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139239/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 8 reboot fail pass in 139225
Tests which did not succeed, but
Hello everyone,
Following up on discussions that we had at the last Xen summit, we’re
submitting a Xen subproject proposal, regarding XCP-ng project (
https://xcp-ng.org). Feel free to give your feedback!
Regards,
Olivier Lambert and XCP-ng team
# XCP-ng proposal
## The Project
XCP-ng is a tu
On 20.07.19 21:25, Julien Grall wrote:
Hi,
Hi, Julien.
Apologies for the late answer. I have been traveling for the past few
weeks.
Absolutely no problem. Thank you for your review.
On 6/26/19 11:30 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMS
On 19/07/2019 14:07, Igor Druzhinin wrote:
> Following 6ff560f7f ("x86/SMP: don't try to stop already stopped CPUs")
> an incorrect condition was placed into kexec transition path
> leaving crashing CPU always online breaking kdump kernel entering.
> Correct it by unifying the condition with smp_se
On Wed, Jul 10, 2019 at 12:48:57PM +0200, Laszlo Ersek wrote:
> On 07/04/19 16:42, Anthony PERARD wrote:
> > On a Xen PVH guest, none of the existing serial or console interface
> > works, so we add a new one, based on XenConsoleSerialPortLib, and
> > implemented via SerialDxe.
> >
> > That is a s
flight 139256 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139256/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, 22 Jul 2019, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> Move the code into a new that is always built in wh
flight 139241 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139241/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5f89bcc4604ea9e439039d873e34a8c06b47c707
baseline version:
ovmf 8ff68cd5e4c91c97f36ac
On 07/19/19 18:42, Anthony PERARD wrote:
> On Fri, Jul 05, 2019 at 02:21:13PM +0200, Laszlo Ersek wrote:
>> The patches on the list are malformed. They have
>>
>> Content-Transfer-Encoding: quoted-printable
>>
>> which is fine, in itself; however, they have CR-CR-LF line terminators.
>>
>> For exam
On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask
> *cpumask,
>* doing a speculative memory access.
>*/
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func
a.k.a. (at least in this form) Andrew's "work which might be offloadable to
someone else" list.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
CC: Lars Kurth
CC: Paul Durrant
CC: Roger
> On Jul 22, 2019, at 12:14 PM, Peter Zijlstra wrote:
>
> On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
>> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask
>> *cpumask,
>> * doing a speculative memory access.
>> */
>> if (info->freed_tables) {
On 07/22/19 15:49, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné wrote:
>> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
>>> ACPI Timer does not work in a PVH guest, but local APIC works on both
>>
>> This is not accurate. It's not that the ACPI
On Mon, Jul 22, 2019 at 07:27:09PM +, Nadav Amit wrote:
> > On Jul 22, 2019, at 12:14 PM, Peter Zijlstra wrote:
> > But then we can still do something like the below, which doesn't change
> > things and still gets rid of that dual function crud, simplifying
> > smp_call_function_many again.
On Mon, 22 Jul 2019, Andrew Cooper wrote:
> On 22/07/2019 03:57, Kevin Buckley wrote:
>> bash-5.0# /usr/lib/xen/bin/pygrub --debug --offset=1048576
>> --list-entries /dev/vg_xen_vbds/lv_4g_02
>> Using to parse /boot/grub/grub.cfg
>> Traceback (most recent call last):
>> File "/usr/lib/xen/bin/p
On 07/22/19 16:53, Anthony PERARD wrote:
> On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
>> On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
>>> When running as a Xen PVH guest, there is no CMOS to read the memory
>>> size from. Rework GetSystemMemorySize(Below|Ab
flight 139261 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139261/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Juergen,
We are working on a technology to limit cache interference between
guests running on the same SoC. It works well, but as a consequence, all
memory allocations are 4K only: higher granularities (2M, 1G) do not
work at all.
One of the issues I am seeing after upgrading dom0 kernel is th
On 22/07/2019 22:21, Stefano Stabellini wrote:
> Hi Juergen,
>
> We are working on a technology to limit cache interference between
> guests running on the same SoC. It works well, but as a consequence, all
> memory allocations are 4K only: higher granularities (2M, 1G) do not
> work at all.
>
> On
At the moment, the user should save x30/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register x0
if it was stored in a different register.
For convenience, a new macro
Adjust the coding style used in the comments within create_pages_tables()
Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within the function, so it does
not need to be part of the common register.
Signed-off-by: Julien Grall
---
xe
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid a branch for the decision and make the code clearer,
launch() is reworked to take in parameters the entry point and its
arguments.
La
At the moment, the user should save r14/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register r0
if it was stored in a different register.
For convenience, a new macro
Hi all,
This is part of the boot/memory rework for Xen on Arm, but not sent as
MM-PARTx as this is focusing on the boot code.
Similar to the memory code, the boot code is not following the Arm Arm and
could lead to memory corruption/TLB conflict abort. I am not aware
of any platforms where Xen fa
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is imp
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate function
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate function
Document the behavior and the main registers usage within the function.
Note that r6 is now only used within the function, so it does not need
to be part of the common register.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 30 +
At the moment, TTBR_EL2 is setup in create_page_tables(). This is fine
as it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the TTBR_EL2 is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the TTBR_EL2 is
seen
The current boot code is using the pattern ldr rX, =... to move an
immediate constant into a 32-bit register.
This pattern implies to load the immediate constant from a literal pool,
meaning a memory access will be performed.
The memory access can be avoided by using movw/movt instructions.
A ne
The 1:1 mapping may clash with other parts of the Xen virtual memory
layout. At the moment, Xen is handling the clash by only creating a
mapping to the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, t
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Fix typo in the commit title
- Add Stefano's reviewed-by
---
xen/arch/arm/arm64/head
setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register x23 holding the address to
the UART.
However, secondary CPUs are not using earlyprintk between turning the
MMU on and switching to the runtime page table. So setting up the
fixmap
At the moment, HTTBR is setup in create_page_tables(). This is fine as
it is called by every CPUs.
However, such assumption may not hold in the future. To make change
easier, the HTTBR is not setup in enable_mmu().
Take the opportunity to add the missing isb() to ensure the HTTBR is
seen before t
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to
avoid TLB incoherency.
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at EL2.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
--
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
Changes in v2:
- x2 and x3 are also clobbers. Update the comment accordingly
- s/ID/1:1/
---
xen/arch/arm/arm64/head.S | 7 +++
1 file changed, 7 insertions(+)
diff -
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is imp
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if earlyp
The return address of a function is always stored in x30. For convenience,
introduce a register alias so "lr" can be used in assembly.
This is defined in asm-arm/arm64/macros.h to allow all assembly files
to use it.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
x
Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
Changes in v2:
- We don't clobber
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e
The current implementation of the macro PRINT will clobber x30/lr. This
means the user should save lr if it cares about it.
Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve
lr, the macro PRINT is modified to s
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/arm32/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/arm32/head.S b/x
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if earlyp
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed. It also means that x26 does not need to be set for secondary
CPU.
Note that we will need to keep x26 around for the boot CPU as BSS should
not be rese
Arm64 provides instructions to load a PC-relative address, but with some
limitations:
- adr is enable to cope with +/-1MB
- adrp is enale to cope with +/-4GB but relative to a 4KB page
address
Because of that, the code requires to use 2 instructions to load any Xen
symbol. To make the c
1 - 100 of 121 matches
Mail list logo
