[Xen-devel] [linux-3.10 test] 32624: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32624 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32624/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 26303

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail   like 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 linuxa472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linuxbe67db109090b17b56eb8eb2190cd70700f107aa


816 people touched revisions under test,
not listing them all


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-rumpuserxen-i386 pass

[Xen-devel] [linux-next test] 32623: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32623 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32623/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 32564
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 32564
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass

version targeted for testing:
 linuxf9f7b9d7aeedb0f6150bc9df08542c3a0b67a4ef
baseline version:
 linux97bf6af1f928216fd6c5a66e8a57bfa95a659672

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   fail
 test-amd64-i386-rumpuserxen-i386 pass
 test-amd64-amd64-xl-pc

[Xen-devel] [Testday]Xen 4.5 RC4

2014-12-24 Thread Hu, Robert 
Hi

This is test report on Xen 4.5 RC4, from Intel OTC VMM Team.

Platform: Grantley-EP, Ivytown-EP

We found these issue blow. Hoping corresponding patches can be committed in Xen 
4.5 release.

Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, 
will fail.
http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html

Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to 
domain, more than 1 time, will fail with errors
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html
Note: this depends on issue 1. need to apply issue 1's patch to get it.

Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the 
guest config
http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html


Best Regards,
Robert Ho


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 32616: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32616 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32616/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32564

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 32564
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 32564
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32564
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 32564

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass

version targeted for testing:
 linux53262d12d1658669029ab39a63e3d314108abe66
baseline version:
 linux97bf6af1f928216fd6c5a66e8a57bfa95a659672


People who touched revisions under test:
  Alex Chen 
  Catalin Marinas 
  Davidlohr Bueso 
  Joe Thornber 
  Jungseok Lee 
  Kirill A. Shutemov 
  Linus Torvalds 
  Lorenzo Pieralisi 
  Marc Dionne 
  Marc Dionne 
  Mike Snitzer 
  Will Deacon 
  zhendong chen 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

