Re: [Xen-devel] 答复: 答复: 答复: 答复: Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?

On 06/07/18 08:58, Juergen Gross wrote: > On 06/07/18 08:27, Chenjia (C) wrote: >> Dear Juergen: >>We will follow your suggestion: unload DPDK, then test a again. >> >> Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's >> dump message, is there a way to show mor

[Xen-devel] [PATCH] x86: drop dead asm-offsets definitions

UREGS_user_sizeof had a use long, long ago on x86, and apparently was blindly cloned into ARM code. The uses of UREGS_saved_upcall_mask and UREGS_{ds,es,fs,gs} disappeared in 71eb3a65e3 ("VMX: streamline entry.S code") and 110b2d6e8a ("SVM: streamline entry.S code"). There are other ARM side UREG

Re: [Xen-devel] 答复: 答复: 答复: 答复: Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?

On 06/07/18 08:27, Chenjia (C) wrote: > Dear Juergen: >We will follow your suggestion: unload DPDK, then test a again. > > Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's > dump message, is there a way to show more dump message? Looking more at this I guess

Re: [Xen-devel] [PATCH 13/13] x86/domctl: Implement XEN_DOMCTL_set_cpumsr_policy

>>> On 05.07.18 at 19:55, wrote: > On 05/07/18 10:28, Jan Beulich wrote: >> > +/* > + * Audit was successful. Replace existing policies, leaving the old > + * policies to be freed. > + */ > +SWAP(new.cp, d->arch.cpuid); > +SWAP(new.dp, d->arch.msr);

Re: [Xen-devel] 答复: 答复: 答复: 答复: Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?

>>> On 06.07.18 at 08:27, wrote: > Dear Juergen: >We will follow your suggestion: unload DPDK, then test a again. > > Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's > dump > message, is there a way to show more dump message? And you don't happen to run D

[Xen-devel] 答复: 答复: 答复: 答复: 答复: Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?

Dear Juergen: Ok, we will add the conring_size parameters and disable DPDK then test again, if we have the new result, we will send to you, thank you for your help! Best Regards -邮件原件- 发件人: Juergen Gross [mailto:jgr...@suse.com] 发送时间: 2018年7月6日 15:50 收件人: Chenjia (C) ; Jan Beul

Re: [Xen-devel] [PATCH 01/13] libx86: Introduce libx86/cpuid.h

>>> On 06.07.18 at 03:35, wrote: > On Wed, Jul 04, 2018 at 07:57:30AM -0600, Jan Beulich wrote: >> >>> On 04.07.18 at 14:03, wrote: >> > On 04/07/18 09:21, Jan Beulich wrote: >> > On 03.07.18 at 22:55, wrote: >> >>> --- a/tools/include/Makefile >> >>> +++ b/tools/include/Makefile >> >>> @@ -

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 06/07/18 00:47, Sander Eikelenboom wrote: > On 05/07/18 19:11, Ian Jackson wrote: >> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 >> design session] Process changes: is the 6 monthly release Cadence too short, >> Security Process, ..."): >>> Just wondering, are there

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On Thu, Jul 05, 2018 at 08:58:18PM -0500, Doug Goldstein wrote: > On Thu, Jul 05, 2018 at 02:02:33PM -0500, Doug Goldstein wrote: > > I guess my point is "No one think that I'm suggesting the web PR model > > so please don't fire off the email cannons!". But I was say there are > > some nice things

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

>>> On 05.07.18 at 20:13, wrote: > On Thu, Jul 05, 2018 at 12:16:09PM +0100, Ian Jackson wrote: >> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design > session] Process changes: is the 6 monthly release Cadence too short, > Security Process, ..."): >> > We didn't look at th

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 06/07/2018 09:32, Jan Beulich wrote: >> Jenkins uses weather icons to attempt to convey if this test is >> trending worse or better or successful or broken. If it fails but not >> every time and the amount of failures is increasing over time then its >> got storm clouds. If the amount of failure

Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page

On 07/05/2018 07:45 PM, Tamas K Lengyel wrote: > On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru > wrote: >> However, our particular application is only interested in setting (and >> querying) page restrictions from userspace (from the dom0 agent). It >> will also need to be able to set the convert

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 05/07/18 17:14, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design > session] Process changes: is the 6 monthly release Cadence too short, > Security Process, ..."): >> Same applies to the host: the base system (without the to be tested >> component l

