I used save without any option when my VM was in running state, save won't
work if I pause a VM.
On Sat, Aug 13, 2016 at 11:04 AM, Cendrin Sa wrote:
>
>- I'm using Xen unstable 4.8 manually compiled on debian , I create a
>debian netinst guest using the following config file and then ju
flight 100470 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100431
Regressions which
- I'm using Xen unstable 4.8 manually compiled on debian , I create a
debian netinst guest using the following config file and then just use
save/restore, after restoring a machine *kernel hangout task happens*.
- We've test it With Xen 4.7 manually compiled on ubuntu 14.04 and the
This run is configured for baseline tests only.
flight 66974 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 10 guest-start
Hi Julien, Roger
On Fri, Aug 12, 2016 at 04:57:06PM +0200, Roger Pau Monné wrote:
>On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote:
>> On 12/08/2016 14:24, Peng Fan wrote:
>> > Hi,
>>
>> Hello Peng,
>>
>> I have CCed Roger who is more familiar than me with the hotplug scripts.
>>
>
From: Cao jin
emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.
Signed-off-by: Cao jin
Signed-off-by: Stefano Stabellini
Acked-by: Stefano Stabellini
---
hw/xen/xen_pt_co
From: Paul Durrant
VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
llini/qemu-dm.git tags/xen-20160812-tag-2
for you to fetch changes up to b7665c6027c972c23668ee74b878b5c617218514:
xen: handle inbound migration of VMs without ioreq server pages (2016-08-12
16:38:30 -0700)
Xen 2016/08/12, fixed comm
gt; 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11
> 17:53:35 +0100)
>
> are available in the git repository at:
>
>
> git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag
>
> for you to fetch changes up to f
llini/qemu-dm.git tags/xen-20160812-tag
for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9:
xen: handle inbound migration of VMs without ioreq server pages (2016-08-12
15:16:15 -0700)
Xen
From: Cao jin
emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.
Signed-off-by: Cao jin
---
hw/xen/xen_pt_config_init.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletio
From: Paul Durrant
VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
flight 100466 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100466/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 100431
test-amd64-amd64-x
On Fri, 12 Aug 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 11 August 2016 21:07
> > To: Paul Durrant
> > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu-
> > de...@nongnu.org; Stefano Stabellini
> > Subject
On Fri, 12 Aug 2016, Lars Kurth wrote:
> COPYING file:
> The motivation of this change is to make it easier for new
> contributors to conduct a license and patent review, WITHOUT
> changing any licenses.
> - Remove references to BSD-style licenses as we have more
> common license exceptions and r
On Fri, Aug 12, 2016 at 10:23:34PM +0200, Greg KH wrote:
> On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> > Alright, how's this new description:
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index cac3f096050d..73e4890c24c4 100644
> > --- a/init/Kconfig
> > +++ b/init/
On Fri, 12 Aug 2016, Jan Beulich wrote:
> > +Let me express this as an algorithm.
> > +
> > + treshhold=2/3;
> > + active='number of active members'; (7 for the Hypervisor project;
> > IanC is inactive)
> > + favour='number of +1 and +2 votes'
> > + against='number of -1 a
flight 66973 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66973/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail
never pass
test-armhf-ar
This run is configured for baseline tests only.
flight 66971 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66971/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
On Fri, 12 Aug 2016, Lars Kurth wrote:
> On 11/08/2016 19:59, "Stefano Stabellini" wrote:
>
> >On Thu, 11 Aug 2016, Lars Kurth wrote:
> >> On 11/08/2016 01:51, "Stefano Stabellini"
> >>wrote:
> >>
> >> >> +Developer's Certificate of Origin
> >> >> +-
> >> >> +
>
This run is configured for baseline tests only.
flight 66972 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66972/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 926059304e8377fc37bb848d06d9419f419d93ff
baseline v
On Fri, Aug 12, 2016 at 05:00:47PM +0200, Julien Grall wrote:
> Hi Konrad,
>
> On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote:
> > The initial support for ARM64 - and livepatching
> > works:
>
> As it is a very RFC I only gave a quick look. I have few comments on it (see
> below).
>
> >
> > (
On Fri, 12 Aug 2016, Greg KH wrote:
> > + Enabling this option never increases the size of your kernel.
>
> Then what does it do? Just burn electricity for no reason?
I think that this whole thing could be without loss of generality
reformulated in a "allows for participating in compile-te
On Fri, Aug 12, 2016 at 08:45:02AM -0600, Jan Beulich wrote:
> The initial size check in xen_build_id_check() came too late (after the
> first access to the structure), but was mostly redundant with checks
> done in all callers; convert it to a properly placed ASSERT(). The
> "mostly" part being ad
On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> Alright, how's this new description:
>
> diff --git a/init/Kconfig b/init/Kconfig
> index cac3f096050d..73e4890c24c4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -53,6 +53,34 @@ config CROSS_COMPILE
> need to set
This run is configured for baseline tests only.
flight 66970 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66970/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopf
flight 100454 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100454/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 100421
test-amd64-i386-xl-qemuu-w
Friday, August 12, 2016, 7:29:37 PM, you wrote:
> Hi,
> On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote :
>> L.S.,
>>
>> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV
>> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on
>> boot
Just some minor typos in descriptions I noticed below...
On Fri, Aug 12, 2016 at 10:35 AM, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
>> Alright, how's this new description:
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index cac3f096050d..73e4
flight 100468 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100468/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> Alright, how's this new description:
>
> diff --git a/init/Kconfig b/init/Kconfig
> index cac3f096050d..73e4890c24c4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -53,6 +53,34 @@ config CROSS_COMPILE
> need to set
Hi,
On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote :
> L.S.,
>
> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV
> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on
> boot
> of the guest, instead of the system clock time.
>
> Bis
Added a COPYING file as a boilerplate to explain license oddities in
this directory
Added a vtpm/COPYING file which contains MIT licensed files only
Added a vtpmmgr/README.source file which contains many BSD-3-Clause
files that originally came from tools/vtpm_manager
Signed-off-by: Lars Kurth
-
This series contains some of the easier license clean-up cases, which can be
fixed
by adding COPYING files or README.source files. The series specially contains:
xen/crypto and xen/include/crypto
Added a README.source file
Does not need a COPYING file: all files are imported
m4
Updated README.s
In addition:
- fixed a reference, which was incorrect
Signed-off-by: Lars Kurth
---
m4/README.source | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/m4/README.source b/m4/README.source
index 21850a6..be7bc5a 100644
--- a/m4/README.source
+++ b/m4/README.source
@@ -3,6
Blktap2 has some complexity, as some files do not have (c) headers
and the directory did not have a COPYING file. At this stage, we
have not verified the intention of (c) holders. We may do this in
future, if the need arises.
Signed-off-by: Lars Kurth
---
tools/blktap2/COPYING | 72 +
I added these, as I came across the sources during
a license scan.
Signed-off-by: Lars Kurth
---
xen/crypto/README.source | 17 +
xen/include/crypto/README.source | 17 +
2 files changed, 34 insertions(+)
create mode 100644 xen/crypto/README.source
creat
L.S.,
I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV
guests and dom0 are uneffected). The clock is always set to 31/12/1999 on boot
of the guest, instead of the system clock time.
Bisecting seems to point out commit:
463a86304cae92e10277b47180ac59cf93982e5b char/ge
On Fri, Aug 12, 2016 at 05:51:21PM +0200, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote:
> > Even so, you don't link the compiled extra code so the only penalty
> > here is when compiling, nothing more. And if you are compiling typically
> > the cost her
On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote:
> Even so, you don't link the compiled extra code so the only penalty
> here is when compiling, nothing more. And if you are compiling typically
> the cost here is just a few seconds.
Yeah, so let's make it clear that this is simil
On Fri, Aug 12, 2016 at 09:51:39AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote:
> > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:
> > > Hey Ross,
> > >
> > > I am running in a symbol dependency issue that I am not exactly
> > > sure h
On Fri, Aug 12, 2016 at 09:25:07AM +0200, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote:
> > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote:
> > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote:
> > > > OK I've added C
On 12/08/16 16:21, Jan Beulich wrote:
On 12.08.16 at 17:02, wrote:
>> On 12/08/16 15:47, Jan Beulich wrote:
>>> Besides being more logical this also allows verifying correct recording
>>> of alignments in .o files.
>>>
>>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
>>
>>> On 12.08.16 at 17:02, wrote:
> On 12/08/16 15:47, Jan Beulich wrote:
>> Besides being more logical this also allows verifying correct recording
>> of alignments in .o files.
>>
>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
>> value (as it now verifies correct tool chai
On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:
> Let me know if you want me to check this in as-is or if you think you
> might send a follow-up patch adding an ASSERT.
>
Done, and it actually explodes like this:
(XEN) [4.870128] Xen call tr
On Fri, Aug 12, 2016 at 04:02:11PM +0200, Samuel Thibault wrote:
> Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote:
> > BUILD_BUG_ON should not appear in a public-facing header, otherwise it
> > risks clashing with macro with the same name in other code bases. I
> > encountered such issue when tr
flight 100457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100457/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
... and use it for RET, LRET, and ENTER processing to limit the amount
of "manual" insn bytes fetching. Note that for the RET and LRET paths
the change utilizes that SrcImplicit (aka SrcNone) table entries leave
src.val as zero.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/ar
There's no need for having identical code spelled out twice.
Signed-off-by: Jan Beulich
---
v2: Add braces (with quite a bit of reluctance).
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1979,9 +1979,14 @@ x86_emulate(
goto done;
On Fri, Aug 12, 2016 at 08:51:14AM -0600, Tamas K Lengyel wrote:
> On Aug 12, 2016 05:24, "Julien Grall" wrote:
> >
> > Hello Tamas,
> >
> >
> > On 10/08/2016 17:00, Tamas K Lengyel wrote:
> >>
> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >> index ef614be..97948fd
On 12/08/16 15:47, Jan Beulich wrote:
> Besides being more logical this also allows verifying correct recording
> of alignments in .o files.
>
> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
> value (as it now verifies correct tool chain behavior), but I've left
> it in nevert
Hi Konrad,
On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote:
The initial support for ARM64 - and livepatching
works:
As it is a very RFC I only gave a quick look. I have few comments on it
(see below).
(XEN) livepatch: xen_hello_world: Applying 1 functions
(XEN) hi_func: Hi! (called 1 tim
1: fold SrcImmByte fetching
2: introduce SrcImm16
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
This run is configured for baseline tests only.
flight 66968 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66968/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-build
On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote:
> On 12/08/2016 14:24, Peng Fan wrote:
> > Hi,
>
> Hello Peng,
>
> I have CCed Roger who is more familiar than me with the hotplug scripts.
>
> > I am using xen master branch on i.MX8 ARM64.
> >
> > My xl configuration:
> >
> > kern
On Aug 12, 2016 05:24, "Julien Grall" wrote:
>
> Hello Tamas,
>
>
> On 10/08/2016 17:00, Tamas K Lengyel wrote:
>>
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index ef614be..97948fd 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>>
Recent enough binutils support --build-id also for COFF/PE output, and
hence we should use that in favor of the original hack when possible.
This gets complicated by the linker requiring at least one COFF object
file to attach the .buildid section to. Hence the patch introduces a
buildid.ihex (in
Section start symbols frequently obscure the actual symbol name living
at the start of the section. Eliminate them where they can be replaced
by linker resolved .startof.* symbols. (Section end symbols may have
the same undesirable effect, but they're less easy to eliminate, as
they'd need to be re
Besides being more logical this also allows verifying correct recording
of alignments in .o files.
The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
value (as it now verifies correct tool chain behavior), but I've left
it in nevertheless.
Signed-off-by: Jan Beulich
--- a/xen/a
The initial size check in xen_build_id_check() came too late (after the
first access to the structure), but was mostly redundant with checks
done in all callers; convert it to a properly placed ASSERT(). The
"mostly" part being addressed too: xen_build_init() was off by one.
And then there was a s
Section start symbols frequently obscure the actual symbol name living
at the start of the section. Eliminate them where they can be replaced
by linker resolved .startof.* symbols. (Section end symbols may have
the same undesirable effect, but they're less easy to eliminate, as
they'd need to be re
1: build-id: fix minor quirks
2: x86/EFI: use less crude way of generating the build ID
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 100452 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100452/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 62b8b5be713dd1f801cd44e4eb28f68585a9bd85
baseline version:
ovmf 82df618711c596d3b6164
Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote:
> BUILD_BUG_ON should not appear in a public-facing header, otherwise it
> risks clashing with macro with the same name in other code bases. I
> encountered such issue when trying to add BUILD_BUG_ON to a private
> header in Xen's gnttab library.
>
BUILD_BUG_ON should not appear in a public-facing header, otherwise it
risks clashing with macro with the same name in other code bases. I
encountered such issue when trying to add BUILD_BUG_ON to a private
header in Xen's gnttab library.
Ideally BUILD_BUG_ON should be moved to a private header, b
flight 100431 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100424
Tests which are fa
I'll try to test this, but I have one comment inline...
On 08/11/2016 10:17 PM, Dave Young wrote:
On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that c
>>> On 12.08.16 at 03:59, wrote:
> On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
>> I'd really like to have those backported, but I have to ask one
>> of you to identify which prereq-s are needed on 4.6 and 4.5
>> (I'll revert them from 4.5 right away, but I'll wait for an osstest
>> fligh
On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote:
> On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:
> > Hey Ross,
> >
> > I am running in a symbol dependency issue that I am not exactly
> > sure how to solve.
> >
> > I have an payload that introduces a new function (xen_foobar)
flight 66969 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66969/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 66914
jobs:
build-amd64 pass
build-armh
On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting
> output"):
> > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > > We don't care when xenconsoled closes the logfile. We care about when
> >
Since commit a9dd01431a799b6743193a75f4f1ce2fdfdb7296, main_cpupoolnumasplit
wants to ensure that dom0 doesn't have more online vCPUs than the number of
pCPUs in a NUMA node.
However, if dom0 already has fewer online vCPUs than the number of pCPUs in a
NUMA node, this will cause some to be made on
Wei Liu, on Fri 12 Aug 2016 13:48:09 +0100, wrote:
> ---8<---
> From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001
> From: Wei Liu
> Date: Fri, 12 Aug 2016 11:32:57 +0100
> Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c
>
> Making that function inlined won't buy
>>> On 12.08.16 at 14:53, wrote:
> On 12/08/2016 13:41, "Jan Beulich" wrote:
> On 12.08.16 at 01:13, wrote:
>>> +### Lazy Consensus {#lazyconsensus}
>>> +
>>> +Lazy Consensus is a useful technique to make decisions for specific
>>>proposals
>>> +which are not covered by the Review Then Comm
On 12/08/2016 14:24, Peng Fan wrote:
Hi,
Hello Peng,
I have CCed Roger who is more familiar than me with the hotplug scripts.
I am using xen master branch on i.MX8 ARM64.
My xl configuration:
kernel = "/root/xen/Image"
memory = "128"
name = "DomU"
vcpus = 1
serial="pty"
disk = [ 'phy:/dev/
On 12/08/2016 13:41, "Jan Beulich" wrote:
On 12.08.16 at 01:13, wrote:
>> +### Lazy Consensus {#lazyconsensus}
>> +
>> +Lazy Consensus is a useful technique to make decisions for specific
>>proposals
>> +which are not covered by the Review Then Commit Policy or do not
>>require a more
>
On Fri, Aug 12, 2016 at 12:42:31PM +0100, Wei Liu wrote:
> On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote:
> > Support ballooning Mini-OS automatically up in case of memory shortage.
> >
> > Do some cleanups, a small correction and add some basic features to
> > lay groundwork for s
>>> On 12.08.16 at 01:13, wrote:
> +### Lazy Consensus {#lazyconsensus}
> +
> +Lazy Consensus is a useful technique to make decisions for specific
> proposals
> +which are not covered by the Review Then Commit Policy or do not require a
> more
> +formal decison (see below). Lazy Consensus is e
Hi,
I am using xen master branch on i.MX8 ARM64.
My xl configuration:
kernel = "/root/xen/Image"
memory = "128"
name = "DomU"
vcpus = 1
serial="pty"
disk = [ 'phy:/dev/loop0,xvda,w' ]
extra = "console=hvc0 root=/dev/xvda debug=/bin/sh"
And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux
>>> On 12.08.16 at 12:35, wrote:
> The undefined behaviour sanitiser shows that it really is NULL via the
> pre_initcall path.
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
> (XEN) member
>>> On 12.08.16 at 12:35, wrote:
> The undefined behaviour sanitiser in Clang 3.8 identifies that these are all
> misaigned when used in __start_xen().
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@list
>>> On 12.08.16 at 12:03, wrote:
> On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote:
>> >>> On 11.08.16 at 11:17, wrote:
>> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long
> mbi_p)
>> > if ( !opt_smep )
>> > setup_clear_cpu_cap(X86_FEATURE_SMEP);
On 12/08/16 11:58, Jan Beulich wrote:
On 11.08.16 at 20:10, wrote:
>> On 09/08/16 11:40, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/mtrr/main.c
>>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>> if ((type == MTRR_TYPE_WRCOMB) &&
>>> On 12.08.16 at 11:44, wrote:
> On 09/08/16 12:30, Jan Beulich wrote:
> On 09.08.16 at 12:48, wrote:
>>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
>>> depriv)"):
Actually, having thought about this some more, and taking this
together with the expec
On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote:
> Support ballooning Mini-OS automatically up in case of memory shortage.
>
> Do some cleanups, a small correction and add some basic features to
> lay groundwork for support of ballooning in Mini-OS (patches 1-14).
>
> The main visib
On 12/08/16 11:50, Jan Beulich wrote:
On 11.08.16 at 19:38, wrote:
>> On 11/08/16 17:44, Jan Beulich wrote:
>> On 11.08.16 at 18:32, wrote:
On 11/08/16 13:06, Jan Beulich wrote:
> @@ -2893,7 +2894,6 @@ x86_emulate(
> goto swint;
>
> case 0xcd: /* int
flight 100433 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100433/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 82df618711c596d3b6164e790572c795b7ea4dcc
baseline version:
ovmf 753cf34e29c52bb45d25e
Hello Tamas,
On 10/08/2016 17:00, Tamas K Lengyel wrote:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..97948fd 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [
>>> On 12.08.16 at 05:18, wrote:
> Hi Jan,
> Thanks for your reply.
> Qemu-xen seems that has problem for support 8G large Bar.
> I think this patch is not perfect:
> https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=aabc8530c7ba2b
> e89e21463f051056ad7c255e6e
> Because I found upper
>>> On 12.08.16 at 12:34, wrote:
> On 11/08/16 19:10, Andrew Cooper wrote:
>> On 09/08/16 11:40, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/mtrr/main.c
>>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>> if ((type == MTRR_TYPE_WRCOMB)
>>> On 11.08.16 at 20:10, wrote:
> On 09/08/16 11:40, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>> printk(KE
>>> On 11.08.16 at 19:38, wrote:
> On 11/08/16 17:44, Jan Beulich wrote:
> On 11.08.16 at 18:32, wrote:
>>> On 11/08/16 13:06, Jan Beulich wrote:
@@ -2893,7 +2894,6 @@ x86_emulate(
goto swint;
case 0xcd: /* int imm8 */
-src.val = insn_fetch_typ
The undefined behaviour sanitiser shows that it really is NULL via the
pre_initcall path.
(XEN)
(XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
(XEN) member access within null pointer of type 'struct proce
The undefined behaviour sanitiser in Clang 3.8 identifies that these are all
misaigned when used in __start_xen().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/boot/mem.S | 1 +
xen/arch/x86/boot/video.S | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/arch/x86/b
On 11/08/16 19:10, Andrew Cooper wrote:
> On 09/08/16 11:40, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>> pri
On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote:
> >>> On 11.08.16 at 11:17, wrote:
> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long
> > mbi_p)
> > if ( !opt_smep )
> > setup_clear_cpu_cap(X86_FEATURE_SMEP);
> > if ( cpu_has_smep )
> > +
Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting
output"):
> On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > We don't care when xenconsoled closes the logfile. We care about when
> > it last calls write() (with a nonempty buffer).
>
> In logfile mode
On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Dario Faggioli
> It might be nice if we could add an ASSERT() that the appropriate
> runqueue was locked, to make sure we don't get caught out
On 09/08/16 12:30, Jan Beulich wrote:
On 09.08.16 at 12:48, wrote:
>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
>> depriv)"):
>>> Actually, having thought about this some more, and taking this
>>> together with the expectations to the privcmd driver previously
COPYING file:
The motivation of this change is to make it easier for new
contributors to conduct a license and patent review, WITHOUT
changing any licenses.
- Remove references to BSD-style licenses as we have more
common license exceptions and replace with "other license
stanzas"
- List the mo
1 - 100 of 112 matches
Mail list logo