2014-12-24 Thread Andy Lutomirski 
On Wed, Dec 24, 2014 at 1:30 PM, David Matlack  wrote:
> On Mon, Dec 22, 2014 at 4:39 PM, Andy Lutomirski  wrote:
>> The pvclock vdso code was too abstracted to understand easily and
>> excessively paranoid.  Simplify it for a huge speedup.
>>
>> This opens the door for additional simplifications, as the vdso no
>> longer accesses the pvti for any vcpu other than vcpu 0.
>>
>> Before, vclock_gettime using kvm-clock took about 64ns on my machine.
>> With this change, it takes 19ns, which is almost as fast as the pure TSC
>> implementation.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  arch/x86/vdso/vclock_gettime.c | 82 
>> --
>>  1 file changed, 47 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
>> index 9793322751e0..f2e0396d5629 100644
>> --- a/arch/x86/vdso/vclock_gettime.c
>> +++ b/arch/x86/vdso/vclock_gettime.c
>> @@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info 
>> *get_pvti(int cpu)
>>
>>  static notrace cycle_t vread_pvclock(int *mode)
>>  {
>> -   const struct pvclock_vsyscall_time_info *pvti;
>> +   const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>> cycle_t ret;
>> -   u64 last;
>> -   u32 version;
>> -   u8 flags;
>> -   unsigned cpu, cpu1;
>> -
>> +   u64 tsc, pvti_tsc;
>> +   u64 last, delta, pvti_system_time;
>> +   u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>>
>> /*
>> -* Note: hypervisor must guarantee that:
>> -* 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>> -* 2. that per-CPU pvclock time info is updated if the
>> -*underlying CPU changes.
>> -* 3. that version is increased whenever underlying CPU
>> -*changes.
>> +* Note: The kernel and hypervisor must guarantee that cpu ID
>> +* number maps 1:1 to per-CPU pvclock time info.
>> +*
>> +* Because the hypervisor is entirely unaware of guest userspace
>> +* preemption, it cannot guarantee that per-CPU pvclock time
>> +* info is updated if the underlying CPU changes or that that
>> +* version is increased whenever underlying CPU changes.
>> +*
>> +* On KVM, we are guaranteed that pvti updates for any vCPU are
>> +* atomic as seen by *all* vCPUs.  This is an even stronger
>> +* guarantee than we get with a normal seqlock.
>>  *
>> +* On Xen, we don't appear to have that guarantee, but Xen still
>> +* supplies a valid seqlock using the version field.
>> +
>
> Forgotten * here?
>
>> +* We only do pvclock vdso timing at all if
>> +* PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>> +* mean that all vCPUs have matching pvti and that the TSC is
>> +* synced, so we can just look at vCPU 0's pvti.
>>  */
>> -   do {
>> -   cpu = __getcpu() & VGETCPU_CPU_MASK;
>> -   /* TODO: We can put vcpu id into higher bits of pvti.version.
>> -* This will save a couple of cycles by getting rid of
>> -* __getcpu() calls (Gleb).
>> -*/
>> -
>> -   pvti = get_pvti(cpu);
>> -
>> -   version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>> -
>> -   /*
>> -* Test we're still on the cpu as well as the version.
>> -* We could have been migrated just after the first
>> -* vgetcpu but before fetching the version, so we
>> -* wouldn't notice a version change.
>> -*/
>> -   cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>> -   } while (unlikely(cpu != cpu1 ||
>> - (pvti->pvti.version & 1) ||
>> - pvti->pvti.version != version));
>> -
>> -   if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>> +
>> +   if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>> *mode = VCLOCK_NONE;
>> +   return 0;
>> +   }
>> +
>> +   do {
>> +   version = pvti->version;
>> +
>> +   /* This is also a read barrier, so we'll read version first. 
>> */
>> +   rdtsc_barrier();
>> +   tsc = __native_read_tsc();
>
> Is there a reason why you read the tsc inside the loop rather than once
> after the loop?

I want to make sure that the tsc value used is consistent with the
scale and offset.  Otherwise it would be possible to read the pvti
data, then get preempted and sleep for a long time before rdtsc.  The
result could be a time value larger than an immediate subsequent call
would return.

--Andy

>
>> +
>> +   pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
>> +   pvti_tsc_shift = pvti->tsc_shift;
>> +   pvti_system_time = pvti->system_time;
>> +   pvti_tsc = pvti->tsc_tim

[Xen-devel] [libvirt test] 32617: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32617 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32617/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 32596

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass

version targeted for testing:
 libvirt  7c6dbf35183aa636ae31290beef14af937a3b248
baseline version:
 libvirt  3865941be1fa5466d7892b24f1a2d7ee14f86712


People who touched revisions under test:
  Dmitry Guryanov 
  Martin Kletzander 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopsfail
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


commit 7c6dbf35183aa636ae31290beef14af937a3b248
Author: Dmitry Guryanov 
Date:   Tue Dec 23 16:23:34 2014 +0300

parallels: report, that cdrom image is raw

VIR_STORAGE_FILE_AUTO should be used only in xml provided to
libvirt by user, if I understood correctly. Driver should
set storage source format to specific disk format in
*DomainGetXMLDesc.

CDROMs in PCS use raw image format.

Signed-off-by: Dmitry Guryanov 

commit 42dc7a471d18c01a8e2fbff28c3b6c801ace37cd
Author: Martin Kletzander 
Date:   Tue Dec 23 06:10:55 2014 +0100

tests: Set up two more overrides for root builders

There are two more places after commit 3865941b that need to be adapted
in order to get rid of some test failures when building as root.

Signed-off-by: Martin Kletzander 

commit 31354b5b3246eb435adab78c513986748ddda727
Author: Martin Kletzander 
Date:   Tue Dec 23 05:32:45 2014 +0100

qemu: Fix coverity issues after refcount refactoring

Signed-off-by: Martin Kletzander 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 32612: tolerable FAIL

2014-12-24 Thread xen . org 
flight 32612 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32612/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate/x10 fail pass 
in 32594
 test-amd64-i386-xl-qemuu-ovmf-amd64  5 xen-bootfail in 32594 pass in 32612

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32594
 test-amd64-amd64-xl-sedf  7 debian-installfail in 32594 like 32574

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass

version targeted for testing:
 xen  36174af3fbeb1b662c0eadbfa193e77f68cc955b
baseline version:
 xen  36174af3fbeb1b662c0eadbfa193e77f68cc955b

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-x

Re: [Xen-devel] virtio_net: Fix napi poll list corruption

2014-12-24 Thread Marcelo Ricardo Leitner 

On 19-12-2014 22:23, Herbert Xu wrote:

David Vrabel  wrote:

After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n->poll(), and is only requeued if all of the
budget was used.  This inadvertently broke netfront because netfront
does not use NAPI correctly.


A similar bug exists in virtio_net.

-- >8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.

It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty.  However, like some
other drivers virtio_net tries to do a last-ditch check and if
there is more work it will call napi_schedule and then immediately
process some of this new work.  Should the entire budget be consumed
while processing such new work then we will violate the new caller
contract.

This patch fixes this by not touching any work when we reschedule
in virtio_net.

The worst part of this bug is that the list corruption causes other
napi users to be moved off-list.  In my case I was chasing a stall
in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
was virtio_net which caused the stall even though the virtio_net
poll was still functioning perfectly after IPsec stalled.


Thanks for finding/fixing this, Herbert. I was debugging this one too. In my 
case, vxlan interface was getting stuck.


  Marcelo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xc Python ext lib: Xen 4.6 Unable to start a 2T guest without OverflowError

2014-12-24 Thread Cathy Avery 
Starting a vm with memory over 2T resulted in an overflow error.

memory = 2097152 defined as number of megabytes returns the error
"OverflowError: signed integer is greater than maximum"

The error is the result of the python extension argument translator
defining max_memkb as a signed int instead of an unsigned int.
So PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb) overflowed by one with
2147483648 kb.