[Xen-devel] [xen-unstable test] 124956: tolerable FAIL - PUSHED

flight 124956 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/124956/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 124566 test-armhf-armhf-libvirt 14 save

[Xen-devel] [ovmf test] 124998: regressions - FAIL

flight 124998 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/124998/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 124920 version targeted for testi

[Xen-devel] [distros-debian-jessie test] 74939: tolerable FAIL

flight 74939 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74939/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74924 baseline version: fl

Re: [Xen-devel] [PATCH] x86: drop dead asm-offsets definitions

On 06/07/18 08:39, Jan Beulich wrote: > UREGS_user_sizeof had a use long, long ago on x86, and apparently was > blindly cloned into ARM code. > > The uses of UREGS_saved_upcall_mask and UREGS_{ds,es,fs,gs} disappeared > in 71eb3a65e3 ("VMX: streamline entry.S code") and 110b2d6e8a ("SVM: > streamli

Re: [Xen-devel] [PATCH 13/13] x86/domctl: Implement XEN_DOMCTL_set_cpumsr_policy

On 06/07/18 08:51, Jan Beulich wrote: > >> +{ >> +/* XXX - Figure out how to avoid a TOCTOU race here. XLAT >> area? */ >> +if ( (ret = x86_msr_copy_from_buffer( >> + NULL, v->arch.msr, xdpc->msr_policy, xdpc->nr_msrs, >> NULL)) )

Re: [Xen-devel] [PATCH] x86: drop dead asm-offsets definitions

Hi Jan, On 06/07/18 08:39, Jan Beulich wrote: UREGS_user_sizeof had a use long, long ago on x86, and apparently was blindly cloned into ARM code. I was looking at using it recently for SSBD. But managed to do it differently. The uses of UREGS_saved_upcall_mask and UREGS_{ds,es,fs,gs} disa

Re: [Xen-devel] [PATCH RFC 07/15] xen/arm: increase MAX_MODULES

Hi Doug, On 06/07/18 03:10, Doug Goldstein wrote: On Wed, Jun 13, 2018 at 03:15:10PM -0700, Stefano Stabellini wrote: Xen boot modules need to account not just for Dom0 but also for a few potential DomUs, each of them coming with their own kernel and initrd. Increase MAX_MODULES to 32 to allow

Re: [Xen-devel] [PATCH RFC 11/15] xen/arm: generate a simple device tree for domUs

On 06/07/18 00:59, Stefano Stabellini wrote: On Thu, 14 Jun 2018, Julien Grall wrote: +#define DOMU_DTB_SIZE 4096 Is this going to be enough? Per the documentation, the maximum size of a DT is 2MB. That is what we use today for the small generated DTB for ACPI dom0. The generated DTB for

[Xen-devel] Ping: [PATCH] x86: fix dependency tracking for asm/indirect_thunk_asm.h

Ping? >>> On 26.06.18 at 09:37, wrote: > Including the header solely at the assembler level means the compiler > can't record the header as a dependency in .*.o.d files. Arrange for the > header to be include-able at the C level instead. > > Signed-off-by: Jan Beulich > > --- a/xen/include/asm

[Xen-devel] Ping: [PATCH] x86: correctly set nonlazy_xstate_used when loading full state

Ping? >>> On 26.06.18 at 09:47, wrote: > In this case, just like xcr0_accum, nonlazy_xstate_used should always be > set to the intended new value, rather than possibly leaving the flag set > from a prior state load. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/domctl.c > +++ b/xen/arc

[Xen-devel] Ping: [PATCH] x86: reduce IRQs disabled section in flush_area_local()

Ping? >>> On 29.06.18 at 15:13, wrote: > Only the pre_flush() / post_flush() section actually needs to run with > interrupts disabled. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/flushtlb.c > +++ b/xen/arch/x86/flushtlb.c > @@ -76,7 +76,13 @@ static void post_flush(u32 t) > > stat

[Xen-devel] Ping: [PATCH] x86/spec-ctrl: "no-xen" should not imply "no-eager-fpu"

Ping? >>> On 29.06.18 at 14:52, wrote: > "Eager FPU" mode is to guard guests, not Xen itself, as is also > expressed by print_details(). > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/spec_ctrl.c > +++ b/xen/arch/x86/spec_ctrl.c > @@ -124,6 +124,8 @@ static int __init parse_spec_ctrl(co

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

Hello, On 04/07/18 21:55, ihor.matushc...@foobox.net wrote: From: Ihor Matushchak This patch enables earlyprintk for Rockchip rk3399 based SoC. Is there any missing pieces in Xen to boot on Rockchip? I would also quite like to see some documentation how to boot Xen on that platform. Cheers,

[Xen-devel] [OSSTEST PATCH 1/2] BuildSupport: Honour new runvar make_njobs

Having a hardcoded -j4, and having this come via DefMakeFlags, is not brilliant. But at least this make_njobs variable has better semantics so won't make it harder to make this more sophisticated later. Signed-off-by: Ian Jackson --- Osstest/BuildSupport.pm | 5 - 1 file changed, 4 insertio

[Xen-devel] [OSSTEST PATCH 2/2] libvirt build: Set make_njobs=1 except when testing libvirt

libvirt has a -j bug. This is allegedly going to be fixed in upstream RSN ? Anyway, for now, serialise all the builds on other branches so they are not affected. Signed-off-by: Ian Jackson --- mfi-common | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mfi-common b/mf

[Xen-devel] xen + i40e: transmit queue timeout

I am currently researching a transmit queue timeout with Xen 4.8.2 and Intel X722 (i40e driver). The problem occurs with various linux versions (4.8.17, 4.13.16, SLES 15 port of i40e). The problem seems to be related to heavy forwarding/bridging as I am running a heavy network stress test i

Re: [Xen-devel] [PATCH v1] earlyprintk configuration for rk3399 boards

Hello Julien, I suppose there is no such documentation, at least I didn't find any. Bringing up XEN 4.10.0 on RK3399 is my pet-project. My current target board is Ibox3399

[Xen-devel] [OSSTEST PATCH] armhf, xsm: Drop XSM tests on 32-bit ARM

We are at the limit of ARM capacity, which has not kept pace with X86 expansion. New hardware is on the way but it is not here yet. Dropping the XSM tests drops one test, but also one build, which saves considerable effort. Builds are currently the bottleneck, because we avoid building on the un

[Xen-devel] [OSSTEST PATCH] ts-depriv-audit-qemu: Leaked substeps are `blocked', and then script is fail

If thus script crash in some non-substep-specific operation, the substeps may have been created (and thus be in the db as `running'). Leaving them like this is not allowed: it is treated by sg-run-job, and by the archaeologists as an internal error. If this happens, what we want is for the script

Re: [Xen-devel] xen + i40e: transmit queue timeout

>>> On 06.07.18 at 12:39, wrote: > I am currently researching a transmit queue timeout with Xen 4.8.2 and > Intel X722 (i40e driver). The problem occurs with various linux versions > (4.8.17, 4.13.16, SLES 15 port of i40e). The problem seems to be related > to heavy forwarding/bridging as I

[Xen-devel] [PATCH] xen: Port the array_index_nospec() infrastructure from Linux

This is as the infrastructure appeared in Linux 4.17, adapted slightly for Xen. The architecture independent array_index_mask_nospec() is ported for ARMs benefit, as it currently lacks the optimised version. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Gra

Re: [Xen-devel] [PATCH] x86: fix dependency tracking for asm/indirect_thunk_asm.h

On 26/06/18 08:37, Jan Beulich wrote: > Including the header solely at the assembler level means the compiler > can't record the header as a dependency in .*.o.d files. Arrange for the > header to be include-able at the C level instead. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___

Re: [Xen-devel] [PATCH] x86: correctly set nonlazy_xstate_used when loading full state

On 26/06/18 08:47, Jan Beulich wrote: > In this case, just like xcr0_accum, nonlazy_xstate_used should always be > set to the intended new value, rather than possibly leaving the flag set > from a prior state load. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper _

Re: [Xen-devel] [OSSTEST PATCH] ts-depriv-audit-qemu: Leaked substeps are `blocked', and then script is fail

On Fri, Jul 06, 2018 at 12:13:54PM +0100, Ian Jackson wrote: > If thus script crash in some non-substep-specific operation, the > substeps may have been created (and thus be in the db as `running'). > Leaving them like this is not allowed: it is treated by sg-run-job, > and by the archaeologists as

Re: [Xen-devel] [PATCH] x86/spec-ctrl: "no-xen" should not imply "no-eager-fpu"

On 29/06/18 13:52, Jan Beulich wrote: > "Eager FPU" mode is to guard guests, not Xen itself, as is also > expressed by print_details(). > > Signed-off-by: Jan Beulich Hmm true.  Also, opt_ssbd needs clearing in the common case. With those fixed, Reviewed-by: Andrew Cooper _

Re: [Xen-devel] Routing physical interrupts to EL1

On 06/07/18 04:51, Saeed Mirzamohammadi wrote: Hi, Hello, I'm trying to route all the physical interrupts to the guest domain rather than being trapped in the Xen. I would like to know what is the right way to do that? May I ask what is your use case for that? If you route interrupts to

Re: [Xen-devel] [OSSTEST PATCH] ts-depriv-audit-qemu: Leaked substeps are `blocked', and then script is fail

Anthony PERARD writes ("Re: [OSSTEST PATCH] ts-depriv-audit-qemu: Leaked substeps are `blocked', and then script is fail"): > On Fri, Jul 06, 2018 at 12:13:54PM +0100, Ian Jackson wrote: > > # (if there are no fds of this class, maybe they were all closed) > > + $classes{$cl} = 'reported'; >

Re: [Xen-devel] [PATCH] x86: reduce IRQs disabled section in flush_area_local()

On 29/06/18 14:13, Jan Beulich wrote: > Only the pre_flush() / post_flush() section actually needs to run with > interrupts disabled. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org http

Re: [Xen-devel] [PATCH] xen/x86: fix linker script to work with lld

On Thu, Jul 05, 2018 at 09:47:57AM +0200, Roger Pau Monné wrote: > On Wed, Jul 04, 2018 at 12:49:00PM +0200, Daniel Kiper wrote: > > On Wed, Jul 04, 2018 at 01:57:58AM -0600, Jan Beulich wrote: > > > >>> On 03.07.18 at 18:02, wrote: > > > > On Thu, Jun 28, 2018 at 11:35:24PM -0600, Jan Beulich wro

[Xen-devel] [OSSTEST PATCH] cs-adjust-flight: Allow runvar-build-set new value to be just "."

This is useful because if you say new: for the flight to be adjusted, you don't have the flight number. Signed-off-by: Ian Jackson --- cs-adjust-flight | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cs-adjust-flight b/cs-adjust-flight index 4f036f4..ee1d917 100755 ---

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Andrew Cooper writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ..."): > On 06/07/2018 09:32, Jan Beulich wrote: > > I think every test failure warrants looking into. It is just the case that > > afte

Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary

On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote: > >>> On 04.07.18 at 18:35, wrote: > > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote: > >> >>> On 04.07.18 at 16:01, wrote: > >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote: > >> >> >>> On 19.06.18 at 16:

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ..."): > On 05/07/18 17:14, Ian Jackson wrote: > > Certainly it would be a bad idea to use anything *on the test host > > itself* as a b

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 06/07/18 16:03, Ian Jackson wrote: > "fail not blocking" is obviously an essential category. If a > particular thing is unreliable, it needs to be stopped from blocking > tests. What is the value of such a test? Either we say the tested functionality isn't mandatory, so a failure should not b

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 06/07/18 16:08, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design > session] Process changes: is the 6 monthly release Cadence too short, > Security Process, ..."): >> On 05/07/18 17:14, Ian Jackson wrote: >>> Certainly it would be a bad idea to use

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ..."): > On 06/07/18 16:03, Ian Jackson wrote: > > "fail not blocking" is obviously an essential category. If a > > particular thing is

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ..."): > On 06/07/18 16:08, Ian Jackson wrote: > > I think you are conflating "released" with "tested". In the current > > osstest setu

Re: [Xen-devel] 4.11.0 RC1 panic

On Tue, Jul 03, 2018 at 06:17:28PM +0200, Manuel Bouyer wrote: > > So instead of the debugging patch, could you give the one below > > a try? > > Sure, the test server is now running with it. > As I'm still using 4.11rc4 sources I had to adjust it a bit (the second chunk > didn't apply cleanly) bu

Re: [Xen-devel] [PATCH] xen: Port the array_index_nospec() infrastructure from Linux

Hi Andrew, On 06/07/18 13:37, Andrew Cooper wrote: > This is as the infrastructure appeared in Linux 4.17, adapted slightly for > Xen. The architecture independent array_index_mask_nospec() is ported for > ARMs benefit, as it currently lacks the optimised version. > > Signed-off-by: Andrew Coope

Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism

On Thu, Jul 05, 2018 at 02:35:32AM -0600, Jan Beulich wrote: > >>> On 04.07.18 at 18:48, wrote: > > On Wed, Jul 04, 2018 at 09:34:09AM -0600, Jan Beulich wrote: > >> >>> On 04.07.18 at 16:25, wrote: > >> > On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beulich wrote: > >> >> >>> On 19.06.18 at 16:

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On Fri, Jul 06, 2018 at 02:32:16AM -0600, Jan Beulich wrote: > >>> On 05.07.18 at 20:13, wrote: > > On Thu, Jul 05, 2018 at 12:16:09PM +0100, Ian Jackson wrote: > >> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design > > session] Process changes: is the 6 monthly release Cad

Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary

