On 12.02.2016 19:05, Konrad Rzeszutek Wilk wrote:
> From: Ross Lagerwall
>
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/Ma
Hi Wei,
On 15/02/16 14:44, Wei Liu wrote:
> On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
>> On 15/02/16 14:16, Wei Liu wrote:
>>> On Mon, Feb 15, 2016 at 09:07:13AM +, Paul Durrant wrote:
>
>>> [...]
> # Option 2: Invent a xen-9p device
>
> Another way of doin
On March 04, 2016 9:59pm, wrote:
> On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote:
> > On March 04, 2016 5:29pm, wrote:
> > > On March 04, 2016 7:59am, wrote:
> > >
> > > > Also I'd highlight the below modification:
> > > > -if ( !spin_trylock(&pcidevs_lock) )
> > > > -return -ERE
flight 85573 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85573/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 85382
test-amd64-i386-xl-qemuu-win
flight 85550 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85550/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
flight 85533 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85533/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 85380
build-amd64-rumpuserxen
Dario,
Thank you very much for the help. I apologize for the HTML output on
the first email, I thought I had outlook set to send it in plain text.
My mistake.
> Well, in this other thread, Paul (Cc-ed) says he basically has tracing
> working on ARM:
> http://lists.xenproject.org/archives/html/
On 03/05/2016 01:22 AM, Ian Jackson wrote:
>> --- a/docs/man/xl.pod.1
>> +++ b/docs/man/xl.pod.1
> ...
>> + COLO support in xl is still in experimental (proof-of-concept) phase.
>> + There is no support for network or disk at the moment.
>
> I think you need to spell out the lack of storag
On 03/05/2016 01:18 AM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 17/27] libxc/save: support COLO save"):
>> From: Wen Congyang
>>
>> After suspend primary vm, get dirty bitmap on secondary vm,
>> and send pages both dirty on primary/secondary to secondary.
>
> This patch again seems
On 03/05/2016 01:14 AM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 15/27] primary vm suspend/resume/checkpoint
> code"):
>> From: Wen Congyang
>
> I would look at this on the same basis as the previous patch.
>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_interna
On 03/05/2016 01:11 AM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 14/27] secondary vm
> suspend/resume/checkpoint code"):
>> From: Wen Congyang
>>
>> Secondary vm is running in colo mode. So we will do
>> the following things again and again:
>
> I don't propose to review this in de
This run is configured for baseline tests only.
flight 44227 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debi
On 03/05/2016 04:23 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 04, 2016 at 05:03:16PM +, Ian Jackson wrote:
>> Changlong Xie writes ("[PATCH v11 12/27] tools/libx{l,c}: introduce
>> wait_checkpoint callback"):
>>> From: Wen Congyang
>>>
>>> Under COLO, we are doing checkpoint on demand, i
On 03/05/2016 01:00 AM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 10/27] tools/libxl: add back channel
> support to write stream"):
>> From: Wen Congyang
>>
>> Add back channel support to write stream. If the write stream is
>> a back channel stream, this means the write stream is us
On 03/05/2016 04:30 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 04, 2016 at 05:52:09PM +, Ian Jackson wrote:
>> Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
>>> +Enable COLO HA for disk. For better understanding block replication on
>>> +QEMU, please refer to:
On 03/05/2016 01:44 AM, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
>> From: Wen Congyang
>>
>> Usage: disk =
>> ['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
>> For QEMU block replication details:
flight 85519 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85519/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pygrub 9 debian-di-install fail in 85360 pass in 85519
test-amd64-i386-xl-qemuu-win7-a
On 03/05/2016 09:51 AM, Yu-An(Victor) Chen wrote:
> Hi Congyang,
>
> Thanks for your reply,
>
> even with your script, and I modify the "path_to_xen_source" to point where
> my xen directory is. I still got this error.
>
> ERROR: User requested feature xen
>configure was not able to fin
flight 85509 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
flight 85493 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85493/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 82793
test-amd64-i386-xl-qemuu-win7-a
This run is configured for baseline tests only.
flight 44226 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44226/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 14 capture-logs/l1(
Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
to independently get and set the scheduling parameters of each
vCPU of a domain
Signed-off-by: Chong Li
Signed-off-by: Meng Xu
Signed-off-by: Sisu Xi
---
Changes on PATCH v5:
1) When processing XEN_DOMCTL_SCHEDOP_get/putvcpuinfo, w
Change main_sched_rtds and related output functions to support
per-VCPU settings.
Signed-off-by: Chong Li
Signed-off-by: Meng Xu
Signed-off-by: Sisu Xi
---
Changes on PATCH v5:
1) Add sched_vcpu_set_all() for the cases that all vcpus of a
domain need to be changed together.
Changes on PATCH v
Add xc_sched_rtds_vcpu_get/set functions to interact with
Xen to get/set a domain's per-VCPU parameters.
Signed-off-by: Chong Li
Signed-off-by: Meng Xu
Signed-off-by: Sisu Xi
---
Changes on PATCH v5:
1) In xc_sched_rtds_vcpu_get/set, re-issueing the hypercall
if it is preempted.
Changes on PA
Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
functions to support per-VCPU settings.
Signed-off-by: Chong Li
Signed-off-by: Meng Xu
Signed-off-by: Sisu Xi
---
Changes on PATCH v5:
1) Add a seperate function, sched_rtds_vcpus_params_set_all(), to set
the parameters of all vcp
[Goal]
The current xl sched-rtds tool can only set the VCPUs of a domain
to the same parameter although the scheduler supports VCPUs with
different parameters. This patchset is to enable xl sched-rtds
tool to configure the VCPUs of a domain with different parameters.
This per-VCPU settings can
flight 85494 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
This run is configured for baseline tests only.
flight 44225 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44225/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-build
flight 85479 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
build-armhf
flight 85470 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
Hello,
Assuming I set v->arch.hvm_vmx.exec_control |=
CPU_BASED_MONITOR_TRAP_FLAG; in hvm_do_resume(), would that cause a
VMEXIT with EXIT_REASON_MONITOR_TRAP_FLAG _before_ the instruction at he
current rIP runs, or _after_ it?
A few tests I've ran suggest that the VMEXIT occurs _before_, i.e. th
flight 85551 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85551/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 1bd52e1fd66c47af690124d74d11ccb271c96f6b
baseline version:
xen abf8824fe530bcf060
flight 85429 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
33 matches
Mail list logo