The other issue is that max_memkb is defined as uint64_t in the subsequent
domctl target api so the xc lib and its python C extension should use uint64_t 
as well.

/* XEN_DOMCTL_max_mem */
struct xen_domctl_max_mem {
/* IN variables. */
uint64_aligned_t max_memkb;
};

Signed-off-by: Cathy Avery 
---
 tools/libxc/include/xenctrl.h |2 +-
 tools/libxc/xc_domain.c   |2 +-
 tools/python/xen/lowlevel/xc/xc.c |4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..1b5c622 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1253,7 +1253,7 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
 
 int xc_domain_setmaxmem(xc_interface *xch,
 uint32_t domid,
-unsigned int max_memkb);
+uint64_t max_memkb);
 
 int xc_domain_set_memmap_limit(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index b864872..2c0fc9f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -630,7 +630,7 @@ int xc_shadow_control(xc_interface *xch,
 
 int xc_domain_setmaxmem(xc_interface *xch,
 uint32_t domid,
-unsigned int max_memkb)
+uint64_t max_memkb)
 {
 DECLARE_DOMCTL;
 domctl.cmd = XEN_DOMCTL_max_mem;
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index f83e33d..7a5d36e 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1658,9 +1658,9 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject 
*self, PyObject *args)
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
 uint32_t dom;
-unsigned int maxmem_kb;
+uint64_t maxmem_kb;
 
-if (!PyArg_ParseTuple(args, "ii", &dom, &maxmem_kb))
+if (!PyArg_ParseTuple(args, "ik", &dom, &maxmem_kb))
 return NULL;
 
 if (xc_domain_setmaxmem(self->xc_handle, dom, maxmem_kb) != 0)
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

2014-12-24 Thread Don Slutz 

On 12/22/14 02:04, Singhal, Upanshu wrote:


Hello Don,

xen_emul_unplug=unnecessary does the trick, I am able to see the 
vmxnet3 driver using lspci and ethtool --I eth0. Thanks a lot for your 
help, much appreciated.


Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
running on ESXi. Similar performance number I get between vmxnet3 on 
ESXi and vif on XEN. Do you know what could be the reason for this?




Not sure, but mtu does have a factor here.

And the full network layout, other uses of network, etc. all have impacts.

Have you checked out:

http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide

I have not been investigating network bandwidth.

   -Don Slutz


Thanks,

-Upanshu

*From:*Don Slutz [mailto:dsl...@verizon.com]
*Sent:* Saturday, December 20, 2014 3:59 AM
*To:* Singhal, Upanshu
*Cc:* xen-devel@lists.xen.org
*Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=unnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] 
(rev 02)

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II]

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
(rev 01)

00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
Ethernet Controller (rev 03)

00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
Ethernet Controller (rev 03)


And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
../../../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
../../../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
../../../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
../../../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
../../../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
../../../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
../../../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
../../../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
../../../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
../../../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
-> ../../../:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
-> ../../../:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
-> ../../../:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
-> ../../../:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
-> ../../../:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
-> ../../../:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
-> ../../../:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
-> ../../../:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
-> ../../../:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
-> ../../../:00:0d.0



   -Don Slutz

On 12/19/14 07:04, Singhal, Upanshu wrote:

Hello,

