flight 64270 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 63449
build-i386-prev
Hi,alls
As we know,xen 4+ maintains a dirty bitmap. Snapshot or migration will
use this bitmap. When the guest domain changes the memory page， VMM can
capture it and set dirty bitmap to 1.
But I can't know how VMM to maintain this dirty bitmap. Under what
circumstances VMM will set the di
flight 64277 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail in 64056
REGR. vs. 63532
Tests
On 15/11/15 00:14, Atom2 wrote:
>
>> Right - it would appear that the USE flag is definitely not what you
>> wanted, and causes bad compilation for Xen. The do_IRQ disassembly
>> you sent is a the result of disassembling a whole block of zeroes.
>> Sorry for leading you on a goose chase - the dou
flight 64281 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64281/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684
test-amd64
On Nov 13, 2015 5:23 PM, "Boris Ostrovsky" wrote:
>
>
>
> On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
>>
>> On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
>> wrote:
>>>
>>> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
>>> ("x86/entry/32: Re-implement SYSENTER usin
flight 64291 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
On 11/14/15 6:14 PM, Atom2 wrote:
> Am 14.11.15 um 21:32 schrieb Andrew Cooper:
>> On 14/11/2015 00:16, Atom2 wrote:
>>> Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
>> Am 12.11.15 um 17:43 schrieb Andrew Cooper:
>
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://g
flight 64287 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs.
63212
Regression
flight 64294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64294/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf a2e619821a791de5cd65cd2c757de0a8aa7f138c
baseline version:
ovmf 0c9a522f28772049ae37c85b8ae589a98d2
flight 64290 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64290/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail like 64095
Tests which did not succeed,
Am 15.11.15 um 16:12 schrieb Andrew Cooper:
[big snip]
Great - so confirms the issue as a SeaBIOS interaction issue, rather
than a hypervisor regression.
As I said before, I am still certain that a guest should not be able
to get itself into the crashing state (short of a hardware errata), so
flight 64293 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Tests which are failin
Am 15.11.15 um 21:12 schrieb Doug Goldstein:
On 11/14/15 6:14 PM, Atom2 wrote:
Am 14.11.15 um 21:32 schrieb Andrew Cooper:
On 14/11/2015 00:16, Atom2 wrote:
Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 s
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 13, 2015 6:29 PM
> To: Hu, Robert
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26]
This run is configured for baseline tests only.
flight 38279 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38279/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf a2e619821a791de5cd65cd2c757de0a8aa7f138c
baseline version:
ovm
This run is configured for baseline tests only.
flight 38278 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build
On 02/11/15 06:51, Juergen Gross wrote:
> The Xen hypervisor supports starting a dom0 with large memory (up to
> the TB range) by not including the initrd and p2m list in the initial
> kernel mapping. Especially the p2m list can grow larger than the
> available virtual space in the initial mapping.
Hi all:
I'd like to SLEEP a while in xen kernel during VMEXIT, the easiest way is to
call "udelay" or "mdelay" there. However, these 2 functions use busy wait to
sleep, which is a waste.
In linux kernel, there's a function named 'schedule_timeout', allowing the
CPU to run other tasks durin
Sorry for delay. Just this patch series is more difficult to review for me
but I'm definitely not ignoring it. I'll try to get to it this week
Le 16 nov. 2015 6:47 AM, "Juergen Gross" a écrit :
> On 02/11/15 06:51, Juergen Gross wrote:
> > The Xen hypervisor supports starting a dom0 with large me
21 matches
Mail list logo