>>> On 06.07.18 at 16:02, wrote: > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote: >> >>> On 04.07.18 at 18:35, wrote: >> > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote: >> >> >>> On 04.07.18 at 16:01, wrote: >> >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beuli

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Doug Goldstein writes ("Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ..."): > You effectively supported my point in the end. People value their time. > Giving them details about trends could help folks to

Re: [Xen-devel] [OSSTEST PATCH] armhf, xsm: Drop XSM tests on 32-bit ARM

On 06/07/18 12:07, Ian Jackson wrote: We are at the limit of ARM capacity, which has not kept pace with X86 expansion. New hardware is on the way but it is not here yet. Dropping the XSM tests drops one test, but also one build, which saves considerable effort. Builds are currently the bottlen

Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism

>>> On 06.07.18 at 16:46, wrote: > On Thu, Jul 05, 2018 at 02:35:32AM -0600, Jan Beulich wrote: >> >>> On 04.07.18 at 18:48, wrote: >> > On Wed, Jul 04, 2018 at 09:34:09AM -0600, Jan Beulich wrote: >> >> >>> On 04.07.18 at 16:25, wrote: >> >> > On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beuli

Re: [Xen-devel] [OSSTEST PATCH] armhf, xsm: Drop XSM tests on 32-bit ARM