In one of my experiment, I am building a Linux VM with Network
interface model as "vmxnet3". I am able to create the VM
successfully, but I see that the driver loaded is "vif" and not
"vmxnet3". I am using the following option for the network
interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
bridge=xenbr0, model=vmxnet3' ]*

**

I tried with model as e1000 and it works fine. Lspci command also
does not show vmxnet3. Though, qemu device help shows that
"vmxnet3" is supported on XEN 4.4.1 version I am using.

I tried searching on internet about the right configuration for
vmxnet3 with XEN, but not able to find right information. Can
someone please help me on how to create a

[Xen-devel] [qemu-mainline test] 32611: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32611 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32611/

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. 32598
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install  fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-amd  7 redhat-installfail REGR. vs. 32598
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-installfail REGR. vs. 32598
 test-amd64-i386-freebsd10-amd64  8 guest-startfail REGR. vs. 32598
 test-amd64-amd64-xl-win7-amd64  7 windows-install fail REGR. vs. 32598
 test-amd64-i386-xl-win7-amd64  7 windows-install  fail REGR. vs. 32598
 test-amd64-i386-freebsd10-i386  8 guest-start fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-winxpsp3  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-rhel6hvm-intel  7 redhat-install  fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-win7-amd64  7 windows-installfail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 
32598
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install fail REGR. vs. 32598
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 
32598
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install fail REGR. vs. 32598
 test-amd64-i386-xl-winxpsp3   7 windows-install   fail REGR. vs. 32598
 test-amd64-i386-xl-qemuu-winxpsp3  7 windows-install  fail REGR. vs. 32598

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32598

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 qemuuab0302ee764fd702465aef6d88612cdff4302809
baseline version:
 qemuu7e58e2ac7778cca3234c33387e49577bb7732714


People who touched revisions under test:
  Alex Williamson 
  Eric Auger 
  Fabian Aggeler 
  Frank Blaschka 
  Greg Bellows 
  Kim Phillips 
  Laszlo Ersek 
  Marcel Apfelbaum 
  Paolo Bonzini 
  Peter Maydell 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebs

Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

2014-12-24 Thread Don Slutz 

On 12/23/14 05:51, Singhal, Upanshu wrote:


Hello Don,

I am not trying to configure VMW PVSCSI type of device but not able to 
do so. Though, PVSCSI is available on the distribution I am using. Any 
inputs on how to configure PVSCSI type disk device?




device_model_args_hvm = [
"-device",
"pvscsi,id=scsi1",
"-drive",
"if=none,id=disk1,file=/home/don/qemu-img/C63-min-disk1.raw",
"-device",
"scsi-disk,bus=scsi1.0,scsi-id=0,drive=disk1",
]

-Don Slutz


Thanks,

-Upanshu

*From:*Singhal, Upanshu
*Sent:* Monday, December 22, 2014 12:35 PM
*To:* 'Don Slutz'
*Cc:* 'xen-devel@lists.xen.org'
*Subject:* RE: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

Hello Don,

xen_emul_unplug=unnecessarydoes the trick, I am able to see the 
vmxnet3 driver using lspci and ethtool –I eth0. Thanks a lot for your 
help, much appreciated.


Performance between vmxnet3 running on XEN is about 1/3 of vmxnet3 
running on ESXi. Similar performance number I get between vmxnet3 on 
ESXi and vif on XEN. Do you know what could be the reason for this?


Thanks,

-Upanshu

*From:*Don Slutz [mailto:dsl...@verizon.com]
*Sent:* Saturday, December 20, 2014 3:59 AM
*To:* Singhal, Upanshu
*Cc:* xen-devel@lists.xen.org 
*Subject:* Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1

xen_emul_unplug=unnecessary (kernel arg) may help you here.

Also udev likes to rename your devices.

Here is a lspci from a guest:


[root@C63-min-tools ~]# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] 
(rev 02)

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II]

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device 
(rev 01)

00:03.0 VGA compatible controller: Cirrus Logic GD 5446
00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
Ethernet Controller (rev 03)

00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit 
Ethernet Controller (rev 03)


And to help:

