On 09/03/2018 06:25 PM, Hans Verkuil wrote:
Hi Oleksandr,
On 09/03/2018 12:16 PM, Oleksandr Andrushchenko wrote:
On 08/21/2018 08:54 AM, Oleksandr Andrushchenko wrote:
On 08/14/2018 11:30 AM, Juergen Gross wrote:
On 31/07/18 11:31, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 3, 2018 7:47 PM
>
> >>> On 03.09.18 at 10:23, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 30 August 2018 17:00
> >>
> >> >>> On 23.08.18 at 11:46, wrote:
> >> > --- a/xen/include/xen/mm.h
> >> > +++
flight 127237 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127237/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 04722cfa309104d815257a2705db5ee7024dc9bf
baseline version:
ovmf e3b9ab433aaccffdcc71c
flight 127242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, September 3, 2018 6:40 PM
>
> On 04/06/18 14:59, Andrew Cooper wrote:
> > See the code comment for the details.
> >
> > Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them read-only inside the EPT; this
way any modification explicitly made by the guest or implicitly made by
the CPU page walker would trigger an EPT violation, which would be
forwarded by Xen to
flight 127234 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
flight 127226 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127226/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126467
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 127228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
flight 127206 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127206/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 127148
test-amd64-
flight 127205 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127205/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd broken
build-amd64-xen-free
On 03/09/18 23:41, osstest service owner wrote:
> flight 127225 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/127225/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-debi
flight 127225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
On Thu, Aug 09, 2018 at 10:25:42AM +0100, Wei Liu wrote:
> On Tue, Aug 07, 2018 at 04:16:07AM +0200, Marek Marczykowski-Górecki wrote:
> > From: Eric Shelton
> >
> > This enum gives the ability to select between a MiniOS-based QEMU
> > traditional stub domain and a Linux-based QEMU upstream stub
This run is configured for baseline tests only.
flight 75160 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75160/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75158
test
flight 127219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
This run is configured for baseline tests only.
flight 75158 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75158/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75153
test
flight 127193 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127193/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125898
test-amd64-amd64-ru
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 03 September 2018 18:14
> To: Shameerali Kolothum Thodi ;
> xen-de...@lists.xen.org
> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> Przywara
> Subject: Re: Xen Dom0 boot failure on platform that supports ARM
flight 127215 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
On 29/08/18 15:24, Jan Beulich wrote:
> Drop the pretty pointless conditionals from code testing AVX insns and
> properly use AVX2 mnemonics in code testing AVX2 insns (the test harness
> is already requiring sufficiently new a compiler/assembler).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
On 29/08/18 15:24, Jan Beulich wrote:
> These are all VEX encoded, so the EVEX decoding logic continues to
> remain unused at this point.
>
> The new testcase is deliberately coded in assembly, as a C one would
> have become almost unreadable due to the overwhelming amount of
> __builtin_...() that
Hi Julien,
On 03.09.18 20:38, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
s/destuction/destruction/
calls.
This is all what is
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
s/destuction/destruction/
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build
flight 127208 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127208/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e3b9ab433aaccffdcc71c4af286ac352d4ce7c20
baseline version:
ovmf 374168ae651fabcb77a0b
Hi,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Currently this call used only to enable TEE support for a domain.
It is planed to extend it when there will be multiple TEE
mediators, so toolstack can determine which TEE is available
on a platform.
Signed-off-by: Volodymyr Babchuk
---
xen/ar
On 03/09/18 17:54, Shameerali Kolothum Thodi wrote:
Hi Julien,
Thanks for taking a look at this.
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 03 September 2018 17:13
To: Shameerali Kolothum Thodi ;
xen-de...@lists.xen.org
Cc: sstabell...@kernel.org; Linux
On Mon, Sep 03, 2018 at 02:59:42PM +0200, Juergen Gross wrote:
> Trying to set the number of vcpus of a domain to 0 isn't refused.
> We should not allow that.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lis
On Mon, Sep 03, 2018 at 06:05:34PM +0100, Andrew Cooper wrote:
> On 03/09/18 18:01, Wei Liu wrote:
> > On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
> >> On 03/09/18 17:54, Wei Liu wrote:
> >>> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> This is the first
On 03/09/18 18:01, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
>> On 03/09/18 17:54, Wei Liu wrote:
>>> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
This is the first step in making the destroy path idepotent, and using it
in
>>> "ide
On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
> On 03/09/18 17:54, Wei Liu wrote:
> > On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> >> This is the first step in making the destroy path idepotent, and using it
> >> in
> > "idempotent".
> >
> >> place of the ad-ho
On Mon, Sep 03, 2018 at 05:48:03PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, Sep 03, 2018 at 01:26:30PM +0200, Juergen Gross wrote:
> Fix another smt=0 fallout: xl -N vcpu-pin prints only parts of the
> affinities as it is using the number of online cpus instead of the
> maximum cpu number.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
On Mon, Sep 03, 2018 at 03:47:00PM +0100, Andrew Cooper wrote:
> ... and move it into the common __domain_destroy() path.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
On 03/09/18 17:54, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
>> This is the first step in making the destroy path idepotent, and using it in
> "idempotent".
>
>> place of the ad-hoc cleanup paths in the create path.
>>
>> To begin with, the trivial free operati
On Mon, Sep 03, 2018 at 03:46:59PM +0100, Andrew Cooper wrote:
> xsm_free_security_domain() is idempotent (both the dummy handler, and the
> flask handler). Move it into the shared __domain_destroy() path, and drop the
> INIT_xsm flag from domain_create()
>
> Signed-off-by: Andrew Cooper
Review
On Mon, Sep 03, 2018 at 03:46:58PM +0100, Andrew Cooper wrote:
> lock_profile_register_struct() is called from common code, but the matching
> deregister was previously only called from x86 code.
>
> The practical upshot of this when using CONFIG_LOCK_PROFILE, destroyed domains
> on ARM (and in pa
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr Babchuk
---
tools/libxl/libxl_arm.c | 29 ++
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will call xc_dom_tee_enable(...) to ask
hypervisor to enable TEE support.
Signed-off-by: Volodymyr Babchuk
---
docs/man/xl.cfg.pod.5.in| 10 ++
tools/libxl/libxl_arm.c | 30
This function uses XEN_DOMCTL_tee_op domctl to enable TEE
support for a given domain.
Signed-off-by: Volodymyr Babchuk
---
tools/libxc/include/xenctrl.h | 7 +++
tools/libxc/xc_domain.c | 13 +
2 files changed, 20 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, becuase mediator need to do address translation in the same
way as it was done for shared buffers registered by NW.
As mediator now accesses shared command buff
OP-TEE meditor needs to store per-domain context, as will be seen
in the next patches. At this moment it stores only reference to domain.
This allows us to filter out calls from domains that are not allowed
to work with OP-TEE.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 66
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC requests. Usually this buf
Shared memory is widely used by NW to communicate with
TAs in OP-TEE. NW can share part of own memory with
TA or OP-TEE core, by registering it OP-TEE, or by providing
a temporal refernce. Anyways, information about such memory
buffers are sent to OP-TEE as a list of pages. This mechanism
is descri
Main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contranst with fast calls, where arguments and return values
are passed in registers, standar
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP-TEE memory with a domain.
Only domain can share memory with OP-TE
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE from DomU will fail and ca
From: Volodymyr Babchuk
Hello all,
This is v2 of patch series for OP-TEE mediator support in XEN. Changes from v1:
- Added domctl interface, so now xl decides what domain should work with TEE
- Removed XSM support due to change described above
- Patch with OP-TEE mediator was splited to 7 se
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcomient OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and
Currently this call used only to enable TEE support for a domain.
It is planed to extend it when there will be multiple TEE
mediators, so toolstack can determine which TEE is available
on a platform.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domctl.c | 10 ++
xen/include/p
On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> This is the first step in making the destroy path idepotent, and using it in
"idempotent".
> place of the ad-hoc cleanup paths in the create path.
>
> To begin with, the trivial free operations are broken out. The rest of the
> cl
Hi Julien,
Thanks for taking a look at this.
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 03 September 2018 17:13
> To: Shameerali Kolothum Thodi ;
> xen-de...@lists.xen.org
> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> Przywara
> Subject: Re: Xen Do
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index a7cc3f3..ab53fc4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -311,6 +311,7 @@ xen/arch/*/efi/runtime.c
xen/include/
On Mon, Sep 03, 2018 at 03:46:56PM +0100, Andrew Cooper wrote:
> Given two subtle failures from getting this wrong before, and more cleanup on
> the way, move the setting of d->guest_type as early as possible.
>
> Note that despite moving the assignment of d->guest_type outside of the
> is_idle_do
My recent patch [1] to qemu-xen-traditional removes the last use of the
'default' ioreq server in Xen. (This is a catch-all ioreq server that is
used if no explicitly registered I/O range is targetted).
This patch can be applied once that patch is committed, to remove the
(>100 lines of) redundant
On 29/08/18 15:23, Jan Beulich wrote:
> While deriving the first AVX512 pieces from existing code I've got the
> (in the end wrong) impression that the emulation of these insns would be
> broken. Besides testing that the instructions act as no-ops when the
> controlling mask bits are all zero, add
On 29/08/18 15:23, Jan Beulich wrote:
> FMA insns, other than the earlier AVX additions, don't use the low
> opcode bit to distinguish between single and double vector elements.
I think I've worked out why "other than the" is so weird to read as a
native speaker here. I think you mean "unlike the
On 27/07/18 15:20, Jan Beulich wrote:
> In order to mostly eliminate abuse of what Xen leaves in the RSB by
> guest level attackers, fill the RSB with almost-NULL pointers right
> before entering guest context.
How do you envisage an attacker using what Xen leaves in the RSB? An
attacker doesn't
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 September 2018 16:45
> To: xen-devel
> Cc: Olaf Hering ; Andrew Cooper
> ; Paul Durrant
> Subject: [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in
> more cases
>
> Assuming consecutive linea
On 03/09/18 15:53, Shameerali Kolothum Thodi wrote:
Hi,
Hello,
I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
has support for GICv4.
But dom0(kernel 4.18) boot fails with the below trap,
XEN) done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN)
>>> On 03.09.18 at 16:47, wrote:
> ... and move it into the common __domain_destroy() path.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/li
>>> On 03.09.18 at 16:46, wrote:
> xsm_free_security_domain() is idempotent (both the dummy handler, and the
> flask handler). Move it into the shared __domain_destroy() path, and drop the
> INIT_xsm flag from domain_create()
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
>>> On 03.09.18 at 16:46, wrote:
> lock_profile_register_struct() is called from common code, but the matching
> deregister was previously only called from x86 code.
>
> The practical upshot of this when using CONFIG_LOCK_PROFILE, destroyed domains
> on ARM (and in particular, the freed page behi
>>> On 03.09.18 at 16:46, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char *s)
> }
> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>
> +/*
> + * Destroy a domain once all references to it have
>>> On 03.09.18 at 16:46, wrote:
> Given two subtle failures from getting this wrong before, and more cleanup on
> the way, move the setting of d->guest_type as early as possible.
>
> Note that despite moving the assignment of d->guest_type outside of the
> is_idle_domain(d) check, it still behav
Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
domain to change the value of the #VE suppress bit for a page.
Add a libxc wrapper for invoking this hvmop.
Signed-off-by: Adrian Pop
Acked-by: Wei Liu
Acked-by: Tamas K Lengyel
---
Changes in v5:
- remove the "set_" from stru
Signed-off-by: Adrian Pop
---
tools/libxc/include/xenctrl.h | 2 ++
tools/libxc/xc_altp2m.c | 26 +++
xen/arch/x86/hvm/hvm.c | 19 ++
xen/arch/x86/mm/mem_access.c| 45 +
xen/include/public/hvm/hvm_op.h | 2 ++
xe
As the code stands right now, after DomU has enabled #VE using
HVMOP_altp2m_vcpu_enable_notify, all its pages have the #VE suppress bit
cleared, generating #VEs for any EPT violation. There is currently no
way to change the value of the #VE suppress bit for a page from a
domain; it can only be don
From: Vlad Ioan Topan
The default value for the "suppress #VE" bit set by set_mem_access()
currently depends on whether the call is made from the same domain (the
bit is set when called from another domain and cleared if called from
the same domain). This patch changes that behavior to inherit th
Currently there is a subop for setting the memaccess of a page, but not
for consulting it. The new HVMOP_altp2m_get_mem_access adds this
functionality.
Both altp2m get/set mem access functions use the struct
xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
been renamed from
Assuming consecutive linear addresses map to all RAM or all MMIO is not
correct. Nor is assuming that a page straddling MMIO access will access
the same emulating component for both parts of the access. If a guest
RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
a page bounda
It can easily be expressed through hvm_copy_from_guest_linear(), and in
two cases this even simplifies callers.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Make sure this compiles standalone. Slightly adjust change in
hvm_ud_intercept().
--- a/x
1: drop hvm_fetch_from_guest_linear()
2: split page straddling emulated accesses in more cases
v2: Patch 1 now builds cleanly (without other patches in place the up-to-
date versions of which are yet to be posted), and patch 2 is no longer RFC.
Jan
_
In order to build a tailored pvshim-only binary from Xen. Switch the
PV shim build from the tools firmware into using the new defconfig.
A diff of the .config generated for the pvshim firmware build before
and after this change shows no differences.
Signed-off-by: Roger Pau Monné
Acked-by: Ian J
On Mon, Sep 03, 2018 at 05:33:26PM +0200, Roger Pau Monne wrote:
> The hvmloader binary generated when using LLVM LD doesn't work
> properly and seems to get stuck while trying to generate and load the
> ACPI tables. This is caused by the layout of the binary when linked
> with LLVM LD.
>
> LLVM L
The hvmloader binary generated when using LLVM LD doesn't work
properly and seems to get stuck while trying to generate and load the
ACPI tables. This is caused by the layout of the binary when linked
with LLVM LD.
LLVM LD has a different default linker script that GNU LD, and the
resulting hvmloa
Hi Oleksandr,
On 09/03/2018 12:16 PM, Oleksandr Andrushchenko wrote:
> On 08/21/2018 08:54 AM, Oleksandr Andrushchenko wrote:
>> On 08/14/2018 11:30 AM, Juergen Gross wrote:
>>> On 31/07/18 11:31, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the
On 03/09/18 17:21, Jan Beulich wrote:
On 03.09.18 at 14:56, wrote:
>> On 03/09/18 14:44, Jan Beulich wrote:
>> On 01.09.18 at 23:43, wrote:
flight 127070 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127070/
Regressions :-(
Tests
On Mon, Sep 03, 2018 at 12:11:27PM +0100, Julien Grall wrote:
> I don't think so. The top makefile does not pass -DCONFIG_ARM on compiler
> command line. This is only done in sub-directory such as console and
> libacpi.
Indeed. That how console code did it.
>
> >
> > There are several CONFIG_AR
>>> On 03.09.18 at 14:56, wrote:
> On 03/09/18 14:44, Jan Beulich wrote:
> On 01.09.18 at 23:43, wrote:
>>> flight 127070 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/127070/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> in
>>> On 03.09.18 at 17:11, wrote:
> On 03/09/18 17:07, Jan Beulich wrote:
> On 03.09.18 at 16:52, wrote:
>>> On 03/09/18 16:47, Jan Beulich wrote:
>>> On 03.09.18 at 15:53, wrote:
> On 03/09/18 15:46, Jan Beulich wrote:
> On 31.08.18 at 18:22, wrote:
>>> Add the thread-id
>>> On 19.07.18 at 15:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 July 2018 11:47
>>
>> @@ -134,7 +135,15 @@ guest_walk_tables(struct vcpu *v, struct
>> /* Get the l4e from the top level table and check its flags*/
>> gw->l4mfn = top_mfn;
>> l4p = (guest_
On 03/09/18 17:07, Jan Beulich wrote:
On 03.09.18 at 16:52, wrote:
>> On 03/09/18 16:47, Jan Beulich wrote:
>> On 03.09.18 at 15:53, wrote:
On 03/09/18 15:46, Jan Beulich wrote:
On 31.08.18 at 18:22, wrote:
>> Add the thread-id to the cpu config data and an accessor ma
On 03/09/18 15:52, Juergen Gross wrote:
> On 03/09/18 16:47, Jan Beulich wrote:
> On 03.09.18 at 15:53, wrote:
>>> On 03/09/18 15:46, Jan Beulich wrote:
>>> On 31.08.18 at 18:22, wrote:
> Add the thread-id to the cpu config data and an accessor macro
> cpu_to_thread().
>
>
>>> On 03.09.18 at 16:52, wrote:
> On 03/09/18 16:47, Jan Beulich wrote:
> On 03.09.18 at 15:53, wrote:
>>> On 03/09/18 15:46, Jan Beulich wrote:
>>> On 31.08.18 at 18:22, wrote:
> Add the thread-id to the cpu config data and an accessor macro
> cpu_to_thread().
>
> Signe
On Mon, Sep 03, 2018 at 05:42:43PM +0300, Isaila Alexandru wrote:
> On Lu, 2018-09-03 at 16:36 +0200, Roger Pau Monné wrote:
> > On Fri, Aug 31, 2018 at 04:56:21PM +0300, Isaila Alexandru wrote:
> > >
> > > On Mi, 2018-08-29 at 08:13 -0600, Jan Beulich wrote:
> > > >
> > > > >
> > > > >
> > > >
flight 127212 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127212/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi,
I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
has support for GICv4.
But dom0(kernel 4.18) boot fails with the below trap,
XEN) done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
inp
On 09/03/2018 03:35 PM, Jan Beulich wrote:
On 03.09.18 at 15:24, wrote:
>> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
>> (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] enabled)
>> (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] enabled)
>> (XEN) ACPI: LAPIC (acpi_id[0x18] lapic
On 03/09/18 16:47, Jan Beulich wrote:
On 03.09.18 at 15:53, wrote:
>> On 03/09/18 15:46, Jan Beulich wrote:
>> On 31.08.18 at 18:22, wrote:
Add the thread-id to the cpu config data and an accessor macro
cpu_to_thread().
Signed-off-by: Juergen Gross
---
xen
>>> On 03.09.18 at 16:19, wrote:
> On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
>> >>> On 24.08.18 at 11:58, wrote:
>> > --- /dev/null
>> > +++ b/tools/firmware/hvmloader/hvmloader.lds
>> > @@ -0,0 +1,13 @@
>> > +SECTIONS
>> > +{
>> > + . = 0x10;
>> > + /*
>> > + * NB: the
>>> On 03.09.18 at 16:27, wrote:
> On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
>> >>> On 30.08.18 at 09:42, wrote:
>> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >> >>> On 26.08.18 at 14:19, wrote:
>> >> > --- a/xen/arch/x86/mm/paging.c
>> >> > +++ b/xen/ar
>>> On 03.09.18 at 15:53, wrote:
> On 03/09/18 15:46, Jan Beulich wrote:
> On 31.08.18 at 18:22, wrote:
>>> Add the thread-id to the cpu config data and an accessor macro
>>> cpu_to_thread().
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> xen/arch/x86/cpu/common.c | 1 +
>>> xen/ar
This is the start of a large amount of cleanup work to eventually allow for
the removal of XEN_DOMCTL_max_cpus hypercall.
The work to do is:
1) Make the domain destruction path fully idempotent, and use instead of the
ad-hoc cleanup in each of the various create functions.
2) Do the same
Given two subtle failures from getting this wrong before, and more cleanup on
the way, move the setting of d->guest_type as early as possible.
Note that despite moving the assignment of d->guest_type outside of the
is_idle_domain(d) check, it still behaves the same. Previously, system
domains had
xsm_free_security_domain() is idempotent (both the dummy handler, and the
flask handler). Move it into the shared __domain_destroy() path, and drop the
INIT_xsm flag from domain_create()
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
C
This is the first step in making the destroy path idepotent, and using it in
place of the ad-hoc cleanup paths in the create path.
To begin with, the trivial free operations are broken out. The rest of the
cleanup code will be moved as it is demonstrated (or made) to be idempotent.
Signed-off-by
... and move it into the common __domain_destroy() path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 9 +++--
xen/common/rangeset.c | 3 +++
2 files changed, 6 insertions(+), 6 delet
1 - 100 of 171 matches
Mail list logo
