flight 151459 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151459/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
flight 151452 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are
On Mon, Jun 22, 2020 at 01:38:20PM +0200, Jan Beulich wrote:
> On 22.01.2020 02:58, Bobby Eshleman wrote:
> > From: Alistair Francis
> >
> > Add the lib directory with find_next_bit support.
> >
> > This was taken from Linux
>
> As was Arm64's - the two definitely would want folding.
>
On Mon, Jun 22, 2020 at 01:43:40PM +0200, Jan Beulich wrote:
> On 22.01.2020 02:59, Bobby Eshleman wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/sysctl.c
> > @@ -0,0 +1,31 @@
> > +/**
> > + * Arch-specific sysctl.c
> >
On Tue, Jun 16, 2020 at 01:16:10PM -0700, Stefano Stabellini wrote:
> On Mon, 15 Jun 2020, Bobby Eshleman wrote:
> > On Tue, Jun 16, 2020 at 01:10:17AM +, Alistair Francis wrote:
> > > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote:
> > > > Any updates? I am looking forward to
> Subject: RE: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, 29 Jun 2020, Peng Fan wrote:
> > > > If that is the case, how is it possible that virtio breaks on ARM
> > > > using the default dma_ops? The breakage is not Xen related (except
> > > > that Xen turns dma_ops on). The original
On Mon, 29 Jun 2020, Peng Fan wrote:
> > > If that is the case, how is it possible that virtio breaks on ARM
> > > using the default dma_ops? The breakage is not Xen related (except
> > > that Xen turns dma_ops on). The original message from Peng was:
> > >
> > > vring_map_one_sg ->
On Fri, 26 Jun 2020, Michael S. Tsirkin wrote:
> On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
>
flight 151457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151457/
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
flight 151448 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151448/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151437
flight 151445 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
On Sun, 28 Jun 2020, Xiaofei Tan wrote:
> Fix the following sparse warning:
>
> arch/arm64/xen/../../arm/xen/enlighten.c:244: warning: macro
> "GRANT_TABLE_PHYSADDR" is not used [-Wunused-macros]
>
> It is an isolated macro, and should be removed when its last user
> was deleted in the following
On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
> While I've been running into an issue here only because of an additional
> local change I'm carrying, to be able to override just the compiler in
> $(XEN_ROOT)/.config (rather than the whole tool chain), in
> config/StdGNU.mk:
>
>
As was pointed out by "mm: fix public declaration of struct
xen_mem_acquire_resource", we're not currently handling structs
correctly that has uint64_aligned_t fields. #pragma pack(4) suppresses
the necessary alignment even if the type did properly survive (which
it also didn't) in the process of
On Sat, 27 Jun 2020, Julien Grall wrote:
> From: Julien Grall
>
> The specification of pvcalls suggests there is padding for 32-bit x86
> at the end of most the structure. However, they are not described in
> in the public header.
>
> Because of that all the structures would be 32-bit aligned
On Fri, Jun 26, 2020 at 7:26 AM Ian Jackson wrote:
>
> Wei Liu writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool"):
> > On Mon, Jun 22, 2020 at 08:12:56PM +0200, Michał Leszczyński wrote:
> > > Add an demonstration tool that uses xc_vmtrace_* calls in order
> > > to manage external
flight 151454 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151454/
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
On 29.06.2020 14:05, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
> variable"):
>> On 26.06.2020 19:00, Andrew Cooper wrote:
>>> diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh
>>> b/xen/xsm/flask/policy/mkaccess_vector.sh
>>> old mode 100644
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 14:51
> To: Ian Jackson
> Cc: Xen-devel ; Wei Liu ;
> Daniel De Graaf
> ; Paul Durrant
> Subject: Re: [PATCH] tools/configure: drop BASH configure variable
>
> On 29/06/2020 14:34, Ian Jackson wrote:
> > Andrew Cooper
On 29/06/2020 14:34, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure
> variable"):
>> This is a weird variable to have in the first place. The only user of it is
>> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two
>> scripts
>> run
Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure variable"):
> This is a weird variable to have in the first place. The only user of it is
> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts
> run with this are shebang sh anyway, so don't need bash
On 29/06/2020 09:25, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 29 June 2020 09:22
>> To: Andrew Cooper
>> Cc: Xen-devel ; Daniel De Graaf
>>
>> Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts
>>
>> On
Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure
variable"):
> On 26.06.2020 19:00, Andrew Cooper wrote:
> > diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh
> > b/xen/xsm/flask/policy/mkaccess_vector.sh
> > old mode 100644
> > new mode 100755
> > diff --git
> -Original Message-
> From: Andrew Cooper
> Sent: 29 June 2020 11:31
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ;
> Roger Pau Monné ; Paul Durrant
> Subject: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out
>
> There is no need to automatically
On 29.06.2020 12:31, Andrew Cooper wrote:
> There is no need to automatically disable PV32 support on SHSTK-capable
> hardware if Xen isn't actually using the feature.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 29/06/2020 12:22, Jan Beulich wrote:
On 29.06.2020 12:03, Julien Grall wrote:
On 29/06/2020 09:28, Jan Beulich wrote:
On 27.06.2020 11:55, Julien Grall wrote:
As an aside, the padding sadly cannot be mandated to be 0 as they are
already present. So it is not going to be possible to use
On 29.06.2020 12:03, Julien Grall wrote:
> On 29/06/2020 09:28, Jan Beulich wrote:
>> On 27.06.2020 11:55, Julien Grall wrote:
>>> As an aside, the padding sadly cannot be mandated to be 0 as they are
>>> already present. So it is not going to be possible to use the padding
>>> for extending a
flight 151441 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did
On 29/06/2020 06:17, Jürgen Groß wrote:
> On 26.06.20 19:24, Andy Lutomirski wrote:
>> On Xen PV, SWAPGS doesn't work. Teach __rdfsbase_inactive() and
>> __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV. The Xen
>> pvop code will understand this and issue the correct hypercalls.
>>
>>
There is no need to automatically disable PV32 support on SHSTK-capable
hardware if Xen isn't actually using the feature.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
For 4.14. Minor bugfix.
---
xen/arch/x86/setup.c | 4
1 file
On Mon, Jun 29, 2020 at 09:56:43AM +, Jan Ruh wrote:
> > Did you try backing up your changes and seeing if the same happens?
>
> If backing up my changes everything works as expected.
>
> > Did you rebuild both the Xen hypervisor and the tools?
>
> Yes, I rebuild both Xen hypervisor and the
Hi Jan,
On 29/06/2020 09:28, Jan Beulich wrote:
On 27.06.2020 11:55, Julien Grall wrote:
From: Julien Grall
The specification of pvcalls suggests there is padding for 32-bit x86
at the end of most the structure. However, they are not described in
in the public header.
Because of that all
Hi Roger,
thank you very much for your help. Further replies are inline.
> Gesendet: Montag, 29. Juni 2020 um 10:57 Uhr
> Von: "Roger Pau Monné"
> An: joshua_pe...@web.de
> Cc: xen-devel@lists.xenproject.org
> Betreff: Re: Questions about PVH memory layout
>
> > The other
> > thing is, the
> Did you try backing up your changes and seeing if the same happens?
If backing up my changes everything works as expected.
> Did you rebuild both the Xen hypervisor and the tools?
Yes, I rebuild both Xen hypervisor and the tools.
> Pasting your xl config file would be helpful in order to
- 23 cze 2020 o 13:54, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> Overall, the moving parts of this series needs to split out into rather
> more patches.
>
> First, in patch 3, the hvm_funcs.pt_supported isn't the place for that
> to live. You want a global "bool
Completely a shot in the dark, but have you tried with legacy boot
(BIOS) instead of UEFI? To try to rule out what might cause the
issues.
From the BIOS: "Legacy Boot mode is not supported on this platform."
This is my punishment for buying a brand new laptop model for Linux...
-Trevor
I don't suppose you have a serial port on this laptop? I ask because
the serial log (and the possibility to issue debug keys) are about
the only thing debugging-wise that may help here, short of someone
noticing the underlying problem by code inspection.
Afraid not, it's hyper-modern; just 3
flight 151444 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151444/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0060e0a694f3f249c3ec081b0e61287c36f64ebb
baseline version:
ovmf
On Sat, Jun 27, 2020 at 08:35:27AM +, Trevor Bentley wrote:
> I asked on #xen on Freenode and was requested to post here.
>
> Summary: Under Xen, both suspend and hibernate operations put the laptop
> into some sort of unrecoverable low-power mode, and a force power-off is
> required.
>
>
On Mon, Jun 29, 2020 at 07:43:43AM +, Jan Ruh wrote:
> Hi Xen Dev Community,
>
>
> I ran into an issue when implementing a prototype for a new
> paravirtualized clock for x86-64 hosts. I extended the
> arch_shared_info struct by 6 fields totaling at 36 bytes. I updated
> the
On Sun, Jun 28, 2020 at 08:58:14AM +0200, joshua_pe...@web.de wrote:
> Hello everyone,
>
> I hope this is the right forum for these kinds of questions (the website
> states no "technical support queries"; I'm not sure if this qualifies).
> If not, sorry for the disturbance; just simply direct me
On 26.06.2020 19:00, Andrew Cooper wrote:
> @@ -24,14 +20,14 @@ extra-y += $(ALL_H_FILES)
>
> mkflask := policy/mkflask.sh
> quiet_cmd_mkflask = MKFLASK $@
> -cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
> +cmd_mkflask = $(mkflask) $(AWK) include $(FLASK_H_DEPEND)
On 27.06.2020 10:35, Trevor Bentley wrote:
> Please let me know if you have any suggestions to try, or if you need
> any extra information for debugging.
I don't suppose you have a serial port on this laptop? I ask because
the serial log (and the possibility to issue debug keys) are about
the
On 27.06.2020 11:55, Julien Grall wrote:
> From: Julien Grall
>
> The specification of pvcalls suggests there is padding for 32-bit x86
> at the end of most the structure. However, they are not described in
> in the public header.
>
> Because of that all the structures would be 32-bit aligned
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 29 June 2020 09:22
> To: Andrew Cooper
> Cc: Xen-devel ; Daniel De Graaf
>
> Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts
>
> On 26.06.2020 19:02, Andrew Cooper wrote:
> >
On 26.06.2020 19:02, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Daniel De Graaf
Since we've not heard anything from Daniel in quite a while, just
in case:
Acked-by: Jan Beulich
Jan
Hi Xen Dev Community,
I ran into an issue when implementing a prototype for a new paravirtualized
clock for x86-64 hosts. I extended the arch_shared_info struct by 6 fields
totaling at 36 bytes. I updated the xen-foreign/references.size to represent
the new size of the arch_shared_info
> -Original Message-
> From: Julien Grall
> Sent: 26 June 2020 18:54
> To: Stefano Stabellini ; p...@xen.org
> Cc: Volodymyr Babchuk ;
> xen-devel@lists.xenproject.org; op-
> t...@lists.trustedfirmware.org
> Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address
>
> -Original Message-
> From: Andrew Cooper
> Sent: 26 June 2020 18:01
> To: Xen-devel
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu
> ; Daniel De Graaf ; Paul Durrant
>
> Subject: [PATCH] tools/configure: drop BASH configure variable
>
> This is a weird variable to have in the first
> -Original Message-
> From: Jürgen Groß
> Sent: 27 June 2020 12:54
> To: Julien Grall ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Stefano Stabellini ; Wei Liu
>
> Subject: Re: [PATCH v4
> -Original Message-
> From: Jürgen Groß
> Sent: 27 June 2020 12:55
> To: Julien Grall ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall
> Subject: Re: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that the
> header is just a reference
>
> On 27.06.20 11:55, Julien
On 26.06.2020 17:39, Roger Pau Monne wrote:
> XENMEM_acquire_resource and it's related structure is currently inside
> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
> hypervisor or the toolstack only. This is wrong as the hypercall is
> already being used by the Linux
On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
make the version an integer.
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, Jun 29, 2020 at 06:25:41AM +, Peng Fan wrote:
> > > > > > Anyway, re-reading the last messages of the original thread
> > > > > > [1], it looks like Peng had a clear idea on how to fix the general
> > > > > > issue.
> > > >
On Mon, Jun 29, 2020 at 06:25:41AM +, Peng Fan wrote:
> > > > > Anyway, re-reading the last messages of the original thread [1],
> > > > > it looks like Peng had a clear idea on how to fix the general issue.
> > > > > Peng, what happened with that?
> > >
> > > We shrinked the rpmsg reserved
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
>
> On Mon, Jun 29, 2020 at 03:05:19AM +, Peng Fan wrote:
> > > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
> > >
> > > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S.
On Mon, Jun 29, 2020 at 03:05:19AM +, Peng Fan wrote:
> > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
> >
> > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote:
> > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700,
57 matches
Mail list logo