[root@C63-min-tools ~]# ls -l /sys/class/net/*/device
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device -> 
../../../vif-0
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device -> 
../../../vif-1
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device -> 
../../../vif-2
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device -> 
../../../vif-3
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device -> 
../../../vif-4
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device -> 
../../../vif-5
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device -> 
../../../vif-6
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device -> 
../../../vif-7
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device -> 
../../../vif-8
lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device -> 
../../../vif-9
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device 
-> ../../../:00:04.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device 
-> ../../../:00:05.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device 
-> ../../../:00:06.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device 
-> ../../../:00:07.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device 
-> ../../../:00:08.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device 
-> ../../../:00:09.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device 
-> ../../../:00:0a.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device 
-> ../../../:00:0b.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device 
-> ../../../:00:0c.0
lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device 
-> ../../../:00:0d.0



-Don Slutz

On 12/19/14 07:04, Singhal, Upanshu wrote:

Hello,

In one of my experiment, I am building a Linux VM with Network
interface model as “vmxnet3”. I am able to create the VM
successfully, but I see that the driver loaded is “vif” and not
“vmxnet3”. I am using the following option for the network
interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22,
bridge=xenbr0, model=vmxnet3' ]*

**

I tr

[Xen-devel] [linux-3.10 test] 32607: regressions - FAIL

2014-12-24 Thread xen . org 
flight 32607 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32607/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 26303
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 26303

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install   fail pass in 32597
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 32597 pass in 32607
 test-amd64-i386-xl-credit25 xen-boot   fail in 32597 pass in 32607

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail   like 26303
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 
fail in 32597 blocked in 26303

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-amd64-libvirt  9 guest-start   fail in 32597 never pass

version targeted for testing:
 linuxa472efc75989c7092187fe00f0400e02c495c436
baseline version:
 linuxbe67db109090b17b56eb8eb2190cd70700f107aa


816 people touched revisions under test,
not listing them all


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test

[Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach failed

2014-12-24 Thread Liang Li 
Use the 'xl pci-attach $DomU $BDF' command to attach more then
one PCI devices to the guest, then detach the devices with
'xl pci-detach $DomU $BDF', after that, re-attach these PCI
devices again, an error message will be reported like following:

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: receive
an error message from QMP server: Duplicate ID 'pci-pt-03_10.1'
for device.

The count of calling xen_pt_region_add and xen_pt_region_del are
not the same will cause the XenPCIPassthroughState and it's related
QemuOpts object not be released properly.

Signed-off-by: Liang Li 
Reported-by: Longtao Pang 
---
 hw/xen/xen_pt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c1bf357..523b8a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -588,7 +588,6 @@ static void xen_pt_region_add(MemoryListener *l, 
MemoryRegionSection *sec)
 XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
  memory_listener);
 
-memory_region_ref(sec->mr);
 xen_pt_region_update(s, sec, true);
 }
 
@@ -598,7 +597,6 @@ static void xen_pt_region_del(MemoryListener *l, 
MemoryRegionSection *sec)
  memory_listener);
 
 xen_pt_region_update(s, sec, false);
-memory_region_unref(sec->mr);
 }
 
 static void xen_pt_io_region_add(MemoryListener *l, MemoryRegionSection *sec)
@@ -606,7 +604,6 @@ static void xen_pt_io_region_add(MemoryListener *l, 
MemoryRegionSection *sec)
 XenPCIPassthroughState *s = container_of(l, XenPCIPassthroughState,
  io_listener);
 
-memory_region_ref(sec->mr);
 xen_pt_region_update(s, sec, true);
 }
 
@@ -616,7 +613,6 @@ static void xen_pt_io_region_del(MemoryListener *l, 
MemoryRegionSection *sec)
  io_listener);
 
 xen_pt_region_update(s, sec, false);
-memory_region_unref(sec->mr);
 }
 
 static const MemoryListener xen_pt_memory_listener = {
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] enable Memory Bandwidth Monitoring (MBM) for VMs

