>>> On 08.08.16 at 19:00, wrote:
> On 08/08/2016 11:54 AM, Jan Beulich wrote:
> On 08.08.16 at 17:28, wrote:
>>> On 08/08/2016 11:10 AM, Jan Beulich wrote:
>>> On 08.08.16 at 16:10, wrote:
> On 08/08/2016 09:56 AM, Jan Beulich wrote:
> On 08.08.16 at 15:41, wrote:
>>> Wh
On 08/09/16 02:56, Tamas K Lengyel wrote:
> From: Tamas K Lengyel
>
> Use __get_gfn_type_access instead of get_gfn_type_access when checking
> the hostp2m entries during altp2m mem_access setting and gfn remapping
> to avoid a lock conflict which can make dom0 freeze.
>
> Signed-off-by: Tamas K
flight 100348 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100348/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100326
build-amd64-rumpuserxen
On Tue, Aug 09, 2016 at 12:18:57AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> Over the last couple of months in my spare time I was playing
> with making livepatch work with ARM64 (using the FoundationModel
> simulator) and I finally got it working tonight.
The git tree is
git://xenbits.xen.
The initial support for ARM64 - and livepatching
works:
(XEN) livepatch: xen_hello_world: Applying 1 functions
(XEN) hi_func: Hi! (called 1 times)
(XEN) Hook executing.
(XEN) livepatch: xen_hello_world finished APPLY with rc=0
(XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0)
(XE
Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.
Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked down and assumed to be .ro=0, nx=1.
Livepatch needs .nx=0 and a
We copied from Linux code (v4.7) the code that generates
the unconditional branch instructions. This is mostly
from Linux commit c0cafbae20d2878883ec3c06d6ea30ff38a6bf92
"arm64: introduce aarch64_insn_gen_branch_reg()"
However the branch-link instructions was omitted, only
the branch instruction i
Hey!
Over the last couple of months in my spare time I was playing
with making livepatch work with ARM64 (using the FoundationModel
simulator) and I finally got it working tonight.
Sending out the patches just in case they don't work tomorrow :-)
The ARM32 part is going slowly - as I don't have
On Mon, Aug 08, 2016 at 05:05:39PM +0200, Luis R. Rodriguez wrote:
> > So how can I disable those table-* things from even getting built? Avoid
> > using table-y? But then everything declared table-y will be built
> > unconditionally. I don't think I like that. :-\
>
> I suppose we could make this
This run is configured for baseline tests only.
flight 66942 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66942/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7989300df75f274203d74266811089aaa11b517c
baseline v
This run is configured for baseline tests only.
flight 66941 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66941/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
flight 100338 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100338/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 99752
test-armhf-armhf-xl-rtds
From: Tamas K Lengyel
Use __get_gfn_type_access instead of get_gfn_type_access when checking
the hostp2m entries during altp2m mem_access setting and gfn remapping
to avoid a lock conflict which can make dom0 freeze.
Signed-off-by: Tamas K Lengyel
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: And
Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropri
On 08/08/2016 19:54, Trammell Hudson wrote:
> This is in reply to an ancient post to the xen-devel list:
>
> http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/
> http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-08/msg00298.html
>
> Ward Vandewege wrote (in 2008):
On 08/08/2016 21:35, Alina wrote:
> Hello,
>
> When I try to enable shadow page table features using the shadow_control
> function, I get this message in the hypervisor logs: "Tried to do a paging
> op on itself". After backtracking to the source of this message, I
> discovered it comes from the co
flight 100350 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100350/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7989300df75f274203d74266811089aaa11b517c
baseline version:
ovmf f4c6c0fdb61b0e9198d91
> On 8 Aug 2016, at 15:04, Ian Jackson wrote:
>
> Lars Kurth writes ("Re: Proposed plan and URL name for new VM to download xen
> tarballs (ftp.xenproject.org)"):
>> I don't mind. I can ask Credativ whether that is doable from a load
>> perspective. But the answer is probably yes.
>
> If it i
flight 100334 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100334/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 100310 pass in 100334
test-amd64-amd64-xl-xsm 3
On Mon, 8 Aug 2016 13:35:42 -0700 (MST) Alina wrote:
> When I try to enable shadow page table features using the shadow_control
> function, I get this message in the hypervisor logs: "Tried to do a paging
> op on itself". After backtracking to the source of this message, I
> discovered it comes fro
Hello,
> When I try to enable shadow page table features using the shadow_control
> function, I get this message in the hypervisor logs: "Tried to do a paging
> op on itself". After backtracking to the source of this message, I
> discovered it comes from the condition: "if ( unlikely(d == current-
Hello,
When I try to enable shadow page table features using the shadow_control
function, I get this message in the hypervisor logs: "Tried to do a paging
op on itself". After backtracking to the source of this message, I
discovered it comes from the condition: "if ( unlikely(d == current->domain)
This run is configured for baseline tests only.
flight 66940 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66940/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4c6c0fdb61b0e9198d919cb4056b2961758e3fd
baseline v
flight 100329 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100329/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 99902
test-amd64-amd6
On Mon, 8 Aug 2016, Peng Fan wrote:
> ...
> :0:0: error: "__OBJECT_FILE__" redefined [-Werror]
> :0:0: note: this is the location of the previous definition
> cc1: all warnings being treated as errors
>
> ...
>
> Does this patch work when cross compile for ARM64?
I dropped that patch following su
On Mon, Aug 08, 2016 at 07:02:25PM +, Trammell Hudson wrote:
> The xen/arch/x86/boot/mkelf32 executable is preventing Xen hypervisors
> from being reproducibly built. It is using an uninitialized stack
> buffer for padding after the ehdr and phdr are written to the xen file,
> which leads to n
The xen/arch/x86/boot/mkelf32 executable is preventing Xen hypervisors
from being reproducibly built. It is using an uninitialized stack
buffer for padding after the ehdr and phdr are written to the xen file,
which leads to non-deterministic bytes in the binary.
Additionally, the file is then com
This is in reply to an ancient post to the xen-devel list:
http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/
http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-08/msg00298.html
Ward Vandewege wrote (in 2008):
> There seems to be a regression with regard to kexe
flight 100349 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100349/
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
flight 100340 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100340/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4c6c0fdb61b0e9198d919cb4056b2961758e3fd
baseline version:
ovmf 74bbe31b8d485da26ec7f
On Mon, Aug 8, 2016 at 10:29 AM, Razvan Cojocaru
wrote:
> On 08/08/16 18:52, Tamas K Lengyel wrote:
>>> I think the issue might be that vm_event_vcpu_pause() uses
>>> > vcpu_pause_nosync(), and it's being used everywhere we pause the VCPU in
>>> > the course of sending out a vm_event.
>>> >
>>> >
On 08/08/16 16:45, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 0/3] tools: support autoballooning of xenstore
> domain"):
>> Support xenstore domain autoballooning by:
>> - adding --maxmem parameter to init-xenstore-domain
>> - build xenstore stubdom with Mini-OS CONFIG_BALLOON set
>> - add
hi all,
is there any difference for a raw image vm save/restore vs an LVM vm
save/restore?
the case is the LVM one won’t work after restore due to the hang_up_task error
but the raw img is working properly.
If someone used LVM save/restore and didn’t get any error please let me know,
or it's
On 08/08/16 10:54, George Dunlap wrote:
Rather than have large fixed-size buffers, start with smaller buffers
and allow them to grow as needed (doubling each time), with a fairly
large maximum. Allow this maximum to be set by a command-line
parameter.
Signed-off-by: George Dunlap
---
CC: Ian J
Ian Jackson writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re:
[PATCH 0/2] xtf: add launcher (+1 bugfix)"):
> With my xenbits admin hat on I therefore intend to:
>
> * Create xtf.git in the xenbits toplevel
>and give it the appropriate permissions
I created a group `xtf-commi
On 08/08/2016 11:54 AM, Jan Beulich wrote:
On 08.08.16 at 17:28, wrote:
>> On 08/08/2016 11:10 AM, Jan Beulich wrote:
>> On 08.08.16 at 16:10, wrote:
On 08/08/2016 09:56 AM, Jan Beulich wrote:
On 08.08.16 at 15:41, wrote:
>> While AMD APM suggests that reserved MSR bit
Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to
cope with relative path"):
> On 08/08/16 17:24, Ian Jackson wrote:
> > My example was disk images.
>
> I fail to see why any question of disk image is relevant here.
It is relevant because we want a coherent answer to "
On Mon, Aug 08, 2016 at 05:26:16PM +0100, Andrew Cooper wrote:
> On 08/08/16 17:21, Wei Liu wrote:
> > On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build
> >> job for 4.8 onwards"):
> >>> Signed-off-by: Wei L
Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH RFC v2 11/14] Introduce
ts-xtf-run"):
> On 08/08/16 10:22, Wei Liu wrote:
...
> > The script may exit early if it detects the test host is down or
> > xtf-runner returns non-recognisable exit code.
>
> What is OSSTests general approach to reco
flight 100346 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100346/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100341
Tests which
On 08/08/16 18:52, Tamas K Lengyel wrote:
>> I think the issue might be that vm_event_vcpu_pause() uses
>> > vcpu_pause_nosync(), and it's being used everywhere we pause the VCPU in
>> > the course of sending out a vm_event.
>> >
>> > So this creates the premise for a race condition: either some mo
On 08/08/16 17:24, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to
> cope with relative path"):
>> On 08/08/16 17:09, Ian Jackson wrote:
>>> Discuss what should happen when the domain is subsequently migrated.
>>> (4 marks)
>> No change.
>>
>> In b
>>> On 12.07.16 at 11:02, wrote:
> @@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type(
> if ( rc )
> goto out;
>
> +if ( t == p2m_ram_rw && memtype[a.hvmmem_type] == p2m_ioreq_server )
> +p2m->ioreq.entry_count++;
> +
> +if ( t == p2m_ioreq_ser
On 08/08/16 10:22, Wei Liu wrote:
> This is the main script for running XTF. It will first perform
> selftest, and then run each XTF test case as a substep.
>
> It does the following things:
>
> 1. Run self tests for individual environment and record the result.
> 2. Collect tests according to ava
flight 100326 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100326/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops3 host-install(3) broken in 7 REGR. vs. 100326
build-i386-rumpuse
On 08/08/16 17:21, Wei Liu wrote:
> On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build
>> job for 4.8 onwards"):
>>> Signed-off-by: Wei Liu
>> FAOD I am expecting xtf to be useable for older branches by the ti
Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to
cope with relative path"):
> On 08/08/16 17:09, Ian Jackson wrote:
> > Discuss what should happen when the domain is subsequently migrated.
> > (4 marks)
>
> No change.
>
> In both of these cases, they are boot-time art
On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build
> job for 4.8 onwards"):
> > Signed-off-by: Wei Liu
>
> FAOD I am expecting xtf to be useable for older branches by the time
> this patch series is non-RFC.
>
On 08/08/16 17:09, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to
> cope with relative path"):
>> The important bit which XTF and regular users want is relative to the
>> .cfg file, rather than $CWD.
> Consider:
>
> cd /root/foo
> xl create di
Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to
cope with relative path"):
> The important bit which XTF and regular users want is relative to the
> .cfg file, rather than $CWD.
Consider:
cd /root/foo
xl create dir/vm1/vm1.cfg
cd /root/bar
xl block-attach vm
On 08/08/16 16:15, Jan Beulich wrote:
On 08.08.16 at 16:10, wrote:
>> On 08/08/16 15:01, Jan Beulich wrote:
>> On 08.08.16 at 15:42, wrote:
On 05/08/16 16:35, Jan Beulich wrote:
On 04.08.16 at 17:49, wrote:
>> In general, the hooks provide flexibility when having to de
On 08/08/16 16:49, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope
> with relative path"):
>> On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote:
>>> Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope
>>> with relative
>>> On 08.08.16 at 17:28, wrote:
> On 08/08/2016 11:10 AM, Jan Beulich wrote:
> On 08.08.16 at 16:10, wrote:
>>> On 08/08/2016 09:56 AM, Jan Beulich wrote:
>>> On 08.08.16 at 15:41, wrote:
> While AMD APM suggests that reserved MSR bits are not supposed to be
> touched, it is not
On Mon, Aug 8, 2016 at 9:10 AM, Razvan Cojocaru
wrote:
> On 08/08/2016 03:47 PM, Razvan Cojocaru wrote:
>> On 08/08/2016 03:01 PM, Andrew Cooper wrote:
>>> On 08/08/16 11:31, Razvan Cojocaru wrote:
Hello,
We've been mostly setting registers by using xc_vcpu_setcontext():
h
Wei Liu writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope
with relative path"):
> On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope
> > with relative path"):
> > > And also document that optio
>>> On 12.07.16 at 11:02, wrote:
> @@ -178,8 +179,34 @@ static int hvmemul_do_io(
> break;
> case X86EMUL_UNHANDLEABLE:
> {
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, &p);
> +struct hvm_ioreq_server *s;
> +
> +if
On 08/08/2016 11:10 AM, Jan Beulich wrote:
On 08.08.16 at 16:10, wrote:
>> On 08/08/2016 09:56 AM, Jan Beulich wrote:
>> On 08.08.16 at 15:41, wrote:
While AMD APM suggests that reserved MSR bits are not supposed to be
touched, it is not clear how (or whether) HW enforces this
On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope with
> relative path"):
> > And also document that option in xl.cfg(5).
> ...
> > -Select the virtual firmware that is exposed to the guest.
> > +Select the virtua
>>> On 08.08.16 at 16:10, wrote:
> On 08/08/16 15:01, Jan Beulich wrote:
> On 08.08.16 at 15:42, wrote:
>>> On 05/08/16 16:35, Jan Beulich wrote:
>>> On 04.08.16 at 17:49, wrote:
> In general, the hooks provide flexibility when having to deal with
> unforeseen cases, but their ap
On 08/08/2016 10:09 AM, Jan Beulich wrote:
>> The reserved bits look the same on all supported families --- bits
>> 63:42, 39:36, 21 and 19. Except apparently on family 12h bit 19 is MBZ.
> Isn't MBZ == reserved for all practical purposes?
My understanding is that when something is MBZ we know we
>>> On 08.08.16 at 17:05, wrote:
> On 08/08/2016 10:09 AM, Jan Beulich wrote:
>>> The reserved bits look the same on all supported families --- bits
>>> 63:42, 39:36, 21 and 19. Except apparently on family 12h bit 19 is MBZ.
>> Isn't MBZ == reserved for all practical purposes?
>
> My understandi
On Mon, Aug 08, 2016 at 04:10:11PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: fix declaration of
> libxl_primary_console_exec_0x040700"):
> > Add missing "int".
>
> Ooops!
>
> Acked-by: Ian Jackson
Thanks. I will push it soon.
___
X
>>> On 08.08.16 at 16:10, wrote:
> On 08/08/2016 09:56 AM, Jan Beulich wrote:
> On 08.08.16 at 15:41, wrote:
>>> While AMD APM suggests that reserved MSR bits are not supposed to be
>>> touched, it is not clear how (or whether) HW enforces this for PMU
>>> registers. At least on some family 1
Wei Liu writes ("[PATCH] libxl: fix declaration of
libxl_primary_console_exec_0x040700"):
> Add missing "int".
Ooops!
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope with
relative path"):
> And also document that option in xl.cfg(5).
...
> -Select the virtual firmware that is exposed to the guest.
> +Select the virtual bios that is exposed to the guest.
> By default, a guess is made based
On 08/08/2016 03:47 PM, Razvan Cojocaru wrote:
> On 08/08/2016 03:01 PM, Andrew Cooper wrote:
>> On 08/08/16 11:31, Razvan Cojocaru wrote:
>>> Hello,
>>>
>>> We've been mostly setting registers by using xc_vcpu_setcontext():
>>>
>>> https://github.com/razvan-cojocaru/libbdvmi/blob/master/src/bdvmix
On Fri, Jul 29, 2016 at 12:06:30PM +0200, Borislav Petkov wrote:
> On Fri, Jul 22, 2016 at 02:24:41PM -0700, Luis R. Rodriguez wrote:
> > A linker table is a data structure that is stitched together from items
> > in multiple object files. Linux has historically implicitly used linker
> > tables fo
Add missing "int".
Signed-off-by: Wei Liu
---
tools/libxl/libxl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 030aad5..ae21302 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1476,8 +1476,8 @@ static inlin
Wei Liu writes ("[OSSTEST PATCH RFC v2 13/14] make-flight: create 5 xtf jobs"):
> Create jobs only for x86 and set host flag diverse-xtf-x86.
I think I acked this one previously. Anyway,
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@list
Wei Liu writes ("[OSSTEST PATCH RFC v2 11/14] Introduce ts-xtf-run"):
> This is the main script for running XTF. It will first perform
> selftest, and then run each XTF test case as a substep.
...
> +# XTF results (runner returned numeric values) and OSStest results:
> +#
> +# SUCCESS(0) -> pass
Wei Liu writes ("[OSSTEST PATCH RFC v2 12/14] sg-run-job: test-xtf recipe"):
> Install XTF, run FEP test and then run all available tests.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Wei Liu writes ("[OSSTEST PATCH RFC v2 10/14] Introduce ts-xtf-fep"):
> Test the availability of FEP during runtime.
...
> +$output =~ m/^(\d+)$/ or die "$output ?";
> +
> +return $1;
> +}
> +
> +exit fep_test();
I think something in this script should log the exit status. Digging
the exi
Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job
for 4.8 onwards"):
> Signed-off-by: Wei Liu
FAOD I am expecting xtf to be useable for older branches by the time
this patch series is non-RFC.
Thanks,
Ian.
___
Xen-devel
Wei Liu writes ("[OSSTEST PATCH RFC v2 08/14] Introduce ts-xtf-install"):
> Extract XTF to the desire location.
^d
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Wei Liu writes ("[OSSTEST PATCH RFC v2 05/14] BuildSupport: move
buildcmd_stamped_logged here"):
> ... so that other build scripts can use it, too.
>
> It now accepts one more parameter called "component" to be useful in
> other build scripts.
Acked-by: Ian Jackson
Wei Liu writes ("[OSSTEST PATCH RFC v2 06/14] Introduce ts-xtf-build"):
> Clone, build and package XTF for later use.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi all,
a quick note that we now moved most of our websites to https:
For the following websites, no http sites are available
1) xenproject.org
There are a couple of known issues:
The documentation and mailing list pages contains a form to xen.markmail.org
which is not available as https site
Juergen Gross writes ("[PATCH 0/3] tools: support autoballooning of xenstore
domain"):
> Support xenstore domain autoballooning by:
> - adding --maxmem parameter to init-xenstore-domain
> - build xenstore stubdom with Mini-OS CONFIG_BALLOON set
> - add XENSTORE_MAX_DOMAIN_SIZE parameter to sysconf
Wei Liu writes ("[OSSTEST PATCH RFC v2 03/14] ap-common: add xtf tree"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Wei Liu writes ("[OSSTEST PATCH RFC v2 01/14] ts-xen-build: always compile in
FEP support"):
> By default FEP depends on debug flag. When we are near release the debug
> flag will be turned off. In order to test a release build, we explicitly
> enable FEP in build configuration.
Acked-by: Ian Jac
And also document that option in xl.cfg(5).
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Andrew Cooper
I suppose this should be able to make xtf free from absolute paths in
config files.
---
docs/man/xl.cfg.pod.5.in | 12 +++-
tools/libxl/libxl_dom.c | 11 +--
2 files chang
Hi,
On Fri, May 13, 2016 at 11:23:29AM -0400, Konrad Rzeszutek Wilk wrote:
>On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote:
>> On Fri, 13 May 2016, Jan Beulich wrote:
>>
>> > >>> On 13.05.16 at 15:49, wrote:
>> > > ...
>> > >
>> > > Still an issue - with 4.7.0-rc1.
>> >
>> > And I d
On Wed, Jul 27, Konrad Rzeszutek Wilk wrote:
> > Xen 4.7.20160704T103633.a492556-1.xen47
> > (XEN) Xen version 4.7.20160704T103633.a492556-1.xen47 (abuild@) (gcc (SUSE
> > Linux) 4.8.5) debug=n Mon Jul 4 12:36:33 UTC 2016
>
> Could you recompile it with debug=y?
Its attached, nothing special
On 08/08/2016 02:34 PM, Jan Beulich wrote:
On 08.08.16 at 10:06, wrote:
>> Allow guest userspace code to request that a vm_event be sent out
>> via VMCALL. This functionality seems to be handy for a number of
>> Xen developers, as stated on the mailing list (thread "[Xen-devel]
>> HVMOP_guest
flight 100344 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100341
Tests which
On 08/08/16 15:01, Jan Beulich wrote:
On 08.08.16 at 15:42, wrote:
>> On 05/08/16 16:35, Jan Beulich wrote:
>> On 04.08.16 at 17:49, wrote:
In general, the hooks provide flexibility when having to deal with
unforeseen cases, but their application should be rarely required (<
>>
On 08/08/2016 09:56 AM, Jan Beulich wrote:
On 08.08.16 at 15:41, wrote:
>> While AMD APM suggests that reserved MSR bits are not supposed to be
>> touched, it is not clear how (or whether) HW enforces this for PMU
>> registers. At least on some family 10h processors writes of these bits
>> ar
>>> On 08.08.16 at 16:06, wrote:
> On 08/08/2016 09:53 AM, Jan Beulich wrote:
> On 08.08.16 at 15:41, wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct cpu_user_regs
> *regs)
>>> {
>>>
>>> On 08.08.16 at 15:46, wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> I'm having, however, a hard time imagining a class 2 bug for any
>> of the hvmop-s that are being converted by the hvmctl series:
>> These act on the target domain, so would
On 08/08/2016 09:53 AM, Jan Beulich wrote:
On 08.08.16 at 15:41, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct cpu_user_regs
>> *regs)
>> {
>> vpmu_msr = 1;
>> case MS
Lars Kurth writes ("Re: Proposed plan and URL name for new VM to download xen
tarballs (ftp.xenproject.org)"):
> I don't mind. I can ask Credativ whether that is doable from a load
> perspective. But the answer is probably yes.
If it isn't doable then moving the release tarballs load elsewhere i
> On 8 Aug 2016, at 14:51, Ian Jackson wrote:
>
> Lars Kurth writes ("Proposed plan and URL name for new VM to download xen
> tarballs (ftp.xenproject.org)"):
>> To fix this, the current plan of record is to
>> - Copy existing tarballs to an existing or new VM
>> - To expose that VM via the new
>>> On 08.08.16 at 15:42, wrote:
> On 05/08/16 16:35, Jan Beulich wrote:
> On 04.08.16 at 17:49, wrote:
>>> In general, the hooks provide flexibility when having to deal with
>>> unforeseen cases, but their application should be rarely required (<
>>> 10%)."
>>
>> But the greater flexibility
>>> On 08.08.16 at 15:41, wrote:
> While AMD APM suggests that reserved MSR bits are not supposed to be
> touched, it is not clear how (or whether) HW enforces this for PMU
> registers. At least on some family 10h processors writes of these bits
> are apparently ignored: guests (such as Linux) ass
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> On 05.08.16 at 18:28, wrote:
> > That is, a bug of class 2 would allow the unprivileged qemu process in
> > dom0 to cause damage to other parts of dom0.
...
> Ah, okay, I think I finally understand. [...]
>
> I
>>> On 08.08.16 at 15:41, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct cpu_user_regs
> *regs)
> {
> vpmu_msr = 1;
> case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
>
Lars Kurth writes ("Proposed plan and URL name for new VM to download xen
tarballs (ftp.xenproject.org)"):
> To fix this, the current plan of record is to
> - Copy existing tarballs to an existing or new VM
> - To expose that VM via the new public URL ftp.xenproject.org (this is
> non-browsable,
flight 100331 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REGR. vs. 99955
test-armhf-armhf-libvir
On 08/08/2016 08:13 AM, Marek Marczykowski-Górecki wrote:
> Thanks for the explanation. What is the current state of HVMlite? I see
> "none" is valid value for "device_model_version" already, but if I try
> to start such guest, it fails at x86_compat call (tries to boot it as PV
> guest). I guess i
On 05/08/16 16:35, Jan Beulich wrote:
On 04.08.16 at 17:49, wrote:
>> In general, the hooks provide flexibility when having to deal with
>> unforeseen cases, but their application should be rarely required (<
>> 10%)."
>
> But the greater flexibility of course comes with increased chances
>
1 - 100 of 181 matches
Mail list logo
