On 01/05/2020 02:26, Stefano Stabellini wrote:
On Wed, 15 Apr 2020, Julien Grall wrote:
Hi Stefano,
On 15/04/2020 02:02, Stefano Stabellini wrote:
We always use a fix address to map the vPL011 to domains. The address
could be a problem for domains that are directly mapped.
Instead, for dom
On 01/05/2020 02:26, Stefano Stabellini wrote:
On Wed, 15 Apr 2020, Julien Grall wrote:
On 15/04/2020 02:02, Stefano Stabellini wrote:
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
On 01/05/2020 02:26, Stefano Stabellini wrote:
On Wed, 15 Apr 2020, Julien Grall wrote:
On 15/04/2020 02:02, Stefano Stabellini wrote:
In some cases it is desirable to map domU memory 1:1 (guest physical ==
physical.) For instance, because we want to assign a device to the domU
but the IOMMU
Hi Stefano,
On 01/05/2020 02:31, Stefano Stabellini wrote:
On Wed, 15 Apr 2020, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4e60ba15cc..4cf430f865 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1677,13 +1677,25 @@ static int vgic_
Hi Hongyan,
On 30/04/2020 21:44, Hongyan Xia wrote:
From: Hongyan Xia
Also add a helper function to retrieve it. Change arch_mfn_in_direct_map
to check this option before returning.
This is added as a boot command line option, not a Kconfig. We do not
produce different builds for EC2 so this
flight 149895 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
Hi Hongyan,
On 30/04/2020 21:44, Hongyan Xia wrote:
From: Hongyan Xia
When there is not an always-mapped direct map, xenheap allocations need
to be mapped and unmapped on-demand.
Signed-off-by: Hongyan Xia
---
xen/common/page_alloc.c | 45 ++---
1 file
flight 149892 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 149889
Tests which did no
On 01.05.20 00:24, Andrew Morton wrote:
> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand wrote:
>
>>>
>>> Why does the firmware map support hotplug entries?
>>
>> I assume:
>>
>> The firmware memmap was added primarily for x86-64 kexec (and still, is
>> mostly used on x86-64 only IIRC). The
Hi Samuel,
> On 1 May 2020, at 06:59, Samuel P. Felton - GPT LLC
> wrote:
>
> So, I’m trying to get a Xen Dom0 and DomU, both running Ubuntu 20.04 LTS up
> on our brand-new Gigabyte ThunderX2 ARM64 box. I can get Ubuntu up and
> running, but after installing the Xen bits, it dies after the UEF
On 1 May 2020, at 10:52, Bertrand Marquis
mailto:bertrand.marq...@arm.com>> wrote:
Hi Samuel,
On 1 May 2020, at 06:59, Samuel P. Felton - GPT LLC
mailto:sam.fel...@glacier-peak.net>> wrote:
So, I’m trying to get a Xen Dom0 and DomU, both running Ubuntu 20.04 LTS up on
our brand-new Gigabyte
*** LAST POSTING TODAY ***
This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Time
Hi,
On 01/05/2020 10:52, Bertrand Marquis wrote:
Hi Samuel,
On 1 May 2020, at 06:59, Samuel P. Felton - GPT LLC
wrote:
So, I’m trying to get a Xen Dom0 and DomU, both running Ubuntu 20.04 LTS up on
our brand-new Gigabyte ThunderX2 ARM64 box. I can get Ubuntu up and running,
but after inst
On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote:
> Hi!
>
> I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock,
> upstream kernel. The kernel itself works perfectly well
> on the board. When I try booting it as Dom0 under Xen,
> it goes into a stacktrace (attached).
Getting
flight 149893 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149893/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149882
test-amd64-amd64-xl-qemut-win7-amd64
On Fri, May 01, 2020 at 12:27:17AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> > # Option #3: Lean on Grub2's LoadFile2() Verification
> >
> > Grub2 will provide a LoadFile2() method to subsequent programs that supports
> > signature
On Thu, Apr 30, 2020 at 09:44:11PM +0100, Hongyan Xia wrote:
> From: Hongyan Xia
>
> Also, introduce a wrapper around vmap that maps a contiguous range for
> boot allocations.
>
> Signed-off-by: Hongyan Xia
> ---
> xen/drivers/acpi/osl.c | 9 -
> xen/include/xen/vmap.h | 5 +
> 2 f
On Thu, Apr 30, 2020 at 09:44:09PM +0100, Hongyan Xia wrote:
> From: Hongyan Xia
>
> This series depends on Xen page table domheap conversion:
> https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg01374.html.
>
> After breaking the reliance on the direct map to manipulate Xen page
>
On Thu, Apr 30, 2020 at 09:44:20PM +0100, Hongyan Xia wrote:
> From: Hongyan Xia
>
> Also add a helper function to retrieve it. Change arch_mfn_in_direct_map
> to check this option before returning.
>
> This is added as a boot command line option, not a Kconfig. We do not
> produce different bui
On Thu, Apr 30, 2020 at 12:00:51PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> After XSA-273, it is not possible to modify the vCPU soft affinity using
> xl vcpu-pin without modifying the hard affinity. Instead the command
> will crash.
>
> 42sh> gdb /usr/local/sbin/xl
> (gdb) r vcpu-pin
On Thu, Apr 30, 2020 at 12:24:15PM +0200, Jan Beulich wrote:
> Along the lines of what the not reverted part of 3c4b2eef4941 ("x86:
> refine link time stub area related assertion") did, we need to transform
> the absolute HV_HCALL_PAGE into the image base relative hv_hcall_page
> (or else there'd b
On 01/05/2020 13:17, Wei Liu wrote:
> On Thu, Apr 30, 2020 at 12:24:15PM +0200, Jan Beulich wrote:
>> Along the lines of what the not reverted part of 3c4b2eef4941 ("x86:
>> refine link time stub area related assertion") did, we need to transform
>> the absolute HV_HCALL_PAGE into the image base re
On Fri, May 01, 2020 at 01:19:39PM +0100, Andrew Cooper wrote:
> On 01/05/2020 13:17, Wei Liu wrote:
> > On Thu, Apr 30, 2020 at 12:24:15PM +0200, Jan Beulich wrote:
> >> Along the lines of what the not reverted part of 3c4b2eef4941 ("x86:
> >> refine link time stub area related assertion") did, we
On Fri, May 01, 2020 at 01:59:59PM +0200, Daniel Kiper wrote:
> On Fri, May 01, 2020 at 12:27:17AM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> > > # Option #3: Lean on Grub2's LoadFile2() Verification
> > >
> > > Grub2 will provide
On Fri, 2020-05-01 at 12:02 +, Wei Liu wrote:
> On Thu, Apr 30, 2020 at 09:44:11PM +0100, Hongyan Xia wrote:
> > From: Hongyan Xia
> >
> > Also, introduce a wrapper around vmap that maps a contiguous range
> > for
> > boot allocations.
> >
> > Signed-off-by: Hongyan Xia
> > ---
> > xen/dri
On Fri, 2020-05-01 at 12:11 +, Wei Liu wrote:
> On Thu, Apr 30, 2020 at 09:44:20PM +0100, Hongyan Xia wrote:
> > From: Hongyan Xia
> >
> > Also add a helper function to retrieve it. Change
> > arch_mfn_in_direct_map
> > to check this option before returning.
> >
> > This is added as a boot c
On Fri, May 01, 2020 at 01:59:24PM +0100, Hongyan Xia wrote:
> On Fri, 2020-05-01 at 12:11 +, Wei Liu wrote:
> > On Thu, Apr 30, 2020 at 09:44:20PM +0100, Hongyan Xia wrote:
> > > From: Hongyan Xia
> > >
> > > Also add a helper function to retrieve it. Change
> > > arch_mfn_in_direct_map
> >
flight 149894 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149894/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 149890
Tests which did not succee
On Fri, 2020-05-01 at 12:07 +, Wei Liu wrote:
> On Thu, Apr 30, 2020 at 09:44:09PM +0100, Hongyan Xia wrote:
> > From: Hongyan Xia
> >
> > This series depends on Xen page table domheap conversion:
> >
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg01374.html
> > .
> >
> > A
On Thu, Apr 23, 2020 at 9:33 AM Tamas K Lengyel wrote:
>
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch
> model
> in which the user can execute the fork without the device model and decide
On Tue, Apr 28, 2020 at 04:20:57PM +0200, Jan Beulich wrote:
> On 28.04.2020 16:01, Anthony PERARD wrote:
> > On Thu, Apr 23, 2020 at 06:48:51PM +0200, Jan Beulich wrote:
> >> On 21.04.2020 18:12, Anthony PERARD wrote:
> >>> --- a/xen/Rules.mk
> >>> +++ b/xen/Rules.mk
> >>> @@ -123,6 +123,7 @@ $(ob
On Tue, Apr 28, 2020 at 03:48:13PM +0200, Jan Beulich wrote:
> On 21.04.2020 18:12, Anthony PERARD wrote:
> > In the case where $(obj-y) is empty, we also replace $(c_flags) by
> > $(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
> > make trying to include %.h file in the ld co
Hi,
On 01/05/2020 14:11, Wei Liu wrote:
On Fri, May 01, 2020 at 01:59:24PM +0100, Hongyan Xia wrote:
On Fri, 2020-05-01 at 12:11 +, Wei Liu wrote:
On Thu, Apr 30, 2020 at 09:44:20PM +0100, Hongyan Xia wrote:
From: Hongyan Xia
Also add a helper function to retrieve it. Change
arch_mfn_in
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
>
> On 01.05.20 00:24, Andrew Morton wrote:
> > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand
> > wrote:
> >
> >>>
> >>> Why does the firmware map support hotplug entries?
> >>
> >> I assume:
> >>
> >> The firmware memmap was added p
On 01.05.20 18:56, Dan Williams wrote:
> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
>>
>> On 01.05.20 00:24, Andrew Morton wrote:
>>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand
>>> wrote:
>>>
>
> Why does the firmware map support hotplug entries?
I assume
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>
> On 01.05.20 18:56, Dan Williams wrote:
> > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 00:24, Andrew Morton wrote:
> >>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand
> >>> wrote:
> >>>
> >
On 01.05.20 19:39, Dan Williams wrote:
> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>>
>> On 01.05.20 18:56, Dan Williams wrote:
>>> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
On 01.05.20 00:24, Andrew Morton wrote:
> On Thu, 30 Apr 2020 20:43:39 +0200 Dav
On 01.05.20 19:45, David Hildenbrand wrote:
> On 01.05.20 19:39, Dan Williams wrote:
>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>>>
>>> On 01.05.20 18:56, Dan Williams wrote:
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
>
> On 01.05.20 00:24, Andrew Morton
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
>
> On 01.05.20 19:45, David Hildenbrand wrote:
> > On 01.05.20 19:39, Dan Williams wrote:
> >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
> >>>
> >>> On 01.05.20 18:56, Dan Williams wrote:
> On Fri, May 1, 2020 at 2:34 A
On 01.05.20 20:03, Dan Williams wrote:
> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
>>
>> On 01.05.20 19:45, David Hildenbrand wrote:
>>> On 01.05.20 19:39, Dan Williams wrote:
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>
> On 01.05.20 18:56, Dan Williams
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
>
> On 01.05.20 20:03, Dan Williams wrote:
> > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 19:45, David Hildenbrand wrote:
> >>> On 01.05.20 19:39, Dan Williams wrote:
> On Fri, May 1, 2020 at 10:21 A
On 01.05.20 20:43, Dan Williams wrote:
> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
>>
>> On 01.05.20 20:03, Dan Williams wrote:
>>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
On 01.05.20 19:45, David Hildenbrand wrote:
> On 01.05.20 19:39, Dan Williams w
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote:
>
> On 01.05.20 20:43, Dan Williams wrote:
> > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 20:03, Dan Williams wrote:
> >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand
> >>> wrote:
>
> On
On 01.05.20 22:12, Dan Williams wrote:
> On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote:
>>
>> On 01.05.20 20:43, Dan Williams wrote:
>>> On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
On 01.05.20 20:03, Dan Williams wrote:
> On Fri, May 1, 2020 at 10:51 AM David
Hi,
On Thu, 30 Apr 2020 at 21:44, Hongyan Xia wrote:
>
> From: Hongyan Xia
>
> Also, introduce a wrapper around vmap that maps a contiguous range for
> boot allocations.
>
> Signed-off-by: Hongyan Xia
> ---
> xen/drivers/acpi/osl.c | 9 -
> xen/include/xen/vmap.h | 5 +
> 2 files c
flight 149896 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149896/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail in 149892 pass
in 149896
test-armhf-armhf-xl-rtd
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote:
>
> On 01.05.20 22:12, Dan Williams wrote:
[..]
> >>> Consider the case of EFI Special Purpose (SP) Memory that is
> >>> marked EFI Conventional Memory with the SP attribute. In that case the
> >>> firmware memory map marked it as conventiona
For now, any #CP exception or shadow stack #PF indicate a bug in Xen, but
attempt to recover if taken in guest context.
Drop the comment beside do_page_fault(). It's stale (missing PFEC_prot_key),
and inaccurate (PFEC_present being set means just that, not necesserily a
protection violation).
Si
For one, they render the vector in a different base.
Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
mnemonic, which starts bringing the code/diagnostics in line with the Intel
and AMD manuals.
Provide constants for every archtiecturally defined exception, even those
This series implements Shadow Stack support for Xen to use.
You'll need a CET-capable toolchain (Binutils 2.32 and later), but no specific
compiler support required.
CET-SS makes PV32 unusable, so using shadow stacks prevents the use of 32bit
PV guests. Compatibilty can be obtained using PV Shim
Introduce CONFIG_HAS_AS_CET to determine whether CET instructions are
supported in the assembler, and CONFIG_XEN_SHSTK as the main build option.
Introduce xen={no-,}shstk to for a user to select whether or not to use shadow
stacks at runtime, and X86_FEATURE_XEN_SHSTK to determine Xen's overall
en
Introduce HYPERVISOR_SHSTK pagetable constants, which are Read-Only + Dirty.
Use these in place of _PAGE_NONE for memguard_guard_stack().
Supervisor shadow stacks need a token written at the top, which is most easily
done before making the frame read only.
Allocate the shadow IST stack block in s
When executing an IRET-to-self, the shadow stack must agree with the regular
stack. We can't manipulate SSP directly, so have to fake a shadow IRET frame
by executing 3 CALLs, then editing the result to look correct.
This is not a fastpath, is called on the BSP long before CET can be set up,
and
We have two free pages in the current stack. A useful property of shadow
stacks and regular stacks is that they act as each others guard pages as far
as OoB writes go.
Move the regular IST stacks up by one page, to allow their shadow stack page
to be in slot 0. The primary shadow stack uses slot
The only user of this facility is dom_crash_sync_extable() by passing 0 into
asm_domain_crash_synchronous(). The common error cases are already covered
with show_page_walk(), leaving only %ss/%fs selector/segment errors in the
compat case.
Point at dom_crash_sync_extable in the error message, whi
UD faults never had any diagnostics printed, and the others were inconsistent.
Don't use dprintk() because identifying traps.c is actively unhelpful in the
message, as it is the location of the fixup, not the fault. Use the new
vec_name() infrastructure, rather than leaving raw numbers for the lo
This allows the AP boot assembly use per-cpu variables, and brings the
semantics closer to that of the BSP, which can use per-cpu variables from the
start of day.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/smpboot.c| 7 ++-
xe
The SYSCALL/SYSEXIT paths need to use {SET,CLR}SSBSY. The IRET to guest paths
must not, which forces us to spill a register to the stack.
The IST switch onto the primary stack is not great as we have an instruction
boundary with no shadow stack. This is the least bad option available.
These pat
When adjusting an IRET frame to recover from a fault, and equivalent
adjustment needs making in the shadow IRET frame.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/traps.c| 22 ++
xen/arch/x86/x86_64/entry.S | 11
The current alternatives algorithm clears CR0.WP and writes into .text. This
has a side effect of the mappings becoming shadow stacks once CET is active.
Adjust _alternative_instructions() to clean up after itself. This involves
extending the set of bits modify_xen_mappings() to include Dirty (a
We need to unwind up to the supervisor token. See the comment for details.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/current.h | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
dif
With all other plumbing in place, activate shadow stacks when possible.
The BSP needs to wait until alternatives have run (to avoid interaction with
CR0.WP), and after the first reset_stack_and_jump() to avoid having a pristine
shadow stack interact in problematic ways with an in-use regular stack
The logic is completely undocumented and almost impossible to follow. It
actually uses return oriented programming. Rewrite it to conform to more
normal call mechanics, and leave a big comment explaining thing. As well as
the code being easier to follow, it will execute faster as it isn't fighti
The 32 calls need dropping from the shadow stack as well as the regular stack.
To shorten the code, we can use the 32bit forms of RDSSP/INCSSP, but need to
double up the input to INCSSP to counter the operand size based multiplier.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC
flight 149898 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149898/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 15 guest-saverestorefail REGR. vs. 149894
Tests which did not succee
Hi Roman,
In regards to the attached stack trace, nothing rings a bell
unfortunately. I don't know why quirk_usb_early_handoff causes a crash.
It would be useful to add a few printk in quirk_usb_early_handoff to
know where the crash is happening exactly.
In regards to Dornerworks's third patch,
On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote:
>
> On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote:
> > Hi!
> >
> > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock,
> > upstream kernel. The kernel itself works perfectly well
> > on the board. When I try booting it as
Hi Stefano!
On Fri, May 1, 2020 at 5:05 PM Stefano Stabellini
wrote:
>
> Hi Roman,
>
>
> In regards to the attached stack trace, nothing rings a bell
> unfortunately. I don't know why quirk_usb_early_handoff causes a crash.
> It would be useful to add a few printk in quirk_usb_early_handoff to
>
On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote:
> On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote:
> >
> > On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote:
> > > Hi!
> > >
> > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock,
> > > upstream kernel. T
flight 149899 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149899/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 149893
Tests which did not succeed,
flight 149902 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
71 matches
Mail list logo