Julien Grall writes ("Re: [Xen-devel] [OSSTEST PATCH] armhf, xsm: Drop XSM tests on 32-bit ARM"): > On 06/07/18 12:07, Ian Jackson wrote: > > CC: Julien Grall > > I don't watch this e-mail a lot anymore. Oops. I was lazy and grepped for your name in the osstest git logs. > > Signed-off-by: Ia

Re: [Xen-devel] [PATCH] xen: Port the array_index_nospec() infrastructure from Linux

>>> On 06.07.18 at 14:37, wrote: > This is as the infrastructure appeared in Linux 4.17, adapted slightly for > Xen. The architecture independent array_index_mask_nospec() is ported for > ARMs benefit, as it currently lacks the optimised version. > > Signed-off-by: Andrew Cooper Acked-by: Jan

Re: [Xen-devel] [PATCH] xen: Port the array_index_nospec() infrastructure from Linux

On 06/07/18 16:29, Jan Beulich wrote: On 06.07.18 at 14:37, wrote: >> This is as the infrastructure appeared in Linux 4.17, adapted slightly for >> Xen. The architecture independent array_index_mask_nospec() is ported for >> ARMs benefit, as it currently lacks the optimised version. >> >> Si

Re: [Xen-devel] [PATCH RFC 11/15] xen/arm: generate a simple device tree for domUs

