> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, August 30, 2016 2:34 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org
> Subject: RE: [PATCH] Fix a BUG_ON issue
>
> >>> On 30.08.16 at 01:19, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >
On Mon, Aug 29, 2016 at 04:18:25PM +0200, Juergen Gross wrote:
> The patch series adding HVMlite support for Mini-OS unfortunately
> broke building Xen's stubdoms. This small series repairs the broken
> bits again.
>
> V2: patch 1: remove CONFIG_KEEP_STARTINFO
>
> Juergen Gross (2):
> mini-os:
On Mon, Aug 29, 2016 at 02:01:39PM +0100, Wei Liu wrote:
> Wei Liu (3):
> Makefile: simplify all_sources macro
> Makefile: add gtags target
> gitignore: ignore files generated by various indexing software
>
> .gitignore | 7 +++
> Makefile | 6 +-
> 2 files changed, 12 insertions(
flight 100658 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100658/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt 12 migrate-s
On Mon, Aug 29, 2016 at 03:07:07PM -0400, Julien Grall wrote:
> Hi Shannon,
>
> On 16/08/2016 06:25, Shannon Zhao wrote:
> >From: Shannon Zhao
> >
> >While it defines the maximum size of guest ACPI tables in guest
> >memory layout, here it adds the size to set the target maxmem
> >to avoid provid
On 08/30/2016 09:39 AM, Jan Beulich wrote:
On 29.08.16 at 18:42, wrote:
>> On 08/29/16 19:20, Jan Beulich wrote:
>> On 29.08.16 at 18:02, wrote:
On 08/29/16 18:42, Jan Beulich wrote:
On 29.08.16 at 17:29, wrote:
>> On 08/26/2016 11:14 AM, Jan Beulich wrote:
>>
>>> On 29.08.16 at 20:41, wrote:
> Hi Jan
>
> Today I had some free cycles so I spent some time looking at gcov
> support in the hypervisor and tried to write a patch to fix the
> currently broken gcov build. But my patch alone is not enough to fix
> that.
>
> There seems to be a problem with th
flight 100657 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100657/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 100655
build-amd64-rumpuserxen
On Tue, Aug 30, 2016 at 02:38:44AM -0600, Jan Beulich wrote:
> >>> On 29.08.16 at 20:41, wrote:
> > Hi Jan
> >
> > Today I had some free cycles so I spent some time looking at gcov
> > support in the hypervisor and tried to write a patch to fix the
> > currently broken gcov build. But my patch al
>>> On 30.08.16 at 10:34, wrote:
> It would appear that either I'm missing something, or the only way to
> continue is to manually add the required translation considering the
> modifications.
At least that's likely the easiest (and most consistent route). See
e.g. the handling of XENMEM_get_vnum
Within compat_memory_op() this needs to be placed in the first switch()
statement, or it ends up being dead code (as that first switch() has a
default case chaining to compat_arch_memory_op()).
Signed-off-by: Jan Beulich
---
Compile tested only.
--- a/xen/common/compat/memory.c
+++ b/xen/common/
On 2016/8/30 3:07, Julien Grall wrote:
> Hi Shannon,
>
> On 16/08/2016 06:25, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> While it defines the maximum size of guest ACPI tables in guest
>> memory layout, here it adds the size to set the target maxmem
>> to avoid providing less available mem
On 29/08/16 12:59, Jan Beulich wrote:
> Hello,
>
> in the context of
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
> I once again came across the different behavior our various
> implementations of the $subject functions, in particular their varying
> handling of the
On 08/30/2016 12:15 PM, Jan Beulich wrote:
> Within compat_memory_op() this needs to be placed in the first switch()
> statement, or it ends up being dead code (as that first switch() has a
> default case chaining to compat_arch_memory_op()).
>
> Signed-off-by: Jan Beulich
> ---
> Compile tested
flight 100659 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100659/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5f53a7aa59d4df1fe4326af18a9240d4dfebc129
baseline version:
ovmf e53f1e253e01026029f5c
>>> On 30.08.16 at 11:46, wrote:
> On 08/30/2016 12:15 PM, Jan Beulich wrote:
>> Within compat_memory_op() this needs to be placed in the first switch()
>> statement, or it ends up being dead code (as that first switch() has a
>> default case chaining to compat_arch_memory_op()).
>>
>> Signed-off
>>> On 30.08.16 at 11:26, wrote:
> On 29/08/16 12:59, Jan Beulich wrote:
>> Hello,
>>
>> in the context of
>> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
>> I once again came across the different behavior our various
>> implementations of the $subject functions, in
This run is configured for baseline tests only.
flight 67606 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e53f1e253e01026029f5ce7474a9d8421c8a0fbb
baseline v
This run is configured for baseline tests only.
flight 67605 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 10 guest-start
On 29/08/16 13:45, Jan Beulich wrote:
On 29.08.16 at 14:00, wrote:
>>> I think this is reasonable, despite it certainly being unexpected for
>>> the BIOS to turn such on when not putting the system into x2APIC
>>> mode.
>> It seems that linux doesn't use x2APIC because the BIOS explicitly
>>
Ian Jackson writes ("[Wg-test-framework] osstest Massachusetts test lab
resource usage investigation"):
> In parallel with the work I am reporting in this email, I am already
> taking steps to investigate the performance of the various database
> queries, and the situation with locking.
>
> I hop
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> Well, in a way. And then not: Initially I had thought no issue would
> arise, until I came to realize the kernel memory corruption potential.
> Question is whether now we're overlooking some other not
> immediate
flight 67607 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67607/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 67581
test-armhf-arm
Mini-OS is currently setting __XEN_INTERFACE_VERSION__ to a rather
ancient version.
To be able to use a more recent variant garnt_entry_t must be changed
to grant_entry_v1_t. In balloon.c we omit initializing elements of
struct xen_memory_reservation with 0 to avoid problems with different
named s
Adding support for HVMlite Mini-OS broke some stubdom functionality
as various parts of the stubdom code was built without specifying
any Mini-OS configuration defines. This led to inconsistencies when
those parts included Mini-OS headers now depending on the config of
Mini9-OS. Some of those cases
Provide non-inline variants of the local_irq_*() functions for Mini-OS
apps which should not depend on Mini-OS configuration.
Signed-off-by: Juergen Gross
---
arch/x86/sched.c | 28
include/x86/os.h | 13 +
2 files changed, 41 insertions(+)
diff --git a/
Mini-OS applications being compiled using Mini-OS headers without
being integrated in the make environment of Mini-OS need a way to set
CONFIG_* defines according to their Mini-OS configuration.
Add a new make target "config" for that purpose creating a Makefile
snipplet $(CONFIG_FILE) (defaults t
Mini-OS apps need to be compiled with the appropriate config settings
of Mini-OS, as there are various dependencies on those settings in
header files included by the apps.
Enhance stubdom Makefile to set the appropriate CPPFLAGS when calling
the apps' make.
Signed-off-by: Juergen Gross
---
stub
Currently enabling gcov in hypervisor won't build because although
26c9d03d ("gcov: Adding support for coverage information") claimed that
%.init.o files were excluded from applying compilation options, it was
in fact not true.
Fix that by filtering out the options correctly. Due to the dependency
A small series to fix gcov build for both x86 and arm.
Wei Liu (4):
arm: acpi/boot.c is only used during initialisation
arm64: use "b" to branch to start_xen
xen: fix gcov compilation
xen: add a gcov Kconfig option
Config.mk | 3 ---
xen/Kconfig.debug | 5 +
The cbz instruction has range limitation. When compiled with gcov
support the object is larger so cbz can't handle that anymore. The error
message is like:
aarch64-linux-gnu-ld-EL -T xen.lds -N prelink.o \
/local/work/xen.git/xen/common/symbols-dummy.o -o
/local/work/xen.git/xen/.xen-sym
That file should contain code and data used during initialisation only.
Mark it as such in build system and correctly annotate enabled_cpus.
This is required to enable gcov support on ARM.
Signed-off-by: Wei Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch/arm/acpi/Makefile | 2 +-
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Doug Goldstein
Would like to have it default to DEBUG, but we also need to check
compiler to be gcc. I couldn't figure out how
On 08/29/2016 10:36 AM, Jan Beulich wrote:
On 26.08.16 at 17:11, wrote:
>> On 08/25/2016 11:06 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
This patch introduces support for using TSC as platform time source
which is the highest resolution time and most performant to
On 08/29/2016 10:41 AM, Jan Beulich wrote:
On 26.08.16 at 17:12, wrote:
>> On 08/25/2016 11:13 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
On 8/16/2016 9:35 PM, George Dunlap wrote:
On 12/07/16 10:02, Yu Zhang wrote:
This patch resets p2m_ioreq_server entries back to p2m_ram_rw,
after an ioreq server has unmapped. The resync is done both
asynchronously with the current p2m_change_entry_type_global()
interface, and synchronously b
As of commit a35dc6ccbb ("x86: remove the use of vm86_mode()") it is
unused.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1851,7 +1851,6 @@ long do_fpu_taskswitch(int set)
static int read_descriptor(unsigned int sel,
const st
On 08/29/2016 11:06 AM, Jan Beulich wrote:
On 26.08.16 at 17:44, wrote:
>> On 08/25/2016 11:37 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
This patch proposes relying on host TSC synchronization and
passthrough to the guest, when running on a TSC-safe platform. On
>>
On 30/08/16 13:18, Jan Beulich wrote:
> As of commit a35dc6ccbb ("x86: remove the use of vm86_mode()") it is
> unused.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xe
>>> On 30.08.16 at 14:08, wrote:
> On 08/29/2016 10:36 AM, Jan Beulich wrote:
> On 26.08.16 at 17:11, wrote:
>>> On 08/25/2016 11:06 AM, Jan Beulich wrote:
>>> On 24.08.16 at 14:43, wrote:
> - Change init_tsctimer to skip all the tests and assume it's called
> only on reliable
>>> On 30.08.16 at 14:10, wrote:
> What would be a preferred period - probably capping it to a day/hour/minutes?
> Or
> keeping the current calculated value? Maximum right now in current platform
> timers
> are few minutes depending on the HPET frequency.
Ideally I would see you just use the ca
Hi Jan,
On 30/08/16 11:08, Jan Beulich wrote:
On 30.08.16 at 11:26, wrote:
On 29/08/16 12:59, Jan Beulich wrote:
Hello,
in the context of
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg03068.html
I once again came across the different behavior our various
implementations of
Could you please use xl -vvv create to create the guest and collect the
output?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Aug 26, 2016 at 02:09:53PM +0100, Wei Liu wrote:
> On Fri, Aug 26, 2016 at 01:58:55PM +0200, Juergen Gross wrote:
> > Commit 91e204d37f44913913776d0a89279721694f8b32 ("libxc: try to find
> > last used pfn when migrating") introduced a bug for the case of a
> > domain supporting the virtual
>>> On 30.08.16 at 14:26, wrote:
> On 08/29/2016 11:06 AM, Jan Beulich wrote:
> On 26.08.16 at 17:44, wrote:
>>> On 08/25/2016 11:37 AM, Jan Beulich wrote:
>>> On 24.08.16 at 14:43, wrote:
> This patch proposes relying on host TSC synchronization and
> passthrough to the guest, w
Hi Jan,
On 24/08/16 08:44, Jan Beulich wrote:
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -21,8 +21,8 @@
#include
#include
-extern const struct device_desc _sdevice[], _edevice[];
-extern const struct acpi_device_desc _asdevice[], _aedevice[];
+extern const struct device_desc
Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"):
> There has not been any substantial update to them since 2011. My quick
> check shows that they don't work.
>
> Just delete them. It would be easy to resurrect them from git log should
> people still need them.
I'm not sure what
Wei Liu writes ("[PATCH v2 1/2] tools: remove blktap2 related code and
documentation"):
> Blktap2 is effectively dead code for a few years.
>
> Notable changes in this patch:
>
> 0. Unhook blktap2 from build system
> 1. Now libxl no longer supports TAP disk backend, appropriate assertions
>a
>>> On 30.08.16 at 14:01, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
with one adjustment (see below).
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Doug Goldstein
>
> Would like to have it default to DEBUG, but we also need to check
> compiler to
Wei Liu writes ("[PATCH 3/4] xen: fix gcov compilation"):
> Currently enabling gcov in hypervisor won't build because although
> 26c9d03d ("gcov: Adding support for coverage information") claimed that
> %.init.o files were excluded from applying compilation options, it was
> in fact not true.
>
>
Wei Liu writes ("[PATCH] libxl: update flex output files"):
> Libxl ships output files from flex (libxlu_*_l.{c,h}). We use the flex
> shipped in Debian to generate those files. Debian just patched their
> flex (DSA 3653-1) to fix CVE-2016-6354, which is a buffer overrun bug.
>
> Note that libxl i
Wei Liu writes ("Re: [PATCH] libxc: correct max_pfn calculation for saving
domain"):
> Pushed.
>
> Ian, please backport this to Xen 4.7.
Noted, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
This run is configured for baseline tests only.
flight 67608 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67608/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5f53a7aa59d4df1fe4326af18a9240d4dfebc129
baseline v
>>> On 30.08.16 at 14:57, wrote:
> Wei Liu writes ("[PATCH 3/4] xen: fix gcov compilation"):
>> Currently enabling gcov in hypervisor won't build because although
>> 26c9d03d ("gcov: Adding support for coverage information") claimed that
>> %.init.o files were excluded from applying compilation op
On Tue, Aug 30, 2016 at 06:56:36AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 14:01, wrote:
> > Signed-off-by: Wei Liu
>
> Acked-by: Jan Beulich
>
> with one adjustment (see below).
>
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Stefano Stabellini
> > Cc: Tim Deegan
> > Cc: Doug Goldstein
>
>>> On 30.08.16 at 14:50, wrote:
> On 24/08/16 08:44, Jan Beulich wrote:
>> --- a/xen/arch/arm/device.c
>> +++ b/xen/arch/arm/device.c
>> @@ -21,8 +21,8 @@
>> #include
>> #include
>>
>> -extern const struct device_desc _sdevice[], _edevice[];
>> -extern const struct acpi_device_desc _asdevice[
Hi Jan,
On 30/08/16 14:09, Jan Beulich wrote:
On 30.08.16 at 14:50, wrote:
On 24/08/16 08:44, Jan Beulich wrote:
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -21,8 +21,8 @@
#include
#include
-extern const struct device_desc _sdevice[], _edevice[];
-extern const struct acpi_
On Tue, Aug 30, 2016 at 01:54:17PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2 1/2] tools: remove blktap2 related code and
> documentation"):
> > Blktap2 is effectively dead code for a few years.
> >
> > Notable changes in this patch:
> >
> > 0. Unhook blktap2 from build system
> > 1.
On Tue, Aug 30, 2016 at 01:01:30PM +0100, Wei Liu wrote:
> The cbz instruction has range limitation. When compiled with gcov
> support the object is larger so cbz can't handle that anymore. The error
> message is like:
>
> aarch64-linux-gnu-ld-EL -T xen.lds -N prelink.o \
> /local/work/xe
On Tue, Aug 30, 2016 at 01:57:06PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 3/4] xen: fix gcov compilation"):
> > Currently enabling gcov in hypervisor won't build because although
> > 26c9d03d ("gcov: Adding support for coverage information") claimed that
> > %.init.o files were exclude
On Tue, Aug 30, 2016 at 01:51:33PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: update flex output files"):
> > Libxl ships output files from flex (libxlu_*_l.{c,h}). We use the flex
> > shipped in Debian to generate those files. Debian just patched their
> > flex (DSA 3653-1) to fix
On Tue, Aug 30, 2016 at 01:52:40PM +0200, Juergen Gross wrote:
> Mini-OS apps need to be compiled with the appropriate config settings
> of Mini-OS, as there are various dependencies on those settings in
> header files included by the apps.
>
> Enhance stubdom Makefile to set the appropriate CPPFL
On Tue, Aug 30, 2016 at 01:51:21PM +0200, Juergen Gross wrote:
> Mini-OS is currently setting __XEN_INTERFACE_VERSION__ to a rather
> ancient version.
>
> To be able to use a more recent variant garnt_entry_t must be changed
> to grant_entry_v1_t. In balloon.c we omit initializing elements of
> st
On Tue, Aug 30, 2016 at 01:51:22PM +0200, Juergen Gross wrote:
> Provide non-inline variants of the local_irq_*() functions for Mini-OS
> apps which should not depend on Mini-OS configuration.
>
I think it would be worth pointing out which apps need to access such
low level functionalities in com
On Tue, Aug 30, 2016 at 01:51:23PM +0200, Juergen Gross wrote:
> Mini-OS applications being compiled using Mini-OS headers without
> being integrated in the make environment of Mini-OS need a way to set
> CONFIG_* defines according to their Mini-OS configuration.
>
> Add a new make target "config"
On 08/30/2016 01:30 PM, Jan Beulich wrote:
On 30.08.16 at 14:08, wrote:
>> On 08/29/2016 10:36 AM, Jan Beulich wrote:
>> On 26.08.16 at 17:11, wrote:
On 08/25/2016 11:06 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> - Change init_tsctimer to skip all the te
On 30/08/16 15:52, Wei Liu wrote:
> On Tue, Aug 30, 2016 at 01:52:40PM +0200, Juergen Gross wrote:
>> Mini-OS apps need to be compiled with the appropriate config settings
>> of Mini-OS, as there are various dependencies on those settings in
>> header files included by the apps.
>>
>> Enhance stubd
On 30/08/16 15:54, Wei Liu wrote:
> On Tue, Aug 30, 2016 at 01:51:22PM +0200, Juergen Gross wrote:
>> Provide non-inline variants of the local_irq_*() functions for Mini-OS
>> apps which should not depend on Mini-OS configuration.
>>
>
> I think it would be worth pointing out which apps need to ac
On 08/30/2016 01:45 PM, Jan Beulich wrote:
On 30.08.16 at 14:26, wrote:
>> On 08/29/2016 11:06 AM, Jan Beulich wrote:
>> On 26.08.16 at 17:44, wrote:
On 08/25/2016 11:37 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> This patch proposes relying on host TSC sync
On Mon, Aug 22, 2016 at 04:10:04AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43, wrote:
> > The final goal is xen.efi binary file which could be loaded by EFI
> > loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> > multiboot2 protocol. This way we will have:
> > - sma
On 08/30/2016 01:05 PM, Jan Beulich wrote:
On 30.08.16 at 11:46, wrote:
>> On 08/30/2016 12:15 PM, Jan Beulich wrote:
>>> Within compat_memory_op() this needs to be placed in the first switch()
>>> statement, or it ends up being dead code (as that first switch() has a
>>> default case chainin
On Thu, Aug 25, 2016 at 05:21:24AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43, wrote:
> > Its visibility is not needed and just pollute symbol table.
> >
> > Suggested-by: Jan Beulich
> > Signed-off-by: Daniel Kiper
>
> With Andrew effectively having NAK-ed v4 of this patch, I don't se
On Thu, Aug 25, 2016 at 05:34:31AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43, wrote:
> > Create generic alloc and copy functions. We need
> > separate tools for memory allocation and copy to
> > provide multiboot2 protocol support.
> >
> > Signed-off-by: Daniel Kiper
>
> The amount of
On 08/29/2016 08:12 PM, Sanghyun Hong wrote:
> Hi Boris,
>
> /[Appreciate for your support, and I have one last question]/
>
> Since we’re using the */Xen/* hypervisor (not the KVM that is
> type-II), I think we cannot use the /*perf k*/*/vm/* command. Here are
> the outputs:
>
>
> # pe
flight 100661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100661/
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 Thu, Aug 25, 2016 at 05:50:04AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43, wrote:
> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> > +if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
> > +break;
> > +
> > +mbi_out->flags |= MBI_MEMMA
On 29/08/16 17:03, Seth Forshee wrote:
> Mounting proc in user namespace containers fails if the xenbus
> filesystem is mounted on /proc/xen because this directory fails
> the "permanently empty" test. proc_create_mount_point() exists
> specifically to create such mountpoints in proc but is current
Mini-OS apps need to be compiled with the appropriate config settings
of Mini-OS, as there are various dependencies on those settings in
header files included by the apps.
Enhance stubdom Makefile to set the appropriate CPPFLAGS when calling
the apps' make.
Signed-off-by: Juergen Gross
---
V2: a
On 29/08/16 16:03, Seth Forshee wrote:
> Mounting proc in user namespace containers fails if the xenbus
> filesystem is mounted on /proc/xen because this directory fails
> the "permanently empty" test. proc_create_mount_point() exists
> specifically to create such mountpoints in proc but is current
On Tue, Aug 30, 2016 at 04:48:08PM +0200, Juergen Gross wrote:
> On 29/08/16 17:03, Seth Forshee wrote:
> > Mounting proc in user namespace containers fails if the xenbus
> > filesystem is mounted on /proc/xen because this directory fails
> > the "permanently empty" test. proc_create_mount_point()
On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote:
> On 29/08/16 16:03, Seth Forshee wrote:
> > Mounting proc in user namespace containers fails if the xenbus
> > filesystem is mounted on /proc/xen because this directory fails
> > the "permanently empty" test. proc_create_mount_point() e
>>> On 30.08.16 at 16:15, wrote:
> On Mon, Aug 22, 2016 at 04:10:04AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > The final goal is xen.efi binary file which could be loaded by EFI
>> > loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
>> > multiboot2 prot
>>> On 30.08.16 at 16:32, wrote:
> On Thu, Aug 25, 2016 at 05:34:31AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > Create generic alloc and copy functions. We need
>> > separate tools for memory allocation and copy to
>> > provide multiboot2 protocol support.
>> >
>> > Signe
On 30/08/16 16:10, Seth Forshee wrote:
> On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote:
>> On 29/08/16 16:03, Seth Forshee wrote:
>>> Mounting proc in user namespace containers fails if the xenbus
>>> filesystem is mounted on /proc/xen because this directory fails
>>> the "permanentl
>>> On 30.08.16 at 16:41, wrote:
> On Thu, Aug 25, 2016 at 05:50:04AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > +case MULTIBOOT2_TAG_TYPE_MMAP:
>> > +if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
>> > +break;
>> > +
>>
>>> On 30.08.16 at 15:18, wrote:
> On 30/08/16 14:09, Jan Beulich wrote:
> On 30.08.16 at 14:50, wrote:
>>> If you want to add it, it should be a separate patch and we should go
>>> further by removing the section in the linker script.
>>
>> While I don't think this needs to be broken out, it
Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modu
>>> On 30.08.16 at 16:27, wrote:
> On Thu, Aug 25, 2016 at 05:21:24AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > Its visibility is not needed and just pollute symbol table.
>> >
>> > Suggested-by: Jan Beulich
>> > Signed-off-by: Daniel Kiper
>>
>> With Andrew effectively
As I said, this works for me for Xen guests. I thought perf kvm might
check whether there is a KVM guest but it's not. The error message that
you see is generated at the end of sampling if no samples are found.
Oh, I see. I tried the same command and check the contents of the perf.data.kvm
file,
On 30/08/16 16:15, Jan Beulich wrote:
On 30.08.16 at 15:18, wrote:
On 30/08/16 14:09, Jan Beulich wrote:
On 30.08.16 at 14:50, wrote:
If you want to add it, it should be a separate patch and we should go
further by removing the section in the linker script.
While I don't think this needs
On Thu, Aug 11, 2016 at 05:17:56PM +0100, Ian Jackson wrote:
> Running XTF in osstest is likely to produce failures where multiple
> steps fail interestingly. We would like to prefer to report, and
> bisect, earlier steps.
>
> This series does that.
>
> Wei, NB, this has a conflict with the XTF
On 08/30/2016 11:22 AM, Sanghyun Hong wrote:
>> As I said, this works for me for Xen guests. I thought perf kvm might
>> check whether there is a KVM guest but it's not. The error message that
>> you see is generated at the end of sampling if no samples are found.
>
> Oh, I see. I tried the same co
Wei Liu writes ("Re: [OSSTEST PATCH 0/7] Apropos of XTF: Improve failed step
selection"):
> The rebased patch is as followed, please check.
Acked-by: Ian Jackson
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xe
On 30/08/16 17:00, Wei Liu wrote:
> On Thu, Aug 11, 2016 at 05:17:56PM +0100, Ian Jackson wrote:
>> Running XTF in osstest is likely to produce failures where multiple
>> steps fail interestingly. We would like to prefer to report, and
>> bisect, earlier steps.
>>
>> This series does that.
>>
>> W
On 05/07/16 16:55, Stefano Stabellini wrote:
> On Wed, 29 Jun 2016, Anthony PERARD wrote:
>> On Wed, Jun 29, 2016 at 05:50:48PM +0200, Juergen Gross wrote:
>>> The qdisk implementation is using the native xenbus protocol only in
>>> case of no protocol specified at all. As using the explicit 32- or
>>> On 19.08.16 at 09:52, wrote:
> Page tables get pre-populated with physical addresses which, due to
> living inside the Xen image, will never exceed 32 bits in width. That
> in turn results in the tool generating the relocations to produce
> 32-bit relocations for them instead of the 64-bit one
flight 100660 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100660/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100611
test-amd64-amd64-xl-rtds
On 19/08/16 13:57, Jan Beulich wrote:
On 19.08.16 at 14:39, wrote:
>> On 19/08/16 08:52, Jan Beulich wrote:
>>> Page tables get pre-populated with physical addresses which, due to
>>> living inside the Xen image, will never exceed 32 bits in width. That
>>> in turn results in the tool generat
Hi Shannon,
On 30/08/16 02:21, Shannon Zhao wrote:
On 2016/8/30 2:05, Julien Grall wrote:
Hi Shannon,
On 25/08/2016 04:05, Shannon Zhao wrote:
On 2016/8/24 20:52, Wei Liu wrote:
On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
From: Shannon Zhao
Construct ACPI RSDP table
flight 100662 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100662/
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
1 - 100 of 128 matches
Mail list logo
