flight 150050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f159102a130fac9b416418eb9b6fa35b63426ca5
baseline version:
ovmf
flight 150053 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150053/
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
flight 150043 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 149911
On Wed, May 6, 2020 at 10:34 AM Stefano Stabellini
wrote:
>
> On Wed, 6 May 2020, Nataliya Korovkina wrote:
> > On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> > wrote:
> > >
> > >
> > > On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> > > > Hello,
> > > >
> > > > What I found out:
On Wed, May 6, 2020 at 10:36 AM Boris Ostrovsky
wrote:
>
>
> On 5/6/20 12:14 PM, Nataliya Korovkina wrote:
> > On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> > wrote:
> >>
> >> On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> >>> Hello,
> >>>
> >>> What I found out: rpi_firmware_property_list()
flight 150059 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150059/
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
Hi all,
on a recent checkout of the Xen staging source I ran into the
following build error with QEMU upstream:
tools/qemu-xen-dir-remote/slirp/src/ip_input.c:330:5: error: ISO C90
forbids mixed declarations and code
[-Werror=declaration-after-statement]
int delta = (char *)q - (m->m_flags &
Hi all,
I would like to let you know that I plan to create a FuSa.git repository
under:
https://gitlab.com/xen-project
to host the work-in-progress Xen safety certification documents.
The goal is to have those documents under xen.git, as they need to be
linked to corresponding source code, but
On 06/05/2020 08:08, Roger Pau Monné wrote:
> On Tue, May 05, 2020 at 07:25:39PM +0100, Andrew Cooper wrote:
>> AMD Fam15h processors introduced the flush-by-asid feature, for more fine
>> grain flushing purposes.
>>
>> Flushing everything including ASID 0 (i.e. Xen context) is an an
>>
On 5/6/20 12:14 PM, Nataliya Korovkina wrote:
> On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> wrote:
>>
>> On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
>>> Hello,
>>>
>>> What I found out: rpi_firmware_property_list() allocates memory from
>>> dma_atomic_pool which was mapped to VMALLOC
On Wed, 6 May 2020, Nataliya Korovkina wrote:
> On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> wrote:
> >
> >
> > On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> > > Hello,
> > >
> > > What I found out: rpi_firmware_property_list() allocates memory from
> > > dma_atomic_pool which was mapped to
On Wed, 6 May 2020, Jürgen Groß wrote:
> On 06.05.20 00:34, Stefano Stabellini wrote:
> > + Boris, Jürgen
> >
> > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
> > related to the recent xen dma_ops changes. Possibly the same thing
> > reported by Peng here:
> >
> >
On Wed, 6 May 2020, Peng Fan wrote:
> > Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
> >
> > On 06.05.20 00:34, Stefano Stabellini wrote:
> > > + Boris, Jürgen
> > >
> > > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
> > > related to the recent xen
Use flex 2.6.4 that is shipped in Debian Buster.
Signed-off-by: Wei Liu
---
Do this because Roger posted a patch to fix clang build, which requires
updating the same files. I don't want bury his changes in unrelated
ones.
---
tools/libxl/libxlu_disk_l.c | 867
On 06/05/2020 16:10, Jan Beulich wrote:
> On 05.05.2020 19:32, Andrew Cooper wrote:
>> @@ -435,17 +435,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
>> struct cpu_user_regs *regs)
>> ASSERT(n2vmcb != NULL);
>>
>> /* Check if virtual VMCB cleanbits are valid */
>> -
> -Original Message-
> From: Jan Beulich
> Sent: 29 April 2020 12:02
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger
> Pau Monné
>
On Wed, May 06, 2020 at 06:41:43AM -0700, Tamas K Lengyel wrote:
> Add functions to issue VM forking hypercalls
>
> Signed-off-by: Tamas K Lengyel
Acked-by: Wei Liu
On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
wrote:
>
>
> On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> > Hello,
> >
> > What I found out: rpi_firmware_property_list() allocates memory from
> > dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page()
> > is not eligible in this
flight 150040 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150040/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
credit2 is currently modifying the pause flags of vcpus non-atomically
via sched_set_pause_flags() and sched_clear_pause_flags(). This is
dangerous as there are cases where the paus flags are modified without
any lock held.
So drop the non-atomic pause flag modification functions and rename the
On 05.05.2020 19:32, Andrew Cooper wrote:
> @@ -435,17 +435,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
> struct cpu_user_regs *regs)
> ASSERT(n2vmcb != NULL);
>
> /* Check if virtual VMCB cleanbits are valid */
> -vcleanbits_valid = 1;
> -if ( svm->ns_ovvmcb_pa
Hi,
On 06/05/2020 14:48, Corey Minyard wrote:
On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote:
Hi,
On 02/05/2020 03:16, Corey Minyard wrote:
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,
On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote:
> Hi,
>
> On 02/05/2020 03:16, Corey Minyard wrote:
> > 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
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 to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> Hello,
>
> What I found out: rpi_firmware_property_list() allocates memory from
> dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page()
> is not eligible in this case.
So then it seems it didn't go through
Add functions to issue VM forking hypercalls
Signed-off-by: Tamas K Lengyel
---
tools/libxc/include/xenctrl.h | 14 ++
tools/libxc/xc_memshr.c | 26 ++
2 files changed, 40 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h
On Wed, May 6, 2020 at 7:00 AM Wei Liu wrote:
>
> On Fri, May 01, 2020 at 07:59:45AM -0600, Tamas K Lengyel wrote:
> > 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
Hello,
What I found out: rpi_firmware_property_list() allocates memory from
dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page()
is not eligible in this case.
Thanks,
Nataliya
On Wed, May 6, 2020 at 4:57 AM Peng Fan wrote:
>
> > Subject: Re: Troubles running Xen on Raspberry
On Tue, May 05, 2020 at 11:24:53AM +0200, Roger Pau Monne wrote:
> The path provided by EXTRA_PREFIX should be added to the search path
> of the configure script, like it's done in Config.mk. Not doing so
> makes the search path for configure differ from the search path used
> by the build.
>
>
On Tue, May 05, 2020 at 11:24:54AM +0200, Roger Pau Monne wrote:
> Clang 10 complains with:
>
> 13: error: misleading indentation; statement is not part of the previous 'if'
> [-Werror,-Wmisleading-indentation]
> if ( ! yyg->yy_state_buf )
> ^
>
On Fri, May 01, 2020 at 07:59:45AM -0600, Tamas K Lengyel wrote:
> 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
>
flight 150056 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150056/
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 Wed, May 6, 2020 at 7:12 AM Jürgen Groß wrote:
>
> On 05.05.20 22:57, Arnd Bergmann wrote:
> > On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote:
> >> On 05.05.20 17:01, Arnd Bergmann wrote:
> >>> On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> On 05.05.20 16:15, Arnd Bergmann wrote:
flight 150055 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150055/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 779efdbb502b38c66b774b124fa0ceed254875bd
baseline version:
xen
flight 150042 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150042/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149836
test-armhf-armhf-xl-rtds 16
Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.
Note: per-cpupool granularity selection is not implemented yet. Every
cpupool gets
Hi Jan,
On 30/04/2020 15:32, Jan Beulich wrote:
On 30.04.2020 14:43, Julien Grall wrote:
From: Julien Grall
Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT
can only have two values (enabled or disabled). So switch from a string
to a bool.
Take the opportunity to replace
Hi George,
On 04/05/2020 12:10, George Dunlap wrote:
On Apr 30, 2020, at 3:50 PM, Jan Beulich wrote:
In order to make easier to experiment, the option EXPERT can now be
selected from the menuconfig rather than make command line. This does
not change the fact a kernel with EXPERT mode
Hi Ian,
On 04/05/2020 13:34, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected
from the menuconfig directly"):
On Apr 30, 2020, at 3:50 PM, Jan Beulich wrote:
Well, if I'm not mis-remembering it was on purpose to make it more
difficult
Hi Jan,
On 05/05/2020 07:26, Jan Beulich wrote:
On 22.04.2020 10:26, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
On 06/05/2020 10:36, Jan Beulich wrote:
Recent changes no longer allow modification of AFLAGS. The needed
conversion was apparently missed in 2740d96efdd3 ("xen/build: have the
root Makefile generates the CFLAGS").
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
---
On Thu, Apr 30, 2020 at 12:21:18PM +0200, Roger Pau Monné wrote:
> On Thu, Apr 30, 2020 at 12:15:58PM +0200, Roger Pau Monné wrote:
> > On Wed, Apr 29, 2020 at 11:47:18AM +, Wei Liu wrote:
> > > On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> > > > The value returned from CPUID is
Recent changes no longer allow modification of AFLAGS. The needed
conversion was apparently missed in 2740d96efdd3 ("xen/build: have the
root Makefile generates the CFLAGS").
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -68,7 +68,7 @@ extra-y +=
On Thu, Apr 30, 2020 at 07:38:42AM +0200, Juergen Gross wrote:
> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
> of the domain's xenstore ring page and the event channel of the
> domain for communicating with Xenstore.
>
> The gfn is not really needed. It is stored in the
On Tue, May 05, 2020 at 06:32:50PM +0100, Andrew Cooper wrote:
> Rework the vmcbcleanbits_t definitons to use bool, drop 'fields' from the
> namespace, position the comments in an unambiguous position, and include the
> bit position.
>
> In svm_vmexit_handler(), don't bother conditionally writing
Hi all,
The proposed agenda is in and
https://cryptpad.fr/pad/#/2/pad/edit/qPQUEQEv3nJJ97clS8b2KdtP/ you can edit to
add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the
> Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
>
> On 06.05.20 00:34, Stefano Stabellini wrote:
> > + Boris, Jürgen
> >
> > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
> > related to the recent xen dma_ops changes. Possibly the same thing
> >
On Tue, May 05, 2020 at 07:25:39PM +0100, Andrew Cooper wrote:
> AMD Fam15h processors introduced the flush-by-asid feature, for more fine
> grain flushing purposes.
>
> Flushing everything including ASID 0 (i.e. Xen context) is an an unnecesserily
> large hammer, and never necessary in the
On Tue, 5 May 2020 at 23:58, Bobby Eshleman wrote:
>
> On Thu, Apr 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote:
> > On Thu, 30 Apr 2020 at 13:15, Daniel Kiper wrote:
> > > Anyway, the advantage of this new protocol is that it uses UEFI API to
> > > load and execute PE kernel and its
flight 150041 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150041/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 149845
test-amd64-i386-xl-pvshim12
50 matches
Mail list logo