On Fri, 6 Jul 2018, Julien Grall wrote: > On 06/07/18 00:59, Stefano Stabellini wrote: > > On Thu, 14 Jun 2018, Julien Grall wrote: > > > > +#define DOMU_DTB_SIZE 4096 > > > > > > Is this going to be enough? Per the documentation, the maximum size of a > > > DT is > > > 2MB. > > > > That is what

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

Hi all, (I also moved the AB to BCC) I summarized the discussion in https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/edit?usp=sharing I may have missed some things or misinterpreted them, but it looks as if consensus is emerging in some areas. I would like to di

Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page

On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru wrote: > > On 07/05/2018 07:45 PM, Tamas K Lengyel wrote: > > On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru > > wrote: > >> However, our particular application is only interested in setting (and > >> querying) page restrictions from userspace (from

Re: [Xen-devel] [PATCH RFC 12/15] xen/arm: generate vpl011 node on device tree for domU

On Fri, 15 Jun 2018, Julien Grall wrote: > Hi Stefano, > > On 06/13/2018 11:15 PM, Stefano Stabellini wrote: > > Introduce vpl011 support to guests started from Xen: it provides a > > simple way to print output from a guest, as most guests come with a > > pl011 driver. It is also able to provide a

[Xen-devel] [xen-unstable-smoke test] 125029: tolerable all pass - PUSHED

flight 125029 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125029/ 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

Re: [Xen-devel] [PATCH RFC 2/3] automation: build stubdom and rombios, and tools on 32 bit

On Wed, May 30, 2018 at 12:28:24AM +0100, Wei Liu wrote: > On Tue, May 29, 2018 at 12:18:40AM -0500, Doug Goldstein wrote: > > On 5/23/18 5:20 AM, Wei Liu wrote: > > > > > > > > # SeaBIOS cannot be built with clang > > > @@ -20,12 +18,6 @@ if [[ "${CC}" == "clang" ]]; then > > > cfgargs+=(

[Xen-devel] [xen-unstable baseline-only test] 74940: tolerable FAIL

This run is configured for baseline tests only. flight 74940 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74940/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail blo

[Xen-devel] [linux-next test] 124959: regressions - trouble: blocked/broken/fail/pass

flight 124959 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/124959/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken test-armhf-armhf-xl 4 host-instal

[Xen-devel] [xen-unstable-smoke test] 125030: tolerable all pass - PUSHED

flight 125030 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125030/ 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

Re: [Xen-devel] [PATCH RFC 2/3] automation: build stubdom and rombios, and tools on 32 bit

On Fri, 6 Jul 2018, Doug Goldstein wrote: > On Wed, May 30, 2018 at 12:28:24AM +0100, Wei Liu wrote: > > On Tue, May 29, 2018 at 12:18:40AM -0500, Doug Goldstein wrote: > > > On 5/23/18 5:20 AM, Wei Liu wrote: > > > > > > > > > > > # SeaBIOS cannot be built with clang > > > > @@ -20,12 +18,6 @@

[Xen-devel] [freebsd-master test] 125014: all pass - PUSHED

flight 125014 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125014/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd ff20311f27958b751ed21c94a01ed31c8d787f0b baseline version: freebsd 36a93b0c2f8

Re: [Xen-devel] [PATCH RFC 13/15] xen/arm: Allow vpl011 to be used by DomU

On Fri, 15 Jun 2018, Julien Grall wrote: > Hi Stefano, > > On 06/13/2018 11:15 PM, Stefano Stabellini wrote: > > Make vpl011 being able to be used without a userspace component in Dom0. > > In that case, output is printed to the Xen serial and input is received > > from the Xen serial one characte

Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs

On Fri, 15 Jun 2018, Julien Grall wrote: > On 06/13/2018 11:15 PM, Stefano Stabellini wrote: > > Introduce support for the "xen,domU" compatible node on device tree. > > Create new DomU VMs based on the information found on device tree under > > "xen,domU". > > While I like the idea of having mult

[Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

Hi all, This is first step toward "dom0less" as discussed in the various certifications related threads and discussions. The goal of this series is to enable Xen to boot multiple domains in parallel, in addition to dom0, out of information found on device tree. The device tree based boot protoco

[Xen-devel] [PATCH v2 07/21] xen/arm: rename acpi_make_chosen_node to make_chosen_node

acpi_make_chosen_node is actually generic and can be reused. Rename it to make_chosen_node and make it available to non-ACPI builds. Signed-off-by: Stefano Stabellini --- xen/arch/arm/domain_build.c | 89 - 1 file changed, 47 insertions(+), 42 deletion

[Xen-devel] [PATCH v2 05/21] xen/arm: extend device tree based multiboot protocol

Extend the existing device tree based multiboot protocol to include information regarding multiple domains to boot. Signed-off-by: Stefano Stabellini --- Changes in v2: - lower case kernel - rename mem to memory - mandate cpus and memory - replace domU-kernel with kernel and domU-ramdisk with ra

[Xen-devel] [PATCH v2 11/21] xen/arm: probe domU kernels and initrds

Find addresses, sizes and cmdlines on device tree from kernel_probe. Introduce a new boot_module_find_by_addr_and_kind function to match not just on boot module kind, but also by address so that we can support multiple domains. Signed-off-by: Stefano Stabellini --- Changes in v2: - fix indentati

[Xen-devel] [PATCH v2 14/21] xen/arm: generate a simple device tree for domUs

Introduce functions to generate a basic domU device tree, similar to the existing functions in tools/libxl/libxl_arm.c. Signed-off-by: Stefano Stabellini --- Changes in v2: - move prepare_dtb rename to previous patch - use switch for the gic version - use arm,gic-400 instead of arm,cortex-a15-gic

[Xen-devel] [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests

Extend allocate_memory to work for non 1:1 mapped domUs. Specifically, memory allocated for domU will be mapped into the domU pseudo-physical address space at the appropriate addresses according to the guest memory map: GUEST_RAM0_BASE and GUEST_RAM1_BASE. To do that, insert_11_bank has been exten

Re: [Xen-devel] [PATCH RFC 09/15] xen/arm: refactor construct_dom0

On Thu, 5 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 05/07/2018 21:55, Stefano Stabellini wrote: > > On Fri, 15 Jun 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 06/15/2018 12:35 AM, Stefano Stabellini wrote: > > > > On Thu, 14 Jun 2018, Julien Grall wrote: > > > > > On 13/06

[Xen-devel] [PATCH v2 15/21] xen/arm: generate vpl011 node on device tree for domU

Introduce vpl011 support to guests started from Xen: it provides a simple way to print output from a guest, as most guests come with a pl011 driver. It is also able to provide a working console with interrupt support. The UART exposed to the guest is a SBSA compatible UART and not a PL011. SBSA UA

[Xen-devel] [PATCH v2 04/21] xen/arm: move a few DT related defines to public/device_tree_defs.h

Move a few constants defined by libxl_arm.c to xen/include/public/device_tree_defs.h, so that they can be used from Xen and libxl. Prepend GUEST_ to avoid conflicts. Move the DT_IRQ_TYPE* definitions from libxl_arm.c to public/device_tree_defs.h. Use them in Xen where appropriate. Re-define the e

[Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs

Call a new function, "create_domUs", from setup_xen to start DomU VMs. Introduce support for the "xen,domU" compatible node on device tree. Create new DomU VMs based on the information found on device tree under "xen,domU". Calls construct_domU for each domain. Introduce a simple global variable

[Xen-devel] [PATCH v2 20/21] xen: support console_switching between Dom0 and DomUs on ARM

Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the mechanism to allow for switching between Xen, Dom0, and any of the initial DomU created from Xen alongside Dom0 out of information provided via device tree. Signed-off-by: Stefano Stabellini CC: andrew.coop...@citrix.com CC: george

[Xen-devel] [PATCH v2 12/21] xen/arm: refactor construct_dom0

Move generic initializations out of construct_dom0 so that they can be reused. Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion. No functional changes in this patch. Signed-off-by: Stefano Stabellini --- Changes in v2: - move discard_initial_modules() after __construct_domain() - rem

[Xen-devel] [PATCH v2 10/21] xen/arm: don't add duplicate boot modules

Don't add duplicate boot modules (same kind and same start address). Don't try to add cmdline for "xen,domain" compatible nodes. It will be added later directly by kernel_probe. Mark kernels and ramdisks of "xen,domain" nodes as BOOTMOD_KERNEL_DOMAIN and BOOTMOD_RAMDISK_DOMAIN respectively, to av

[Xen-devel] [PATCH v2 08/21] xen/arm: increase MAX_MODULES

Xen boot modules need to account not just for Dom0 but also for a few potential DomUs, each of them coming with their own kernel and initrd. Increase MAX_MODULES to 32 to allow for more DomUs. Signed-off-by: Stefano Stabellini Reviewed-by: Doug Goldstein --- xen/include/asm-arm/setup.h | 2 +-

[Xen-devel] [PATCH v2 09/21] xen/arm: move cmdline out of boot_modules

Remove the cmdline field from struct boot_module, cmdline is stored independently out of the boot_modules array as dom0_cmdline. Add a pointer to struct kernel_info to point to the cmdline for a given kernel. boot_fdt_cmdline is only used to retrieve the Xen cmdline. Remove the code to return the

[Xen-devel] [PATCH v2 16/21] xen/arm: introduce a union in vpl011

Introduce a union in struct vpl011 to contain the console ring members. A later patch will add another member of the union with a small ring structure. Signed-off-by: Stefano Stabellini --- Changes in v2: - new patch --- xen/arch/arm/vpl011.c| 20 ++-- xen/include/asm-arm

[Xen-devel] [PATCH v2 06/21] xen/arm: do not pass dt_host to make_memory_node and make_hypervisor_node

In order to make make_memory_node and make_hypervisor_node more reusable, do not pass them dt_host. As they only use it to calculate addrcells and sizecells, pass addrcells and sizecells directly. In make_hypervisor_node, assume that evtchn_irq has already been allocated. Move the evtchn_allocate

[Xen-devel] [PATCH v7 00/12] arm: more kconfig configurability and small default configs

Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. The series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. It also introduces a reference kconfig for Renesas RCar (due to

[Xen-devel] [PATCH v2 17/21] xen/arm: refactor vpl011_data_avail

Move the code to calculate in_fifo_level and out_fifo_level out of vpl011_data_avail, to the caller. This change will make it possible to reuse vpl011_data_avail with different ring structures in a later patch. Signed-off-by: Stefano Stabellini --- Changes in v2: - new patch --- xen/arch/arm/vp

[Xen-devel] [PATCH v2 03/21] xen: allow console_io hypercalls from certain DomUs

Introduce an is_console option to allow certain classes of domUs to use the Xen console. Specifically, it will be used to give console access to all domUs started from Xen from information on device tree. Signed-off-by: Stefano Stabellini CC: andrew.coop...@citrix.com CC: george.dun...@eu.citrix.

[Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU

Make vpl011 being able to be used without a userspace component in Dom0. In that case, output is printed to the Xen serial and input is received from the Xen serial one character at a time. Call domain_vpl011_init during construct_domU if vpl011 is enabled. Introduce a new ring struct with only t

[Xen-devel] [PATCH v2 21/21] xen/arm: split domain_build.c

domain_build.c is too large. Move all the ACPI specific device tree generating functions from domain_build.c to acpi/acpi_dt_build.c. Signed-off-by: Stefano Stabellini --- xen/arch/arm/acpi/Makefile| 1 + xen/arch/arm/acpi/acpi_dt_build.c | 588 ++

[Xen-devel] [PATCH v2 01/21] xen/arm: rename get_11_allocation_size to get_allocation_size

... and remove the BUG_ON(!dom0_11_mapping) in allocate_memory. A follow-up patch will make the function work with non 1:1 mapped guests. No functional changes. Signed-off-by: Stefano Stabellini --- Changes in v2: - new patch --- xen/arch/arm/domain_build.c | 22 -- 1 file

[Xen-devel] [PATCH v2 13/21] xen/arm: introduce construct_domU

Similar to construct_dom0, construct_domU creates a barebone DomU guest. The device tree node passed as argument is compatible "xen,domain", see docs/misc/arm/device-tree/booting.txt. Signed-off-by: Stefano Stabellini --- Changes in v2: - rename mem to memory - make cpus and memory mandatory -

[Xen-devel] [PATCH v7 11/12] xen: specify support for EXPERT and DEBUG Kconfig options

Add a clear statement about them, reflecting the current security support status of Kconfig options (no changes to current policies). Signed-off-by: Stefano Stabellini CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: andrew.coop...@citrix.com CC: Konrad Rzes

[Xen-devel] [PATCH v7 02/12] arm: make it possible to disable HAS_GICV3

Today it is a silent option. This patch adds a one line description and makes it optional. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- Changes in v3: - remove any c

  1   2   >