2014-12-24 Thread Chao Peng 
On Tue, Dec 23, 2014 at 03:47:35PM +, Andrew Cooper wrote:
> On 23/12/2014 08:54, Chao Peng wrote:
> >Intel Memory Bandwidth Monitoring(MBM) is a new hardware feature
> >which builds on the CMT infrastructure to allow monitoring of system
> >memory bandwidth. Event codes are provided to monitor both "total"
> >and "local" bandwidth, meaning bandwidth over QPI and other external
> >links can be monitored.
> >
> >For XEN, MBM is used to monitor memory bandwidth for VMs. Due to its
> >dependency on CMT, the software also makes use of most of CMT codes.
> >Actually, besides introducing two additional events and some cpuid
> >feature bits, there are no extra changes compared to cache occupancy
> >monitoring in CMT. Due to this, CMT should be enabled first to use
> >this feature.
> >
> >For interface changes, the patch serial only introduces a new command
> >"XEN_SYSCTL_PSR_CMT_get_l3_event_mask" which exposes MBM feature
> >capability to user space and introduces two additional options for
> >"xl psr-cmt-show":
> >total_mem_bandwidth: Show total memory bandwidth
> >local_mem_bandwidth: Show local memory bandwidth
> >
> >The usage flow keeps the same with CMT.
> >
> >Chao Peng (4):
> >   x86: expose CMT L3 event mask to user space
> >   tools: libxc: add routine to get CMT L3 event mask
> >   tools: libxl: code preparation for MBM
> >   tools: add total/local memory bandwith monitoring
> 
> Please can you add a note about MBM in the command line documentation,
> beside the CMT information.
Sure.
Chao
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/4] tools: libxc: add routine to get CMT L3 event mask

2014-12-24 Thread Chao Peng 
On Tue, Dec 23, 2014 at 03:46:41PM +, Andrew Cooper wrote:
> 
> On 23/12/2014 08:54, Chao Peng wrote:
> >This is the xc side wrapper for XEN_SYSCTL_PSR_CMT_get_l3_event_mask
> >of XEN_SYSCTL_psr_cmt_op. Additional check for event id against value
> >got from this routine is also added.
> >
> >Signed-off-by: Chao Peng 
> >---
> >  tools/libxc/include/xenctrl.h |1 +
> >  tools/libxc/xc_psr.c  |   32 
> >  2 files changed, 33 insertions(+)
> >
> >diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> >index 0ad8b8d..96b357c 100644
> >--- a/tools/libxc/include/xenctrl.h
> >+++ b/tools/libxc/include/xenctrl.h
> >@@ -2697,6 +2697,7 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch, 
> >uint32_t domid,
> >  int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
> >  int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
> >  uint32_t *upscaling_factor);
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >  uint32_t *l3_cache_size);
> >  int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
> >index 872e6dc..94c8698 100644
> >--- a/tools/libxc/xc_psr.c
> >+++ b/tools/libxc/xc_psr.c
> >@@ -112,6 +112,30 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface 
> >*xch,
> >  return rc;
> >  }
> >+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask)
> >+{
> >+static int val = 0;
> >+int rc;
> >+DECLARE_SYSCTL;
> >+
> >+if ( val )
> >+{
> >+*event_mask = val;
> >+return 0;
> >+}
> >+
> >+sysctl.cmd = XEN_SYSCTL_psr_cmt_op;
> >+sysctl.u.psr_cmt_op.cmd =
> >+XEN_SYSCTL_PSR_CMT_get_l3_event_mask;
> >+sysctl.u.psr_cmt_op.flags = 0;
> >+
> >+rc = xc_sysctl(xch, &sysctl);
> >+if ( !rc )
> >+val = *event_mask = sysctl.u.psr_cmt_op.u.data;
> >+
> >+return rc;
> >+}
> >+
> >  int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
> >uint32_t *l3_cache_size)
> >  {
> >@@ -144,6 +168,7 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
> >  xc_resource_op_t op;
> >  xc_resource_entry_t entries[2];
> >  uint32_t evtid;
> >+uint32_t event_mask;
> >  int rc;
> >  switch ( type )
> >@@ -155,6 +180,13 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t 
> >rmid,
> >  return -1;
> >  }
> >+rc = xc_psr_cmt_get_l3_event_mask(xch, &event_mask);
> >+if ( rc < 0 )
> >+return rc;
> >+
> >+if ( !(event_mask & (1 << (evtid - 1))) )
> >+return -1;
> >+
> 
> This adds an extra hypercall on a common path to return a constant. As libxc
> is mostly a set of basic hypercall wrappers, I don't it should be validating
> its parameters like this.
> 
> The caller of xc_psr_cmt_get_data() must be aware of all the details, and
> whether certain events are supported or not.  I woud simply let the
> xc_resourse_op() fail (faulting on the wrmsr) if the caller passes a bad
> event id.
> 
Sounds reasonable. I'd move the validation to the caller, that's, the xl side.
Thanks Andrew.
> 
> >  entries[0].u.cmd = XEN_RESOURCE_OP_MSR_WRITE;
> >  entries[0].idx = MSR_IA32_CMT_EVTSEL;
> >  entries[0].val = (uint64_t)rmid << 32 | evtid;
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel