On 30.11.2021 23:01, Andrew Cooper wrote:
> The supported parameter was added in 2d9b91f1aeaa ("VMX/vPMU: fix DebugCtl MSR
> handling"), it laid the groundwork for XSA-269, and in the meantime
> 2a8a8e99feb9 ("x86/vtx: Fix the checking for unknown/invalid MSR_DEBUGCTL
> bits") totally rewrote MSR_D
On 30.11.2021 21:56, Andrew Cooper wrote:
> On 29/11/2021 09:10, Jan Beulich wrote:
>> @@ -133,14 +133,13 @@ int vpmu_do_msr(unsigned int msr, uint64
>> goto nop;
>>
>> vpmu = vcpu_vpmu(curr);
>> -ops = vpmu->arch_vpmu_ops;
>> -if ( !ops )
>> +if ( !vpmu_is_set(vpmu, VP
On 30.11.2021 19:12, Ayan Kumar Halder wrote:
> GENMASK(30, 21) should be 0x7fe0. Fixed this in the comment
> in bitops.h.
>
> Signed-off-by: Ayan Kumar Halder
Acked-by: Jan Beulich
On 30.11.2021 19:35, Ayan Kumar Halder wrote:
> On 30/11/2021 07:57, Jan Beulich wrote:
>> On 29.11.2021 20:16, Ayan Kumar Halder wrote:
>>> +{
>>> +struct cpu_user_regs *regs = guest_cpu_user_regs();
>>> +unsigned int val;
>>> +
>>> +val = get_user_reg(regs, instr->code.rn);
>>> +v
On 11/30/21 23:41, Thomas Gleixner wrote:
On Tue, Nov 30 2021 at 23:10, Thomas Gleixner wrote:
On Tue, Nov 30 2021 at 22:48, Cédric Le Goater wrote:
On 11/29/21 22:38, Thomas Gleixner wrote:
On Mon, Nov 29 2021 at 08:33, Cédric Le Goater wrote:
thanks for having a look. I fixed up this and ot
flight 166960 xen-unstable real [real]
flight 166964 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166960/
http://logs.test-lab.xenproject.org/osstest/logs/166964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 166954 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166954/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166953
test-amd64-amd64-qemuu-nested-amd 2
On Tue, Nov 30 2021 at 23:10, Thomas Gleixner wrote:
> On Tue, Nov 30 2021 at 22:48, Cédric Le Goater wrote:
>> On 11/29/21 22:38, Thomas Gleixner wrote:
>>> On Mon, Nov 29 2021 at 08:33, Cédric Le Goater wrote:
>>> thanks for having a look. I fixed up this and other fallout and pushed out
>>> an
On Tue, Nov 30 2021 at 22:48, Cédric Le Goater wrote:
> On 11/29/21 22:38, Thomas Gleixner wrote:
>> On Mon, Nov 29 2021 at 08:33, Cédric Le Goater wrote:
>> thanks for having a look. I fixed up this and other fallout and pushed out an
>> updated series (all 4 parts) to:
>>
>> git://git.k
flight 166956 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166956/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
As all function pointer calls are resoved to direct calls on boot, clobber the
endbr64 instructions too to make life harder for an attacker which has managed
to hijack a function pointer.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/cpu/vpm
On 29/11/2021 09:11, Jan Beulich wrote:
> Both vendors' code populates all hooks, so there's no need to have any
> NULL checks before invoking the hook functions. With that the only
> remaining uses of the object are in alternative_{,v}call(), i.e. none
> after alternatives patching.
>
> In vpmu_ar
The supported parameter was added in 2d9b91f1aeaa ("VMX/vPMU: fix DebugCtl MSR
handling"), it laid the groundwork for XSA-269, and in the meantime
2a8a8e99feb9 ("x86/vtx: Fix the checking for unknown/invalid MSR_DEBUGCTL
bits") totally rewrote MSR_DEBUGCTL handling.
Strip out the parameter again.
On 11/29/21 22:38, Thomas Gleixner wrote:
Cedric,
On Mon, Nov 29 2021 at 08:33, Cédric Le Goater wrote:
On 11/27/21 02:18, Thomas Gleixner wrote:
Remove the kobject.h include from msi.h as it's not required and add a
sysfs.h include to the core code instead.
Signed-off-by: Thomas Gleixner
On 29/11/2021 09:10, Jan Beulich wrote:
> I see little point in having an open-coded switch() statement to achieve
> the same; like other vendor-specific operations the function can be
> supplied in the respective ops structure instances.
>
> Signed-off-by: Jan Beulich
Yeah, that logic was just b
On 29/11/2021 09:10, Jan Beulich wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -17,12 +17,12 @@
> *
> * Author: Haitao Shan
> */
> -#include
> -#include
> -#include
> -#include
> #include
> +#include
> #include
> +#include
> +#include
> +#include
>
flight 166942 linux-linus real [real]
flight 166962 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166942/
http://logs.test-lab.xenproject.org/osstest/logs/166962/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 30/11/2021 14:57, Andrew Cooper wrote:
> On 30/11/2021 14:32, Jan Beulich wrote:
>> On 30.11.2021 15:25, Andrew Cooper wrote:
>>> On 30/11/2021 14:03, Jan Beulich wrote:
On 30.11.2021 14:48, Andrew Cooper wrote:
> On 29/11/2021 09:04, Jan Beulich wrote:
>> The aim being to have as f
flight 166959 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166959/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166394
test-amd64-amd64-xl-qemuu-win7-a
Hi Andre,
Thanks for your comments. They are useful.
On 30/11/2021 09:49, Andre Przywara wrote:
On Mon, 29 Nov 2021 19:16:38 +
Ayan Kumar Halder wrote:
Hi,
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover all the instruct
Hi Jan,
Thanks a lot for the feedback.
I need a clarification.
On 30/11/2021 07:57, Jan Beulich wrote:
On 29.11.2021 20:16, Ayan Kumar Halder wrote:
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover all the instructions a domain
Hi Jan,
On 30/11/2021 10:31, Jan Beulich wrote:
On 30.11.2021 10:37, Ayan Kumar Halder wrote:
On 30/11/2021 07:18, Jan Beulich wrote:
On 29.11.2021 20:44, Ayan Kumar Halder wrote:
GENMASK(30, 21) should be 0x07fe0
Please can this have a meaningful title? E.g. "bitops: fix incorrect
valu
GENMASK(30, 21) should be 0x7fe0. Fixed this in the comment
in bitops.h.
Signed-off-by: Ayan Kumar Halder
---
Changelog :-
v2 :- 1. Replaced the word "vector" with "value" in comment.
2. Changed 0x07fe0 to 0x7fe0.
3. Updated the commit message to make it meaningful.
(All suggested by
Most functions in this call chain have 8 parameters, meaning that the final
two booleans are spilled to the stack for for calls.
First, delete nestedhap_walk_L1_p2m and introduce nhvm_hap_walk_L1_p2m() as a
thin wrapper around hvm_funcs just like all the other nhvm_*() hooks. This
involves includ
The sole caller doesn't check the return value, and both vendors implement the
hook.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Tamas K Lengyel
CC: Alexandru Isaila
CC: Petre Pircalabu
---
xen/include/asm-x86/hvm/hvm.h | 10 ++
1 file chang
Andrew Cooper (2):
x86/hvm: Simplify hvm_enable_msr_interception()
x86/hvm: Rework nested hap functions to reduce parameters
xen/arch/x86/hvm/hvm.c | 5 +
xen/arch/x86/hvm/svm/nestedsvm.c| 11 +
xen/arch/x86/hvm/vmx/vvmx.c | 10 -
xen/
On 30.11.2021 17:44, Andrew Cooper wrote:
> On 30/11/2021 16:10, Jan Beulich wrote:
>> ept_free_entry() gets called after a flush - if one is necessary in the
>> first place - was already issued. That behavior is similar to NPT, which
>> also doesn't have any further flush in p2m_free_entry(). (Fur
On 30/11/2021 16:10, Jan Beulich wrote:
> ept_free_entry() gets called after a flush - if one is necessary in the
> first place - was already issued. That behavior is similar to NPT, which
> also doesn't have any further flush in p2m_free_entry(). (Furthermore,
> the function being recursive, in ca
On 30/11/2021 16:11, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 30/11/2021 16:14, Jan Beulich wrote:
> Sufficient and in particular regular testing on very large hosts cannot
> currently be guaranteed. Anyone wanting us to support larger hosts is
> free to propose so, but will need to supply not only test results, but
> also a test plan.
>
> This is a follow
Sufficient and in particular regular testing on very large hosts cannot
currently be guaranteed. Anyone wanting us to support larger hosts is
free to propose so, but will need to supply not only test results, but
also a test plan.
This is a follow-up to XSA-385.
Signed-off-by: Jan Beulich
--- u
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -263,7 +263,7 @@ int arch_monitor_domctl_event(struct dom
if ( unlikely(old_status == requested_status) )
return -EEXIST;
-if ( !hvm_funcs.set_descriptor_access_exiting )
+
ept_free_entry() gets called after a flush - if one is necessary in the
first place - was already issued. That behavior is similar to NPT, which
also doesn't have any further flush in p2m_free_entry(). (Furthermore,
the function being recursive, in case of recursiveness way too many
flushes would h
On Fri, Sep 24, 2021 at 11:45:57AM +0200, Jan Beulich wrote:
> Introduce a helper function to determine the largest possible mapping
> that allows covering a request (or the next part of it that is left to
> be processed).
>
> In order to not add yet more recurring dfn_add() / mfn_add() to the two
flight 166958 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166958/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
From: Juergen Gross
[ Upstream commit 03e143b2acebe23c893f22ebed9abc0fe2a7f27e ]
The Xen pvcalls device is not essential for booting. Set the respective
flag.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Link: https://lore.kernel.org/r/20211022064800.14978-5-jgr...@suse.com
Signe
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 1c669938c31b6e2a0d5149c3c6257ca9df6cb100 ]
Similar to the virtual frame buffer (vfb) the pv display driver is not
essential for booting the system. Set the respective flag.
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Bor
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 37a72b08a3e1eb28053214dd8211eb09c2fd3187 ]
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are identif
From: Juergen Gross
[ Upstream commit de6da33e6cb79abd4a5721b65b9a7dbed24378f8 ]
The Xen pv sound driver is not essential for booting. Set the respective
flag.
[boris: replace semicolon with comma]
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
On 30/11/2021 14:32, Jan Beulich wrote:
> On 30.11.2021 15:25, Andrew Cooper wrote:
>> On 30/11/2021 14:03, Jan Beulich wrote:
>>> On 30.11.2021 14:48, Andrew Cooper wrote:
On 29/11/2021 09:04, Jan Beulich wrote:
> The aim being to have as few indirect calls as possible (see [1]),
> wh
On 30/11/2021 13:11, Andrew Cooper wrote:
> On 30/11/2021 10:04, Andrew Cooper wrote:
>> There is no circumstance under which any part of the Xen image in memory
>> wants
>> to have any cacheability other than Write Back.
>>
>> Furthermore, unmapping random pieces of Xen like that comes with a
>>
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit 897919ad8b42eb8222553838ab82414a924694aa ]
This configuration option provides a misc device as an API to userspace.
Make this API usable without having to select the module as a transitive
dependency.
This also fixes an issue where localyesconfig would sele
From: Juergen Gross
[ Upstream commit de6da33e6cb79abd4a5721b65b9a7dbed24378f8 ]
The Xen pv sound driver is not essential for booting. Set the respective
flag.
[boris: replace semicolon with comma]
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
From: Juergen Gross
[ Upstream commit 03e143b2acebe23c893f22ebed9abc0fe2a7f27e ]
The Xen pvcalls device is not essential for booting. Set the respective
flag.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Link: https://lore.kernel.org/r/20211022064800.14978-5-jgr...@suse.com
Signe
From: Juergen Gross
[ Upstream commit 1c669938c31b6e2a0d5149c3c6257ca9df6cb100 ]
Similar to the virtual frame buffer (vfb) the pv display driver is not
essential for booting the system. Set the respective flag.
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Bor
From: Juergen Gross
[ Upstream commit 37a72b08a3e1eb28053214dd8211eb09c2fd3187 ]
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are identif
On 30.11.2021 14:49, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:44:50AM +0200, Jan Beulich wrote:
>> Or really, in the case of ->map_page(), accommodate it in the existing
>> "flags" parameter. All call sites will pass 0 for now.
>
> It feels slightly weird from an interface PoV that the
On 30.11.2021 12:56, Roger Pau Monné wrote:
> On Mon, Sep 27, 2021 at 11:04:26AM +0200, Jan Beulich wrote:
>> On 24.09.2021 16:45, Roger Pau Monné wrote:
>>> On Fri, Sep 24, 2021 at 11:42:13AM +0200, Jan Beulich wrote:
-parent = (struct dma_pte
*)map_vtd_domain_page(hd->arch.vtd.pgd_
On 30.11.2021 15:25, Andrew Cooper wrote:
> On 30/11/2021 14:03, Jan Beulich wrote:
>> On 30.11.2021 14:48, Andrew Cooper wrote:
>>> On 29/11/2021 09:04, Jan Beulich wrote:
The aim being to have as few indirect calls as possible (see [1]),
whereas during initial conversion performance was
On 30/11/2021 14:03, Jan Beulich wrote:
> On 30.11.2021 14:48, Andrew Cooper wrote:
>> On 29/11/2021 09:04, Jan Beulich wrote:
>>> The aim being to have as few indirect calls as possible (see [1]),
>>> whereas during initial conversion performance was the main aspect and
>>> hence rarely used hooks
On 30.11.2021 14:48, Andrew Cooper wrote:
> On 29/11/2021 09:04, Jan Beulich wrote:
>> The aim being to have as few indirect calls as possible (see [1]),
>> whereas during initial conversion performance was the main aspect and
>> hence rarely used hooks didn't get converted. Apparently one use of
>
On Fri, Sep 24, 2021 at 11:44:50AM +0200, Jan Beulich wrote:
> Or really, in the case of ->map_page(), accommodate it in the existing
> "flags" parameter. All call sites will pass 0 for now.
It feels slightly weird from an interface PoV that the map handler
takes the order from the flags parameter
On 29/11/2021 09:04, Jan Beulich wrote:
> The aim being to have as few indirect calls as possible (see [1]),
> whereas during initial conversion performance was the main aspect and
> hence rarely used hooks didn't get converted. Apparently one use of
> get_interrupt_shadow() was missed at the time.
On 30/11/2021 10:04, Andrew Cooper wrote:
> There is no circumstance under which any part of the Xen image in memory wants
> to have any cacheability other than Write Back.
>
> Furthermore, unmapping random pieces of Xen like that comes with a non-trivial
> risk of a Triple Fault, or other fatal co
On 30/11/2021 11:22, Jan Beulich wrote:
> On 30.11.2021 12:14, Andrew Cooper wrote:
>> On 30/11/2021 10:33, Jan Beulich wrote:
>>> On 30.11.2021 11:04, Andrew Cooper wrote:
It has been 4 years since the default load address changed from 1M to 2M,
and
_stext ceased residing in l2_xen
flight 166941 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166941/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166912
test-amd64-amd64-xl-qemut-win7-amd64
On Fri, Sep 24, 2021 at 11:43:57AM +0200, Jan Beulich wrote:
> Generic code will use this information to determine what order values
> can legitimately be passed to the ->{,un}map_page() hooks. For now all
> ops structures simply get to announce 4k mappings (as base page size),
> and there is (and
On Mon, Sep 27, 2021 at 11:04:26AM +0200, Jan Beulich wrote:
> On 24.09.2021 16:45, Roger Pau Monné wrote:
> > On Fri, Sep 24, 2021 at 11:42:13AM +0200, Jan Beulich wrote:
> >> -parent = (struct dma_pte
> >> *)map_vtd_domain_page(hd->arch.vtd.pgd_maddr);
> >> -while ( level > 1 )
> >> +
flight 166589 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166589/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 30.11.2021 12:14, Andrew Cooper wrote:
> On 30/11/2021 10:33, Jan Beulich wrote:
>> On 30.11.2021 11:04, Andrew Cooper wrote:
>>> It has been 4 years since the default load address changed from 1M to 2M,
>>> and
>>> _stext ceased residing in l2_xenmap[0]. We should not be inserting an
>>> unu
flight 166764 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 30.11.2021 12:16, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
In case it matters
Acked-by: Jan Beulich
Jan
> ---
> SUPPORT.md | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index b1367e2b22..85726102ea 100644
> --- a/SUPPORT.md
Signed-off-by: Ian Jackson
---
SUPPORT.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index b1367e2b22..85726102ea 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -10,9 +10,9 @@ for the definitions of the support status levels etc.
# Release Supp
On 30/11/2021 10:33, Jan Beulich wrote:
> On 30.11.2021 11:04, Andrew Cooper wrote:
>> It has been 4 years since the default load address changed from 1M to 2M, and
>> _stext ceased residing in l2_xenmap[0]. We should not be inserting an unused
>> mapping.
>>
>> To ensure we don't create mappings
Hello,
I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
which uncovered an issue with get_desc() trying to access the GDT, as
introduced by 670f928ba09b ("x86/insn-eval: Add utility function to
get segment descriptor"). When running in a PV domain under Xen, the
(hypervisor's) G
On 30.11.2021 11:04, Andrew Cooper wrote:
> It has been 4 years since the default load address changed from 1M to 2M, and
> _stext ceased residing in l2_xenmap[0]. We should not be inserting an unused
> mapping.
>
> To ensure we don't create mappings accidentally, loop from 0 and obey
> _PAGE_PRE
On 30.11.2021 10:37, Ayan Kumar Halder wrote:
> On 30/11/2021 07:18, Jan Beulich wrote:
>> On 29.11.2021 20:44, Ayan Kumar Halder wrote:
>>> GENMASK(30, 21) should be 0x07fe0
>>
>> Please can this have a meaningful title? E.g. "bitops: fix incorrect
>> value in comment"?
>>
>>> --- a/xen/includ
There is no circumstance under which any part of the Xen image in memory wants
to have any cacheability other than Write Back.
Furthermore, unmapping random pieces of Xen like that comes with a non-trivial
risk of a Triple Fault, or other fatal condition. Even if it appears to work,
an NMI or int
At the moment, we have two locations selecting restricted permissions, not
very far apart on boot, dependent on opposite answers from using_2M_mapping().
The later location however can shatter superpages if needed, while the former
cannot.
Collect together all the permission adjustments at the sli
The calculation in __start_xen() for xen_virt_end is an opencoding of
ROUNDUP(_end, 2M). This is __2M_rwdata_end as provided by the linker script.
This corrects the bound calculations in arch_livepatch_init() and
update_xen_mappings() to not enforce 2M alignment when Xen is not compiled
with CONF
The first loop relocates all reachable non-leaf entries in idle_pg_table[],
which includes l2_xenmap[511]'s reference to l1_fixmap_x[].
The second loop relocates only leaf mappings in l2_xenmap[], so update the
skip condition to be opposite to the first loop.
No functional change.
Signed-off-by:
Also some prep cleanup, because the boot time pagetable handling is seemingly
impossible to edit without finding more skeletons lying around...
Andrew Cooper (8):
x86/boot: Drop incorrect mapping at l2_xenmap[0]
x86/boot: Better describe the pagetable relocation loops
x86/boot: Fix data plac
multiboot_ptr should be in __initdata - it is only used on the BSP path.
Furthermore, the .align 8 then .long means that stack_start is misaligned.
Move both into setup.c, which lets the compiler handle the details correctly,
as well as providling proper debug information for them.
Declare stack_
For security hardening reasons, it advantageous to make setup-once data
immutable after boot. Borrow __ro_after_init from Linux.
On x86, place .data.ro_after_init at the start of .rodata, excluding it from
the early permission restrictions. Re-apply RO restrictions to the whole of
.rodata in ini
It has been 4 years since the default load address changed from 1M to 2M, and
_stext ceased residing in l2_xenmap[0]. We should not be inserting an unused
mapping.
To ensure we don't create mappings accidentally, loop from 0 and obey
_PAGE_PRESENT on all entries.
Fixes: 7ed93f3a0dff ("x86: chang
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
RFC. I don't know if this is something we'd want to keep or not.
Getting extable handling working for test_nx_data is proving tricky, and while
I can't spot anything that should stop the extable from working wit
On Mon, 29 Nov 2021 19:16:38 +
Ayan Kumar Halder wrote:
Hi,
> At the moment, Xen is only handling data abort with valid syndrome (i.e.
> ISV=0). Unfortunately, this doesn't cover all the instructions a domain
> could use to access MMIO regions.
>
> For instance, Xilinx baremetal OS will use
On 30/11/2021 07:28, Jan Beulich wrote:
> On 29.11.2021 18:42, Andrew Cooper wrote:
>> On 29/11/2021 17:26, Andrew Cooper wrote:
>>> It has been 4 years since the default load address changed from 1M to 2M,
>>> and
>>> _stext ceased residing in l2_xenmap[0]. We should not be inserting an
>>> unu
Hi Jan,
Thanks for the review. Just one question.
On 30/11/2021 07:18, Jan Beulich wrote:
On 29.11.2021 20:44, Ayan Kumar Halder wrote:
GENMASK(30, 21) should be 0x07fe0
Please can this have a meaningful title? E.g. "bitops: fix incorrect
value in comment"?
--- a/xen/include/xen/bitops
85 matches
Mail list logo
