On 22/12/2018 12:14, Juergen Gross wrote:
> On 06/12/2018 12:46, Greg KH wrote:
>> On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
>>> On 06/12/2018 12:13, Greg KH wrote:
On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov
flight 131896 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131896/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-amd64-xl-
On Fri, Jan 11, 2019 at 08:59:52AM +0100, Juergen Gross wrote:
> On 22/12/2018 12:14, Juergen Gross wrote:
> > On 06/12/2018 12:46, Greg KH wrote:
> >> On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
> >>> On 06/12/2018 12:13, Greg KH wrote:
> On Thu, Nov 29, 2018 at 02:35:17PM
On 11/01/2019 09:46, Greg KH wrote:
> On Fri, Jan 11, 2019 at 08:59:52AM +0100, Juergen Gross wrote:
>> On 22/12/2018 12:14, Juergen Gross wrote:
>>> On 06/12/2018 12:46, Greg KH wrote:
On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
> On 06/12/2018 12:13, Greg KH wrote:
>>>
On Fri, Jan 11, 2019 at 7:04 AM Christopher Clark
wrote:
>
> On Thu, Jan 10, 2019 at 2:19 AM Roger Pau Monné wrote:
> >
> > On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> > > +/*
> > > + * Locking is organized as follows:
> > > + *
> > > + * Terminology: R() means taking a read l
On Fri, Jan 11, 2019 at 7:29 AM Christopher Clark
wrote:
>
> On Thu, Jan 10, 2019 at 3:25 AM Roger Pau Monné wrote:
> >
> > On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> > > +static int
> > > +ring_map_page(struct argo_ring_info *ring_info, unsigned int i, void
> > > **out_ptr)
The way the instruction invocations are coded, it is compiler version
dependent whether things work: With old gcc, fail_{,in}valid will not
get touched and hence remain at their initial values, while with newer
gcc evaluation of the status flags occurs outside of the asm(), i.e.
also when an except
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 08 January 2019 15:18
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Wei Liu ;
> Jan Beulich ; Andrew Cooper
> ; Roger Pau Monne
> Subject: [PATCH v2 1/8] viridian: add init hooks
>
> This patch
CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
at around that time as well). Cope with it being undefined as well as
with the underlying kernel not knowing of it.
Signed-off-by: Jan Beulich
---
Considering how old "old" here really means, I could understand if
this was reje
flight 131897 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131897/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-i38
On 12/25/18 4:29 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Friday, December 14, 2018 7:50 PM
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwis
>>> On 10.01.19 at 19:46, wrote:
> On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
>> On Thu, 10 Jan 2019, Jan Beulich wrote:
>> > >>> On 10.01.19 at 03:40, wrote:
>> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
>> > > wrote:
>> > >
>> > >> Introduce a macro, SYMBOL, which
>>> On 11.01.19 at 03:14, wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the unsigned long
> solution is best. But Julien also did some research and he thinks that
> Jan's version (returning pointer type) not only does not help with
> MISRA-C, but also doesn't solve
>>> On 10.01.19 at 18:44, wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
>> >>> On 10.01.19 at 00:42, wrote:
>> > @@ -1138,9 +1138,10 @@ void free_init_memory(void)
>> > for ( i = 0; i < nr; i++ )
>> > *(p + i) = insn;
>> >
>> > -set_pte_flags_on_range(__init_begin, len, mg_
>>> On 10.01.19 at 19:52, wrote:
> On Thu, 10 Jan 2019, Stefano Stabellini wrote:
>> diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
>> index 548b64d..3fa56ff 100644
>> --- a/xen/include/xen/kernel.h
>> +++ b/xen/include/xen/kernel.h
>> @@ -66,27 +66,27 @@
>> })
>>
>> extern c
Andrii,
Due to some events on my side, I had to move from the R-Car H3 I was using
to the R-Car M3 in my posession.
I followed your initial advice and updated my environment to a newer
version, opting to stick to the rocko version for the m3ulcb.
The Yocto build configuration is shown below:
Bu
On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> at around that time as well). Cope with it being undefined as well as
> with the underlying kernel not knowing of it.
>
> Signed-off-by: Jan Beulich
> ---
> Consi
>>> On 11.01.19 at 12:18, wrote:
> On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
>> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
>> at around that time as well). Cope with it being undefined as well as
>> with the underlying kernel not knowing of it.
>>
>>
On Fri, Dec 14, 2018 at 12:50 PM Razvan Cojocaru
wrote:
>
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> re
>>> On 07.01.19 at 08:42, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -17,7 +17,177 @@
> */
>
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> +#include
> +#include
> +
> +DEFINE_XEN_GUEST_HANDLE(xen_argo_addr_t);
> +DEFINE_XEN_
Anthony PERARD writes ("[PATCH v8 17/17] libxl: Add comments to
libxl__json_*get* functions"):
> This comments that libxl__json_object_get_* and libxl__json_*_get
> functions accept the libxl__json_object parameter to be NULL.
>
> libxl__json_object_to_json also works with NULL.
>
> This also mo
On Fri, Jan 11, 2019 at 04:24:35AM -0700, Jan Beulich wrote:
[...]
> >
> >> +#endif
> >> +r = unshare(CLONE_NEWIPC);
> >> +if (r) {
> >> +if (r && errno != EINVAL) {
> >> +LOGE(ERROR, "libxl: IPC namespace unshare failed");
> >> +return ERROR_FAIL;
> >> +
Anthony PERARD writes ("[PATCH v8 06/17] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> This patch implement the API libxl__ev_qmp documented in the previous
> patch, "libxl: Design of an async API to issue QMP commands to QEMU".
>
> Since this API is to interact with QEMU via the QMP protocol
> On Jan 11, 2019, at 9:18 PM, Wei Liu wrote:
>
> On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
>> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
>> at around that time as well). Cope with it being undefined as well as
>> with the underlying kernel not know
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
sched_clock() interface") broke Xen guest time handling across
migration:
[ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 187.251137] OOM killer disabled.
[ 187.251137] Freezing remaining fre
On Fri, Jan 11, 2019 at 12:06:59PM +, George Dunlap wrote:
>
>
> > On Jan 11, 2019, at 9:18 PM, Wei Liu wrote:
> >
> > On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
> >> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> >> at around that time as well). C
On Fri, Jan 11, 2019 at 12:06:07PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v8 06/17] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> > This patch implement the API libxl__ev_qmp documented in the previous
> > patch, "libxl: Design of an async API to issue QMP commands to QEM
Anthony PERARD writes ("Re: [PATCH v8 06/17] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Fri, Jan 11, 2019 at 12:06:07PM +, Ian Jackson wrote:
> > Doesn't this want to be
> > +assert(r > 0 && r <= max_write);
>
> Yes, I think that would be fine. I guess that would catch iss
This patch implement the API libxl__ev_qmp documented in the previous
patch, "libxl: Design of an async API to issue QMP commands to QEMU".
Since this API is to interact with QEMU via the QMP protocol, it also
implement a QMP client. The specification for the QEMU Machine Protocol
(QMP) can be fou
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.libxl-ev-qmp-v9
Changes in v9:
fix on assert in "libxl_qmp: Implementation of libxl__ev_qmp_*".
all patch acked.
Cheers,
Anthony PERARD (17):
libxl: Enhance libxl__sendmsg_fd
On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> at around that time as well). Cope with it being undefined as well as
> with the underlying kernel not knowing of it.
>
> Signed-off-by: Jan Beulich
Acked-by: We
Hi,
On 1/11/19 1:08 PM, Juergen Gross wrote:
> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
> sched_clock() interface") broke Xen guest time handling across
> migration:
>
> [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [ 187.251137]
flight 131905 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Thu, 10 Jan 2019 at 13:52, Anthony PERARD wrote:
>
> The following changes since commit 8ae951fbc1068308313b2c57a4fc3c68451641f4:
>
> Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190109'
> into staging (2019-01-09 16:08:31 +)
>
> are available in the Git repository at
>>> On 11.01.19 at 13:06, wrote:
>> On Jan 11, 2019, at 9:18 PM, Wei Liu wrote:
>> On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
>>> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
>>> at around that time as well). Cope with it being undefined as well as
>>> w
On 11/01/2019 14:12, Hans van Kranenburg wrote:
> Hi,
>
> On 1/11/19 1:08 PM, Juergen Gross wrote:
>> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
>> sched_clock() interface") broke Xen guest time handling across
>> migration:
>>
>> [ 187.249951] Freezing user space pro
Ping!
Adding Ian Jackson specifically - we should really fix this for 4.12
Regards
Lars
> On 2 Aug 2018, at 12:24, Lars Kurth wrote:
>
> Hi all,
>
> most of our man pages on pretty much all releases from 4.2 contain broken
> links.
>
> For example:
> In https://xenbits.xen.org/docs/unstable/
flight 131917 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131917/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ]
The LDT remap placement has been changed. It's now placed before the direct
mapping in the kernel virtual address space for both paging mod
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
This reserved ra
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ]
The LDT remap placement has been changed. It's now placed before the direct
mapping in the kernel virtual address space for both paging mod
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
This reserved ra
On 11/01/2019 11:09, Jan Beulich wrote:
> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> at around that time as well). Cope with it being undefined as well as
> with the underlying kernel not knowing of it.
>
> Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
On Tue, Jan 8, 2019 at 10:53 AM Dongli Zhang wrote:
>
> Hi Roger,
>
> On 01/07/2019 11:27 PM, Roger Pau Monné wrote:
> > On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote:
> >>
> >>
> >> On 01/07/2019 10:05 PM, Dongli Zhang wrote:
> >>>
> >>>
> >>> On 01/07/2019 08:01 PM, Roger Pau Monn
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_ran
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_ran
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/d
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/xen/gntdev.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index b0b02a5..ca4acee 100644
---
Convert to use vm_insert_range_buggy() to map range of kernel
memory to user vma.
This driver has ignored vm_pgoff. We could later "fix" these drivers
to behave according to the normal vm_pgoff offsetting simply by
removing the _buggy suffix on the function name and if that causes
regressions, it
On 1/11/19 5:10 PM, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+)
This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of page-walks that have to emulate
instructions in access denied pages.
We use hvmemul_map_linear_addr() ro intercept r/w access and
hvmemul_insn_fetch() to intercept exec access.
First we try to send
This is done so hvmemul_linear_to_phys() can be called from
hvmemul_map_linear_addr()
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/emulate.c | 181 ++---
1 file changed, 90 insertions(+), 91 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/
On Fri, Jan 11, 2019 at 01:35:29PM +, Peter Maydell wrote:
> On Thu, 10 Jan 2019 at 13:52, Anthony PERARD
> wrote:
> >
> > The following changes since commit 8ae951fbc1068308313b2c57a4fc3c68451641f4:
> >
> > Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190109'
> > into
On 1/11/19 3:01 PM, Juergen Gross wrote:
> On 11/01/2019 14:12, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 1/11/19 1:08 PM, Juergen Gross wrote:
>>> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
>>> sched_clock() interface") broke Xen guest time handling across
>>> migrati
On Fri, 11 Jan 2019 at 15:55, Anthony PERARD wrote:
>
> On Fri, Jan 11, 2019 at 01:35:29PM +, Peter Maydell wrote:
> > On Thu, 10 Jan 2019 at 13:52, Anthony PERARD
> > wrote:
> > >
> > > The following changes since commit
> > > 8ae951fbc1068308313b2c57a4fc3c68451641f4:
> > >
> > > Merge r
On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
wrote:
>
> This patch aims to have mem access vm events sent from the emulator.
> This is useful in the case of page-walks that have to emulate
> instructions in access denied pages.
>
I'm a little confused about the scenario you mention her
On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
wrote:
This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of page-walks that have to emulate
instructions in access denied pages.
I'm a little conf
On Fri, 11 Jan 2019, Juergen Gross wrote:
> On 11/01/2019 03:14, Stefano Stabellini wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with Julien: we are both convinced that the unsigned long
> > solution is best. But Julien also did some research and he thinks that
> > Jan's version (returning pointer
On Fri, 11 Jan 2019, Jan Beulich wrote:
> >> > --- a/xen/arch/arm/setup.c
> >> > +++ b/xen/arch/arm/setup.c
> >> > @@ -772,8 +772,10 @@ void __init start_xen(unsigned long
> >> > boot_phys_offset,
> >> >
> >> > /* Register Xen's load address as a boot module. */
> >> > xen_bootmodule =
flight 131919 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131919/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Fri, 11 Jan 2019, Jan Beulich wrote:
> > If all we really care about is making PRQA happy, I believe it does support
> > some sort of comment-based suppression. I've seen comments like
> > /* PRQA S 0487 */ or /* PRQA S 0488 */ in various codebases, I'm guessing
> > comments like this have somet
On 11/01/2019 09:50, Jan Beulich wrote:
> The way the instruction invocations are coded, it is compiler version
> dependent whether things work: With old gcc, fail_{,in}valid will not
> get touched and hence remain at their initial values, while with newer
> gcc evaluation of the status flags occur
Juergen Gross writes ("Re: [PATCH] libxl: fix build on rather old systems"):
> On 11/01/2019 11:09, Jan Beulich wrote:
> > CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> > at around that time as well). Cope with it being undefined as well as
> > with the underlying kernel n
On Fri, 11 Jan 2019, Jan Beulich wrote:
> >>> On 11.01.19 at 03:14, wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with Julien: we are both convinced that the unsigned long
> > solution is best. But Julien also did some research and he thinks that
> > Jan's version (returning pointer type) not only
Patch "xen: add event channel interface for XenDevice-s" makes use of
the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
4.7. Also the function xen_device_bind_event_channel assign the return
value of xenevtchn_bind_interdomain to channel->local_port but check the
result for err
On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> Patch "xen: add event channel interface for XenDevice-s" makes use of
> the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
> 4.7. Also the function xen_device_bind_event_channel assign the return
> value of xenevt
CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.
Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old. Placate these people by providing
a fallback #define for CLONE_NEWIPC.
This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.
This situation should be handled by disabling the dm restrict
feature, not silently falling back to lower protection.
Also this #ifdeffery is bad style.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_linux.c | 16 ++--
On Fri, 11 Jan 2019 at 18:13, Anthony PERARD wrote:
>
> On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> > Patch "xen: add event channel interface for XenDevice-s" makes use of
> > the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen
> > 4.7. Also the function xe
On Fri, Jan 11, 2019 at 06:12:11PM +, Ian Jackson wrote:
> +#ifndef CLONE_XNEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
There's a strange X here, but not below.
> +# define CLONE_NEWIPC 0x0800
--
Anthony PERARD
___
Xen-devel mailing
On Friday, January 11, 2019 1:04 PM, Stefano Stabellini wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
> > >>> On 11.01.19 at 03:14, wrote:
> > > Hi Juergen, Jan,
> > >
> > > I spoke with Julien: we are both convinced that the unsigned long
> > > solution is best. But Julien also did some resea
Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix build (missing
CLONE_NEWIPC) on astonishingly old systems"):
> On Fri, Jan 11, 2019 at 06:12:11PM +, Ian Jackson wrote:
> > +#ifndef CLONE_XNEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
>
> There's a strange X here, but no
flight 131920 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131920/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.
Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old. Placate these people by providing
a fallback #define for CLONE_NEWIPC.
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 January 2019 18:10
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Stefano Stabellini
> ; Paul Durrant ; open
> list:X86
> Subject: [PATCH] xen: Fix event channel interface for XenDevice-s
>
> Pat
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand, <
stewart.hildebr...@dornerworks.com> wrote:
>
> Why don't we change the type of _start so it's not a pointer type?
Can you suggest a type that would be suitable?
Cheers,
___
Xen-devel mailing list
Xen-de
On 1/11/19 7:08 AM, Juergen Gross wrote:
> @@ -421,6 +424,11 @@ void xen_restore_time_memory_area(void)
> if (ret != 0)
> pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
> ret);
> +
> +out:
> + /* Need pvclock_resume() before using xen_c
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> >
> > Why don't we change the type of _start so it's not a pointer type?
>
> Can you suggest a type that would be suitable?
>
> Cheers,
Yes. My opinion is that the "sufficient-width in
On Fri, Jan 11, 2019 at 9:51 AM Razvan Cojocaru
wrote:
>
> On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
> > On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >> This patch aims to have mem access vm events sent from the emulator.
> >> This is useful in the case of page-walks
flight 131906 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131906/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pairbroken
test-amd64-i386-xl-
On 1/11/19 10:51 PM, Tamas K Lengyel wrote:
> On Fri, Jan 11, 2019 at 9:51 AM Razvan Cojocaru
> wrote:
>>
>> On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
>>> On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
>>> wrote:
This patch aims to have mem access vm events sent from the emula
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
> On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> > On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> > >
> > > Why don't we change the type of _start so it's not a pointer type?
> >
> > Can you suggest a type that would be suitable?
>
On Fri, Jan 11, 2019 at 2:37 PM Razvan Cojocaru
wrote:
>
> On 1/11/19 10:51 PM, Tamas K Lengyel wrote:
> > On Fri, Jan 11, 2019 at 9:51 AM Razvan Cojocaru
> > wrote:
> >>
> >> On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
> >>> On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
> >>> wrote:
>
On 1/11/19 4:57 PM, Hans van Kranenburg wrote:
> On 1/11/19 3:01 PM, Juergen Gross wrote:
>> On 11/01/2019 14:12, Hans van Kranenburg wrote:
>>> Hi,
>>>
>>> On 1/11/19 1:08 PM, Juergen Gross wrote:
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
sched_clock() inter
flight 131922 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131922/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> reply may legitim
flight 131908 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131908/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-i386-pvops
flight 131904 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131904/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub broken
test-amd64-i386-libvirt
flight 131913 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs. 131783
build-amd64-free
flight 131907 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131907/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-xl
flight 131909 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131909/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt broken
build-amd64-rumprun
Dear xen-devel mailing list,
(I know I am not subscribed; so this must be let through by a moderator.)
In the linux kernel MAINTAINERS file, largely
xen-devel@lists.xenproject.org (moderated for non-subscribers) is
mentioned as the xen-devel mailing list.
However, the DRM DRIVERS FOR XEN mention
On 12/01/2019 07:50, Lukas Bulwahn wrote:
> Dear xen-devel mailing list,
>
> (I know I am not subscribed; so this must be let through by a moderator.)
>
> In the linux kernel MAINTAINERS file, largely
> xen-devel@lists.xenproject.org (moderated for non-subscribers) is
> mentioned as the xen-devel
93 matches
Mail list logo
